Що таке data lake простими словами: як зберігають сирі дані

Компанія збирає логи мобільного застосунку, записи розмов колцентру, знімки з камер складу й таблиці продажів — і все це в різних форматах, різних обсягах і з різною швидкістю надходження. Класти таке в класичну базу даних дорого й боляче: спочатку треба все почистити, привести до єдиної структури, визначити схему. Саме для такої ситуації й придумали data lake — сховище, куди дані скидають у тому вигляді, в якому вони народилися, а розбирають уже тоді, коли з’являється конкретне питання.

Нижче розбираємо, що це за технологія, як вона працює під капотом, де межа між озером і болотом та коли бізнесу воно справді потрібне, а коли — просто модне слово в презентації.

Що таке data lake простими словами

Data lake (дослівно — «озеро даних») — це централізоване сховище, яке приймає дані будь-якого типу в первісному, «сирому» вигляді й зберігає їх без попередньої трансформації. Структуру й схему застосовують не на вході, а на виході — у момент, коли аналітик чи модель машинного навчання починає ці дані читати.

Термін запропонував Джеймс Діксон, технічний директор компанії Pentaho, приблизно у 2010 році. Він порівняв data lake з пляшкою води: якщо сховище даних (data warehouse) — це бутильована, очищена й розфасована вода для конкретного споживача, то озеро — природний резервуар, куди стікають різні потоки й звідки кожен бере те, що йому потрібно. Метафора прижилася, хоча сам Діксон пізніше скаржився, що її часто розуміють надто буквально. На відміну від озера, data warehouse зберігає вже очищені й структуровані дані під конкретні звіти.

Проста аналогія з повсякденного життя: уявіть гараж, куди складають інструменти, запчастини, старі коробки й спортивний інвентар без сортування. Зайвих витрат на організацію немає, місце дешеве, скласти можна все що завгодно. Але щоб щось знайти, доведеться або пам’ятати, де що лежить, або вести хоча б приблизний реєстр. Якщо реєстру немає — гараж швидко перетворюється на звалище.

Що саме кладуть в озеро

У data lake може потрапити практично все:

• структуровані дані — вигрузки з CRM, таблиці транзакцій, бухгалтерські реєстри;
• напівструктуровані — JSON-файли з API, XML-документи, логи серверів, CSV-вигрузки;
• неструктуровані — аудіо дзвінків, відео з камер, скани документів, листи, дописи в соцмережах;
• потокові дані — телеметрія датчиків, кліки користувачів на сайті, події з мобільних застосунків у реальному часі.

Ключове тут — відсутність вимоги до єдиного формату на вході. Один день у сховище падають мільйони рядків телеметрії, іншого — архів PDF-договорів за десять років.

Як data lake працює зсередини

Архітектура озера даних ґрунтується на принципі schema-on-read — «схема під час читання». Це головна відмінність від традиційних систем, де схему визначають заздалегідь (schema-on-write). Працює це так.

Дані потрапляють у сховище через механізми завантаження: пакетні вигрузки за розкладом, потокові конвеєри, прямі інтеграції з джерелами. На вході їх не чистять і не перетворюють — максимум розкладають по логічних зонах. Типове озеро ділять на кілька шарів:

• зона сирих даних (raw) — все в оригінальному вигляді, нічого не видаляється і не змінюється;
• зона очищених даних (curated) — дані після базової обробки: прибрані дублікати, узгоджені формати, додані обов’язкові поля;
• зона для споживання (analytics-ready) — агреговані набори, готові для звітів, дашбордів або навчання моделей.

Обчислення відбуваються поверх сховища окремими інструментами: SQL-рушіями, Spark-кластерами, сервісами машинного навчання. Саме розділення зберігання й обчислень робить підхід гнучким — можна збільшувати обсяг даних, не купуючи потужніші сервери для аналітики, і навпаки.

Технічно озера найчастіше будують на об’єктних сховищах хмарних провайдерів — Amazon S3, Azure Data Lake Storage, Google Cloud Storage — або на розподілених файлових системах на власному обладнанні, класичний приклад яких — HDFS у екосистемі Hadoop. Об’єктні сховища домінують, бо гігабайт там коштує копійки, а масштабування практично необмежене. Саме завдяки cloud computing озера даних масштабуються за потреби без закупівлі власних серверів.

Роль метаданих і каталогізації

Сирі файли без опису — це просто купа байтів. Щоб озеро працювало, поряд з даними зберігають метадані: звідки прийшов набір, коли оновлювався, хто власник, які в нього поля й що вони означають. Цією задачею займаються каталоги даних і сервіси на кшталт AWS Glue або Apache Atlas.

Саме каталогізація відділяє озеро від болота. Термін data swamp («болото даних») описує типову невдачу: компанія роками скидала в сховище все підряд, не ведучи обліку, і тепер ніхто не знає, що там лежить, чи можна цим користуватися і чи не застаріло воно. Витрати на зберігання ростуть, користі — нуль.

Чим data lake відрізняється від data warehouse

Ці два поняття часто плутають, хоча вони розв’язують різні задачі й дедалі частіше існують поряд. Порівняння найзручніше подати таблицею.

Коротка практична теза: сховище даних відповідає на відомі запитання швидко, озеро даних дозволяє ставити нові запитання, яких учора ще не існувало. Якщо компанії потрібен стабільний фінансовий звіт щопонеділка — це задача для warehouse. Якщо дата-сайєнтист хоче перевірити гіпотезу на логах трирічної давності — без озера не обійтися.

Останніми роками поширюється гібридна архітектура lakehouse, яка поєднує дешеве зберігання озера з транзакційними можливостями й швидкістю сховища. Формати на кшталт Delta Lake або Apache Iceberg дозволяють тримати одне сховище й для сирих файлів, і для акуратних таблиць.

Де data lake застосовують на практиці

Реальні сценарії краще за будь-які визначення показують, для чого технологія існує.

У ритейлі озеро збирає історію покупок, кліки на сайті, дані програм лояльності й навіть звернення в підтримку. На цьому фундаменті будують рекомендації товарів і прогнози попиту. Аналітик може за потреби повернутися до сирих кліків півторарічної давності й перевірити поведінку конкретного сегмента — у сховищі даних такої деталізації зазвичай уже немає.

У банках і фінтеху озера зберігають потоки транзакцій і логи систем моніторингу. Це основа для виявлення шахрайства: модель шукає аномалії у великих масивах сирих подій, а не лише в агрегованих зведеннях. Плюс сирий архів спрощує регуляторні перевірки — оригінали записів нікуди не зникли.

У виробництві датчики верстатів генерують тисячі показників на секунду. Зберігати це в аналітичній базі було б надто дорого, тому телеметрія падає в озеро, а алгоритми предиктивного обслуговування вчаться передбачати поломку за вібрацією й температурою ще до аварії.

Медичні й фармацевтичні організації складають в озера дослідницькі дані, результати лабораторних тестів і масиви знімків для навчання діагностичних моделей — звісно, з дотриманням вимог до персональних даних.

Переваги та обмеження підходу

Сильні сторони озера даних:

• дешеве зберігання практично необмежених обсягів;
• гнучкість — дані можна використати для задач, про які на момент збору ніхто не думав;
• жодні дані не втрачаються через невідповідність схемі;
• природна платформа для машинного навчання, де потрібні саме великі масиви сирої інформації.

Але є й обмеження, про які варто знати до старту проєкту. Швидкість аналітики без попередньої підготовки низька — запит по сирих JSON-логах на терабайти може виконуватися годинами. Якість даних ніхто не гарантує: сміття на вході означає сміття на виході. Безпека й розмежування доступу складніші, ніж у класичній базі, бо сховище одне, а рівнів конфіденційності в даних — багато. І нарешті, озеро вимагає дисциплінованої команди: без інженерів, які підтримують пайплайни й каталог, система деградує за рік-два.

Важливе застереження: data lake не замінює культуру роботи з даними. Технологія лише дає місце для зберігання; цінність створюють процеси каталогізації, контролю якості й управління доступом.

Хмара чи власна інфраструктура

Перші озера даних будували на власних серверах із Hadoop-кластерами — це було складно, дорого й вимагало окремої команди адміністраторів. З появою хмар ситуація змінилася: об’єктні сховища зробили вхід у технологію доступним навіть для невеликих компаній.

Хмарний варіант виграє в більшості випадків: оплата за фактично зайнятий обсяг, масштабування без закупівлі заліза, готові керовані сервіси для каталогізації й обчислень. Типові комбінації — S3 плюс Athena в екосистемі AWS, ADLS плюс Synapse в Azure, Cloud Storage плюс BigQuery в Google Cloud.

Власна інфраструктура досі має сенс у кількох сценаріях: жорсткі вимоги регуляторів щодо розміщення даних, дуже великі й стабільні обсяги, де капітальні витрати на сервери за кілька років дешевші за хмарну оренду, або наявні інвестиції в дата-центр. Нерідко зустрічається й гібрид: чутливі дані лежать у власному сховищі, а масиви для аналітики й машинного навчання — у хмарі.

Типові помилки при запуску озера даних

Більшість невдалих проєктів провалюються не через технологію, а через організацію. Найчастіші помилки виглядають так:

1. Зберігати все без плану. «Складемо, потім розберемося» — прямий шлях до болота. Навіть сирі дані потребують мінімального реєстру джерел.
2. Ігнорувати каталог метаданих. Без нього пошук потрібного набору перетворюється на археологічні розкопки.
3. Не визначати власників даних. Якщо за набір ніхто не відповідає, він застаріває, і ніхто цього не помічає.
4. Забути про життєвий цикл. Частина даних втрачає цінність або підлягає видаленню за законом — потрібні політики архівації та ретенції.
5. Будувати озеро «бо всі будують». Якщо компанії достатньо звітів із однієї CRM, озеро стане дорогою іграшкою.

Часті запитання про data lake

Чим data lake відрізняється від звичайної бази даних?

База даних зберігає інформацію в суворо визначеній структурі й оптимізована під конкретні операції — наприклад, облік замовлень. Озеро приймає будь-які формати без структури й слугує довготривалим архівом і джерелом для аналізу, а не операційною системою.

Чи потрібен data lake малому бізнесу?

Зазвичай ні. Якщо всі дані компанії вміщаються в кілька систем і потрібна лише стандартна звітність, вистачить бази даних і простого сховища. Озеро починає окупатися, коли обсяги великі, джерел багато, а формати різноманітні.

Що таке data swamp?

Так жартома називають озеро, яке перетворилося на болото: дані накопичували без каталога, контролю якості та власників, і сховищем стало неможливо користуватися. Це найпоширеніший сценарій провалу.

Чи можна обійтися тільки data lake без сховища даних?

Теоретично так, особливо з сучасними lakehouse-форматами, але на практиці регулярну бізнес-звітність швидше й зручніше будувати поверх оптимізованого сховища. Найчастіше обидві системи працюють паралельно.

Наскільки дорого обходиться озеро даних?

Саме зберігання в хмарі коштує недорого — рахунок рахують за гігабайти на місяць. Основні витрати йдуть на обчислення, коли дані обробляють, і на роботу інженерів, які підтримують інфраструктуру. Точна сума залежить від обсягів і частоти аналітики.

Як зрозуміти, що компанії час будувати озеро

Є кілька практичних сигналів, що data lake — не примха, а потреба: дані надходять із багатьох систем у різних форматах, і їхнє узгодження «на льоту» забирає надто багато часу; дата-сайєнтистам або аналітикам регулярно потрібні історичні сирі дані, яких у звітах уже немає; обсяги зростають так, що зберігати все в аналітичних базах стає надто дорого; з’являються задачі машинного навчання, яким потрібні великі масиви необробленої інформації. Якщо жоден із цих пунктів не про вас — почніть із простішого рішення, а озеро залиште на потім. Технологія легко масштабується, тож пізно почати майже не буває.