Modernización de datos empresariales: Hadoop, Netezza y el cambio de rumbo de las plataformas de datos

El estado del entorno de datos

Entra en el entorno de datos de cualquier banco de primer nivel y encontrarás capas de historia. Un mainframe. Un almacén Oracle adquirido en los años 2000. Un sistema Netezza comprado para dar cabida a los informes regulatorios. Un clúster Hadoop creado por un equipo de analítica. Cargas SAS. Tableau. SQL Server. Una presencia creciente en Azure o AWS. Cada capa fue la respuesta correcta al problema que alguien tenía el día que la compró.

El trabajo del arquitecto de datos empresariales no consiste en reemplazar todo eso por una plataforma hermosa. Consiste en trazar los límites: qué cargas pertenecen a qué plataforma, qué plataformas son estratégicas, cuáles son tácticas y cuáles han llegado al final de su vida útil. Después, con la misma importancia, consiste en hacer respetar esos límites —asesorando, aprobando y recomendando la elección de plataforma para cada iniciativa nueva.

Hadoop como zona estratégica de recepción

Hadoop fue la apuesta estratégica para cargas nuevas y no estructuradas. El esquema en lectura permitía recibir datos sin procesar sin negociar primero un esquema de destino; HDFS y el metastore de Hive nos dieron una ubicación física única para las uniones entre dominios; el ecosistema abierto (Spark, Hive, Impala y cuadernos de análisis posteriores) dio a cada equipo de analítica la flexibilidad necesaria sin crear infraestructura a medida.

La regla arquitectónica que redactamos era sencilla: si una nueva carga recibe datos de eventos sin procesar, une distintos dominios o sirve a científicos de datos que necesitan cómputo flexible, la plataforma elegida es Hadoop. Si genera informes regulatorios por fila sobre un almacén especializado estrictamente modelado, se queda donde está.

Netezza como motor táctico de trabajo

No hacía falta reemplazar Netezza. Hacía falta dejar de acumular cargas para las que no estaba diseñado. El sistema sigue siendo excelente en lo suyo: SQL estructurado, basado en conjuntos y con formas predecibles sobre tablas de hechos de varios terabytes. Almacenes regulatorios especializados, informes financieros y agregación de riesgos: todas eran buenas cargas para Netezza y todas se quedaron.

Lo que retiramos de Netezza fueron cargas que nunca debieron estar allí: análisis exploratorios ad hoc sobre flujos de eventos sin procesar, uniones entre dominios que debían haberse realizado en una zona de recepción y preparación ETL que utilizaba el almacén como tabla temporal. Retirarlas permitió a Netezza cumplir mejor su función real.

El árbol de decisiones para seleccionar plataformas

Aprobar la elección de plataformas para nuevas iniciativas requiere un árbol de decisiones reproducible, no una reunión. El que utilizamos:

• ¿Son informes regulatorios sobre un almacén especializado modelado? → Sistemas de almacenamiento existentes (Netezza u Oracle).
• ¿Recibe datos de eventos sin procesar y con esquemas flexibles? → Zona de recepción de Hadoop.
• ¿Es una carga transaccional? → Base de datos operativa, no el conjunto de almacenes.
• ¿Es un análisis exploratorio basado en cuadernos? → Hadoop con acceso de solo lectura a almacenes especializados modelados mediante federación.
• ¿El conjunto de datos es nuevo y el consumidor es nativo de la nube? → Plataforma de datos en la nube, con un flujo unidireccional deliberado hacia el entorno local.

Ese árbol, junto con una revisión de arquitectura de datos empresariales al inicio de cada iniciativa, evitó la proliferación descontrolada del entorno. El árbol es más importante que las elecciones tecnológicas que produce.

Gobernanza sin burocracia

La gobernanza de datos tiene mala reputación porque a menudo se presenta como políticas sin medios para aplicarlas. La versión que funciona en un banco de primer nivel es aquella en la que la gobernanza entrega herramientas y controles junto con las políticas: un catálogo de metadatos realmente actualizado, un esquema de clasificación de datos aplicado durante la ingesta, trazabilidad automática en lugar de mantenida manualmente y una vía clara de escalamiento para las excepciones que siempre existen.

Nuestro papel como arquitectos de datos empresariales fue tender un puente entre el equipo de gobernanza y los equipos de entrega. Gobernanza fijaba las reglas; nosotros nos asegurábamos de que siempre se reflejaran en la elección de plataforma. Los proyectos que lo hicieron bien fueron más rápidos, no más lentos, porque no tuvieron que rehacer su capa de datos seis meses después.

Qué implica esto para tu estrategia de datos

• No busques la única plataforma perfecta. Busca el límite adecuado entre dos o tres de ellas.
• Retira cargas de trabajo para desmantelar plataformas. La plataforma se reduce de forma natural cuando dejas de enviarle el trabajo equivocado.
• Revisa la arquitectura al principio, no al final. Aprobar pronto la elección de plataforma cuesta diez veces menos que reconstruir.
• Trazabilidad y clasificación desde la ingesta. Incorporarlas después es la forma más costosa de deuda técnica en un entorno de datos.
• La nube es un destino, no una fecha límite. Migra las cargas que se beneficien; conserva donde están las demás.

¿Estás replanteando tu entorno de datos?

SEYSO ha asesorado sobre arquitectura de datos empresariales a bancos de primer nivel: selección de plataformas, retirada de duplicados y gobernanza de entornos de datos multiplataforma. Si te enfrentas a una proliferación de almacenes, un clúster Hadoop infrautilizado o una migración de datos a la nube que necesita organizarse por etapas, nos encantará conversar.