La hoja de ruta de los datos de autoservicio

Capítulo 1. Introducción Introducción

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Los datos son el nuevo petróleo. Se ha producido un crecimiento exponencial de la cantidad de datos estructurados, semiestructurados y no estructurados recopilados en las empresas. La información extraída de los datos se está convirtiendo en un valioso elemento diferenciador para las empresas de todos los sectores verticales, y los modelos de aprendizaje automático (ML) se utilizan en las características de los productos, así como en la mejora de los procesos empresariales.

Las empresas actuales son ricas en datos, pero pobres en información. Gartner predice que el 80% de los conocimientos analíticos no producirán resultados empresariales hasta 2022. Otro estudio destaca que el 87% de los proyectos de datos nunca llegan a la implementación de producción. Sculley et al. de Google demuestran que menos del 5% del esfuerzo de implantación del ML en producción se dedica a los algoritmos ML reales (como se ilustra en la Figura 1-1). El 95% restante del esfuerzo se dedica a la ingeniería de datos relacionada con el descubrimiento, la recopilación y la preparación de los datos, así como a la construcción e implementación de los modelos en producción.

Aunque se recoge una enorme cantidad de datos en los lagos de datos, puede que no sean coherentes, interpretables, precisos, oportunos, normalizados o suficientes. Los científicos de datos dedican una gran cantidad de tiempo a actividades de ingeniería relacionadas con la alineación de sistemas para la recopilación de datos, la definición de metadatos, la manipulación de datos para alimentar algoritmos de ML, la implementación de tuberías y modelos a escala, etcétera. Estas actividades están fuera de sus competencias básicas de extracción de información, y se ven obstaculizadas por la dependencia de los ingenieros de datos y de los ingenieros informáticos de plataforma, que normalmente carecen del contexto empresarial necesario. La complejidad de la ingeniería limita la accesibilidad de los datos a los analistas y científicos de datos, en lugar de democratizarla a un número creciente de ciudadanos de datos en la gestión de productos, marketing, finanzas, ingeniería, etc. Aunque hay una plétora de libros sobre el avance en la programación ML, y libros de profundización sobre tecnologías de datos específicas, hay poco escrito sobre los patrones operativos para la ingeniería de datos necesarios para desarrollar una plataforma de autoservicio que dé soporte a un amplio espectro de usuarios de datos.

Figura 1-1. El estudio de Sculley et al. analizó el tiempo empleado en llevar los modelos ML a producción. El código ML ocupó el 5% del tiempo empleado, mientras que el 95% del tiempo se dedicó a las restantes casillas relacionadas con las actividades de ingeniería de datos.

Varias empresas han identificado la necesidad de automatizar y hacer autoservicio el viaje de los datos a la información. TensorFlow Extended (TFX) de Google, Michelangelo de Uber, y FBLearner Flow de Facebook son ejemplos de plataformas de autoservicio para desarrollar conocimientos de ML. No existe una estrategia milagrosa que pueda adoptarse universalmente. Cada empresa es única en cuanto a los componentes tecnológicos existentes, la calidad de los conjuntos de datos, los tipos de casos de uso admitidos, los procesos y las aptitudes del personal. Por ejemplo, crear una plataforma de autoservicio para un puñado de científicos de datos expertos que desarrollen modelos ML utilizando conjuntos de datos limpios es muy diferente de una plataforma que dé soporte a usuarios de datos heterogéneos que utilicen conjuntos de datos de calidad variable con herramientas propias para la ingestión, la programación y otros bloques de construcción.

A pesar de las importantes inversiones en tecnologías de datos, hay tres razones, basadas en mi experiencia, por las que las iniciativas de plataformas de datos de autoservicio no llegan a despegar o pierden fuelle a mitad de camino durante su ejecución:

Puntos de dolor reales de los usuarios de datos que se pierden en la traducción

Los usuarios de datos y los ingenieros de plataformas de datos hablan idiomas diferentes. Los ingenieros de datos no tienen el contexto del problema empresarial y los puntos de dolor encontrados en el mapa de viaje. Los usuarios de datos no comprenden las limitaciones y realidades de las tecnologías de big data. Esto lleva a señalar con el dedo y a tirarse los problemas entre equipos, sin una solución duradera.

Adoptar nuevas tecnologías "brillantes" por el bien de la tecnología

Dada la plétora de soluciones, los equipos a menudo invierten en la siguiente tecnología "brillante" sin comprender claramente los problemas que ralentizan la hoja de ruta de la extracción de información. A menudo, las empresas acaban invirtiendo en tecnología por el bien de la tecnología, sin reducir el tiempo total de obtención de información.

Abordar demasiadas cosas durante el proceso de transformación

Las múltiples capacidades hacen que una plataforma sea autoservicio. A menudo, los equipos pretenden trabajar en todos los aspectos simultáneamente, lo que es análogo a hervir el océano. En cambio, el desarrollo de plataformas de datos de autoservicio debería ser como el desarrollo de coches autoconducidos, que tienen diferentes niveles de capacidades de autoconducción que varían en nivel de automatización y complejidad de implementación.

Mapa de viaje de los datos brutos a la información

Tradicionalmente, un almacén de datos agregaba datos de bases de datos transaccionales y generaba informes retrospectivos por lotes. Las soluciones de almacenamiento solían estar empaquetadas y vendidas por un único proveedor con funciones integradas de catalogación de metadatos, programación de consultas, conectores de ingestión, etc. El motor de consulta y el almacenamiento de datos se acoplaban con opciones limitadas de interoperabilidad . Hoy en día, en la era de los grandes datos, la plataforma de datos es un mosaico de diferentes almacenes de datos, marcos y motores de procesamiento que soportan una amplia gama de propiedades de datos y tipos de información. Hay muchas opciones tecnológicas en las implementaciones locales, en la nube o híbridas, y la disociación del almacenamiento y el cálculo ha permitido mezclar y combinar los almacenes de datos, los motores de procesamiento y los marcos de gestión. El mantra en la era de los grandes datos es utilizar la "herramienta adecuada para el trabajo adecuado" en función del tipo de datos, los requisitos del caso de uso, la sofisticación de los usuarios de los datos y la interoperabilidad con las tecnologías desplegadas. La Tabla 1-1 destaca las diferencias clave.

Tabla 1-1. Las diferencias clave en la extracción de información de los almacenes de datos tradicionales en comparación con la era moderna de los grandes datos

	Extraer información en la era del almacenamiento de datos	Extraer información en la era de los grandes datos
Formatos de datos	Datos estructurados	Datos estructurados, semiestructurados y no estructurados
Características de los datos	Datos de gran volumen	Las4 V de los datos: volumen, velocidad, variedad y veracidad
Datos de catalogación	Definidos en el momento de agregar los datos	Definido en el momento de leer los datos
Frescura de las ideas	Las percepciones son principalmente retrospectivas (por ejemplo, lo que ocurrió en la empresa la semana pasada)	Las percepciones son una combinación de retrospectivas, interactivas, en tiempo real y predictivas
Enfoque del procesamiento de consultas	Procesador de consultas y almacenamiento de datos acoplados como una única solución	Procesamiento de consultas y almacenamiento de datos desacoplados
Servicios de datos	Integrado como una solución unificada	Mezcla y combina, lo que permite muchas permutaciones para seleccionar la herramienta adecuada para el trabajo

La hoja de ruta para desarrollar cualquier conocimiento puede dividirse en cuatro fases clave: descubrir, preparar, construir y poner en funcionamiento (como se muestra en la Figura 1-2). Para ilustrar la hoja de ruta, considera el ejemplo de crear un cuadro de mando de información empresarial en tiempo real que haga un seguimiento de los ingresos, el rendimiento de las campañas de marketing, las altas y bajas de clientes, etcétera. El cuadro de mandos también incluye un modelo de previsión ML de los ingresos en distintas ubicaciones geográficas.

Figura 1-2. La hoja de ruta para extraer información de los datos brutos.

Descubre

Cualquier proyecto de insights comienza con el descubrimiento de los conjuntos de datos y artefactos disponibles, así como con la recopilación de los datos adicionales necesarios para desarrollar el insight. La complejidad del descubrimiento de datos surge como resultado de la dificultad de escalar el conocimiento dentro de la empresa. Los equipos de datos suelen empezar a pequeña escala con conocimientos de equipo que son fácilmente accesibles y fiables. A medida que los datos crecen y los equipos se amplían, se crean silos entre las líneas de negocio, lo que hace que no exista una única fuente de verdad. Hoy en día, los usuarios de datos tienen que navegar eficazmente por un mar de recursos de datos de calidad, complejidad, relevancia y fiabilidad variables. En el ejemplo del cuadro de mandos empresarial en tiempo real y el modelo de previsión de ingresos, el punto de partida para los usuarios de datos es comprender los metadatos de los conjuntos de datos de uso común, a saber, el perfil del cliente, los registros de inicio de sesión, los conjuntos de datos de facturación, precios y promociones, etc.

Descubrir los detalles de los metadatos de un conjunto de datos

El primer hito es comprender las propiedades de los metadatos, como dónde se originaron los datos, cómo se generaron los atributos de los datos, etc. Los metadatos también desempeñan un papel clave a la hora de determinar la calidad y fiabilidad de los datos. Por ejemplo, si el modelo se construye utilizando una tabla que no se rellena correctamente o tiene fallos en sus conductos de datos, el modelo resultante será incorrecto y poco fiable. Los usuarios de los datos parten de los conocimientos del equipo disponibles de otros usuarios, que pueden estar desfasados y ser poco fiables. Recopilar y correlacionar metadatos requiere acceder a almacenes de datos, marcos de ingestión, programadores, catálogos de metadatos, marcos de cumplimiento, etc. No existe un formato estandarizado para rastrear los metadatos de un conjunto de datos a medida que se recopilan y transforman. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para interpretar.

Buscar conjuntos de datos y artefactos disponibles

Con la capacidad de comprender los detalles de los metadatos de un conjunto de datos, el siguiente hito es encontrar todos los conjuntos de datos y artefactos relevantes, es decir, vistas, archivos, flujos, eventos, métricas, cuadros de mando, ETL y consultas ad hoc. En una empresa típica, hay miles o millones de conjuntos de datos. Como ejemplo extremo, Google tiene 26.000 millones de conjuntos de datos. Dependiendo de la escala, los usuarios de datos pueden tardar días y semanas en identificar detalles relevantes. Hoy en día, la búsqueda se basa en gran medida en el conocimiento del equipo de usuarios de datos y en el contacto con los desarrolladores de aplicaciones. Los conjuntos de datos y artefactos disponibles evolucionan continuamente y deben actualizarse continuamente. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para encontrar.

Reutilizar o crear características para modelos ML

Siguiendo con el ejemplo, el desarrollo de los modelos de previsión de ingresos requiere un entrenamiento utilizando valores históricos de cifras de ingresos por mercado, línea de productos, etc. Los atributos como los ingresos que se introducen en el modelo ML se denominan características. Un atributo puede utilizarse como característica si se dispone de valores históricos. En el proceso de creación de modelos de ML, los científicos de datos iteran sobre las combinaciones de características para generar el modelo más preciso. Los científicos de datos dedican el 60% de su tiempo a crear conjuntos de datos de entrenamiento para generar características para los modelos de ML. Reutilizar las características existentes puede reducir radicalmente el tiempo de desarrollo de los modelos de ML. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para featurizar.

Agregar los datos que faltan

Para crear el cuadro de mando empresarial, hay que unir los conjuntos de datos identificados (como la actividad de los clientes y los registros de facturación) para generar la visión del riesgo de retención. Los conjuntos de datos que se encuentran en diferentes silos de aplicaciones a menudo deben trasladarse a un repositorio centralizado, como un lago de datos. Mover los datos implica orquestar el movimiento de datos a través de sistemas heterogéneos, verificar la corrección de los datos y adaptarse a cualquier cambio de esquema o configuración que se produzca en la fuente de datos. Una vez desplegados los insights en producción, el movimiento de datos es una tarea continua y debe gestionarse como parte del pipeline. El tiempo necesario para completar este hito se controla mediante la métrica tiempo hasta la disponibilidad de los datos.

Gestión de eventos clickstream

En el cuadro de mandos empresarial, supongamos que queremos analizar los flujos de trabajo que más tiempo consumen dentro de la aplicación. Esto requiere analizar la actividad del cliente en términos de clics, vistas y contexto relacionado, como las páginas anteriores de la aplicación, el tipo de dispositivo del visitante, etc. Para rastrear la actividad, los usuarios de datos pueden aprovechar la instrumentación existente dentro del producto que registra la actividad o añadir instrumentación adicional para registrar los clics en widgets específicos, como botones. Los datos del flujo de clics deben agregarse, filtrarse y enriquecerse antes de que puedan consumirse para generar perspectivas. Por ejemplo, el tráfico generado por bots debe filtrarse de los eventos sin procesar. Manejar un gran volumen de eventos de flujo es extremadamente difícil, especialmente en casos de uso casi en tiempo real, como la personalización dirigida. El tiempo necesario para completar este hito de recopilación, análisis y agregación de datos de comportamiento se rastrea mediante la métrica tiempo para hacer clic.

Prepara

La fase de preparación se centra en conseguir que los datos estén listos para construir la lógica empresarial real para extraer información. La preparación es una tarea iterativa que requiere mucho tiempo e incluye la agregación, limpieza, normalización, transformación y desnormalización de los datos. Implica múltiples herramientas y marcos de trabajo. La fase de preparación también debe garantizar la gobernanza de los datos para cumplir los requisitos normativos.

Gestionar los datos agregados en un repositorio central

Siguiendo con el ejemplo, los datos necesarios para el cuadro de mando empresarial y el modelo de previsión están ahora agregados en un repositorio central (comúnmente denominado lago de datos). El cuadro de mandos empresarial necesita combinar datos históricos por lotes, así como eventos de datos de comportamiento en streaming. Los datos deben persistir de forma eficiente en lo que respecta a los modelos de datos y el formato en disco. Al igual que en la gestión de datos tradicional, los usuarios de datos deben garantizar el control de acceso, las copias de seguridad, el control de versiones, las propiedades ACID para las actualizaciones de datos concurrentes, etc. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo de gestión del lago de datos.

Estructurar, limpiar, enriquecer y validar datos

Con los datos ahora agregados en el lago, tenemos que asegurarnos de que los datos están en la forma correcta. Por ejemplo, supongamos que los registros del conjunto de datos de facturación tienen un valor de facturación nulo para los clientes de prueba. Como parte de la estructuración, los nulos se convertirán explícitamente en ceros. Del mismo modo, puede haber valores atípicos en el uso de determinados clientes que deban excluirse para evitar sesgar el análisis general del compromiso. Estas actividades se denominan transformación de datos. La aplicación de transformaciones de wrangling requiere escribir secuencias de comandos idiosincrásicas en lenguajes de programación como Python, Perl y R, o dedicarse a una tediosa edición manual. Dado el creciente volumen, velocidad y variedad de los datos, los usuarios de datos utilizan habilidades de codificación de bajo nivel para aplicar las transformaciones a escala de forma eficiente, fiable y recurrente. Estas transformaciones no son puntuales, sino que deben aplicarse de forma fiable y continua. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo de manipulación.

Garantizar el cumplimiento de los derechos de los datos

Supongamos que el cliente no ha dado su consentimiento para utilizar sus datos de comportamiento para generar perspectivas. Los usuarios de datos deben comprender qué datos de los clientes pueden utilizarse para qué casos de uso. El cumplimiento es un acto de equilibrio entre servir mejor a la experiencia del cliente con conocimientos y garantizar que los datos se utilizan de acuerdo con las directrices del cliente. No existe una heurística sencilla que pueda aplicarse universalmente para resolver este problema. Los usuarios de datos quieren una forma fácil de localizar todos los datos disponibles para un caso de uso determinado, sin tener que preocuparse por las infracciones de la normativa. No existe un identificador único para rastrear los datos de clientes aplicables en todos los silos. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo hasta el cumplimiento.

Construye

Durante la fase de construcción, la atención se centra en escribir la lógica real necesaria para extraer la información. A continuación se indican los hitos clave de esta fase.

Decidir el mejor enfoque para acceder a los datos y analizarlos

Un punto de partida para la fase de construcción es decidir una estrategia para escribir y ejecutar la lógica de insights. Los datos del lago pueden persistir como objetos, o almacenarse en capas de servicio especializadas, a saber, almacenes de valores clave, bases de datos de gráficos, almacenes de documentos, etc. Los usuarios de los datos tienen que decidir si aprovechan las API nativas y las palabras clave de los almacenes de datos, y decidir el motor de consulta para la lógica de procesamiento. Por ejemplo, las consultas cortas e interactivas se ejecutan en clusters Presto, mientras que los procesos por lotes de larga duración se realizan en Hive o en Spark. Lo ideal es que la lógica de transformación sea agnóstica y no cambie cuando los datos se trasladen a un almacén políglota diferente, o si se implementa un motor de consulta distinto. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para virtualizar.

Escribir la lógica de transformación

La lógica real para el cuadro de mando o la visión del modelo se escribe como un Extract-Transform-Load (ETL), Extract-Load-Transform (ELT), o un patrón de análisis de flujo. La lógica empresarial debe traducirse en código real que debe ser eficaz y escalable, además de fácil de gestionar para los cambios. La lógica debe ser monitoreada en cuanto a disponibilidad, calidad y gestión de cambios. El tiempo necesario para completar este hito se controla mediante la métrica tiempo de transformación.

Entrenamiento de los modelos

Para el ejemplo de previsión de ingresos, hay que entrenar un modelo ML. Los valores históricos de ingresos se utilizan para entrenar el modelo. Con conjuntos de datos de tamaño creciente y modelos de aprendizaje profundo complicados, el entrenamiento puede llevar días y semanas. El entrenamiento se ejecuta en una granja de servidores formada por una combinación de CPU y hardware especializado, como las GPU. El entrenamiento es iterativo, con cientos de permutaciones de valores para los parámetros del modelo y los valores de los hiperparámetros que se aplican para encontrar el mejor modelo. El entrenamiento del modelo no se realiza una sola vez; es necesario volver a entrenar los modelos para las propiedades cambiantes de los datos. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo de entrenamiento.

Integrar continuamente los cambios del modelo ML

Supongamos que en el ejemplo del cuadro de mando empresarial se produce un cambio en la definición de cómo se calculan los suscriptores activos. Las canalizaciones de modelos ML evolucionan continuamente con cambios en el esquema de origen, la lógica de las funciones, los conjuntos de datos dependientes, las configuraciones de procesamiento de datos y los algoritmos de los modelos. De forma similar a la ingeniería de software tradicional, los modelos de ML se actualizan constantemente con múltiples cambios realizados diariamente por los equipos. Para integrar los cambios, se realiza un seguimiento de los datos, el código y la configuración asociados a los conductos de ML. Los cambios se verifican mediante su implementación en un entorno de prueba y utilizando datos de producción. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para integrar.

Pruebas A/B de ideas

Considera un ejemplo diferente de un modelo ML que pronostica los precios de la vivienda para los clientes finales. Supongamos que hay dos modelos igualmente precisos desarrollados para esta previsión: ¿cuál es mejor? Una práctica cada vez más extendida en la mayoría de las empresas es la implementación de varios modelos y su presentación a distintos grupos de clientes. Basándose en los datos de comportamiento de uso de los clientes, el objetivo es seleccionar un modelo mejor. Las pruebas A/B -también conocidas como pruebas de cubo, pruebas divididas o experimento controlado- se están convirtiendo en un enfoque estándar para tomar decisiones basadas en datos. Es fundamental integrar las pruebas A/B como parte de la plataforma de datos para garantizar que se aplican definiciones de métricas coherentes en los modelos de ML, los informes empresariales y la experimentación. Configurar correctamente los experimentos de pruebas A/B no es trivial y debe garantizar que no haya desequilibrios que den lugar a una diferencia estadísticamente significativa en una métrica de interés en las poblaciones variantes. Además, los clientes no deben estar expuestos a interacciones entre variantes de diferentes experimentos. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para la prueba A/B.

Operacionaliza

En la fase de operacionalización del mapa de viaje, la perspectiva se implementa en producción. Esta fase continúa hasta que el conocimiento se utiliza activamente en producción.

Verificar y optimizar las consultas

Siguiendo con el ejemplo del cuadro de mando empresarial y el modelo de previsión de ingresos, los usuarios de datos han escrito la lógica de transformación de datos como consultas SQL o modelos de programación de big data (como Apache Spark o Beam) implementados en Python, Java, Scala, etc. La diferencia entre consultas buenas y malas es bastante significativa; basándonos en experiencias reales, una consulta que se ejecuta durante unas horas puede ajustarse para que se complete en minutos. Los usuarios de datos necesitan comprender la multitud de mandos de los motores de consulta como Hadoop, Spark y Presto. Para la mayoría de los usuarios de datos, comprender qué mandos ajustar y su impacto no es trivial y requiere un profundo conocimiento del funcionamiento interno de los motores de consulta. No hay balas de plata: los valores óptimos de los mandos para la consulta varían en función de los modelos de datos, los tipos de consulta, el tamaño de los clústeres, la carga de consultas concurrentes, etc. Como tal, la optimización de consultas es una actividad continua. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para optimizar.

Orquestar canalizaciones

Hay que programar las consultas asociadas al cuadro de mando empresarial y a las canalizaciones de previsión. ¿Cuál es el momento óptimo para ejecutar la canalización? ¿Cómo nos aseguramos de que las dependencias se gestionan correctamente? La orquestación es un acto de equilibrio para garantizar los acuerdos de nivel de servicio (SLA) de los pipelines y la utilización eficiente de los recursos subyacentes. Los pipelines invocan servicios a través de la ingesta, la preparación, la transformación, la formación y la implementación. Los usuarios de datos tienen que monitorizar y depurar los conductos para comprobar la corrección, solidez y puntualidad de estos servicios, lo que no es trivial. La orquestación de las canalizaciones es multiusuario y admite varios equipos y casos de uso empresarial. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo para orquestar.

Implementación de los modelos de ML

El modelo de previsión se implementa en producción de forma que pueda ser llamado por distintos programas para obtener el valor previsto. La implementación del modelo no es una tarea puntual: los modelos ML se actualizan periódicamente en función del reentrenamiento. Los usuarios de datos utilizan secuencias de comandos caseras no estandarizadas para desplegar modelos que deben personalizarse para admitir una amplia gama de tipos de modelos ML, bibliotecas y herramientas ML, formatos de modelos y puntos finales de implementación (como dispositivos IoT, móviles, navegadores y API web). No existen marcos estandarizados para monitorear el rendimiento de los modelos y escalar automáticamente en función de la carga. El tiempo necesario para completar este hito se rastrea mediante la métrica tiempo de implementación.

Monitoreo de la calidad de los conocimientos

Como el cuadro de mando empresarial se utiliza a diario, considera un ejemplo en el que muestre un valor incorrecto para un día concreto. Hay varias cosas que pueden ir mal y provocar problemas de calidad: cambios no coordinados en el esquema de origen, cambios en las propiedades de los elementos de datos, problemas de ingestión, sistemas de origen y destino con datos no sincronizados, fallos de procesamiento, definiciones empresariales incorrectas para generar métricas, y muchas más. Los usuarios de datos necesitan analizar los atributos de los datos en busca de anomalías y depurar la causa raíz de los problemas de calidad detectados. Los usuarios de datos dependen de comprobaciones puntuales que no son escalables con grandes volúmenes de datos que fluyen por múltiples sistemas. El objetivo no es sólo detectar los problemas de calidad de los datos, sino también evitar que los registros de datos de baja calidad se mezclen con el resto de las particiones del conjunto de datos. El tiempo que se tarda en completar este hito se controla mediante la métrica tiempo para conocer la calidad.

Monitoreo continuo de los costes

Ahora tenemos percepciones desplegadas en producción con un monitoreo continuo para garantizar la calidad. La última pieza de la fase operativa es la gestión de costes. La gestión de costes es especialmente crítica en la nube, donde el modelo de pago por uso aumenta linealmente con el uso (en contraste con el modelo tradicional de compra por adelantado y coste fijo). Con la democratización de los datos, en la que los usuarios pueden autogestionar el viaje para extraer información, existe la posibilidad de que se desperdicien recursos de forma significativa y se generen costes sin límite. Una sola consulta errónea ejecutada en GPUs de gama alta puede acumular miles de dólares en cuestión de horas, normalmente para sorpresa de los usuarios de los datos. Los usuarios de datos necesitan responder a preguntas como: a) ¿cuál es el gasto en dólares por aplicación? b) ¿qué equipo se prevé que gaste más de sus presupuestos asignados? c) ¿hay oportunidades de reducir el gasto sin afectar al rendimiento y la disponibilidad? y d) ¿se utilizan adecuadamente los recursos asignados? El tiempo necesario para completar este hito se controla mediante la métrica tiempo para optimizar el coste.

En general, en cada fase del viaje actual, los usuarios de datos dedican un porcentaje significativo de su tiempo a tareas de ingeniería de datos, como mover datos, comprender el linaje de los datos, buscar artefactos de datos, etc. El nirvana ideal para los usuarios de datos es una plataforma de datos de autoservicio que simplifique y automatice estas tareas encontradas durante el viaje diario.

Definir tu cuadro de mando del tiempo de observación

El tiempo hasta la comprensión es la métrica global que mide el tiempo que se tarda en completar todo el recorrido desde los datos brutos hasta la comprensión. En el ejemplo del desarrollo del cuadro de mando empresarial y el modelo de previsión de ingresos, el tiempo hasta la obtención de información representa el número total de días, semanas o meses necesarios para completar las fases del mapa de ruta. Basándome en mi experiencia en la gestión de plataformas de datos, he dividido el mapa de viaje en 18 hitos clave, como se describe en la sección anterior. Asociado a cada hito hay una métrica, de modo que el tiempo total hasta la comprensión es una suma de las métricas de los hitos individuales.

Cada empresa difiere en sus puntos de dolor relacionados con el mapa de viaje. Por ejemplo, en el ejemplo del desarrollo del cuadro de mando empresarial, una empresa puede dedicar la mayor parte del tiempo a interpretar y tiempo a encontrar debido a los múltiples silos y a la falta de documentación, mientras que una empresa de una vertical regulada puede tener el tiempo para cumplir como punto doloroso clave en su mapa de viaje. En general, las empresas varían en sus puntos de dolor debido a las diferencias en la madurez del proceso existente, la tecnología, los conjuntos de datos, las habilidades del equipo de datos, la vertical de la industria, etc. Para evaluar el estado actual de la plataforma de datos, utilizamos un cuadro de mando de tiempo hasta la visión, como se muestra en la Figura 1-3. El objetivo del ejercicio es determinar los hitos que requieren más tiempo en el mapa de viaje general.

Figura 1-3. Cuadro de mando para la métrica del tiempo hasta la visión como suma de las métricas de los hitos individuales dentro del mapa de viaje.

Cada capítulo del resto del libro corresponde a una métrica del cuadro de mando y describe los patrones de diseño para hacerlas autoservicio. A continuación se ofrece un breve resumen de las métricas:

Tiempo para interpretar

Asociado al hito de comprender los detalles de los metadatos de un conjunto de datos antes de utilizarlo para desarrollar perspectivas. Las suposiciones incorrectas sobre el conjunto de datos suelen conducir a percepciones incorrectas. El valor existente de la métrica depende del proceso de definición, extracción y agregación de metadatos técnicos, metadatos operativos y conocimientos del equipo. Para minimizar el tiempo de interpretación y convertirlo en autoservicio, el Capítulo 2 cubre los patrones de implementación de un servicio de catálogo de metadatos que extrae los metadatos rastreando las fuentes, rastrea el linaje de los conjuntos de datos derivados y agrega el conocimiento del equipo en forma de etiquetas, reglas de validación, etc.

Hora de encontrar

Asociado al hito de buscar conjuntos de datos y artefactos relacionados. Un tiempo elevado para encontrar conduce a que los equipos opten por reinventar la rueda desarrollando clones de canalizaciones de datos, cuadros de mando y modelos dentro de la empresa, lo que conduce a múltiples fuentes de la verdad. El valor existente de la métrica depende del proceso existente para indexar, clasificar y controlar el acceso a conjuntos de datos y artefactos. En la mayoría de las empresas, estos procesos son ad hoc o tienen dependencias manuales del equipo de la plataforma de datos. Para minimizar el tiempo de búsqueda y convertirlo en autoservicio, el Capítulo 3 cubre los patrones de implementación de un servicio de búsqueda.

Hora de featurizar

Asociado al hito de gestionar características para el entrenamiento de modelos ML. Los científicos de datos dedican el 60% de su tiempo a crear conjuntos de datos de entrenamiento para modelos ML. El valor actual de la métrica depende del proceso de cálculo y servicio de características. Para minimizar el tiempo de featurización y hacer que sea autoservicio, el Capítulo 4 cubre los patrones de implementación de un servicio de almacenamiento de características.

Tiempo hasta la disponibilidad de los datos

Asociado al hito de mover datos a través de los silos. Los usuarios de datos dedican el 16% de su tiempo a mover datos. El valor actual de la métrica depende del proceso de conexión a fuentes de datos heterogéneas, de la copia y verificación de los datos, y de la adaptación a cualquier cambio de esquema o configuración que se produzca en las fuentes de datos. Para minimizar el tiempo de disponibilidad de los datos y convertirlo en autoservicio, el Capítulo 5 cubre los patrones de implementación de un servicio de movimiento de datos.

Hora de hacer clic en las métricas

Asociada al hito de recopilar, gestionar y analizar eventos de datos de flujo de clics. El valor actual de la métrica depende del proceso de creación de balizas de instrumentación, agregación de eventos, enriquecimiento mediante filtrado y cosido de ID. Para minimizar el tiempo de obtención de la métrica de clics y hacerla autoservicio, el Capítulo 6 cubre los patrones de implementación de un servicio de flujo de clics.

Tiempo de gestión del lago de datos

Asociado al hito de gestionar los datos en un repositorio central. El valor actual de la métrica depende del proceso de gestión de las tareas primitivas del ciclo de vida de los datos, de garantizar la coherencia de las actualizaciones de los datos y de gestionar conjuntamente los datos por lotes y en streaming. Para minimizar el tiempo de gestión del lago de datos y convertirlo en autoservicio, el Capítulo 7 cubre los patrones de implementación de un servicio de gestión del lago de datos.

Hora de luchar

Asociado al hito de estructurar, limpiar, enriquecer y validar datos. El valor actual de la métrica depende del proceso de identificación de los requisitos de curación de datos para un conjunto de datos, la construcción de transformaciones para curación de datos a escala, y el monitoreo operativo de la corrección. Para minimizar el tiempo de curaduría y hacerla autoservicio, el Capítulo 8 cubre los patrones de implementación de un servicio de curaduría de datos.

Tiempo para cumplir

Asociada al hito de garantizar el cumplimiento de los derechos sobre los datos. El valor existente de la métrica depende del proceso para rastrear los datos de los clientes en los silos de aplicaciones, ejecutar las solicitudes de derechos de datos de los clientes y garantizar que los casos de uso sólo utilizan los datos que han sido consentidos por los clientes. Para minimizar el tiempo de cumplimiento y convertirlo en autoservicio, el Capítulo 9 cubre los patrones de implementación de un servicio de gobernanza de derechos de datos.

Es hora de virtualizar

Asociado al hito de seleccionar el enfoque para construir y analizar datos. El valor actual de la métrica depende del proceso de formulación de consultas para acceder a los datos que residen en almacenes de datos políglotas, de las consultas para unir datos entre los almacenes de datos y del procesamiento de las consultas a escala de producción. Para minimizar el tiempo de virtualización y hacerla autoservicio, el Capítulo 10 trata de los patrones de implementación de un servicio de virtualización de datos.

Hora de transformar

Asociado al hito de implementar la lógica de transformación en los pipelines de datos y ML. La transformación puede ser por lotes, casi en tiempo real o en tiempo real. El valor existente de la métrica depende del proceso para definir, ejecutar y operar la lógica de transformación. Para minimizar el tiempo de transformación y hacerla autoservicio, el Capítulo 11 cubre los patrones de implementación de un servicio de transformación de datos .

Hora de entrenar

Asociada al hito del entrenamiento de los modelos ML. El valor existente de la métrica depende del proceso para orquestar el entrenamiento, el ajuste de los parámetros del modelo y el reentrenamiento continuo para nuevas muestras de datos. Para minimizar el tiempo de entrenamiento y hacerlo autoservicio, el Capítulo 12 cubre los patrones de implementación de un servicio de entrenamiento de modelos.

Hora de integrar

Asociada al hito de integrar los cambios de código, datos y configuración en las canalizaciones de ML. El valor actual de la métrica depende del proceso de seguimiento de las iteraciones de las tuberías de ML, de la creación de paquetes reproducibles y de la validación de la corrección de los cambios en las tuberías. Para minimizar el tiempo de integración y hacerla autoservicio, el Capítulo 13 cubre los patrones de implementación de un servicio de integración continua para las tuberías de ML.

Tiempo para la prueba A/B

Asociada al hito de las pruebas A/B. El valor actual de la métrica depende del proceso de diseño de un experimento en línea, la ejecución a escala (incluido el análisis de las métricas) y la optimización continua del experimento. Para minimizar el tiempo de la prueba A/B y hacerla autoservicio, el Capítulo 14 cubre los patrones de implementación de un servicio de pruebas A/B como parte de la plataforma de datos.

Hora de optimizar

Asociada al hito de optimizar las consultas y los programas de big data. El valor existente de la métrica depende del proceso de agregación de estadísticas de monitoreo, análisis de los datos monitoreados e invocación de acciones correctivas basadas en el análisis. Para minimizar el tiempo de la prueba A/B y hacerla autoservicio, el Capítulo 15 trata de los patrones de implementación de un servicio de optimización de consultas.

Hora de orquestar

Asociada al hito de orquestar pipelines en producción. El valor existente de la métrica depende del proceso para diseñar las dependencias de los trabajos, conseguir que se ejecuten eficientemente en los recursos de hardware disponibles, y monitorear su calidad y disponibilidad, especialmente para los pipelines de producción sujetos a SLA. Para minimizar el tiempo de orquestación y hacerla autoservicio, el Capítulo 16 cubre los patrones de implementación de un servicio de orquestación de canalizaciones.

Tiempo de implementación

Asociada al hito de implementación de insights en producción. El valor existente de la métrica depende del proceso para empaquetar y escalar los insights disponibles en forma de puntos finales del modelo, monitoreando la deriva del modelo. Para minimizar el tiempo de despliegue y hacerlo autoservicio, el Capítulo 17 cubre los patrones de implementación de un servicio de despliegue de modelos.

Tiempo para comprender la calidad

Asociado al hito de garantizar la corrección de las percepciones generadas. El valor existente de la métrica depende del proceso para verificar la exactitud de los datos, perfilar las propiedades de los datos en busca de anomalías y evitar proactivamente que los registros de datos de baja calidad contaminen el lago de datos. Para minimizar el tiempo de obtención de insights de calidad y convertirlo en autoservicio, el Capítulo 18 cubre los patrones de implementación de un servicio de observabilidad de la calidad.

Tiempo para optimizar el coste

Asociado al hito de minimizar costes, especialmente cuando se ejecuta en la nube. El valor actual de la métrica depende del proceso para seleccionar servicios en la nube rentables, configurar y hacer funcionar los servicios, y aplicar la optimización de costes de forma continua. Para minimizar el tiempo de optimización de costes y hacer que sea autoservicio, el Capítulo 19 cubre los patrones de implementación de un servicio de gestión de costes.

El resultado final de este análisis es rellenar el cuadro de mando correspondiente al estado actual de la plataforma de datos (similar a la Figura 1-4). Cada métrica está codificada por colores en función de si las tareas asociadas a la métrica pueden completarse, en el orden de horas, días o semanas. Una métrica que tarda un orden de semanas suele representar tareas que hoy en día se ejecutan de forma ad hoc utilizando scripts y programas manuales no estándar y/o tareas que requieren coordinación entre los usuarios de datos y los equipos de la plataforma de datos. Estas métricas representan oportunidades en las que la empresa necesita invertir para que las tareas asociadas sean de autoservicio para los usuarios de datos.

La complejidad asociada a cada una de las métricas del cuadro de mando diferirá entre empresas. Por ejemplo, en una startup con un puñado de conjuntos de datos y miembros del equipo de datos, el tiempo de búsqueda y el tiempo de interpretación pueden lograrse en cuestión de horas si se confía únicamente en los conocimientos del equipo, aunque el proceso sea ad hoc. En cambio, la mayor parte del tiempo puede dedicarse a la gestión de los datos o al seguimiento de la calidad de las percepciones, dada la escasa calidad de los datos disponibles. Además, las empresas varían en los requisitos asociados a cada servicio de la plataforma de datos. Por ejemplo, una empresa que sólo despliega modelos ML entrenados fuera de línea una vez al trimestre (en lugar de un entrenamiento continuo en línea) puede no dar prioridad a la mejora de la métrica del tiempo de entrenamiento, aunque tarde varias semanas.

Figura 1-4. Ejemplo de cuadro de mando que representa el estado actual de la plataforma de datos de una empresa .

Construye tu hoja de ruta de autoservicio de datos

El primer paso para desarrollar la hoja de ruta de los datos de autoservicio es definir el cuadro de mando del estado actual de la plataforma de datos, como se describe en la sección anterior. El cuadro de mando ayuda a preseleccionar las métricas que actualmente ralentizan el viaje de los datos brutos a la información. Cada métrica del cuadro de mando puede estar en un nivel diferente de autoservicio, y priorizarse para su automatización en la hoja de ruta en función del grado en que ralentiza el tiempo total hasta la obtención de información.

Como ya se ha mencionado, cada capítulo abarca patrones de diseño para hacer que la métrica correspondiente sea autoservicio. Consideramos que el autoservicio tiene varios niveles, análogos a los distintos niveles de los coches autoconducidos, que varían en función de los niveles de intervención humana necesarios para hacerlos funcionar (como se ilustra en la Figura 1-5). Por ejemplo, un coche autoconducido de nivel 2 acelera, dirige y frena por sí mismo bajo la supervisión del conductor, mientras que el nivel 5 está totalmente automatizado y no requiere supervisión humana.

Figura 1-5. Diferentes niveles de automatización en un coche autoconducido (de DZone).

Las empresas deben planificar sistemáticamente la hoja de ruta para mejorar el nivel de automatización de cada una de las métricas preseleccionadas. Los patrones de diseño de cada capítulo están organizados como la jerarquía de necesidades de Maslow; el nivel inferior de la pirámide indica el patrón inicial a implantar y le siguen dos niveles más, cada uno de los cuales se basa en el anterior. Toda la pirámide dentro de un capítulo determinado representa el autoservicio, como se muestra en la Figura 1-6.

Figura 1-6. Jerarquía de Maslow de automatización de tareas seguida en cada capítulo.

En resumen, este libro se basa en la experiencia de implantación de plataformas de datos de autoservicio en múltiples empresas. Para obtener el máximo valor del libro, animo a los lectores a aplicar el siguiente enfoque para ejecutar su hoja de ruta de autoservicio:

1. Empieza por definir el cuadro de mando actual.

2. Identifica dos o tres métricas que ralenticen de forma más significativa el mapa de viaje basándote en encuestas a los usuarios de datos, y realiza un análisis técnico de cómo se están implementando actualmente las tareas. Ten en cuenta que la importancia de estas métricas varía en cada empresa en función de sus procesos actuales, las habilidades de los usuarios de datos, los componentes tecnológicos, las propiedades de los datos y los requisitos de los casos de uso.

3. Para cada una de las métricas, comienza con la jerarquía de Maslow de patrones a implementar. Cada capítulo está dedicado a una métrica, y abarca patrones con niveles crecientes de automatización. En lugar de recomendar tecnologías específicas que pronto quedarán obsoletas en la vertiginosa evolución del big data, el libro se centra en los patrones de implantación, y proporciona ejemplos de tecnologías existentes disponibles tanto in situ como en la nube.

4. Sigue una estrategia escalonada de arrastrarte, andar y correr, centrada en duplicar cada trimestre las métricas preseleccionadas y hacerlas autoservicio.

Por último, el libro intenta aunar las perspectivas tanto de los usuarios de los datos como de los ingenieros de la plataforma de datos. Crear un entendimiento común de los requisitos es fundamental para desarrollar una hoja de ruta pragmática que cruce lo que es posible y lo que es factible teniendo en cuenta el plazo y los recursos disponibles.

¡Preparados! ¡Preparados! ¡Adelante!