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

Modelagem dimensional em LakeFlow Pipelines

A modelagem dimensional é uma técnica para organizar seus dados de camada de ouro em tabelas de fatos e tabelas de dimensões, de forma que analistas e ferramentas de Business Intelligence (BI) possam consultá-los com eficiência. Esta página explica como construir esse modelo com LakeFlow Pipelines.

Visão geral​

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

  • As tabelas de fatos armazenam os eventos ou métricas que lhe interessam, como pedidos, cliques ou vendas. Cada linha representa uma ocorrência desse evento, descrita principalmente por chaves e medidas numéricas.
  • 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.

Quando precisar de uma chave substituta, evite uma substituta hash como sha2(natural_key). Um hash é deliberadamente aleatório, o que é prejudicial para o desempenho de liquid clustering e Z-order, pois linhas fisicamente adjacentes acabam espalhadas por vários arquivos. Em vez disso, derive uma substituta que preserve a ordem deterministicamente a partir da chave natural estável, para que a mesma entidade de negócio sempre seja mapeada para a mesma substituta. Uma key determinística sobrevive a um refresh completo ou à reconstrução da dimensão, o que mantém intactos os joins existentes entre fatos e dimensões.

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.

Dimensões de data​

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​

Uma tabela de dimensão é normalmente uma materialized view criada a partir de dados silver limpos, com uma linha por entidade de negócio, como 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")
    )

Tabela de fatos​

Uma tabela de fatos contém os eventos mensuráveis, referenciando as 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 obter detalhes descritivos no momento da consulta, como no código a seguir:

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:

  • Mantenha os fatos como tabelas de transmissão e as dimensões como visualizações materializadas, a menos que você precise especificamente do histórico de alterações, 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 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