Modelagem dimensional em pipelines do Lakeflow

Modelagem dimensional é uma técnica para organizar seus dados da camada dourada em tabelas de fatos e tabelas de dimensões, para que analistas e ferramentas de inteligência de negócios (BI) possam consultá-los de forma eficiente. Esta página explica como construir esse modelo com pipelines do Lakeflow.

Overview

A modelagem dimensional separa os dados em dois tipos de tabelas:

  • Tabelas de fatos guardam os eventos ou medidas que você valoriza, como pedidos, cliques ou promoções. Cada linha é uma ocorrência desse evento, descrita principalmente por chaves e medidas numéricas.
  • Tabelas de dimensões guardam o contexto descritivo desses eventos, como clientes, produtos ou datas. Cada linha corresponde a uma entidade de negócios.

Um esquema em estrela é a forma que você obtém quando coloca uma tabela de fatos no meio e a conecta a várias tabelas de dimensões através das chaves delas. O layout é fácil para analistas e ferramentas de BI consultarem e fácil para engenheiros raciocinarem, porque cada tabela tem uma responsabilidade única e clara.

Nos pipelines do Lakeflow, o esquema em estrela se encaixa naturalmente na camada ouro da arquitetura de medalhão. Conjuntos de dados bronze e prata gerenciam a ingestão e a limpeza, e o ouro materializa suas tabelas de fatos e dimensões para que os consumidores downstream os consultem diretamente. Como o pipeline mantém essas tabelas atualizadas incrementalmente, você obtém a simplicidade de consulta de um esquema estrela sem uma etapa separada de extração, transformação, carregamento (ETL) na camada BI.

Como funciona

Você constrói dimensões e fatos como conjuntos de dados no seu pipeline, escolhendo o tipo de conjunto que corresponde a como cada um muda. Para a maioria dos modelos de camada de ouro:

  • Construa tabelas de dimensões como vistas materializadas (ou como tabelas de streaming com dimensão que muda lentamente (SCD) Tipo 2 quando precisar de histórico). Uma visualização materializada recalcula eficientemente a partir dos seus dados prata limpos conforme as entradas mudam, dando a você uma linha por entidade empresarial.
  • Construa tabelas de fatos como tabelas de streaming alimentadas incrementalmente a partir da prata, para que os agregados da camada ouro permaneçam próximos ao tempo real. Os fatos referenciam suas dimensões por chave, em vez de duplicar atributos descritivos.

Para mais informações sobre os dois tipos de conjuntos de dados, veja Visualizações materializadas e tabelas de streaming. Para acompanhar o histórico em uma dimensão, consulte As APIs AUTO CDC: simplifique a captura de dados de alterações com pipelines.

Chaves e chaves substitutas

Prefira chaves naturais (um identificador que já existe nos dados de origem, como um número de ordem) onde a chave natural da fonte é estável e utilizável, porque ela se agrupa e se junta bem. Só procure uma chave substituta (um identificador substituto gerado pelo pipeline) quando uma fonte reutiliza ou altera IDs.

Quando você realmente precisar de uma chave substituta, evite uma chave substituta baseada em hash, como sha2(natural_key). Um hash é intencionalmente aleatório, o que é ruim para o agrupamento líquido e para o desempenho da ordenação Z, porque linhas fisicamente adjacentes acabam dispersas pelos arquivos. Em vez disso, gere de forma determinística uma chave substituta que preserve a ordem a partir da chave natural estável, de modo que a mesma entidade de negócios sempre mapeie para a mesma chave substituta. Uma chave determinística sobrevive a uma atualização completa ou reconstrução da dimensão, que mantém intactas as uniões existentes entre fatos e dimensões.

Alternativamente, você pode usar uma coluna IDENTITY quando a tabela upstream receber apenas acréscimos e nunca for atualizada por completo. Como os valores IDENTITY são atribuídos à medida que as linhas são inseridas, uma reconstrução pode reatribuir IDs diferentes à mesma entidade e comprometer silenciosamente as junções entre fatos e dimensões que continham os valores antigos.

Dimensões de data

Crie um dim_date como uma visualização materializada simples gerada com sequence() e explode() em um intervalo de datas, em vez de ingeri-lo de uma origem. São dados de referência estáticos, baratos de processar e simplificam junções e janelas com base em datas em todo o restante do modelo.

Exemplos

Os exemplos a seguir constroem um pequeno esquema estrela com uma dimensão do cliente e uma tabela de dados de pedidos.

Tabela de dimensões

Uma tabela de dimensões é tipicamente uma visualização materializada construída a partir de dados prata limpos, com uma linha por entidade comercial, conforme no código a seguir:

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;

Tabela de fatos

Uma tabela de fatos contém os eventos mensuráveis, referenciando dimensões por suas chaves em vez de duplicar atributos descritivos. Mantenha os fatos restritos (principalmente chaves e medidas numéricas) e use junções para extrair detalhes descritivos no momento da consulta, conforme no seguinte código:

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);

Práticas recomendadas

Algumas práticas mantêm um esquema estrela saudável à medida que cresce:

  • Mantenha os fatos como tabelas de streaming e dimensões como visualizações materializadas , a menos que você precise especificamente alterar o histórico, caso em que use AUTO CDC com STORED AS SCD TYPE 2. Consulte As APIs AUTO CDC: Simplifique a captura de dados de alterações com pipelines.
  • Use ferramentas de BI downstream para consultar diretamente as visualizações materializadas da camada ouro. Os pipelines do Lakeflow os mantêm atualizados de forma incremental, para que você obtenha resultados quase em tempo real sem uma etapa separada de ETL para relatórios.
  • Modele as dimensões e os fatos como fluxos separados na mesma camada ouro, para que cada conjunto de dados possa ser agendado, ter checkpoint salvo e ser atualizado como parte de um DAG coeso. Consulte Carregar e processar dados incrementalmente com fluxos de pipeline do Lakeflow.

Recursos adicionais

  • Last updated on