Изменить сбор данных

В базах данных система отслеживания измененных данных ( CDC ) представляет собой набор шаблонов проектирования программного обеспечения , используемых для определения и отслеживания измененных данных («дельты»), чтобы можно было предпринять действия с использованием измененных данных. Результатом является , управляемый дельтой набор данных .

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

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

Методология

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

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

Временные метки в строках

Таблицы, изменения которых должны быть зафиксированы, могут иметь столбец, представляющий время последнего изменения. Такие имена, как LAST_UPDATE, LAST_MODIFIED и т. д., являются общими. Любая строка в любой таблице, имеющая метку времени в этом столбце, более позднюю, чем дата последнего сбора данных, считается измененной.

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

Номера версий в строках

Разработчики баз данных предоставляют таблицам, изменения которых должны быть зафиксированы, столбец, содержащий номер версии. Такие имена, как VERSION_NUMBER и т. д., являются общими.

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

(Не путайте этот метод с управлением версиями на уровне строк, используемым для оптимистической блокировки . Для оптимистической блокировки каждая строка имеет независимый номер версии, обычно последовательный счетчик. Это позволяет процессу атомарно обновлять строку и увеличивать ее счетчик только в том случае, если другой процесс имеет не увеличил счетчик. Но CDC не может использовать версии на уровне строк для поиска всех изменений, если ему не известна исходная «начальная» версия каждой строки. Это непрактично.)

Индикаторы состояния в строках

Этот метод может дополнять или дополнять временные метки и управление версиями. Он может настроить альтернативу, если, например, в строке таблицы установлен столбец состояния, указывающий, что строка изменилась (например, логический столбец, который, если ему присвоено значение true, указывает, что строка изменилась). В противном случае он может действовать как дополнение к предыдущим методам, указывая, что строка, несмотря на наличие нового номера версии или более поздней даты, все равно не должна обновляться в целевом объекте (например, данные могут потребовать проверки человеком).

Время/версия/статус строк

Этот подход сочетает в себе три ранее обсуждавшихся метода. Как уже отмечалось, нередко можно увидеть работу нескольких решений CDC в одной системе, однако сочетание времени, версии и статуса обеспечивает особенно мощный механизм, и программистам следует использовать их как трио, где это возможно. Эти три элемента не являются лишними или излишними. Их совместное использование позволяет реализовать такую логику, как «Собрать все данные для версии 2.1, которые изменились между 01.06.2005 00:00 и 01.07.2005 00:00, где код состояния указывает, что она готова к производству».

Триггеры на таблицах

Может включать шаблон публикации/подписки для передачи измененных данных нескольким целям. В этом подходе триггеры записывают события, происходящие с транзакционной таблицей, в другую таблицу очереди, которую позже можно «воспроизвести». Например, представьте себе таблицу Accounts: когда в этой таблице выполняются транзакции, срабатывают триггеры, которые затем сохраняют историю событий или даже дельты в отдельной таблице очереди. Таблица очереди может иметь схему со следующими полями: Id, TableName, RowId, Timestamp, Operation. Данные, вставленные для нашего образца учетной записи, могут быть следующими: 1, учетные записи, 76, 2008-11-02 00:15, обновление. Более сложные конструкции могут регистрировать фактические изменившиеся данные. Эту таблицу очередей затем можно было «воспроизвести» для репликации данных из исходной системы в целевую.

Сбор данных представляет собой проблему, поскольку структура, содержание и использование журнала транзакций специфичны для системы управления базами данных. В отличие от доступа к данным, для журналов транзакций не существует стандарта. Большинство систем управления базами данных не документируют внутренний формат своих журналов транзакций, хотя некоторые предоставляют программные интерфейсы для своих журналов транзакций (например: Oracle, DB2, SQL/MP, SQL/MX и SQL Server 2008).

Другие проблемы при использовании журналов транзакций для сбора данных об изменениях включают в себя:

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

Решения CDC, основанные на файлах журналов транзакций, имеют явные преимущества, в том числе:

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

Смешивающие факторы

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

Неподходящие исходные системы

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

Отслеживание захвата

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

Отслеживание изменений с помощью триггеров базы данных
Чтение журнала транзакций сразу после его записи или вскоре после него.

Если данные отсутствуют в современной базе данных, CDC становится проблемой программирования.

Толкать против тянуть

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

Альтернативы

Иногда медленно меняющееся измерение . в качестве альтернативного метода используется ^{[ 1 ]} CDC и SCD схожи тем, что оба метода могут обнаруживать изменения в наборе данных. Наиболее распространенными формами SCD являются тип 1 (перезапись), тип 2 (сохранение истории) или 3 (только предыдущее и текущее значение). SCD 2 может быть полезен, если в целевой системе требуется история. CDC перезаписывает в целевой системе (аналогично SCD1) и идеален, когда в цель должны поступить только измененные данные. ^{[ 2 ]} т. е. управляемый дельтой набор данных, . ^{[ нужна ссылка ]}

См. также

Ссылки

^ Герой, Эрит (2015). 4гг Рти.
^ Медленно меняющиеся измерения (SCD) и сбор измененных данных (CDC)

Анкорион, Итамар Анкорион, 2005. «Изменение эффективного ETL сбора данных для бизнес-аналитики в реальном времени». Информационный менеджмент, 15(1).

См. также

Интегратор данных Oracle

[1] Герой, Эрит (2015). 4гг Рти.

[2] Медленно меняющиеся измерения (SCD) и сбор измененных данных (CDC)

[ 1 ]

[ 2 ]