Размерное моделирование в конвейерах Lakeflow

Размерное моделирование — это метод организации данных золотого слоя в таблицы фактов и таблицы измерений, чтобы аналитики и инструменты бизнес-аналитики (BI) могли эффективно выполнять запросы к ним. На этой странице объясняется, как построить эту модель с помощью конвейеров Lakeflow.

Overview

Размерное моделирование разделяет данные на два типа таблиц:

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

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

В трубопроводах Lakeflow схема звёзд естественным образом вписывается в золотой слой архитектуры медальона. Бронзовые и серебряные наборы данных отвечают за загрузку и очистку данных, а золотые материализуют таблицы фактов и измерений, чтобы последующие потребители данных могли запрашивать их напрямую. Поскольку конвейер постепенно обновляет эти таблицы, вы получаете простоту запроса, как в схеме звёзд, без отдельного шага извлечения, преобразования, загрузки (ETL) на уровне BI.

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

Вы строите измерения и факты как наборы данных в вашем конвейере, выбирая тип набора данных, который соответствует тому, как каждый из них меняется. Для большинства моделей с золотым слоем:

  • Создавайте таблицы измерений как материализованные представления (или как потоковые таблицы с медленно меняющимися измерениями типа 2 (SCD Type 2), если требуется хранить историю). Материализованное представление эффективно пересчитывается на основе очищенных данных серебряного уровня по мере изменения входных данных, формируя по одной строке на каждую бизнес-сущность.
  • Постройте таблицы фактов как потоковые таблицы, постепенно питающиеся из серебра, чтобы агрегаты золотого слоя оставались близки к реальному времени. Факты ссылаются на свои измерения по ключу, а не дублируют описательные атрибуты.

Дополнительные сведения о двух типах наборов данных см. в разделах Материализованные представления и Потоковые таблицы. Чтобы отслеживать историю в измерении, см. API AUTO CDC: упрощение захвата изменений данных с использованием конвейеров.

Ключи и заместительные ключи

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

Если вам действительно нужен суррогатный ключ, избегайте суррогатного ключа на основе hash, такого как sha2(natural_key). Хэш является намеренно случайным, что плохо влияет на ликвидную кластеризацию и производительность Z-порядка, потому что физически соседние строки разбросаны по файлам. Вместо этого детерминированно получайте суррогат с сохранением порядка из стабильного естественного ключа, чтобы одна и та же бизнес-сущность всегда отображалась в один и тот же суррогат. Детерминированный ключ сохраняется после полного обновления или перестройки измерения, что сохраняет существующие соединения между фактами и измерениями нетронутыми.

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

Размеры дат

Создайте dim_date как простое материализованное представление, сгенерированное с помощью sequence() и explode() в пределах диапазона дат, а не загруженное из источника. Это статические эталонные данные, недорогие в вычислении, и они упрощают соединения и окна на основе даты во всех остальных частях модели.

Примеры

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

Таблица измерения

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

Python

from pyspark import pipelines as dp

@dp.materialized_view(name="dim_customer", comment="Customer dimension")
def dim_customer():
    return (
        spark.read.table("customers_silver")
        .select("customer_id", "customer_name", "region", "signup_date")
    )

SQL

CREATE OR REFRESH MATERIALIZED VIEW dim_customer
COMMENT "Customer dimension"
AS SELECT customer_id, customer_name, region, signup_date
FROM customers_silver;

Таблица фактов

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

Python

from pyspark import pipelines as dp

@dp.table(name="fact_orders", comment="One row per order line, keyed to dimensions")
def fact_orders():
    return (
        spark.readStream.table("orders_silver")
        .select(
            "order_id",
            "customer_id",       # foreign key to dim_customer
            "product_id",        # foreign key to dim_product
            "order_date",        # foreign key to dim_date
            "quantity",
            "amount",
        )
    )

SQL

CREATE OR REFRESH STREAMING TABLE fact_orders
COMMENT "One row per order line, keyed to dimensions"
AS SELECT
  order_id,
  customer_id,   -- foreign key to dim_customer
  product_id,    -- foreign key to dim_product
  order_date,    -- foreign key to dim_date
  quantity,
  amount
FROM STREAM(orders_silver);

Лучшие практики

Несколько рекомендаций помогают поддерживать схему «звезда» в хорошем состоянии по мере её развития:

  • Храните факты в виде потоковых таблиц, а измерения — в виде материализованных представлений, если только вам не нужна история изменений; в этом случае используйте AUTO CDC с STORED AS SCD TYPE 2. См . API AUTO CDC: упрощение отслеживания изменений с помощью конвейеров.
  • Используйте внешние BI-инструменты, чтобы напрямую обращаться с запросами к материализованным представлениям уровня Gold. Пайплайны Lakeflow постепенно обновляют их, поэтому вы получаете результаты почти в реальном времени без отдельного этапа отчётности по ETL.
  • Размеры и факты модели как отдельные переходят в один и тот же золотой слой, поэтому каждый набор данных можно планировать, проверять и обновлять в рамках единого когерентного DAG. См. Поэтапная загрузка и обработка данных с помощью потоков конвейера Lakeflow.

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

  • Last updated on