Capítulo 1. Ingestión de datos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

La ingestión de datos, en esencia, consiste en transferir datos de una fuente a un destino designado. Su objetivo principal es introducir los datos en un entorno preparado para la puesta en escena, el procesamiento, el análisis y la inteligencia artificial/aprendizaje automático (IA/AM). Mientras que las organizaciones masivas pueden centrarse en mover datos internamente (entre equipos), para la mayoría de nosotros, la ingestión de datos hace hincapié en extraer datos de fuentes externas y dirigirlos a objetivos internos.

En una era en la que los datos tienen una importancia central tanto en el desarrollo empresarial como en el de productos, no se puede exagerar la importancia de disponer de datos precisos y oportunos. Esta mayor dependencia de los datos ha dado lugar a una multitud de "fuentes" de las que los equipos extraen información para perfeccionar los procesos de toma de decisiones, elaborar productos excepcionales y llevar a cabo multitud de otras acciones. Por ejemplo, un equipo de marketing necesitaría recuperar datos de varias plataformas de publicidad y análisis, como Meta, Google (incluidos Ads y Analytics), Snapchat, LinkedIn y Mailchimp.

Sin embargo, con el paso del tiempo, las API y las fuentes de datos sufren modificaciones. Es posible que se introduzcan o eliminen columnas, que se cambie el nombre de los campos y que nuevas versiones sustituyan a las obsoletas. Manejar los cambios de una sola fuente puede ser factible, pero ¿qué hay de hacer malabarismos con las alteraciones de múltiples fuentes -cinco, diez o incluso cien-? El reto apremiante es el siguiente: "¿Cómo puede un equipo de datos en ciernes manejar eficazmente estas diversas fuentes de forma coherente y ampliable?" Como ingenieros de datos, ¿cómo garantizamos nuestra reputación de proporcionar un acceso a los datos fiable y sencillo, especialmente cuando las demandas de cada departamento aumentan continuamente?

Ingestión de datos: ahora y antes

Aunque los principios de la ingestión siguen siendo en gran medida los mismos, muchas cosas han cambiado. A medida que evolucionan el volumen, la velocidad y la variedad de los datos, también deben hacerlo nuestros métodos.

Hemos tenido múltiples cambios en la industria para adaptarnos a esto: el paso a la nube, del almacén al lago de datos, y la simplificación de las tecnologías de flujo, por nombrar algunos. Esto se ha manifestado como un cambio de los flujos de trabajo extraer-transformar-cargar (ETL) a extraer-cargar-transformar (ELT), siendo la diferencia clave que ahora todos los datos se cargan en un sistema de destino. Hablaremos de estos entornos en el contexto de la transformación en el Capítulo 2.

Nos abstenemos de ser demasiado pedantes sobre los términos ETL y ELT; sin embargo, nos gustaría destacar que casi todos los flujos de trabajo modernos de ingeniería de datos implicarán la puesta en escena de casi todos los datos en la nube. La excepción notable son los casos en los que se procesan a diario cientos de billones de filas de datos altamente granulares (por ejemplo, datos del Internet de las Cosas [IoT] o de sensores), en los que tiene sentido agregar o descartar datos antes de la puesta en escena.

A pesar de los constantes cambios, la verdad fundamental de la extracción es que los datos se extraen de una fuente y se escriben en un destino. Por tanto, el debate en torno a la extracción debe centrarse precisamente en eso.

Fuentes y objetivos

Aunque la mayoría asocia la ingesta con la extracción, también está estrechamente relacionada con la carga; después de todo, cada fuente requiere un destino. En esta guía, asumimos que tienes un almacén o lago de datos establecido; por tanto, el almacenamiento no será un tema principal en este capítulo. En su lugar, destacaremos tanto las buenas prácticas para la puesta en escena como las características de las implementaciones ideales de almacenamiento.

Nuestra misión es dotarte de un conjunto de herramientas para el diseño de la arquitectura, teniendo en cuenta que puede que no exista una solución "perfecta". Navegaremos por un marco para valorar las fuentes y desenredar los singulares nudos de la ingestión de datos. Nuestro enfoque de alto nivel está diseñado para ofrecerte una visión a vista de pájaro del panorama, permitiéndote tomar decisiones informadas y adecuadas.

La Fuente

Nuestra principal consideración para la ingesta de datos es la fuente y sus características. A menos que tengas mucha suerte, habrá muchas fuentes. Cada una debe evaluarse por separado para garantizar los recursos adecuados y establecer los criterios para tu(s) solución(es) de ingestión.

Con el enorme volumen de fuentes de datos y la naturaleza de los requisitos empresariales (rara vez me han pedido que elimine fuentes, pero añadir una es un jueves más), es muy probable que te encuentres con una o muchas fuentes que no encajan en una única solución. Aunque generar confianza lleva semanas, meses y años, puede perderse en un día. Una ingesta fiable y puntual es primordial. Entonces, ¿qué es importante a la hora de elegir una fuente?

Examinar las fuentes

Como guía práctica, adoptamos el enfoque de presentar preguntas de eficacia probada que te guiarán hacia la comprensión de los datos de origen, tanto de sus características como de la forma en que la empresa obtendrá valor.

Recomendamos adoptar una postura muy crítica: siempre es posible que los datos de origen no sean necesarios o que una fuente diferente se adapte mejor a la empresa. Tú eres el experto en datos de tu organización, y es tu trabajo comprobar y volver a comprobar los supuestos. Es normal inclinarse por la acción y la complejidad, pero es imperativo considerar el esencialismo y la simplicidad.

Cuando examines las fuentes, ten en cuenta que es probable que trabajes con ingenieros de software en datos anteriores, pero las consideraciones posteriores son igual de importantes. Descuidarlas puede resultar muy costoso, ya que es posible que tu error no se manifieste hasta que hayan pasado semanas de trabajo.

Preguntas que debes hacer

¿Con quién trabajaremos?

En la era de la inteligencia artificial, damos prioridad a la inteligencia real. La parte más importante de cualquier canalización de datos son las personas a las que servirá. ¿Quiénes son las partes interesadas? ¿Cuáles son sus motivos principales? Los objetivos y resultados clave o los mandatos organizativos pueden ser útiles para alinear los incentivos y hacer avanzar rápidamente los proyectos.

¿Cómo se utilizarán los datos?

Estrechamente ligado al "quién", el modo en que se utilizarán los datos debería guiar en gran medida las decisiones posteriores. Es una forma de comprobar los requisitos de las partes interesadas y conocer el "problema que hay detrás del problema" que intentan resolver. Recomendamos encarecidamente una lista de requisitos técnicos sí/no para evitar ambigüedades.

¿Cuál es la frecuencia?

Como discutiremos en detalle más adelante, la mayoría de los profesionales saltan inmediatamente a lote frente a flujo. Cualquier dato puede procesarse como lote o como flujo, pero comúnmente nos referimos a las características de los datos que nos gustaría transmitir. Abogamos por considerar primero si los datos son acotados o no acotados, esdecir, si son finales (por ejemplo, el conjunto de datos de la Encuesta sobre la Comunidad Estadounidense del Censo de 2020), o si son continuos (por ejemplo, los datos de registro de un armario de fibra).

Una vez considerados los límites, la frecuencia mínima disponible establece un límite duro para la frecuencia con la que podemos extraer información de la fuente. Si una API sólo se actualiza a diario, existe un límite duro en la frecuencia de tus informes. Los límites, la velocidad y los requisitos empresariales determinarán la frecuencia con la que decidamos extraer los datos.

¿Cuál es el volumen de datos previsto?

El volumen de datos ya no es un limitador de la capacidad de almacenarlos; después de todo, "el almacenamiento es barato" y, aunque la informática puede ser costosa, es menos cara que nunca (por un factor de millones; véanse las Figuras 1-1 y 1-2). Sin embargo, el volumen informa estrechamente sobre cómo elegimos escribir y procesar nuestros datos y sobre la escalabilidad de nuestra solución deseada.

Figura 1-1. Costes de los discos duros por GB, de 1980 a 2015 (Fuente: Matt Komorowski); los valores del eje y están en escala logarítmica
Figura 1-2. Coste de computación, millones de instrucciones por segundo (MIPS) (Fuente: Field Robotics Center); los valores del eje y están en escala logarítmica
¿Cuál es el formato?

Aunque al final elegiremos un formato para el almacenamiento, el formato de entrada es una consideración importante. ¿Cómo se entregan los datos? ¿A través de una carga útil de Notación de Objetos JavaScript (JSON) sobre una API? ¿Quizá a través de un servidor FTP? Si tienes suerte, ya viven en alguna base de datos relacional. ¿Qué aspecto tiene el esquema? ¿Existe un esquema? El interminable número de formatos de datos mantiene interesante nuestro medio de vida, pero también supone un reto.

¿Cuál es la calidad?

La calidad del conjunto de datos determinará en gran medida si es necesaria alguna transformación. Como ingenieros de datos, nuestro trabajo consiste en garantizar conjuntos de datos coherentes para nuestros usuarios. Puede que sea necesario procesar mucho los datos o incluso enriquecerlos a partir de fuentes externas para completar las características que faltan.

Utilizaremos estas características para responder a nuestra pregunta final:

¿Cómo se almacenarán los datos?

Como ya hemos mencionado, este libro asume algún destino fijo para tus datos. Aun así, hay algunas consideraciones clave en el almacenamiento de datos: organizar o no organizar (¿es realmente una pregunta?), los requisitos empresariales y la adecuación a las partes interesadas son las más importantes.

Lista de control de fuentes

Para cada fuente que encuentres, ten en cuenta estas preguntas orientativas. Aunque pueda parecer desalentador a medida que se amontona el número de fuentes, recuerda: no se trata de una tarea de redacción. Es un marco para desentrañar los retos de cada fuente, ayudándote a esbozar soluciones adecuadas que alcancen tus objetivos.

Aunque pueda parecer repetitivo, este trabajo previo ahorra tiempo y recursos a largo plazo.

Pregunta Ejemplo
¿Con quién colaboraremos? Ingeniería (Pagos)
¿Cómo se utilizarán los datos? Informes financieros y elaboración de estrategias trimestrales
¿Hay varias fuentes? Sí
¿Cuál es el formato? API semiestructuradas (Stripe e internas)
¿Cuál es la frecuencia? Por horas
¿Cuál es el volumen? Aproximadamente 1.000 nuevas filas/día, con una reserva existente de ~100.000
¿Qué tratamiento se requiere? Ordenación de datos, como renombrar columnas, y enriquecimiento a partir de fuentes suplementarias
¿Cómo se almacenarán los datos? Almacenamiento de datos por etapas en tablas Delta mediante Databricks

El destino

Aunque los sistemas de extremo a extremo requieren consideraciones hipotéticas que son sólo eso, suponemos que la mayoría de los lectores tendrán la tarea de construir una tubería en un sistema existente, donde la tecnología de almacenamiento ya está elegida.

La elección de la tecnología de almacenamiento de datos está fuera del alcance del enfoque de esta guía, pero consideraremos brevemente los destinos, ya que son muy importantes para el valor total creado por un sistema de datos. Así, al analizar (o considerar) un destino, recomendamos utilizar una lista de comprobación similar a la de una fuente. Normalmente, hay muchos menos destinos que fuentes, por lo que éste debería ser un ejercicio mucho más sencillo.

Examinar los destinos

Un elemento diferenciador clave en los destinos es que se da prioridad a las partes interesadas. Los destinos tienen un rasgo único: pivotan en torno a las partes interesadas. Estos destinos alimentan directamente las aplicaciones BI, analíticas y de IA/ML, o las impulsan indirectamente cuando se trata de datos por etapas, por no hablar de las aplicaciones orientadas al usuario. Aunque recomendamos la misma lista de comprobación, sugerimos enmarcarla ligeramente hacia la parte interesada para asegurarnos de que cumple sus requisitos, al tiempo que se trabaja hacia los objetivos de ingeniería.

Somos plenamente conscientes de que esto no siempre es posible. Como ingeniero, tu papel es elaborar la solución más adecuada, aunque eso signifique llegar a un término medio o admitir que no hay una respuesta clara. A pesar de los increíbles avances de la tecnología, algunos dilemas lógicos no tienen soluciones sencillas.

Puesta en escena de los datos ingeridos

Abogamos por un enfoque de lago de datos para la ingestión de datos. Esto implica ingerir la mayoría de los datos en sistemas de almacenamiento en la nube, como S3, Google Cloud Platform o Azure, antes de cargarlos en un almacén de datos para su análisis.

Un paso más allá es un lakehouse, que aprovecha los protocolos de almacenamiento de datos, como Delta Lake, que utilizan metadatos para añadir rendimiento, fiabilidad y capacidad ampliada. Los almacenes de lago pueden incluso replicar algunas funcionalidades del almacén; esto significa evitar la necesidad de cargar datos en un sistema de almacén independiente. La incorporación de una capa de gobierno de datos, como Unity Catalog de Databricks, puede mejorar la capacidad de descubrimiento, la gestión del acceso y la colaboración para todos los activos de datos de una organización.

Una práctica predominante y eficaz para almacenar datos es utilizar formatos de archivo basados en Parquet y centrados en metadatos, como Delta Lake, Apache Iceberg o Apache Hudi. Basados en Parquet -un formato comprimido y columnar diseñado para grandes conjuntos de datos-, estos formatos incorporan una capa de metadatos, que ofrece funciones como el desplazamiento en el tiempo, el cumplimiento de ACID (atomicidad, consistencia, aislamiento y durabilidad), etc.

La integración de estos formatos con la arquitectura medallón, que procesa los datos por etapas en tres capas de calidad distintas, garantiza la conservación de todo el historial de datos. Esto facilita la adición de nuevas columnas, la recuperación de datos perdidos y la reposición de datos históricos.

Los matices de la arquitectura medallón se desarrollarán en nuestro capítulo sobre transformación de datos(Capítulo 2). Para el debate actual, es pertinente considerar la viabilidad de dirigir todos los datos a una "capa de preparación" dentro del proveedor de almacenamiento en la nube que hayas elegido.

Captura de datos de cambios

La captura de datos de cambios (CDC) es un patrón de diseño de ingeniería de datos que captura y rastrea los cambios en las bases de datos de origen para actualizar los sistemas posteriores. En lugar de cargar por lotes bases de datos enteras, la CDC transfiere sólo los datos modificados, optimizando tanto la velocidad como el uso de recursos.

Esta técnica es crucial para el análisis en tiempo real y el almacenamiento de datos, ya que garantiza que los datos de los sistemas de destino estén actualizados y sincronizados con los de origen. Al permitir las actualizaciones incrementales, la CDC mejora la disponibilidad y coherencia de los datos en todo el conducto de datos. En palabras sencillas de Joe Reis y Matt Housley en Fundamentals of Data Engineering (O'Reilly, 2022), "CDC... es el proceso de ingesta de cambios desde un sistema de base de datos de origen".

La CDC adquiere importancia en los patrones de análisis e ingeniería, como la creación de tablas de tipo 1 y 2 de Dimensión Lentamente Cambiante (SCD), un proceso que puede ser innecesariamente complejo y llevar mucho tiempo. Elegir plataformas o soluciones que admitan CDC de forma nativa puede agilizar tareas comunes, permitiéndote centrarte en lo que más importa. Un ejemplo es Delta Live Tables (DLT) en Databricks, que proporciona soporte nativo para SCD de tipo 1 y 2 tanto en procesos por lotes como en streaming.

Lista de destinos

Aquí tienes un ejemplo de lista de comprobación con las preguntas que debes tener en cuenta al seleccionar un destino:

Pregunta Ejemplo
¿Con quién colaboraremos? Recursos Humanos
¿Cómo se utilizarán los datos? Comprender cómo afecta la permanencia/duración del contrato a los resultados finales en una organización multinacional.
¿Hay varios destinos? Los datos se organizan en Delta Lake; las tablas finales se construyen en Databricks SQL.
¿Cuál es el formato? Parquet en Delta Lake. Estructurado/semi-estructurado en Databricks SQL.
¿Cuál es la frecuencia? Lote
¿Cuál es el volumen? Aproximadamente 1.000 nuevas filas/día, con una reserva existente de ~100.000
¿Qué tratamiento se requiere? Procesamiento descendente mediante DLT. Modelos ML y aplicaciones de IA generativa en Spark.
¿Cómo se almacenarán los datos? Mezcla de Databricks SQL y tablas externas en Delta Lake.

Consideraciones sobre la ingestión

En esta sección, esbozamos las características fundamentales de los datos. Aunque esta lista no es exhaustiva y está influida por contextos específicos, aspectos como la frecuencia, el volumen, el formato y el procesamiento surgen como preocupaciones primordiales.

Frecuencia

Ya hemos mencionado que la primera consideración en la frecuencia deben ser los límites, es decir, si el conjunto de datos es limitado o no. Los límites y las necesidades de la empresa dictarán la frecuencia de la ingesta de datos, ya sea por lotes o en streaming. La Figura 1-3 muestra claramente la diferencia entre los procesos por lotes y de flujo; el flujo captura los eventos a medida que se producen, mientras que el lote los agrupa, como su nombre indica.

Figura 1-3. La latencia es la propiedad que define los procesos "por lotes" o "en flujo"; más allá de algún umbral arbitrario de latencia, consideramos los datos "en flujo" (cortesía de Denny Lee)

Presentaremos lote, microlotes y streaming, junto con nuestras ideas para ayudarte a seleccionar la frecuencia más adecuada y una solución de ingestión compatible.

Lote

El procesamiento por lotes es el acto de procesar datos por lotes en lugar de todos a la vez. Al igual que un bucle for que itera sobre una fuente, el procesamiento por lotes consiste simplemente en trocear un conjunto de datos acotado y procesar cada componente o procesar conjuntos de datos no acotados a medida que llegan los datos.

Microlote

Un microlote es simplemente "bajar el dial" del procesamiento por lotes. Si una ingesta por lotes típica funciona a diario, un microlote podría funcionar cada hora o incluso cada minuto. Por supuesto, podrías decir: "¿En qué momento esto es sólo semántica? Un canal de microlotes con una latencia de 100 ms se me parece mucho al streaming".

Estamos de acuerdo.

Durante el resto de este capítulo (y del libro), nos referiremos a las soluciones de microlote de baja latencia como soluciones de streaming, siendo la más obvia el Streaming Estructurado de Spark. Aunque "técnicamente" se trata de microlotes, la latencia de cientos de milisegundos convierte a Spark Structured Streaming en una solución en tiempo real.

Streaming

El streaming se refiere a la lectura continua de conjuntos de datos, ya sean acotados o no, a medida que se generan. Aunque no trataremos el streaming en gran detalle, merece una investigación más profunda. Para una comprensión completa de las fuentes de datos en streaming, sugerimos explorar recursos como Streaming 101, Streaming Databases y, por supuesto, Fundamentos de la Ingeniería de Datos.

Métodos

Entre los métodos habituales de transmisión de datos no limitados se incluyen:

Ventana

Segmentar una fuente de datos en trozos finitos basados en límites temporales.

Ventanas fijas

Los datos se "microlotean" esencialmente y se leen en pequeñas ventanas fijas a un objetivo.

Ventanas correderas

Similar a las ventanas fijas, pero con límites superpuestos.

Sesiones

Ventanas dinámicas en las que las secuencias de acontecimientos están separadas por espacios de inactividad: en las sesiones, la "ventana" la definen los propios datos.

Agnóstico en el tiempo

Adecuado para datos en los que el tiempo no es crucial, a menudo utilizando cargas de trabajo por lotes.

La Figura 1-4 muestra la diferencia entre ventanas fijas, ventanas deslizantes y sesiones. Es crucial diferenciar entre el tiempo real del evento y el tiempo de procesamiento, ya que pueden surgir discrepancias.

Figura 1-4. Las ventanas fijas, las ventanas deslizantes y las sesiones tratan la llegada de datos en flujo de forma bastante diferente

Servicios de mensajes

Cuando decimos "servicios de mensajes", nos referimos a "capas de transporte" o sistemas para comunicar y transportar datos en streaming. Una nota importante es que no se trata de una comparación directa; aunque hay solapamientos en estos servicios, muchos funcionan con arquitecturas fundamentalmente diferentes, lo que hace que los debates "Kafka frente a Pub/Sub" o "Kinesis frente a Redpanda" sean en gran medida irrelevantes.

Apache Kafka

Creado en LinkedIn en 2011, Apache Kafka comenzó como un sistema de cola de mensajes, pero rápidamente evolucionó hasta convertirse en una plataforma de streaming distribuido. Aunque el diseño de Kafka permite un alto rendimiento y escalabilidad, su complejidad inherente sigue siendo un obstáculo para muchos.

Redpanda

Desarrollado como alternativa a Kafka, Redpanda ofrece un rendimiento similar con una configuración e instalación simplificadas. Redpanda se basa en C++ en lugar de Java y es compatible con las API de Kafka.

Pub/Sub

Pub/Sub es la oferta de Google Cloud para una cola de mensajería duradera y dinámica. A diferencia de Kafka, Google Pub/Sub se escala dinámicamente para gestionar cargas de trabajo variables. En lugar de tratar con "flujos" y "fragmentos", Pub/Sub opta por "temas" y "suscripciones". Un gran atractivo de Pub/Sub es la eliminación de la mayoría de las tareas de "mantenimiento": está casi totalmente gestionado.

Kinesis

Kinesis es otro servicio robusto y totalmente gestionado. Como servicio de Amazon, Kinesis ofrece la evidente facilidad de integración con otras ofertas de Amazon Web Services (AWS), al tiempo que aporta escalabilidad automática y procesamiento de datos en tiempo real. Al igual que Pub/Sub, Kinesis destaca por su naturaleza de servicio gestionado, ofreciendo una carga operativa menor que Apache Kafka.

Motores de procesamiento de flujos

El procesamiento de flujos consiste en analizar y actuar sobre datos en tiempo real (flujos). Dada la longevidad de Kafka, las tres herramientas de procesamiento de flujos más populares y conocidas son:

Apache Flink

Un motor de código abierto que procesa continuamente conjuntos de datos tanto ilimitados como limitados con un tiempo de inactividad mínimo. Apache Flink garantiza una baja latencia mediante cálculos en memoria, ofrece alta disponibilidad eliminando los puntos únicos de fallo, y escala horizontalmente.

Streaming estructurado Apache Spark

Una rama del ecosistema Apache Spark diseñada para manejar el procesamiento de datos en tiempo real. Aporta la familiaridad y potencia de las APIs DataFrame y Dataset de Spark a los datos en streaming. El Streaming Estructurado puede ser una opción atractiva dada la popularidad de Apache Spark en el procesamiento de datos y la ubicuidad del motor en herramientas como Databricks.

Apache Kafka Streams

Una biblioteca basada en Kafka que proporciona capacidades de procesamiento de estados, pero los vínculos con Java pueden ser limitantes.

Simplificar el procesamiento de flujos

Varias soluciones relativamente nuevas simplifican el procesamiento de flujos ofreciendo clientes sencillos, centrados en el rendimiento y en ciclos de desarrollo simples.

Plataformas gestionadas

Tomando Databricks como ejemplo: aprovechar herramientas como Delta Live Tables (DLT) o simplemente ejecutar trabajos de Spark Streaming en el tiempo de ejecución de Databricks puede ser una poderosa abstracción de la complejidad y simplificar drásticamente el proceso de construcción de sistemas de streaming.

Kafka confluente

Un intento de llevar las capacidades de Apache Kafka a Python, aunque sigue siendo rudimentario en comparación con su homólogo Java. Confluent Kafka es simplemente una biblioteca cliente del mismo modo que psycopg2 es una biblioteca cliente de Postgres.

Bytewax

Una biblioteca que pretende salvar las distancias ofreciendo una forma más intuitiva y pitónica de tratar el procesamiento de flujos, haciéndolo más accesible a un mayor número de desarrolladores. Basada en Rust, Bytewax tiene un alto rendimiento, es más sencilla que Flink y cuenta con bucles de retroalimentación más cortos y una fácil implementación/escalabilidad.

Herramientas aún más nuevas que tratan de unificar el procesamiento de flujos -como Apache Beam o Estuary Flow- o combinan el procesamiento de flujos directamente con las bases de datos (bases de datos de flujo) están ganando popularidad. Recomendamos Streaming Systems y Streaming Databases para una visión en profundidad.

El panorama del streaming, aunque complejo, ha experimentado avances en cuanto a simplificación y facilidad de uso, especialmente si se consideran las plataformas gestionadas, como Databricks, y las soluciones de microlotes de baja latencia, como Spark Structured Streaming.

Aunque muchos piensan que los datos en tiempo real son el objetivo final, nosotros hacemos hincapié en un enfoque "en tiempo real". Como con cualquier solución, la latencia puede optimizarse infinitamente, pero el coste de la solución (y la complejidad) aumentarán proporcionalmente. La mayoría considerará que pasar de datos diarios o semidiarios a datos horarios/subhorarios es una solución perfectamente aceptable.

Carga útil

El término "carga útil" se refiere al mensaje real que se transmite, junto con los metadatos o cabeceras utilizados para enrutar, procesar o formatear los datos. Las cargas útiles de datos tienen una definición inherentemente amplia, ya que pueden adoptar casi cualquier forma imaginable. En esta sección hablaremos de las características típicas de las cargas útiles.

Volumen

El volumen es un factor fundamental en las decisiones de ingestión de datos, ya que influye en la escalabilidad de las soluciones de procesamiento y almacenamiento. Al evaluar el volumen de datos, asegúrate de tener en cuenta factores como:

Coste

Los mayores volúmenes suelen conllevar mayores costes, tanto de almacenamiento como de recursos informáticos. Asegúrate de alinear el factor coste con tu presupuesto y las necesidades de tu proyecto, incluidos los costes de almacenamiento/escalonamiento asociados a almacenes, lagos o naves lacustres, en función de tu solución.

Latencia

Dependiendo de si necesitas ingesta de datos en tiempo real, casi real o por lotes, la latencia puede ser un factor crítico. El procesamiento en tiempo real no sólo requiere más recursos, sino que también exige una mayor eficiencia cuando se producen picos de volumen. Para cualquier volumen de datos, asegúrate de que tus sistemas pueden hacer frente a los requisitos de latencia.

Rendimiento/escalabilidad

Es esencial conocer la capacidad de la herramienta de ingestión para manejar el gran volumen de datos entrantes. Si la fuente de datos genera grandes cantidades de datos, la herramienta de ingestión debe ser capaz de ingerir esos datos sin provocar cuellos de botella.

Retención

Con grandes volúmenes, las políticas de retención de datos cobran mayor importancia. Necesitarás una estrategia para envejecer los datos antiguos o trasladarlos a soluciones de almacenamiento a largo plazo más baratas. Además de almacenar los datos antiguos, hay que tener en cuenta la seguridad y el backfilling (restauración) de los datos perdidos.

Para manejar conjuntos de datos de gran tamaño, es crucial utilizar formatos comprimidos como Apache Avro o Parquet. Cada uno ofrece ventajas y limitaciones distintas, especialmente en lo que respecta a la evolución del esquema. Para cada una de estas consideraciones, asegúrate de mirar hacia el futuro: las soluciones sostenibles pueden desintegrarse rápidamente con aumentos del orden de magnitud en el volumen de datos.

Estructura y forma

Los datos varían mucho en forma y estructura, desde los datos "estructurados", ordenados y relacionales, hasta los datos "no estructurados", de forma más libre. Es importante destacar que estructura no equivale a calidad; simplemente significa la presencia de un esquema.

En el panorama actual impulsado por la IA, el valor de los datos no estructurados se está disparando a medida que los avances en los grandes modelos de lenguaje y aprendizaje automático nos permiten extraer ricas percepciones de dichos datos. A pesar de ello, los seres humanos tienen predilección por los datos estructurados cuando se trata de análisis en profundidad, un hecho subrayado por la perdurable popularidad de SQL (Lenguaje de Consulta Estructurado), un elemento básico en el análisis de datos durante casi medio siglo.

No estructurado

Como hemos aludido, los datos no estructurados son datos sin ningún esquema o estructura predefinidos. La mayoría de las veces se representan como texto, pero otras formas de medios también representan datos no estructurados. El vídeo, el audio y las imágenes tienen elementos que pueden analizarse numéricamente. Los datos no estructurados pueden ser el texto de una novela de Pierce Brown:

"Un hombre cree que puede volar, pero tiene miedo de saltar. Un pobre amigo le empuja por detrás". Me mira. "Un buen amigo salta con él".

Estos datos suelen alimentar aplicaciones de aprendizaje automático o IA, lo que subraya la necesidad de comprender exhaustivamente los requisitos de las partes interesadas. Dada la complejidad del aprendizaje automático, es vital comprender cómo se utilizarán estos datos no estructurados antes de ingerirlos. Métricas como la longitud del texto o el tamaño sin comprimir pueden servir como medidas de la forma.

Semiestructurado

Los datossemiestructurados se sitúan entre los datos estructurados y los no estructurados: XML y JSON son dos formatos populares. Los datos semiestructurados pueden adoptar la forma de una carga JSON: 

'{"friends": ["steph", "julie", "thomas", "tommy", "michelle", "tori", “larry”]}'

A medida que las plataformas de datos sigan madurando, también lo hará la capacidad de procesar y analizar directamente datos semiestructurados. El siguiente fragmento muestra cómo analizar JSON semiestructurado en Google BigQuery para dividir una lista en filas de datos:

WITH j_data AS (
        SELECT
            (
            JSON '{"friends": ["steph", "julie", "thomas", "tommy", "michelle", "tori", “larry”]}'
            ) AS my_friends_json
), l_data AS (
    SELECT
        JSON_EXTRACT_ARRAY(
            JSON_QUERY(j_data.my_friends_json, "$.friends"), '$'
        ) as my_friends_list
    FROM j_data
)
    SELECT
        my_friends
FROM l_data, UNNEST(l_data.my_friends_list) as my_friends
ORDER BY RAND()

En algunas situaciones, trasladar el procesamiento de datos a la capa analítica merece la pena: permite a los analistas e ingenieros analíticos una mayor flexibilidad en la forma de consultar y almacenar los datos. Los datos semiestructurados en un almacén (o a los que se accede a través de tablas externas) permiten flexibilidad en caso de cambio de esquemas o de falta de datos, al tiempo que siguen proporcionando todas las ventajas de la manipulación de datos tabulares y SQL.

Aun así, debemos tener cuidado de validar adecuadamente estos datos para asegurarnos de que los datos que faltan no están causando errores. Muchas consultas no válidas se deben a la consideración inadecuada de los datos de NULL.

Describir la forma de JSON implica con frecuencia hablar de claves, valores y número de elementos anidados. Para ello, recomendamos herramientas como JSONLint y JSON Crack. También existen extensiones de VS Code para validar y formatear datos JSON/XML.

Estructurado

Los datos dorados "ideales", las fuentes estructuradas están organizadas ordenadamente con esquemas fijos y claves invariables. Durante más de 50 años, SQL ha sido el lenguaje elegido para consultar datos estructurados. Al almacenar datos estructurados, a menudo nos preocupamos por el número de columnas y la longitud de la tabla (en filas). Estas características informan nuestro uso de la materialización, las construcciones incrementales y, en conjunto, una base de datos OLAP frente a OLTP (orientada a columnas/filas).

Aunque hoy en día muchos datos carecen de estructura, SQL sigue siendo la herramienta dominante para el análisis. ¿Cambiará esto? Posiblemente, pero como hemos demostrado, es más probable que SQL simplemente se adapte para acomodarse a los formatos semiestructurados. Aunque las herramientas de consulta basadas en lenguajes han empezado a aparecer con los avances de la IA, SQL suele ser un intermediario. Si SQL desaparece del análisis de datos, probablemente seguirá vivo como API.

Formato

¿Cuál es el mejor formato para los datos de origen? Aunque JSON y CSV (valores separados por comas) son opciones habituales, pueden surgir infinidad de consideraciones sobre el formato. Por ejemplo, algunas transferencias SFTP/FTP antiguas pueden llegar comprimidas, necesitando un paso extra de extracción.

El formato de los datos suele dictar los requisitos de procesamiento y las soluciones disponibles. Mientras que una herramienta como Airbyte podría integrarse perfectamente con una fuente CSV, podría tropezar con un método de compresión personalizado o una codificación Windows peculiar (créenos, ocurre).

Si es posible, aconsejamos optar por formatos de datos conocidos y populares. Como en la reparación de un vehículo, cuanto más popular sea el formato, más fácil será encontrar recursos, bibliotecas e instrucciones. Aun así, en nuestra experiencia es un rito de iniciación enfrentarse a un formato desconcertante, ¡pero eso es parte de lo que hace divertido nuestro trabajo!

Variedad

Es muy probable que trates con múltiples fuentes y, por tanto, con cargas útiles diversas. La variedad de datos desempeña un papel importante a la hora de elegir tu solución de ingesta: no sólo debe ser capaz de manejar tipos de datos dispares, sino también lo suficientemente flexible como para adaptarse a los cambios de esquema y a los distintos formatos. La variedad hace que la gobernanza y la observabilidad sean especialmente difíciles, algo que trataremos en el Capítulo 5.

Si no se tiene en cuenta la variedad de datos, pueden producirse cuellos de botella, un aumento de la latencia y una canalización desordenada, comprometiendo la integridad y utilidad de los datos ingeridos.

Elegir una solución

Las mejores herramientas para tu equipo serán las que apoyen tus fuentes y objetivos. Dados los requisitos de datos únicos de cada organización, tus elecciones dependerán del contexto. Aun así, nunca insistiremos lo suficiente en la importancia de aprovechar los conocimientos de mentores, compañeros y expertos del sector. Aunque las conferencias pueden ser caras, el rendimiento de sus conocimientos puede ser inestimable. Para los que tienen un presupuesto ajustado, las comunidades de datos pueden tener un valor incalculable. Búscalas en plataformas como Slack y LinkedIn y a través de los boletines del sector.

Al considerar una solución de ingestión, pensamos en términos de consideraciones generales y específicas de la solución: las primeras se aplican a todas las herramientas que consideremos, y las segundas son específicas de la clase de herramientas.

Las consideraciones generales incluyen la extensibilidad, el coste de construcción, el coste de mantenimiento, el coste de conmutación y otros aspectos relacionados con el sistema.

Las consideraciones específicas de la solución dependen de la clase de utillaje, que suele adoptar una de dos formas:

  • Las soluciones declarativas dictan los resultados. Por ejemplo, "Utilizo la interfaz de usuario de AWS Glue para crear un rastreador que procese datos sistemáticamente" o "Creo una nueva conexión Airbyte a través de una interfaz de usuario".

  • Las soluciones imperativas dictan acciones. Por ejemplo: "Construyo una lambda que llama a la API de Stripe, codifica/decodifica los datos y los carga incrementalmente en Snowflake".

Cada una de estas soluciones tiene sus pros y sus contras. Discutiremos brevemente cada una de ellas y presentaremos nuestro método recomendado para abordar la integración de datos.

Soluciones declarativas

Clasificamos las soluciones declarativas en heredadas, modernas o nativas, dependiendo en gran medida de su adhesión a los principios de la pila de datos moderna (MDS), como la infraestructura como código, DRY (no te repitas) y otras buenas prácticas de ingeniería de software. Las plataformas nativas difieren de las dos primeras: se integran directamente en un proveedor de nube:

Legado

Piensa en Talend, WhereScape y Pentaho. Estas herramientas tienen conectores robustos y se benefician de una rica comunidad y un amplio soporte. Sin embargo, a medida que evoluciona el panorama de los datos, muchas de estas herramientas se quedan rezagadas y no se adaptan a las exigencias del SMD. A menos que exista una razón de peso, recomendaríamos mirar más allá de las herramientas empresariales heredadas.

Moderno

Aquí es donde entran en juego Fivetran, Stitch y Airbyte. Diseñadas en torno a "conectores", estas herramientas pueden enlazar sin problemas varias fuentes y objetivos, con tecnología punta y aprovechando lo mejor del MDS.

Nativo

En las dos primeras soluciones, partimos del supuesto de que los datos deben trasladarse de una fuente a otra, pero ¿y si dispusieras de una plataforma gestionada que admitiera la ingesta, lista para usar? Databricks, por ejemplo, puede realizar la ingesta de forma nativa desde buses de mensajes y almacenamiento en la nube:

CREATE STREAMING TABLE raw_data 
AS select * 
FROM cloud_files(“/raw_data”, “json”);

CREATE STREAMING TABLE clean_data
AS SELECT SUM(profit)...
FROM raw_data;

Aunque no hay un tipo "correcto" de solución declarativa, muchos se beneficiarán del menor coste de construir y mantener estas soluciones, especialmente las nativas de tu proveedor/plataforma de nube existente.

Coste de construcción/mantenimiento

Las soluciones declarativas no requieren mucha intervención: ¡aquí es donde sacas partido a tu dinero! Ingenieros especializados se encargan del desarrollo y mantenimiento de los conectores. Esto significa que delegas el trabajo pesado en especialistas. La mayoría de las soluciones de pago vienen con equipos de asistencia o gestores de clientes dedicados, que ofrecen conocimientos y orientación adaptados a tus necesidades. Es probable que estos expertos tengan una visión a vista de pájaro del panorama de los datos y puedan ayudarte a sortear la ambigüedad en torno a problemas de datos concretos o ponerte en contacto con otros profesionales.

Extensibilidad

La extensibilidad gira en torno a lo fácil que es construir sobre las soluciones existentes. ¿Qué probabilidades hay de que ese nuevo conector se añada a Airbyte o Fivetran? ¿Puedes hacerlo tú mismo, construyendo sobre el mismo marco? ¿O tienes que esperar semanas/meses/años a que llegue un equipo de producto? ¿Bastará con utilizar Stitch, o necesitarás una solución complementaria? Recuerda que hacer malabarismos con varias soluciones puede inflar los costes y complicar los flujos de trabajo. En las soluciones declarativas, la extensibilidad es enorme. Nadie quiere adoptar una solución sólo para enterarse de que sólo resolverá el 15% de sus necesidades.

Coste del cambio

El coste de cambiar es donde salen a la luz las limitaciones de las herramientas declarativas. Los marcos propietarios y los métodos CDC específicos hacen que migrar a otra herramienta resulte caro. Aunque quedarse con un proveedor puede ser un compromiso necesario, es esencial tenerlo en cuenta a la hora de evaluar posibles soluciones.

Soluciones imperativas

Los enfoques de ingestión de datos imperativos pueden ser taps Singer internos, funciones lambda, plantillas Apache Beam o trabajos orquestados a través de sistemas como Apache Airflow.

Normalmente, las grandes organizaciones con recursos sustanciales encuentran el mayor valor en adoptar una metodología imperativa. Mantener y escalar un marco de ingesta personalizado e interno suele requerir la experiencia de varios ingenieros de datos o incluso de un equipo especializado.

La mayor ventaja de las soluciones imperativas es su extensibilidad.

Extensibilidad

Por naturaleza, el imperativo es personalizado, lo que significa que cada toma y cada objetivo se adaptan a las necesidades de la empresa. Al explorar las opciones de integración de datos, rápidamente se hace evidente que ninguna herramienta cumple todos los criterios. Las soluciones estándar implican inevitablemente compromisos. Sin embargo, con un enfoque imperativo, existe la libertad de diseñarlo con precisión según las especificaciones deseadas. Por desgracia, sin una gran organización dedicada a la ingeniería de datos, esta extensibilidad es increíblemente cara de construir y mantener.

Coste de construcción/mantenimiento

Aunque las soluciones imperativas pueden resolver problemas de ingestión complejos y difíciles, requieren bastante ingeniería. Un vistazo al diagrama de relación de entidades de Stripe debería bastar para convencerte de que esto puede llevar muchísimo tiempo. Además, la naturaleza evolutiva de los datos -como los cambios en el esquema o la desaparición de una API- puede aumentar la complejidad. Gestionar una única fuente de datos es una cosa, pero ¿qué ocurre cuando escalas a múltiples fuentes?

Un sistema imperativo auténticamente resistente debe incorporar las buenas prácticas en el diseño de software, haciendo hincapié en la modularidad, la comprobabilidad y la claridad. Descuidar estos principios podría comprometer los tiempos de recuperación del sistema y dificultar la escalabilidad, afectando en última instancia a las operaciones empresariales. Por tanto, sugerimos que sólo las empresas con una sólida infraestructura de ingeniería de datos consideren la posibilidad de volverse totalmente imperativas.

Coste del cambio

La transición de una solución imperativa a otra puede no ser siempre sencilla, dada la posible incompatibilidad entre los formatos de los distintos proveedores. Sin embargo, desde un punto de vista más positivo, las plataformas basadas en marcos comunes, como Singer, podrían mostrar más compatibilidad, ofreciendo potencialmente un cambio más suave en comparación con herramientas puramente declarativas como Fivetran o Airbyte.

Soluciones híbridas

Conseguir el equilibrio adecuado en la integración a menudo significa adoptar un enfoque híbrido. Esto puede implicar aprovechar herramientas como Fivetran para la mayoría de las tareas de integración, mientras se elaboran soluciones internas para fuentes únicas, u optar por plataformas como Airbyte/Meltano y crear componentes personalizados para fuentes de datos no compatibles.

Contribuir al código abierto también puede ser gratificante en un entorno híbrido. Aunque no están exentos de fallos, los conectores híbridos, como los de Airbyte o los grifos Singer, se benefician del amplio apoyo de la comunidad. En particular, las contribuciones de Airbyte al sector han influido positivamente en la dinámica del mercado, obligando a competidores como Fivetran a introducir niveles gratuitos. También animamos a adoptar un enfoque proactivo para explorar las bibliotecas y herramientas emergentes. Por ejemplo, dlt (herramienta de carga de datos, ¡no confundir con Delta Live Tables!) es una biblioteca de código abierto muy prometedora.

Considera la integración de datos como la elección de un automóvil. No todas las tareas exigen la destreza de un Fórmula Uno. Más a menudo, lo que se necesita es un vehículo fiable y versátil. Sin embargo, aunque un Toyota satisfará el 99% de los usos, no encontrarás un Sienna en una carrera de F1. ¿La estrategia óptima? Confiar en el fiable vehículo de uso diario, pero garantizar el acceso a herramientas de alto rendimiento cuando sea necesario.

Get Entender el ETL now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial