SoundCloud sustituyó 100 ETL no documentados por una gobernanza de datos de seis principios

A mediados de 2019, el almacén de datos de SoundCloud era el resultado de seis años de decisiones que ya no tenían sentido: un único equipo pequeño era responsable de más de 100 canalizaciones ETL en Amazon Redshift, la mayoría con poca documentación e inconsistencias entre ellas, de modo que los equipos de negocio y de producto no podían autoservirse los datos de forma fiable. Un contrato para migrar a Google BigQuery dio al equipo una razón para empezar de cero, pero un intento anterior de migración de tipo «lift and shift» a principios de 2018 ya se había abortado una vez.

El nuevo equipo de Data Corpus redactó una declaración de misión y seis principios de gobernanza antes de reconstruir las tablas: calidad, cumplimiento, puntualidad, usabilidad, eficiencia y mantenibilidad, adaptados de una norma ISO. La calidad implicaba una herramienta que compara una nueva versión de un ETL con la desplegada, de modo que solo aparezca el cambio previsto. La puntualidad implicaba mapear los tiempos de llegada de cada ETL y sus dependencias; desacoplar una tabla necesaria de otra más lenta sin relación eliminó cuatro horas de la canalización. La mantenibilidad implicaba un «principio del 80 por ciento»: construir para la mayoría de las solicitudes, no para los casos extremos.

La reconstrucción se hizo por etapas: una versión intermedia de Corpus en diciembre de 2019 todavía leía del almacén antiguo, Corpus Alpha en abril de 2020 fue la primera versión totalmente independiente de él, y Corpus 1.0 en julio de 2020 fue la primera versión que satisfacía los seis principios. Para Corpus 2.2 en abril de 2021, el proyecto de BigQuery resultante usaba aproximadamente un 90 por ciento menos de almacenamiento que los datos brutos de los que leía, mientras que las partes interesadas con conocimientos básicos de SQL podían autoservirse la mayoría de las preguntas mediante tablas documentadas y descritas.

Escribir los principios de gobernanza antes de escribir una sola tabla

La comparación automatizada de versiones convierte «¿este cambio rompió algo aguas abajo?» de una decisión de criterio en la revisión de código en una comprobación mecánica que se ejecuta en cada actualización de ETL.

El principio del 80 por ciento dio al equipo una respuesta permanente a los debates sobre la ampliación del alcance, de modo que las tablas se mantuvieron lo bastante simples para que las consultaran personas no expertas, en lugar de acumular complejidad para casos extremos.

Mapear las dependencias de los ETL y los tiempos de llegada convirtió una vaga queja de «los datos a veces llegan tarde» en una corrección concreta, desacoplar dos tablas, con una mejora medida de cuatro horas.

Publicar en versiones por etapas a lo largo de aproximadamente 18 meses, cada una evaluada con los mismos seis principios, permitió al equipo aprender las funciones de BigQuery antes de tomar decisiones de diseño que eran las más difíciles de revertir.

Cuando migres un sistema que creció sin documentación, escribe los principios que impiden que el nuevo se deteriore de la misma manera y luego convierte cada uno en una comprobación automatizada, no en una directriz que nadie aplica.

SoundCloud siguió publicando más versiones de Corpus después de la 2.2, ampliando la cobertura de tablas a medida que evolucionaba el producto, en lugar de tratar el modelo de gobernanza como un entregable de migración único. El equipo enmarca Corpus como un proyecto en evolución continua y espera explícitamente que el diseño actual acabe pareciendo tan obsoleto como el almacén anterior a la migración, manteniendo los mismos principios como marco permanente para decidir cuándo cambiarlo.