Как передать изменения данных из транзакционной базы в аналитическую без дублей и задержек: CDC-ETL из PostgreSQL в ClickHouse с PeerDB.
CDC для ClickHouse с PeerDB и ClickPipes
Возможности Clickhouse позволяют построить на нем корпоративное хранилище данных целиком или реализовать отдельный слой, например, для денормализованных витрин. Также совместное использование транзакционных и аналитических баз данных обеспечивает получение информации в реальном времени и масштабируемую аналитику. Такая архитектура данных позволяет реализовать паттерн CQRS, разделив рабочие нагрузки на чтение и запись данных, попутно увеличив доступность и масштабируемость приложений. При этом необходимо обеспечить транспорт данных из транзакционных систем в аналитические.
Рассмотрим совместное использование Clickhouse с популярной транзакционной БД PostgreSQL. Довольно популярным подходом к интеграции PostgreSQL с ClickHouse является захват измененных данных – CDC (Change Data Capture), который непрерывно отслеживает вставки, обновления и удаления и передает их, обеспечивая аналитику в реальном времени. Однако, ClickHouse ориентирован на пакетную вставку множества записей за раз, что мы разбирали здесь. Поэтому передавать точечные изменения из транзакционных систем в эту колоночную БД неоптимально. Чтобы обойти это ограничение, для интеграции PostgreSQL с ClickHouse можно использовать следующие способы:
- PeerDB – инструмент репликации с открытым исходным кодом
- ClickPipes – интеграционный движок ClickHouse Cloud с CDC-коннектором.
PeerDB – это ETL/ELT-инструмент, который реализует быстрый, простой и экономически эффективный способ потоковой передачи записей из PostgreSQL в очереди, хранилища и движки хранения данных. PeerDB бесплатен для использования и развертывания. Он лицензирован под Elastic License 2.0 (ELv2).
PeerDB состоит из платформы и коннекторов. Платформа включает основные службы настройки и выполнения операций запроса и перемещения данных, в т.ч. уровень запросов Nexus и компонент передачи данных Flow. Nexus — это реализованная на Rust служба, которая позволяет выполнять SQL-запросы, совместимые с Postgres, по различным источникам и хранилищам данных. Он поддерживает протокол PGWire и может горизонтально масштабироваться для управления высоким спросом. Компонент передачи данных Flow, написанный на Golang, управляет передачей данных между источниками и приемниками. Flow состоит из API и горизонтально масштабируемых рабочих потоков. Коннекторы обозначают различные источники и приемники данных, с которыми может взаимодействовать PeerDB: PostgreSQL, MySQL, Bigquery, Snowflake и Clickhouse.
Для хранения метаданных об операциях PeerDB используется PostgreSQL, а для организации процесса передачи данных внутри компонента Flow – внешняя служба Temporal, механизм временной оркестровки.
PeerDB разработан для синхронизации изменений в реальном времени и реализует несколько оптимизаций, связанных с логической репликацией PostgreSQL, включая параллельное чтение слотов. Это позволяет быстро захватывать измененные данные, обеспечивая высокую пропускную способность более 10 тысяч транзакций в секунду. Для обеспечения надежности поддерживаются механизмы отказоустойчивости: управление состоянием, автоматические повторные попытки, обработка идемпотентности и согласованности. Настраиваемая пакетная обработка и параллелизм предотвращают нехватку памяти (OOM-ошибку, Out Of Memory) и сбои.
PeerDB поддерживает нативные функции PostgreSQL: полный набор типов данных, включая сложные типы (jsonb, arrays, geospatial), эффективную потоковую передачу столбцов больших таблиц TOAST, изменения схемы и пр. PeerDB имеет различные режимы потоковой передачи:
- CDC на основе лога;
- на основе курсора с помощью временной метки или целого числа;
- на основе XMIN.
ClickPipes и PeerDB используют логическое декодирование PostgreSQL для потребления изменений по мере их возникновения в PostgreSQL. Основная идея логического декодирования заключается в потоковой передаче изменений базы данных в формате, понятном другим системам. Логическое декодирование реализуется путем декодирования содержимого журналов WAL и потоковой передачи изменений в настраиваемом формате. Такое декодирование позволяет логической репликации реплицировать изменения как серии мутаций, т.е. операций INSERT, UPDATE и DELETE, в другие гетерогенные системы.
В рамках процесса репликации ClickPipes автоматически создает соответствующие таблицы с наиболее естественным сопоставлением типов данных в ClickHouse и выполняет начальные снимки, а также обратную заливку данных. ClickPipes сопоставляет таблицы PostgreSQL с ClickHouse с помощью табличного движка ReplacingMergeTree, который отличается от MergeTree характером дедубликации. ReplacingMergeTree удаляет повторяющиеся записи с одинаковым значением ключа сортировки по столбцу с оператором ORDER BY, а не PRIMARY KEY. Дедупликация данных происходит только во время слияния, которое происходит в фоновом режиме в неизвестное время. Это экономит место, но не гарантирует отсутствия дубликатов. Подробнее об этом мы писали здесь. Поскольку ClickHouse лучше всего работает с рабочими нагрузками только для добавления и не очень подходит для частых обновлений, для репликации изменений из PostgreSQL используется именно ReplacingMergeTree.
Как оптимизировать CDC-передачу данных из PostgreSQL в ClickHouse с помощью PeerDB, рассмотрим в следующей статье.
Освойте ClickHouse на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
