Buenas Prácticas de Ingeniería de Datos
Cinco cosas a las que vuelvo siempre. Ninguna es ingeniosa, y más o menos ese es el punto.
1. Construí para el año que viene, no para la próxima década
Elegí lo más simple que sobreviva los próximos doce meses. Igual te vas a equivocar con el año tres, y la arquitectura que armaste para eso va a seguir ahí, pidiendo upgrades, en manos de alguien que no estaba en la sala cuando la elegiste. Casi toda la complejidad que tuve que desarmar se había agregado para una escala que nunca llegó.
2. Instrumentá los bordes, no todo
No necesitás una métrica por función. Necesitás saber, en cada salto donde los datos cruzan un límite de sistema, cuántas filas entraron, cuántas salieron y cuándo. Son tres números y un timestamp por etapa, y responden casi todas las preguntas de si está roto o solo lento antes de que alguien abra una notebook.
3. Los controles de calidad van adentro del pipeline
Una suite de tests con su propio schedule te cuenta el problema de ayer. Poné las aserciones en la misma corrida que la transformación y dejá que la hagan fallar. Se siente agresivo durante una semana, y después dejás de mandar datos malos aguas abajo, que era el trato que querías.
4. Anotá el porqué, no el qué
El código dice qué. Nunca dice por qué la conversión de moneda va antes del dedup, ni por qué esa fuente tiene una ventana de 48 horas para datos tardíos y las otras no. Eso se decide una vez, en un hilo de chat, y después vive en la cabeza de alguien hasta que se va. Tres líneas de comentario en la parte rara valen más que una wiki que nadie abre.
5. Hacé el ciclo corto como para usarlo
Si verificar un cambio implica esperar la corrida nocturna, la gente deja de verificar. Datos muestreados, un runner local, lo que sea que lo baje a menos de diez minutos. Los equipos que vi mejorar más rápido no eran los que tenían mejor documentación. Eran los que podían probar algo antes del almuerzo.