Un flujo de datos es un sistema automatizado que traslada los datos de los sistemas de origen a un destino para analizarlos. Resuelve un problema común para las empresas que se basan en los datos: cómo procesar y analizar información útil que está dispersa en muchos sistemas diferentes. El flujo de datos puede mover los datos de forma fiable y repetida.

A continuación, explicaremos qué es un flujo de datos, cómo funciona, en qué difieren los enfoques de lotes y de streaming, y cómo encajan los datos de pago en la configuración de un flujo de datos.

Destacados

• Un flujo de datos reemplaza las exportaciones manuales y los procesos ad hoc que fallan bajo presión.

• La elección entre los flujos de datos por lotes y de streaming depende de lo actualizados que deban estar tus datos. Las cargas de trabajo de finanzas y análisis suelen ejecutarse cómodamente por lotes.

• Los datos de pago requieren un cuidado especial en la configuración del flujo de datos. Una sincronización nativa de tu proveedor de servicios de pago mejora la seguridad y la fiabilidad.

¿Qué es un flujo de datos?

Un flujo de datos es una secuencia automatizada de pasos que extrae datos de una o más fuentes, los transforma (de manera opcional) y los carga en un destino donde pueden analizarse o utilizarse para ejecutar operaciones. El destino suele ser un almacén de datos, un lago de datos o un almacenamiento en la nube.

¿Por qué son importantes los flujos de datos para la elaboración de informes y la toma de decisiones?

El valor de un flujo de datos es lo que se vuelve posible cuando tus datos están en un lugar donde puedes usarlos. Los flujos de datos crean las siguientes ventajas:

• Reducción de los silos de datos: Cuando tus datos están divididos entre sistemas (por ejemplo, los datos de ingresos residen en tu proveedor de servicios de pago, los datos de los clientes residen en tu sistema de gestión de relaciones con los clientes (CRM) y los datos de soporte residen en tu servicio de asistencia técnica), no puedes responder fácilmente a las preguntas que cruzan esos límites. Un flujo de datos que centralice esas fuentes hace posible el análisis interdisciplinar.

• Definiciones coherentes: Los flujos de datos imponen una estructura. Si todos los equipos extraen información de las mismas tablas de almacén, que se calculan de la misma manera, las métricas como los ingresos recurrentes mensuales (MRR) se definen de manera uniforme en todos los informes, y no hay debate sobre las cifras de quién son las correctas.

• Procesos repetibles y auditables: Los flujos de datos producen resultados comparables día tras día. Esa repetibilidad permite realizar un seguimiento de las métricas a lo largo del tiempo e investigar las anomalías cuando aparecen.

• Ciclos de elaboración de informes más rápidos: Los equipos financieros que antes pasaban días extrayendo y conciliando datos pueden acortar sustancialmente el ciclo cuando los datos ya se encuentran en el almacén, depurados y estructurados.

¿Cuáles son los componentes principales de un flujo de datos?

Muchos flujos de datos, independientemente de su complejidad, se crean a partir del mismo conjunto de componentes básicos. Estos son los componentes que importan:

• Fuentes: Donde se originan los datos, lo que incluye las bases de datos, las interfaces de programación de aplicaciones (API) de software como servicio (SaaS), los flujos de eventos y los archivos planos. Cuantas más fuentes extraiga un flujo de datos, más importante será hacer un seguimiento del esquema y la fiabilidad de cada una de ellas, y de la frecuencia con la que cambia la fuente.

• Ingesta: El mecanismo de extracción de datos de las fuentes al flujo de datos. Esto podría significar consultas a la base de datos programadas, una suscripción a un flujo de webhooks o un conector de terceros. La ingesta es, a menudo, el punto donde se interrumpen los flujos de datos (p. ej., las API cambian, las credenciales caducan, las fuentes fallan), de modo que las capas de ingesta se diseñan para detectar y subsanar los errores.

• Transformaciones: El paso que transforma los datos en bruto en una forma útil desde el punto de vista analítico. Por ejemplo, las transformaciones limpian registros y eliminan duplicados, combinan datos de varias fuentes, calculan campos derivados o imponen un esquema coherente en sistemas que no comparten uno de forma nativa.

• Organización: La capa que gestiona las dependencias y la programación. Si la tabla B depende de que la tabla A esté completamente cargada, la capa de organización debe saberlo y aplicar el orden. Herramientas como Apache Airflow, Prefect y data build tool (dbt) pueden encargarse de este tipo de gestión de dependencias.

• Destinos: Dónde aterrizan los datos procesados. Por lo general, se trata de un almacén de datos en la nube como Snowflake o Redshift, o almacenamiento en la nube como S3 o Google Cloud Storage (GCS). La elección del destino determina el tipo de análisis que se puede realizar a posteriori.

¿En qué se diferencian los flujos de datos por lotes y los de streaming?

Para el movimiento de datos, tanto el streaming como el procesamiento por lotes tienen usos legítimos. La elección correcta depende de lo obsoletos que puedan ser tus datos antes de que causen un problema real.

Flujos de datos por lotes

Mueven los datos de forma programada (p. ej., cada hora, por la noche, cada semana). Se adaptan bien a cargas de trabajo en las que la latencia no es importante, como los informes financieros mensuales, los análisis de cohortes de clientes semanales y las sincronizaciones nocturnas con un almacén de datos. El procesamiento por lotes suele ser más fácil de crear y utilizar. Además, para muchos casos de uso de análisis, es exactamente lo que necesitas.

Flujos de datos de streaming

Procesan los datos de forma continua, a medida que se producen los eventos, con una latencia medida en segundos o milisegundos en lugar de en horas. Se crean para casos de uso en los que actuar con datos obsoletos tiene costes reales, como la detección de fraude, el seguimiento de inventario en tiempo real y los paneles de control en tiempo real.

Antes de elegir esta ruta para el movimiento de datos, determina la capacidad de tu equipo. La infraestructura de streaming es más cara y más difícil de depurar. Si tu equipo de datos es pequeño, los gastos generales de un flujo de datos de streaming podrían superar las ventajas que ofrece la latencia.

¿Qué relación tienen los flujos de datos, las ETL y las ELT entre sí?

Aunque un flujo de datos es cualquier sistema automatizado que traslada los datos de un origen a un destino, la extracción, transformación y carga (ETL), así como la extracción, carga y transformación (ELT) son dos patrones que estructuran ese movimiento. Así es como funcionan.

ETL

ETL significa que los datos se transforman antes de cargarlos en el destino. La transformación se produce en una capa intermedia, por lo que solo la información estructurada y depurada llega al almacén. Este fue el patrón dominante cuando el almacenamiento era caro y los almacenes no estaban bien preparados para tratar los datos en bruto a escala.

ELT

Con ELT, estos últimos pasos se invierten. Los datos en bruto se extraen y se cargan en el almacén, y la transformación se lleva a cabo mediante el lenguaje de consulta estructurado (SQL) o una herramienta como dbt. Los almacenes modernos en la nube son lo bastante asequibles para almacenar datos sin procesar y lo bastante potentes para transformarlos en el momento de realizar la consulta o como una tarea programada. ELT se ha convertido en el patrón más habitual para las cargas de trabajo analíticas, en parte porque conserva los datos en bruto para volver a procesarlos y facilita la auditoría, el control de versiones y la modificación de las transformaciones.

No todos los flujos de datos encajan de forma exacta en una u otra categoría. Algunos trasladan datos sin casi ninguna transformación; sincronizan registros de eventos (logs) en bruto procedentes de una API con el almacenamiento en la nube para procesarlos posteriormente. La terminología es útil como abreviatura de la intención de la arquitectura y no como una taxonomía precisa.

¿Cómo encaja un proveedor de servicios de pago en una configuración de flujo de datos?

Los datos de pago suelen encontrarse entre los datos más valiosos y complicados del almacén de una empresa. Por lo general, los equipos pasan por la misma progresión cuando intentan gestionarlos.

Exportaciones de valores separados por comas (CSV)

Muchos equipos empiezan con exportaciones CSV. Descargan informes, los limpian y los suben al almacén. Pero las exportaciones fallan, los esquemas cambian o alguien olvida ejecutar el proceso. Como resultado, los datos históricos a menudo faltan o son incoherentes.

Conectores ETL de terceros

A continuación, recurren a herramientas que extraen (Pull) datos de una API de pago y los cargan en un almacén de forma programada. Estas herramientas son razonablemente fiables, pero introducen a un proveedor en un flujo de datos confidencial. Si una empresa tiene datos financieros que pasan por un sistema de terceros adicional, eso ampliará su superficie de ataque, creará consideraciones de cumplimiento de la normativa y producirá datos que podrían ser sutilmente diferentes de los que tiene su proveedor de servicios de pago.

Sincronización nativa a través de Stripe Data Pipeline

Stripe Data Pipeline permite una sincronización directa con Stripe que mueve los datos a un almacén o destino de almacenamiento en la nube sin un conector de terceros. La configuración lleva solo unos pocos clics, no es necesario escribir código y el flujo de datos incluye datos históricos de la cuenta de Stripe de un usuario. También incluye informes sintetizados seleccionados y conjuntos de datos seleccionados, como resúmenes financieros estructurados y tablas preparadas para el análisis para analizar el MRR, el fraude y mucho más. Los propios sistemas de Stripe los generan y un conector genérico no puede replicarlos.