Сбор данных об изменениях

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

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

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

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

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

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

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

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

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

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

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

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

Этот подход объединяет три ранее обсуждавшихся метода. Как уже отмечалось, нередко можно увидеть несколько решений CDC, работающих в одной системе, однако сочетание времени, версии и статуса обеспечивает особенно мощный механизм, и программисты должны использовать их как трио, где это возможно. Эти три элемента не являются избыточными или излишними. Их совместное использование позволяет реализовать такую ​​логику, как «Захват всех данных для версии 2.1, которые изменились между 2005-06-01 00:00 и 2005-07-01 00:00, где код статуса указывает на готовность к производству».

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

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

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

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

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

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

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

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

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

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

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

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

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

• Ссылочная целостность
• Медленно меняющееся измерение

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

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