Carga de datos en Redshift con DBT

• Yelp revisó recientemente cómo cargar datos en Redshift de forma más eficiente, a medida que crece la demanda de datos por parte de los consumidores
• En este artículo se explora cómo DBT puede usarse sin problemas con Redshift Spectrum para leer datos desde el Data Lake hacia Redshift, reducir significativamente el tiempo de ejecución, resolver problemas de calidad de datos y mejorar la productividad de los desarrolladores

Punto de partida

• La forma de cargar datos por lotes en Redshift ha sido efectiva durante años, pero se siguieron buscando mejoras
• Principalmente se usaban trabajos de Spark para leer datos en S3 y publicarlos en un pipeline interno de datos basado en Kafka, para llevarlos tanto al Data Lake como a Redshift
• Sin embargo, comenzaron a enfrentar varios problemas:
  • Rendimiento: los conjuntos de datos grandes (más de 1 millón de filas al día) empezaron a presentar demoras. La causa principal eran los escaneos de tabla para evitar claves primarias duplicadas durante los upserts
  • Cambios de esquema: la mayoría de las tablas estaban definidas con esquemas Avro. Los cambios de esquema a veces eran complejos porque requerían un proceso de varios pasos para generar y registrar un nuevo esquema Avro
  • Backfill: el soporte para backfills de correcciones de datos era deficiente, ya que no había una forma sencilla de modificar filas in-place. Con frecuencia se borraban manualmente los datos antes de volver a escribir los datos corregidos para una partición completa
  • Calidad de datos: escribir en paralelo al Data Lake y a Redshift implicaba el riesgo de discrepancias, como diferencias en tipos de datos entre ambos almacenes

Mejorar la carga en Redshift con DBT

• Al considerar una forma más eficiente de mover datos, se eligió aprovechar AWS Redshift Spectrum, una herramienta creada específicamente para permitir que Redshift consulte datos del Data Lake
• Como las tablas del Data Lake normalmente tenían el esquema más actualizado, se decidió usar el Data Lake en lugar de S3 como fuente de datos para los lotes de Redshift. Esto no solo ayudó a reducir discrepancias, sino que también se alineó con la práctica recomendada de tratar al Data Lake como fuente única de verdad
• Para la implementación, Spectrum requiere un esquema definido, que ya existía en Glue para las tablas del Data Lake. La única configuración adicional necesaria fue agregar las tablas del Data Lake como tablas externas para que Redshift pudiera acceder a ellas mediante consultas SQL simples
• Ya se había comenzado a adoptar DBT para otros conjuntos de datos, pero también parecía un candidato perfecto para capturar consultas de Redshift Spectrum en el pipeline. DBT destaca en la transformación de datos y ayuda a imponer una escritura de SQL modular y bajo control de versiones
• En lugar de que los trabajos de Spark leyeran desde S3 hacia Redshift, se usó DBT para copiar datos directamente del Data Lake a Redshift. Además de aportar ventajas características como reproducibilidad, flexibilidad y linaje de datos, DBT también ayudó a resolver varios de los problemas mencionados arriba

Cambios de esquema simplificados

• Para simplificar los cambios de esquema, se aprovechó el argumento de configuración on_schema_change de DBT. Se configuró como append_new_columns para garantizar que las columnas no se eliminaran cuando faltaran en los datos entrantes
• También se usaron contratos de DBT como una segunda capa de protección para verificar que los datos escritos coincidieran con la configuración del modelo

Backfills menos manuales

• Los backfills también se volvieron mucho más fáciles con DBT. El argumento de configuración pre_hook permite especificar consultas que se ejecutan justo antes del modelo
• Esto permitió eliminar de manera más automática los datos de las particiones que iban a reescribirse
• Ahora se puede garantizar la idempotencia, por lo que es posible hacer backfills sin preocuparse de que no se eliminen datos antiguos

Eliminación de datos duplicados

• Para resolver las filas duplicadas, se agregó una capa de deduplicación en SQL y se validó con pruebas de DBT
• DBT incluye una prueba integrada de unicidad de columna, pero requiere un escaneo completo de la tabla, por lo que no es viable para tablas grandes
• En su lugar, se usó la función expect_column_values_to_be_unique del paquete dbt_expectations. Esto permite especificar una condición por fila para escanear solo las filas escritas recientemente

Mejoras de rendimiento

• El resultado más notable fue la mejora de rendimiento, especialmente en el conjunto de datos de Redshift con más problemas:
  • Las escrituras antes tardaban unas 2 horas, pero ahora normalmente se ejecutan en solo 10 minutos
  • Antes había retrasos de hasta 6 horas al mes, pero ahora ya no hay retrasos. Esto redujo considerablemente la carga del trabajo de respuesta a incidentes del equipo on-call
  • Las actualizaciones de esquema antes eran un proceso más largo y de varios pasos. Ahora se mejoraron a un proceso de 3 pasos que toma solo unas horas

Mejor consistencia de datos

• Al eliminar la bifurcación en el flujo de datos, aumentó la confianza en que los datos no divergirán entre distintos almacenes
• Como todos los datos que entran a Redshift primero deben pasar por el Data Lake, se puede garantizar mejor que el Data Lake siga siendo la fuente única de verdad

Conclusión

• Tras el éxito de la migración, estos cambios se aplicaron a unas 12 conjuntos de datos adicionales y, en general, se observaron beneficios similares
• Al aprovechar herramientas como AWS Redshift Spectrum y DBT, se adapta la infraestructura a las necesidades de datos en evolución para ofrecer mayor valor a usuarios y partes interesadas