Fundamentos de ingeniería de datos E-Book

Joe Reis

• Herausgeber: Marcombo
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Spanisch
• Veröffentlichungsjahr: 2023

Seitenzahl: 901

Beschreibung

La ingeniería de datos ha crecido rápidamente en la última década. Esto ha ocasionado que muchos ingenieros de software, científicos de datos y analistas se hayan quedado estancados y busquen conseguir una visión completa de esta materia. Si quiere estar a la última y desea aprender a planificar y desarrollar sistemas para satisfacer las necesidades de su organización y las de sus clientes, este es el libro indicado. En él se explica cómo evaluar las mejores tecnologías disponibles a través del ciclo de vida del framework de la ingeniería de datos. Los autores Joe Reis y Matt Housley detallan, en este libro, el ciclo de vida de la ingeniería de datos y muestran cómo unir una variedad de tecnologías en la nube para satisfacer las necesidades de los procesos consumidores de datos que se encuentran en las fases posteriores al ciclo de vida de la ingeniería de datos. Gracias a esta lectura, entenderá cómo aplicar los conceptos de generación de datos, ingestión, orquestación, transformación, almacenamiento y gobernanza, que son críticos en cualquier entorno de datos, independientemente de la tecnología subyacente. Asimismo, con este libro: "Obtendrá una visión concisa de todo el panorama de la ingeniería de datos "Evaluará los problemas de ingeniería de datos mediante el uso integral de las mejores prácticas "Sabrá elegir el conjunto más adecuado de tecnologías, arquitecturas y procesos de datos "Utilizará el ciclo de vida de la ingeniería de datos para diseñar y desarrollar una arquitectura sólida "Incorporará la gobernanza y la seguridad de los datos en todo el ciclo de vida de la ingeniería de datos Joe Reis es un "científico en recuperación de datos", ingeniero y arquitecto de datos. Matt Housley es consultor de ingeniería de datos y especialista en la nube. "Desde hace tiempo, el mundo de los datos se encuentra en permanente evolución. Primero fueron los diseñadores. Después, los administradores de bases de datos. Luego, los CIO. A continuación, los arquitectos de datos. Este libro señala el siguiente paso en la evolución y madurez del sector. Es una lectura obligada para cualquiera que sea honesto con su profesión y su carrera" -Bill Inmon Creador del data warehouse "Fundamentos de la ingeniería de datos es una gran introducción a las actividades de mover, procesar y manejar datos. Explica la taxonomía de los conceptos de datos, sin centrarse demasiado en herramientas o en proveedores individuales, por lo que las técnicas e ideas deberían perdurar más que cualquier tendencia o producto individual. Lo recomiendo con vehemencia a cualquiera que quiera ponerse al día en ingeniería de datos o en analítica, o a los profesionales de hoy que quieran cubrir las lagunas que tengan en cuanto a su comprensión" -Jordan Tigani fundador y CEO de MotherDuck, e ingeniero fundador y Cocreador de BigQuery

Leseprobe

Primera edición original publicada en inglés por O’Reilly con el título Fundamentals of Data Engineering, ISBN 978-1-098-10830-4 © Joseph Reis y Matt Housley, 2022.

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Título de la edición en español:

Fundamentos de ingeniería de datos

Primera edición en español, 2023

© 2023 MARCOMBO, S.L.

www.marcombo.com

Diseño de portada: Karen Montgomery

Ilustración: Kate Dullea

Traducción: Francisco Martínez Carreño

Corrección: Mónica Muñoz Marinero

Directora de producción: M.a Rosa Castillo

Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra solo puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. La presente publicación contiene la opinión del autor y tiene el objetivo de informar de forma precisa y concisa. La elaboración del contenido, aunque se ha trabajado de forma escrupulosa, no puede comportar una responsabilidad específica para el autor ni el editor de los posibles errores o imprecisiones que pudiera contener la presente obra.

ISBN del libro en papel: 978-84-267-3688-8

ISBN del libro electrónico: 978-84-267-3699-4

Producción del ePub: booqlab

Índice de contenidos

Prefacio

Parte I. Fundamentos y componentes

1. Descripción de la ingeniería de datos

¿Qué es la ingeniería de datos?

Definición de ingeniería de datos

Ciclo de vida de la ingeniería de datos

Evolución del ingeniero de datos

Ingeniería de datos y ciencia de datos

Habilidades y actividades de la ingeniería de datos

La madurez de los datos y el ingeniero de datos

Formación y habilidades del ingeniero de datos

Responsabilidades empresariales

Responsabilidades técnicas

El progreso de las funciones de la ingeniería de datos, de la A a la B

Ingenieros de datos de la organización

Ingenieros de datos de cara a la organización y de cara al exterior

Ingenieros de datos y otros roles técnicos

Ingenieros de datos y liderazgo empresarial

Conclusión

Recursos adicionales

2. Ciclo de vida de la ingeniería de datos

¿Qué es el ciclo de vida de la ingeniería de datos?

El ciclo de vida de los datos frente al ciclo de vida de la ingeniería de datos

Generación: sistemas fuente

Almacenamiento

Ingestión

Transformación

Servicio de datos

Principales undercurrents en el ciclo de vida de la ingeniería de datos

Seguridad

Gestión de datos

Operaciones de datos

Arquitectura de datos

Orquestación

Ingeniería de software

Conclusión

Recursos adicionales

3. Diseño de la buena arquitectura de datos

¿Qué es la arquitectura de datos?

Definición de arquitectura empresarial

Definición de arquitectura de datos

La «buena» arquitectura de datos

Principios de la buena arquitectura de datos

Principio 1: elegir bien los componentes comunes

Principio 2: planificar para el fracaso

Principio 3: ser arquitecto de la escalabilidad

Principio 4: la arquitectura es liderazgo

Principio 5: hay que ser siempre arquitecto

Principio 6: desarrollar sistemas poco acoplados

Principio 7: adoptar decisiones reversibles

Principio 8: dar prioridad a la seguridad

Principio 9: adoptar FinOps

Principales conceptos de arquitectura

Dominios y servicios

Sistemas distribuidos, escalabilidad y diseño para el fracaso

Acoplamiento fuerte frente a acoplamiento débil: niveles, monolitos y microservicios

Acceso de usuarios: un usuario frente a varios usuarios

Arquitectura basada en eventos

Proyectos Brownfield frente a Greenfield

Ejemplos y tipos de arquitecturas de datos

Almacén de datos

Lagos de datos

Convergencia, lagos de datos de próxima generación y plataforma de datos

Pila de datos moderna

Arquitectura Lambda

Arquitectura Kappa

El modelo Dataflow y la unificación de lotes y streaming

Arquitectura para Internet de las cosas

Malla de datos

Otros ejemplos de arquitectura de datos

¿Quién participa en el diseño de la arquitectura de datos?

Conclusión

Recursos adicionales

4. Elección de las tecnologías en todo el ciclo de vida de la ingeniería de datos

Tamaño y capacidades del equipo

Velocidad de comercialización

Interoperabilidad

Optimización de costes y valor empresarial

Coste total de propiedad

Coste total de oportunidad de la propiedad

FinOps

El presente frente al futuro: tecnologías inmutables frente a transitorias

Nuestros consejos

Ubicación

Ubicación en las instalaciones

Ubicación en la nube

Ubicación en la nube híbrida

Ubicación en la multinube

Ubicación descentralizada: blockchain y computación de borde

Nuestros consejos

Argumentos para la repatriación de la nube

Crear frente a comprar

Software de código abierto

Jardines amurallados en propiedad

Nuestros consejos

Sistema monolítico frente a sistema modular

El monolito

Modularidad

Patrón de monolito distribuido

Nuestros consejos

Sin servidores o con servidores

Sin servidores

Contenedores

Cómo evaluar la tecnología de servidores frente a la de sin servidores

Nuestros consejos

Optimización, rendimiento y los conflictos de análisis de rendimiento

Big Data... de los años 90

Comparaciones absurdas de costes

Optimización asimétrica

Advertencia a los interesados

Los undercurrents y su impacto en la elección de las tecnologías

Gestión de datos

Operaciones de datos (DataOps)

Arquitectura de datos

Ejemplo de orquestación: Airflow

Ingeniería de software

Conclusión

Recursos adicionales

Parte II. El ciclo de vida de la ingeniería de datos en profundidad

5. Generación de datos en los sistemas fuente

Fuentes de datos: ¿cómo se crean los datos?

Sistemas fuente: ideas principales

Archivos y datos no estructurados

API

Base de datos de la aplicación (sistemas OLTP)

Sistema de procesamiento analítico en línea

Captura de datos de cambios

Registros

Registros de la base de datos

CRUD

Patrón de solo inserción

Mensajes y flujos

Tipos de tiempos

Detalles prácticos de los sistemas fuente

Bases de datos

API

Intercambio de datos

Fuentes de datos de terceros

Colas de mensajes y plataformas de streaming de eventos

Con quién trabajará

Los undercurrents y su impacto en los sistemas fuente

Seguridad

Gestión de datos

Operaciones de datos (DataOps)

Arquitectura de datos

Orquestación

Ingeniería de software

Conclusión

Recursos adicionales

6. Almacenamiento

Ingredientes básicos del almacenamiento de datos

Unidad de disco magnético

Unidad de estado sólido

Memoria de acceso aleatorio

Red y CPU

Serialización

Compresión

Almacenamiento en caché

Sistemas de almacenamiento de datos

Almacenamiento en una sola máquina frente al almacenamiento distribuido

Consistencia eventual frente a consistencia fuerte

Almacenamiento de archivos

Almacenamiento en bloques

Almacenamiento de objetos

Sistemas de almacenamiento basados en caché y memoria

Sistema de archivos distribuidos Hadoop

Almacenamiento de streaming

Índices, particiones y clustering

Abstracciones de almacenamiento en ingeniería de datos

Almacén de datos

Lago de datos

Data lakehouse

Plataformas de datos

Arquitectura de almacenamiento de streaming a lotes

Grandes ideas y tendencias en materia de almacenamiento

Catálogo de datos

Intercambio de datos

Esquema

Separación del cómputo del almacenamiento

Ciclo de vida del almacenamiento de datos y retención de datos

Almacenamiento de un solo cliente frente al de multicliente

Con quién trabajará

Undercurrents

Seguridad

Gestión de datos

Operaciones de datos (DataOps)

Arquitectura de datos

Orquestación

Ingeniería de software

Conclusión

Recursos adicionales

7. Ingestión

¿Qué es la ingestión de datos?

Consideraciones clave de ingeniería para la fase de ingestión

Datos acotados frente a datos no acotados

Frecuencia

Ingestión síncrona frente a asíncrona

Serialización y deserialización

Tasa de transferencia efectiva y escalabilidad

Fiabilidad y durabilidad

Carga útil

Patrones push frente a pull frente a sondeo

Consideraciones sobre la ingestión por lotes

Extracción instantánea o diferencial

Exportación e ingestión basadas en archivos

ETL frente a ELT

Inserciones, actualizaciones y tamaño de los lotes

Migración de datos

Consideraciones sobre la ingestión de mensajes y flujos

Evolución del esquema

Datos tardíos

Pedidos y entregas múltiples

Repetición

Tiempo de vida

Tamaño del mensaje

Tratamiento de errores y colas de letras muertas

Push y pull del consumidor

Ubicación

Formas de ingestión de datos

Conexión directa a la base de datos

Captura de datos de cambios

API

Colas de mensajes y plataformas de streaming de eventos

Conectores de datos gestionados

Movimiento de datos en el almacenamiento de objetos

EDI

Bases de datos y exportación de archivos

Problemas prácticos con los formatos de archivo más habituales

Shell

SSH

SFTP y SCP

Webhooks

Interfaz web

Raspado web

Dispositivos de transferencia para la migración de datos

Intercambio de datos

Con quién trabajará

Partes interesadas de las fases anteriores del proceso

Partes interesadas de las fases posteriores del proceso

Undercurrents

Seguridad

Gestión de datos

Operaciones de datos (DataOps)

Orquestación

Ingeniería de software

Conclusión

Recursos adicionales

8. Consultas, modelización y transformación

Consultas

¿Qué es una consulta?

Vida de la consulta

Optimizador de consultas

Mejora del rendimiento de las consultas

Consultas sobre datos de streaming

Modelado de datos

¿Qué es el modelo de datos?

Modelos de datos conceptuales, lógicos y físicos

Normalización

Técnicas de modelización de datos analíticos por lotes

Modelado de datos de streaming

Transformaciones

Transformaciones por lotes

Vistas materializadas, federación y virtualización de consultas

Transformaciones y procesamiento de streaming

Con quién trabajará

Partes interesadas de las fases anteriores del proceso

Partes interesadas de la cadena de suministro

Undercurrents

Seguridad

Gestión de datos

Operaciones de datos (DataOps)

Arquitectura de datos

Orquestación

Ingeniería de software

Conclusión

Recursos adicionales

9. Servicio de datos para analítica, machine learning y ETL inversa

Consideraciones generales para el servicio de datos

Confianza

¿Cuál es el caso de uso y quién es el usuario?

Productos de datos

¿Autoservicio o no?

Definiciones de datos y lógica

Malla de datos

Analítica

Analítica empresarial

Analítica operativa

Analítica integrada

Machine learning

Lo que el ingeniero de datos debe saber sobre ML

Formas del servicio de datos para analítica y ML

Intercambio de archivos

Bases de datos

Sistemas de streaming

Federación de Consultas

Intercambio de datos

Capas semánticas y métricas

Servicio de datos de notebooks

ETL inversa

Con quién trabajará

Undercurrents

Seguridad

Gestión de datos

Operaciones de datos (DataOps)

Arquitectura de datos

Orquestación

Ingeniería de software

Conclusión

Recursos adicionales

Parte III. Seguridad, privacidad y el futuro de la ingeniería de datos

10. Seguridad y privacidad

Las personas

El poder del pensamiento negativo

Sea siempre precavido

Procesos

El teatro de la seguridad frente al hábito de la seguridad

Seguridad activa

Principio del mínimo privilegio

Responsabilidad compartida en la nube

Haga siempre una copia de seguridad de sus datos

Ejemplo de política de seguridad

Tecnología

Sistemas de parcheo y actualización

Cifrado

Registro, monitorización y alertas

Acceso a la red

Seguridad para la ingeniería de datos de bajo nivel

Conclusión

Recursos adicionales

11. El futuro de la ingeniería de datos

El ciclo de vida de la ingeniería de datos no va a desaparecer

Declive de la complejidad y auge de las herramientas de datos fáciles de usar

Sistema operativo de datos a escala de la nube y mejora de la interoperabilidad

Ingeniería de datos «empresarial»

Las titulaciones y las responsabilidades se transformarán…

Más allá de la pila de datos moderna, hacia la pila de datos vivos

Pila de datos en vivo

Pipelines de streaming y bases de datos analíticas en tiempo real

Fusión de datos con aplicaciones

Retroalimentación fuerte entre aplicaciones y ML

Los datos de la materia oscura y el auge de... ¿las hojas de cálculo?

Conclusión

12. Detalles técnicos de serialización y compresión.

13. Redes en la nube

Prefacio

¿Cómo surgió este libro? El origen está profundamente arraigado en nuestro viaje de la ciencia de datos a la ingeniería de datos. A menudo, de broma, nos referimos a nosotros mismos como «científicos de datos en proceso de recuperación». Ambos tuvimos la experiencia de que nos asignaran proyectos de ciencia de datos, y en aquel momento nos costó mucho realizar los proyectos debido a la ausencia de principios fundamentales adecuados. Nuestro viaje hacia la ingeniería de datos comenzó cuando emprendimos las tareas para establecer sus principios fundamentales y su infraestructura.

Con el auge de la ciencia de datos, las empresas realizaron importantes desembolsos en la contratación de talentos en esta disciplina, con la esperanza de cosechar grandes beneficios. Muy a menudo, los científicos de datos se enfrentaban a problemas básicos que su formación no había tenido en cuenta: recopilación de datos, limpieza de datos, acceso a datos, transformación de datos y la infraestructura de datos. Estos son los problemas que la ingeniería de datos pretende resolver.

Lo que el libro no es

Antes de hablar de lo que trata el libro y de lo que obtendrá de él, vamos a comentar rápidamente lo que el libro no es. Este libro no se ocupa de una herramienta, tecnología o plataforma en particular de la ingeniería de datos. Aunque muchos y excelentes libros abordan las tecnologías de la ingeniería de datos desde esta perspectiva, estos libros tienen una vida útil corta. En su lugar, nosotros nos centramos en los conceptos fundamentales de la ingeniería de datos.

De qué trata el libro

El libro pretende llenar el vacío que existe en los contenidos y materiales actuales de la ingeniería de datos. Aunque no faltan recursos técnicos que abordan las herramientas y las tecnologías específicas de la ingeniería de datos, a las personas les cuesta entender cómo se ensamblan estos componentes en un todo coherente que se pueda aplicar al mundo real. Este libro relaciona los puntos del ciclo de vida de los datos de principio a fin. Muestra cómo unir varias tecnologías para satisfacer las necesidades de los consumidores de datos de fases posteriores al ciclo de vida de la ingeniería de datos, como son los analistas, científicos de datos e ingenieros de machine learning. Este libro sirve de complemento a los libros de O’Reilly, que tratan los detalles de determinadas tecnologías, plataformas y lenguajes de programación.

La idea central del libro es el ciclo de vida de la ingeniería de datos: generación, almacenamiento, ingestión, transformación y servicio de datos. Desde la aparición de los datos, hemos visto el auge y la caída de innumerables tecnologías específicas y productos de proveedores, pero las etapas del ciclo de vida de la ingeniería de datos han permanecido esencialmente sin cambios. Con este esquema, el lector adquirirá una sólida comprensión que le permitirá aplicar las tecnologías a los problemas empresariales del mundo real.

Nuestro objetivo aquí es trazar principios que contengan dos ejes. En primer lugar, queremos sintetizar la ingeniería de datos en principios que puedan incluir cualquier tecnología relevante. En segundo lugar, queremos presentar principios que resistan el paso del tiempo. Esperamos que estas ideas reflejen las lecciones aprendidas a través de la convulsión tecnológica de los últimos veinte años y que nuestro esquema mental siga siendo útil durante una década o más en el futuro.

Hay una cosa que hay que tener en cuenta: adoptamos sin reparos un enfoque que da prioridad a la nube. Vemos la nube como un desarrollo fundamentalmente transformador que perdurará durante décadas; la mayoría de los sistemas de datos y cargas de trabajo locales acabarán trasladándose al alojamiento en la nube. Suponemos que la infraestructura y los sistemas son efímeros y escalables, y que los ingenieros de datos se inclinarán por el despliegue de servicios gestionados en la nube. Dicho esto, la mayoría de los conceptos de este libro se trasladarán a entornos no relacionados con la nube.

Quién debería leer el libro

El principal público objetivo para este libro lo constituyen los profesionales técnicos, ingenieros de software de nivel medio y superior, científicos de datos o analistas interesados en pasarse a la ingeniería de datos; o ingenieros de datos que trabajan en los entresijos de tecnologías específicas, pero que desean desarrollar una perspectiva más completa. En segundo lugar, el público objetivo es el de los que se interesan por los datos y trabajan junto a los profesionales técnicos; por ejemplo, jefes de equipo de datos con formación técnica que supervisan un equipo de ingenieros de datos, o directores de almacenamiento de datos que desean migrar de la tecnología local a una solución basada en la nube.

Lo ideal es que sea curioso y quiera aprender: ¿por qué, si no, estaría leyendo este libro? Usted se mantiene al día en las tecnologías de datos y sus tendencias mediante la lectura de libros y artículos sobre almacenamiento de datos, lagos de datos, sistemas por lotes y de streaming, orquestación, modelado, gestión, análisis, desarrollos de las tecnologías en la nube, etc. Este libro le ayudará a entrelazar lo que ha leído en una imagen completa de la ingeniería de datos a través de las tecnologías y los paradigmas.

Requisitos previos

Suponemos que los lectores están bastante familiarizados con los tipos de sistemas de datos que se encuentran en un entorno corporativo. Además, suponemos que tienen cierto conocimiento de SQL y Python (o algún otro lenguaje de programación), y que poseen experiencia con los servicios en la nube.

Los aspirantes a ingenieros de datos disponen de numerosos recursos para practicar Python y SQL. Abundan los recursos gratuitos en línea (publicaciones en blogs, sitios de tutoriales, vídeos de YouTube), y cada año se publican muchos libros nuevos sobre Python.

La nube ofrece oportunidades sin precedentes para adquirir experiencia práctica con las herramientas de datos. Sugerimos a los aspirantes a ingenieros de datos que creen cuentas de servicios en la nube como AWS, Azure, Google Cloud Platform, Snowflake, Databricks, etc. Hay que tener en cuenta que muchas de estas plataformas tienen opciones de niveles gratuitos, pero los lectores, cuando estudien, deben vigilar los costes y trabajar con pequeñas cantidades de datos y clústeres de un solo nodo.

Conseguir familiarizarse con los sistemas de datos corporativos fuera de un entorno corporativo sigue siendo difícil, y esto crea ciertas barreras para los aspirantes a ingenieros de datos que aún no han conseguido su primer trabajo de datos. Este libro puede ayudar. Sugerimos a los novatos en datos que lean las ideas de alto nivel y que luego consulten los materiales de la sección de recursos adicionales al final de cada capítulo. En una segunda lectura, sugerimos que anoten los términos y tecnologías que no les resulten familiares. Pueden utilizar Google, Wikipedia, entradas de blogs, vídeos de YouTube y sitios de proveedores para familiarizarse con los nuevos términos y rellenar las lagunas en cuanto a su comprensión.

Lo que aprenderá y cómo mejorará sus habilidades

Este libro pretende ayudarle a crear una base sólida para resolver problemas de ingeniería de datos en el mundo real.

Al terminar el libro entenderá:

• Cómo afecta la ingeniería de datos a su cometido actual (científico de datos, ingeniero de software o jefe de equipo de datos).

• Cómo superar el bombo del marketing y elegir las tecnologías, la arquitectura de datos y los procesos adecuados.

• Cómo utilizar el ciclo de vida de la ingeniería de datos para diseñar y crear una arquitectura sólida.

• Las mejores prácticas para cada etapa del ciclo de vida de los datos.

Y podrá conseguir:

• Incorporar los principios de la ingeniería de datos a su cometido actual (científico de datos, analista, ingeniero de software, jefe de equipo de datos, etc.).

• Unir diferentes tecnologías en la nube para satisfacer las necesidades de los consumidores de datos de fases posteriores al ciclo de vida de la ingeniería de datos.

• Evaluar los problemas de ingeniería de datos con un esquema integral sobre las mejores prácticas.

• Incorporar la gobernanza y la seguridad de los datos en todo el ciclo de vida de la ingeniería de datos.

Navegación por el libro

Este libro consta de cuatro partes:

•Parte I. Fundamentos y componentes.

•Parte II. El ciclo de vida de la ingeniería de datos en profundidad.

•Parte III. Seguridad, privacidad y el futuro de la ingeniería de datos.

• Apéndices A y B: tratan tanto la serialización como la compresión, y las redes en la nube, respectivamente.

En la Parte I, comenzamos definiendo la ingeniería de datos en el Capítulo 1 y, a continuación, trazamos el ciclo de vida de la ingeniería de datos en el Capítulo 2. En el Capítulo 3, hablamos de lo que es una buena arquitectura. En el Capítulo 4, introducimos el esquema de trabajo para elegir la tecnología adecuada; aunque a menudo vemos que la tecnología y la arquitectura se confunden, en realidad son temas muy diferentes. entre sí.

La Parte II se fundamenta en el Capítulo 2 para tratar el ciclo de vida de la ingeniería de datos en profundidad; cada etapa del ciclo de vida (generación de datos, almacenamiento, ingestión, transformación y servicio) se trata en su correspondiente capítulo. La Parte II es, sin duda, el corazón del libro, y los demás capítulos existen para apoyar las ideas centrales que en ella se presentan.

En la Parte III se tratan otros temas. En el Capítulo 10, se habla de la seguridad y la privacidad. Aunque la seguridad siempre ha sido una parte importante de la profesión de ingeniero de datos, se ha vuelto más crítica con el aumento de la piratería informática con fines de lucro y los ciberataques patrocinados por estados. ¿Y qué podemos decir de la privacidad? La era del nihilismo de la privacidad corporativa se ha acabado: ninguna empresa quiere ver su nombre en el titular de un artículo sobre prácticas deficientes de la privacidad. El manejo imprudente de los datos personales también puede tener importantes ramificaciones legales con la llegada de GDPR, CCPA y otras regulaciones. En resumen, la seguridad y la privacidad deben ser las principales prioridades en cualquier trabajo de ingeniería de datos.

En el curso de nuestro trabajo en ingeniería de datos, en la investigación para elaborar este libro y en las entrevistas con numerosos expertos, hemos reflexionado mucho sobre el rumbo que seguirá este campo a corto y largo plazo. El Capítulo 11 esboza nuestras ideas, sumamente especulativas, sobre el futuro de la ingeniería de datos. Por su naturaleza, el futuro es algo resbaladizo. El tiempo dirá si algunas de nuestras ideas son correctas. Nos encantaría que nuestros lectores nos dijeran si sus visiones del futuro coinciden o difieren de las nuestras.

En los apéndices, tratamos un puñado de temas técnicos que son extremadamente relevantes para la práctica diaria de la ingeniería de datos, pero que no encajaban en el cuerpo principal del texto. En concreto, los ingenieros necesitan entender la serialización y la compresión (véase el apéndice A), tanto para trabajar directamente con los archivos de datos como para evaluar las consideraciones de rendimiento en los sistemas de datos. Y las redes en la nube (véase el Apéndice B) son un tema fundamental a medida que la ingeniería de datos se traslada a la nube.

Convenciones utilizadas en el libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivos y extensiones de archivos.

Anchura constante

Se utiliza en los listados de programas, así como en los párrafos, para hacer referencia a elementos del programa (como son los nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave).

Este elemento se refiere a un consejo o sugerencia.

Este elemento significa una nota general.

Este elemento significa una advertencia o precaución.

Agradecimientos

Cuando empezamos a escribir el libro, muchas personas nos advirtieron de que nos enfrentábamos a una ardua tarea. Un libro como este tiene muchas partes apasionantes y, debido a su amplia visión del campo de la ingeniería de datos, requirió una tonelada de investigación, entrevistas, discusiones y reflexiones profundas. No pretendemos haber captado todos los matices de la ingeniería de datos, pero esperamos que los resultados sean de su agrado. Un gran número de personas han contribuido a nuestros esfuerzos, y estamos agradecidos por el apoyo que hemos recibido por parte de muchos expertos en la materia.

En primer lugar, gracias a nuestro increíble equipo de revisores técnicos. Se han esforzado en leer el libro muchas veces y han aportado valiosos —y, a menudo, despiadadamente contundentes— comentarios. Este libro sería solo una fracción del mismo sin sus esfuerzos. Sin ningún orden en particular, damos las gracias a Bill Inmon, Andy Petrella, Matt Sharp, Tod Hanseman, Chris Tabb, Danny Lebzyon, Martin Kleppman, Scott Lorimor, Nick Schrock, Lisa Steckman, Veronika Durgin y Alex Woolford.

En segundo lugar, hemos tenido la oportunidad única de hablar con los principales expertos en el campo de los datos en nuestros programas en directo, podcasts, reuniones y un sinfín de llamadas privadas. Sus ideas ayudaron a dar forma al libro. Por su extensión no es posible nombrar a todas las personas individualmente, pero nos gustaría mencionar a Jordan Tigani, Zhamak Dehghani, Ananth Pakkildurai, Shruti Bhat, Eric Tschetter, Benn Stancil, Kevin Hu, Michael Rogove, Ryan Wright, Adi Polak, Shinji Kim, Andreas Kretz, Egor Gryaznov, Chad Sanderson, Julie Price, Matt Turck, Monica Rogati, Mars Lan, Pardhu Gunnam, Brian Suk, Barr Moses Lior Gavish, Bruno Aziza, Gian Merlino, DeVaris Brown, Todd Beauchene, Tudor Girba, Scott Taylor, Ori Rafael, Lee Edwards, Bryan Offutt, Ollie Hughes, Gilbert Eijkelenboom, Chris Bergh, Fabiana Clemente, Andreas Kretz, Ori Reshef, Nick Singh, Mark Balkenende, Kenten Danas, Brian Olsen, Lior Gavish, Rhaghu Murthy, Greg Coquillo, David Aponte, Demetrios Brinkmann, Sarah Catanzaro, Michel Tricot, Levi Davis, Ted Walker, Carlos Kemeny, Josh Benamram, Chanin Nantasenamat, George Firican, Jordan Goldmeir, Minhaaj Rehmam, Luigi Patruno, Vin Vashista, Danny Ma, Jesse Anderson, Alessya Visnjic, Vishal Singh, Dave Langer, Roy Hasson, Todd Odess, Che Sharma, Scott Breitenother, Ben Taylor, Thom Ives, John Thompson, Brent Dykes, Josh Tobin, Mark Kosiba, Tyler Pugliese, Douwe Maan, Martin Traverso, Curtis Kowalski, Bob Davis, Koo Ping Shung, Ed Chenard, Matt Sciorma, Tyler Folkman, Jeff Baird, Tejas Manohar, Paul Singman, Kevin Stumpf, Willem Pineaar y Michael Del Balso de Tecton, Emma Dahl, Harpreet Sahota, Ken Jee, Scott Taylor, Kate Strachnyi, Kristen Kehrer, Taylor Miller, Abe Gong, Ben Castleton, Ben Rogojan, David Mertz, Emmanuel Raj, Andrew Jones, Avery Smith, Brock Cooper, Jeff Larson, Jon King, Holden Ackerman, Miriah Peterson, Felipe Hoffa, David González, Richard Wellman, Susan Walsh, Ravit Jain, Lauren Balik, Mikiko Bazeley, Mark Freeman, Mike Wimmer, Alexey Shchedrin, Mary Clair Thompson, Julie Burroughs, Jason Pedley, Freddy Drennan, Jason Pedley, Kelly y Matt Phillipps, Brian Campbell, Faris Chebib, Dylan Gregerson, Ken Myers, Jake Carter, Seth Paul, Ethan Aaron, y muchos otros.

Si a alguien no se le menciona específicamente, que no se lo tome como algo personal. Ya sabe quién es. Avísenos y lo incluiremos en la próxima edición.

También queremos dar las gracias al equipo de Ternary Data (Colleen McAuley, Maike Wells, Patrick Dahl, Aaron Hunsaker y otros), a nuestros estudiantes y a las innumerables personas de todo el mundo que nos han apoyado. Es un gran recordatorio de que el mundo es un lugar muy pequeño.

Trabajar con el equipo de O’Reilly fue increíble. Un agradecimiento especial a Jess Haberman por confiar en nosotros durante el proceso de propuesta del libro, a nuestras increíbles y extremadamente pacientes editoras de desarrollo Nicole Taché y Michele Cronin por su inestimable edición, sus comentarios y su apoyo. Gracias también al magnífico equipo de producción de O’Reilly (Greg y su equipo).

Joe quiere dar las gracias a su familia (Cassie, Milo y Ethan) por dejarle escribir el libro. Han tenido que aguantar mucho, y Joe promete no volver a escribir otro libro. ;)

Matt quiere dar las gracias a sus amigos y a su familia por su paciencia y apoyo constantes. Todavía tiene la esperanza de que Séneca se digne a llevar a cabo una revisión de cinco estrellas después de la gran cantidad de trabajo y de tiempo que no disfrutó con su familia durante las vacaciones.

PARTE I

Fundamentos y componentes

CAPÍTULO 1

Descripción de la ingeniería de datos

Si trabaja en el ámbito de los datos o del software, es posible que haya notado que la ingeniería de datos está saliendo de las sombras y que ahora comparte escenario con la ciencia de datos. La ingeniería de datos es uno de los campos más candentes del mundo de los datos y la tecnología, y por una buena razón. Crea los cimientos de la ciencia de datos y el análisis en la fase de producción. Este capítulo explora qué es la ingeniería de datos, cómo nació este campo y su evolución, las habilidades que deben tener los ingenieros de datos y con quiénes trabajan.

¿Qué es la ingeniería de datos?

A pesar de la popularidad de la ingeniería de datos en la actualidad, hay mucha confusión sobre lo que significa la ingeniería de datos y lo que hacen los ingenieros de datos. La ingeniería de datos ha existido de alguna forma desde que las empresas empezaron a hacer cosas con los datos (como el análisis predictivo, el análisis descriptivo y los informes) y se hizo patente con el auge de la ciencia de datos en la década de 2010. Para el propósito de este libro, es fundamental definir lo que significa ingeniería de datos e ingeniero de datos.

En primer lugar, vamos a ver cómo se ha descrito la ingeniería de datos y desarrollaremos alguna terminología que podamos utilizar a lo largo del libro. Existen infinitas definiciones de ingeniería de datos. A principios de 2022, una búsqueda exacta en Google de «¿Qué es la ingeniería de datos?» mostró más de 91 000 resultados diferentes. Antes de presentar nuestra definición, he aquí algunos ejemplos de cómo definen la ingeniería de datos algunos expertos en la materia:

La ingeniería de datos es un conjunto de operaciones destinadas a crear interfaces y mecanismos de flujo y acceso a la información. Se necesitan especialistas entregados (ingenieros de datos) para mantener los datos de manera que sigan estando disponibles y los puedan utilizar otros usuarios. En resumen, los ingenieros de datos configuran y operan la infraestructura de datos de la organización, preparándolos para su posterior análisis por parte de los analistas y científicos de datos.

(«Data Engineering and Its Main Concepts», de Alexsoft1)

El primer tipo de ingeniería de datos se centra en SQL. Tanto el trabajo como el almacenamiento principal de los datos se realiza en bases de datos relacionales. Todo el procesamiento de datos se realiza con SQL o un lenguaje basado en SQL. A veces, este procesamiento de datos se realiza con una herramienta ETL2. El segundo tipo de ingeniería de datos se centra en Big Data. El trabajo y el almacenamiento principal de los datos se realiza mediante tecnologías de Big Data como Hadoop, Cassandra y HBase. Todo el procesamiento de datos se realiza en frameworks de Big Data como MapReduce, Spark y Flink. Aunque se utiliza SQL, el procesamiento principal se realiza con lenguajes de programación como Java, Scala y Python.

(Jesse Anderson3)

En relación con los roles existentes con anterioridad, el campo de la ingeniería de datos podría considerarse un superconjunto de la inteligencia empresarial y el almacenamiento de datos que aporta muchos elementos de la ingeniería de software. Esta disciplina también integra la especialización en torno al funcionamiento de los llamados sistemas distribuidos de Big Data, junto con conceptos sobre el ecosistema ampliado de Hadoop, el procesamiento de flujos y dentro de la computación a escala.

(Maxime Beauchemin4)

La ingeniería de datos tiene que ver con el movimiento, la manipulación y la gestión de datos.

(Lewis Gavin5)

¡Guau! Es totalmente comprensible que esté confundido sobre la ingeniería de datos. Son solo un puñado de definiciones, y contienen una enorme variedad de opiniones sobre el significado de la ingeniería de datos.

Definición de ingeniería de datos

Cuando desciframos los aspectos comunes en las definiciones de ingeniería de datos, surge un patrón obvio: el ingeniero de datos obtiene datos, los almacena y los prepara para que los consuman los científicos de datos, los analistas y otros usuarios. Definimos la ingeniería de datos y el ingeniero de datos como sigue:

La ingeniería de datos consiste en el desarrollo, la implementación y el mantenimiento de sistemas y procesos que toman datos sin procesar y generan información consistente y de alta calidad que respalda casos de uso en un momento posterior, como son el análisis y machine learning. La ingeniería de datos es la intersección entre la seguridad, la gestión de datos, las operaciones de datos, la arquitectura de datos, la orquestación y la ingeniería de software. El ingeniero de datos gestiona el ciclo de vida de la ingeniería de datos, comenzando por la obtención de datos de los sistemas fuente y terminando por el servicio de los datos para casos de uso, como son el análisis o machine learning.

Ciclo de vida de la ingeniería de datos

Es demasiado fácil fijarse en la tecnología y, al hacerlo de forma miope, perder la visión de conjunto. Este libro se centra en una gran idea llamada ciclo de vida de la ingeniería de datos (Figura 1-1), que creemos que proporciona a los ingenieros de datos el contexto holístico para examinar su papel.

Figura 1-1.Ciclo de vida de la ingeniería de datos.

El ciclo de vida de la ingeniería de datos desplaza el diálogo con la tecnología hacia los propios datos y hacia los objetivos finales a los que deben servir. Las etapas del ciclo de vida de la ingeniería de datos son las siguientes:

• Generación

• Almacenamiento

• Ingestión

• Transformación

• Servicio

El ciclo de vida de la ingeniería de datos también contiene la noción de undercurrents: conceptos cruciales a lo largo de todo el ciclo de vida. Entre ellos se encuentran la seguridad, la gestión de datos, las operaciones de datos, la arquitectura de datos, la orquestación y la ingeniería de software. El ciclo de vida de la ingeniería de datos y sus undercurrents se trata con más detalle en el Capítulo 2. Sin embargo, lo introducimos aquí porque es esencial para nuestra definición de ingeniería de datos y para la discusión que sigue en este capítulo.

Ahora que tiene una definición práctica de ingeniería de datos y una introducción a su ciclo de vida, demos un paso atrás y veamos un poco de historia.

Evolución del ingeniero de datos

La historia no se repite, pero rima.

(Un famoso adagio atribuido a menudo a MarkTwain).

Para entender la ingeniería de datos de hoy y del mañana es necesario conocer el contexto de la evolución en este campo. Esta sección no es una lección de historia, pero mirar al pasado tiene un valor incalculable para entender dónde estamos hoy y hacia dónde van las cosas. Un tema general reaparece constantemente: lo que es viejo vuelve a ser nuevo.

Los primeros tiempos: de 1980 a 2000, de los almacenes de datos a la web

Podría decirse que el nacimiento del ingeniero de datos tiene sus raíces en el almacenamiento de datos, que se remonta a la década de 1970, con el almacén de datos empresariales que se configura a lo largo de la década de 1980 y Bill Inmon, que acuña oficialmente el término warehouse (almacén de datos) en 1989. Después de que los ingenieros de IBM desarrollaran la base de datos relacional y el lenguaje de consulta estructurado (SQL), Oracle popularizó la tecnología. A medida que los incipientes sistemas de datos crecían, las empresas necesitaban herramientas y pipelines de datos específicos para la elaboración de informes y la inteligencia empresarial (Business Intelligence, BI). Para ayudar a las personas a modelar correctamente su lógica empresarial en el almacén de datos, Ralph Kimball e Inmon desarrollaron sus respectivas técnicas y enfoques de modelado de datos, que llevan sus nombres, y que todavía se utilizan ampliamente en la actualidad.

El almacenamiento de datos marcó el comienzo de la primera era de la analítica escalable, con la aparición de nuevas bases de datos de procesamiento masivo en paralelo (Massive Parallel Processing, MPP), que utilizan múltiples procesadores para procesar grandes cantidades de datos y soportan volúmenes de datos sin precedentes. Roles como el de ingeniero de BI, desarrollador de ETL e ingeniero de almacén de datos abordaron las diversas necesidades del almacén de datos. Los ingenieros de almacén de datos y de BI fueron los precursores de la actual ingeniería de datos y siguen desempeñando un papel fundamental en esta disciplina.

Internet se generalizó a mediados de la década de los 90, y creó toda una nueva generación de empresas que se orientaban a la web, como AOL, Yahoo y Amazon. El auge de las empresas puntocom generó una gran actividad en las aplicaciones web y los sistemas de backend que las soportaban: servidores, bases de datos y almacenamiento. Gran parte de la infraestructura era cara, monolítica y con muchas licencias. Los proveedores que vendían estos sistemas backend probablemente no previeron la magnitud de datos que producirían las aplicaciones web.

Principios de la década de 2000: el nacimiento de la ingeniería de datos contemporánea

Avancemos hasta principios de la década de 2000, cuando el boom de las puntocom de finales de los 90 se vino abajo, dejando atrás un pequeño grupo de supervivientes. Algunas de estas empresas, como Yahoo, Google y Amazon, se convertirían en poderosas compañías tecnológicas. Al principio, estas empresas siguieron confiando en las tradicionales bases de datos relacionales monolíticas y en los almacenes de datos de los años 90, y llevaron estos sistemas al límite. A medida que estos sistemas colapsaban, se iban necesitando enfoques actualizados para gestionar el crecimiento de los datos. La nueva generación de sistemas debía ser rentable, escalable, estar disponible y ser fiable.

Coincidiendo con la explosión de los datos, el hardware básico (como son los servidores, la memoria RAM, los discos y las unidades flash) también se abarató y se hizo omnipresente. Varias innovaciones permitieron la computación y el almacenamiento distribuidos en clústeres informáticos masivos a gran escala. Estas innovaciones empezaron a descentralizar y a romper los servicios monolíticos tradicionales. La era de los Big Data había comenzado.

El Oxford English Dictionary define big data (https://oreil.ly/8IaGH) como «conjuntos de datos extremadamente grandes que se pueden analizar computacionalmente para revelar patrones, tendencias y asociaciones, especialmente relacionadas con el comportamiento y las interacciones humanas». Otra famosa y sucinta descripción de Big Data es la de las tres V de los datos: velocidad, variedad y volumen.

En 2003, Google publicó un artículo sobre su sistema de archivos y, poco después, en 2004, publicó un artículo sobre MapReduce, un paradigma de procesamiento de datos ultraescalable. En realidad, Big Data tiene antecedentes en los almacenes de datos MPP y en la gestión de datos para proyectos de física experimental; pero las publicaciones de Google constituyeron un «big bang» para las tecnologías de datos y las raíces culturales de la ingeniería de datos tal y como la conocemos hoy en día. Ampliará su aprendizaje sobre los sistemas MPP y MapReduce en los Capítulos 3 y 8, respectivamente.

Los documentos de Google inspiraron a los ingenieros de Yahoo para desarrollar y, posteriormente, abrir el código de Apache Hadoop en 20066. Es difícil superar el impacto de Hadoop. Los ingenieros de software interesados en problemas de datos a gran escala se vieron atraídos por las posibilidades de este nuevo ecosistema tecnológico de código abierto. A medida que empresas de todos los tamaños y tipos veían crecer sus datos hasta alcanzar muchos terabytes, e incluso petabytes, fue creciendo la era del ingeniero de Big Data.

Al mismo tiempo, Amazon tuvo que seguir el ritmo de las propias necesidades de la expansión de sus datos y creó entornos informáticos elásticos (Amazon Elastic Compute Cloud, o EC2), sistemas de almacenamiento infinitamente escalables (Amazon Simple Storage Service, o S3), bases de datos NoSQL altamente escalables (Amazon DynamoDB) y muchos otros componentes de datos básicos7. Amazon decidió ofrecer estos servicios para consumo interno y externo a través de AmazonWeb Services (AWS), convirtiéndose así en la primera nube pública popular. AWS creó un mercado de recursos ultraflexibles de pago por uso mediante la virtualización y reventa de grandes conjuntos de hardware básico. En lugar de comprar el hardware para un centro de datos, los desarrolladores podían simplemente alquilar la computación y el almacenamiento de AWS.

Cuando AWS se convirtió en un motor de crecimiento muy rentable para Amazon, no tardaron en seguirle otras nubes públicas, como Google Cloud, Microsoft Azure y Digital Ocean. La nube pública es, sin duda, una de las innovaciones más importantes del siglo XXI y generó una revolución en la forma de desarrollar y desplegar aplicaciones de software y datos.

Las primeras herramientas de Big Data y de la nube pública sentaron las bases del ecosistema de datos actual. El panorama moderno de los datos, y la ingeniería de datos tal y como la conocemos ahora, no existirían sin estas innovaciones.

Las décadas de 2000 y 2010: la ingeniería de Big Data

Las herramientas de Big Data de código abierto del ecosistema Hadoop maduraron rápidamente y se extendieron desde Silicon Valley a las empresas tecnológicas de todo el mundo. Por primera vez, cualquier empresa tenía acceso a las mismas herramientas de datos de última generación utilizadas por las principales empresas tecnológicas. Otra revolución se produjo con la transición de la computación por lotes al streaming de eventos, que dio paso a una nueva era de Big Data en «tiempo real». A lo largo de este libro aprenderá sobre la computación por lotes y el streaming de eventos.

Los ingenieros podían elegir lo último y lo mejor: Hadoop, Apache Pig, Apache Hive, Dremel, Apache HBase, Apache Storm, Apache Cassandra, Apache Spark, Presto y muchas otras nuevas tecnologías que aparecieron en escena. Las herramientas de datos tradicionales orientadas a la empresa y basadas en la interfaz gráfica de usuario (Graphic User interface, GUI) se consideraron de repente anticuadas, y la ingeniería de «lo primero es el código» se puso de moda con el ascenso de MapReduce. Nosotros (los autores) ya estábamos en esa época, y parecía que los viejos dogmas morían repentinamente en el altar del Big Data.

La explosión de las herramientas de datos a finales de la década de 2000 y a lo largo de la década de 2010 dio paso al ingeniero de Big Data. Para utilizar eficazmente estas herramientas y técnicas (en concreto, el ecosistema Hadoop, que incluye Hadoop, YARN, Hadoop Distributed File System y MapReduce), los ingenieros de Big Data tenían que ser competentes en el desarrollo de software y en el hacking de bajo nivel, pero con un interés diferente. Los ingenieros de Big Data solían mantener clústeres masivos de hardware básico para proporcionar datos a escala. Aunque ocasionalmente podían enviar solicitudes pull al código del core Hadoop, cambiaron su enfoque del desarrollo de la tecnología core al de la entrega de datos.

Big Data se convirtió rápidamente en víctima de su propio éxito. Como palabra de moda, Big Data ganó popularidad desde principios de la década de 2000 hasta mediados de la de 2010. Capturó la imaginación de las empresas que intentaban dar sentido a los crecientes volúmenes de datos y al interminable bombardeo del marketing descarado de las empresas que vendían herramientas y servicios de Big Data. Debido al inmenso bombo y platillo, era habitual ver a las empresas utilizando herramientas de Big Data para problemas de datos de pequeño volumen (a veces montando un clúster Hadoop para procesar solo unos pocos gigabytes). Parecía que todo el mundo quería participar en la acción de Big Data. Dan Ariel tuiteó (https://oreil.ly/cpL26): «Big Data es como el sexo adolescente: todo el mundo habla de ello, nadie sabe realmente cómo hacerlo, todos piensan que los demás lo hacen, así que todos afirman que lo hacen».

La Figura 1-2 muestra una instantánea de Google Trends para el término de búsqueda «Big Data». Viéndola, podrá hacerse una idea del auge y la caída del Big Data.

Figura 1-2.Google Trends para «Big Data» (marzo de 2022).

A pesar de la popularidad del término, Big Data ha perdido fuerza. ¿Qué ha pasado? Una palabra: simplificación. A pesar de la potencia y sofisticación de las herramientas de Big Data de código abierto, su gestión suponía mucho trabajo y requería una atención constante. A menudo, las empresas empleaban equipos enteros de ingenieros de Big Data, que costaban millones de dólares al año, para cuidar estas plataformas. Los ingenieros de Big Data solían dedicar demasiado tiempo al mantenimiento de las complicadas herramientas y, posiblemente, no dedicaban tanto tiempo a la obtención de información y generación de valor para la empresa.

Los desarrolladores de código abierto, las nubes y terceros empezaron a buscar formas de resumir, simplificar y hacer que los Big Data estuvieran disponibles sin la elevada sobrecarga administrativa y el coste de gestionar sus clústeres y de instalar, configurar y actualizar su código fuente abierto. El término «Big Data» es esencialmente una reliquia con la que describir una época y un enfoque particular para manejar grandes cantidades de datos.

Hoy en día, los datos se mueven más rápido que nunca y crecen cada vez más, pero el procesamiento de Big Data se ha vuelto tan accesible que ya no merece la pena utilizar un término por separado; todas las empresas pretenden resolver sus problemas de datos, independientemente del tamaño real de los mismos. Los ingenieros de Big Data son ahora, simplemente, ingenieros de datos.

La década de 2020: ingeniería para el ciclo de vida de los datos

En el momento de escribir estas líneas, el papel de la ingeniería de datos está evolucionando muy rápidamente. Esperamos que esta evolución continúe a un ritmo rápido en el futuro inmediato. Mientras que los ingenieros de datos se han dedicado históricamente a los detalles de bajo nivel de los frameworks monolíticos como Hadoop, Spark o Informática, la tendencia se dirige hacia herramientas descentralizadas, modulares, gestionadas y altamente abstractas.

De hecho, las herramientas de datos han proliferado a un ritmo asombroso (véase la Figura 1-3). Las tendencias más populares de principios de la década de 2020 incluyen la pila de datos moderna, que representa una colección de productos de código abierto y de terceros reunidos para facilitar la vida de los analistas. Al mismo tiempo, las fuentes de datos y los formatos de datos están creciendo tanto en variedad como en tamaño. La ingeniería de datos es cada vez más una disciplina de interoperabilidad y de conexión de varias tecnologías, como si fueran ladrillos de LEGO, para servir a los objetivos empresariales finales.

Figura 1-3.Panorama de datos de Matt Turck (https://oreil.ly/TWTfM) en 2012 frente a 2021.

El ingeniero de datos del que hablamos en este libro puede describirse con mayor precisión como ingeniero del ciclo de vida de los datos. Con una mayor abstracción y simplificación, un ingeniero del ciclo de vida de los datos ya no se ve afectado por los detalles escabrosos de los frameworks del Big Data de ayer. Si bien los ingenieros de datos mantienen sus habilidades en la programación de datos de bajo nivel y las utilizan según sea necesario, su función se centra cada vez más en aspectos más altos de la cadena de valor: seguridad, gestión de datos, operaciones de datos, arquitectura de datos, orquestación y gestión general del ciclo de vida de los datos8.

A medida que se simplifican las herramientas y los flujos de trabajo, hemos visto un cambio notable en la actitud de los ingenieros de datos. En lugar de centrarse en quién tiene los «volúmenes de datos más grandes», los proyectos y servicios de código abierto se preocupan cada vez más por gestionar y gobernar los datos, facilitando su uso y descubrimiento, y mejorando su calidad. Los ingenieros de datos están ahora familiarizados con las siglas CCPA y GDPR9; mientras diseñan pipelines de datos, se preocupan por la privacidad, por conseguir que los datos sean anónimos, por la recolección de datos basura y por el cumplimiento normativo de las regulaciones.

Lo viejo vuelve a ser nuevo. Mientras que las cosas «empresariales», como la gestión de datos (incluida la calidad y la gobernanza de los datos), eran comunes para las grandes empresas en la era anterior a Big Data, no se adoptaron de forma amplia en las empresas más pequeñas. Ahora que muchos de los problemas de los sistemas de datos de ayer se han resuelto, producido y empaquetado, los tecnólogos y empresarios han vuelto a centrarse en las cosas «empresariales», pero haciendo hincapié en la descentralización y la agilidad, lo que contrasta con el enfoque tradicional de mando y control de la empresa.

Vemos el presente como una edad de oro de la gestión del ciclo de vida de los datos. Los ingenieros de datos que gestionan el ciclo de vida de la ingeniería de datos disponen de mejores herramientas y técnicas que nunca. En el siguiente capítulo tratamos el ciclo de vida de la ingeniería de datos y sus undercurrents con mayor detalle.

Ingeniería de datos y ciencia de datos

¿Dónde encaja la ingeniería de datos en la ciencia de datos? En relación con este tema existe un debate, ya que algunos sostienen que la ingeniería de datos es una disciplina dentro de la disciplina de la ciencia de datos. Nosotros creemos que la ingeniería de datos está separada de la ciencia de datos y la analítica. Se complementan, pero son claramente diferentes. La ingeniería de datos se sitúa antes de la ciencia de datos (Figura 1-4), lo que significa que los ingenieros de datos proporcionan las entradas que utilizan los científicos de datos (que se encuentran después de la ingeniería de datos), que convierten esas entradas en algo útil.

Figura 1-4.La ingeniería de datos se sitúa antes de la ciencia de datos.

Considere la jerarquía de necesidades de la ciencia de datos (Figura 1-5). En 2017, Monica Rogati publicó esta jerarquía en un artículo (https://oreil.ly/pGg9U) que mostraba dónde se situaban la AI y machine learning (ML) en cuanto a la proximidad a áreas más «mundanas», como el movimiento/almacenamiento de datos, la recopilación y la infraestructura.

Figura 1-5.Jerarquía de necesidades de la ciencia de datos (https://oreil.ly/pGg9U).

Aunque muchos científicos de datos están ansiosos por elaborar y ajustar modelos de machine learning (ML), la realidad es que se estima que entre el 70 y el 80 % de su tiempo se dedica a las tres partes inferiores de la jerarquía: recopilación de datos, limpieza de datos y procesamiento de datos; y solo una pequeña parte de su tiempo se dedica al análisis y a ML. Rogati sostiene que las empresas deben crear una base sólida de datos (los tres niveles inferiores de la jerarquía) antes de abordar áreas como AI y ML.

Los científicos de datos no suelen tener formación para diseñar sistemas de datos a nivel de producción, y acaban haciendo este trabajo de forma aleatoria porque carecen del apoyo y de los recursos del ingeniero de datos. En un mundo ideal, los científicos de datos deberían dedicar más del 90 % de su tiempo a las capas superiores de la pirámide: analítica, experimentación y ML. Cuando los ingenieros de datos se centran en estas partes inferiores de la jerarquía, crean una base sólida para que los científicos de datos tengan éxito.

Dado que la ciencia de datos impulsa tanto la analítica avanzada como ML, la ingeniería de datos se encuentra a caballo entre la obtención de datos y la obtención de valor a partir de los mismos (véase la Figura 1-6). Creemos que la ingeniería de datos tiene la misma importancia y visibilidad que la ciencia de datos, y que los ingenieros de datos desempeñan un papel fundamental para que la ciencia de datos tenga éxito a nivel de producción.

Figura 1-6.El ingeniero de datos obtiene los datos y proporciona valor a partir de ellos.

Habilidades y actividades de la ingeniería de datos

El conjunto de habilidades del ingeniero de datos abarca los undercurrents de la ingeniería de datos: seguridad, gestión de datos, operaciones de datos, arquitectura de datos e ingeniería de software. Este conjunto de habilidades requiere una comprensión de cómo evaluar las herramientas de datos y cómo encajan en el ciclo de vida de la ingeniería de datos. También es fundamental saber cómo se producen los datos en los sistemas fuente y cómo los analistas y científicos de datos consumirán y crearán valor después de procesar y organizar los datos. Por último, el ingeniero de datos hace malabares con muchas piezas móviles complejas y debe optimizar constantemente los ejes de coste, agilidad, escalabilidad, simplicidad, reutilización e interoperabilidad (Figura 1-7). En los próximos capítulos trataremos estos temas con más detalle.

Figura 1-7.Equilibrio de la ingeniería de datos.

Como hemos comentado, en el pasado reciente se esperaba que el ingeniero de datos conociera y entendiera cómo utilizar un pequeño puñado de tecnologías potentes y monolíticas (Hadoop, Spark, Teradata, Hive y muchas otras) para crear una solución de datos. La utilización de estas tecnologías suele requerir una comprensión sofisticada de la ingeniería de software, las redes, la computación distribuida, el almacenamiento y otros detalles de bajo nivel. Su trabajo se dedicaría a la administración y el mantenimiento del clúster, la gestión de la sobrecarga y la escritura de trabajos de pipeline y transformación, entre otras tareas.

Actualmente, el panorama de las herramientas de datos es mucho menos complicado de gestionar e implementar. Las herramientas de datos modernas abstraen y simplifican considerablemente los flujos de trabajo. Como resultado, los ingenieros de datos se centran ahora en equilibrar los servicios más sencillos y rentables, los mejores de su clase, que aporten valor a la empresa. También se espera que el ingeniero de datos pueda crear arquitecturas de datos ágiles que evolucionen a medida que surjan nuevas tendencias.

¿Qué cosas no hace el ingeniero de datos? Un ingeniero de datos no suele crear directamente modelos de ML, crear informes o cuadros de mando, realizar análisis de datos, crear indicadores clave de rendimiento (Key Performace Indicator, KPI) o desarrollar aplicaciones de software. El ingeniero de datos debe tener un buen conocimiento de estas áreas para servir mejor a las partes interesadas.

La madurez de los datos y el ingeniero de datos

El nivel de complejidad de la ingeniería de datos en una empresa depende en gran medida de la madurez de los datos de la empresa. Esto influye de forma importante en las responsabilidades del trabajo diario del ingeniero de datos y en el progreso de su carrera. ¿Qué es exactamente la madurez de los datos?

La madurez de los datos es la progresión hacia una mayor utilización de los datos, capacidades e integración en toda la organización; pero la madurez de los datos no depende simplemente del tiempo de vida o de los ingresos de la empresa. Una empresa en su fase inicial puede tener una mayor madurez de datos que una empresa con 100 años de antigüedad con ingresos anuales de miles de millones. Lo que importa es la forma en que se aprovechan los datos como ventaja competitiva.

Los modelos de madurez de datos tienen muchas versiones, como es el caso del modelo Data Management Maturity (DMM) (https://oreil.ly/HmX62), entre otros, y es difícil elegir uno que sea sencillo y útil para la ingeniería de datos. Así que crearemos nuestro propio modelo de madurez de datos simplificado. Este modelo de madurez de datos (Figura 1-8) tiene tres etapas: empezar con los datos, escalar con los datos y liderar con los datos. Veamos cada una de estas etapas y lo que suele hacer el ingeniero de datos en cada una de ellas.

Figura 1-8.Nuestro modelo simplificado de madurez de datos para una empresa.

Etapa 1: empezar con los datos

Una empresa que se inicia en el uso de los datos se encuentra, por definición, en las primeras etapas de su madurez. La empresa puede tener objetivos difusos y poco definidos o no tenerlos. La arquitectura y la infraestructura de datos se encuentran en las primeras fases de planificación y desarrollo. La adopción y la utilización de los datos son probablemente incipientes o inexistentes. El equipo de datos es pequeño, a menudo con una plantilla de un solo dígito. En esta fase, el ingeniero de datos suele ser un generalista y suele desempeñar otras funciones, como científico de datos o ingeniero de software. El objetivo del ingeniero de datos es avanzar rápidamente, conseguir impulso y añadir valor.

Los aspectos prácticos de la obtención de valor de los datos suelen ser poco conocidos, pero el deseo de hacerlo existe. Los informes o análisis carecen de una estructura formal y la mayoría de las solicitudes de datos son ad hoc. Aunque en esta fase es tentador lanzarse de cabeza a ML, no lo recomendamos. Hemos visto cómo innumerables equipos de datos se atascan y se quedan cortos cuando intentan saltar a ML sin crear una base de datos sólida.

Esto no quiere decir que no se puedan obtener éxitos con ML en esta etapa: es raro, pero es posible. Sin una base de datos sólida, es probable que no se tengan los datos para entrenar modelos de ML fiables ni los medios para desplegar estos modelos en producción de una manera escalable y repetible. Nos llamamos a nosotros mismos, medio en broma, «científicos de datos en proceso de recuperación» (https://oreil.ly/2wXbD), principalmente por la experiencia personal de haber participado en proyectos de ciencia de datos prematuros sin la madurez de datos adecuada o el apoyo de la ingeniería de datos.

En las organizaciones que se inician en los datos, el ingeniero de datos debe centrarse en lo siguiente:

• Conseguir la aprobación de los principales interesados, incluida la dirección ejecutiva. Lo ideal es que el ingeniero de datos cuente con un patrocinador de las iniciativas críticas para diseñar y construir una arquitectura de datos que apoye los objetivos de la empresa.

• Definir la arquitectura de datos adecuada (normalmente en solitario, ya que probablemente no se disponga de un arquitecto de datos). Esto significa determinar los objetivos empresariales y la ventaja competitiva que se pretende conseguir con la iniciativa de los datos. Trabajar en una arquitectura de datos que apoye estos objetivos. Consulte el Capítulo 3 para ver nuestros consejos sobre lo que es una «buena» arquitectura de datos.

• Identificar y auditar los datos que respaldarán las iniciativas clave y que funcionarán en la arquitectura de datos que usted diseñó.

• Elaborar una base de datos sólida para que los futuros analistas y científicos de datos generen informes y modelos que aporten valor competitivo. Mientras tanto, es posible que también tenga que generar estos informes y modelos hasta que se contrate al equipo.

Se trata de una etapa delicada con muchas trampas. Aquí tiene algunos consejos para esta etapa:

• La fuerza de voluntad de la organización se puede resentir si no se producen muchos éxitos visibles con los datos. La obtención de resultados rápidos hará que los datos cobren importancia dentro de la organización. Solo hay que tener en cuenta que las victorias rápidas probablemente crearán una deuda técnica. Tenga un plan para reducir esta deuda, ya que, de lo contrario, añadirá fricción a la futura entrega.

• Salir y hablar con la gente, y evitar trabajar en compartimentos estancos. A menudo vemos al equipo de datos trabajando en una burbuja, sin comunicarse con personas ajenas a sus departamentos y sin obtener perspectivas y opiniones de las partes interesadas del negocio. El peligro es que pase mucho tiempo trabajando en cosas poco útiles para la gente.

• Evitar el trabajo pesado e indiferenciado. No encerrarse en una complejidad técnica innecesaria. Utilizar soluciones listas para usar siempre que sea posible.

• Crear soluciones y códigos personalizados solo cuando estas opciones proporcionen una ventaja competitiva.

Etapa 2: escalar con los datos

En este punto, la empresa se ha alejado de las solicitudes de datos ad hoc y tiene las prácticas convencionales en datos. Ahora el reto es crear arquitecturas de datos escalables y planificar un futuro en el que la empresa esté realmente orientada a los datos. Las funciones de la ingeniería de datos pasan de ser generalistas a especialistas, con personas que se centran en aspectos concretos del ciclo de vida de la ingeniería de datos.

En las organizaciones que se encuentran en la fase 2 de madurez de datos, los objetivos del ingeniero de datos son los siguientes:

• Establecer prácticas convencionales en datos.

• Crear arquitecturas de datos escalables y robustas.

• Adoptar prácticas de operaciones de desarrollo y operaciones de datos.

• Crear sistemas que apoyen ML.

• Seguir evitando el trabajo pesado indiferenciado y personalizar solo cuando se obtenga una ventaja competitiva.

Volveremos a hablar de cada uno de estos objetivos más adelante en el libro.

Entre las cuestiones a las que hay que prestar atención se encuentran las siguientes:

• A medida que nos volvemos más sofisticados con los datos, existe la tentación de adoptar tecnologías de vanguardia basadas en la prueba social de las empresas de Silicon Valley. Esto no suele constituir un buen uso de su tiempo y energía. Cualquier decisión tecnológica debe estar motivada por el valor que aportará a sus clientes.

• El principal cuello de botella para el escalado no son los nodos del clúster, el almacenamiento o la tecnología, sino el equipo de ingeniería de datos. Céntrese en soluciones que sean sencillas de desplegar y gestionar para aumentar el rendimiento de su equipo.

• Tendrá la tentación de presentarse como un tecnólogo, un genio de los datos que puede ofrecer productos mágicos. En lugar de actuar de esa manera, cambie su enfoque hacia un liderazgo pragmático y comience la transición a la siguiente etapa de madurez; comunique a otros equipos la utilidad práctica de los datos. Enseñe a la organización a consumir y aprovechar los datos.

Etapa 3: dirigir con los datos

En esta fase, la empresa se basa en los datos. Los pipelines y sistemas automatizados creados por los ingenieros de datos permiten a los empleados de la empresa realizar analítica de autoservicio y ML. La introducción de nuevas fuentes de datos es perfecta y se obtiene un valor tangible. Los ingenieros de datos implementan controles y prácticas adecuadas para garantizar que los datos estén siempre disponibles para las personas y los sistemas. Los roles de la ingeniería de datos continúan especializándose más profundamente que en la etapa 2.

En las organizaciones que se encuentran en la etapa 3 de madurez de datos, el ingeniero de datos continuará el desarrollo sobre las etapas anteriores, además de hacer lo siguiente:

• Crear la automatización para la introducción y el uso de nuevos datos sin problemas.

• Centrarse en el desarrollo de herramientas y sistemas personalizados que aprovechen los datos como ventaja competitiva.

• Centrarse en los aspectos «empresariales» de los datos (como su gestión, incluidas la gobernanza y la calidad de los datos) y de las operaciones de datos.

• Implantar herramientas que expongan y difundan los datos en toda la organización, incluidos los catálogos de datos, las herramientas de linaje de datos y los sistemas de gestión de metadatos.

• Colaborar eficazmente con los ingenieros de software, ingenieros de ML y analistas.

• Crear una comunidad y un entorno en el que las personas puedan colaborar y hablar abiertamente, independientemente de su función o posición.