Необхідність Zero-ETL в еру ШІ
Розглянемо приклад: ви опублікували блог на Medium і хочете відслідковувати його доходи в режимі реального часу. Однак поточна система оновлює ці доходи лише раз на 24 години.
Скриншот перегляду доходів на Medium, які оновлюються кожні 24 години
Чому виникає ця затримка? Дані з транзакційних систем, що відстежують активність, пов'язану з блогом (наприклад, перегляди та кліки), спочатку мають бути скопійовані до Data Lake для агрегації та аналізу. Це зазвичай виконується як пакетний процес, коли дані періодично передаються до Data Lake за запланованими інтервалами.
Хоча це досить простий приклад, проблема стає значно більш складною, коли мова йде про зростаючу кількість застосунків штучного інтелекту, які орієнтовані на клієнтів і залежать від даних у реальному часі з Data Lake.
Ці застосунки вимагають скорочення затримки між генеруванням даних у транзакційних системах та їх доступністю для споживання в Data Lake.
Сучасні застосунки все частіше надаватимуть аналітичні дані безпосередньо кінцевим користувачам, і для цього потрібні дані, які є якнайсвіжішими і найточнішими. Чи то відстеження доходів з блогу, надання рекомендацій в реальному часі, чи підтримка інформаційних панелей на основі ШІ, мінімізація затримки при переміщенні даних критично важлива для надання значущих і своєчасних аналітичних висновків.
Концепція Zero-ETL (Extract, Transform, Load) змінює спосіб обробки даних в організаціях. Традиційні ETL конвеєри, хоч і потужні, часто вводять затримку, вимагають складних налаштувань і потребують постійного обслуговування.
Zero-ETL, з іншого боку, має на меті усунути ці проблеми, забезпечуючи безперешкодний рух даних в реальному часі та їх перетворення безпосередньо в інтегрованих системах.
Цей блог досліджує три ключові моделі впровадження Zero-ETL — Пряма синхронізація даних, Архітектури, що керуються подіями, та Вбудоване оброблення даних — висвітлюючи, як кожна з них працює, а також приклади інструментів, які їх реалізують.
Фото Джошуа Сортіно на Unsplash
1. Пряма синхронізація даних
Визначення:
Пряма синхронізація даних означає обмін даними в реальному часі або майже в реальному часі між системами без зберігання їх у проміжних шарах зберігання.
Це зазвичай досягається за допомогою вбудованих інтеграцій, API та механізмів Change Data Capture (CDC), які постійно відстежують і реплікують зміни від джерела до цільових систем.
Як це працює:
- Вбудовані інтеграції: Хмарні екосистеми, такі як AWS, Google Cloud та Azure, забезпечують вбудовану зв'язність між своїми сервісами.
Наприклад, база даних може передавати оновлення безпосередньо в сховище даних. - Механізми CDC: Вони відстежують зміни в базах даних (наприклад, вставки, оновлення, видалення) і передають їх в інші системи в реальному часі.
- API: Інтерфейси програмування додатків дозволяють безпосередньо ділитися даними між інструментами, часто обходячи потребу в проміжних етапах трансформації.
Приклади інструментів:
- Fivetran: Використовує CDC для реплікації змін з операційних баз даних в аналітичні платформи, такі як Snowflake або BigQuery, в реальному часі.
- Debezium: Інструмент з відкритим вихідним кодом, побудований на Kafka, який забезпечує реальний час синхронізації змін у базах даних.
- Інтеграція AWS Aurora з Redshift: Дозволяє безшовну синхронізацію в реальному часі між базами даних Aurora та Redshift без необхідності в ETL.
- Google Cloud BigQuery Data Transfer Service: Забезпечує вбудовані інтеграції для синхронізації даних безпосередньо з сервісів Google (наприклад, Google Ads, Analytics).
Переваги:
- Мінімальна затримка забезпечує доступність актуальних даних для аналізу або оперативного використання.
- Відсутність необхідності в проміжному зберіганні даних знижує складність і вартість.
- Забезпечує консистентність даних у системах в реальному часі.
2.
Архітектури, орієнтовані на події
Опис:
Архітектури, орієнтовані на події, дозволяють системам комунікувати асинхронно шляхом публікації та підписки на події в центральному шину або платформі потокової обробки.
Замість переміщення даних партіями, системи Zero-ETL реагують на окремі зміни даних у реальному часі.
Як це працює:
- Модель публікації-підписки: Джерела систем публікують події (наприклад, оновлення баз даних, події додатків) на центральну платформу потокової обробки.
- Підписники: Інші системи споживають ці події і виконують дії на їх основі, наприклад, оновлюють аналітичні панелі або запускають процеси знизу вгору.
- Центральна шина: Платформи, такі як Apache Kafka або AWS EventBridge, служать центральною шиною для управління та розподілу подій.
Приклади інструментів:
- Apache Kafka: Широко використовується для потокової обробки в реальному часі, Kafka виступає як центральний хаб для подій, підтримуючи Zero-ETL пайплайни для аналітики в реальному часі та оперативних панелей.
- AWS EventBridge: Забезпечує автобуси подій для з'єднання додатків та сервісів, дозволяючи реалізовувати робочі процеси, орієнтовані на події, у реальному часі.
- Google Cloud Pub/Sub: Сервіс обміну повідомленнями для збору та обробки подій у реальному часі серед хмарних систем.
Використання:
- Обробка даних IoT: Збір даних з сенсорів і ініціація дій, таких як сповіщення або автоматичні відповіді.
- Оперативна автоматизація: Публікація бізнес-подій (наприклад, оформлення замовлення) для запуску подальших дій, таких як оновлення запасів або відстеження відправлень.
Переваги:
- Реактивність у реальному часі дозволяє приймати швидші рішення.
- Розділена архітектура забезпечує незалежну роботу систем, покращуючи масштабованість і стійкість.
- Гнучкість у з'єднанні різних систем, підтримка гібридних і мультихмарних середовищ.
3.
Вбудована обробка даних
Визначення:
Вбудована обробка даних передбачає перетворення даних на льоту, часто під час їх збору або безпосередньо в джерелі чи цільовій системі.
Цей підхід усуває необхідність у окремих ETL-пайплайнах, мінімізує затримку та спрощує робочі процеси.
Як це працює:
- Обробка в системі: Трансформації виконуються безпосередньо в джерелі даних.
- Обробка на льоту: Дані трансформуються під час їх перенесення, при зборі в аналітичні або операційні системи.
- Трансформації на основі запитів: Системи використовують інтерфейси, схожі на SQL, для визначення трансформацій, які застосовуються динамічно під час виконання запиту.
Приклади інструментів:
- Snowflake з Snowpipe: Дозволяє здійснювати реальний збір даних і трансформацію безпосередньо в сховищі.
- Databricks Auto Loader: Виконує трансформації під час збору як для пакетних, так і для потокових пайплайнів даних.
- AWS Glue DataBrew: Дозволяє користувачам очищати та трансформувати дані візуально без необхідності окремих інструментів ETL.
- Google BigQuery: Підтримує трансформації на основі запитів за допомогою SQL, дозволяючи динамічну обробку без попереднього етапу трансформації даних.
Використання:
- Потоковий ETL: Трансформування даних журналу в структуровані формати під час збору для реального часу аналітики.
- Збагачення даних: Додавання зовнішнього контексту до зібраних даних, наприклад, додавання геолокаційних даних до записів транзакцій.
- Самообслуговування аналітики: Надання можливості бізнес-користувачам динамічно запитувати трансформовані дані без залучення інженерів.
Переваги:
- Зменшує затримку, усуваючи етапи пакетної трансформації.
- Спрощує обслуговування пайплайнів, консолідуючи обробку в меншу кількість систем.
- Підтримує використання в реальному часі, таке як виявлення аномалій або операційні інсайти.
Підсумок
Zero-ETL означає суттєвий зсув у підходах до інтеграції даних, орієнтуючись на швидкість, простоту та гнучкість.
Це дозволяє застосункам будувати швидші інсайти, знижувати витрати та оптимізувати робочі процеси. Хоча Zero-ETL не замінить традиційний ETL у всіх випадках, зокрема для складних трансформацій даних, його можливості в реальному часі роблять його незамінним для швидко змінюваних потреб даних сучасних AI-додатків. Патерни Zero-ETL стануть дедалі важливішими в сучасних платформах обробки даних.
Перекладено з: Zero-ETL patterns to meet AI data freshness needs