Descripción general

Las verificaciones de CI/CD de Data Observability se ejecutan automáticamente cuando abre una solicitud de extracción (PR) que modifica modelos de dbt. Las verificaciones le brindan la información que necesita para decidir si un cambio es seguro para fusionarlo.

Datadog publica los resultados como un comentario en su PR, y el comentario se actualiza cada vez que envía nuevos cambios. También hay un informe completo disponible en Datadog, y obtendrá un enlace al mismo en el comentario de la solicitud de extracción.

Tipos de verificación

Linaje de impacto

El linaje de impacto crea un gráfico de todo lo que se encuentra aguas abajo de los modelos de dbt modificados. Úselo para evaluar el alcance de un cambio antes de fusionarlo. Vea qué tablas, paneles y otros consumidores dependen de los modelos que modificó, y dirija la revisión a los propietarios correctos.

Consulte Linaje para obtener más detalles sobre cómo Datadog crea y navega por los gráficos de linaje.

Detección de desviaciones

La detección de desviaciones compara los datos producidos por sus modelos antes y después de sus cambios mediante una serie de verificaciones estadísticas. Úsela para confirmar que un cambio en el modelo produce el resultado esperado, o para detectar efectos secundarios no deseados, como cambios significativos en el recuento de filas, cambios en la tasa de nulos o cambios de cardinalidad en los valores de una columna.

Configuración

1. Conecte su proveedor de control de código fuente y su proyecto de dbt

1. Conecte su proveedor de control de código fuente. Las verificaciones de CI/CD son compatibles con GitHub y GitLab.
2. Conecte la cuenta de fuente de datos compatible donde se ejecutan sus modelos de dbt.
3. Conecte su proyecto de dbt Cloud o dbt Core a Datadog. También puede conectar su proyecto de dbt mientras configura las verificaciones de CI/CD.

2. Seleccione su proyecto de dbt y su repositorio

1. Desde la configuración de CI/CD, haga clic en Add CI/CD Checks.
2. Seleccione el proyecto de dbt para el que desea agregar verificaciones.
3. Seleccione el trabajo principal para el proyecto. Este es el trabajo con mayor conocimiento de su esquema de dbt.
4. Si Datadog no infiere automáticamente el repositorio de su proveedor de control de código fuente, selecciónelo manualmente.

Configuración avanzada

Si su proyecto de dbt no se encuentra en la raíz de su repositorio, puede especificar la ruta a su proyecto de dbt en la configuración avanzada.

3. Configurar verificaciones

Puede habilitar cada verificación de forma independiente. Habilitar todas las verificaciones genera los informes más completos.

Linaje de impacto

El linaje de impacto genera un gráfico de los activos aguas abajo que pueden verse afectados por los cambios en su modelo.

Configuración general

Detección de desviaciones

La detección de desviaciones compara el estado actual de sus datos en la rama con una línea base y marca cualquier desviación. Datadog utiliza las ejecuciones de dbt de su canalización de CI como activadores para las verificaciones de detección de desviaciones. Para dbt Core, debe enviar eventos de OpenLineage desde su trabajo de CI para que Datadog reciba estas ejecuciones. Consulte la documentación de configuración de OpenLineage. Para dbt Cloud, configure el trabajo de CI que se ejecuta en las solicitudes de extracción en la configuración CI Job URL en la sección dbt Cloud.

Datadog también debe poder leer las tablas que su trabajo de CI crea para compararlas. El rol que creó durante la configuración de Snowflake (DATADOG_ROLE de forma predeterminada) necesita USAGE y SELECT en la base de datos en la que su trabajo de CI materializa los modelos. La configuración de la integración de Snowflake de Datadog incluye un procedimiento grant_database_access que otorga esto en todas las tablas y vistas actuales y futuras en cada esquema de una base de datos. Ejecútelo para la base de datos en la que escribe su trabajo de CI:

CALL grant_database_access('["<CI_DATABASE>"]', '<ROLE_NAME>');

Si su CI crea una base de datos efímera por solicitud de extracción, llame al procedimiento como parte de ese paso de aprovisionamiento para que cada base de datos nueva sea legible. Consulte Configuración de Snowflake para ver la definición del procedimiento. Sin este acceso, Datadog recibe la ejecución de CI pero no puede consultar las tablas de CI, y la detección de desviaciones falla.

Para dbt Core, la detección de desviaciones también requiere que el número de solicitud de extracción se adjunte a sus eventos de OpenLineage a través de la faceta sourceCodeLocation. Esto requiere la versión openlineage-dbt 1.46.0 o posterior y la variable de entorno OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__DISABLED=false. Consulte Establecer las variables de entorno. Si su trabajo de CI de dbt Core se ejecuta dentro de un contenedor, necesita una configuración adicional. Consulte la sección Ejecución de su trabajo de CI de dbt Core en un contenedor.

Configuración general

dbt Cloud

dbt Core

Ejecución de su trabajo de CI de dbt Core en un contenedor

Si su trabajo de CI de dbt Core se ejecuta dentro de un contenedor que inicia el ejecutor de CI (por ejemplo, un flujo de trabajo de GitHub Actions que ejecuta el trabajo con docker run), el contenedor no hereda el contexto de git del ejecutor de CI. Como resultado, la URL del repositorio, el SHA de confirmación y el número de solicitud de extracción no se detectan automáticamente, y la faceta sourceCodeLocation se envía sin ellos. Datadog utiliza estos valores para hacer coincidir la ejecución con la solicitud de extracción que abrió o actualizó, por lo que sin ellos no aparecen resultados de desviación en la solicitud de extracción.

El siguiente ejemplo utiliza GitHub Actions; en otros proveedores de CI, los nombres de las variables de entorno difieren, pero el enfoque es el mismo. En el ejecutor de CI, lea los valores y páselos al contenedor explícitamente:

# On the CI runner, before launching the container:
PR_NUMBER=$(jq -r '.pull_request.number'  "$GITHUB_EVENT_PATH")
HEAD_SHA=$(jq -r '.pull_request.head.sha' "$GITHUB_EVENT_PATH")   # the pull request's head commit, not the merge commit
REPO_URL="${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}"

docker run \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__DISABLED=false \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__REPO_URL="$REPO_URL" \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__PULL_REQUEST_NUMBER="$PR_NUMBER" \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__VERSION="$HEAD_SHA" \
  <YOUR_IMAGE> <YOUR_DBT_OL_COMMAND>

El flujo de trabajo debe ejecutarse cuando se abre o actualiza una solicitud de extracción:

on:
  pull_request:
    types: [opened, synchronize, reopened]

Lecturas adicionales

Documentación, enlaces y artículos útiles adicionales:

Descripción general de Data ObservabilityDOCUMENTACIÓN Catálogo de datosDOCUMENTACIÓN LinajeDOCUMENTACIÓN Quality MonitoringDOCUMENTACIÓN Jobs MonitoringDOCUMENTACIÓN