Métodos de integración de datos: ETL, ELT y sincronización por eventos

Cuando dos sistemas de una empresa necesitan los mismos datos, hay tres formas habituales de moverlos: ETL, ELT y sincronización por eventos. Elegir entre ellas tiene menos que ver con la moda y más con cuatro preguntas: qué tan actualizados tienen que estar los datos, qué tan limpios, quién puede verlos y qué pasa cuando una ejecución falla. Esta guía explica cada método en términos simples y muestra las partes que suelen romperse: reintentos, duplicados y cambios de esquema.

Las herramientas de integración no son almacenes de datos

Los artículos más viejos sobre este tema, incluida nuestra versión anterior, mezclaban dos tipos de producto.

• Las herramientas de integración mueven datos. Por ejemplo, plataformas de conectores como Airbyte, herramientas de flujos como n8n, Make o Zapier, y herramientas de captura de cambios de datos (CDC) como Debezium.
• Los almacenes de datos y las bases de datos guardan datos y te permiten consultarlos. Por ejemplo, una base Postgres, BigQuery o Snowflake.

Si querés reportes que crucen varios sistemas, por lo general necesitás una de cada tipo. Si solo necesitás que una aplicación reaccione a otra, por ejemplo crear una factura cuando se cierra una venta, puede que no necesites un almacén de datos.

Los tres métodos en términos simples

ETL: extraer, transformar, cargar

Los datos se sacan del origen, se limpian y se reorganizan en el camino, y después se cargan en el destino. El destino solo ve la versión terminada.

Elegilo cuando el destino no debería guardar datos crudos, por ejemplo cuando tenés que quitar campos personales antes de que algo llegue a una base de reportes compartida, o cuando el destino es otra aplicación de negocio que espera un formato fijo.

ELT: extraer, cargar, transformar

Los datos se cargan crudos en el almacén primero y después se transforman ahí, con SQL o con una herramienta de transformación.

Elegilo cuando querés conservar el historial crudo y cambiar la lógica de tus reportes más adelante sin volver a extraer. Un malentendido común es que ELT significa tiempo real. No es así. ELT describe dónde ocurre la transformación, no cada cuánto se mueven los datos. La mayoría de los procesos ELT corren con una frecuencia fija, cada hora o cada noche, y los datos están tan actualizados como la última ejecución.

Sincronización por eventos

En lugar de consultar con una frecuencia fija, el origen envía un mensaje cuando pasa algo: un webhook cuando se paga un pedido, o un evento de cambio cuando se actualiza una fila en una base de datos. Las herramientas de captura de cambios como Debezium describen su trabajo como capturar los cambios a nivel de fila en tus bases de datos y publicarlos como un flujo de eventos que otras aplicaciones pueden leer.

Elegila cuando un sistema que recibe los datos tiene que reaccionar en segundos o minutos, por ejemplo para actualizar el stock, avisarle a un cliente o iniciar un paso de preparación de pedidos.

Tabla de decisión

Muchas empresas terminan usando dos métodos: eventos para las acciones operativas y ELT para los reportes.

Reintentos e idempotencia

Toda integración va a tener fallas. La pregunta es si un reintento causa daño.

La documentación de webhooks de Stripe es un buen modelo de lo que podés esperar de cualquier fuente de eventos. Dice que Stripe reintenta los eventos no entregados con espera exponencial durante hasta tres días en modo activo, que los endpoints a veces reciben el mismo evento más de una vez y que no garantiza que los eventos lleguen en el orden en que se generaron. Su consejo: registrar los ID de los eventos que ya procesaste y saltear los que ya viste, devolver una respuesta de éxito rápido antes de hacer el trabajo lento y procesar los eventos a través de una cola.

Convertí eso en reglas para cualquier integración que armes:

1. Dale a cada registro una clave estable del sistema de origen y escribí con "insertar o actualizar" sobre esa clave, en lugar de inserciones simples.
2. Mantené una tabla de los ID de eventos o lotes ya procesados. Revisala antes de actuar.
3. No dependas del orden de llegada. Si el orden importa, pedí el estado actual a la API del origen antes de escribir.
4. Confirmá la recepción rápido y después hacé el trabajo en una cola, así un sistema lento del otro lado no hace que el emisor reintente.
5. Mandá las fallas que se repiten a una lista aparte que revisa una persona, en lugar de reintentar para siempre.

Un paso idempotente es uno que podés correr dos veces con el mismo resultado que si lo corrieras una sola vez. Si todos los pasos son idempotentes, los reintentos dejan de dar miedo.

Cambios de esquema

Los orígenes cambian. Se renombra un campo, se agrega una columna, un tipo pasa de número a texto. Decidí de antemano qué tiene que hacer tu proceso.

La documentación de Airbyte muestra las opciones que suele ofrecer una plataforma de conectores para cada conexión: propagar solo los cambios de campos, propagar todos los cambios de campos y de flujos, detectar los cambios pero esperar a que una persona los apruebe, o frenar las próximas sincronizaciones cuando se detecta cualquier cambio. También trata algunos cambios como incompatibles, por ejemplo eliminar una clave primaria o un campo cursor, y pausa la conexión para revisión manual sin importar la configuración.

Para un equipo chico, una configuración razonable por defecto es aprobar a mano los cambios en todo lo que alimente datos de finanzas o datos que ven los clientes, y avisarle a una persona con nombre cuando se detecta un cambio. Si tu herramienta de flujos no tiene esa opción, agregá un control que compare los campos entrantes con una lista esperada y frene si no coinciden.

Revisá la licencia y la disponibilidad antes de elegir

Los listados de herramientas envejecen mal. Los productos cambian de licencia, los compran otras empresas o eliminan su plan gratuito. Antes de comprometerte:

• Leé la licencia en la documentación oficial. Por ejemplo, las preguntas frecuentes sobre licencias de Airbyte dicen que la plataforma usa la Elastic License 2.0, que entre otras cosas prohíbe ofrecer el producto a terceros como servicio administrado. Eso importa si pensás alojarlo para clientes, no si lo usás para tu propia empresa.
• Confirmá que el conector que necesitás existe y tiene mantenimiento, y quién lo mantiene.
• Revisá dónde guarda los datos el servicio y si eso coincide con lo que esperan tus clientes y con tus obligaciones.
• Mirá vos mismo la página de precios actual. No te bases en los números de los artículos.

Checklist de recuperación

• ¿Podés volver a correr el proceso de ayer sin generar duplicados?
• ¿Podés reenviar los eventos desde un momento determinado si el receptor estuvo caído?
• ¿Comparás la cantidad de registros entre origen y destino de forma periódica?
• ¿Hay una persona con nombre que recibe el aviso de falla?
• ¿Hay una nota escrita sobre cómo completar los datos faltantes después de una caída larga?

Dónde entra automotif

Esto es trabajo de desarrollo de automatizaciones: diseñamos y armamos la sincronización entre tus sistemas en tus propias cuentas, con n8n, Make o Zapier cuando sirven y con código cuando no, con reintentos, eliminación de duplicados y avisos de falla desde el principio. Para mapear tus sistemas y tus flujos de datos con nosotros, reservá una llamada gratis de 30 a 60 minutos.

Fuentes

• Recibe los eventos de Stripe en tu punto de conexión de webhook
• Schema change management (Airbyte Docs)
• License FAQ (Airbyte Docs)
• Debezium Documentation