Pular para o conteúdo principal
Última atualização em

Dimensional modeling in Lakeflow pipelines

Dimensional modeling is a technique for organizing your gold-layer data into fact tables and dimension tables so that analysts and business intelligence (BI) tools can query it efficiently. This page explains how to build that model with Lakeflow pipelines.

Visão geral​

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

  • Fact tables hold the events or measurements you care about, such as orders, clicks, or sales. Each row is one occurrence of that event, described mostly by keys and numeric measures.
  • Tabelas de dimensão mantêm o contexto descritivo em torno desses eventos, como clientes, produtos ou datas. Cada linha é uma entidade de negócios.

Um esquema em estrela é a forma que você obtém ao colocar uma tabela de fatos no meio e conectá-la a várias tabelas de dimensão por meio de suas chaves. A disposição é fácil para analistas e ferramentas de BI realizarem queries e fácil para engenheiros entenderem, porque cada tabela tem uma responsabilidade única e clara.

Nos Lakeflow pipelines, o esquema em estrela se encaixa naturalmente na camada ouro da arquitetura medallion. Os datasets bronze e silver lidam com a ingestão e limpeza, e o ouro materializa suas tabelas de fatos e de dimensão para que os consumidores downstream as consultem diretamente. Como o pipeline mantém essas tabelas atualizadas incrementalmente, você obtém a simplicidade de consulta de um esquema em estrela sem uma etapa separada de extrair, transformar, carregar (ETL) na camada de BI.

Como funciona​

Você cria dimensões e fatos como datasets em seu pipeline, escolhendo o tipo de dataset que corresponde à forma como cada um é alterado. Para a maioria dos modelos da camada Ouro:

  • Crie tabelas de dimensão como views materializadas (ou como tabelas de transmissão com dimensões que mudam lentamente (SCD) Tipo 2 quando precisar de histórico). Uma view materializada recomputa de forma eficiente a partir dos seus dados silver limpos à medida que as entradas mudam, fornecendo uma linha por entidade de negócio.
  • Crie tabelas de fatos como tabelas de transmissão alimentadas incrementalmente a partir da camada silver, para que os agregados da camada ouro permaneçam próximos ao tempo real. As tabelas de fatos referenciam suas dimensões por key em vez de duplicar atributos descritivos.

Para obter mais informações sobre os dois tipos de dataset, consulte Exibições materializadas e Tabelas de transmissão. Para rastrear o histórico em uma dimensão, consulte As APIs AUTO CDC: simplifique a captura de dados de alterações (CDC) com pipelines.

Chaves e chaves substitutas​

Prefira natural key (um identificador que já existe nos dados de origem, como um número de pedido) quando a natural key da origem for estável e utilizável, pois ela realiza clusters e join de forma eficiente. Utilize uma surrogate key (um identificador substituto gerado pelo pipeline) apenas quando uma origem reutilizar ou alterar IDs.

When you do need a surrogate key, avoid a hash surrogate such as sha2(natural_key). A hash is deliberately random, which is bad for liquid clustering and Z-order performance because physically adjacent rows end up scattered across files. Instead, derive an order-preserving surrogate deterministically from the stable natural key, so the same business entity always maps to the same surrogate. A deterministic key survives a full refresh or rebuild of the dimension, which keeps existing fact-to-dimension joins intact.

Alternativamente, você pode usar uma coluna IDENTITY quando a tabela upstream for apenas de acréscimo e nunca sofrer atualização completa. 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 quebrar silenciosamente os joins de fato-para-dimensão que carregavam os valores antigos.

Date dimensions​

Crie uma dim_date como uma view materializada simples gerada com sequence() e explode() em um intervalo de datas, em vez de ingeri-la de uma fonte. São dados de referência estáticos, baratos de compute, e isso simplifica joins baseados em data e janelamento em todo o restante do modelo.

Exemplos​

Os exemplos a seguir criam um pequeno esquema em estrela com uma dimensão de cliente e uma tabela de fatos de pedidos.

Tabela de dimensão​

A dimension table is typically a materialized view built from cleaned silver data, with one row per business entity, as in the following code:

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

Tabela de fatos​

A fact table holds the measurable events, referencing dimensions by their keys rather than duplicating descriptive attributes. Keep facts narrow (mostly keys and numeric measures) and use joins to pull in descriptive detail at query time, as in the following code:

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",
        )
    )

Práticas recomendadas​

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

  • Keep facts as streaming tables and dimensions as materialized views unless you specifically need change history, in which case use AUTO CDC with STORED AS SCD TYPE 2. See The AUTO CDC APIs: Simplify change data capture with pipelines.
  • Use ferramentas de BI downstream para consultar visualizações materializadas ouro diretamente. Os Lakeflow Pipelines os mantêm atualizados incrementalmente, para que você obtenha resultados em tempo real sem um passo de ETL de relatório separado.
  • Modele dimensões e fatos como fluxos separados na mesma camada ouro , para que cada dataset possa ser agendado, verificado e atualizado como parte de um DAG coerente. Consulte Carregar e processar dados gradualmente com fluxos de pipeline do LakeFlow.

Outros recursos​

Nesta página