Це стаття переклад моєї статті на medium яка виявилася досить популярною, напевно через свою простоту. Тому я вирішив написати її російською мовою і трохи доповнити, щоб простій людині, яка не є фахівцем з роботи з даними, стало зрозуміло, що таке сховище даних (DW), а що таке озеро даних (Data Lake), і як вони разом уживаються .
Чому я захотів написати про озеро даних? Я працюю з даними та аналітикою більше 10 років, і зараз я точно працюю з великими даними в Amazon Alexa AI в Кембриджі, який у Бостоні, хоча сам живу у Вікторії на острові Ванкувер і часто буваю і в Бостоні, і в Сіетлі, і в Ванкувері, а іноді навіть у Москві виступаю на конференціях. Так само час від часу я пишу, але пишу в основному англійською, і написав уже , так само у мене є потреба ділитися трендами аналітики з Північної Америки, і я іноді пишу в .
Я завжди працював зі сховищами даних, і з 2015 року почав щільно працювати з Amazon Web Services, та й узагалі переключився на хмарну аналітику (AWS, Azure, GCP). Я спостерігав еволюцію рішень для аналітики з 2007 року і сам навіть попрацював у вендорі сховищ даних Терадата і впроваджував її в Ощадбанку, тоді і з'явилася Big Data з Hadoop. Всі стали говорити, що пройшла ера сховищ і тепер все на Hadoop, а потім вже почали говорити про Data Lake, знову ж таки, що тепер точно сховищу даних прийшов кінець. Але на щастя (може для когось і на нещастя, хто заробляв багато грошей на налаштуванні Hadoop), сховище даних не пішло.
У цій статті ми розглянемо, що таке озеро даних. Стаття розрахованих на людей, у яких мало досвіду зі сховищами даними чи ні.
На картинці озеро Блед, це одне з моїх улюблених озер, хоча я там був лише один раз, але запам'ятав його на все життя. Але ми поговоримо про інший тип озера – озеро даних. Можливо, багато хто з вас уже не раз чув про це цей термін, але ще одне визначення нікому не зашкодить.
Насамперед ось найпопулярніші визначення Озера Даних:
"файлове сховище всіх типів сирих даних, які доступні для аналізу будь-ким в організації" - Мартін Фовлер.
«Якщо ви думаєте, що вітрина даних – це пляшка води – очищеної, запакованої та розфасованої для зручного вживання, то озеро даних – це у нас величезний резервуар з водою в її природному вигляді. Користувачі, можу набирати води для себе, пірнати на глибину, дослідити» - Джеймс Діксон.
Тепер ми точно знаємо, що озеро даних це про аналітику, воно дозволяє нам зберігати великі обсяги даних у їхній початковій формі і у нас є необхідний і зручний доступ до даних.
Я часто люблю спрощувати речі, якщо я можу розповісти складний термін простими словами, отже, для себе я зрозумів, як це працює і для чого це потрібно. Як то, я копирсався в iPhone у фотогалереї, і мене осінило, так це ж справжнє озеро даних, я навіть зробив слайд для конференцій:
Все дуже просто. Ми робимо фотографію на телефон, фотографія зберігається на телефоні і може бути збережено в iCloud (файлове сховище у хмарі). Також телефон збирає мета-дані фотографії: що зображено, гео мітка, час. Як результат, ми можемо використовувати зручний інтерфейс iPhone, щоб знайти нашу фотографію і при цьому ми навіть бачимо показники, наприклад, коли я шукаю фотографії зі словом вогонь (fire), то я знаходжу 3 фотографії із зображенням вогнища. Для мене це прямий як Business Intelligence інструмент, який працює дуже швидко та чітко.
І звичайно, нам не можна забувати про безпеку (авторизацію та аутентифікацію), інакше наші дані можуть легко потрапити у відкритий доступ. Дуже багато новин, про великі корпорації та стартапи, у яких дані потрапили у відкритий доступ через недбалість розробників і не дотримання простих правил.
Навіть така проста картинка допомагає нам уявити, що таке озеро даних, його відмінності від традиційного сховища даних та його основні елементи:
- завантаження даних (Ingestion) – ключовий компонент озера даних. Дані можуть потрапляти до сховища даних двома способами – batch (завантаження з інтервалами) та streaming (потік даних).
- Файлове сховище (Storage) – головний компонент Озера Даних. Нам необхідно, що сховище було легко масштабоване, надзвичайно надійне і мало низьку вартість. Наприклад, в AWS це S3.
- Каталог та Пошук (Catalog and Search) — для того, щоб уникнути Болота Даних (це коли ми звалюємо всі дані в одну купу, і потім неможливо з ними працювати), нам необхідно створити шар мета-даних для класифікації даних, щоб користувачі легко могли знайти дані, які їм необхідні аналізу. Додатково можна використовувати додаткові рішення для пошуку, наприклад ElasticSearch. Пошук допомагає користувачеві шукати потрібні дані через зручний інтерфейс.
- Обробка (Process) – це крок відповідає за обробку та трансформацію даних. Ми можемо трансформувати дані, змінювати їх структури, очищати та багато іншого.
- Безпека (Security) – важливо витратити час на дизайн безпеки рішення. Наприклад, шифрування даних під час зберігання, обробки та завантаження. Важливо використовувати методи автентифікації та авторизації. Насамкінець, потрібен інструмент аудиту.
З практичної точки зору, ми можемо характеризувати озеро даних трьома атрибутами:
- Збирайте та зберігайте все що завгодно — озеро даних містить усі дані, як необроблені сирі дані за будь-який період часу, так і оброблених/очищені дані.
- Глибокий аналіз - озеро даних дозволяє користувачам досліджувати та аналізувати дані.
- Гнучкий доступ - озеро даних забезпечує гнучкий доступ для різних даних та різних сценаріїв.
Тепер можна поговорити про різницю між сховищем даних та озером даних. Зазвичай люди запитують:
- А як же сховище даних?
- Ми замінюємо сховище даних на озеро даних, чи ми його розширюємо?
- Чи можна все ж таки обійтися без озера даних?
Якщо коротко, то чіткої відповіді немає. Все залежить від конкретної ситуації, навичок у команді та бюджету. Наприклад, міграція сховища даних на Oracle в AWS і створення озера даних дочірньою компанією Амазон — Woot — .
З іншого боку, вендор Snowflake заявляє, що вам більше не потрібно думати про озеро даних, оскільки їх платформа даних (до 2020 року це було сховище даних), дозволяє вам поєднати і озеро даних і сховище даних. Я працював небагато зі Snowflake, і це дійсно унікальний продукт, який може так робити. Ціна питання, це інше питання.
На закінчення, моя особиста думка, що нам все ще потрібно сховище даних як основне джерело даних для нашої звітності, і все, що не міститься, ми зберігаємо в озері даних. Вся роль аналітики - це надати зручний доступ бізнесу для ухвалення рішень. Як не крути, але бізнес користувачі працюю ефективніше зі сховищем даних, ніж озером даних, наприклад в Amazon є Redshift (аналітичне сховище даних) і є Redshift Spectrum/Athena (SQL інтерфейс для озера даних в S3 на базі Hive/Presto). Те саме стосується інших сучасних аналітичних сховищ даних.
Давайте розглянемо типову архітектуру сховища даних:
Це класичне рішення. У нас є джерела системи, за допомогою ETL/ELT ми копіюємо дані в аналітичне сховище даних і підключаємо до Business Intelligence рішення (моє улюблене Tableau, а ваше?).
Таке рішення має такі недоліки:
- ETL/ELT операції потребують часу та ресурсів.
- Як правило, пам'ять для зберігання даних в аналітичному сховищі даних не дешева (наприклад Redshift, BigQuery, Teradata), тому що нам треба купувати цілий кластер.
- Бізнес-користувачі мають доступ до очищених і часто агрегованих даних і у них немає можливості отримати сирі дані.
Звичайно, все залежить від вашого кейсу. Якщо у вас немає проблем з вашим сховищем даних, то вам зовсім не потрібне озеро даних. Але коли виникають проблеми з нестачею місця, потужності чи ціна питання має ключову роль, можна розглянути варіант озера даних. Саме тому озеро даних дуже популярне. Ось приклад архітектури озера даних:
Використовуючи підхід озера даних, ми завантажуємо сирі дані до нашого озера даних (batch або streaming), далі ми обробляємо дані за потребою. Озеро даних дозволяє бізнес користувачам створювати власні трансформації даних (ETL/ELT) або аналізувати дані в рішеннях Business Intelligence (якщо є потрібний драйвер).
Мета будь-якого аналітичного рішення служити бізнес користувачам. Тому ми завжди маємо працювати від вимог бізнесу. (В Амазон це один із принципів – working backwards).
Працюючи і зі сховищем даних та з озером даних, ми можемо порівняти обидва рішення:
Основний висновок, який можна зробити, що сховище даних, не змагається з озером даних, а більше доповнює. Але це вирішувати, що підходить для вашого випадку. Завжди цікаво спробувати самому і зробити правильні висновки.
Я хотів би також розповісти один з кейсів, коли я почав використовувати підхід озера даних. Все досить банально, я спробував використати інструмент ELT (у нас був Matillion ETL) та Amazon Redshift, моє рішення працювало, але не вкладалося у вимоги.
Мені необхідно було взяти веб логи, трансформувати їх та агрегувати, щоб надати дані для 2х кейсів:
- Команда маркетингу хотіла аналізувати активність ботів для SEO
- IT хотіло дивитися метрики по роботі сайтів
Дуже прості, дуже прості логи. Ось приклад:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"Один файл важив 1-4 мегабайти.
Але була одна трудність. У нас було 7 доменів по всьому світу, за один день створювалося 7000 тисяч файлів. Це не більше обсягу, всього 50 гігабайт. Але розмір нашого кластера Redshift був також невеликим (4 ноди). Завантаження традиційним способом одного файлу займало близько хвилини. Тобто в лоб завдання не вирішувалося. І це був той випадок, коли я вирішив використати підхід озера даних. Рішення виглядало приблизно так:
Воно досить просте (я хочу зауважити, що перевага роботи у хмарі – це простота). Я використовував:
- AWS Elastic Map Reduce (Hadoop) як обчислювальна потужність
- AWS S3 як файлове сховище з можливістю шифрування даних та розмежування доступу
- Spark як InMemory обчислювальну потужність та PySpark для логіки та трансформації даних
- Parquet як результат роботи Spark
- AWS Glue Crawler як збирач метаданих про нові дані та партії
- Redshift Spectrum як SQL інтерфейс до озера даних для користувачів Redshift
Найменший кластер EMR+Spark обробляв усю пачку файлів за 30 хвилин. Є й інші кейси для AWS, особливо багато пов'язаних з Alexa, де дуже багато даних.
Нещодавно я дізнався один з недоліків озера даних - це GDPR. Проблема в тому, коли клієнт просить його видалити, а дані знаходяться в одному файлі, ми не можемо використовувати Data Manipulation Language і операцію DELETE як в базі даних.
Сподіваюся, стаття прояснила різниці між сховищем даних та озером даних. Якщо було цікаво, то можу перекласти свої статті або статті професіоналів, яких читаю. А також розповісти про рішення, з якими працюю, та їхню архітектуру.
Джерело: habr.com