Часто в распределенных ИТ-ландшафтах компании используют несколько хранилищ данных под разные задачи. Это делает их важным компонентом любой системы Change Data Capture (CDC) — они помогают отслеживать изменения данных и связывать используемые хранилища. Но далеко не все CDC-инструменты способны ответить на актуальные запросы бизнеса.
Меня зовут Евгений Афанасьев. Я архитектор VK Tech в команде Tarantool. В этой статье я расскажу о том, с какими вызовами сталкиваются современные компании при работе с данными и как на них помогает отвечать Tarantool CDC.
Вызовы, стоящие перед компаниями, и варианты ответа на них
С ростом сложности задач, которые бизнес ставит перед своими ИТ-системами, компании вынуждены строить все более производительный и масштабный ИТ-ландшафт. Но под разные задачи часто используются разные инструменты, а под разные форматы данных и требования к их доступности — разные хранилища.
Такой подход позволяет получить максимальную эффективность решения поставленных задач. Но одновременно с получением пользы современные компании сталкиваются с рядом трудностей.
Рост количества и качества ИТ-сервисов и повышение нагрузки на центральные системы при цифровой трансформации. Даже в компаниях, для которых ИТ не основной профиль, количество и сложность ИТ-систем постоянно растут. Критичной становится возможность «увязывания» систем, используемых разными командами, и агрегирования данных из разных источников. Это большая задача для ИТ-команд, для решения которой нужны не только ресурсы, но и экспертиза.
Низкая доступность данных, разбросанных по различным источникам и форматам. Под разные задачи и форматы данных компании часто используют разные хранилища. При этом, например, для аналитики и маркетинга бизнесу важно уметь быстро собирать и анализировать данные из всех источников. И делать это надо практически в реальном времени.
Отсутствие поддержки западных вендоров СУБД. Многие инструменты, которые компании использовали для консолидации данных из разных источников, стали частично или полностью недоступны пользователям из РФ. То есть бизнес вынужден перестраивать существующий стек, одновременно стараясь не нарушить работу уже надежно и давно работающих систем.
В этих условиях у компаний есть два варианта:
Самостоятельно строить решение на базе свободно распространяемых программных продуктов и/или собственной разработки для работы со всем объемом данных. Подход позволяет кастомизировать все решения, но он трудозатратный, требует глубокой экспертизы и не гарантирует получение нужного результата.
Использовать продукты от российских вендоров. Этот подход часто более приоритетный: пользователи могут быстро внедрить готовое решение для переливания данных без проблем с совместимостью, надежностью, безопасностью и поддержкой.
Пример такого готового продукта — Tarantool CDC.
Об экосистеме Tarantool и Tarantool CDC
VK Tech предлагает пользователям технологическую платформу Tarantool Enterprise Edition, которая представляет собой SDK для построения резидентных систем хранения данных.
На его основе построен целый пул коробочных решений Tarantool для конечных пользователей. В том числе:
Tarantool DB — мультипротокольная резидентная СУБД для сверхвысоких транзакционных нагрузок;
Tarantool Graph DB — графово-векторная база данных, которую можно использовать для моделирования сложных структур данных;
Tarantool Queue Enterprise — распределенная in‑memory-система очередей сообщений, которая позволяет создавать очереди с нужной архитектурой под разные сценарии использования;
Tarantool Column Store — in-memory-колоночная СУБД для гибридной транзакционно-аналитической обработки данных в реальном времени.
А для интеграции данных из разных систем хранения в продуктовом портфеле Tarantool есть Tarantool CDC.
Tarantool CDC: инструмент near real-time-репликации данных для решения задач
Tarantool CDC — репликатор, который позволяет сократить затраты на обслуживание real-time-репликаций данных между БД.
Используя инструмент, можно организовать обработку данных с помощью брокеров сообщений, построить кэш или витрину данных.
Tarantool CDC обеспечивает высокую производительность и перенос данных, обновляемых в реальном времени, не создавая дополнительной нагрузки на БД-источник. И даже подходит для систем, где объем обработки данных превышает 100 000 TPS.
Tarantool CDC предназначен для разных сценариев переноса данных. В том числе для:
синхронизации данных из Tarantool в другие СУБД;
наполнения кэш-витрин в Tarantool из мастер-базы (в том числе Oracle без GoldenGate);
двусторонней синхронизации Tarantool ↔ PostgreSQL;
миграции данных из проприетарных СУБД.
Варианты агрегации данных
Tarantool CDC позволяет реализовать агрегацию данных в двух направлениях.
Первый вариант — агрегация данных из одного или нескольких источников в Tarantool. Подход полезен, когда нужно данные из основной системы клиента обогатить информацией из других хранилищ и в консолидированном виде передать в единое хранилище, которым может быть, например, Tarantool DB. В этом случае модуль Tarantool CDC подключается к получателю информации.
Возможные источники в таком сценарии:
PostgreSQL;
Oracle (Xstreams / OpenLogReplicator).
Режим экспорта — синхронный, пакетный.
Причем, что важно, для передачи данных из Oracle при подключении модуля Tarantool CDC не нужен Oracle GoldenGate: мы можем в режиме реального времени забирать данные из архивных журналов Oracle и передавать их в Tarantool с минимальными задержками.
Второй вариант использования Tarantool CDC — передача данных из Tarantool DB в другие БД.
То есть репликатор позволяет забирать данные из Tarantool и отдавать их в Oracle, Postgres и другие БД, которые поддерживают подключение по ODBC/JDBC (PostgreSQL, MS SQL, DB2, MySQL, Oracle и другие).
В перспективе Tarantool CDC также можно будет использовать для передачи данных в базы данных для аналитики и документарные полнотекстовые базы данных, такие как ClickHouse, GreenPlum, ElasticSearch.
В таком сценарии возможен синхронный и пакетный режим передачи данных, но зачастую CDC рассматривают как решение для оперативной передачи данных в режиме реального времени.
Алгоритмы передачи данных из сторонних БД
Алгоритм CDC из Oracle в Tarantool DB следующий:
Инструмент OpenLogReplicator (OLR) отслеживает изменения таблиц Oracle, производя разбор Online Redo Log Files и Archive Redo Log Files.
Source Oracle Connector получает CDC-поток из OLR по сети.
Коннектор отправляет данные в Tarantool Queue Enterprise через GRPC-интерфейс.
Очередь Tarantool Queue Enterprise передает сообщения в Sink Tarantool Connector, который, в свою очередь, записывает данные в Tarantool DB.
Tarantool CDC развертывается в Kubernetes, что позволяет легко масштабироваться, если нужно увеличить производительность системы.
В случае передачи данных из PostgreSQL алгоритм несколько отличается:
Source Connector отслеживает изменения таблиц GreenPlum/PostgreSQL.
Коннектор отправляет данные в Tarantool Queue Enterprise через GRPC-интерфейс.
Очередь Tarantool Queue Enterprise передает сообщения в Sink Tarantool Connector, который, в свою очередь, записывает данные в Tarantool DB.
В этой схеме отсутствует промежуточный инструмент OpenLogReplicator (OLR), используемый при репликации данных из Oracle.
Потоками и компонентами в случае PostgreSQL также управляет K8s Operator.
Эксплуатационные возможности и преимущества Tarantool СDC
Tarantool СDC можно интегрировать в разные системы. Эффективности и надежности трансфера данных между разными хранилищами способствует ряд особенностей инструмента. Выделим несколько:
высокая производительность за счет использования in-memory-технологии;
минимизация нагрузки на базу-источник за счет чтения непосредственно журналов транзакций;
совместимость с экосистемой Debezium, готовые коннекторы;
отказоустойчивость за счет очереди под капотом Tarantool Queue Enterprise (аналог Kafka);
собственные коннекторы на разных языках GO, JAVA: Source для Tarantool Enterprise Edition, Tarantool Data Grid 2, Tarantool DB, PostgreSQL, Sink для Tarantool DB, ClickHouse, PostgreSQL;
real-time-репликация из проприетарных СУБД;
масштабирование за счет K8s Operator;
совместимость с отечественными операционными системами (AstraLinux, RedOS и AltLinux);
доступность экспорта метрик мониторинга;
возможность развертывания в среде Kubernetes.
Пример построения системы с Tarantool СDC
Чтобы наглядно представить возможности Tarantool СDC, рассмотрим условный сценарий использования репликатора в системе real-time-маркетинга.
Представим, что есть крупная финансовая организация, которая хочет получить возможность готовить маркетинговые предложения клиентам на лету. При этом изначально у компании несколько десятков миллионов клиентов и есть старая система real-time-маркетинга на SAP и Oracle. Соответственно, чтобы реализовать требуемую новую систему и получить возможность в режиме реального времени анализировать интересы, поведение, психотип и другие признаки конкретного человека, необходимо построить сложную систему, работающую в реальном времени.
Дополнительные требования:
оперативный учет изменений в правилах кампании или в выборке участников, которые могут происходить в течение дня;
оперативная фиксация статусов предложений и реакции клиентов.
Для построения такой системы подойдет следующее решение.
Ночью создается основной массив предложений для всех потенциальных «покупателей». Пользователи делятся на сегменты, способы взаимодействия с которыми добавляются в основную базу данных. Таким образом формируется общее хранилище предложений.
В течение дня происходит взаимодействие с частью или со всеми пользователями. Для этого часть данных с помощью Tarantool CDC передается в активную витрину, построенную на Tarantool DB.
В течение дня можно оперативно дослать предложения, добавив их в основное хранилище. То есть за счет того, что передача изменений происходит практически в реальном времени, вносить изменения в кампанию взаимодействия можно по мере необходимости.
Приложения для взаимодействия считывают информацию из активной витрины и передают предложение клиенту через выбранный канал.
Клиент может никак не реагировать, реагировать негативно или проявить интерес. Все реакции клиента фиксируются и записываются обратно в Tarantool DB.
Записанный результат с помощью Tarantool CDC передается в основное хранилище для дальнейшего анализа.
Таким образом, мы получаем следующую цепочку движения данных:
Хранилище предложения (PostgreSQL).
Tarantool CDC.
Активные предложения (Tarantool DB).
Отклики (Tarantool DB).
Tarantool CDC.
Хранилище откликов (PostgreSQL).
Легко заметить, что именно Tarantool CDC в данной конфигурации является основным связующим звеном, которое обеспечивает взаимодействие всех компонентов системы.
У подобной реализации несколько важных достоинств. В том числе:
возможность предварительной генерации предложений;
доставка предложений и фиксация результата по разным каналам связи;
возможность оперативного изменения предложений;
мгновенное получение реакций клиентов и возможность планово или оперативно отреагировать на них.
Итоги
В компаниях, где много данных, а ИТ-ландшафт разрозненный, без связки в виде CDC практически не обойтись. Причем нередко «первого попавшегося» CDC недостаточно: решение должно быть совместимо со стеком компании, быть отказоустойчивым, уметь оперативно обрабатывать большие объемы данных, иметь локазированную поддержку.
Tarantool СDC удовлетворяет этим требованиям и эффективно помогает сократить затраты на обслуживание real-time-репликаций из реляционных СУБД во внешние системы. Порог входа в работу с Tarantool CDC минимальный, с решением не требуются лицензии на дополнительные продукты, а собирать данные можно из большинства популярных реляционных СУБД. И все это в реальном времени, без дополнительной нагрузки БД-источники и с возможностью обработки данных свыше 100 000 TPS.
Узнавайте о новых релизах, вебинарах и выходящих статьях в Telegram-канале Tarantool News.
О принципах и примерах работы продуктов Tarantool читайте в блоге на сайте.