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

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 cargas de trabajo se realicen con una simple consulta SQL (consulte todos los detalles en la documentació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 puede clonar e implementar en su propio espacio de trabajo, o simplemente preguntarle a Genie.

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

El adaptador dbt-databricks (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-databricks inyecta automáticamente metadatos sobre cada ejecución de modelo:

Estas etiquetas automáticas le permiten obtener visibilidad por modelo sin configuración: el adaptador lo hace por usted.Etiquetas a 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 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. Puede consultarlo utilizando la sintaxis estándar de acceso a mapas:SELECCIONAR

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 En la parte inferior derecha del perfil de consulta, verá las etiquetas de consulta que definió, 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, elimina la necesidad de realizar análisis manuales de registros o dividir los recursos del almacén.

¿Qué modelos dbt consumen la mayor cantidad de recursos del 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: Genie

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 de autosuperitación

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

El panel 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 el tipo de materialización
• División de materialización: gráfico circular que muestra cómo se distribuye el cálculo en la tabla, la vista y la tabla de detalles de metric_view
• Query: Cada consulta etiquetada con modelo, duración, entorno y ejecutor

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

Crear este panel de control usted mismo lleva minutos con Genie Code: solicite el tiempo de cálculo por modelo dbt desde system.query.history filtrado por las etiquetas de consulta, y escribirá el 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 con dbt-databricks 1.12 y posteriores) son un nuevo tipo de materialización que define semántica empresarial reutilizable en forma de dimensiones y medidas directamente en Unity Catalog (consulte 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 databricks son etiquetas de catálogo de Unity en el objeto mismo (para fines de gobernanza 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, hemos cubierto el proceso holístico para crear una práctica sólida de FinOps 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.
• Etiquete siempre el entorno. 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 el @@dbt_model_name, inyectado automáticamente, obtienes una trazabilidad completa: proyecto → modelo → materialización.
• No etiquetes demasiado. 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.
• Etiqueta 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. Clone el repositorio
2. Cree un entorno virtual de Python 3.12 e instale dependencias: pip instale dbt-databricks>=1.12.0a1
3. Actualice profiles.yml con el host del espacio de trabajo, la ruta HTTP del almacén SQL, el catálogo y las etiquetas de consulta personalizadas
4. Ejecutar dbt deps && dbt ejecute --profiles-dir . para ejecutar el pipeline
5. Query system.query.history para ver las etiquetas en acción
6. Actualice dbt_profiles/profiles.yml y databricks.yml para señalar la configuración correcta.
7. Implemente con databricks bundle deploy para ejecuciones programadas y el panel de análisis

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

¡Clone el repositorio hoy mismo! 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