Інформаційне сховище. Озеро даних. Lakehouse. Якщо жодне з цих слів не резонує з вами хоча б трохи, то ваша робота явно не пов’язана з даними.
Однак це було б досить нереалістичним припущенням, оскільки сьогодні все пов’язано з даними. Або як це люблять описувати керівники компаній:
- Бізнес, орієнтований на дані та керований даними.
- Дані будь-де, будь-коли та будь-яким чином.
Найважливіший актив
Здається, дані стають найціннішим активом все більшої кількості компаній. Я пам’ятаю, великі корпорації завжди створювали багато даних, думаю, терабайти нових даних щомісяця. Це було ще років 10-15 тому. Але тепер ви можете легко створити таку кількість даних протягом кількох днів. Можна було б запитати, чи це дійсно необхідно, навіть якщо це певний вміст, який будь-хто використовуватиме. І так, точно ні 😃.
Не весь вміст буде корисним, а деякі частини навіть не один раз. Я часто був свідком на передовій, як компанії генерували величезну кількість даних, щоб стати марними після успішного завантаження.
Але це вже не актуально. Зберігання даних – тепер у хмарі – дешеве, джерела даних зростають у геометричній прогресії, і сьогодні ніхто не може передбачити, що їм знадобиться через рік, коли в систему ввійдуть нові служби. У цей момент навіть старі дані можуть стати цінними.
Тому стратегія полягає в тому, щоб зберігати якомога більше даних. Але також у максимально ефективній формі. Таким чином, дані можна не тільки ефективно зберігати, але й запитувати, повторно використовувати або перетворювати та поширювати далі.
Давайте розглянемо три рідні способи, як це зробити в AWS:
- Athena Database – дешевий і ефективний, але простий спосіб створити озеро даних у хмарі.
- Redshift Database – серйозна хмарна версія сховища даних, яка має потенціал замінити більшість поточних локальних рішень, не в змозі наздогнати експоненційне зростання даних.
- Databricks – поєднання озера даних і сховища даних в одному рішенні з деякими бонусами на додачу до всього цього.
Data Lake від AWS Athena
Джерело: aws.amazon.com
Озеро даних — це місце, де можна швидко зберігати вхідні дані в неструктурованому, напівструктурованому або структурованому вигляді. У той же час ви не очікуєте, що ці дані будуть змінені після їх збереження. Натомість ви хочете, щоб вони були максимально атомарними та незмінними. Тільки це забезпечить найбільший потенціал для повторного використання на наступних етапах. Якщо ви втратите цю атомарну властивість даних відразу після першого завантаження в озеро даних, неможливо буде повернути цю втрачену інформацію.
AWS Athena — це база даних зі сховищем безпосередньо в сегментах S3 і без кластерів серверів, що працюють у фоновому режимі. Це означає, що це дійсно дешевий сервіс озера даних. Структуровані формати файлів, такі як файли parquet або файли зі значеннями, розділеними комами (CSV), підтримують організацію даних. Відро S3 містить файли, і Athena звертається до них щоразу, коли процеси вибирають дані з бази даних.
Athena не підтримує різні функції, які інакше вважаються стандартними, як-от оператори оновлення. Ось чому вам потрібно дивитися на Athena як на дуже простий варіант. З іншого боку, це допомагає вам запобігти модифікації вашого атомарного озера даних просто тому, що ви не можете 😐.
Він підтримує індексування та розділення, що робить його придатним для ефективного виконання операторів select і створення логічно окремих фрагментів даних (наприклад, розділених датою або ключовими стовпцями). Він також може дуже легко масштабуватися горизонтально, оскільки це так само складно, як додавання нових сегментів до інфраструктури.
Плюси і мінуси
Переваги, які слід враховувати:
- Той факт, що Athena дешева (складається лише з сегментів S3 і витрат на використання SQL за кожне використання), є найбільшою перевагою. Якщо ви хочете створити доступне озеро даних в AWS, це все.
- Як національний сервіс Athena може легко інтегруватися з іншими корисними сервісами AWS, такими як Amazon QuickSight для візуалізації даних або AWS Glue Data Catalog, для створення постійних структурованих метаданих.
- Найкраще підходить для виконання спеціальних запитів до великої кількості структурованих або неструктурованих даних без підтримки цілої інфраструктури навколо них.
Недоліки, які слід враховувати:
- Athena не дуже ефективна у швидкому поверненні складних запитів на вибірку, особливо якщо запити не відповідають припущенням моделі даних про те, як ви розробили запит даних з озера даних.
- Це також робить його менш гнучким щодо потенційних майбутніх змін у моделі даних.
- Athena не підтримує жодних додаткових розширених функцій із коробки, і якщо ви хочете, щоб щось конкретне було частиною сервісу, вам потрібно реалізувати це поверх.
- Якщо ви очікуєте, що дані озера даних будуть використовуватися на більш просунутому рівні представлення, часто єдиним вибором буде поєднати його з іншою службою бази даних, більш придатною для цієї мети, як-от AWS Aurora або AWS Dynamo DB.
Призначення та використання в реальному світі
Виберіть Athena, якщо метою є створення простого озера даних без розширених функцій, подібних до сховищ даних. Так, наприклад, якщо ви не очікуєте серйозних високопродуктивних аналітичних запитів, які регулярно виконуються в озері даних. Натомість пріоритетом є наявність пулу незмінних даних із простим розширенням для зберігання даних.
Вам більше не потрібно надто турбуватися про брак місця. Навіть вартість зберігання відра S3 можна ще більше зменшити, запровадивши політику життєвого циклу даних. По суті, це означає переміщення даних між різними типами сегментів S3, націлених більше на архівні цілі з повільнішим часом повернення, але меншими витратами.
Чудовою особливістю Athena є те, що вона автоматично створює файл, що складається з даних, які є частиною результату вашого SQL-запиту. Потім ви можете взяти цей файл і використовувати його для будь-яких цілей. Тож це хороший варіант, якщо у вас є багато лямбда-сервісів, які додатково обробляють дані в кілька етапів. Кожен лямбда-результат автоматично буде результатом у форматі структурованого файлу як вхідні дані, готові для подальшої обробки.
Athena є хорошим варіантом у ситуаціях, коли велика кількість необроблених даних надходить у вашу хмарну інфраструктуру, і вам не потрібно обробляти їх під час завантаження. Це означає, що все, що вам потрібно, це швидке зберігання в хмарі в зрозумілій структурі.
Іншим варіантом використання може бути створення спеціального простору для цілей архівування даних для іншого сервісу. У такому випадку Athena DB стане дешевим місцем резервного копіювання всіх даних, які вам зараз не потрібні, але це може змінитися в майбутньому. На цьому етапі ви просто отримаєте дані та надішлете їх далі.
Сховище даних від AWS Redshift
Джерело: aws.amazon.com
Сховище даних – це місце, де дані зберігаються дуже структурованим способом. Легко завантажувати та витягувати. Намір полягає в тому, щоб виконувати велику кількість дуже складних запитів, об’єднуючи багато таблиць за допомогою складних об’єднань. Існують різні аналітичні функції для обчислення різних статистичних даних за наявними даними. Кінцева мета полягає в тому, щоб отримати майбутні прогнози та факти для подальшого використання в бізнесі, використовуючи наявні дані.
Redshift — це повноцінна система сховища даних. З кластерними серверами для налаштування та масштабування – горизонтально та вертикально та системою зберігання бази даних, оптимізованою для швидкого повернення складних запитів. Хоча сьогодні ви можете запустити Redshift і в безсерверному режимі. Немає файлів на S3 або щось подібне. Це стандартний кластерний сервер бази даних із власним форматом зберігання.
Він має готові інструменти моніторингу продуктивності, а також настроювані показники інформаційної панелі, які можна використовувати та спостерігати, щоб точно налаштувати продуктивність для свого випадку використання. Адміністрація також доступна через окремі панелі керування. Потрібні певні зусилля, щоб зрозуміти всі можливі функції та налаштування та те, як вони впливають на кластер. Але все одно це не так складно, як адміністрування серверів Oracle у випадку локальних рішень.
Незважаючи на те, що в Redshift існують різні обмеження AWS, які встановлюють певні обмеження щодо щоденного використання (наприклад, жорсткі обмеження на кількість одночасних активних користувачів або сеансів в одному кластері бази даних), той факт, що операції виконується дуже швидко, допомагає певною мірою обійти ці обмеження.
Плюси і мінуси
Переваги, які слід враховувати:
- Власна служба хмарного сховища даних AWS, яку легко інтегрувати з іншими службами.
- Центральне місце для зберігання, моніторингу та прийому різних типів джерел даних із дуже різних джерельних систем.
- Якщо ви коли-небудь хотіли мати безсерверне сховище даних без інфраструктури для його підтримки, тепер ви можете.
- Оптимізовано для високопродуктивного аналізу та звітності. На відміну від рішення озера даних, існує сильна реляційна модель даних для зберігання всіх вхідних даних.
- Механізм баз даних Redshift походить від PostgreSQL, що забезпечує високу сумісність з іншими системами баз даних.
- Дуже корисні оператори COPY і UNLOAD для завантаження та вивантаження даних із та до сегментів S3.
Недоліки, які слід враховувати:
- Redshift не підтримує велику кількість одночасних активних сеансів. Сеанси будуть призупинені та оброблятимуться послідовно. Хоча в більшості випадків це може не бути проблемою, оскільки операції дуже швидкі, це обмежуючий фактор у системах із великою кількістю активних користувачів.
- Незважаючи на те, що Redshift підтримує багато функціональних можливостей, раніше відомих у зрілих системах Oracle, він все ще не на такому ж рівні. Деякі з очікуваних функцій можуть бути відсутні (наприклад, тригери БД). Або Redshift підтримує їх у досить обмеженій формі (наприклад, матеріалізовані перегляди).
- Щоразу, коли вам потрібна розширеніша спеціальна робота з обробки даних, ви повинні створити її з нуля. У більшості випадків використовуйте мову коду Python або Javascript. Це не так природно, як PL/SQL у випадку системи Oracle, де навіть функції та процедури використовують мову, дуже схожу на запити SQL.
Призначення та використання в реальному світі
Redshift може стати вашим центральним сховищем для всіх різноманітних джерел даних, які раніше існували поза хмарою. Це дійсна заміна попередніх рішень для сховищ даних Oracle. Оскільки це також реляційна база даних, міграція з Oracle є досить простою операцією.
Якщо у вас є будь-які існуючі рішення для сховищ даних у багатьох місцях, які насправді не є уніфікованими з точки зору підходу, структури чи попередньо визначеного набору загальних процесів для запуску над даними, Redshift — чудовий вибір.
Це просто надасть вам можливість об’єднати всі різноманітні системи сховищ даних з різних місць і країн під одним дахом. Ви все ще можете розділити їх за країнами, щоб дані залишалися безпечними та доступними лише для тих, кому вони потрібні. Але в той же час це дозволить вам створити уніфіковане складське рішення, що охоплює всі корпоративні дані.
Інший випадок може бути, якщо метою є створення платформи сховища даних із широкою підтримкою самообслуговування. Ви можете розуміти це як набір обробки, який можуть створити окремі користувачі системи. Але в той же час вони ніколи не є частиною спільного платформного рішення. Це означає, що такі послуги залишаться доступними лише для творця або групи людей, визначених створеним. Вони жодним чином не вплинуть на решту користувачів.
Перегляньте наше порівняння між Datalake і Datawarehouse.
Lakehouse від Databricks на AWS
Джерело: databricks.com
Lakehouse — це термін, який дійсно пов’язаний із сервісом Databricks. Навіть якщо це не рідний сервіс AWS, він чудово живе та працює в екосистемі AWS і надає різні варіанти підключення та інтеграції з іншими сервісами AWS.
Databricks спрямовані на з’єднання (раніше) дуже різних областей:
- Рішення для зберігання неструктурованих, напівструктурованих і структурованих даних в озері даних.
- Рішення для сховища даних зі структурованими та швидкодоступними даними запитів (також називається Delta Lake).
- Рішення для підтримки аналітики та машинного навчання обчислень через озеро даних.
- Управління даними для всіх перерахованих вище областей із централізованим адмініструванням і готовими інструментами для підтримки продуктивності для різних типів розробників і користувачів.
Це звичайна платформа, яку можуть одночасно використовувати інженери даних, розробники SQL і спеціалісти з машинного навчання. Кожна з груп також має набір інструментів, які вони можуть використовувати для виконання своїх завдань.
Отже, Databricks націлені на універсальне рішення, намагаючись поєднати переваги озера даних і сховища даних в одному рішенні. Крім того, він надає інструменти для тестування та запуску моделей машинного навчання безпосередньо на вже створених сховищах даних.
Плюси і мінуси
Переваги, які слід враховувати:
- Databricks — це високомасштабована платформа даних. Він масштабується залежно від розміру робочого навантаження, і робить це навіть автоматично.
- Це середовище для спільної роботи вчених, інженерів даних і бізнес-аналітиків. Мати можливість робити все це в одному просторі та разом є великою перевагою. Не лише з організаційної точки зору, це також допомагає заощадити додаткові кошти, необхідні для окремих середовищ.
- AWS Databricks легко інтегрується з іншими службами AWS, такими як Amazon S3, Amazon Redshift і Amazon EMR. Це дозволяє користувачам легко передавати дані між службами та користуватися всіма перевагами хмарних служб AWS.
Недоліки, які слід враховувати:
- Databricks може бути складним у налаштуванні та управлінні, особливо для користувачів, які не знайомі з обробкою великих даних. Щоб отримати максимальну віддачу від платформи, потрібен значний рівень технічної експертизи.
- Незважаючи на те, що Databricks є економічно ефективним з точки зору моделі ціноутворення «оплата за використання», він все одно може бути дорогим для великомасштабних проектів обробки даних. Вартість використання платформи може швидко зрости, особливо якщо користувачам потрібно збільшити свої ресурси.
- Databricks надає ряд готових інструментів і шаблонів, але це також може бути обмеженням для користувачів, яким потрібні додаткові параметри налаштування. Платформа може не підходити для користувачів, яким потрібна більша гнучкість і контроль над робочими процесами обробки великих даних.
Призначення та використання в реальному світі
AWS Databricks найкраще підходить для великих корпорацій з дуже великим обсягом даних. Тут він може охоплювати вимоги щодо завантаження та контекстуалізації різних джерел даних із різних зовнішніх систем.
Часто вимогою є надання даних у реальному часі. Це означає, що з моменту, коли дані з’являються у вихідній системі, процеси негайно запускаються, обробляють і зберігають дані в Databricks миттєво або з мінімальною затримкою. Якщо затримка перевищує одну хвилину, це вважається обробкою майже в реальному часі. У будь-якому випадку обидва сценарії часто досяжні за допомогою платформи Databricks. Головним чином це пов’язано з великою кількістю адаптерів та інтерфейсів реального часу, які підключаються до різноманітних інших рідних служб AWS.
Databricks також легко інтегрується з системами Informatica ETL. Щоразу, коли система організації вже широко використовує екосистему Informatica, Databricks виглядає як гарне сумісне доповнення до платформи.
Заключні слова
Оскільки обсяг даних продовжує зростати в геометричній прогресії, корисно знати, що існують рішення, які можуть ефективно впоратися з цим. Те, що колись було кошмаром для адміністрування та підтримки, тепер вимагає дуже мало адміністративної роботи. Команда може зосередитися на створенні цінності з даних.
Залежно від ваших потреб, просто виберіть службу, яка може це впоратися. Хоча AWS Databricks — це те, чого вам, ймовірно, доведеться дотримуватися після прийняття рішення, інші альтернативи є досить гнучкими, навіть якщо вони менш спроможні, особливо їх безсерверні режими. Згодом досить легко перейти на інше рішення.