Введение в систему CDC — эффективный способ репликации транзакционных данных в озеро данных
Спрос на новые эффективные механизмы репликации транзакционной базы данных в аналитическую базу данных в режиме реального времени постоянно растет. Происходит это по следующим причинам:
- Традиционные реплики транзакционной базы данных не подходят для аналитических запросов (OLAP);
- Они не могут быть масштабированы для долгосрочных аналитических запросов (OLAP);
- Перекрестное соединение баз данных не всегда легко осуществить;
- Запросы OLAP могут мешать процессам OLTP, что может повлиять на поток транзакций.
Компании постоянно пытаются решить все вышеперечисленные проблемы, перебирая самые разные способы. Один из общепринятых подходов заключается в планировании пакетных заданий для периодической загрузки данных в озеро/хранилище данных. Однако это не совсем подходит для случаев, близких к работе в режиме реального времени, поскольку:
- Свежесть: для работы в режиме реального времени потребителям данных необходимы только самые свежие данные. Обычно задержка обработки данных составляет 12/24 часа, что неприемлемо для real-time ситуаций;
- Производительность: хранение большого количества небольших файлов влияет на задержку чтения;
- Стабильность: для систем загрузки, основанных на использовании моментальных снимков, необходимо решение, поддерживающее непрерывные операции обновления и удаления для существующих данных.
Чтобы решить данные задачи, в Swiggy используется система CDC (захват изменений данных от англ. Change Data Capture), структура поэтапной обработки данных, обеспечивающая непрерывное функционирование важных для бизнеса конвейеров данных с низкой задержкой чтения и высокой эффективностью.
Мотивирующий прецедент: поздние обновления и удаления
Рассмотрим жизненный цикл заказа Swiggy. Как правило, заказ поступает из системы предварительных заказов (витрина магазина), систем выполнения и доставки, а также из систем, связанных с процессами после осуществления доставки (поддержка клиентов). В то время, как большинство обновлений заказов выполняется в течение часа, каждую минуту мы получаем новые заказы и кучу обновлений для существующих заказов. Некоторые из них (например, обновления, связанные со службой поддержки клиентов, сверкой компенсаций и т. д.) могут появиться и для заказов, созданных за последние 15 дней.
Общая идея состоит в том, чтобы хранить эти данные об обновлениях в разных разделах (например, разделы данных по дате, часу или городу). Разделы значительно упрощают управление большими объемами информации. Основная проблема заключается в обновлении устаревших разделов, поскольку оно включает в себя:
- Поиск правильного раздела и правильного файла, в котором находятся данные, требует сканирования большого объема данных;
- Обеспечение согласованности данных при обновлении файла затруднено.
Что такое CDC?
CDC (Change Data Capture) - это паттерн проектирования, который фиксирует все изменения, происходящие с данными, вместо того, чтобы обрабатывать весь набор данных.
Вместо того, чтобы копировать всю базу данных, с помощью CDC фиксируются только те данные, которые изменились в базе данных, эти же изменения применяются и к аналитической базе данных (в том же порядке), чтобы обеспечить синхронизацию обеих баз данных.
Это более масштабируемое решение, поскольку имеет дело только с изменениями данных. Например, рассмотрим случай таблицы с 1 миллиардом записей и несколькими миллионами изменений в день. Данный подход позволяет нам применять только измененные записи (~ миллионы) вместо ежедневного копирования всего набора данных (~ миллиарды записей).
Подход, основанный на CDC
Основная идея подхода, основанного на CDC, заключается в применении изменений на аналитической стороне процесса по аналогии с тем, как это происходит в транзакционной базе данных. Чтение всего набора данных и перезапись в целевом хранилище заменяется непрерывным и поэтапным применением изменений в зависимости от типа операции (вставка/обновление/удаление). Нагрузка на исходную систему при этом значительно снижается, поскольку размер журналов транзакций очень мал, а сам процесс осуществляется в несколько этапов.
Решение, основанное на CDC, позволяет легко, эффективно и экономично решить вариант использования запаздывающих обновлений, упомянутый выше. Всякий раз, когда система сталкивается с обновлениями, она выбирает только те файлы, которые необходимо обновить, и в итоге обновляет только определенные записи.
Подход к построению системы репликации в реальном времени включает в себя два основных этапа:
- Создание копии текущей транзакционной базы данных;
- Применение текущих изменений к этой копии в том же порядке, в котором они появляются в транзакционной базе данных.
Важной частью данного подхода является корректность — захват «всех» изменений из транзакционной базы данных. Этот процесс должен легко восстанавливаться после сбоя, при этом никакие данные не должны быть потеряны. Если хотя бы одно событие потеряно, данные будут несогласованными. Другим ключевым моментом является время начала данного процесса. Если мы начнем процесс сбора изменений после создания реплики транзакционной базы данных, мы потеряем события, которые происходят во время процесса начальной загрузки. Поэтому лучше сначала запустить процесс CDC, а затем - процесс начальной загрузки.
Когда у нас есть текущие записи базы данных, мы используем метод поэтапного обновления для чтения данных из источника и применения изменений (вставка/обновление/удаление) в соответствии с тегами в исходных данных на основе поля первичного ключа.
Наконец, чтобы выполнить запрос к этому набору данных, мы синхронизируем схему таблицы и разделы с метахранилищем Hive и метаданными Snowflake.
Компоненты высокого уровня и поток данных при этом выглядят так:
Аргументы за и против использования CDC вместо массового извлечения и загрузки данных
Хотя CDC имеет ряд преимуществ, он сопряжен с определенными затратами. В данной статье мы обсудим издержки с точки зрения минусов данного подхода.
Аргументы за:
- Распределенная нагрузка — нагрузка распределена в течение суток. Извлечение и загрузка данных разбивается на небольшие наборы пошаговых изменений, что делает прием простым и эффективным;
- Масштабируемость — система масштабируется для поддержки ряда источников, ее очень легко масштабировать в различных точках системы, таких как CDC replicator, S3, задания Spark и т. д.;
- Быстрая и эффективная инструкция UPSERT — поскольку речь идет о пошаговых изменениях, время на upsert очень мало по сравнению с массовой вставкой/перезаписью. Это также эффективно, потому что операция происходит постепенно;
- Доступность - настройка доступности важна для случаев использования, близких к реальному времени. Система CDC предоставляет пользователю свободу выбора требований к задержке. В зависимости от требований система определяет интервал опроса/частоту обновления;
- Согласованность — одним из ключевых принципов этой системы является согласованность, для ее достижения мы использовали надежную, отказоустойчивую и легко восстанавливаемую систему, которая гарантирует 100% согласованность данных;
- Стоимость — стоимость работы системы конкурентоспособна по сравнению с процессом массового извлечения и загрузки. Стоимость оптимизируется за счет использования простых инфраструктурных компонентов, таких как lambda, DynamoDB, AWS DMS, S3, общие кластеры Spark, облегченные сервисы с использованием Golang. Значительная экономия средств достигается за счет удаления реплики чтения MySQL из источников;
- Легкое восстановление — процесс восстановления после сбоя очень прост и удобен. В случае сбоев система запускается с последней контрольной точки.
Аргументы против:
- Сложность : CDC – более сложная система по сравнению с Извлечением и Загрузкой;
Ограничения:
- Зависимость от ключа записи: Upsert последних обновлений поддерживается только для набора данных, который содержит ключ записи.
