Procesamiento de Big Data

Diseñamos plataformas de datos en capas, con interfaces explícitas entre ellas. Una capa de bronce captura fielmente los datos de origen; una capa de plata limpia, conforma y une; una capa de oro expone las entidades y métricas consumidas por analistas, científicos de datos y aplicaciones. Cada capa tiene sus propios propietarios, sus propias expectativas de calidad y sus propias reglas de evolución. La disciplina es poco glamurosa y la recompensa es sustancial: un conjunto de datos que se comporta mal puede localizarse, explicarse y corregirse rápidamente.

Dentro de cada capa utilizamos los formatos de almacenamiento y los motores de consulta que mejor se adaptan a la carga de trabajo. Los formatos Lakehouse — Apache Iceberg, Delta Lake, Apache Hudi — nos permiten cada vez más ejecutar análisis estilo data warehouse en almacenamiento con economía de lago, al tiempo que preservan las propiedades de ingeniería (escrituras ACID, viaje en el tiempo, evolución de esquemas) que requiere el trabajo de producción. Cuando se necesita un rendimiento de data warehouse genuino en la capa dorada, estamos encantados de utilizar marts curados en Snowflake, BigQuery, Redshift o Synapse.

El streaming se trata como un modo de entrega de primera clase en lugar de una ocurrencia tardía. Utilizamos Kafka, Kinesis o Pub/Sub para el transporte, Flink, Spark Structured Streaming o Beam para el procesamiento, e Iceberg o Delta para el aterrizaje, con los mismos controles de calidad y gobernanza de los que disfrutan los pipelines por lotes. Las arquitecturas de estilo Lambda con rutas paralelas por lotes y de streaming son algo que ahora evitamos activamente; el coste operativo rara vez se justifica.

• Diseño en capas bronce / plata / oro
• Formatos de tabla abiertos (Iceberg, Delta, Hudi)
• Ingesta primero en streaming cuando vale la pena
• Almacenamiento nativo de la nube con políticas de ciclo de vida
• Transformaciones reutilizables en dbt o Spark
• ETL inverso a sistemas operativos

La calidad no es un atributo de un conjunto de datos; es un atributo del pipeline que lo produce. Instrumentamos cada transformación con expectativas explícitas — esquema, rangos de valores, integridad referencial, frescura — y tratamos las infracciones como incidentes de primera clase con sus propios manuales de procedimientos. Herramientas como Great Expectations, pruebas dbt y Monte Carlo encuentran un lugar regular en nuestras implementaciones, pero la herramienta importa menos que el compromiso cultural de corregir al productor en lugar de disculparse con el consumidor.

Prestamos especial atención al linaje. Cada tabla importante tiene un diagrama de linaje generado que muestra las fuentes ascendentes, las transformaciones aplicadas y los consumidores descendentes. Cuando un panel se mueve inesperadamente, el analista puede rastrearlo hasta una ejecución de trabajo específica en lugar de esperar a que el equipo de datos investigue. Esta única capacidad elimina una parte significativa de la carga de soporte ad hoc de los equipos de datos.

Los controles de privacidad conviven con los controles de calidad. Los datos personales se identifican en la ingesta, se clasifican y se protegen de acuerdo con la política que los rige. El enmascaramiento, la tokenización y la agregación se aplican a medida que los datos cruzan los límites de las capas, de modo que los datos brutos sensibles nunca llegan a una superficie de consulta que no los necesite. Esta es la forma arquitectónica de la privacidad desde el diseño, y es mucho más económica que adaptar los controles posteriormente.

Los pipelines de datos que parecen elegantes en desarrollo y frágiles en producción suelen compartir la misma causa raíz: nunca fueron diseñados para ser operados. Diseñamos pipelines para que sean idempotentes, reejecutables desde cualquier punto e instrumentados de manera que los incidentes sean fáciles de diagnosticar. Se esperan y absorben los fallos; la recuperación no requiere un ingeniero heroico a las tres de la mañana.

La orquestación está centralizada — típicamente en Airflow, Dagster o Prefect — con convenciones compartidas para el nombramiento, reintentos, alertas y SLAs. Cuando es apropiado, incorporamos objetivos a nivel de servicio en el nivel del producto de datos, de modo que los compromisos de frescura y disponibilidad orientados al consumidor sean explícitos y medidos en lugar de aspiraciones.

Tratamos el coste como una propiedad de la plataforma, no como algo que se nota a fin de mes. La computación y el almacenamiento se perfilan continuamente por trabajo, por equipo y por producto de datos, y la visibilidad resultante tiende a autofinanciarse en un trimestre. Hemos reducido repetidamente el gasto en datos en la nube entre un veinte y un cuarenta por ciento sin sacrificar el rendimiento, simplemente reemplazando patrones derrochadores que el equipo había heredado y nunca medido.

“Un pipeline que no puede operar es un pasivo, no un activo. La operabilidad es parte del diseño, no un paso de pulido.”

Una parte significativa de nuestro trabajo implica trasladar a las organizaciones de plataformas ETL heredadas — Informatica, Ab Initio, scripts de shell escritos a mano, sistemas SSIS obsoletos — a stacks modernos nativos de la nube. Estas migraciones suelen estar limitadas por el hecho de que la plataforma existente, por torpe que sea, está gestionando el negocio; el tiempo de inactividad y las regresiones silenciosas no son aceptables.

Abordamos la migración de sistemas heredados como un programa de ingeniería, no como un "lift-and-shift". Catalogamos lo que realmente se usa (típicamente mucho menos de lo que se construye), identificamos a los consumidores, rediseñamos en lugar de traducir y ejecutamos los sistemas nuevos y viejos en paralelo hasta que la paridad orientada al consumidor haya sido verificada independientemente. Se resiste la tentación de reconstruir todo; el objetivo es migrar valor, no líneas de código.

Cuando corresponde, incorporamos la migración a una modernización más amplia: introduciendo una capa semántica, consolidando la lógica duplicada, pasando de la seguridad a nivel de fila a la seguridad a nivel de columna y retirando la inevitable acumulación de informes zombis. El resultado rara vez es más barato de ejecutar el primer día, pero consistentemente es más barato de cambiar, que es donde realmente reside la mayor parte del gasto en datos.

Los proyectos van desde intervenciones específicas — un caso de uso de streaming que ofrecer, un programa de costes que ejecutar, una migración que evaluar — hasta asociaciones de plataforma multianuales. Nos sentimos igualmente cómodos integrando un pequeño equipo en su grupo de plataforma y asumiendo la entrega discreta de principio a fin, y adaptamos la estructura del contrato (T&M, hitos a precio fijo, servicio gestionado) al modelo que mejor se adapte al trabajo.

No vendemos plataformas ni licencias, y no tenemos preferencia entre proveedores de nube más allá de lo que se adapte a su entorno. Los ingenieros que desplegamos son los ingenieros que conoce. Si identificamos lagunas que no podemos cubrir, lo decimos y le ayudamos a buscar en otro lugar.