Saltar al contenido

Por qué el futuro de ETL no es ELT, sino EL (T) – DZone Big Data

La forma en que almacenamos y administramos los datos ha cambiado por completo durante la última década. Pasamos de un mundo ETL a un mundo ELT, con empresas como Fivetran impulsando la tendencia. Sin embargo, no creemos que se detenga ahí; ELT es una transición en nuestra mente hacia EL (T) (con EL desacoplado de T). Y para entender esto, necesitamos discernir las razones subyacentes de esta tendencia, ya que podrían mostrar lo que nos espera en el futuro.

Esto es lo que haremos en este artículo. Soy el cofundador de Airbyte, el nuevo estándar de código abierto para integraciones de datos.

¿Cuáles son los problemas con ETL?

Históricamente, el proceso de canalización de datos consistía en extraer, transformar y cargar datos en un almacén o lago de datos. Hay serias desventajas en esta secuencia.

ETL es inherentemente rígido. Obliga a los analistas de datos a conocer de antemano todas las formas en que van a utilizar los datos, cada informe que van a producir. Cualquier cambio que hagan puede ser costoso. Potencialmente, puede afectar a los consumidores de datos posteriores a la extracción inicial.

Falta de visibilidad

Cada transformación realizada en los datos oculta parte de la información subyacente. Los analistas no verán todos los datos del almacén, solo el que se mantuvo durante la fase de transformación. Esto es arriesgado, ya que se pueden sacar conclusiones basadas en datos que no se han dividido adecuadamente.

Falta de autonomía para los analistas

Por último, pero no menos importante, la creación de una canalización de datos basada en ETL a menudo está más allá de las capacidades técnicas de los analistas. Por lo general, requiere la participación cercana de talentos de ingeniería, junto con código adicional para extraer y transformar cada fuente de datos.

La alternativa a un proyecto de ingeniería complejo es realizar análisis y generar informes sobre una base ad hoc, que requiere mucho tiempo y, en última instancia, es insostenible.

Qué cambió y por qué ELT es mucho mejor

Computación y almacenamiento de datos basados ​​en la nube

El enfoque ETL alguna vez fue necesario debido a los altos costos de la computación y el almacenamiento locales. Con el rápido crecimiento de los almacenes de datos basados ​​en la nube, como Snowflake, y el costo cada vez más bajo de la computación y el almacenamiento basados ​​en la nube, hay pocas razones para continuar con la transformación antes de cargar en el destino final. De hecho, cambiar los dos permite a los analistas hacer un mejor trabajo de forma autónoma.

ELT admite la toma de decisiones ágil para los analistas

Cuando los analistas pueden cargar datos antes de transformarlos, no tienen que determinar de antemano exactamente qué conocimientos quieren generar antes de decidir el esquema exacto que necesitan obtener.

En cambio, los datos de origen subyacentes se replican directamente en un almacén de datos, que comprende una “fuente única de la verdad”. Luego, los analistas pueden realizar transformaciones en los datos según sea necesario. Los analistas siempre podrán volver a los datos originales y no sufrirán transformaciones que podrían haber comprometido la integridad de los datos, dándoles libertad de acción. Esto hace que el proceso de inteligencia empresarial sea incomparablemente más flexible y seguro.

ELT promueve la alfabetización de datos en toda la empresa

Cuando se usa en combinación con herramientas de inteligencia empresarial basadas en la nube como Looker, Mode y Tableau, el enfoque ELT también amplía el acceso a un conjunto común de análisis en todas las organizaciones. Los paneles de inteligencia empresarial se vuelven accesibles incluso para usuarios relativamente no técnicos.

También somos grandes admiradores de ELT en Airbyte. Pero ELT no está resolviendo completamente el problema de integración de datos y tiene sus propios problemas. Creemos que EL debe estar completamente desacoplado de T.

Qué está cambiando ahora y por qué EL (T) es el futuro

Fusión de Data Lakes y Almacenes

Andreessen Horowitz realizó un gran análisis sobre cómo están evolucionando las infraestructuras de datos. Aquí está el diagrama de arquitectura de la infraestructura de datos moderna que se les ocurrió después de muchas entrevistas con líderes de la industria.

La infraestructura de datos tiene dos propósitos a un alto nivel:

Ayuda a los líderes empresariales a tomar mejores decisiones mediante el uso de datos: casos de uso analítico

Incorpora inteligencia de datos en aplicaciones orientadas al cliente, incluso a través del aprendizaje automático: casos de uso operativo

Han surgido dos ecosistemas paralelos en torno a estos amplios casos de uso.

El almacén de datos forma la base del ecosistema de análisis. La mayoría de los almacenes almacenan datos en un formato estructurado. Están diseñados para generar conocimientos a partir de métricas comerciales centrales, generalmente con SQL (aunque Python está ganando popularidad).

El lago de datos es la columna vertebral del ecosistema operativo. Al almacenar datos sin procesar, ofrece la flexibilidad, la escala y el rendimiento necesarios para las aplicaciones y las necesidades de procesamiento de datos más avanzadas. Los lagos de datos operan en una amplia gama de lenguajes, incluidos Java / Scala, Python, R y SQL.

Lo que es realmente interesante es que los almacenes de datos y los lagos de datos modernos están empezando a parecerse entre sí: ambos ofrecen almacenamiento de productos básicos, escalado horizontal nativo, tipos de datos semiestructurados, transacciones ACID, consultas SQL interactivas, etc.

Por lo tanto, es posible que se pregunte si los almacenes de datos y los lagos de datos están en camino hacia la convergencia. ¿Se volverán intercambiables en una pila? ¿Se utilizarán también los almacenes de datos para el caso de uso operativo?

EL (T) admite ambos casos de uso: análisis y aprendizaje automático operativo

EL, a diferencia de ELT, desacopla completamente la parte Extracto-Carga de cualquier transformación opcional que pueda ocurrir.

Los casos de uso operativo son únicos en la forma en que se aprovechan los datos entrantes. Algunos pueden usar un proceso de transformación único; algunos ni siquiera utilizan ninguna transformación.

Con respecto al caso de análisis, los analistas deberán normalizar los datos entrantes para sus propias necesidades en algún momento. Pero desacoplar EL de T les permitiría elegir la herramienta de normalización que deseen. DBT ha estado ganando mucha tracción últimamente entre los equipos de ingeniería de datos y ciencia de datos. Se ha convertido en el estándar de código abierto para la transformación. Incluso Fivetran se integra con ellos para permitir que los equipos usen DBT si están acostumbrados.

EL escala más rápido y aprovecha todo el ecosistema

La transformación es donde se encuentran todos los casos extremos. Para cada necesidad específica dentro de cualquier empresa, existe un esquema de normalización único, para todas y cada una de las herramientas.

Al desacoplar EL de la T, esto permite a la industria comenzar a cubrir la larga cola de conectores. En Airbyte, estamos construyendo una “planta de fabricación de conectores” para que podamos llegar a 1000 conectores prefabricados en cuestión de meses.

Además, como se mencionó anteriormente, ayudaría a los equipos a aprovechar todo el ecosistema de una manera más fácil. Empieza a ver un estándar de código abierto para cada necesidad. En cierto sentido, la arquitectura de datos futura podría verse así:

Al final, la extracción y la carga se desacoplarán de la transformación. ¿Estás de acuerdo?

Este contenido se publicó originalmente aquí.