Cloud, Data Lake, Big Data, IA, Streaming, DevOps, protección de datos y seguridad… estas evoluciones incorporadas en los últimos años a nuestros sistemas de información han tenido un fuerte impacto en las arquitecturas de datos.
En este contexto, la integración de datos debe también llevar a cabo su revolución. Puede que usted utilice todavía un ETL tradicional..
Usted dirige entonces un hombre orquesta, impresionante y eficaz en su área, pero que dispone de un número limitado de instrumentos y capacidades.
El ETL está en el corazón del sistema y debe plegarse a numerosas exigencias y a evoluciones incesantes.
Su agilidad es puesta a prueba, la justificación de su costo es desafiada.
La constatación es cada vez más unánime: la plataforma de integración del Chief Data Officer (Director de Sistemas de Datos), o su equivalente, debe hoy por hoy parecerse más a un director de orquesta que a un hombre orquesta.
El objetivo no es que haga todo por sí solo, sino coordinar de manera inteligente los recursos disponibles y optimizarlos.
Esta serie de artículos (éste es el primero) tendrá como objetivo comprender los retos actuales de la integración de datos y de medir los impactos sobre la manera en la que una solución informática debe utilizar el dato en la actualidad.
ELT versus ETL ¿un viejo debate cerrado desde hace tiempo?
Recuerda quizás el viejo debate ELT versus ETL que apareció durante los años 2000.
Todavía es posible consultar en Internet y en la prensa los rastros de este tipo de debate, he aquí por ejemplo un artículo de BFM TV de 2005 que explica los méritos de una solución francesa de esa época.
Cuando aparecieron los primeros ETL (Extract Transform & Load), ya habían aparecido los primeros críticos, partidarios de la línea de código, predicando a cuerpo y alma que nada podía compararse a un buen script escrito a mano.
Este desacuerdo sigue siendo de actualidad y ¿le recuerda quizás algunas discusiones acaloradas pero todavía actuales sobre muchos otros temas aparte del ETL?
La herramienta ETL se ha impuesto, sin embargo, como una evidencia.
Permite industrializar y estandarizar los procesos de integración de datos a la escala de toda la organización y hacer abstracción del Sistema de Información existente, proponiendo un lenguaje de transformación único.
Pero de manera bastante rápida, en ciertas configuraciones, el volumen de datos manipulados ha obligado a ciertos usuarios, y luego a ciertos desarrolladores, a proponer una alternativa a los motores ETL.
Esta alternativa consistía en desplazar el lugar de transformación de los datos hacia el destino sin utilizar el motor propietario para la transformación.
Es el famoso enfoque ELT (Extract Load & Transform).
Con este enfoque, los datos se cargan en la base de datos de destino, luego se transforman y se controlan en el destino, y ya no en un motor intermedio.
La transformación se ha desplazado del motor hacia los sistemas de bases de datos. Recurrir a este tipo de arquitectura es, todavía hoy, en gran medida justificado por la necesidad de mayor rendimiento.
Ya que cada enfoque tiene sus ventajas, hubiésemos podido creer que el debate estaba cerrado desde hace tiempo.
Así como en el mundo material (hardware) tenemos quienes son Mac y quienes son PC, en el mundo de la data, hay quienes son ETL y quienes ELT. Debate cerrado. Cada quien con su enfoque.
Pero esto sería así sin no tomásemos en cuenta las evoluciones incorporadas durante los últimos años a nuestros sistemas de información.
El debate no estaba cerrado sino parcialmente, esperando la primera ocasión para resurgir con fuerza..
- ¿Qué ha pasado?
- ¿Cuáles son las evoluciones que han suscitado una nueva forma de debate en torno a la transformación?
- Primeramente, la emergencia de la Nube (Cloud) y los proyectos de Big Data
La arquitectura de Nube (Cloud) y el Big Data vuelven a poner el balón en juego
La arquitectura de Nube (Cloud) y el Big Data vuelven a poner el balón en juego
De acuerdo a Gartner, "de aquí al 2022 hasta el 60% de las organizaciones utilizarán ofertas de servicios manejados desde la nube por un proveedor de servicios externo, el doble del porcentaje con respecto a 2018" *fuente
Esto implica numerosas evoluciones en la arquitectura global del Sistema de Información (SI) y, por lo tanto, de los flujos de datos.
En primer lugar, la Nube conduce a una descentralización de las infraestructuras y, sobre todo, de los datos.
No es raro ver aparecer sistemas de información cada vez más distribuidos, con componentes en sitio (on premise) y componentes en la Nube. El enfoque SaaS ha llevado a numerosas organizaciones hacia una separación cada vez más importante de sus aplicaciones en silos de información.
Uno casi podría pensar que la Nube ha destruido al ERP tradicional, o que este último no juega ya un papel tan central en los sistemas… Pero este es otro debate, puede que para otro artículo.
La constatación es innegable: ¡El SI de los años 2020 está masivamente descentralizado!
El dato se despacha en silos de aplicación, repartido por el mundo.
Se comprende que en esta situación el uso de un motor de transformación, por su esencia misma centralizado, plantea una primera interrogante: ¿en dónde vamos a colocar el motor? ¿Debe estar "on Premise"? ¿Debe estar en la Nube?
Y posicionarlo en la Nube lo que hace no es acaso desplazar el problema y plantear una nueva interrogante: ¿en cuál Nube?
¡Hablamos hoy en día de sistema multinube o de Nube Híbrida! No es poco habitual el ver cohabitar, en el seno de una misma organización, a componentes de Google, con Nubes privadas, y en algún lugar aplicaciones SaaS propietarias.
Se plantea una verdadera pregunta sobre la arquitectura y, detrás de esta pregunta, problemáticas de seguridad y de costos que están lejos de ser insignificantes.
En este contexto, un enfoque sin motor de transformación (ELT) se posiciona entonces como una nueva alternativa.
De hecho ¡esto elmina a la vez la pregunta sobre la arquitectura y sobre el costo!
Igualmente, la opción de posicionar una aplicación o una solución informática en la Nube implica al menos dos necesidades inmediatas: será necesario migrar el patrimonio de datos hacia esta nueva aplicación de tipo Nube; luego habrá que integrar de manera confiable y eficaz esta nueva aplicación con el resto del sistema de información.
Se presentan entonces nuevas preguntas: ¿debo continuar utilizando mi solución ETL o EAI (Enterprise Application Integration) tradicional? ¿ésta es compatible?¿es suficiente? ¿El ROI (retorno de inversión) está asegurado? ¿O más bien debo optar por una alternativa completamente en la nube? Entonces voy a eliminar los silos de mis aplicaciones, haciendo que se comuniquen, pero pagando un precio: ¡crear silos de integración de datos que tengan varias soluciones informáticas para necesidades muy similares!
Aún así, en esta situación, el ELT se plantea como una alternativa real.
Inútil desplegar cualquier cosa nueva en la Nube.
Adicionalmente, aparte de la Nube, otros elementos han venido a cambiar por completo la arquitectura de los sistemas de información y por lo tanto, de la integración de datos: el Big Data, y detrás, implícitamente, todos los proyectos de ciencia de datos, y luego de ingeniería de datos.
Efectivamente, incluso por definición, se trata de proyectos de transformación del dato. Hadoop, con su concepto de Map Reduce, es una manera de transformar los datos. Pero entonces, ¿dónde ubicamos el ETL en este caso? ¿Cuál es el valor agregado en un proyecto de Big Data?
Spark o Storm, ¿son estos también, en esencia, motores de transformación de datos?
Se entiende que, a fin de cuentas, los algoritmos de procesamiento del Big Data naturalmente hacen las veces de un ETL.
Si se quiere resumir el argumento: Spark, Google BigQuery, Snowflake, Big Table, Kafka, Flink… cada una de estas herramientas a veces es mil veces más potente que el ETL que utilizaba en los años 90. ¿El Big Data ha acabado con el ETL tradicional haciéndolo obsoleto?
Por esto hemos tenido que pasar del hombre orquesta al director de orquesta. El hombre orquesta trataba de hacer todo, corría detrás de la música.
El director de orquesta distribuye, coordina y optimiza el trabajo de los músicos de su orquesta.
Consideremos la plataforma de integración como un director de orquesta y la potencia de las diferentes herramientas de nuestro sistema de información como los diferentes instrumentos adaptados a cada situación
¿Qué hay del ELT? Ha tenido que reinventarse pero está en su elemento, a saber, generar y organizar código: Java, Spark, Python, incluso SQL específico a estos entornos.
¿Estará siempre a la orden del día para industrializar y maximizar el rendimiento? Este será el tema de nuestro próximo artículo...
Continuación del artículo próximamente "El rendimiento y la industrialización, los elementos clave de la delegación de las transformaciones"
Acerca del autor:
Fabien BRUDER, cofundador de la sociedad Stambia desde 2009.
Ingeniero informático de la EPITA, especializado en inteligencia artificial, es diplomado en gestión de empresas en el IAE de París.
Después IBS France (integrador), luego Sagent (desarrollador), pasa 7 años en la empresa de desarrollo Sunopsis (Oracle) como asesor, director técnico y luego director de agencia.
Acumula 20 años trabajando como experto en el área de integración de datos..