Эта статья частично пересекается со статьей Понимание инкрементальных стратегий dbt, часть 1 (рекомендую ознакомиться).

Изменение данных — одна из основных задач для команд инженерии данных, особенно при переходе от одной технологии к другой. Обсудим команды DML в языке SQL.

Ниже будут рассмотрены основные схемы обновления данных в Data Engineering.

Стратегия полного обновления (full refresh)

Вариант 1 — Truncate Table

Стирание — это шаблон обновления, который ничего не обновляет. Он просто удаляет старые данные. При обновлении по схеме «стирание и перезагрузка» (truncate-and-reload) таблица очищается от данных, а преобразования запускаются заново и загружаются в таблицу, фактически создавая её новую версию.

Пример:

TRUNCATE TABLE target_table;  

INSERT INTO target_table  
SELECT customer_id, SUM(amount) AS total_amount  
FROM source_table  
WHERE order_date >= '2024-12-01' AND order_date <= '2024-12-31'  
GROUP BY customer_id;

Вариант 2 — Drop Table

Replace (Drop and Recreate) — Удаление таблицы и создание новой с новыми данными.

Применение:

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

Пример:

DROP TABLE IF EXISTS target_table;  

CREATE TABLE target_table AS  
SELECT *  
FROM source_table;

Вариант 3 — Собираем временную таблицу и делаем переименование

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

В разных базах данных по разному можно выполнить переименование таблиц, в ClickHouse есть например EXCHANGE.

Append Only (Anti Join)

Append (Anti Join) — Добавление только новых записей, которых нет в целевой таблице.

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

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

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

При вставке данных в OLAP-базы на основе столбцов часто возникает проблема, когда инженеры, переходящие со строковых систем, используют однострочную вставку. Этот антипаттерн создаёт огромную нагрузку на систему. Данные записываются в множество отдельных файлов, что снижает эффективность их последующего считывания. Рекомендуется загружать данные микропакетами или пакетами.

Исключением из правила «не выполнять частую вставку» является усовершенствованная лямбда-архитектура, применяемая в BigQuery и Apache Druid. Она сочетает потоковый буфер с хранилищем на основе столбцов.

Применение Append:

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

Принцип работы:

1. Выполняется проверка на наличие данных в целевой таблице с использованием ANTI JOIN.
2. Данные, которых нет в целевой таблице, добавляются.

Пример:

Добавление новых заказов, которых еще нет в основной таблице.

INSERT INTO target_table (id, order_date, amount)  
SELECT s.id, s.order_date, s.amount  
FROM source_table s  
LEFT JOIN target_table t ON s.id = t.id  
WHERE t.id IS NULL; -- Только те записи, которых нет в целевой таблице

Merge (также называется Upsert)

Upsert / Merge — Обновление существующих данных или добавление новых.

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

Операция Upsert (обновление + вставка) вызывает проблемы у инженеров, особенно при переходе от строковых баз данных к облачным хранилищам на основе столбцов.

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

Файловые системы не поддерживают обновление файлов на месте. Они используют технологию копирования при записи (Copy-on-write, COW): при изменении или удалении записи переписывается весь файл. Это делает операции обновления сложными.

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

Обновления редко приводят к переписыванию всей таблицы. Эффективность зависит от стратегии разбиения и кластеризации.

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

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

Применение:

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

Принцип работы:

1. Выполняется проверка на совпадение ключей между источником и целевой таблицей.
2. При совпадении ключа выполняется обновление.
3. При отсутствии совпадения выполняется вставка.

Пример:

Синхронизация информации о пользователях.

MERGE INTO target_table AS t  
USING source_table AS s  
ON t.id = s.id  
WHEN MATCHED THEN  
    UPDATE SET t.name = s.name, t.email = s.email  
WHEN NOT MATCHED THEN  
    INSERT (id, name, email)  
    VALUES (s.id, s.name, s.email);

Delete + Insert

Удаление данных важно, если исходная система требует их удаления в соответствии с нормативными требованиями. В системах на основе столбцов удаление обходится дороже, чем вставка.

Существуют два вида удаления: жёсткое и мягкое. Жёсткое удаление окончательно удаляет запись из базы данных, а мягкое помечает запись как «удалённую». Мягкое удаление полезно, если запись не нужно удалять навсегда, но нужно исключить из результатов запроса.

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

Delta Updates (Change-Based Updates) — Применение изменений к целевой таблице на основе метки времени или инкрементального идентификатора.

Применение:

Используется, если источник предоставляет только измененные записи.

Пример:

Обновление заказов, измененных после последней загрузки.

-- Удаление старых данных
DELETE FROM target_table  
WHERE id IN (SELECT id FROM source_table WHERE updated_at > @last_load_time);  

-- Вставка новых данных
INSERT INTO target_table  
SELECT *  
FROM source_table  
WHERE updated_at > @last_load_time;

Insert Overwrite / Swap partitions

Windowed Updates (Partition-Based) — это Обновление данных по партициям (например, по диапазонам дат).

Схема работы с партициями следующая:

1. Собирается таблица с обновленными партициями.
2. Далее меняются партиции целевой таблицы (target table) и временной.
3. После замены существующих партиций и вставки новых партиций — временная таблица удаляется

Пример для ClickHouse:

ALTER TABLE test.hits_local REPLACE PARTITION '2020-10-27' FROM test.hits_local_tmp;
ALTER TABLE test.hits_local_tmp DROP PARTITION '2020-10-27';

Работа с партициями в ClickHouse

Для работы с партициями доступны следующие операции:

• DETACH PARTITION — перенести партицию в директорию detached;
• DROP PARTITION — удалить партицию;
• ATTACH PARTITION|PART — добавить партицию/кусок в таблицу из директории detached;
• ATTACH PARTITION FROM — скопировать партицию из другой таблицы;
• REPLACE PARTITION — скопировать партицию из другой таблицы с заменой;
• MOVE PARTITION TO TABLE — переместить партицию в другую таблицу;
• CLEAR COLUMN IN PARTITION — удалить все значения в столбце для заданной партиции;
• CLEAR INDEX IN PARTITION — очистить построенные вторичные индексы для заданной партиции;
• FREEZE PARTITION — создать резервную копию партиции;
• UNFREEZE PARTITION — удалить резервную копию партиции;
• FETCH PARTITION|PART — скачать партицию/кусок с другого сервера;
• MOVE PARTITION|PART — переместить партицию/кускок на другой диск или том.
• UPDATE IN PARTITION — обновить данные внутри партиции по условию.
• DELETE IN PARTITION — удалить данные внутри партиции по условию.

SCD (Slowly Changing Dimensions)

Медленно изменяющиеся измерения в хранилище данных (Slowly Changing Dimensions, SCD) — важная концепция, которая используется для включения исторического аспекта данных в аналитическую систему. Как вы знаете, хранилище данных используется для анализа исторических данных, важно хранить различные состояния данных.

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

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

Типы SCD

SCD Тип 0

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

Ниже приведен пример для типа 0 медленно изменяющихся измерений в хранилище данных.

В приведенном выше измерении «Клиент» FirstDesignation, JoinedDate и DateFirstPurchase — это атрибуты, которые не будут обновляться, что соответствует SCD типа 0.

SCD Тип 1

В SCD типа 1 вы просто перезаписываете данные в измерениях. Могут быть ситуации, когда у вас нет всех данных, когда запись инициируется в измерении. Например, когда инициируется запись клиента, вы можете не получить все атрибуты. Поэтому, когда запись клиента инициируется в рабочей базе данных, в записях клиентов будут пустые или нулевые записи. После выполнения ETL эти пустые записи будут созданы в хранилище данных. После того, как эти атрибуты будут заполнены в рабочих базах данных, это должно быть обновлено в хранилище данных.

SCD типа 1 определяют, являются ли существующие атрибуты нулевыми, и вы получаете значение из рабочей таблицы.

В приведенной выше таблице Customer Dimension AnnualIncome клиентов CustomerKey 11015 и 11019 равны NULL. Когда эти записи обновляются в операционной базе данных, эти значения должны обновляться в хранилище данных без учета того, что это исторические значения.

SCD Тип 2

Тип 2 Медленно изменяющиеся измерения в хранилище данных — это самое популярное измерение, которое используется в хранилище данных. Как мы уже обсуждали, хранилище данных используется для анализа данных. Если вам нужно проанализировать данные, вам нужно учесть исторические аспекты данных. Давайте посмотрим, как мы можем реализовать SCD Тип 2.

Для SCD типа 2 нам необходимо включить еще три атрибута, такие как StartDate, EndDate и IsCurrent, как показано ниже.

В приведенном выше измерении клиента есть две записи, и предположим, что клиент, CustomerCode которого — AW00011012, был повышен до старшего руководства. Однако, если вы просто обновите запись новым значением, вы не увидите предыдущие записи. Поэтому будет создана новая запись с новым CustomerKey и новым Designation. Однако другие атрибуты останутся прежними.

Как вы можете видеть на рисунке выше, CustomerCode AW00011012 имеет новую запись с кодом 11013. Все новые транзакции будут связаны с CustomerKey 11013, в то время как предыдущие транзакции связаны с CustomerKey 11012. Этот механизм помогает сохранить исторический аспект клиента, как показано в запросе ниже.

SELECT
    C.Designation,
    SUM(SalesAmount) AS SalesAmount,
    SUM(TotalProductCost) AS TotalProductCost 
FROM FactInternetSales F
INNER JOIN Dim_Customer C ON F.CustomerKey = C.CustomerKey
GROUP BY C.Designation

После выполнения запроса будут получены следующие результаты.

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

SCD Тип 3

Тип 3 Медленно изменяющееся измерение в хранилище данных — это простая реализация, где история будет храниться в дополнительном столбце. Если мы свяжем тот же сценарий, который мы обсуждали в Типе 2 SCD, с Типом 3 SCD, измерение клиента будет выглядеть следующим образом.

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

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

SCD Тип 4

Как мы обсуждали в SCD типа 2, мы сохраняем историю, добавляя другую версию строки в измерение. Однако, если изменения быстрые по своей природе, SCD типа 2 не будет масштабируемым.

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

Ниже приведена взаимосвязь между таблицами «Факт» и «Клиентское измерение».

SCD Type 4 вводится для исправления этой проблемы. В этом методе быстро меняющийся столбец выносится из измерения и перемещается в новую таблицу измерений. Это новое измерение связано с таблицей фактов, как показано на диаграмме ниже.

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

SCD Тип 6

Медленно изменяющиеся измерения типа 6 в хранилище данных представляют собой комбинацию SCD типа 2 и типа 3. Это означает, что в реализации SCD типа 6 оба столбца являются строками.

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

SELECT
    C.Occupation,
    C.CurrentOccupation,
    SUM(SalesAmount) AS SalesAmount,
    SUM(TotalProductCost) AS TotalProductCost 
FROM FactInternetSales F
INNER JOIN Dim_Customer C ON F.CustomerKey = C.CustomerKey
GROUP BY C.Occupation,C.CurrentOccupation

Приведенный выше запрос даст следующий результат:

Без Типа 6, медленно меняющихся измерений в хранилище данных, приходится использовать сложные запросы.

В SCD типа 6 можно использовать не только текущую профессию, но и первую профессию для проведения более глубокого анализа.

Как устроено CDC (Change Data Capture)

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

Почему это важно

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

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

Три основных подхода CDC (Change Data Capture Methods)

1. Log-based CDC (CDC на основе журнала). Это наиболее эффективный способ внедрения CDC. Когда новая транзакция попадает в базу данных, она регистрируется в файле журнала без влияния на исходную систему. И вы можете подобрать эти изменения, а затем переместить их из журнала.
Блок-схема, показывающая изменения данных в исходной базе данных (удаление, обновление, вставка), регистрируемые майнером журнала транзакций и применяемые к целевой системе с метками времени и суммами для каждой операции.

2. Query-based CDC (CDC на основе запросов) / Timestamp-Based CDC. Здесь вы запрашиваете данные в источнике, чтобы получить изменения. Этот подход более инвазивный для исходных систем, потому что вам нужно что-то вроде временной метки в самих данных.

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

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

Подборка видео про CDC

Change Data Capture (CDC) Explained (with examples)

Stream your PostgreSQL changes into Kafka with Debezium

Сообщение Инкрементальное обновление данных — Incremental Data Refresh появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.