Vistas de métricas del modelo

Las vistas de métricas crean una capa semántica para los datos, transforman tablas y vistas en métricas empresariales estandarizadas. Definen qué medir, cómo agregarlo y cómo segmentarlo. Como resultado, todos los usuarios de toda la organización notifican el mismo valor para el mismo KPI, lo que elimina los informes incoherentes y permite el análisis flexible en todos los campos.

Los componentes principales que defina son orígenes, combinaciones, filtros, campos y medidas.

Para obtener un ejemplo completo con combinaciones, campos, medidas y metadatos del agente, consulte Tutorial: Compilación de una vista de métricas con combinaciones y modelado de datos.

Componentes principales

Una vista de métrica consta de los siguientes elementos:

Componente Description Ejemplo
Source Tabla base, vista o consulta SQL que contiene los datos. samples.tpch.orders
Combinaciones Relaciones entre tablas, vistas y vistas métricas para enriquecer los datos. Combinar orders tabla con customers tabla en customer_key
Filtros Condiciones aplicadas a los datos de origen para definir el ámbito.
  • status = 'completed'
  • order_date > '2024-01-01'
Campos Columnas usadas para agrupar, filtrar y agregar métricas. Incluye columnas categóricas y columnas numéricas no agregadas. También llamadas dimensiones. Categoría del producto, Mes de pedido, Precio unitario
Medidas Agregaciones de columnas que generan métricas. COUNT(o_orderkey) como Recuento de pedidos, SUM(o_totalprice) como Ingresos totales

Definición de un origen

Puede usar un recurso similar a una tabla o una consulta SQL como origen de la vista de métricas. Debe tener al menos SELECT privilegios en cualquier recurso al que se haga referencia.

Un recurso similar a una tabla es cualquier objeto del Catálogo de Unity que presenta un esquema tabular y admite consultas, incluidas las tablas, vistas, vistas materializadas, tablas de flujo, tablas externas, tablas del sistema y vistas de métricas.

Uso de un recurso similar a una tabla como origen

Para usar un recurso similar a una tabla como origen, especifique el nombre completo. Por ejemplo: samples.tpch.orders.

Uso de una vista de métrica como origen

Puede usar una vista de métrica existente como origen para una nueva vista de métrica:

version: 1.1

source: views.examples.source_metric_view

fields:
  - name: Order month
    expr: '`Order Month`'

measures:
  - name: Latest order month
    expr: MAX(`Order month`)
  - name: Latest order year
    expr: "DATE_TRUNC('year', MEASURE(`Latest order month`))"

Cuando se usa una vista de métrica como origen, se aplican las mismas reglas de composición para hacer referencia a campos y medidas. Consulte Composabilidad.

Uso de una consulta SQL como origen

Para usar una consulta SQL, escriba el texto de la consulta directamente en YAML:

version: 1.1

source: SELECT * FROM samples.tpch.orders o LEFT JOIN samples.tpch.customer c ON o.o_custkey
  = c.c_custkey

fields:
  - name: Order key
    expr: o_orderkey

measures:
  - name: Order Count
    expr: COUNT(o_orderkey)

Note

Cuando se usa una consulta SQL como origen con una JOIN cláusula , establezca restricciones de clave principal y externa en las tablas subyacentes y use la RELY opción para obtener un rendimiento óptimo de las consultas. Consulte Declarar la clave principal, la clave externa y las restricciones únicas y la optimización de consultas mediante la clave principal y las restricciones únicas.

Campos

Los campos, también llamados dimensiones, son columnas de una vista de métricas que se pueden usar en las cláusulas SELECT, WHERE y GROUP BY al realizar una consulta. Un campo puede ser una columna de categorías, como región o estado, o una columna numérica no agregada, como el precio o la cantidad, que puede agregar en el momento de la consulta. Cada expresión de campo debe devolver un valor escalar. Puede hacer referencia a columnas de los datos de origen o a campos definidos anteriormente en la vista de métricas. Cada campo consta de dos componentes:

  • name: alias de la columna
  • expr: expresión SQL que hace referencia a los datos de origen o campos definidos previamente en la vista de métricas.

Advertencia

Los campos de vista de métricas de tipo cadena son siempre STRING, incluso cuando la columna de origen es CHAR o VARCHAR. Dado que CHAR(n) se pierde el espaciado, las comparaciones pueden devolver resultados diferentes. Por ejemplo, column = 'COLLEGE' coincide con CHAR(10) valor en la tabla de origen (que está rellenada con espacios), pero no en el campo de la vista de métricas.

Medidas

Las medidas son expresiones que generan resultados sin un nivel de agregación determinado previamente. Deben expresarse mediante funciones de agregado. Para hacer referencia a una medida en una consulta, use la MEASURE función . Las medidas pueden hacer referencia a columnas base en los datos de origen, los campos definidos anteriormente o las medidas definidas anteriormente. Cada medida consta de los siguientes componentes:

  • name: alias de la medida.
  • expr: expresión SQL agregada que puede incluir funciones de agregado de SQL.

En el ejemplo siguiente se muestran patrones de medida comunes para analizar los datos de pedidos e ingresos. En estos ejemplos se usa la tabla TPC-H pedidos, que contiene datos de transacciones de ventas, incluidos los precios de pedido (o_totalprice), los identificadores de cliente (o_custkey), las claves de pedido (o_orderkey), las fechas de pedido (o_orderdate) y los niveles de prioridad (o_orderpriority):

measures:
  # Simple count measure
  - name: Order Count
    expr: COUNT(1)

  # Sum aggregation measure
  - name: Total Revenue
    expr: SUM(o_totalprice)

  # Distinct count measure
  - name: Unique Customers
    expr: COUNT(DISTINCT o_custkey)

  # Calculated measure combining multiple aggregations
  - name: Average Order Value
    expr: SUM(o_totalprice) / COUNT(DISTINCT o_orderkey)

  # Filtered measure with WHERE condition
  - name: High Priority Order Revenue
    expr: SUM(o_totalprice) FILTER (WHERE o_orderpriority = '1-URGENT')

  # Measure using a field
  - name: Average Revenue per Month
    expr: SUM(o_totalprice) / COUNT(DISTINCT DATE_TRUNC('MONTH', o_orderdate))

Consulte Funciones de agregado para obtener una lista de funciones de agregado.

Aplicar filtros

Un filtro se aplica a todas las consultas que hacen referencia a la vista de métricas. Para definir un filtro en la interfaz de usuario, consulte Paso 3: Definir un filtro.

Para definir un filtro en la definición de YAML, escriba una expresión booleana. En el ejemplo siguiente se muestran patrones de filtro comunes:

# Single condition
filter: o_orderdate > '2024-01-01'

# Multiple conditions
filter: o_orderdate > '2024-01-01' AND o_orderstatus = 'F'

# IN clause
filter: o_orderstatus IN ('F', 'P') AND o_orderdate >= '2024-01-01'

Trabajar con combinaciones

Las vistas de métricas admiten combinaciones para enriquecer los datos de origen con atributos de tablas relacionadas. Puede modelar esquemas de estrella (tabla de hechos unida a tablas de dimensiones), esquemas de copo de nieve (combinaciones de dimensiones de varios niveles) y relaciones uno a varios (expansión de hechos de un origen dimensional). Para más información sobre los tipos de combinación, la cardinalidad, los patrones de esquema y las restricciones, consulte Combinaciones en vistas de métricas.

Para definir combinaciones en la interfaz de usuario, consulte Paso 2: Agregar una combinación. Para definir combinaciones en la definición de YAML, use los patrones de las secciones siguientes.

Note

Las tablas combinadas no pueden incluir MAP columnas de tipo. Para desempaquetar valores de columnas de MAP tipo, vea Explotar elementos anidados de una asignación o matriz.

Esquemas de estrella modelo

En un esquema de estrella, source es la tabla de hechos y combina con una o varias tablas de dimensiones mediante .LEFT OUTER JOIN Las vistas de métricas unen las tablas de hechos y dimensiones necesarias para la consulta específica, en función de los campos y medidas seleccionados.

Especifique las columnas de unión mediante la cláusula on (expresión booleana) o la cláusula using (nombres de columnas compartidos). La unión debe basarse en una relación de varios a uno. En los casos de muchos a muchos, el motor selecciona la primera fila que coincida de la tabla de dimensiones combinada.

En el ejemplo siguiente se unen orders (tabla de hechos) a customer (tabla de dimensiones) y se exponen atributos de cliente como campos. La configuración rely.at_most_one_match: true declara que la combinación es de varios a uno (cada pedido tiene exactamente un cliente), lo que permite al motor optimizar las consultas que filtran por campos de la tabla combinada.

Advertencia

Establezca at_most_one_match: true solo cuando la relación sea de varios a uno. Esta propiedad no se valida en tiempo de ejecución. Si la combinación genera un ventilador, las medidas devuelven resultados incorrectos.

Consulte Optimización de combinaciones con rely.

version: 1.1
source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey

fields:
  - name: Customer name
    expr: customer.c_name

measures:
  - name: Total revenue
    expr: SUM(o_totalprice)

Sintaxis y formato de YAML

Las definiciones de la vista métrica siguen la sintaxis de notación YAML estándar. Consulte Referencia de sintaxis de YAML de la vista métrica para obtener la sintaxis y el formato necesarios.

Procedimientos recomendados

Use las instrucciones siguientes al modelar vistas de métricas:

  • Medidas atómicas del modelo: comience definiendo primero las medidas más sencillas (por ejemplo, SUM(revenue), COUNT(DISTINCT customer_id)). Crear medidas complejas usando la composabilidad.
  • Estandarizar valores de campo: use transformaciones (como CASE instrucciones) para convertir códigos de base de datos en nombres de negocio claros (por ejemplo, convertir el estado de pedido "O" a "Abrir" y "F" a "Cumplido").
  • Definir el ámbito con filtros: si una vista de métrica solo debe incluir pedidos completados, defina ese filtro en la vista de métricas para que los usuarios no puedan incluir datos incompletos accidentalmente.
  • Use nombres claros: los nombres de las métricas deben ser reconocibles para los usuarios empresariales (por ejemplo, "Valor del Tiempo de Vida del Cliente" en lugar de cltv_agg_measure).
  • Campos de hora independientes: incluya campos de hora pormenorizados (como "Fecha de pedido") y campos de hora truncados (como "Mes de pedido" o "Semana de pedido") para habilitar el análisis de tendencias y el nivel de detalle.

Recursos adicionales

  • Last updated on