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

Меня зовут Андрей Капустин. Я менеджер продукта Tarantool CDC в компании VK Tech. В этой статье я расскажу о Tarantool CDC и о том, как инструмент помогает консолидировать данные из разрозненных хранилищ, в том числе проприетарных СУБД, обеспечивая прозрачность, высокую консистентность и скорость.

Об актуальности задачи

С ростом цифровизации и требований к ИТ-системам бизнес разных направлений стремится получить возможность анализировать данные и принимать решения с минимальными задержками, а иногда практически мгновенно. Так, бизнес-задачи, подразумевающие работу с данными, поступающими в Real-time, можно выделить в разных отраслях:

• финтех: получение актуального профиля клиента, контроль транзакций и счетов;

• ритейл: контроль остатков, дедупликация, партионный учет;

• телеком: биллинг, Real-time marketing, омниканальность;

• госсектор: аналитическая отчетность, работа с реестрами;

• производство: IIoT, цифровые двойники, сбор данных для целей ML/AI;

• интернет: сервисы авторизации, сайты-агрегаторы, Data Transfer (облака).

Но чтобы обеспечить возможность реализации подобных сценариев, нужен механизм, способный собрать данные со всех источников, а затем перенести в целевое хранилище без задержек, потерь и повреждений. 

Таким механизмом являются решения CDC. Tarantool CDC — одно из них.

Tarantool CDC: место в экосистеме и эволюция

Tarantool объединяет экосистему продуктов для хранения данных разных типов и работы с ними. Ядром платформы является Tarantool Enterprise Edition — версия Tarantool, ориентированная на крупных клиентов, желающих построить нестандартные решения. 

На основе Tarantool Enterprise Edition построена целая линейка продуктов, среди которых:

• Tarantool DB — российская NoSQL in-memory СУБД;

• Tarantool Graph DB — графово-векторная база данных;

• Tarantool Queue Enterprise — распределенная in‑memory-система очередей сообщений;

• Tarantool Column Store — in-memory колоночная СУБД для транзакционно-аналитической обработки данных в реальном времени. 

Особое место в экосистеме занимает Tarantool CDC — решение для Real-time-репликации данных на основе потока событий БД-источника. 

На нем остановимся подробнее.

Эволюция Tarantool CDC

На этапе появления первых версий Tarantool CDC (v1) инструмент предоставлял пользователям только основной функционал, но не мог предложить достаточный набор интеграций и коннекторов. Из-за этого, чтобы обеспечить возможность применять Tarantool CDC в нужных кейсах и существующих клиентских системах, мы были вынуждены разрабатывать коннекторы под заказ. Например:

• Sink в ClickHouse;

• Sink в ElasticSearch;

• Source из Oracle (через Golden Gate).

И таких реализаций были десятки. Причем многие из них по разным причинам даже не доходили до прода. 

По мере развития Tarantool CDC (v2) стало очевидно, что создание коннекторов под заказ — путь, напоминающий «придумывание велосипеда». Поэтому мы решили пойти дальше и добавили Tarantool в готовую экосистему, в качестве которой выбрали Debezium — проверенный популярный продукт с большим набором Source- и Sink-коннекторов. 

Чтобы сделать Tarantool CDC частью экосистемы Debezium, нам фактически требовалось только разработать Source- и Sink-коннекторы для Tarantool.

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

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

В результате мы пришли к Tarantool CDC версии 9, в которой:

• сохранились все преимущества CDC v2;

• в качестве буфера используется Tarantool Queue Enterprise;

• есть поддержка Kubernetes;

• обеспечена совместимость с экосистемой Debezium;

• есть собственные коннекторы на Java, Go;

• поддерживаются механизмы масштабирования и отказоустойчивости Tarantool;

• есть возможность работы на отечественных операционных системах: Astra Linux, «РедОС», ALT Linux;

• есть экспорт метрик мониторинга в Prometheus и Grafana.

Сценарии использования Tarantool CDC

Tarantool CDC — инструмент Near Real-time-репликации данных, который может работать в нескольких режимах. Выделю основные:

• синхронизация данных из Tarantool в другие СУБД;

• наполнение кэш-витрин в Tarantool из мастер-базы;

• двусторонняя синхронизация Tarantool — PostgreSQL;

• миграция данных из проприетарных СУБД Oracle без Golden Gate.

Примечание: Помимо этого, Tarantool CDC можно применять в сценариях, когда Tarantool не используется как хранилище данных.

Чтобы понять, насколько просто Tarantool CDC справляется с подобными задачами, достаточно рассмотреть принцип CDC из Oracle в Tarantool DB. Все сводится к простому алгоритму:

1. Экстрактор OpenLogReplicator (OLR) отслеживает изменения таблиц Oracle, производя разбор журнала логов: Online Redo Log Files и Archive Redo Log Files.

2. Source Oracle Connector получает CDC-поток из OLR по сети.

3. Source Oracle Connector отправляет данные в распределенный брокер сообщений Tarantool Queue Enterprise.

4. Очередь Tarantool Queue Enterprise передает сообщения в Sink Tarantool Connector, который записывает данные в Tarantool DB.

Теперь немного о репликации.

Обобщенно репликация данных при работе с Tarantool CDC строится по схожему принципу:

1. Source Connector отслеживает изменения таблиц в БД-источнике.

2. Source Connector отправляет данные в Tarantool Queue Enterprise.

3. Очередь отправляет данные в Sink Connector, который на нее подписан (возможно, Broadcast).

4. Sink Connector записывает данные в БД-приемник.

Причем в качестве Source Connector и Sink Connector может быть практически любая СУБД из-за совместимости с экосистемой Debezium: Tarantool CDC может справиться и с такими задачами.

Архитектура Tarantool CDC v9

Tarantool CDC v9 имеет расширенную совместимость. Так, в качестве источников данных инструмент может взаимодействовать:

• с PostgreSQL;

• с Oracle (XStreams/OpenLogReplicator);

• с Tarantool Enterprise 2.x/3.x;

• с Tarantool DB 1.x/2.x;

• с Tarantool Data Grid 2;

• с MS SQL (в планах).

Для сбора данных Tarantool CDC читает логи или подписывается на репликационный поток. 

В качестве получателей данных могут выступать:

• Tarantool Enterprise 2.x/3.x;

• Tarantool DB 1.x/2.x;

• ODBC/JDBC: PostgreSQL, MS SQL, DB2, MySQL, Oracle и другие;

• Elasticsearch;

• ClickHouse;

• GreenPlum (в планах).

Ядром архитектуры самого Tarantool CDC является Tarantool Queue Enterprise. Очередь взаимодействует с подсистемой чтения, которая включает несколько исполнителей (например, Исполнитель 1-1, Исполнитель 1-2) с собственными коннекторами источников для взаимодействия с разными базами данных. 

С другой стороны, Tarantool Queue Enterprise также взаимодействует с подсистемой записи, которая включает задачи с загрузчиками, работающими с различными БД-получателями. 

Таким образом, транспорт данных осуществляется по следующему принципу:

1. В БД-источник поступают новые данные.

2. Исполнители с коннекторами подключаются к БД-источнику, забирают данные и трансформируют их во внутренний формат CDC.

3. В формате CDC данные передаются в очередь.

4. Из очереди данные получают загрузчики, которые преобразовывают данные в формат целевой системы.

5. Данные в формате целевой системы передаются в БД-получатель. 

При этом Tarantool CDC функционирует на базе Kubernetes и умеет работать с внешним реестром схем, поэтому в архитектуре решения также есть соответствующие модули:

• оркестратор;

• внешний реестр схем.

При этом архитектуру можно гибко масштабировать.

Для примера: если нагрузка небольшая, то можно использовать общую очередь в Tarantool Queue Enterprise, чтобы собрать данные с двух СУБД-источников и положить их в целевую СУБД-получатель.

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

От теории к практике

Теперь сделаем краткий обзор возможностей Tarantool CDC при решении реальной прикладной задачи. 

Например, в качестве условий задачи примем, что:

• БД-источник — Oracle;

• первый БД-получатель — Tarantool DB;

• данные из Tarantool DB нужно сразу отдавать в PostgreSQL.

Полная схема в таком случае будет иметь следующий вид:

1. Первоначальный источник информации — Oracle.

2. WAL-логи из Oracle читает OpenLogReplicator.

3. Далее Sink-коннектор Oracle забирает данные из OpenLogReplicator и передает их в очередь Tarantool Queue Enterprise.

4. Sink-коннектор Tarantool забирает данные из Tarantool Queue Enterprise и отдает в Tarantool DB.

5. Source-коннектор Tarantool забирает данные из Tarantool DB и снова передает их в Tarantool Queue Enterprise.

6. Из Tarantool Queue Enterprise данные забирает Sink-коннектор PostgreSQL и отдает их в БД-получатель PostgreSQL.

То есть схема простая и фактически состоит из двух цепочек: 

• из Oracle в Tarantool DB;

• из Tarantool DB в PostgreSQL.

При старте загрузки данных в Oracle данные начнут автоматически переливаться в Tarantool DB и PostgreSQL. Всю динамику, показатели загрузки данных и подробную информацию по этим процессам можно отслеживать также Grafana + Prometheus в формате наглядных графиков и дашбордов. 

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

Таким образом, Tarantool CDC может выполнять задачи некого all-in-one-комбайна, который и предоставляет нужные коннекторы, и переливает данные, и обеспечивает консистентность данных, и позволяет отслеживать все процессы. 

Выводы и планы

Инструменты класса Change Data Capture — наиболее эффективное решение для прокачки данных между хранилищами, даже если речь идет о системах, где данные обновляются в режиме реального времени. Фактически CDC значительно упрощают подобные задачи и помогают обходить подводные камни. 

Но среди CDC нет серебряной пули — у каждого инструмента свой набор интеграций, возможностей, преимуществ. Например, к достоинствам Tarantool CDC можно отнести:

• высокую производительность за счет использования in-memory-технологии;

• совместимость с экосистемой Debezium, готовые коннекторы;

• отказоустойчивость и масштабирование за счет очереди Tarantool Queue Enterprise под капотом;

• собственные коннекторы на разных языках Go, Java: Source для Tarantool Enterprise Edition, Tarantool Data Grid 2, Tarantool DB, ClickHouse, PostgreSQL;

• Real-time-репликацию из проприетарных СУБД (например, Oracle);

При этом мы не останавливаемся на достигнутом и продолжаем активно развивать продукт. Так, в перспективе будут проработаны:

• Advanced Observability (мониторинг, алертинг, логирование);

• интеграция CDC v9 в VK Data Platform;

• Sink-коннектор для GreenPlum;

• Source-коннектор для YDB, SAP HANA (в рамках проверки гипотезы);

• трансформации данных при репликации (в рамках проверки гипотезы).

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

А пока рассказывайте в комментариях о своем опыте консолидации данных из разрозненных хранилищ.

Вступайте в чат сообщества Tarantool и подписывайтесь на наш канал в Telegram.