Herramientas como DBT hacen que la construcción de tuberías de datos SQL sea fácil y sistemática. Pero incluso con la estructura adicional y los modelos de datos claramente definidos, las tuberías aún pueden volverse complejas, lo que dificulta los problemas de depuración y la validación de cambios en los modelos de datos.
La creciente complejidad de la lógica de transformación de datos da lugar a los siguientes problemas:
- Procesos de revisión de código tradicional Solo mira código cambia y excluye el impacto de los datos de esos cambios.
- El impacto de los datos resultante de los cambios en el código es difícil de rastrear. En extensos DAG con dependencias anidadas, descubrir cómo y dónde ocurre el impacto de los datos es extremadamente lento o casi imposible.
Gitlab’s DBT DAG (que se muestra en la imagen destacada de arriba) es el ejemplo perfecto de un proyecto de datos que ya es una casa de tarjetas. Imagine tratar de seguir un simple cambio de lógica SQL a una columna a través de todo este DAG de linaje. Revisar una actualización del modelo de datos sería una tarea desalentadora.
¿Cómo abordaría este tipo de revisión?
¿Qué es la validación de datos?
La validación de datos se refiere al proceso utilizado para determinar que los datos son correctos en términos de requisitos del mundo real. Esto significa garantizar que el La lógica de SQL en un modelo de datos se comporta según lo previsto al verificar que los datos son correctos. La validación generalmente se realiza después de modificar un modelo de datos, como acomodar nuevos requisitos o como parte de un refactor.
Un desafío de revisión único
Los datos tienen estados y se ven directamente afectados por la transformación utilizada para generarlo. Es por eso que revisar los cambios del modelo de datos es un desafío único, porque tanto el código y Los datos deben ser revisados.
Debido a esto, las actualizaciones del modelo de datos deben revisarse no solo para completar, sino también contexto. En otras palabras, los datos son los datos correctos y las métricas existentes no fueron alterados involuntariamente.
Dos extremos de validación de datos
En la mayoría de los equipos de datos, la persona que realiza el cambio se basa en el conocimiento institucional, la intuición o la experiencia pasada para evaluar el impacto y validar el cambio.
“He hecho un cambio en X, creo que sé cuál debería ser el impacto. Lo comprobaré ejecutando Y”
El método de validación generalmente cae en uno de dos extremos, ninguno de los cuales es ideal:
- Verificación de manchas con consultas y algunas verificaciones de alto nivel como el recuento de filas y el esquema. Es rápido pero corre el riesgo de perder el impacto real. Los errores críticos y silenciosos pueden pasar desapercibidos.
- Comprobación exhaustiva de cada modelo aguas abajo. Es lento e intensivo en recursos, y puede ser costoso a medida que crece la tubería.
Esto da como resultado un proceso de revisión de datos que no está estructurado, difícil de repetir y a menudo introduce errores silenciosos. Se requiere un nuevo método que ayude al ingeniero a realizar una validación de datos precisa y específica.
Un mejor enfoque a través de la comprensión de las dependencias del modelo de datos
Para validar un cambio en un proyecto de datos, es importante comprender la relación entre los modelos y cómo fluye los datos a través del proyecto. Estas dependencias entre los modelos nos informan cómo se pasan los datos y se transforman de un modelo a otro.
Analizar la relación entre los modelos
Como hemos visto, los DAG del proyecto de datos pueden ser enormes, pero un cambio de modelo de datos solo afecta un subconjunto de modelos. Al aislar este subconjunto y luego analizar la relación entre los modelos, puede retroceder las capas de complejidad y centrarse solo en los modelos que realmente necesitan validación, dado un cambio lógico SQL específico.
Los tipos de dependencias en un proyecto de datos son:
Modelo a modelo
Una dependencia estructural en la que se seleccionan las columnas de un modelo aguas arriba.
--- downstream_model
select
a,
b
from {{ ref("upstream_model") }}Columna a columna
Una dependencia de proyección que selecciona, renombra o transforma una columna aguas arriba.
--- downstream_model
select
a,
b as b2
from {{ ref("upstream_model") }}Modelo a columna
Una dependencia del filtro en la que un modelo aguas abajo utiliza un modelo aguas arriba en un lugar donde, unión u otra cláusula condicional.
-- downstream_model
select
a
from {{ ref("upstream_model") }}
where b > 0Comprender las dependencias entre los modelos nos ayuda a definir el radio de impacto de un cambio lógico del modelo de datos.
Identificar el radio de impacto
Al hacer cambios en el SQL de un modelo de datos, es importante comprender qué otros modelos podrían verse afectados (los modelos que debe verificar). En el alto nivel, esto se hace mediante relaciones de modelo a modelo. Este subconjunto de nodos DAG se conoce como el radio de impacto.
En el DAG a continuación, el radio de impacto incluye nodos B (el modelo modificado) y D (el modelo aguas abajo). En DBT, estos modelos se pueden identificar utilizando el selector Modified+.
Identificar nodos modificados y aguas abajo es un gran comienzo, y al aislar cambios como este, reducirá el área potencial de validación de datos. Sin embargo, esto aún podría dar lugar a una gran cantidad de modelos aguas abajo.
Clasificando el tipos Los cambios de SQL pueden ayudarlo a priorizar qué modelos realmente requieren validación al comprender la gravedad del cambio, eliminando las ramas con cambios que se sabe que son seguros.
Clasifique el cambio SQL
No todos los cambios de SQL tienen el mismo nivel de riesgo a los datos aguas abajo, por lo que deben clasificarse en consecuencia. Al clasificar los cambios de SQL de esta manera, puede agregar un enfoque sistemático a su proceso de revisión de datos.
Un cambio SQL a un modelo de datos se puede clasificar como uno de los siguientes:
Cambio no roto
Cambios que no afectan los datos en los modelos posteriores, como agregar nuevas columnas, ajustes al formato SQL o agregar comentarios, etc.
-- Non-breaking change: New column added
select
id,
category,
created_at,
-- new column
now() as ingestion_time
from {{ ref('a') }}Cambio parcial
Cambios que solo afectan los modelos posteriores que hacen referencia a ciertas columnas, como eliminar o cambiar el nombre de una columna; o modificar una definición de columna.
-- Partial breaking change: `category` column renamed
select
id,
created_at,
category as event_category
from {{ ref('a') }}Cambio de rato
Cambios que afectan a todos los modelos posteriores, como filtrar, clasificar o cambiar la estructura o significado de los datos transformados.
-- Breaking change: Filtered to exclude data
select
id,
category,
created_at
from {{ ref('a') }}
where category != 'internal'Aplicar la clasificación para reducir el alcance
Después de aplicar estas clasificaciones, el radio de impacto, y el número de modelos que deben validarse, puede reducirse significativamente.
En el DAG anterior, los nodos B, C y F se han modificado, lo que resulta en potencialmente 7 nodos que necesitan ser validados (C a E). Sin embargo, no cada rama contiene cambios SQL que realmente requieren validación. Echemos un vistazo a cada rama:
Nodo C: Cambio no roto
C se clasifica como un cambio no roto. Por lo tanto, no es necesario verificar a C y H, se pueden eliminar.
Nodo B: cambio parcial
B se clasifica como un cambio parcial debido al cambio en la columna B.C1. Por lo tanto, D y E deben ser revisados solo Si hacen referencia a la columna B.C1.
Nodo F: cambio de ruptura
La modificación al Modelo F se clasifica como un cambio de ruptura. Por lo tanto, todos los nodos aguas abajo (G y E) deben verificarse para el impacto. Por ejemplo, el modelo G podría agregar datos de la columna aguas arriba modificada
Los 7 nodos iniciales ya se han reducido a 5 que deben verificarse para el impacto de los datos (B, D, E, F, G). Ahora, al inspeccionar los cambios SQL en el nivel de la columna, podemos reducir ese número aún más.
Estrechando el alcance aún más con el linaje a nivel de columna
Los cambios de ruptura y no roto son fáciles de clasificar, pero, cuando se trata de inspeccionar cambios parciales, los modelos deben analizarse a nivel de columna.
Echemos un vistazo más de cerca al cambio parcial en el Modelo B, en el que se ha modificado la lógica de la columna C1. Esta modificación podría dar como resultado 4 nodos aguas abajo afectados: D, E, K y J. Después de rastrear el uso de la columna aguas abajo, este subconjunto puede reducirse aún más.
Siguiendo la columna B.C1 aguas abajo podemos ver eso:
- B.C1 → D.C1 es una dependencia de columna a columna (proyección).
- D.C1 → E es una dependencia de modelo a columna.
- D → K es una dependencia de modelo a modelo. Sin embargo, como D.C1 no se usa en K, este modelo puede eliminarse.
Por lo tanto, los modelos que deben validarse en esta rama son B, D y E. junto con el cambio de ruptura F y la G aguas abajo, los modelos totales que se validarán en este diagrama son F, G, B, D y E, o solo 5 de un total de 9 modelos potencialmente impactados.
Conclusión
La validación de datos después de un cambio de modelo es difícil, especialmente en DAG grandes y complejos. Es fácil perderse errores silenciosos y realizar validación se convierte en una tarea desalentadora, ya que los modelos de datos a menudo se sienten como cajas negras cuando se trata de impacto posterior.
Un proceso estructurado y repetible
Al utilizar esta técnica de validación de datos consciente del cambio, puede aportar estructura y precisión al proceso de revisión, haciéndolo sistemático y repetible. Esto reduce el número de modelos que deben verificarse, simplifica el proceso de revisión y reduce los costos al validar solo los modelos que realmente lo requieren.
Antes de que te vayas …
Dave es un defensor técnico senior en Reaccionardonde estamos construyendo un conjunto de herramientas para habilitar flujos de trabajo de validación de datos avanzados. Siempre se complace en conversar sobre SQL, ingeniería de datos o ayudar a los equipos a navegar por sus desafíos de validación de datos. Conéctese con Dave en LinkedIn.
La investigación para este artículo fue posible gracias a mi colega Chen en Lu (Palometa).