Divulgación completa:dado que este artículo está escrito por una empresa centrada en ETL con su punto fuerte en la manipulación de big data fuera de las bases de datos, lo que sigue no parecerá objetivo para muchos. Sin embargo, todavía tiene la intención de presentar elementos de reflexión y abre el debate.
Desde sus inicios, a los arquitectos de almacenamiento de datos (DWA) se les ha encomendado la tarea de crear y llenar un almacenamiento de datos con datos de fuentes y formatos dispares. Debido al espectacular crecimiento de los volúmenes de datos, estos mismos DWA tienen el desafío de implementar sus operaciones de integración y preparación de datos de manera más eficiente. La cuestión de si la transformación de datos ocurrirá dentro o fuera de la base de datos de destino se ha vuelto crítica debido al rendimiento, la conveniencia y las consecuencias financieras involucradas.
En las operaciones ETL (extracción, transformación, carga), los datos se extraen de diferentes fuentes, se transforman por separado y se cargan en una base de datos DW y posiblemente en otros destinos. En ELT, los extractos se introducen en la base de datos de preparación única que también maneja las transformaciones.
ETL sigue prevaleciendo porque el mercado prospera con jugadores probados como Informatica, IBM, Oracle e IRI con Voracity, que combina transformaciones FACT (Fast Extract), CoSort o Hadoop y carga masiva en la misma GUI de Eclipse para extraer y transformar datos. Este enfoque evita sobrecargar las bases de datos diseñadas para almacenamiento y recuperación (optimización de consultas) con la sobrecarga de la transformación de datos a gran escala.
Sin embargo, con el desarrollo de nuevas tecnologías de base de datos y dispositivos de hardware como Oracle Exadata que pueden manejar transformaciones "en una caja", ELT puede ser una solución práctica en ciertas circunstancias. Y hay beneficios específicos para aislar las capas de preparación (carga) y semántica (transformación).
Una ventaja citada de ELT es el aislamiento del proceso de carga del proceso de transformación, ya que elimina una dependencia inherente entre estas etapas.
Notamos que el enfoque ETL de IRI los aísla de todos modos porque Voracity organiza los datos en el sistema de archivos (o HDFS). Cualquier fragmento de datos vinculado a la base de datos se puede adquirir, limpiar y transformar externamente antes de una carga (preclasificada). Esto elimina la carga de las transformaciones a gran escala de la base de datos (así como las herramientas analíticas/BI, etc.).
Los volúmenes de datos y los presupuestos suelen ser lo que determina si un DWA debe desarrollar una solución ETL o ELT. En su artículo de blog de ITToolbox "¿Qué es mejor, ETL o ELT?", Vincent McBurney plantea sus pros y contras de cada enfoque, que he repetido a continuación, y luego siguió cada uno con una respuesta típica que IRI ETL los usuarios orientados hacen el punto (según mi advertencia inicial de subjetividad):
ETL profesionalContra ETL
- ETL puede equilibrar la carga de trabajo y compartir la carga de trabajo con el RDBMS, y, de hecho, eliminar esa carga de trabajo al transformar los datos mediante el programa SortCL o Hadoop sin codificación en Voracity
- ETL puede realizar operaciones más complejas en diagramas de flujo de datos únicos a través de mapas de datos, como con el mapeo de Voracity y los diagramas de flujo de trabajo que también resumen cortos y abiertos Scripts 4GL frente a SQL
- ETL puede escalar con hardware separado:en cajas de productos básicos que puede obtener y mantener a costos mucho más bajos que los dispositivos de un solo proveedor
- ETL puede manejar la partición y el paralelismo independientemente del modelo de datos, el diseño de la base de datos y la arquitectura del modelo de datos de origen, a través de los trabajos CoSort SortCL de Voracity no es necesario dividirlo en absoluto...
- ETL puede procesar datos in-stream, ya que se transfieren del origen al destino, o por lotes, si eso también tiene sentido
- ETL no requiere la ubicación conjunta de conjuntos de datos para hacer su trabajo, lo que le permite mantener las plataformas de fuentes de datos existentes sin preocupaciones de sincronización de datos
- ETL captura enormes cantidades de linaje de metadatos en la actualidad. ¿Qué tan bien o intuitivamente puede hacer eso una base de datos provisional?
- ETL puede ejecutarse en hardware SMP o MPP, que nuevamente puede administrar y explotar de manera más rentable, y no preocuparse por la disputa de rendimiento con la base de datos
- ETL procesa la información fila por fila y eso parece funcionar bien con la integración de datos en productos de terceros; mejor aún bloque completo, tabla o archivo(s) a la vez, que Voracity ejecuta en volumen.
ELT para profesionales
- Se necesita una inversión de hardware adicional para los motores ETL, a menos que lo ejecute en los servidores de la base de datos
- Costo adicional de construir un sistema ETL o licenciar herramientas ETL, que aún son más baratas en relación con los dispositivos ELT, pero aún más baratas son las herramientas IRI como Voracity que combinan Fast Extract (FACT) y CoSort para acelerar ETL sin tanta complejidad
- Posible rendimiento reducido del enfoque basado en filas:correcto, y por qué la capacidad de Voracity para perfilar, adquirir, transformar y generar datos en fragmentos más grandes es más rápida
- Se requieren habilidades especializadas y curva de aprendizaje para implementar la herramienta ETL, a menos que esté utilizando una GUI ergonómica como la de Voracity, que brinda múltiples opciones de diseño de trabajo en el mismo IDE de Eclipse
- Flexibilidad reducida debido a la dependencia del proveedor de la herramienta ETL. No estoy seguro de cómo se mejora al confiar en un solo proveedor de ELT/dispositivo en su lugar; ¿No es la independencia del proveedor la clave para la flexibilidad y el ahorro de costes?
- Los datos deben viajar a través de una capa más antes de aterrizar en el data mart, a menos que el mart fuera solo otro resultado del proceso ETL, típico de las operaciones Voracity de varios objetivos.
Contra ELT
- ELT aprovecha el hardware del motor RDBMS para la escalabilidad, pero también grava los recursos de la base de datos destinados a la optimización de consultas. Las transformaciones de CoSort y Hadoop en Voracity aprovechan los algoritmos de escalado lineal y la consolidación de tareas, no la memoria o los recursos de E/S de la base de datos.
- ELT mantiene todos los datos en el RDBMS todo el tiempo, lo cual está bien siempre que los datos de origen y de destino estén en la misma base de datos
- ELT se paraleliza de acuerdo con el conjunto de datos, y la E/S del disco generalmente se optimiza a nivel del motor para un rendimiento más rápido. sí, pero eso es aún más cierto en el caso de las transformaciones externas que no compiten con los recursos del servidor de la base de datos
- ELT se escala siempre que el hardware y el motor RDBMS puedan continuar escalando, ¿cuánto cuesta en relación con la alternativa anterior?
- ELT puede lograr entre 3 y 4 veces las tasas de rendimiento en la plataforma MPP RDBMS correctamente ajustada, lo que coloca el dispositivo en los niveles de rendimiento de Voracity en relación con las herramientas ETL también, pero a un costo 20 veces mayor.
- La transformación de ELT se realiza en el servidor RDBMS una vez que la base de datos está en la plataforma de destino y ya no ejerce presión sobre la red – ¿Entonces ejerce presión sobre la base de datos (usuarios)?
- ELT tiene especificaciones de transformación simples a través de SQL, que no son tan simples, flexibles o ricas en funciones como la sintaxis de CoSort SortCL o el mapeo de campos de arrastrar y soltar en la GUI de Eclipse de Voracity.
- Herramientas limitadas disponibles con soporte completo para ELT, y a precios muy altos para dispositivos DB que promocionan un rendimiento de alto volumen
- Pérdida de estadísticas detalladas de monitoreo en tiempo de ejecución y linaje de datos, especialmente análisis de impacto de metadatos en cambios en archivos, tablas o fuentes no estructuradas dispares
- Pérdida de modularidad debido al diseño basado en conjuntos para el rendimiento:y la pérdida de funcionalidad/flexibilidad que se derivan de ello
- Las transformaciones utilizarían los recursos de la base de datos, lo que podría afectar el rendimiento de los informes de BI, sin mencionar el rendimiento de las consultas y otras operaciones de la base de datos
Las arquitecturas híbridas como ETLT, TELT e incluso TETLT están surgiendo posteriormente en un intento de reforzar las debilidades en cualquiera de los enfoques. Pero estos parecen agregar niveles adicionales de complejidad a los procesos que ya son tan complicados. Realmente no existe una panacea y muchos proyectos de integración de datos fallan debido al peso de los SLA, los sobrecostos y la complejidad.
Es por estas razones que IRI creó Voracity para integrar datos a través del programa CoSort SortCL en sistemas de archivos existentes o estructuras de Hadoop sin volver a codificar. Voracity es la única plataforma orientada a ETL (aunque también compatible con ELT) que ofrece ambas opciones para transformaciones de datos externos. Además de una relación precio-rendimiento superior en el movimiento y la manipulación de datos, Voracity incluye:
- transformación avanzada de datos, calidad de datos, MDM e informes
- dimensiones que cambian lentamente, captura de datos modificados, federación de datos
- perfilado de datos, enmascaramiento de datos, generación de datos de prueba y gestión de metadatos
- secuencias de comandos 4GL simples que usted o los asistentes, diagramas y cuadros de diálogo de Eclipse crean y administran
- ejecución perfecta en Hadoop MR2, Spark, Spart Stream Storm y Tez
- soporte para erwin Smart Connectors (conversión de otras herramientas ETL)
- controladores nativos de MongoDB y conexiones a otras fuentes NoSQL, Hadoop, en la nube y heredadas
- informes integrados, estadísticas y funciones predictivas, conexiones de KNIME y Splunk, y fuentes de datos de herramientas analíticas .
Véase también:
- http://www.iri.com/blog/data-transformation2/etl-elt-iri-in- between
- http://www.iri.com/solutions/data-integration/etl
- http://www.iri.com/solutions/data-integration/elt
- http://www.iri.com/solutions/data-integration/implement
