Table of Contents

За последнее десятилетие организации, создающие и управляющие своими платформами данных, претерпели сейсмический сдвиг. Центральным элементом этой трансформации является принятие Event Driven Architecture (EDA), парадигмы проектирования программного обеспечения, которая коренным образом меняет то, как данные перемещаются между системами. При применении к интеграции Data Lakes и Data Warehouses EDA открывает возможности, которые ранее было трудно или невозможно достичь с помощью традиционных пакетно-ориентированных подходов. В этой статье рассматривается, как EDA меняет структуру озера данных и интеграцию хранилища данных, обеспечивая понимание в режиме реального времени, улучшенную масштабируемость и большую операционную гибкость.

Понимание озер данных и складов данных

Прежде чем погрузиться в влияние EDA, важно оценить различные роли, которые Data Lakes и Data Warehouses играют в современном стеке данных.

Озера данных

Data Lake — централизованное хранилище, предназначенное для хранения огромных количеств сырых, необработанных данных в родном формате. Сюда входят структурированные данные транзакционных систем, полуструктурированные данные, такие как журналы и файлы JSON, и неструктурированные данные, такие как изображения и видео. Data Lakes предлагают огромную гибкость с помощью подхода «схема на чтение», то есть структура применяется только тогда, когда данные запрашиваются. Это делает их идеальными для поисковой аналитики, машинного обучения и рабочих нагрузок в области науки о данных, где схема не известна заранее. Популярные технологии Data Lake включают Amazon S3, Azure Data Lake Storage и Apache Hadoop.

Хранилища данных

Склад данных, напротив, хранит обработанные, структурированные и очищенные данные, оптимизированные для бизнес-аналитики (BI) и отчетности. Склады данных используют подход схемы на записи, где данные трансформируются и организуются в размерные модели (например, звездные схемы) перед загрузкой. Это обеспечивает высокую производительность запросов и согласованность данных, что делает их системой для оперативной отчетности и приборных панелей. Ведущие решения включают Snowflake, Amazon Redshift, Google BigQuery и Azure Synapse.

Традиционно организации поддерживали эти две системы в виде отдельных бункеров, при этом пакетные трубопроводы ETL/ELT перемещали данные между собой, однако растущая потребность в аналитике в реальном времени и растущая скорость обработки данных обнажили ограничения пакетной обработки, что привело к росту событийных архитектур.

Что такое событийно-управляемая архитектура?

Event Driven Architecture - это шаблон проектирования программного обеспечения, в котором компоненты общаются путем производства и потребления событий - уведомлений о том, что произошло что-то интересное. Событие обычно содержит полезную нагрузку, описывающую изменение и метаданные, такие как временная метка и уникальный идентификатор. События публикуются брокеру событий (или шине событий), который отделяет производителей от потребителей, позволяя системам реагировать асинхронно.

Ключевые компоненты EDA

  • Производители событий: Услуги или приложения, обнаруживающие изменение состояния и публикующие событие. Например, инструмент сбора данных об изменениях (CDC), публикующий изменения строк баз данных.
  • Брокер событий: Промежуточное ПО, которое получает, хранит и направляет события заинтересованным потребителям.Популярные брокеры включают Apache Kafka, Amazon Kinesis и RabbitMQ.
  • Потребители событий: Услуги или процессы, которые подписываются на конкретные типы событий и действуют на них, такие как обновление хранилища данных или запуск конвейера данных.

EDA способствует свободному взаимодействию, то есть производители и потребители могут развиваться независимо. Эта архитектура превосходит сценарии, требующие обработки в реальном времени, высокой масштабируемости и способности обрабатывать различные источники данных.

Переход от пакетной к событийной интеграции данных

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

Интеграция данных, управляемая событиями, заменяет или увеличивает циклы пакетов непрерывными, постепенными потоками данных. Когда в системе источника происходит изменение (например, новый порядок размещается или пользователь обновляет свой профиль), событие публикуется и сразу же попадает в озеро данных. Потребители нисходящего потока, такие как хранилище данных, могут затем реагировать на событие для обновления материализованных просмотров или агрегированных таблиц в режиме реального времени. Этот сдвиг уменьшает задержку данных от часов до секунд.

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

Влияние EDA на интеграцию с озерами данных

Озеро данных, как хранилище необработанных данных, является естественным первым бенефициаром проглатывания, управляемого событиями.

Потребление данных в реальном времени

С EDA данные могут поступать в озеро данных непрерывно по мере возникновения событий. Вместо ожидания ночного пакетного окна новые данные доступны для запроса в течение нескольких секунд. Это важно для таких случаев использования, как мониторинг датчиков IoT, анализ потоков кликов и двигатели персонализации в реальном времени. Такие инструменты, как Apache Kafka Connect и Amazon Kinesis Firehose, позволяют передавать прямые события в озеро данных, сохраняя события в таких форматах, как Parquet или Avro для эффективного запроса.

Гибкость схемы чтения

Схемы событий могут развиваться, не нарушая Озеро данных. Поскольку Озеро данных хранит сырые события, потребители могут применять различные схемы или преобразования по мере необходимости. Это идеально согласуется с свободной связью EDA - производитель может изменить свою схему событий (после наилучших практик версионного анализа), а потребители могут адаптироваться независимо. Реестры схем (например, Реестр сменных схем) помогают управлять совместимостью и предотвращать немую коррупцию.

Поддержка Event Sourcing и Data Mesh

EDA позволяет создавать модели поиска событий, где Data Lake становится системой записи всех изменений состояния. За счет хранения каждого события организации могут восстанавливать текущее состояние в любой момент времени или запускать историческую аналитику. Кроме того, EDA облегчает архитектуру ячеек данных, позволяя командам доменов публиковать свои данные в качестве событий, которые другие команды могут потреблять через брокера событий. Это способствует децентрализованному владению и улучшает возможность обнаружения данных.

Влияние EDA на интеграцию хранилища данных

Склады данных традиционно обновляются с помощью пакетных рабочих мест ETL. EDA трансформирует это, позволяя проводить дополнительные обновления в режиме реального времени, не жертвуя производительностью и согласованностью, которые требуют склады.

Изменение сбора данных и потоковых обновлений

Инструменты Change Data Capture (CDC) могут фиксировать изменения базы данных (вставки, обновления, удаления) в качестве событий и публиковать их брокеру. Затем потребители склада применяют эти изменения к соответствующим таблицам с использованием операций слияния или повышения производительности. Это позволяет складу непрерывно синхронизироваться с транзакционными системами, поддерживая дотошную отчетность. Например, розничная компания может отслеживать уровни запасов в режиме реального времени с использованием событий CDC, перетекающих из операционной базы данных на склад Snowflake.

Материализованные взгляды Incremental

Современные складские платформы поддерживают материализованные виды, которые можно обновлять постепенно. Когда событие указывает на изменение базовых данных, склад может пересчитать только затронутые разделы. EDA может автоматически запускать эти обновления, снижая затраты на вычисления и время обновления по сравнению с полными перестройками. Эта модель особенно мощна в сочетании с потоковым проникновением в озеро данных, где склад считывает из таблиц, полученных из событий.

Последовательность данных и порядок

Поддержание согласованности в складе, ориентированном на события, является сложной задачей, поскольку события могут выходить из строя или дублироваться. Для решения этой проблемы склады должны правильно реализовать логику идемпотентного обновления и использовать метаданные событий (например, временные метки или порядковые номера) для изменения заказа. Многие платформы теперь поддерживают транзакционные гарантии при обработке потоков событий, позволяя складам поддерживать сильную согласованность, извлекая выгоду из обновлений с низкой задержкой.

Унифицированная архитектура данных с EDA: модель Lakehouse

Конвергенция Data Lakes и Data Warehouses в архитектуру Lakehouse ускоряется за счет интеграции, основанной на событиях. Lakehouse использует Data Lake в качестве единого слоя хранения и добавляет складские функции — транзакции ACID, SQL-запросы и принудительное исполнение схемы. EDA обеспечивает соединительную ткань, которая позволяет поток данных в реальном времени в Lakehouse.

В озерном домике события текут прямо в стол Дельта-Лейк или Айсберг, где они сразу доступны как для BI, так и для рабочих нагрузок машинного обучения. Материализованные виды или обслуживающие слои могут обновляться с помощью функций, спровоцированных событиями. Это устраняет необходимость в отдельных системах и уменьшает движение данных, что приводит к снижению затрат и более простой архитектуре. Такие платформы, как Databricks и Apache Flink, глубоко интегрируются с брокерами событий, чтобы включить семантику ровно один раз в средах озерного дома.

Проблемы и соображения

Хотя преимущества ЭДА для интеграции данных и складов значительны, организации должны преодолеть несколько проблем для достижения успеха.

Заказ событий и время жить

События могут выходить из строя из-за задержек в сети или стратегий разделения. Без надлежащего заказа данные склада могут стать непоследовательными. Решения включают использование разделов событий, закодированных бизнес-идентификатором, использование времени события (не время обработки) для заказа и использование устойчивых к задержкам структур данных, таких как регистрационные журналы. Кроме того, события могут быть неограниченно сохранены у брокеров, что приводит к затратам на хранение. Внедрение политики удержания и уплотнения имеет важное значение.

Ровно однажды семантика

Поставка по крайней мере один раз является обычным явлением в брокерах событий, что означает, что потребители могут видеть дублирующие события. Склады данных требуют точно один раз семантики, чтобы избежать двойного подсчета в метриках. Это может быть достигнуто путем создания у потребителей идемпотента - с использованием ключей дедупликации (например, идентификатор события) и выполнения восходящих сигналов - или путем использования транзакционных раковин, которые поддерживают точно один раз обработку, такую как семантика Кафки точно один раз в сочетании с совместимым разъемом раковины.

Качество данных и управление схемами

Схемы событий часто меняются с течением времени по мере развития требований бизнеса. Без управления потребители могут нарушать. Лучшие практики включают использование реестра схем с проверками совместимости, редактирование событий и реализацию политики эволюции схем (например, обратная совместимость, прямая совместимость). Проверки качества данных должны применяться как у производителя событий (для раннего выявления проблем), так и у потребителя (для фильтрации или карантина искаженных событий).

Оперативная сложность и мониторинг

Платформа данных, управляемая событиями, включает в себя множество движущихся частей: производителей, брокеров, потоковых процессоров и потребителей. Мониторинг задержки, пропускной способности и частоты ошибок по всему трубопроводу является сложной задачей. Организации должны инвестировать в инструменты наблюдения, которые отслеживают линию событий, предупреждают о обратном давлении и обеспечивают сквозные панели задержки. Управление государственной обработкой потоков (например, в Kafka Streams или Flink) требует специальных навыков и тщательного предоставления ресурсов.

Лучшие практики внедрения EDA в платформы данных

Чтобы максимизировать преимущества интеграции, основанной на событиях, и минимизировать риск, следуйте этим проверенным шаблонам.

Начните с сбора данных об изменениях

CDC является точкой входа с низким коэффициентом трения для EDA. Путем потоковой передачи изменений базы данных из транзакционных систем вы можете немедленно вносить данные в реальном времени в свое Data Lake и Warehouse без изменения исходных приложений. Используйте зрелые инструменты CDC, такие как Debezium или AWS DMS, которые интегрируются с Kafka и популярными хранилищами данных.

Выберите правильного брокера событий

Apache Kafka является стандартом де-факто для высокопроизводительной, устойчивой потоковой передачи событий. Для более простых вариантов использования или облачных сред рассмотрите Amazon Kinesis, Google Pub/Sub или Azure Event Hubs. Оцените такие факторы, как масштабируемость, требования к задержке, интеграция с существующими инструментами и эксплуатационные накладные расходы.

Охватывает недееспособных потребителей

Создайте так, чтобы все потребители могли изящно обрабатывать дубликаты событий. Используйте комбинацию операций UPSERT и логики дедупликации. В складах на базе SQL, используйте MERGE-заявления с идентификаторами событий. В средах озера данных используйте идемпотентность на уровне файлов (например, запись в уникальные пути файлов) или журналы транзакций.

Осуществление управления схемой

Принять реестр схем (например, Confluent, AWS Glue Schema Registry) для обеспечения соблюдения правил совместимости между производством и потреблением приложений. Автоматическая проверка схемы в рамках вашего конвейера CI / CD, чтобы предотвратить прорыв изменений от достижения производства.

Мониторинг конечной задержки

Настройка показателей задержки производства событий, времени доставки брокера и времени обработки потребителей. Цель - цикл обратной связи, в котором задержка увеличивает триггерные сигналы и автоматическое масштабирование. Используйте распределенное отслеживание (например, OpenTelemetry) для отладки узких мест в сложных трубопроводах.

Роль гибких платформ данных в мире, управляемом событиями

По мере того, как организации принимают EDA для интеграции данных, платформы, которые подключаются к этим потокам событий, становятся критическими. Гибкая платформа данных, такая как Directus, действует как потребитель событий, так и производитель, обеспечивая бесшовную связь между брокерами событий, базами данных и аналитическими системами. Directus может публиковать веб-хуки или слушать внешние потоки событий для обновления своей базовой базы данных в режиме реального времени. Это делает его отличным инструментом для создания панелей мониторинга в реальном времени, бэкэндов управления контентом или операционных приложений, которые полагаются на последние данные из Data Lakes и Warehouses.

Разоблачая унифицированный API поверх разнородных источников данных, Directus снижает сложность интеграции инструментов EDA с бизнес-логикой. Команды могут сосредоточиться на извлечении ценности из событий, а не на написании пользовательского кода клея для каждого типа событий.

Заключение

Архитектура событий коренным образом меняет то, как интегрированы и управляются Data Lakes и Data Warehouses. Перейдя от пакетных к реальным, событийным шаблонам, организации достигают меньшей задержки, большей масштабируемости и более отзывчивых систем данных. Data Lakes становятся непрерывными потоками сырых событий, в то время как Data Warehouses получают дополнительные обновления, которые сохраняют панели инструментов BI свежими. Модель Lakehouse, включенная EDA, объединяет эти два мира в единую, сплоченную платформу.

Однако успех требует тщательного внимания к порядку проведения мероприятий, согласованности данных, управлению схемами и оперативному мониторингу. При правильной архитектуре и инструментарии, включая CDC, реестры схем, идемпотентных потребителей и гибкие платформы, такие как Directus, организации могут использовать всю мощь интеграции данных, ориентированной на события. По мере роста объемов данных и ускорения бизнес-требований EDA больше не является роскошью, а необходимостью для конкурентного преимущества.

Внешние ссылки: