Изменение данных и создание моментальных снимков

Инженеры данных часто должны реплицировать данные из источников вышестоящих Azure Databricks, таких как реляционные базы данных (Oracle, Postgres, SQL Server), в Azure Databricks для аналитики, отчетности и машинного обучения. По мере изменения операционных систем аналитические таблицы должны оставаться синхронизированными с этими изменениями.

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

Запись измененных данных (CDC) обрабатывает базу данных как набор изменений, а не как полную статическую базу данных. На следующей схеме показано, что при обновлении строки в исходной таблице, содержащей данные сотрудника, создаётся новый набор строк в потоке CDC, который содержит только изменения. Каждая строка веб-канала CDC обычно содержит дополнительные метаданные, включая операцию, такую как UPDATE, и столбец, который можно использовать для упорядочивания строк в веб-канале CDC, чтобы можно было обрабатывать неупорядоченные обновления. Например, sequenceNum столбец на следующей схеме определяет порядок строк в канале данных CDC.

Обзор отслеживания измененных данных.

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

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

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

Преимущества CDC

Запись измененных данных обеспечивает несколько преимуществ в рабочих нагрузках.

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

Как применяются изменения: текущее состояние или полный журнал изменений

Медленно изменяющиеся измерения (SCD) определяют, как изменения применяются и моделируются после того, как они попадают в аналитические таблицы. Организации могут использовать различные подходы в зависимости от потребностей в данных. SCD Type 1 позволяет сохранять только текущее состояние набора данных. SCD Type 2 сохраняет полную историю изменений в наборе данных. В этом разделе подробно описаны эти сведения.

SCD Type 1: только текущее состояние

SCD Type 1 перезаписывает старые данные новыми данными при каждом изменении, сохраняя только последнюю версию каждой записи. История не сохраняется.

Используйте SCD Type 1, когда:

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

В SCD1 доступна только последняя версия данных. Это простой подход, который можно рассматривать как хранение только окончательной таблицы. Если запись изменяется с Owner на Manager,, в таблице остаётся только Manager.

Обзор отслеживания измененных данных SCD Type 1.

ScD Type 2: историческое отслеживание

SCD Type 2 сохраняет полную историческую запись, создавая несколько версий данных с течением времени, каждая из которых снабжена временной меткой и метаданными. Столбцы __START_AT и __END_AT определяют срок действия каждой версии записи. Активные записи имеют __END_AT = NULL. Состояние набора данных можно просмотреть в любой момент времени.

Используйте SCD Type 2, когда:

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

Обработка SCD Типа 2 поддерживает историческую запись изменений данных. Например, если поле роли в записи в настоящее время установлено на Manager, вы также можете увидеть, что оно ранее было установлено на Owner. На следующем изображении это как раз то, что произошло с записью Chris. Вы можете определить текущую запись, поскольку она имеет значение null поля end_at.

Обзор фиксации изменений данных SCD Type 2.

Что такое поток данных CDC?

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

Например, если у вас есть таблица сотрудников в Oracle с 50 строками, и должность одного сотрудника изменяется, поток CDC содержит одну UPDATE запись для этого сотрудника. Это позволяет Azure Databricks обрабатывать только измененные записи, а не читать всю исходную таблицу во всех запусках.

Каждая запись CDC из исходной базы данных включает:

  • Тип операции (INSERT, UPDATE, DELETE)
  • Значения данных для записи
  • Порядковый номер или метка времени для детерминированного порядка

Порядковый номер гарантирует правильную обработку поздних или не в порядке поступлений. Транзакционные базы данных, такие как SQL Server, MySQL и Oracle, генерируют CDC фиды нативно. Таблицы Delta также создают собственный поток данных CDC, известный как поток данных изменений (CDF), что упрощает обработку изменений из источников Delta.

Что такое моментальный снимок?

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

Команды не всегда включают каналы CDC в операционные базы данных по различным причинам.

  • Затраты (CDC могут увеличить нагрузку на рабочие базы данных)
  • Проблемы с производительностью базы данных-источника
  • Устаревшие системы, не поддерживающие CDC
  • Ограничения организации (команды, управляющие процессом обработки данных, не владеют базами данных, находящимися на предыдущем этапе)

Если поток изменений недоступен, прием с использованием моментальных снимков — единственный вариант. Моментальные снимки могут поступать из:

  • Периодический экспорт из реляционных баз данных (Oracle, Postgres, SQL Server)
  • Дампы файлов облачного хранилища из вышестоящих систем
  • Таблицы Delta (каждая версия таблицы фактически является снимком состояния)
  • OpenSharing для вышестоящих арендаторов

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

Автоматическая обработка потоков CDC

Azure Databricks упрощает обработку CDC с помощью API AUTO CDC в конвейерах Lakeflow. Этот API предназначен для обработки изменений из каналов CDC в исходных базах данных или таблицах Delta с включенной функцией отслеживания изменений данных.

Примеры кода SQL и Python см. в примерах AUTO CDC.

Используйте AUTO CDC, если одно из этих условий выполняется:

  • Исходная система создает поток данных об изменениях (CDF)
  • Вы читаете из таблицы Delta с включенной функцией Change Data Feed
  • У вас есть веб-канал CDC из реляционной базы данных (с помощью таких средств, как Debezium или Oracle GoldenGate)

AUTO CDC автоматически обрабатывает записи вне последовательности путем обработки событий в порядке, определенном столбцом последовательности. Столбец последовательности должен быть монотонно возрастающим представлением корректного порядка событий с уникальным обновлением для каждого ключа при каждом значении последовательности. NULL Значения упорядочивания не поддерживаются. Для SCD типа 2 конвейер передает значения последовательности в столбцы __START_AT и __END_AT целевой таблицы.

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

Автоматическое обработка моментальных снимков

Если потоки данных CDC недоступны, Azure Databricks предоставляет AUTO CDC FROM SNAPSHOT API. Этот API предназначен для приема, основанного на моментальных снимках; он сравнивает последовательные моментальные снимки, создает синтетическую ленту изменений и применяет логику SCD Типа 1 или SCD Типа 2 к целевой таблице. Целевая таблица может предоставлять поток CDC (называемый потоком измененных данных (CDF) в Delta таблицах) либо для SCD Типа 1, либо для Типа 2 для последующих запросов.

Примеры кода Python см. в примерах AUTO CDC FROM SNAPSHOT.

AUTO CDC FROM SNAPSHOT поддерживается только в интерфейсе конвейера Python. Моментальные снимки должны обрабатываться в порядке возрастания по версии; если обнаруживается моментальный снимок не в порядке возрастания, он игнорируется. Нижестоящая обработка, такая как материализованное представление, которое запрашивает выходные данные AUTO CDC FROM SNAPSHOT набора данных, получает преимущества CDC, такие как возможность инкрементного обновления и стабильные суррогатные ключи.

Примечание.

AUTO CDC FROM SNAPSHOT не только для начальных загрузок. Он предназначен для непрерывной обработки, когда моментальные снимки являются единственным доступным форматом. Каждый раз при поступлении нового моментального снимка API сравнивает его с предыдущим моментальным снимком для определения изменений и формирования потока данных об изменениях.

AUTO CDC FROM SNAPSHOT следует использовать в следующих случаях:

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

AUTO CDC FROM SNAPSHOT обрабатывает следующие функции автоматически:

  1. Сравнивает последовательные моментальные снимки для идентификации вставленных, обновленных и удаленных записей.
  2. Создает синтетический поток изменений на основе различий между моментальными снимками.
  3. Применяет ту же логику SCD, что AUTO CDC и для вычислений SCD Типа 1 или Типа 2.

Примечание.

AUTO CDC FROM SNAPSHOT знает только об изменениях между одним снимком и следующим и не получает сведения о промежуточных изменениях. Например, если вы получаете ежедневные моментальные снимки, и пользователь изменяет свой адрес дважды за один день (с A на B, затем с B на C), ваш change feed может перейти прямо с A на C, так как вы получили моментальные снимки только в эти моменты времени.

Шаблоны обработки моментальных снимков

AUTO CDC FROM SNAPSHOT поддерживает два паттерна для определения версий моментальных снимков.

Обработка снимков состояния с использованием времени ввода данных в конвейер

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

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

Обработка моментальных снимков с помощью функций версии

Вы предоставляете функцию, указывающую версию снимка для обработки на момент выполнения конвейера. Функция возвращает кортеж: (DataFrame, version_number) API обрабатывает снимки в соответствии с порядком, определённым номерами версий. Если обнаружен снимок, выпавший из очереди, снимок игнорируется.

Используйте этот шаблон, когда:

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

Дополнительные возможности CDC

Изменение операций с целевыми объектами AUTO CDC

В отличие от стандартных таблиц потоковой передачи, таблицы каталога Unity, нацеленные AUTO CDC на поддержку INSERT, UPDATE, DELETE и MERGE операторов, поддерживают их даже в процессе выполнения конвейера. Дополнительные сведения и ограничения см. в разделе "Добавление, изменение или удаление данных в целевой потоковой таблице".

Чтение потоков изменений данных из целевых объектов AUTO CDC

AUTO CDC Целевые таблицы потоковой передачи могут выдавать собственный канал данных изменений (CDF), позволяя подчиненным конвейерам использовать изменения из выходных AUTO CDC данных. Дополнительные сведения см. в чтении потока изменяемых данных из целевой таблицы AUTO CDC.

Метрики и мониторинг

AUTO CDC автоматически фиксирует num_upserted_rows и num_deleted_rows метрики для каждого запуска конвейера. Дополнительные сведения см. в темах об advanced AUTO CDC.

Отслеживание подмножеств столбцов в SCD Type 2

По умолчанию SCD Type 2 создает новую версию при каждом изменении значения столбца. AUTO CDC позволяет указать, какие столбцы следует отслеживать для истории, чтобы изменения в неотслеживаемых столбцах обновляли текущую версию, а не создавали новую историческую запись. Это снижает затраты на хранение и сложность запросов, сохраняя историю критически важных атрибутов. Пример см. в разделе "Отслеживание подмножества столбцов" с помощью SCD Type 2.

Рекомендации

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

Используйте API AUTO CDC, когда необходимо реплицировать данные из вышестоящих систем в Azure Databricks и синхронизировать их с изменениями в исходных данных. Правильный API зависит от того, как исходная система предоставляет изменения:

  • Используйте AUTO CDC, если ваш источник выдает поток изменений, например реляционную базу данных с включенным CDC (с помощью таких инструментов, как Debezium или Oracle GoldenGate), таблицу Delta с включенной функцией Change Data Feed или любой источник, который создает поток вставок, обновлений и удалений со столбцом последовательности.
  • Использовать AUTO CDC FROM SNAPSHOT, если источник не поддерживает CDC и предоставляет только периодические полные дампы таблиц. Этот API выявляет изменения, сравнивая последовательные снимки состояния и создавая искусственную ленту изменений, поэтому вы получаете те же преимущества обработки SCD даже без собственного канала CDC.

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

Дополнительные ресурсы

  • Last updated on