ГЛАВА 7. Многомерное моделирование (Dimensional Modeling)

Аннотация

Моделирование Data Vault не является заменой Dimensional Modeling, которое является отраслевым стандартом для определения витрины данных (уровня, используемого для предоставления данных конечному пользователю). Поскольку данная книга предназначена для охвата всего процесса построения хранилища данных от начала до конца, она также охватывает и Dimensional Modeling.

Первая часть этой главы сосредоточена на базовых сущностях Dimensional Modeling — фактовых сущностях и размерных сущностях.

• Fact Entities (Сущности фактов) — хранят измерения, метрики или факты бизнес-процесса (иными словами содержат числовые показатели бизнес-операций — факты и ключи к соответствующим таблицам размерностей).
• Dimension Entities (Cущности измерений) — содержат описательные атрибуты для фактов.

Будут рассмотрены различные типы размерностей, такие как медленно изменяющиеся измерения, а также способы выполнения запросов к данным из многомерной модели. Вторая часть этой главы объясняет, как работать с несколькими звёздными схемами, особенно с использованием согласованных измерений. Последняя часть сосредоточена на техниках многомерного проектирования и представляет снежинку и схему «Звезда» как частный случай схемы снежинки.

Ключевые слова

• Dimension modeling (Многомерное моделирование)
• Fact Entities (Фактовые сущности)
• Техники проектирования
• Snowflake Schemas (Схема «Снежинка»)
• Star Schemas (Схема «Звезда»)

Наилучшее применение моделирования Data Vault 2.0 — это уровень корпоративного хранилища данных. Оно было специально разработано для этой цели и является оптимальным выбором, когда требуется расширяемая, функционально-ориентированная модель, позволяющая отслеживать историю и проводить аудит, а также интегрируемая в среды реального времени и NoSQL.

Однако большинство бизнес-пользователей не знакомы с моделированием Data Vault 2.0. Во многих случаях конечным пользователям сначала требуется надлежащее обучение, чтобы они могли напрямую обращаться к Raw Data Vault или Business Vault, которые моделируются по тем же принципам. Им также необходимо понимать, как соединять многочисленные сущности, чтобы получать ценные и пригодные для использования сырые данные, которые могут быть обработаны в полезную информацию. Поэтому прямой доступ к уровню корпоративного хранилища данных ограничен опытными пользователями, которые хотят использовать собственные запросы и которым нужны сырые данные для этих целей. Большинство же конечных пользователей будут использовать информационные витрины для доступа к подготовленной информации, которую они могут напрямую использовать для выполнения своих задач.

Ещё одна проблема заключается в том, что большинство фронтенд-инструментов, используемых бизнесом для анализа информации, предоставляемой хранилищем данных, не могут напрямую использовать структуры Data Vault. Например, построение OLAP-куба в Microsoft SQL Server Analysis Services (SSAS) лучше всего работает, если источник данных смоделирован в виде звёздной схемы, которая является реляционной версией Dimension модели.

Многомерное моделирование было представлено широкой аудитории в индустрии хранилищ данных Ральфом Кимбаллом в 1997 году. Однако он не был его изобретателем. Термины «размерности» и «факты», которые являются основными конструкциями в многомерном моделировании, восходят к 1960-м годам, когда проводился совместный исследовательский проект между Дартмутским университетом и General Mills. Первая размерная модель (dimension model) была представлена компаниями AC Nielsen и IRI для описания ранних многомерных витрин данных для данных о розничных продажах. Но именно серия книг Ральфа Кимбалла способствовала популяризации размерного/многомерного моделирования в индустрии хранилищ данных, и оно стало стандартом моделирования. В результате многомерное моделирование поддерживается многими фронтенд-инструментами сегодня. Поэтому оно хорошо известно и понятно конечным пользователям и является оптимальным выбором для моделирования информационных витрин, которые служат в качестве фронтенд-слоя.

Введение

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

• Как изменялась степень загрузки на определённых рейсах за последний финансовый год?
• Какова эффективность нашей бонусной программы для часто летающих пассажиров в отношении продаж?
• Кто наши часто летающие пассажиры? Каков их средний объём продаж?

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

По всем этим причинам имеет смысл организовать данные в слое информационных витрин (information mart) таким образом, чтобы бизнес-пользователи могли быстро агрегировать информацию, а не быстро её модифицировать. Именно поэтому размерная модель (dimensional model) проектируется с учётом того, как измеряются данные. Поскольку метрики (measurement) часто основаны на бизнес-процессе, сам бизнес-процесс должен быть центром моделирования. Кроме того, необходим контекст, чтобы придать метрикам смысл, например, чтобы упорядочить метрики по аэропортам, как показано в Таблице 7.1.

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

В этой таблице представлено одна метрика — число лиц, которые были либо пассажирами, либо провожающими/встречающими, либо работниками, либо посетителями аэропорта, выраженное в виде соотношения между этими четырьмя ролями. Четыре роли — это первое измерение (dimension), а аэропорт — второе. Обе размерности охватывают данные и определяют уровень детализации для подсчёта лиц.

Эти две фундаментальные концепции — метрики (measurements) и контекст (context) — являются основой размерного моделирования.

Схема «Звезда» (Star Schemas)

Когда размерная модель реализована в реляционной базе данных, она называется звёздной схемой. Это объясняется тем, что размерная модель реляционных таблиц при взгляде сверху выглядит как звезда (см. Рисунок 7.1).

Рисунок 7.1 Пример схемы «Звезда» для посещений аэропортов (физическая реализация)

Исходный рисунок (в плохом качестве)

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

Основное отличие схемы «Звезда» на Рисунке 7.1 от нормализованной модели в третьей нормальной форме (3NF), которая часто используется в операционных системах, заключается в том, что размерная модель обычно использует денормализованные таблицы, особенно:

• Таблицы Фактов: таблица в центре этой схемы содержит метрики/меры/показатели бизнеса, которые в случае Рисунка 7.1 представляют собой транзакции полётов. Эти measurements, как правило, являются метриками, которые бизнес желает проанализировать.
• Таблицы Измерений: таблицы размерностей группируют факты по категориям и предоставляют дополнительные описательные атрибуты к этим категориям. Эти категории называются размерностями и помогают конечному пользователю ориентироваться в модели и выбирать только нужное подмножество данных для анализа.

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

Это связано с денормализацией, которая обычно происходит при преобразовании модели 3NF в размерную модель. Иерархии и справочники предобъединены, что требует от оптимизатора СУБД учитывать меньшее количество объединений и временных таблиц. Также становится проще агрегировать данные, поскольку все измерения уже содержатся в центральной таблице фактов. Некоторые редакции Microsoft SQL Server также поддерживают оптимизацию звёздного объединения (star join optimization), функцию, которая значительно сокращает объём данных, считываемых с диска для ответа на запросы.

Следующие разделы более подробно объясняют основные сущности размерного моделирования и звёздных схем.

Таблицы фактов (Fact Tables)

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

В других случаях таблицы фактов могут содержать отношения между бизнес-объектами, например, уровни запасов на определённые даты. Эти уровни запасов являются формой отношений, потому что они показывают, какой продукт доступен в каком складском расположении в определённый момент времени. Каждое такое отношение представлено в таблице фактов одной записью. На рисунке 7.2 показан пример таблицы фактов, представляющей рейс.

Рисунок 7.2 Таблица фактов для рейсов (физическая модель)

Таблица фактов содержит два разных типа столбцов:

• Во-первых, внешние ключи на таблицы измерений, которые рассматриваются в следующем разделе. Сюда входят все четыре ссылки, которые являются частью составного первичного ключа, а также TailNumberKey, CancelledKey и DivertedKey.
• Во-вторых, значения измерений, сами факты. Многие из них указывают продолжительность задержек, например, DepartureDelay, WeatherDelay или SecurityDelay. Другие показывают продолжительность подпроцессов, например, время руления при въезде и выезде, время в полёте и пройденное расстояние.

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

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

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

Гранулярность таблицы фактов (Grain of a Fact Table)

Количество ссылок на измерения в таблице фактов определяет уровень детализации таблицы фактов. Этот уровень детализации называется гранулярностью (Grain).

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

Такой подход называется свёрткой (roll-up) и используется для обобщения данных по подмножеству измерений факта (subset of fact dimensions). Однако, хранение таблиц фактов на самом низком уровне гранулярности не всегда осуществимо, если серверная инфраструктура не предоставляет достаточных ресурсов для хранения самого низкого уровня детализации. В этом случае предварительная агрегация данных до более высокого уровня детализации обеспечивает более быстрые ответы бизнес-пользователям при прямом запросе к таблицам фактов. Обратите внимание, что это утверждение уже не актуально при использовании многомерных OLAP-кубов, потому что они агрегируют данные внутри куба прозрачно для конечного пользователя.

Таблицы размерностей/измерений (Dimension Tables)

Измерения/Размерности/Dimensions (а значит, и реляционные таблицы размерностей) предоставляют контекст для фактов. Они очень важны для понимания хранилища данных. Без измерений (dimensions) невозможно было бы понять метрики, предоставляемые таблицей фактов, потому что все метки и прочая описательная информация берутся из таблиц измерений. Как уже объяснялось в предыдущем разделе, они также используются для определения, как факты будут агрегироваться (сворачиваться). Кроме того, они могут использоваться для фильтрации фактов в соответствии с записью dimension или одним из её описательных атрибутов. Также возможно сортировать агрегированные метрики по измерению или одному из её атрибутов. На рисунке 7.3 показан пример таблицы размерности.

Рисунок 7.3 Таблица измерений пассажиров (физическая модель)

В отличие от таблиц фактов, таблица измерения использует значение ключа PassengerKey в качестве первичного ключа таблицы. Это связано с тем, что этот ключ часто используется в таблице фактов, ссылающейся на таблицу измерения. Чтобы сократить объём необходимого хранилища и повысить производительность соединений, имеет смысл поступать именно так и избегать использования натурального ключа. В остальном этот ключ не имеет значения для бизнеса. В дополнение к этому техническому ключу Измерения (Dimensions) часто содержат бизнес-ключи, которые идентифицируют записи в таблице dimension. На рисунке 7.3 это атрибут PassportNumber. Записи часто представляют собой бизнес-объекты и изменения этих объектов в операционной системе. Хотя натуральный ключ для одного и того же бизнес-объекта остаётся неизменным, даже если описательные данные были изменены в операционной системе, ключ изменяется при каждом изменении данных. Этот эффект используется таблицей фактов для ссылки на версию данных, которая была активна в момент, когда произошло бизнес-событие. Хеш-ключ из модели Data Vault 2.0 используется в качестве ключа в многомерной модели. Это упрощает процесс загрузки и помогает виртуализировать информационные витрины.

Несмотря на ключи в таблице, таблица измерения содержит описательные данные, которые описывают dimension entry (сущность измерения). Очень часто таблицы размерностей состоят из множества описательных атрибутов. Их количество может достигать 50 или 100 столбцов. С другой стороны, такие таблицы часто не содержат большого количества строк. Существуют некоторые размерности, такие как размерность Passenger, представленная на рисунке 7.3, которые могут содержать много записей, но большинство измерений довольно малы, содержащие, возможно, не более сотни записей.

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

• Полностью аддитивные меры (Fully additive measures): полностью аддитивны в том смысле, что такие значения, как суммы и количества, могут быть просуммированы до допустимого общего значения.
• Полуаддитивные меры (Semi-additive measures): могут быть просуммированы по некоторым доступным размерностям, но не по всем.
• Неаддитивные меры (Nonadditive measures): не поддаются сложению.

Таким образом, это также зависит от бизнес-потребностей, станет ли атрибут мерой в таблице фактов или описательным атрибутом в одной из её размерностей.

Запросы к схемам «звезда»

Конечные пользователи, знакомые со схемами типа «звезда», часто следуют простой схеме при прямом запросе данных из размерной модели:

• Выбор необходимых фактов: сначала конечный пользователь решает, какие факты следует выбрать, определяя используемые таблицы фактов.
• Выбор необходимых измерений: добавляя размерности к запросу через соединения (join), конечные пользователи добавляют необходимый контекст.
• Ограничение области фактов: факты фильтруются в соответствии со значениями измерений (либо из таблицы фактов по ключам, либо из присоединённых размерностей).
• Агрегация фактов: исходные факты агрегируются с помощью агрегатных функций, таких как SUM() или COUNT().

Поскольку такой подход настолько распространён, многие производители СУБД оптимизировали свои реляционные движки под подобные запросы, включая Microsoft за счёт поддержки оптимизации соединений типа «звезда».

Следующий оператор может быть использован для запроса к таблице фактов на рисунке 7.2:

SELECT
    OriginAirport.Code, AVG(DepartureDelay)
FROM 
    FactFlight
INNER JOIN
    DimAirport OriginAirport ON OriginAirport.AirportKey = FactFlight.OriginAirportKey
WHERE
    OriginAirport.State = 'CA'
GROUP BY
    OriginAirport.Code

Этот оператор сначала соединяет таблицу измерений DimAirport с таблицей фактов, используя OriginAirportKey. Обратите внимание, что таблица DimAirport может быть использована дважды:

• сначала для аэропорта отправления,
• затем для аэропорта назначения.

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

Оператор также показывает, как отдельные части SQL-оператора используются в запросах к Dimension модели:

• Оператор SELECT определяет меры и размерности, которые должны быть представлены конечному пользователю. Также указываются любые формулы, включая агрегатные функции, которые должны быть применены к результату.
• Оператор FROM определяет таблицу фактов, к которой выполняется запрос. Во многих случаях это только одна таблица фактов. Однако также возможно выполнение запроса к нескольким таблицам фактов.
• Оператор JOIN присоединяет контекст фактов к итоговому результату. Во многих случаях имеется несколько операторов JOIN, каждый из которых соединяет отдельную таблицу измерения.
• Оператор WHERE ограничивает область фактов, используемых в результирующем наборе. Во многих случаях доступны данные из дополнительных записей размерности (например, регионы продаж), которые не имеют отношения к выполняемой задаче. Поэтому конечные пользователи обычно ограничивают данные интересующими их записями размерностей.
• Оператор GROUP BY определяет, как данные группируются перед агрегацией и представлением конечному пользователю. Агрегация в операторе SELECT основана на этом GROUP BY. Таким образом, оператор GROUP BY используется для изменения гранулярности (grain) результата по сравнению с гранулярностью исходной таблицы фактов.

Хотя оператор GROUP BY может использоваться для повышения уровня гранулярности фактов, невозможно получить результат с более низким уровнем гранулярности. Рассмотрим таблицу фактов, содержащую данные об итогах рейсов: количество пассажиров на борту, аэропорт отправления и назначения, дата рейса и т.д. Если таблица фактов не содержит информации на уровне пассажиров, проанализировать такую информацию невозможно. Поэтому важно правильно выбрать гранулярность таблицы фактов при проектировании многомерной модели данных.

Несколько звёзд (Multiple Stars)

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

Согласованные размерности/измерения (Conformed Dimensions)

Согласованные измерения — это размерности, которые используются несколькими звёздами. Они применяются для сравнения мер из каждой схемы звезда. Повторное использование согласованных размерностей является очень распространённым для «поддержки подлинного анализа бизнес-процессов в разных областях». Это возможно только в том случае, если все схемы звезда, которые должны анализироваться в рамках такого сквозного анализа, используют одну и ту же таблицу измерений с точно такими же значениями ключей (первичными ключами). Использование хеш-ключей из модели Data Vault 2.0 упрощает соблюдение этого требования. Такой анализ называется drill-across и объединяет информацию из нескольких бизнес-процессов или событий. Только тогда становится возможным анализ данных из различных таблиц фактов с помощью согласованного измерения. На рисунке 7.4 приведён пример.

Рисунок 7.4 Две схемы звезда, соединённые согласованными измерениями (физический дизайн)

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

В этом примере имеются две схемы звезда с их таблицами фактов в центре:
FactConnection слева и FactAirportVisit с рисунка 7.1 — справа. Каждая из них имеет ряд подключённых измерений. Обе используют две общие таблицы согласованных измерений — DimAirport и DimDate, которые показаны в центре схемы. Для поддержки сквозного анализа между FactConnection и FactAirportVisit крайне важно, чтобы обе согласованные размерности имели абсолютно одинаковую структуру и данные.

Чтобы поддерживать такие согласованные размерности, необходимо, чтобы любые изменения в согласованной размерности не нарушали работу одной из размерных звёзд, использующих эту размерность. Это может — и, скорее всего, произойдёт — на последующих спринтах проекта. Всякий раз при изменении структуры или содержания согласованной размерности необходимо пересмотреть влияние на каждую зависимую схему звезда и провести соответствующее тестирование. Поэтому использование согласованных размерностей влечёт за собой влияние изменений, которое может ограничить гибкость команды разработки. Этот избыточный объём сопровождения согласованных размерностей часто приводит к практике, при которой разработчики не изменяют существующие согласованные размерности, чтобы избежать тестирования. Вместо этого они создают новые дополнительные согласованные размерности, чтобы избежать затрат на переинжиниринг, что приводит к несогласованным размерностям. В других случаях они копируют структуру и данные существующих согласованных размерностей в новые схемы звезда и расширяют их новыми функциями, оставляя старую согласованную размерность без изменений (и, следовательно, без необходимости тестирования), снова добавляя несогласованные размерности. Мы называем эту практику «dimension-itis», что приводит к неконтролируемому количеству размерностей, которые вроде бы одинаковые, но… несогласованные.

Обратная практика — это добавление большего количества атрибутов и данных в существующие согласованные размерности, чтобы избежать создания новых. Этот подход применяется, когда разработчики хотят избежать создания новых согласованных размерностей из-за объёма необходимого тестирования существующих фактов и измерений. Конечный результат такого подхода — так называемая «деформированная» размерность (“deformed” dimension): такая размерность не может больше устойчиво изменяться из-за неясных и неконтролируемых изменений в структуре и сложных или запутанных зависимостей, и становится кошмаром с огромными затратами на переинжиниринг при необходимости изменений в будущем. Команды, создающие такие деформированные размерности, как правило, избегают их документирования, что создаёт дополнительные сложности для их преемников.

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

Проектирование измерений (Dimension Design)

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

Медленно изменяющиеся измерения (Slowly Changing Dimensions, SCD)

До этого момента измерения (dimensions) рассматривались как сущности, обеспечивающие контекст для фактов. Это верно, но важно понимать, что этот контекст со временем меняется. Например, домашний адрес пассажиров может изменяться из-за переезда, фамилия — из-за брака, а обращение — из-за исправления ошибки. Поскольку связь между схемой звезда и измерением основана на значениях ключей, модель может учитывать изменения в системе-источнике наилучшим образом для удовлетворения требований анализа: изменения могут либо отслеживаться внутри измерения, либо перезаписывать существующие данные в измерении.

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

Slowly Changing Dimension Type 0 (Медленно изменяющееся измерение Типа 0) сохраняет исходные значения атрибутов измерения. Если в системе-источнике происходит изменение, значение в таблице измерений не изменяется. Хотя этот тип встречается реже, чем следующие три, он может использоваться для хранения исходного кредитного рейтинга клиента или любого другого первоначального значения.

Изменения в системе-источнике перезаписывают данные в Slowly Changing Dimension Type 1 (Медленно изменяющемся измерении Типа 1). Атрибут измерения всегда отражает наиболее актуальное значение. Следовательно, история не отслеживается. Если на этом атрибуте основана агрегация (например, в предложении GROUP BY оператора), результаты этих агрегаций будут меняться в зависимости от нового значения. В таблице 7.2 приведён пример SCD типа 1.

Таблица 7.2 Медленно изменяющаяся размерность типа 1

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

Вместо перезаписи существующих данных, изменения в системе-источнике добавляют новую строку в таблицу Slowly Changing Dimension Type 2 (Медленно изменяющееся измерение Типа 2). Используя такой подход, часто можно корректно отслеживать историю. Поэтому это является преобладающей техникой отслеживания истории в информационных витринах. Пример размерности типа 2 представлен в таблице 7.3.

Таблица 7.3. Медленно изменяющаяся размерность типа 2

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

В этом примере Эми Миллер, с ключом 1b3ba82..., вышла замуж за Петера Хайнца, с ключом 28ab342..., и переехала к нему в Калифорнию. Поэтому её новая запись с ключом 444bbaa... отражает эти изменения. Старая запись остаётся нетронутой, чтобы сохранить историческую информацию. Старые факты продолжают использовать запись с ключом 1b3ba82..., но новые факты ссылаются на запись размерности с ключом 444bbaa....

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

Таблица 7.4. Медленно изменяющаяся размерность типа 3

Этот пример показывает, как бизнес отслеживает предыдущее состояние пассажира с помощью дополнительного столбца. Когда пассажир переезжает, как в случае с Эми Миллер (теперь Эми Хайнц) в записи с ключом 1b3ba82..., старый адрес перезаписывается, а атрибуты, которые должны быть исторически отслежены, копируются в дополнительные столбцы. В данном случае столбец Previous State обновляется, чтобы отразить предыдущее состояние пассажира.

История не ограничивается только одной записью. Обычно используется ограниченное количество столбцов для хранения нескольких изменений — в большинстве случаев только текущего и предыдущего значения. В других случаях ключевые показатели эффективности (KPI) отслеживаются со временем, как в примере в таблице 7.5.

Таблица 7.5. Медленно изменяющаяся размерность типа 3 с несколькими столбцами

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

В дополнение к представленным типам размерностей, в некоторых случаях встречаются и следующие:

• Slowly changing dimension type 4 (Медленно изменяющаяся размерность типа 4): этот тип выносит изменчивые атрибуты в отдельную мини-размерность.
• Slowly changing dimension type 5 (Медленно изменяющаяся размерность типа 5): гибрид типов 4 и 1 (4 + 1 = 5). Позволяет получить доступ к текущим атрибутам мини-размерности вместе с другими из основной размерности без связывания через таблицу фактов.
• Slowly changing dimension type 6 (Медленно изменяющаяся размерность типа 6): этот тип добавляет текущие атрибуты к размерности типа 2.
• Slowly changing dimension type 7 (Медленно изменяющаяся размерность типа 7): этот тип обеспечивает ту же функциональность, что и тип 6, но с использованием двух внешних ключей в таблице фактов: один ссылается на размерность типа 2 с отслеживаемыми атрибутами, а другой — на текущую строку.

Иерархии

Иерархии (Hierarchies) — ещё одна важная концепция в размерном моделировании. Они позволяют производить детализацию данных для более глубокого анализа. Рассмотрим следующий пример:
В Excel PivotTable представлена мировая выручка от пассажиров за несколько лет в виде общих значений (см. рисунок 7.5).

Рисунок 7.5 Выручка от пассажиров по годам и регионам

Столбцы на рисунке 7.5 показывают финансовые годы (FY) из размерности даты, доступные в сводной таблице. Строки отображают географические регионы из размерности географии. Кроме того, присутствуют общие итоги, показывающие совокупное значение для каждого столбца или строки. Например, выручка от пассажиров за финансовый год 2008 в Соединённых Штатах составила $19,471,989.04.

Географическая иерархия состоит из следующих уровней:

• Страна
• Штат/Провинция
• Город
• Почтовый индекс

Возможно выполнение детализации (drill-down) до любого уровня, который доступен в сводной таблице (которая основана на OLAP-кубе), но не глубже. Рисунок 7.6 показывает логическую модель, в которой представлена размерность географии с её иерархией.

Рисунок 7.6 Размерность географии (логическая модель)

Обозначения следуют методологии моделирования ADAPT (Application Design for Analytical Processing Technologies) для размерных баз данных. Эта методология часто используется в индустрии для моделирования и документирования размерных моделей. Первый элемент изображает саму размерность Geography. Размерность включает одну иерархию, также называемую Geography. Остальные элементы представляют собой отдельные уровни иерархии и должны следовать в указанном порядке. Мы будем использовать методологию моделирования ADAPT на протяжении всей книги.

Аналогично иерархии Geography, иерархия Fiscal Calendar состоит из нескольких уровней:

• Финансовый год
• Финансовое полугодие
• Финансовый квартал
• Месяц
• Дата

Эта иерархия очень распространена в системах хранилищ данных и часто используется конечными пользователями. Она использует другую дату начала года, что часто практикуется коммерческими организациями. Например, предприятия в сфере торговли часто начинают финансовый год не с 31 декабря. Это связано с большим числом возвратов после Рождества, совершаемых клиентами, недовольными подарками. Поскольку объём таких возвратов достаточно велик, он оказывает влияние на общую выручку за год. Однако в большинстве случаев возвраты происходят в январе следующего календарного года. Если компания закрывает отчётный год 31 декабря, возвраты будут отнесены к следующему финансовому периоду и исказят финансовые результаты. Поэтому такие компании часто выбирают другой месяц в качестве окончания финансового периода. Один из примеров — Best Buy, розничный продавец электроники в США. Финансовый год этой компании заканчивается 1 февраля. Рисунок 7.7 показывает логическую модель размерности Date.

Рисунок 7.7 Размерность даты (логическая модель)

Обратите внимание, что в размерности доступны две иерархии: Calendar и Fiscal Calendar. Обе имеют свои собственные уровни Год, Полугодие и Квартал, но разделяют уровни Месяц и Дата. Обе иерархии используют все атрибуты размерности, но организованы по-разному. В зависимости от потребностей бизнес-аналитика используется та или иная иерархия. Обе являются корректными; ценность каждой иерархии зависит от контекста бизнес-анализа.

Чтобы более подробно проанализировать информацию на рисунке 7.5, можно нажать знак «плюс» рядом с меткой строки и выполнить детализацию по иерархии географии, как показано на рисунке 7.8.

Рисунок 7.8 Выручка от пассажиров в Соединённых Штатах по годам

Общая выручка от пассажиров, которая всё ещё отображается в строке, выделенной полужирным шрифтом, разбивается по штатам — следующий географический уровень ниже уровня страны. Для каждого штата показывается выручка от пассажиров по годам. Можно дополнительно разбить эти данные, выполнив детализацию до следующего уровня (рисунок 7.9).

Рисунок 7.9 Выручка от пассажиров в штате Алабама по годам

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

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

Рисунок 7.10 Выручка от пассажиров в Алабаме по годам, в деталях

Иерархия географии реализована физически из таблицы размерности, как показано на рисунке 7.11.

Рисунок 7.11 Размерность географии (физическая модель)

Каждый уровень иерархии основан на одном из физических атрибутов таблицы размерности. Связь между атрибутом и уровнем иерархии задаётся в Microsoft SQL Server Analysis Services. Аналогичные иерархии будут реализованы в этой главе при построении OLAP-куба и добавлении размерности даты как иерархии.

Дизайн «Снежинка» (Snowflake Design)

В этой главе была представлена схема «звезда», основанная на таблице фактов в центре и сопровождающих её таблицах размерностей, которые предоставляют контекст для фактов. Эти таблицы измерений напрямую соединяются с таблицей фактов. Косвенное соединение таблиц измерений — то есть, когда одна таблица измерения ссылается на другую таблицу измерения — невозможно в схеме звезда. Это справедливо даже в случае наличия связи между атрибутами измерений.

Рассмотрим пример корпоративных групп в авиационной индустрии и отдельных авиаперевозчиков. Каждая авиакомпания входит в состав более крупной группы, которая владеет этим перевозчиком. Например, United Continental Holdings, Inc. владеет как United Airlines, так и Continental Airlines, а также другими, более мелкими перевозчиками.

Если схема звезда должна отразить эту связь, обе размерности — DimGroup и DimCarrier — должны быть напрямую связаны с таблицей фактов, как показано на рисунке 7.12.

Рисунок 7.12 Схема звезда с таблицей фактов в центре и только напрямую связанными размерностями (физическая модель)

Этот пример повторяет представленный на рисунке 7.4. Однако он показывает только одну схему звезда. Обратите внимание на две размерности DimGroup и DimCarrier, которые независимо связаны с таблицей фактов. Тем не менее, между этими двумя размерностями существует неявная связь. Эта связь реализована в ETL-задании, которое загружает таблицу. ETL-задание гарантирует, что в таблицу фактов загружаются только допустимые комбинации CarrierKey и GroupKey. Модель не реализует никаких правил, которые препятствовали бы загрузке недопустимых комбинаций. С другой стороны, эта модель проста в использовании для бизнес-пользователей, потому что они могут напрямую соединять всю необходимую контекстную информацию. Именно поэтому схема звезда допускает только напрямую связанные таблицы измерений.

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

SELECT
    DimGroup.Name, AVG(DepDelay)
FROM 
    FactConnection
INNER JOIN
    DimGroup ON DimGroup.GroupKey = FactConnection.GroupKey
GROUP BY
    DimGroup.Name

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

Схема «снежинка», с другой стороны, допускает косвенные таблицы измерений. Это полезно, если необходимо явно смоделировать отношения между атрибутами измерений. Если бы модель на рисунке 7.12 была реализована как схема «снежинка», она выглядела бы примерно как на рисунке 7.13.

Рисунок 7.13 Схема снежинка с таблицей фактов в центре и косвенно связанными измерениями (физическая модель)

Как видно из диаграммы, термин «снежинка» происходит от внешнего вида модели. Таблицы измерений отходят от центральной таблицы фактов, подобно лучам снежинки. Вместо того чтобы напрямую ссылаться на DimGroup из FactConnection, группа ссылается косвенно через DimCarrier. GroupKey, который идентифицирует группу в таблице фактов, перемещён в DimCarrier. Чтобы вернуть среднюю задержку группы, как в предыдущем запросе, необходимо сначала соединить DimCarrier, а затем DimGroup.

Это не представляет проблемы, если вы умеете писать SQL-запросы и не испытываете трудностей при косвенном соединении таблиц, как в этом случае. Для опытного разработчика баз данных такой запрос не представляет никакой угрозы. Однако если бизнес-аналитики с меньшими знаниями и опытом работы с SQL-запросами должны работать со схемами снежинка, они могут почувствовать себя перегруженными и не справиться с базой данных.

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

Сообщение Перевод 7 Главы — Dimensional Modeling (Data Vault 2.0) появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Эта статья частично пересекается со статьей Понимание инкрементальных стратегий 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.