Modelado dimensional en tuberías de flujo de lago

El modelado dimensional es una técnica para organizar tus datos de la capa dorada en tablas de hechos y tablas dimensionales para que analistas y herramientas de inteligencia empresarial (BI) puedan consultarlos de forma eficiente. Esta página explica cómo construir ese modelo con tuberías Lakeflow.

Overview

El modelado dimensional separa los datos en dos tipos de tablas:

  • Las tablas de datos contienen los eventos o medidas que te interesan, como pedidos, clics o rebajas. Cada fila es una aparición de ese evento, descrita principalmente por claves y medidas numéricas.
  • Las tablas de dimensiones contienen el contexto descriptivo alrededor de esos eventos, como clientes, productos o fechas. Cada fila es una entidad empresarial.

Un esquema de estrella es la forma que obtienes cuando colocas una tabla de hechos en el centro y la conectas a varias tablas dimensionales a través de sus claves. El diseño es fácil de consultar para analistas y herramientas de BI y fácil de razonar para los ingenieros, porque cada tabla tiene una responsabilidad única y clara.

En las canalizaciones de Lakeflow, el esquema en estrella encaja de forma natural en la capa de oro de la arquitectura de medallón. Los conjuntos de datos de bronce y plata gestionan la ingestión y la limpieza, y el oro materializa sus tablas de datos y dimensiones para que los consumidores posteriores los consulten directamente. Como la pipeline mantiene esas tablas actualizadas de forma incremental, obtienes la simplicidad de consulta de un esquema estrella sin un paso separado de extracción, transformación y carga (ETL) en la capa BI.

Cómo funciona

Creas dimensiones y hechos como conjuntos de datos en tu pipeline, eligiendo el tipo de conjunto de datos que mejor se adapta a cómo cambia cada uno. Para la mayoría de los modelos de capa de oro:

  • Construye tablas dimensionales como vistas materializadas (o como tablas de streaming con dimensión que cambia lentamente (SCD) Tipo 2 cuando necesites historial). Una vista materializada se recalcula eficientemente a partir de sus datos de plata limpiados a medida que cambian las entradas, dándole una fila por entidad empresarial.
  • Cree tablas de hechos como tablas en streaming alimentadas de forma incremental desde la capa silver, para que las agregaciones de la capa gold se mantengan casi en tiempo real. Los hechos hacen referencia a las dimensiones mediante claves en lugar de duplicar atributos descriptivos.

Para más información sobre los dos tipos de conjuntos de datos, véase Vistas materializadas y Tablas de streaming. Para rastrear el historial en una dimensión, consulte Las API de AUTO CDC: simplifican la captura de cambios en los datos con canalizaciones.

Claves y claves sustitutas

Prefiere claves naturales (un identificador que ya existe en los datos fuente, como un número de orden) donde la clave natural de la fuente es estable y utilizable, porque se agrupa y se une bien. Recurra a una clave sustituta (un identificador alternativo generado por la canalización) solo cuando un origen reutiliza o cambia los ID.

Cuando realmente necesites una clave subrogada, evita una clave subrogada de hash como sha2(natural_key). Un hash es deliberadamente aleatorio, lo cual es perjudicial para el agrupamiento líquido y el rendimiento en orden Z porque filas físicamente adyacentes acaban dispersas entre archivos. En su lugar, derivar determinísticamente un sustituto que preserva el orden a partir de la clave natural estable, de modo que la misma entidad empresarial siempre corresponda al mismo sustituto. Una clave determinista sobrevive a una actualización o reconstrucción completa de la dimensión, lo que mantiene intactas las uniones existentes entre hechos y dimensiones.

Alternativamente, puede usar una columna IDENTITY cuando la tabla ascendente solo se añada y nunca se actualice por completo. Como los valores de IDENTITY se asignan a medida que se insertan las filas, una reconstrucción puede reasignar identificadores distintos a la misma entidad y romper silenciosamente las uniones entre hechos y dimensiones que utilizaban los valores anteriores.

Dimensiones de fecha

Cree una dim_date como una vista materializada simple generada con sequence() y explode() para un intervalo de fechas, en lugar de incorporarla desde un origen. Son datos de referencia estáticos, baratos de calcular, y simplifican las uniones y ventanas basadas en fechas en el resto del modelo.

Examples

Los siguientes ejemplos construyen un pequeño esquema estrella con una dimensión del cliente y una tabla de datos de pedidos.

Tabla de dimensiones

Una tabla de dimensiones suele ser una vista materializada construida a partir de datos de plata limpiados, con una fila por entidad empresarial, como en el siguiente 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;

Tabla de hechos

Una tabla de hechos contiene los eventos medibles, referenciando las dimensiones por sus claves en lugar de duplicar atributos descriptivos. Mantén los hechos limitados (principalmente claves y medidas numéricas) y utiliza uniones para extraer detalles descriptivos en el momento de la consulta, como en el siguiente 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);

procedimientos recomendados

Algunas prácticas mantienen un esquema de estrellas saludable a medida que crece:

Recursos adicionales

  • Last updated on