Modelação dimensional em pipelines do Lakeflow

A modelação dimensional é uma técnica para organizar os dados da camada dourada em tabelas de factos e tabelas de dimensões, para que analistas e ferramentas de inteligência de negócio (BI) possam consultá-los de forma eficiente. Esta página explica como criar esse modelo com pipelines do Lakeflow.

Overview

A modelação dimensional separa os dados em dois tipos de tabelas:

  • As tabelas de factos guardam os eventos ou medidas que lhe interessam, como encomendas, cliques ou promoções. Cada linha é uma ocorrência desse evento, descrita principalmente por chaves e medidas numéricas.
  • As tabelas de dimensões contêm o contexto descritivo em torno desses eventos, como clientes, produtos ou datas. Cada linha é uma entidade empresarial.

Um esquema em estrela é a configuração que se obtém quando se coloca uma tabela de factos no meio e se liga a várias tabelas de dimensões por meio das respetivas chaves. O layout é fácil de consultar para analistas e ferramentas de BI e fácil de raciocinar para engenheiros, porque cada tabela tem uma responsabilidade única e clara.

Nos pipelines Lakeflow, o esquema estrela encaixa-se naturalmente na camada dourada da arquitetura do medalhão. Conjuntos de dados de bronze e prata tratam da ingestão e limpeza, e o ouro materializa as suas tabelas de factos e dimensões para que os consumidores posteriores os consultem diretamente. Como o pipeline mantém essas tabelas atualizadas de forma incremental, obtém-se a simplicidade de consulta de um esquema estrela sem um passo separado de extração, transformação, carregamento (ETL) na camada BI.

Como funciona

Constróis dimensões e factos como conjuntos de dados no teu pipeline, escolhendo o tipo de conjunto que corresponde à forma como cada um muda. Para a maioria dos modelos de camada de ouro:

  • Constrói tabelas de dimensões como vistas materializadas (ou como tabelas de streaming com dimensão que muda lentamente (SCD) Tipo 2 quando precisares de história). Uma vista materializada recomputa eficientemente a partir dos seus dados de prata limpos à medida que os inputs mudam, dando-lhe uma linha por entidade empresarial.
  • Construir tabelas factuais como tabelas de streaming alimentadas incrementalmente a partir da prata, para que os agregados da camada de ouro permaneçam próximos do tempo real. Os factos referenciam as suas dimensões por chave, em vez de duplicar atributos descritivos.

Para mais informações sobre os dois tipos de conjuntos de dados, consulte Visualizações materializadas e tabelas de streaming. Para acompanhar o histórico numa dimensão, veja 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 se agrupa e junta bem. Só procura uma chave substituta (um identificador de substituição gerado pelo pipeline) quando uma fonte reutiliza ou altera IDs.

Quando precisar mesmo de uma chave de substituição, evite uma chave de substituição baseada em hash, como sha2(natural_key). Uma função hash é deliberadamente aleatória, o que é prejudicial ao agrupamento líquido e ao desempenho da ordenação Z, porque as linhas fisicamente adjacentes acabam dispersas por vários ficheiros. Em vez disso, derive-se deterministicamente um substituto que preserva a ordem a partir da chave natural estável, de modo que a mesma entidade empresarial corresponde sempre ao mesmo substituto. Uma chave determinística sobrevive a uma atualização ou reconstrução completa da dimensão, o que mantém intactas as uniões facto-dimensão existentes.

Em alternativa, pode utilizar uma coluna IDENTITY quando a tabela de origem apenas permite acrescentos e nunca é recriada por completo. Uma vez que os valores de IDENTITY são atribuídos quando as linhas são inseridas, uma reconstrução pode reatribuir IDs distintos à mesma entidade e comprometer silenciosamente as junções entre factos e dimensões que utilizavam os valores antigos.

Dimensões da data

Constrói uma dim_date como uma vista materializada simples gerada com sequence() e explode() sobre um intervalo de datas, em vez de a ingerir de uma fonte. São dados de referência estáticos, baratos de calcular, e simplificam as junções e janelas baseadas em datas em todo o resto do modelo.

Examples

Os exemplos seguintes constroem um pequeno esquema estrela com uma dimensão do cliente e uma tabela de factos de encomendas.

Tabela de dimensões

Uma tabela de dimensões é tipicamente uma vista materializada construída a partir de dados de prata limpos, com uma linha por entidade empresarial, conforme no seguinte código:

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 factos

Uma tabela de factos contém os eventos mensuráveis, referenciando as dimensões pelas suas chaves em vez de duplicar atributos descritivos. Mantenha os factos restritos (principalmente chaves e medidas numéricas) e use joins para extrair detalhes descritivos no momento da consulta, como 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);

Melhores práticas

Algumas práticas ajudam a manter um esquema em estrela saudável à medida que este cresce:

  • Mantém os factos como tabelas de streaming e as dimensões como vistas materializadas, a menos que precises especificamente de histórico de alterações, caso em que deves usar AUTO CDC com STORED AS SCD TYPE 2. Consulte As APIs do AUTO CDC: Simplifique a captura de dados de alteração com pipelines.
  • Utilize ferramentas de BI posteriores para consultar diretamente as vistas materializadas da camada gold. Os pipelines do Lakeflow mantêm-nos atualizados de forma incremental, pelo que obtém resultados quase em tempo real sem uma etapa ETL de criação de relatórios em separado.
  • Modelar dimensões e factos como fluxos separados para a mesma camada de ouro, para que cada conjunto de dados possa ser agendado, controlado e atualizado como parte de um DAG coerente. Veja Dados de carga e processamento incrementalmente com fluxos de oleodutos Lakeflow.

Recursos adicionais

  • Last updated on