Introducción

Durante muchos años, los productos de IBM han sido la elección preferida para grandes instituciones (principalmente bancos). Muchos profesionales han compartido historias sobre la durabilidad de los "fierros" de IBM (AS/400) llegando incluso a resistir incendios, caídas desde segundos pisos y otras anécdotas sorprendentes.

La fiabilidad excepcional de estas máquinas, junto con su robustez, seguridad, rendimiento y arquitectura totalmente integrada, hizo que sus clientes no solo confiaran plenamente en sus servidores para la operación de aplicaciones críticas, sino que también adoptaran nuevos productos del portafolio de IBM, preparados para operar en perfecta armonía, como IBM DB2.

Es así como, con el paso del tiempo, los clientes han terminado en una relación de profunda dependencia, tanto en software como hardware. Esta relación se asemeja a un matrimonio en el que ambas partes han acumulado numerosos bienes en común, lo que hace difícil separarse, incluso cuando podría ser beneficioso seguir caminos distintos.

Muchas instituciones financieras enfrentan esta situación con un legado tecnológico pesado. Sin embargo, un hecho llamativo es que, mientras la decomisión de plataformas como Cloudera, SAS o Hortonworks se ha normalizado en el sector, no ocurre lo mismo con IBM. Es poco frecuente ver migraciones desde DB2, y en mi opinión, esto se debe a una dependencia que va más allá del software.

A pesar de todas las barreras para salir de este ecosistema, será cuestión de tiempo antes de que las instituciones opten por adoptar nuevas tecnologías. Y una vez que se marque esa tendencia, no habrá vuelta atrás (opinión personal). Este cambio no ocurrirá solo por mayor eficiencia o menores costos, sino porque los competidores estarán ofreciendo servicios que no podrán igualar, eventualmente expulsándolos del mercado. Por esto mismo hoy, nos adentraremos en un nuevo episodio centrado en uno de los stacks de datos más utilizados en instituciones financieras y en dos de sus componentes principales: IBM DB2 e IBM InfoSphere DataStage.

Visión General de la Estrategia de Migración

Comenzaremos presentando el ecosistema de datos típico en IBM, detallando sus componentes principales y su funcionamiento. A continuación, analizaremos las equivalencias de estos componentes dentro de Databricks. Este análisis nos permitirá comprender cómo llevar a cabo una transición eficiente desde el stack de IBM hacia Databricks.

Una vez establecido este contexto, nos centraremos exclusivamente en dos de los componentes más críticos y ampliamente utilizados del ecosistema de IBM: IBM DB2 e InfoSphere DataStage. Analizaremos en profundidad cómo abordar su migración a Databricks, detallando consideraciones, alternativas y mejores prácticas necesarias para garantizar una transición eficiente y sin interrupciones.

Por el momento, omitiremos otros componentes de la vertical InfoSphere para mantener el enfoque en DB2 y DataStage, que constituyen el core del stack de datos y representan aproximadamente el 80% del proyecto de migración.

Ecosistema de Datos de IBM

La situación se asemeja al blog anterior sobre SAP: nos enfrentamos a un amplio portafolio de productos y servicios, algunos de los cuales han sido reemplazados por otros, lo que añade una capa adicional de complejidad. Sin embargo, al enfocarnos únicamente en la sección de "datos", la explicación se simplifica y resulta mucho más manejable.

IBM DB2: Es una base de datos relacional, ideal para aplicaciones transaccionales y operacionales que requieren alta fiabilidad, rendimiento y seguridad. Lanzada en 1982, DB2 ha evolucionado para soportar diversos sistemas operativos y modalidades de despliegue, incluyendo la nube y entornos híbridos o virtualizados (VMWare).

No sólo es uno de los productos más emblemáticos y antiguos de IBM que siguen vigentes, sino también está muy optimizado para mainframes de IBM y plataforma IBM iSeries ya que está integrado profundamente con el sistema operativo y hardware.

Es fundamental aclarar para evitar confusiones que, aunque IBM DB2 puede utilizarse dentro de un entorno de data warehouse y es común verlo de esta manera, IBM ha desarrollado una versión específica denominada DB2 Warehouse. Esta versión está basada en procesamiento paralelo masivo y diseñado para consultas analíticas.

IBM InfoSphere DataStage y QualityStage: Son dos componentes que trabajan a la par para ofrecer una solución integral en la gestión y modelado de datos. DataStage es la herramienta de ETL que permite integrar datos desde múltiples fuentes y diseñar procesos de transformación complejos. Por su parte, QualityStage se enfoca en la gestión y mejora de la calidad de los datos, con objetivos como limpiar, estandarizar y enriquecer la información.

DataStage y QualityStage están estrechamente integrados. Ambas herramientas comparten una interfaz común, lo que facilita a los usuarios diseñar, gestionar y monitorear procesos que abarcan tanto la integración como la calidad de los datos en un único entorno. En otras palabras, aunque son dos herramientas teóricamente separadas, normalmente funcionan en conjunto dentro de la misma interfaz.

En la captura anterior podemos observar la herramienta, cuyo diseño resulta práctico y funcional. Visualmente, no difiere demasiado de otras herramientas ETL, aunque su apariencia puede parecer algo más anticuada en comparación con las modernas.

IBM InfoSphere Governance Catalog: Es la solución de IBM para la gobernanza de datos, diseñada para catalogar, gestionar y garantizar el cumplimiento de políticas de datos. Proporciona trazabilidad y control de acceso a información sensible.

Es importante destacar la existencia de IBM Cloud Pak for Data, que ha integrado muchas de las capacidades vistas en los componentes clásicos de IBM, convirtiéndose en lo que podríamos considerar su "evolución" dentro del stack de datos, especialmente en entornos híbridos y cloud. En mi experiencia, la mayoría de los clientes de IBM aún utilizan herramientas tradicionales como Governance Catalog o DataStage. Sin embargo, es crucial tener presente que Cloud Pak for Data ofrece una solución parcialmente equivalente, con diferencias en el alcance y funcionalidades, lo que puede generar ciertas variaciones con lo explicado previamente.

IBM Information Analyzer: Es una herramienta diseñada para analizar y evaluar la calidad de los datos dentro de una organización. Su propósito principal es proporcionar a las empresas una visión clara de la estructura, el contenido y la calidad de sus datos, permitiéndoles identificar problemas y oportunidades de mejora. Information Analyzer no sustituye a IBM QualityStage, sino que lo complementa al abordar diferentes aspectos del ciclo de vida de los datos.

Mientras que Information Analyzer se enfoca en analizar y generar métricas detalladas sobre la calidad de los datos, QualityStage utiliza estas métricas para ejecutar procesos de limpieza, estandarización y deduplicación. En conjunto, ambas herramientas forman una solución integral que garantiza datos confiables, consistentes y aptos para análisis y toma de decisiones estratégicas.

IBM InfoSphere Information Server: Es la plataforma central que integra diversas de las herramientas que hemos visto antes de gestión, integración, calidad y gobierno de datos. En otras palabras, DataStage, QualityStage y Information Analyzer forman parte de este ecosistema o agrupación de productos desde un punto de vista arquitectónico denominado Information Server.

Otros: IBM también cuenta con herramientas dentro de su suite de analítica y ciencia de datos, como IBM Cognos Analytics para BI y IBM Watson Studio para desarrollo en ciencia de datos e inteligencia artificial. En este artículo no profundizaremos en estas herramientas, ya que suelen tener una presencia limitada en los stacks de datos de los clientes (aunque Cognos es más frecuente).

Migración a Databricks

Una de las actividades clave al diseñar una arquitectura de destino es comprender el propósito y el rol que cumple cada componente en la arquitectura de origen. Esto asegura que, al proponer una solución nueva, se mantenga la funcionalidad necesaria para satisfacer las necesidades del negocio.

Para lograrlo, es fundamental comparar las funcionalidades de los componentes de la arquitectura actual, descritos en la sección anterior, con sus contrapartes en este caso en Databricks. Es importante señalar que algunas funcionalidades pueden tener múltiples alternativas dentro del ecosistema de Databricks, y pueden complementarse con servicios en la nube o de terceros, lo que permite seleccionar la opción más adecuada según el caso.

Esta versatilidad no es exclusiva de plataformas como Databricks o Snowflake, aunque es más natural en entornos cloud-agnostic. Por ejemplo, en un ecosistema como IBM, también es posible combinar diferentes componentes, pero suelen presentarse barreras inherentes al ecosistema del fabricante, lo que frecuentemente lleva a adoptar "la suite completa" para evitar complicaciones de integración o limitaciones técnicas.

En contraste, en plataformas como Databricks o Snowflake, existe una mayor libertad para integrar herramientas de diversos proveedores (y que funcionen bien). Por ejemplo, se puede utilizar cualquier solución ETL, como Azure Data Factory, AWS Glue, Fivetran o incluso las propias herramientas nativas de la plataforma. Esta flexibilidad permite seleccionar la mejor opción para cada caso, sin estar limitado a un único ecosistema.

Siempre existirán dependencias, pero es casi imposible que se alcance el mismo nivel de dependencia que se tenía en entornos como IBM, debido a la amplia gama de alternativas disponibles, tanto internas como externas, para cada situación y también al no contar con la dependencia hardware, sistema operativo y ecosistema. De hecho, como prueba de esto realizar una migración de Snowflake a Databricks, es bastante sencillo.

Mapa de Componentes Databricks e IBM

A continuación, presentamos las opciones naturales de migración para cada componente del stack de IBM hacia el ecosistema de Databricks. Además, identificamos situaciones específicas donde pueden aplicarse alternativas dentro del entorno de Databricks, ofreciendo flexibilidad según las necesidades de cada caso.

IBM DB2/DB2 Warehouse → Delta Lake en Databricks SQL: Databricks unifica el procesamiento transaccional y analítico dentro de su plataforma Lakehouse, aprovechando Delta Lake para soportar transacciones ACID y consultas analíticas avanzadas en un único entorno. Esto permite gestionar datos estructurados y semiestructurados con alta eficiencia, ofreciendo capacidades modernas para el almacenamiento y análisis en tiempo real, todo integrado en un ecosistema escalable y preparado para la nube.

IBM DataStage → Databricks Workflows & Delta Live Tables: En Databricks, el desarrollo de pipelines de datos difiere significativamente de las interfaces clásicas como IBM DataStage. En lugar de una interfaz gráfica tradicional, Databricks utiliza notebooks interactivos, que resultan más flexibles y amigables, especialmente para los usuarios modernos que prefieren trabajar con código. Además, Databricks incluye un asistente basado en inteligencia artificial generativa, capaz de proporcionar soporte contextualizado al usuario. Este asistente puede sugerir, convertir, corregir y optimizar código, lo que simplifica el desarrollo y mejora la productividad.

La plataforma también amplía las opciones de ingesta de datos mediante la integración con herramientas especializadas como Fivetran o servicios nativos de las nubes, como Azure Data Factory y AWS Glue, ofreciendo alternativas escalables y eficientes para cubrir una amplia gama de necesidades en la integración y transformación de datos.

IBM QualityStage → DQX by Databricks Labs: Lanzado recientemente por Databricks Labs el 21 de enero de 2025. Esta herramienta está diseñada para integrarse de manera fluida en pipelines de datos desarrollados en notebooks o DLT, permite evaluar la calidad de los datos de manera eficiente, proporcionando información detallada sobre por qué filas o columnas específicas presentan problemas de calidad. Además, es compatible tanto con cargas de trabajo por lotes como con flujos de datos en tiempo real, facilitando su integración en diversos entornos de procesamiento de datos.

Adicionalmente, Databricks permite combinar DQX con herramientas externas o librerías especializadas como Great Expectations para cubrir necesidades avanzadas, como validación de esquemas, limpieza y enriquecimiento de datos. Esto asegura que los procesos de calidad no solo sean robustos, sino también escalables en arquitecturas modernas de datos.

IBM InfoSphere Information Analyzer → Databricks Data Profile: Las capacidades de análisis y perfilado de datos de Information Analyzer se pueden abordar parcialmente mediante Databricks Data Profile. Esta herramienta permite a los usuarios realizar un análisis rápido y detallado de los datos almacenados en tablas o DataFrames, proporcionando insights como la distribución de valores, la identificación de columnas nulas, los valores únicos y la detección de anomalías. Para escenarios más avanzados como la detección de patrones complejos o dependencias entre columnas, se puede complementar con herramientas especializadas como Great Expectations.

IBM InfoSphere Governance Catalog → Unity Catalog: Es el componente estrella (junto a Genie) de los últimos años y que probablemente más funcionalidad y alcance gane en el futuro. Centraliza la gobernanza y el catalogado de datos en entornos Lakehouse, permitiendo gestionar metadatos, trazar linajes de datos, administrar controles de acceso y proporcionar una gobernanza integral de manera nativa, transversal y extensible a todos los productos de datos que se desarrollan sobre la plataforma.

IBM Cognos Analytics → Databricks Dashboards/Genie: La herramienta de BI puede quedar fuera del alcance directo de la migración, ya que, si se mantiene el mismo modelo de datos, la transición puede resumirse en una actividad de "conectar y usar". Es decir, es posible migrar a Databricks y continuar utilizando IBM Cognos, Qlik, o cualquier herramienta de BI de preferencia, sin interrupciones significativas.

Alternativamente, Databricks también ofrece opciones internas como Databricks Dashboard, integrado en la plataforma, para crear visualizaciones directamente (si se quiere con lenguaje natural). Además, herramientas avanzadas como Genie permiten interactuar con los datos de manera conversacional, añadiendo un nivel de accesibilidad y simplicidad para los usuarios no técnicos.

IBM Watson Studio → Databricks Machine Learning: Databricks es la plataforma por excelencia para científicos de datos, ofreciendo una solución completa y unificada para gestionar el ciclo de vida de modelos de ML e IA. El equipo puede trabajar de forma colaborativa en notebooks interactivos, utilizando el lenguaje de programación de su preferencia y sus librerías favoritas.

Además, Databricks proporciona acceso a recursos de CPU y GPU para el entrenamiento de modelos, integrando herramientas como MLflow para el tracking, registro y despliegue de modelos, y AutoML para pruebas rápidas y optimización automática. La plataforma también incluye Apps para publicar aplicaciones, facilitando la interacción y el despliegue de soluciones, entre muchas otras funcionalidades.

IBM Streams → Structured Streaming en Databricks: Es su equivalente, aunque no son exactamente iguales. IBM Streams es una solución para flujos de datos mientras que Structured Streaming tiene un alcance mayor al unificar el procesamiento por lotes y en tiempo real en una única plataforma. Simplifica mucho la gestión y la complejidad. Está completamente integrado sobre la plataforma y simplemente es un "método" más para la gestión de datos. Es una solución más moderna, escalable y performante.

Ahora que hemos analizado y comparado ambos ecosistemas, es momento de abordar cómo realizar la migración de los dos componentes principales: IBM DB2 y DataStage, hacia la plataforma Databricks.

IBM DB2 a Databricks

omo toda migración, el reto no se encuentra en la copia de datos ni en la conexión entre sistemas sino en la planificación, la buena gestión de las variables que suelen complicar o retrasar estos proyectos (y muchas veces no dependen de uno, como los accesos por parte del cliente o el ancho de banda, ventanas de mantenimiento, dependencias, etc), y la definición de una estrategia controlada, que no afecte a la operación del cliente y que permita avanzar paulatinamente por fases.

En este sentido, es esencial contemplar aspectos como la coordinación de ventanas de mantenimiento con el cliente, la gestión de dependencias entre sistemas que comparten la base de datos, la calidad de la conexión o el ancho de banda disponible para no saturar la red, los planes de contingencia en caso de fallos, la validación y pruebas de la información (conteos, checksums, integridad referencial), y las responsabilidades de cada equipo involucrado en la migración.

Solo así se puede asegurar una transición ordenada, minimizando riesgos para la operación y evitando retrasos ocasionados por factores externos a la mera copia de datos. Desde un punto de vista técnico y de integración de datos, IBM Db2 es sencillamente otra base de datos, por lo que no presenta una complejidad especial en cuanto al acceso a la información. Existen tres alternativas principales:

Crear una conexión JDBC hacia Db2
Emplear una herramienta de ETL (ADF, Fivetran, Talend o equivalente)
Realizar una exportación directa de archivos planos para su posterior carga en el Data Lake

Usualmente, la opción más recomendable es el uso de una herramienta de ETL, ya que ofrece conectores listos para usar y facilita la gestión de algunas de las variables del entorno; además, es poco frecuente que la migración se limite a un solo proceso ("one-shot"). Lo que probablemente genere mayores dolores de cabeza, sobre todo si el cliente cuenta con un alto nivel de burocracia (y lo será porque tu cliente probablemente sea un banco), será la configuración relacionada con redes y seguridad. Para ello, es fundamental definir en conjunto con el cliente cómo se llevará a cabo la conexión con la instancia de Db2 (ya sea a través de una VPN, una VPC o una conexión segura).

Una vez los datos ya se encuentren en el data lake se deberán realizar las actividades típicas que aplican a cualquier proceso de migración entre plataformas (pueden consultar nuestros otros blogs). Por ejemplo: mapeo de tipos de datos asegurando que coincidan con los atributos originales, validar la necesidad de limpiar datos, formatear columnas, normalizar codificaciones o eliminar columnas, registrar las tablas en catálogos, aplicar pruebas de calidad y validaciones, entre otros.

IBM InfoSphere DataStage a Databricks

El proceso de migración de DataStage es más consultivo que técnico. Me explico, la actividad principal aquí estará más vinculada al análisis de procesos, revisión de transformaciones, análisis de dependencias (scripts, secuencias UNIX/Windows, triggers y otros procesos externos) y luego la refactorización de flujos en la nueva plataforma.

Probablemente nos encontremos con procesos ETL transaccionales y otros analíticos. En este tipo de clientes, normalmente los críticos son los transaccionales y son los más complejos pero a la vez los que más demandan recursos y que más se pueden aprovechar de una plataforma como Databricks por lo que muchas veces es recomendable empezar por ahí.

Es muy útil apoyarse de aceleradores que permitan mapear e interpretar los procesos de origen y ayudar en la refactorización de código. En SunnyData tenemos nuestro propio acelerador de migraciones basado en GenIA que reduce entre un 60% y 80% los plazos de proyecto automatizando el discovery y mapeo de procesos, conversión de procesos y las validaciones - pruebas (actualmente en proceso de certificación como Brickbuilder Solutions).

En el próximo post profundizaremos en la perspectiva arquitectónica, ofreciendo un "paso a paso" detallado para enfrentar la migración de IBM Db2 y DataStage a Databricks. ¡Los esperamos la próxima semana!

Migración de IBM DB2 y DataStage a Databricks (Parte 1)

¿Por qué nadie migra de Databricks a Snowflake?

El Caos de los Datos: Cómo la Fragmentación Está Frenando la Innovación