Me di cuenta de que mi empresa utiliza un proceso ELT (extracción-transformación-carga) en lugar de utilizar un proceso ETL (extracción-transformación-carga).
¿Cuáles son las diferencias en los dos enfoques y en qué situaciones sería "mejor" que el otro? Sería genial si pudieras proporcionar algunos ejemplos.
Respuestas:
muchas discusiones sobre ETL vs ELT por ahí.
La principal diferencia entre ETL frente a ELT es donde ocurre el procesamiento El procesamiento de datos ETL ocurre en la herramienta ETL (generalmente registro en un momento y en memoria) El procesamiento de datos ELT ocurre en el motor de base de datos
Los datos son iguales y los resultados finales de los datos se pueden lograr en ambos métodos.
depende en gran medida de usted y de su entorno Si tiene un motor de base de datos sólido y un buen hardware y puede realizar un procesamiento pesado en él, ELT es bueno para usted, si tiene un motor de datawarehouse ocupado y necesita liberarlo del procesamiento, vaya para ETL.
tenga en cuenta que tener una herramienta ETL le brinda ambas opciones, como ETL (T), puede hacer la transformación en la herramienta ETL y también puede hacer la transformación en el motor de base de datos
pero ELT solo tiene la opción de transformación en el motor de la base de datos, pero debe saber que las bases de datos son mejores en operaciones basadas en conjuntos que las herramientas de ETL de registro a la vez.
pregunta similar sobre SO pero apoyando ETL y también un buen artículo que compara ETL vs ELT, pero favorece ELT
Es casi una cuestión de semántica. Se discute mucho aire caliente en las discusiones sobre esto, pero no estoy realmente convencido de que haya una profundidad filosófica real para una distinción entre los dos.
En algún nivel, puede ver ETL como datos transformadores en una herramienta del lado del cliente antes de finalmente cargarlo, con ELT lo que implica que los datos se transfieren a algún tipo de área de preparación con relativamente poco cambio en el formato. La 'transformación' tiene lugar después.
Estas son definiciones muy esponjosas y podrían aplicarse a una amplia variedad de arquitecturas técnicas, y hay muchos diseños posibles que cualquiera de los términos podría usarse para describir.
Estoy muy a favor de una arquitectura en la que toda la lógica de transformación y de negocios pueda integrarse en una base de código más o menos homogénea, y he hecho muchos sistemas en los que la lógica de transformación era bastante compleja. Esto solía usar la herramienta ETL para obtener los datos y luego toda la transformación se realizó en procedimientos almacenados. Podría decirse que esto podría describirse como ETL o ELT con la diferencia simplemente de ser una semántica.
Sin embargo, algunas herramientas están muy centradas en la base de datos (Oracle Data Integrator, por ejemplo, a menudo se conoce como una herramienta ELT). Si se suscribe a esta vista, entonces 'Extraer' y 'Cargar' suceden antes de que los datos se transformen a medida que se desembarcan en un área de ensayo y luego se procesan mediante código SQL o PL / SQL (que puede generar la herramienta o escrito a mano). Varias personas con las que he hablado parecen considerar el mérito principal de ODI, ya que no es OWB.
Si utiliza una herramienta del lado del cliente, como Informatica Powercentre o MS SQL Server Integration Services, la herramienta puede realizar una transformación extensa al lado del cliente de datos. Algunas herramientas ETL, como Ascential Datastage y Ab Initio, están diseñadas para hacer mucho trabajo con archivos planos y estructuras de datos en memoria para mayor velocidad. En este tipo de arquitectura, la transformación ya se ha realizado antes de que se cargue. Quizás este tipo de arquitectura podría clasificarse definitivamente como 'ETL', aunque he visto muchos proyectos centrados en herramientas en los que todo el trabajo real se realiza mediante un montón de código de procedimiento almacenado.
Las herramientas y los enfoques arquitectónicos tienen ventajas, pero no se puede hacer una declaración general sobre los méritos de los enfoques 'ETL' versus 'ELT' porque los términos son tan amplios que la diferencia no tiene sentido. Algunas herramientas y arquitecturas pueden tener ventajas específicas, por ejemplo, el uso intensivo de archivos planos por parte de Ab Initio le brinda una ventaja de rendimiento significativa en grandes volúmenes de datos.
En la práctica, hacer la distinción entre 'ETL' y 'ELT' no tiene mucho sentido sin entrar en una discusión mucho más profunda de los requisitos del sistema, la plataforma y la arquitectura técnica.
También es una cuestión de dinero. Cuando los volúmenes de datos son altos como usted señala, las soluciones basadas en archivos planos como Ab Initio y DataStage Parallel Extender son realmente más rápidas, pero pueden ser propuestas de seis cifras entre medias y altas. IRI CoSort está muy centrado en ETL (según su comparación ELT), y la única forma asequible que he visto para abordar el volumen de transformación con la velocidad del sistema de archivos, aparte de una implementación compleja de Hadoop. También creo que lanzar hardware al problema en general (lo que también hacen los dispositivos ELT y los DB en memoria) no escala tan bien en cuanto a costos tampoco.