ETL-поток начинается с передачи из источника (source system) в хранилище (DHW) свежей порции данных. Почти в любом хранилище требуется передавать только данные, изменившиеся с момента предыдущей загрузки. Полное обновление таблиц фактов (fact) и измерений (dimension) обычно нежелательно.

Вычленение в источнике только новых данных называется «захват изменившахся данных» (changed data capture) и часто сокращается до CDC в архитектурных диаграммах. Идея CDC кажется достаточно простой: передавать данные, которые изменились с момента последней загрузки. Но создать хорошую систему CDC не так просто, как кажется.

Вот основные цели создания системы CDC:

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

Первый шаг при создании системы CDC – это обнаружение изменений. Существует четыре основных способа для обнаружения изменений:

  1. Колонки аудита. В большинстве случаев системы-источники (source system) содержат колонки аудита. Эти колонки добавляются к каждой таблице и содержат дату и время вставки и последнего обновления. Значения этих колонок обычно заполняются с помощью триггеров, запускающихся автоматически при вставке или изменении записи. Иногда, по причинам, связанным с производительностью, значения заполняются конечными приложениями, а не триггерами (trigger) СУБД. В случае, если эти колонки заполняются любым способом, кроме триггеров, следует уделить особое внимание вопросу их достоверности. Следует проанализировать и протестировать каждую колонку, чтобы убедиться, является ли она надежным индикатором изменившейся записи. Если вы встречаете в этой колонке пустые значения, то следует поискать другой способ обнаружения изменений. Типична ситуация, препятствующая использованию колонок аудита в системе ETL: значение колонок генерируются конечными приложениями, но администраторы БД (DBA) запускают служебные скрипты, модифицирующие записи. Если это ваш случай, то вы рискуете время от времени пропускать изменившиеся данные при инкрементальных загрузках.
  2. Анализ журнальных файлов. Способ заключается в периодическом копировании журналов повторного выполнения (redo log) базы данных и разборе этих журналов с целью выделить транзакции, влияющие на интересующие вас таблицы. Можно также в постоянном режиме «опрашивать» журналы и обрабатывать транзакции «на лету». Анализ журнальных файлов является, наверное, самым малоприятным способом. Нередко журнальные файлы переполняются, что блокирует дальнейшие транзакции. Когда такое случается в промышленной транзакционной системе, рефлекторной реакцией ответственного администратора БД является очистка журналов, чтобы бизнес мог продолжать работать. Но при очистке журналов теряется информация о транзакциях. Если вы перебрали все варианты, и анализ журналов оказался единственным подходящим, то следует убедить администратора БД создать для вас специальный журнал транзакций.
  3. Выборки по времени. Выборка по времени подразумевает, что вы выбираете все записи, у которых дата вставки или последней модификации равна sysdate-1, подразумевая, что вы выбираете все «вчерашние» записи. Звучит отлично, верно? Неверно! Загрузка записей, основанная только на дате, является частой ошибкой всех начинающих разработчиков ETL. Этот процесс ужасно ненадежен. Загрузки, основанные на временной метке (timestamp), дублируют записи в случае перезапуска процесса загрузки из-за сбоя. Это значит, что в случае любого сбоя требуется ручное вмешательство для очистки. При этом, если ночная загрузка оканчивается сбоем и пропускается день, существует риск, что пропущенный день так никогда и не попадет в хранилище.
  4. Полное сравнение. При полном сравнении сохраняется полный снимок БД на вчерашний день, и сравнивается по каждой записи с сегодняшней БД для поиска каждого изменения. Хорошая новость заключается в том, что это наиболее общий способ – вы гарантированно найдете все изменения. Очевидная плохая новость состоит в том, что в большинстве случаев этот способ очень ресурсоемкий. Если вам требуется провести полное сравнение, то попытайтесь сделать его на системе-источнике, чтобы не вытаскивать всю БД в среду ETL. Проработайте также вопрос о применении контрольных сумм (CRC) для быстрого выяснения того, изменилась или нет сложная запись.

Этот совет указывает лишь на каплю проблем, окружающих CDC. Для более глубокого изучения вопроса я могу предложить следующее. Во-первых, вы можете почитать новую книгу The Data Warehouse ETL Toolkit, которую я написал совместно с Joe Caserta, для более детального рассмотрения каждого из описанных выше вариантов. Во-вторых, вы можете посетить мои семинары для архитекторов систем ETL. Для получения детальной информации посетите наш веб-сайт.

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ralph Kimball
Перевод на русский язык: Егор Демьянов
Оригинальный документ располагается здесь


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также:
    None Found