Data Lake vs Data Warehouse vs Data Mart — що є що й чим вони відрізняються

Привіт. Мене звуть Дмитро Москаленко, я працюю Chief Product & Technology Officer у компанії MAUDAU.

У цій статті я розповім про найпопулярніші підходи до структурування та зберігання даних — Data Lake, Data Warehouse і Data Mart. Поділюся своїм досвідом роботи з ними, поясню, чим вони відрізняються та як підібрати підхід відповідно до потреб проєкту. Розповідатиму просто та доступно, щоб навіть початківці могли ознайомитися із цими підходами та нюансами їх використання.

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

За типами вони можуть бути неструктуровані, напівструкторовані та структуровані. Які типи даних використовує бізнес, залежить від задач. Можна працювати з ними в будь-якому із цих проявів.

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

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

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

Що в них спільного

Data Lake, Data Warehouse і Data Mart — це підходи до керування даними та їхнього зберігання, тобто системи сховищ даних.

Усі вони потрібні для побудови системи аналітики, зокрема й «наскрізної». Це підхід, за якого бізнеси стараються аналізувати користувача на всіх етапах його залучення та взаємодії з продуктом, застосунком чи платформою: від джерел і ресурсів, звідки він приходить, до того, які дії він зробив або не зробив. Дані надходять з різних джерел: з Google Analytics, операційної аналітики, бухгалтерської, маркетингової тощо.

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

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

Наприклад існує CJM (customer journey map) — інструмент постійного дослідження та покращення продукту. Це графік, на який наносять основні шляхи взаємодії користувача з продуктом, канали комунікації з користувачем та емоції і дії гостя на кожному етапі його контакту з продуктом.

Щоб щоденно мати змогу оновлювати цю «карту», потрібно збирати та аналізувати дані про користувачів та їхні дії. Це можна реалізувати досить детально: за портретами користувачів, за джерелами, з яких вони приходять тощо. Щоб отримати ці деталі, потрібно поєднати дані про досвід контакту конкретного користувача з продуктом з різних джерел.

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

Про це не знає GA, але знає база самого проєкту. У ній відбивається повна історія замовлення до моменту, поки його не доставили клієнту.

Тобто маємо два різні джерела, дані з яких треба об’єднати. Для цього й потрібні Data Lake та Data Warehouse, бо якби воно було одне, не треба було б нічого будувати.

Усі ці підходи мають як спільні, так і відмінні риси. Складно розповідати про них, не порівнюючи.

Ключова відмінність — це підхід збереження даних: структурований він чи ні. Дуже спрощений приклад: бухгалтерський звіт в Excel — це Data Warehouse або Data Mart. Тут усі дані мають чітку структуру та формат. Якщо помістити цей же звіт одним текстом у Word, буде просто масив інформації — це Data Lake. Доведеться напружитися, щоб у ньому знайти потрібну інформацію.

Зараз, щоб зібрати базову Data-інфраструктура будь-яким із цих підходів, не обов’язково мати в команді Data-інженерів. Можна впоратися самостійно за допомогою інструментів від Amazon, Google, Microsoft тощо. Проте з Data Warehouse та Data Mart у майбутньому можуть виникнути труднощі. Про це розповім далі.

Що таке Data Lake і які в нього переваги та недоліки

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

У Data Lake («Озеро даних») використовується schema-on-read. Це підхід, у якому схема (структура) даних визначається не в момент їхнього збереження, а в момент їхнього читання.

Перша перевага Data Lake — відносно невисокий поріг входу. Для нього не потрібно розробляти структуру даних, приводити їх до певної нормальної форми тощо. Уже є інструменти, котрі дозволяють швидко організувати сховище для даних, налаштувати їхні «переливання» в Data Lake.

Звісно, це не все: потрібно побудувати data flow, у якому ми будемо очищати дані, за необхідності задавати їм структуру й так далі. Проте і для цього є готові рішення. Наприклад, AWS пропонує сервіс Glue для очищення даних, а для роботи з SQL — Athena, якщо беремо дані одразу зі сховища (наприклад, S3), або Redshift, якщо запити складні. Існують інструменти також для маппінгу даних, управління налаштуваннями Data Lake тощо.

За допомогою Amazon, Google та їхніх інструментів можна швидко зібрати Data Lake і працювати з ним. Створити його досить нескладно. Потрібно:

• обрати Cloud-провайдера (Amazon, Google Cloud Platform, Microsoft Azure тощо). Можна працювати на своєму залізі, хоча я давно не бачив, щоб хтось обирав цей варіант, бо буде дорожче і складніше.
• Обрати інструменти для зберігання даних. Наприклад, бакет S3 від Amazon, де можна зберігати будь-які типи файлів — від картинок до текстових.
• Мати розуміння, як побудувати Data Flow, та підібрати інструменти, щоб дані збиралися швидко, їх можна було очистити тощо.
• Підготувати налаштування і вуаля — усе готово.

Друга перевага — неструктуровані дані зберігати дешевше, бо вони просто зливаються в необробленому вигляді. Їх більше, але ми не платимо за їхнє обчислення. Оплата нараховується лише під час їх використання.

Якщо в проєкті петабайти даних, варто використовувати Data Lake: так вигідніше зберігати інформацію та швидше підключати нові джерела, бо тобі не потрібно осмислювати, як структурувати дані з них. Ти спершу все зливаєш, а потім вирішуєш, що потрібно, а що ні, що знадобиться стрімити в real-time, а що збирати раз на місяць.

Переваги Data Lake — масштабованість, гнучкість, зниження витрат. Для продукту, що має великі обсяги даних і динамічно розвивається, це гарне рішення.

Недоліки полягають у тому, що на роботу з Raw Data йде досить багато часу.

Розповім про свій досвід. Я використовував Data Lake під час побудови певного продукту — системи аналітики для WEB3-проєктів. Це актуально для напрямку таких проєктів, бо Google Analytics показує тільки інформацію по взаємодії з web-app, але не має даних щодо того, що відбувається в рамках blockchain.

Ми мали задачу створити інструмент, котрий би дозволив мати наскрізну аналітику, що поєднала б off-chain (web-app) і on-chain (blockchain) дані. Для цього нам потрібно було розробити збір в одному місці великої кількості даних у різних форматах і робити це у форматі real-time.

У blockchain мільярди транзакцій, які потрібно опрацьовувати, тому «зливати» собі потрібно всі дані, адже коли приходить користувач аналітики, ти не знаєш, де лежать конкретні транзакції його клієнтів. Щоб не платити за зберігання цих даних усі гроші світу, підходить Data Lake. Так треба сплачувати за опрацювання лише тих даних, котрі використовують клієнти й за опрацювання котрих, у цьому кейсі, можна отримати гроші.

Ще один не менш важливий нюанс: Data Lake — відносно свіжий напрям. Мало спеціалістів достеменно знають, як він працює. Навіть інструменти для роботи з ним подекуди схожі у своїй функціональності, але мають нюанси, через що є ризик зробити помилку. Тому Data Lake простіше зібрати ніж DWH, але можуть бути проблеми з масштабуванням, якщо не вірно обрати інструменти.

Що таке Data Warehouse і які його переваги та недоліки

Це централізована система для збереження та обробки структурованих даних. Оскільки дані приходять з різних джерел, у них різна структура. Щоб зберегти їх у DWH, потрібно їх обробити, тобто привести до нової єдиної структури. Data Warehouse як підхід містить так званий ETL (extract, transform, load) — процес того, як ти забираєш дані, трансформуєш (очищаєш, нормалізуєш, агрегуєш тощо) та завантажуєш у сховище.

Тут використовується підхід schema-on-write — коли дані одразу структуруються на момент запису. Тобто зберігаються лише структуровані дані — ті, що мають реляційну (логічну) структуру. Кожна сутність описується таблицею даних — набором полів з параметрами. Сутності мають залежності. Наприклад, один користувач може мати багато замовлень, а одне замовлення — багато позицій. Це різні таблиці, які мають різні ключі, щоб усе зв’язати.

У DWH можуть використовуватися і напівструктуровані дані. Вони мають певну структуру й залежності, за якими можна звернутися, наприклад, у певну підкатегорію, але всередині неї дані будуть неструктурованими.

Тож перша перевага Data Warehouse у тому, що він зберігає дані опрацьованими, очищеними, складеними в певній структурі даних. З ними одразу можна працювати: писати SQL query і збирати дашборди на рівні BI інструменту.

Кожна операція з обробки даних коштує грошей. Зберігання таких даних також впливає на ціну. Це дорожче, бо структуровані дані займають більший обсяг памʼяті через звʼязки, індекси та інші параметри. Окрім того, що це вимагає більше фізичного місця для збереження, DWH потребує додаткових ресурсів для роботи з ним, адже під час звернення до таблиць відбувається їхня віртуалізація (завантаження до ОЗУ), обчислення і виконання запиту. Під час роботи з Data Lake ресурси на обчислення також потрібні, але там перевага в тому, що опрацьовуються тільки дані, потрібні в моменті.

Якщо Data Warehouse побудований правильно, він буде працювати швидше, ніж Data Lake. Дані не потрібно буде на льоту трансформувати — вони вже готові до роботи. Тобто вартість обробки даних у цьому підході дорожча, ніж у Data Lake, але ми отримуємо швидкість у роботі з даними як за їхнього відображення, так і обчислені.

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

Це робить поріг входу складнішим. Я зустрічав дуже мало людей, котрі здатні створити крутий великий Data Warehouse і підтримувати його. Зазвичай це основна проблема. У Data Lake — простіше.

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

Таку точність можна гарантувати тільки завдяки структурованим даним. У неструктурованих дуже складно це організувати й нічого не пропустити.

На одному з попередніх проєктів я допомагав побудувати систему аналітики для страхової компанії. У них дуже стара кор-система, що має близько 15 різних баз: 1С, Google Analytics, CRM система зі своїм сховищем, додаткова система, написана на Oracle. Страхові компанії обмежені регуляторними нормами як і банки, тому їм теж потрібно подавати звіти за кожен квартал. Поки ми не розробили систему аналітики, вони витрачали два тижні, щоб вручну зібрати звіти. А про операційну та користувацьку аналітики я мовчу — її взагалі не було.

Той же DHW може бути першим простим кроком у побудові аналітики. Наприклад, якщо ви використовуєте в себе GA, у котрій є інформація про користувацькі сесії, її досить просто почати зливати в GBQ (Google Big Query). Це налаштовується в пару кліків. Далі через API GBQ туди можна закидувати інші дані з проєкту, котрі, наприклад, лежать у вашій БД. Таким способом можна поєднати два джерела даних, із котрих далі будується більш детальна аналітика.

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

Що таке Data Mart і які його переваги та недоліки

Із цих трьох підходів, Data Mart («Вітрина даних») — єдиний, який я ніколи окремо не використовував. Зазвичай він йшов у парі чи з DWH чи Data Lake.

Фактично це підтип Data Warehouse, його менша частина. Він має ті ж самі параметри, так само структурує і зберігає дані. Єдина відмінність у тому, що Data Warehouse розглядається як рішення на всю компанію, а Data Mart може бути частиною даних під конкретний напрямок чи відділ.

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

В одному проєкті можна одночасно використовувати Data Warehouse і Data Mart або Data Mart і Data Lake.

Наприклад, є компанія, що зливає багато даних, тому будує собі Data Lake. Водночас у неї є окремі дані, зібрані з підпискок (subscribtion) та клієнтів. Цих даних не так багато, тому для них раціонально зробити окремий Data Mart і на його базі зі структурованих даних робити фінансову звітність.

Data Mart також корисний інструмент, якщо в компанії є Data-security норми, коли доступ до певних даних мають лише деякі співробітники й тільки один Data-аналітик може працювати з показниками. Тоді їм можна надати обмежений доступ на рівні Data Mart.

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

Data Mart — це підмножина Data Werhouse, яка фокусується на конкретній області даних. Тому сам по собі Data Mart як підхід не може розв’язувати задачі цілої компанії. Тобто якщо DWH потрібен для побудови комплексного аналізу даних, то Data Mart підходить для розв’язання конкретних задач і запитів.

А от міксувати Data Warehouse і Data Lake — нераціонально. Це можливо, але питання в тому, скільки за це доведеться платити.

Зміна підходів

Інколи виникає потреба «переїхати» з одного підходу на інший. Наприклад, раніше я працював у проєкті з доставки продуктів Rocket. Певний час ми жили з форматом Data Warehouse, коли всі дані збирали в одному сховищі в Google BigQuery (далі — GBQ). Туди одразу зливалися дані з Google Analytics і ми вивантажували частину даних зі своїх баз. На основі цього Data-аналітики збирали репорти.

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

У проєктах таке трапляється часто: спершу будують Data Warehouse на базі GBQ, який, поки невеликий, працює швидко. Потім на нього починають навантажувати додаткові структури, але не проводять рев’ю (оцінку), скільки це буде коштувати і як впливатиме на перфоманс. Із часом він стає дуже дорогим і невигідним, до нього довго і важко підключати нові джерела, дані оновлюються повільно.

Це безпосередньо впливає на роботу проєкту. Тому доводиться переходити на Data Lake, чи змінювати інструмент. Але ця міграція може бути непростою задачею

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

Набагато складніше переїжджати з Data Lake в інший формат, бо необхідно великий обсяг неструктурованих даних опрацювати, проструктурувати та перенести.

Підсумуємо

Вибір підходу залежить від специфіки проєкту та задач, які є в плані аналітики.

Обирати Data Lake варто, якщо:

• проєкт пов’язаний із великими обсягами даних або великою кількістю джерел, які буде складно структурувати;
• команда розуміє, що проєкт буде інтенсивно розвиватися, обсяги даних швидко зростатимуть або додаватиметься велика кількість нових джерел;
• у команди немає експертизи для побудови DWH.

Обирати Data Warehouse краще, якщо:

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

Data Mart підійде проєктам, де:

• потрібна не комплексна аналітика, а, наприклад, лише фінзвітність;
• DWH чи Data Lake, який уже використовують у проєкті, не може розв’язати задачу для певного напряму / відділу, тому потрібна інша структура даних і т. д.;
• до частини даних повинна мати доступ обмежена кількість працівників.

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

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

Я вважаю, що більшості продуктів на ринку на старті з головою вистачить Data Warehouse — до того моменту, поки він не почне створювати проблеми. Хоча в нього поріг входу складніший, але завдяки готовим інструментам його можна швидко зібрати без допомоги Data-інженерів і використовувати в роботі. Наприклад той же GBQ, про який ми вже говорили, може певний час закривати потреби в комплексній аналітиці.

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

Проте якщо це стартап, на старті якого зрозуміло, що обсяг даних буде дуже великим (Data Science, проєкти з AI, лабораторні дослідження, IoT), краще одразу будувати Data Lake.

У більшості продуктів / проєктів на старті немає обсягів даних, для котрих потрібен Data Lake. Як на мене, використовувати його на невеликих проєктах — там, де немає терабайтів даних — може бути недоцільним. Мені здається, стандартна середньостатистична база даних — від 10 до 50 ГБ даних, а відсоток компаній, що справді мають highload і великий об’єм від петабайту даних на світовому рівні дорівнює близько 15 %.

Наприклад, у Rocket в нас було орієнтовно 300 запитів у секунду, мільйони користувачів, але навіть на таких обсягах у нас і близько не було терабайтів даних.

Ще років пʼять тому я не чув, щоб у компаніях використовували Data Lake, а зараз — кожна пʼята. Як на мене, головна причина, що він «пішов у маси» в тому, що про нього почали говорити топові компанії типу Google, Facebook. Тож усі захотіли й собі таке та почали це підхоплювати. Усі хочуть вважати, що в них масштабний проєкт, хочуть бути до цього дотичними.

Проте підхід мусить бути прагматичним: навіть якщо проєкт перспективний, але масштабується він через 2–3 роки, не варто вішати собі ярмо на шию. Краще ці гроші витратити, наприклад, на маркетинг.

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

Думаю, у майбутньому Data Lake ставатиме ще популярнішим. Враховуючи, як розвиваються технології cloud-провайдерів, ця історія прийде в стан, де в три кліки можна буде під’єднати різні джерела. Принаймні всі інструменти, котрі є зараз, розвиваються в цьому напрямку. І з інженерної точки зору, для Data Lake це просто простіше реалізувати, бо під час розробки таких інструментів не потрібно думати про можливі структури даних.

До речі, раджу слідкувати за cloud-провайдерами. Вони роблять багато безплатних презентацій, курсів, презентацій до своїх інструментів. Крім цього, якщо в тебе великий проєкт, можна прийти до провайдера з технічними питаннями і вони можуть виділити свого архітектора, що дасть тобі потрібні відповіді. У проєктах, де я працював раніше, ми так і робили, тож багато чого дізналися саме від спеціалістів.

Ще я рекомендую йти до них у блоги, бо там є багато статей, корисних відео та успішних кейсів клієнтів. Плюс, коли користуєшся інструментами, корисно стежити за оновленнями.