CDC с Kestra вместо Debezium с Kafka Connect

инженер данных примеры курсы обучение Debezium CDC Kestra, курсы Apache Kafka Интеграция, курсы по Кафка, обучение Кафка, курсы Kafka Connect, курсы KSQL, Kafka Connect и KSQL, обучение Kafka Connect, обучение KSQL, обучение Big Data для разработчиков, Kafka Streams курсы, Apache Kafka Для разработчиков обучение курсы, учебный центр Коммерсант Школа Больших Данных, курсы Big Data в Москве

Как реализовать CDC-сценарий, используя платформу оркестрации Kestra вместо Debezium с Kafka Connect для планирования и управления конвейером обработки данных. За счет чего Kestra работает эффективнее Debezium с коннекторами Kafka Connect и при чем здесь Apache AirFlow с NiFi.

Что не так с реализацией CDC на Debezium с Kafka Connect

Мы уже писали о том, как можно реализовать CDC-паттерн (Change Data Capture) захвата измененных данных в реальном времени с платформой Debezium. CDC — это процесс выявления и регистрации изменений, внесенных в данные в базе данных, а затем доставки этих изменений в режиме реального времени в нижестоящий процесс или систему. Debezium включает набор распределенных сервисов, которые фиксируют изменения на уровне строк в одной или нескольких базах данных, чтобы их видели подключенные приложения и могли реагировать на них в режиме реального времени. Все изменения на уровне строк записываются в журнал транзакций, и каждое приложение просто читает соответствующие логи.

Debezium обеспечивает строго однократную доставку (exactly once) всех изменений и следит за тем, чтобы изменения поступали в том порядке, в котором они были отправлены. Для потоковых рабочих нагрузок необходим постоянный мониторинг источников, поэтому коннекторы для Debezium должны работать непрерывно. Для такого постоянного соединения Debezium использует Kafka Connect – часть платформы Apache Kafka от Confluent, фиксируя изменения данных всякий раз, когда они происходят. Даже в самом простом развертывании Debezium в любой момент времени работает как минимум два коннектора Kafka Connect. Один извлекает данные из восходящего источника, а второй отправляет изменения данных в места назначения. Эти коннекторы работают непрерывно, с постоянной пропускной способностью, с выделенной обработкой и мощностью памяти, чтобы гарантировать, что данные принимаются и доставляются как можно ближе к моменту. Для каждого изменения на уровне строки Debezium создает соответствующее событие, полностью описывающее эти изменения. Со временем эти события могут стать довольно большими и занимать много ресурсов. Каждый процесс, использующий события Debezium, потребляет установленное минимальное количество ресурсов, независимо от трафика. Это может потреблять значительную часть полосы пропускания, а также ресурсы (ЦП, память) для обработки событий, проходящих через конвейер.

Хотя Debezium предлагает очевидные преимущества для CDC-сценариев в реальном времени, он может быть неэффективным, если потребление ресурсов становится слишком высоким. В зависимости от сложности развертывания количество необходимых коннекторов Kafka Connect может привести к истощению системных ресурсов. На практике часто бывает, что даже в сложном развертывании много источников обычно генерируют не очень много трафика, а несколько строк в час. Для такого источника не имеет особого смысла иметь постоянный, всегда активный процесс, потребляющий много системных ресурсов.

А если включены контрольные списки доступа к данным (ACL, Access Control List), поддерживающие детальное управление доступом на основе ролей, количество коннекторов Kafka Connect, может увеличиться, чтобы реализовать сложные RBAC-политики. При этом коннекторы конкурируют за одни и те же системные ресурсы. Все это сильно снижает производительность Debezium в сценариях потоковой передачи больших объемов данных. Поэтому имеет смысл рассмотреть альтернативные варианты, особенно, если нет строгих требований к мониторингу изменений в реальном времени. Одним из таких инструментов является open-source платформа оркестрации Kestra, которую мы рассмотрим далее.

Kestra и микропакетная обработка

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

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

Примечательно, что Kestra была разработана как попытка улучшить популярный среди дата-инженеров ETL-оркестратор и планировщик Apache AirFlow, который довольно зрелый, но имеет ряд недостатков, о которых мы упоминали здесь и здесь.

Kestra может получать события CDC напрямую без сервисов Kafka Connect, используя движок Debezium, и перенаправлять их в любое поддерживаемое место назначения (BigQuery, JDBC, облачное хранилище и пр.), без конвейера потоковой передачи. Периодичность можно запланировать на любой интервал или использовать триггеры для создания событий выполнения каждый раз, когда появились доступны данные. Kestra также применяется для преобразования данных перед их отправкой в пункт назначения.

При использовании Kestra для рабочих нагрузок CDC, близких к реальному времени или в пакетном режиме, и Debezium для потоковой передачи можно тратить только ресурсы, необходимые для рассматриваемого сценария вместо того, чтобы применять ресурсоемкие потоковые ресурсы к каждому процессу. Для рабочих процессов, которые не работают в режиме реального времени, ресурсы ЦП и памяти ограничены или отключаются, когда они не используются. Это очень удобно для сервисов, которые взимают плату в зависимости от пропускной способности. Например BigQuery и многие сервисы AWS оплачиваются только во время использования. Таким образом, можно сэкономить деньги, продолжая надежно фиксировать все изменения на уровне строк и делать моментальные снимки базы данных при первом запуске Debezium с помощью встроенной функции этой платформы.

Наконец, конвейеры обработки данных с Kestra становятся более наглядными, а значит, лучше управляются. Благодаря непрерывному мониторингу зависимостей, дата-инженер может точно увидеть, где именно в конвейере данных случилась проблема. Эта возможность мониторинга обеспечивает большую уверенность при управлении различными требованиями к потокам данных и снижает сложность кластерных развертываний Kafka с Debezium.

Кроме того, Kestra позволяет итеративно вносить изменения в конвейеры данных «на лету» с помощью нескольких строк YAML-кода, добавляя новые компоненты и интеграции, не нарушая рабочий процесс. Новый конвейер данных можно применить за считанные минуты. А благодаря многочисленным плагинам Kestra реализует глубокую интеграцию с множеством систем. Системы без существующих плагинов можно интегрировать с простыми инструментами контейнеризации, такими как Docker и Kubernetes.

В заключение отметим, что Kestra, хотя и позиционируется как оркестратор и планировщик ETL-конвейеров в режиме почти реального времени, эта платформа не является заменой Apache NiFi, который позволяет маршрутизировать потоки данных, что мы рассматривали вчера.

Освойте технологии работы с дата-конвейерами для систем аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://kestra.io/blog/2022-04-05-debezium-without-kafka-connect.html
  2. https://kestra.io/docs/
Поиск по сайту