Чтобы продемонстрировать, почему Debezium и Delta Lake составляют интересную комбинацию, особенно для случаев использования, связанных с приложениями микросервисов и большими данными, я расскажу историю, с которой я недавно столкнулся.

Пример использования клиента

Один из наших клиентов рассказал мне такую ​​историю:

  • Компания делает приложение для микросервисов
  • Каждый из их клиентов запускает собственный экземпляр приложения вместе с собственными базами данных.
  • Они хотят фиксировать изменения данных во всех экземплярах приложений - всех своих клиентов - для обновления центрального озера данных, в котором хранится репликация последнего состояния базы данных.
  • Затем они хотят использовать это озеро данных для агрегирования и аналитики.

В чем проблема?

Наивное решение, которое они предприняли, состоит в том, чтобы поддерживать столбец временной метки last_updated и периодически извлекать все изменения с момента последней извлеченной метки времени.
Этот подход имеет несколько недостатков:

  • Когда разработчики не обновляют столбец last_updated - изменения не поступают
  • Процесс извлечения не является отказоустойчивым - например, при сетевой ошибке он не знает, продолжить с того места, где он остановился.
  • Аппликативные накладные расходы - они должны поддерживать дополнительный код поверх ядра приложения, чтобы управлять этой задачей.

Что такое Дебезиум?

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

Чем нам может помочь Дебезиум?

Поскольку Debezium читает журналы базы данных:

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

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

Как выглядит продукция Debezium?

Сообщение в формате json с описанием измененных данных
Некоторые интересные поля:

  • ”op”: код операции (c - создать, u - обновить, d - удалить, r - первое чтение).
  • ”before”: строка перед изменением.
  • ”after”: строка после изменения.
  • ”источник”: содержит полезную информацию о сервере, базе данных и таблице, из которых произошло изменение.

Ключевой вопрос - как преобразовать вывод Debezium в содержательную таблицу в контексте Data Lake?

Если бы только мы могли выполнить эти изменения в нашей таблице Data Lake, мы бы получили желаемый результат - реплицированное состояние всех исходных баз данных.

Вот где в игру вступает Дельта-Лейк. Раньше было сложно надежно выполнять операции UPSERTS и DELETES для таблиц озера данных, однако Delta Lake, наряду с другими преимуществами, позволяет это сделать. Вы можете прочитать больше об этом здесь"

Обзор стратегии высокого уровня

  • Debezium читает журналы базы данных, создает сообщения json, описывающие изменения, и передает их в Kafka.
  • Kafka передает сообщения в потоковом режиме и сохраняет их в папке S3. Мы называем это бронзовой таблицей, так как в ней хранятся необработанные сообщения.
  • Используя Spark с Delta Lake, мы преобразуем сообщения в операции INSERT, UPDATE и DELETE и запускаем их в таблице целевого озера данных. Это таблица, в которой хранится последнее состояние всех исходных баз данных. Мы называем это Серебряный стол
  • Затем мы можем выполнить дальнейшее агрегирование таблицы Silver для аналитики. Мы называем это Золотым столом

Пример проекта сквозного трубопровода

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

Вы можете найти код вместе с дополнительной информацией в нашем репозитории GitHub.

Ограничения

Перед использованием Debezium и Delta Lake примите во внимание следующие ограничения и открытые вопросы:

  • Соединения представлений / таблиц:
    В Debezium такого понятия нет. Он знает, как фиксировать изменения в отдельных таблицах, но вы не можете сказать ему «если эта таблица изменится - захватите все объединенное представление» без дополнительных усилий с вашей стороны.
  • Продолжение потоковой передачи:
    Поддержка потоковой передачи в Delta Lake ограничена микропакетными потоками. Поскольку он работает с файлами, он не поддерживает непрерывные потоки в реальном времени.

Резюме

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

Спасибо за прочтение!

Контактная информация:
[email protected]