Atribución granular de uso para canalizaciones dbt con etiquetas de consulta

Su proyecto dbt ejecuta 80 modelos cada noche. La factura del almacén se duplicó el último trimestre. El rendimiento del modelo varía ampliamente y los efectos de las optimizaciones más recientes no están claros. Finanzas pregunta qué equipo es responsable. Abres el historial de consultas y ves... 80 filas idénticas etiquetadas como 'Databricks Dbt'. Buena suerte.

Con Query Tags (ahora en versión preliminar pública), los equipos de datos pueden beneficiarse de etiquetas de inyección automática listas para usar, como dbt_model_name, que enriquecen cada ejecución. También puede asociar sus propias etiquetas personalizadas (equipo, centro de costes, entorno, etc.) a cada consulta que genere la canalización.

Las etiquetas se registran en system.query.history, lo que permite que la atribución de costos, la depuración de rendimiento y la supervisión de la carga de trabajo sean una simple consulta SQL (consulte la documentación para obtener más información).

En este blog se describe un proyecto completo de dbt de código abierto que muestra etiquetas de consulta de principio a fin: desde la configuración hasta los paneles de atribución de costos. Todo lo descrito aquí está disponible como un repositorio de GitHub que puedes clonar e implementar en tu propio espacio de trabajo, o simplemente preguntarle a Genie.

Cómo dbt-databricks se integra con etiquetas de consulta

El dbt-databricksadaptador (versión 1.11+) admite etiquetas de consulta de forma nativa. Existen tres niveles en los que se pueden aplicar etiquetas, cada uno de los cuales se basa en el anterior:

Etiquetas inyectadas automáticamente

Además de las etiquetas personalizadas, dbt-databricksinyecta automáticamente metadatos sobre cada ejecución de modelo:

Estas etiquetas automáticas le permiten obtener visibilidad por modelo sin necesidad de configuración: el adaptador lo hace por usted.

Etiquetas de nivel de perfil

El enfoque más sencillo: agregue un campo query_tags a un destino específico en su perfil dbt. Todas las consultas del proyecto heredan estas etiquetas automáticamente.

Por ejemplo, esta línea única etiqueta cada consulta con cuatro dimensiones: quién es el propietario (equipo), dónde va el costo (centro_coste), a qué canalización pertenece (nombre_proyecto) y en qué entorno se ejecuta (env).

Etiquetas a nivel de modelo

Para una atribución más detallada, puede proporcionar etiquetas en modelos específicos en dbt_project.yml o en la configuración del modelo en su definición de sql. 

Las etiquetas de nivel de modelo se fusionan con etiquetas de nivel de perfil. Si ambos definen la misma clave, el valor a nivel de modelo tiene prioridad.

Dónde aparecen las etiquetas: system.query.history

Después de ejecutar dbt run, cada instrucción SQL aparece en system.query.history con la columna query_tags rellenada como MAP<STRING, STRING>. Puede consultarlo utilizando la sintaxis estándar de acceso a mapas:

Esto devuelve todas las consultas etiquetadas de los últimos siete días, con las etiquetas personalizadas y autoinyectadas extraídas en columnas individuales listas para agregarse.

También puede encontrar las etiquetas de consulta de la consulta que ejecutó en la interfaz de usuario del historial de consultas o en la interfaz de usuario de supervisión de SQL Warehouse.

En la parte inferior derecha del perfil de consulta verá las etiquetas de consulta que haya definido, que le proporcionarán toda la información necesaria de un vistazo.

Atribución de costes con etiquetas de consulta

Las etiquetas de consulta permiten determinar la atribución granular del uso directamente mediante consultas SQL, lo que elimina la necesidad de realizar análisis manuales de registros o dividir los recursos del almacén.

¿Qué modelos de dbt consumen más recursos de almacén?

Puede responder a esta pregunta de dos maneras: solicite a Genie en lenguaje sencillo que realice una exploración ad hoc o escriba usted mismo el SQL para obtener un resultado repetible y listo para el panel de control. Ambos leen los mismos datos de system.query.history.

Opción 1: Genio

Genie escribe y ejecuta la consulta equivalente, y usted sigue analizando las preguntas de seguimiento sin tocar ningún código SQL.

Opción 2: SQL

Cualquiera de las rutas devuelve la misma imagen. En nuestro proyecto de referencia, las cuatro tablas mart (materializadas como tabla) dominan el tiempo de cálculo, mientras que las vistas de preparación y métricas son casi instantáneas. Esto le indica inmediatamente dónde debe centrarse el esfuerzo de optimización.

Creación de un panel de control automonitorizado

Nuestro proyecto de referencia incluye un panel de control de IA/BI que consulta a system.query.history filtrado por las etiquetas de consulta propias del proyecto. El resultado: el canal que analiza los datos de facturación también realiza un seguimiento de sus propios costos, alimentando a los perros etiquetas de consulta en sí mismo.

El panel de control incluye:

• Indicadores clave de rendimiento: consultas etiquetadas totales, segundos de cálculo totales, modelos de dbt distintos
• Actividad diaria: recuento de consultas y tiempo de cálculo por día, dividido por entorno
• Desglose del modelo: tiempo de cálculo por modelo, con colores según tipo de materialización
• División de materialización: gráfico circular que muestra cómo se distribuye el cálculo en tabla, vista y vista_métrica
• Tabla de detalles de consulta: todas las consultas etiquetadas con modelo, duración, entorno y ejecutor

En nuestro proyecto de referencia, los cuatro modelos de mart representaban el 92 % del tiempo de cómputo; sin etiquetas de consulta, esa información era invisible.

Crear este panel de control usted mismo lleva minutos con Genie Code: solicite tiempo de cálculo por modelo dbt de system.query.history filtrado por las etiquetas de consulta, y Genie Code escribirá el código SQL y ensamblará los elementos visuales. Si prefiere pasar directamente al resultado final, el panel de control también se incluye en el proyecto de referencia y se implementa con un paquete de databriks que se implementa junto con el trabajo de dbt (consulte el repositorio de Github para obtener una guía detallada).

Etiquetado de vistas métricas

Las vistas métricas de Databricks (disponibles en dbt-databricks1.12 y versiones posteriores) son un nuevo tipo de materialización que define semántica empresarial reutilizable en forma de dimensiones y medidas directamente en el catálogo de Unity (consulta la documentación completa). Pueden llevar etiquetas de consulta como cualquier otro modelo, utilizando el parámetro de configuración query_tags:

Tenga en cuenta la distinción: las etiquetas de consulta se asocian a las consultas SQL que crean o actualizan la vista métrica (se rastrean en system.query.history), mientras que las etiquetas de datos de los catálogos de Unity están asociadas a las consultas SQL que crean o actualizan la vista métrica (se realizan en el propio objeto para fines de gobierno y descubrimiento). El primero es para el seguimiento a nivel de consulta, mientras que el segundo es a nivel de objeto del catálogo de Unity para la detección general de datos. 

Mejores prácticas para etiquetar proyectos dbt

En este artículo, cubrimos el proceso holístico para crear una práctica sólida de operaciones financieras en la que las etiquetas de consulta son fundamentales para la atribución de costos. Esto es lo que aprendimos al crear el proyecto de referencia y hablar con usuarios avanzados de dbt:

• Utilice una jerarquía de etiquetas coherente. Defina etiquetas de toda la organización a nivel de perfil (equipo, centro de costes, nombre_proyecto, env) y reserve etiquetas a nivel de modelo para casos excepcionales. Esto mantiene las etiquetas predecibles y evita la dispersión de la configuración por modelo.
• Etiqueta siempre el medio ambiente. Utilice diferentes valores de env para el desarrollo local (local-dev) y los trabajos implementados (dev, staging, prod). Esto le permite separar las consultas de desarrollo ad hoc de las ejecuciones de producción programadas en sus análisis. En nuestro proyecto de referencia, el perfil local establece "env": "local-dev", mientras que el perfil implementado establece "env": "dev".
• Utilice `nombre_proyecto` para distinguir las tuberías. Cuando varios proyectos dbt comparten un almacén, project_name le permite atribuir costes por canalización sin dividir los almacenes. Combinado con la inyección automática@@dbt_model_name, se obtiene una trazabilidad completa: proyecto → modelo → materialización.
• No te excedas en el estilo. Las etiquetas inyectadas automáticamente ya cubren el nombre del modelo, el tipo de materialización y las versiones del adaptador. Rara vez es necesario duplicar esta información en etiquetas personalizadas. Centra las etiquetas personalizadas en el contexto empresarial que dbt no puede inferir: propiedad del equipo, centro de costes, identidad del proyecto.
• Etiquete vistas métricas explícitamente. Dado que las vistas de métricas son una materialización más reciente, resulta útil etiquetarlas con una clave de característica (por ejemplo, "característica": "vista_métrica") para poder filtrar fácilmente las consultas de creación de vistas métricas en el análisis de costos.

Pruébalo tú mismo

El proyecto de referencia completo está disponible en GitHub: github.com/databricks-solutions/dbt-query-tags

Para empezar:

1. Clonar el repositorio
2. Crear un entorno virtual de Python 3.12 e instalar dependencias: pip install dbt-databricks>=1.12.0a1
3. Actualice profiles.yml con el host del espacio de trabajo, la ruta HTTP de SQL Warehouse, el catálogo y las etiquetas de consulta personalizadas
4. Ejecute dbt deps && dbt run --profiles-dir . para ejecutar la canalización
5. Consulta system.query.history para ver tus etiquetas en acción
6. Actualice dbt_profiles/profiles.yml y databricks.yml para que apunten a la configuración correcta.
7. Implementar con databricks Implementación en paquetes para ejecuciones programadas y el panel de análisis

Intercambia los valores de tu propio equipo y centro de costes. El patrón funciona para cualquier proyecto dbt en Databricks.

¡Clone el repositorio hoy! Solo se necesita una línea en su perfil para desbloquear la visibilidad de la atribución de uso a nivel de modelo en todo el almacén.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original