Що таке озеро даних? Визначення, ArchiТекстура та найкращі практики

⚡ Розумний підсумок

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

  • 🗄️ Основне визначення: Репозиторій, що містить усі типи даних у необробленому вигляді, без фіксованого обмеження на розмір облікового запису чи файлу.
  • 🏗️ Рівнева структура: Отримання, зберігання, дистиляція, обробка, аналітика та уніфіковані операції формують шість архітектурних рівнів.
  • 🔑 Основні компоненти: Прийом, зберігання, управління, безпека, якість, виявлення, аудит, походження та дослідження повинні працювати разом.
  • 📈 Шлях зрілості: Чотири етапи переводять організацію від первинного отримання даних до повноцінного корпоративного управління в межах озера.
  • 🇧🇷 Контраст складу: Озера застосовують схему на читання для фахівців з обробки даних, сховища застосовують схему на запис для бізнес-звітності.
  • ⚠️ Основний ризик: Слабкий контроль доступу та відсутність нагляду перетворюють некероване озеро на непридатне для використання болото даних.

Що таке озеро даних Archiтектура

Що таке озеро даних?

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

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

Озеро даних
Озеро даних

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

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

Чому Data Lake?

Основна мета побудови озера даних — запропонувати дослідникам даних неуточнене уявлення про дані.

Причини використання Data Lake:

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

Озеро даних Archiтектура

Озеро даних Archiтектура
Озеро даних Archiтектура

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

  1. Рівень прийому: Рівні ліворуч зображують джерела даних. Дані можна завантажувати в озеро даних пакетами або в режимі реального часу
  2. Рівень статистики: Рівні праворуч представляють дослідницьку сторону, де використовуються аналітичні дані системи. SQL, запити NoSQL або навіть excel можна використовувати для аналізу даних.
  3. HDFS є економічно ефективним рішенням як для структурованих, так і для неструктурованих даних. Це зона посадки для всіх даних, які перебувають у стані спокою в системі.
  4. Перегінний ярус бере дані з рівня сховища та перетворює їх на структуровані дані для легшого аналізу.
  5. Ярус обробки запускати аналітичні алгоритми та запити користувачів із змінним режимом реального часу, інтерактивними, пакетними, щоб генерувати структуровані дані для полегшення аналізу.
  6. Уніфікований рівень операцій керує управлінням і моніторингом системи. Він включає в себе аудит і управління кваліфікацією, управління даними, управління робочим процесом.

Озеро ключових даних Concepts

Нижче наведено ключові концепції Data Lake, які потрібно зрозуміти, щоб повністю зрозуміти Data Lake Archiтектура

Приймання даних

Приймання даних дозволяє конекторам отримувати дані з різних джерел даних і завантажувати їх в озеро даних.

Передача даних підтримує:

  • Усі типи структурованих, напівструктурованих і неструктурованих даних.
  • Кілька прийомів, як-от пакетне, у реальному часі, одноразове завантаження.
  • Багато типів джерел даних, як-от бази даних, веб-сервери, електронні листи, IoTі FTP.

зберігання даних

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

Управління даними

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

Безпека

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

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

Якість даних

Якість даних є важливим компонентом архітектури Data Lake. Дані використовуються для визначення бізнес-цінності. НаприкладtracОтримання висновків з даних низької якості призведе до висновків низької якості.

Виявлення даних

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

Аудит даних

Два основні завдання аудиту даних: tracзміни короля до ключового набору даних.

  1. Tracking зміни важливих елементів набору даних
  2. Фіксує, як/коли/хто змінює ці елементи.

Аудит даних допомагає оцінити ризик і відповідність.

Родовід даних

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

Дослідження даних

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

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

Популярні платформи Data Lake

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

  • Amazon S3 з формуванням озера AWS: Сховище об'єктів у поєднанні зі службою, яка реєструє джерела, встановлює дозволи та створює каталог даних. Див. Підручник AWS для ширшої екосистеми.
  • Azure Сховище даних озера 2-го покоління: Додає ієрархічний простір імен поверх сховища BLOB-об'єктів, що забезпечує безпеку на рівні каталогу та швидший доступ до аналітики.
  • Google Cloud Зберігання з BigLake: Поєднує сховище об'єктів із рівнем запитів, який безпосередньо зчитує відкриті формати таблиць.
  • Apache Hadoop з HDFS: Початковий локальний варіант, який досі використовується там, де дані мають залишатися в приватному центрі обробки даних.
  • Цеглини даних та сніжинка: Платформи, що об'єднують формати таблиць, такі як Delta Lake та Apache Iceberg поверх об'єктного сховища для додавання транзакцій та керування версіями.

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

Стадії зрілості Data Lake

Визначення етапів зрілості озера даних відрізняється від підручника до іншого. Хоча суть залишається та ж. Після зрілості визначення стадії відбувається з точки зору неспеціаліста.

Етап 1: обробка та прийом даних у масштабі

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

Етап 2: Формування аналітичної мускулатури

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

Етап 3: EDW і Data Lake працюють в унісон

Цей крок передбачає отримання даних і аналітики якомога більшої кількості людей. На цьому етапі озеро даних і корпоративне сховище даних починають працювати в об’єднанні. Обидва відіграють свою роль в аналітиці

Етап 4: Можливості підприємства в озері

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

Найкращі практики впровадження Data Lake

  • Archiструктурні компоненти, їх взаємодія та визначені продукти повинні підтримувати рідні типи даних
  • Дизайн Data Lake має ґрунтуватися на доступності, а не на вимогах. Схема та вимога до даних не визначені, доки не буде отримано запит
  • Дизайн повинен керуватися одноразовими компонентами, інтегрованими з API служби.
  • Виявленням, прийомом, зберіганням, адмініструванням, якістю, перетворенням і візуалізацією даних слід керувати незалежно.
  • Архітектура Data Lake повинна бути адаптована до конкретної галузі. Він повинен гарантувати, що можливості, необхідні для цього домену, є невід’ємною частиною проекту
  • Швидке включення нових виявлених джерел даних є важливим
  • Data Lake допомагає налаштованому управлінню досягтиtracмаксимальне значення t
  • Озеро даних має підтримувати існуючі техніки та методи керування корпоративними даними

Проблеми створення озера даних:

  • У Data Lake обсяг даних більший, тому процес має бути більш залежним від програмного адміністрування
  • Важко мати справу з розрідженими, неповними, мінливими даними
  • Більший обсяг набору даних і джерела потребує більшого управління даними та підтримки

⚠️ Попередження: Озеро без каталогізованих метаданих та правил доступу перетворюється на болото даних. Дані є, але ніхто не може їх знайти, довіряти їм або довести, хто їх змінив. Тому управління є вимогою запуску, а не пізнішим етапом.

Різниця між озерами даних і сховищем даних

У наступному порівнянні підсумовано, де знаходиться кожен магазин. Більш детальний аналіз доступний у озеро даних проти сховища даних порівняння.

Параметри Озера даних Інформаційне сховище
дані Озера даних зберігають усе. Data Warehouse фокусується лише на бізнес-процесах.
Обробка Дані переважно не оброблені Інтенсивно оброблені дані.
Тип даних Він може бути неструктурованим, напівструктурованим і структурованим. Здебільшого він має табличну форму та структуру.
Завдання Обмін даними Оптимізовано для пошуку даних
Спритність Висока гнучкість, налаштування та переналаштування за потреби. Порівняно з Data lake, воно менш гнучке та має фіксовану конфігурацію.
користувачів Data Lake в основному використовується Data Scientist Бізнес-професіонали широко використовують Data Warehouse
зберігання Дизайн озер даних для недорогого зберігання. Використовується дороге сховище, яке забезпечує швидкий час відгуку
Безпека Пропонує менший контроль. Дозволяє краще контролювати дані.
Заміна EDW Озеро даних може бути джерелом для EDW Доповнення до EDW (не заміна)
схема Схема під час читання (немає попередньо визначених схем) Схема під час запису (попередньо визначені схеми)
Обробка даних Допомагає швидко вводити нові дані. Введення нового вмісту займає багато часу.
Деталізація даних Дані з низьким рівнем деталізації або деталізації. Дані на зведеному або зведеному рівні деталізації.
Інструменти Можна використовувати інструменти з відкритим кодом, такі як Hadoop/ Map Reduce В основному комерційні інструменти.

Що таке Data Lakehouse?

Наведене вище порівняння передбачає дві окремі системи. Data Lakehouse об'єднує їх в одну, саме тому цей термін з'являється в більшості сучасних обговорень архітектури.

Lakehouse зберігає необроблені файли в недорогому об'єктному сховищі, а потім додає шар транзакційних метаданих через відкриті табличні формати, такі як Delta Lake, Apache Iceberg або Apache Hudi. Цей рівень забезпечує гарантії, які надає сховище даних, поки базові файли залишаються відкритими.

Можливості Озеро даних Data Lakehouse
Transactions Не підтримується ACID-транзакції на таблицях
Обробка схеми Схема лише для читання Застосування та еволюція схеми
Основні користувачі Вчені-дані Аналітики та фахівці з обробки даних разом
Швидкість звітності Повільно без окремого складу Прямі запити з індексацією та кешуванням

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

Переваги та ризики використання Data Lake

Ось деякі основні переваги використання озера даних:

  • Повністю допомагає з продакшеном та розширеною аналітикою
  • Пропонує економічно ефективну масштабованість і гнучкість
  • Пропонує цінність необмеженої кількості типів даних
  • Зменшує довгострокову вартість володіння
  • Дозволяє економічно зберігати файли
  • Швидко адаптується до змін
  • Головною перевагою озера даних є централізація різних джерел вмісту
  • Користувачі з різних відділів можуть бути розкидані по всьому світу гнучкий доступ до даних

Ризик використання Data Lake:

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

Поширені запитання

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

Колонкові формати, такі як Parquet та ORC, добре стискаються та дозволяють запитам зчитувати лише необхідні стовпці. JSON та CSV залишаються корисними в зоні необробленого цільового простору перед конвертацією.

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

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

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

Підсумуйте цей пост за допомогою: