Change Data Capture (CDC) — захват изменений данных

Анализ транзакций, хранящихся в OLTP-системах, играет важную роль для понимания состояния бизнес-процессов компании и в разработке решений по их совершенствованию. Однако ценность данных со временем снижается, поэтому организациям необходимо анализировать их практически в момент поступления. Как правило, данные в OLTP-системах являются «сырыми», поэтому перед анализом их сначала перемещают в хранилище данных (ХД), где они интегрируются, подвергаются очистке и предобработке.

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

Применение технологий CDC имеет следующие преимущества:

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

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

Отслеживание изменений данных в источниках

В CDC используют несколько методов отслеживания изменений данных в источниках, которые выбираются в зависимости от требований бизнеса и допустимых вычислительных затрат.

Метки времени

Для этого в таблицы вводятся дополнительные поля, в которых фиксируется время создания или последнего обновления записей (например, «LAST_UPDATED» или «DATE_MODIFIED»). Тогда при каждом перемещении данных следует извлекать только те записи, которые были созданы или изменены со времени прошлой выгрузки.

Логика CDC для этого метода будет следующей:

1. Получить максимальное значение столбцов «Время создания» и «Время обновления» целевой таблицы. Несложно увидеть, что это будут значения 15:00 и 18:00 соответственно.
2. Выбрать все строки из источника данных, у которых «Время создания» превышает максимальное значение «Время создания» целевой таблицы, и это все вновь созданные строки с момента выполнения последнего процесса CDC. Таким образом, это будут строки с метками времени 17:00, 15:30 и 16:00.
3. Выбрать все строки из исходной таблицы, у которых «Время обновления» больше максимального «Время обновления» целевой таблицы, но меньше ее максимального «Время создания». Причина исключения строк, дата создания которых меньше максимальной целевой даты, заключается в том, что они были включены в п.2. В показанном примере этому пункту будет удовлетворять единственная строка в источнике данных со временем обновления 20:00.
4. Вставить новые строки из шага 2 или изменить существующие строки из п.3 в целевой таблице.

Таким образом в целевую таблицу будут включены строки, выбранные в п.2, т.е. с метками времени создания 17:00, 15:30 и 16:00. При этом строка, созданная в 17.00 будет еще и обновлена в 20:00. Результирующая целевая таблица будет иметь вид:

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

Таблица «дельт»

Две таблицы сравнивают на предмет несовпадения и формируют подмножество несовпадающих записей или «дельта». Затем используются сценарии для переноса «дельт» из исходной таблицы в целевую.

Результирующая таблица, которая и будет загружена в целевую систему хранения, будет иметь вид:

Преимущество подхода заключается в том, что он обеспечивает точное представление изменений данных. Недостаток — высокие вычислительные затраты, поскольку требуется создавать и хранить три набора данных: исходное состояние таблицы, текущее состояние и «дельту». Кроме того, нагрузка на ХД значительно возрастает, поскольку метод плохо масштабируется в приложениях с высокими транзакционными нагрузками, что снижает скорость обновления данных.

Триггеры БД

Другой метод сбора данных об изменениях на уровне приложения — использование триггеров базы данных и создание собственного журнала изменений в теневых таблицах. Триггеры срабатывают до или после команд INSERT, UPDATE или DELETE и используются для создания журнала изменений, на который «подписываются» целевые системы хранения.

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

Журналы изменений

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

Поиск изменений на основе журналов

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

Особенности работы CDC-систем

Таким образом, когда в таблице источника данных добавляется, обновляется или удаляется строка, CDC формирует запись о произошедшем изменении с указанием первичного ключа строки и передает поток изменений в ХД (или иную целевую систему хранения).

При этом должны соблюдаться следующие требования:

• каждое изменение доставляется ровно один раз (exactly-once-семантика).
• изменения по одному и тому же первичному ключу доставляются в том же порядке, в котором они располагались в исходной таблице;
• запись об изменении доставляется только после фиксации соответствующей транзакции в таблице.

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

Другие материалы по теме:

Информационная экосистема предприятия

Дрейф данных