E135 - Intro y demo de GX Core - Data Quality

Resumen

En este episodio (E135) se presenta Great Expectations Core (GX Core), la librería de Python gratuita para controlar la calidad de datos, y se muestra una demo paso a paso con el objetivo de incluir un checkpoint dentro de un pipeline de desarrollo. Se explica la jerarquía de conceptos: data context, data source, data asset, batch definition y batch. Luego se explican expectations, expectation suites, validation definitions, checkpoints con acciones (Slack, actualización de data docs) y los data docs en HTML con los resultados. Se discute quién es responsable de la calidad de datos (nadie quiere hacerse cargo; el negocio o gobierno de datos serían los candidatos) y se recomienda validar el input y, sobre todo, el output del pipeline. Se estima que un data scientist puede tener el setup funcionando en unas 16 horas (dos días), mientras que al presentador le tomó unas 6 horas. Quedan pendientes los batches particionados y las acciones de Slack, que no funcionaron. Al final se discuten las diferencias entre data engineer, data analyst y data scientist.

Capítulos

• 00:00
  IntroSe presenta Great Expectations como librería de calidad de datos que sirve para enviar alertas y colocar checks dentro de un flujo de trabajo. El objetivo final es mostrar cómo poner un check dentro de un pipeline de ejecución de un proyecto.
• 01:38
  Configuración del entornoSe recorre la documentación (GX Core, GX Cloud, Learn, Expectation Gallery) y se distingue GX Core (gratis) de GX Cloud (servicio de pago). Se instala con pip en un ambiente virtual; funciona con Python 3.9 a 3.12, y se menciona que hay dependencias adicionales según la nube o base de datos (AWS, Azure, Google Cloud, SQL, Spark). Se inicializa el proyecto con el comando `init`.
• 05:07
  Contexto de datosEl data context almacena la configuración básica que se define una vez y luego solo se lee. Se menciona que esta es la sexta sesión de la serie de productivización.
• 07:14
  Fuentes de datosUn data source no es necesariamente una base de datos (puede ser una carpeta, un CSV o datos en RAM), un data asset es una "tabla" dentro del source, un batch definition indica cómo dividir el asset (por ejemplo por mes) y un batch es el asset ya filtrado.
• 08:40
  ExpectativasLas expectations son afirmaciones sobre lo que se espera de los datos (máximo de nulos, valores entre un rango) y se agrupan en expectation suites. La Expectation Gallery lista las disponibles y se pueden crear expectations personalizadas.
• 10:19
  ValidacionesUna validation definition une expectation suite y batch; el checkpoint dispara la validación y ejecuta acciones (correo, mensajes). Los data docs son el registro en HTML de cada validación, con porcentaje de fallos por columna.
• 12:42
  Creación del Data Context, definiciones de data assets y data sources, y overview del setupSe lee el contexto con `get_context` desde el archivo YAML de la carpeta `gx`. Se crea un data source de Pandas, un data frame asset de contratos, un batch definition de todo el dataset y una expectation `expect_column_values_to_be_between`. Se mencionan los tipos de data source "fluent" y las integraciones soportadas.
• 20:41
  Ejecutando código de prueba y lectura de elementos del data contextSe leen data source, asset y batch definition ya creados; al repetir un nombre falla y se usa otro, lo que modifica el YAML. Se comenta que el archivo YAML se puede editar a mano y que el batch definition puede particionarse por fecha (anual o mensual). Se conversa sobre si GX sirve para datos que no son tablas (por ejemplo imágenes).
• 28:12
  Expectations con parámetrosSe define una expectation cuyos valores límite no son fijos sino parámetros (diccionario con `$PARAMETER`) que se pasan en el momento de validar, útil para cambiar umbrales entre ejecuciones.
• 31:14
  Creación y gestión de conjuntos de expectativasSe crea la expectation suite con un nombre, se le agregan expectations con `add_expectation` y se persiste con `save`. Se explica que los archivos JSON de las suites, las definiciones de validación y el YAML se commitean, mientras que la carpeta `uncommitted` (resultados) no.
• 37:34
  MemesPausa de memes: "expectations everywhere", pipelines que entregan nulos a una herramienta de BI y la pregunta de si GX es un "policy manager". Se aclara que verifica reglas de calidad de datos, no da ni quita accesos. El presentador cuenta que le tomó unas 6 horas dominar la herramienta siguiendo la documentación, con problemas solo en los batches particionados y en la acción de Slack.
• 44:01
  Responsabilidad por la calidad de datosDebate sobre quién es dueño de la calidad de datos: se plantean data engineer, gobierno de datos, unidades de negocio, DevOps o un rol de QA de datos. Se concluye que GX sirve para alertar y que es recomendable validar al comienzo (para enterarse de problemas) y al final (como responsabilidad del data scientist hacia el cliente). Se muestran más memes sobre plataformas de ML y presupuesto de calidad de datos.
• 55:15
  Creación de un batch de datos y validación de esos batchesSe obtiene el batch con `get_batch` y se valida con una expectation sobre `monthly_charges` entre 0 y 60, diseñada para fallar. El resultado muestra los índices de casos inesperados, un 58% de fallos y el estado global de éxito o falla.
• 59:21
  Uso de validation con batch y expectation suiteSe valida pasando parámetros y luego se guarda una validation definition (batch definition + suite + nombre) en el contexto, que se ejecuta con `run` y con parámetros de batch y de expectations.
• 01:00:24
  Dónde se guardan las definiciones de las validacionesLas definiciones quedan en el archivo de configuración y los resultados JSON en `uncommitted/validations`. Se aclara que estas validaciones no tienen relación con LLMs ni con flujos de CI/CD.
• 01:04:11
  Acciones y checkpointsSe importan `SlackNotificationAction` y `UpdateDataDocsAction`, se arma una lista de acciones y se crea un checkpoint que referencia la validation definition por ID. Se discute que el correo sirve para alertar y no para visualizar, y se mencionan integraciones con Slack, correo, PagerDuty, Opsgenie y Microsoft Teams. Se enfatiza definir las cosas una sola vez y referenciarlas.
• 01:10:24
  Data docs con resultados de validaciones en htmlSe abre el `index.html` de data docs, que lista todos los checkpoints ejecutados con el detalle de qué falló, índices y porcentaje de valores inesperados. Se puede aceptar un umbral de fallos (por ejemplo 10%) y borrar historial, o aplicar lifecycle policies en un bucket de S3.
• 01:14:13
  Inclusión de checkpoints dentro del pipeline de desarrolloSe agrega a un pipeline existente un archivo Python de 31 líneas que lee el contexto y ejecuta el checkpoint. Se recomienda poner un checkpoint al inicio y otro al final del pipeline.
• 01:15:50
  Ideas futurasEl presentador quiere crear un script que genere la definición inicial con nombres y rutas estándar para su contexto de trabajo.
• 01:16:28
  Cuánto tiempo debería demorar un DS en hacer el setup y otras dudasEstima unas 16 horas (dos días) para un data scientist y 6 horas para quien ya conoce la herramienta; no asegura tiempos para batches particionados ni acciones. Se comenta el modelo de negocio open source más versión de pago de GX Cloud, que reduce el setup a cerca de una hora con interfaz visual.
• 01:21:17
  Roles en la gestión de datosSe explican los roles: data engineer (mueve y transforma datos), data analyst (reportes y análisis descriptivos), data scientist (patrones y predicciones con modelos) y los nuevos roles que usan LLMs con datos no estructurados.
• 01:23:14
  CierreSe recuerda que los streams son los martes de 7 a 9 (hora de Santiago de Chile) y se agradece a la audiencia.

Palabras clave