Capítulo 1. Modernizar tu plataforma de datos: Una visión general introductoria

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

Los datos son un activo valioso que puede ayudar a tu empresa a tomar mejores decisiones, identificar nuevas oportunidades y mejorar las operaciones. Google emprendió en 2013 un proyecto estratégico para aumentar la retención de empleados mejorando la calidad de los directivos. Incluso algo tan vago como la habilidad de los directivos podía estudiarse con datos en. Google pudo mejorar la favorabilidad de los directivos del 83% al 88% analizando 10.000 revisiones de rendimiento, identificando los comportamientos comunes de los directivos de alto rendimiento y creando programas de formación. Otro ejemplo de proyecto estratégico de datos se llevó a cabo en Amazon. El gigante del comercio electrónico implantó un sistema de recomendaciones basado en los comportamientos de los clientes que impulsó el 35% de las compras en 2017. Los Warriors, un equipo de baloncesto de San Francisco, es otro ejemplo; pusieron en marcha un programa de análisis que les ayudó a catapultarse a la cima de su liga. Todos ellos -retención de empleados, recomendaciones de productos, mejora de los porcentajes de victorias- son ejemplos de objetivos empresariales alcanzados gracias a la analítica de datos moderna.

Para convertirte en una empresa basada en datos, necesitas construir un ecosistema para el análisis, el procesamiento y la comprensión de los datos. Esto se debe a que hay muchos tipos diferentes de aplicaciones (sitios web, cuadros de mando, aplicaciones móviles, modelos ML, dispositivos distribuidos, etc.) que crean y consumen datos. También hay muchos departamentos diferentes dentro de tu empresa (finanzas, ventas, marketing, operaciones, logística, etc.) que necesitan información basada en datos. Dado que toda la empresa es tu base de clientes, crear una plataforma de datos es algo más que un proyecto informático.

Este capítulo presenta las plataformas de datos, sus requisitos y por qué las arquitecturas de datos tradicionales resultan insuficientes. También analiza las tendencias tecnológicas en el análisis de datos y la IA, y cómo construir plataformas de datos para el futuro utilizando la nube pública. Este capítulo es una visión general de los temas centrales que se tratan con más detalle en el resto del libro.

El ciclo de vida de los datos

El propósito de una plataforma de datos es apoyar los pasos que las organizaciones necesitan llevar a cabo para pasar de los datos brutos a la información perspicaz. Resulta útil comprender los pasos del ciclo de vida de los datos (recopilar, almacenar, procesar, visualizar, activar) porque pueden mapearse casi tal cual en una arquitectura de datos para crear una plataforma analítica unificada.

El Viaje a la Sabiduría

Los datos ayudan a las empresas a desarrollar productos más inteligentes, llegar a más clientes y aumentar el rendimiento de la inversión (ROI). Los datos también pueden aprovecharse para medir la satisfacción del cliente, la rentabilidad y el coste. Pero los datos por sí solos no bastan. Los datos son materia prima que debe pasar por una serie de etapas antes de poder utilizarse para generar ideas y conocimientos. Esta secuencia de etapas es lo que llamamos ciclo de vida de los datos. Hay muchas definiciones disponibles en la literatura, pero desde un punto de vista general, podemos identificar cinco etapas principales en la arquitectura moderna de las plataformas de datos:

1. Recoge: Los datos tienen que ser adquiridos e inyectados en los sistemas de destino (por ejemplo, entrada manual de datos, carga por lotes, ingestión en streaming, etc.).
2. Almacena: Los datos deben persistir de forma duradera, con la posibilidad de acceder a ellos fácilmente en el futuro (por ejemplo, sistema de almacenamiento de archivos, base de datos).
3. Proceso/transformación: Hay que manipular los datos para que sean útiles en los pasos posteriores (por ejemplo, depuración, manipulación, transformación).
4. Analizar/visualizar: Hay que estudiar los datos para obtener información empresarial mediante elaboración manual (por ejemplo, consultas, slice and dice) o procesamiento automático (por ejemplo, enriquecimiento mediante interfaces de programación de aplicaciones-API de ML).
5. Activa: Hacer aflorar las percepciones de los datos de una forma y en un lugar donde se puedan tomar decisiones (por ejemplo, notificaciones que actúen como desencadenantes de acciones manuales específicas, ejecuciones automáticas de trabajos cuando se cumplan determinadas condiciones, modelos ML que envíen información a los dispositivos).

Cada una de estas etapas alimenta a la siguiente, de forma similar al flujo de agua a través de un conjunto de tuberías.

Analogía de las tuberías de agua

Para entender mejor el ciclo de vida de los datos, piensa en él como en un sistema simplificado de tuberías de agua. El agua comienza en un acueducto y luego se transfiere y transforma a través de una serie de tuberías hasta que llega a un grupo de casas. El ciclo de vida de los datos es similar: los datos se recogen, almacenan, procesan/transforman y analizan antes de utilizarse para tomar decisiones (ver Figura 1-1).

Water lifecycle, providing an analogy for the five steps in the data lifecycle

Puedes ver algunas similitudes entre el mundo de la fontanería y el de los datos. Los ingenieros de fontanería son como los ingenieros de datos, que diseñan y construyen los sistemas que hacen que los datos sean utilizables. Las personas que analizan muestras de agua son como los analistas de datos y los científicos de datos, que analizan los datos para encontrar ideas. Por supuesto, esto es sólo una simplificación. Hay muchas otras funciones en una empresa que utilizan datos, como ejecutivos, desarrolladores, usuarios empresariales y administradores de seguridad. Pero esta analogía puede ayudarte a recordar los conceptos principales.

En el ciclo de vida canónico de los datos, que se muestra en la Figura 1-2, los ingenieros de datos recopilan y almacenan los datos en un almacén analítico. A continuación, los datos almacenados se procesan mediante diversas herramientas. Si las herramientas implican programación, el procesamiento lo realizan normalmente los ingenieros de datos. Si las herramientas son declarativas, el procesamiento lo realizan normalmente los analistas de datos. A continuación, los usuarios empresariales y los científicos de datos analizan los datos procesados. Los usuarios empresariales utilizan los datos para tomar decisiones, como lanzar campañas de marketing o emitir reembolsos. Los científicos de datos utilizan los datos para entrenar modelos de ML, que pueden utilizarse para automatizar tareas o hacer predicciones.

El mundo real puede diferir de la anterior descripción idealizada de cómo deben funcionar la arquitectura y las funciones de una plataforma de datos moderna. Las etapas pueden combinarse (por ejemplo, almacenamiento y procesamiento) o reordenarse (por ejemplo, procesamiento antes que almacenamiento, como en ETL [extraer-transformar-cargar], en lugar de almacenamiento antes que procesamiento, como en ELT [extraer-cargar-transformar]). Sin embargo, estas variaciones tienen sus contrapartidas. Por ejemplo, combinar el almacenamiento y el procesamiento en una sola etapa provoca un acoplamiento que se traduce en un desperdicio de recursos (si el tamaño de los datos aumenta, tendrás que escalar tanto el almacenamiento como el cálculo) y problemas de escalabilidad (si tu infraestructura no puede soportar la carga adicional, estarás atascado).

Ahora que hemos definido el ciclo de vida de los datos y resumido las distintas etapas del viaje de los datos, desde la recogida de datos brutos hasta la activación, repasemos sucesivamente cada una de las cinco etapas del ciclo de vida de los datos.

Recoge

El primer paso en el proceso de diseño es la ingestión . La ingestión es el proceso de transferir datos desde una fuente, que puede estar en cualquier parte (en las instalaciones, en dispositivos, en otra nube, etc.), a un sistema de destino donde se pueden almacenar para su posterior análisis. Esta es la primera oportunidad para considerar las 3V de los grandes datos de:

Volumen: ¿Cuál es el tamaño de los datos? Normalmente, cuando se trata de big data, esto significa terabyte (TB) o petabyte (PB) de datos.
Velocidad: ¿Cuál es la velocidad de los datos que entran? Generalmente se trata de megabytes/segundo (MB/s) o TB/día. A menudo se denomina rendimiento.
Variedad: ¿Cuál es el formato de los datos? Tablas, archivos planos, imágenes, sonido, texto, etc.

Identifica el tipo de datos (estructurados, semiestructurados, no estructurados), el formato y la frecuencia de generación (continua o a intervalos específicos) de los datos que se van a recopilar. En función de la velocidad de los datos y de la capacidad de la plataforma de datos para manejar el volumen y la variedad resultantes, elige entre la ingesta por lotes, la ingesta en streaming, o un híbrido de ambas.

Como distintas partes de la organización pueden estar interesadas en distintas fuentes de datos, diseña esta etapa para que sea lo más flexible posible. Hay varias soluciones comerciales y de código abierto que pueden utilizarse, cada una especializada para un tipo de datos/enfoque específico de los mencionados anteriormente. Tu plataforma de datos tendrá que ser exhaustiva y admitir toda la gama de volumen, velocidad y variedad necesaria para todos los datos que haya que ingerir en la plataforma. Podrías tener herramientas sencillas que transfieran archivos entre servidores de Protocolo de Transferencia de Archivos (FTP) a intervalos regulares, o podrías tener sistemas complejos, incluso distribuidos geográficamente, que recopilen datos de dispositivos IoT en tiempo real.

Tienda

En este paso, almacena en los datos brutos que recogiste en el paso anterior. No modificas los datos en absoluto, sólo los almacenas. Esto es importante porque es posible que más adelante quieras volver a procesar los datos de otra forma, y para ello necesitas disponer de los datos originales.

Los datos tienen muchas formas y tamaños diferentes. La forma de almacenarlos dependerá de tus necesidades técnicas y comerciales. Algunas opciones habituales son los sistemas de almacenamiento de objetos, los sistemas de gestión de bases de datos relacionales (RDBMS), los almacenes de datos (DWH) y los lagos de datos. Tu elección dependerá en cierta medida de si el hardware, el software y los artefactos subyacentes son capaces de hacer frente a los requisitos de escalabilidad, coste, disponibilidad, durabilidad y apertura impuestos por tus casos de uso deseados.

Escalabilidad

Escalabilidad es la capacidad de crecer y gestionar el aumento de la demanda de forma capaz. Hay dos formas principales de lograr la escalabilidad:

Escalabilidad vertical: Esto implica añadir unidades de expansión adicionales al mismo nodo para aumentar la capacidad del sistema de almacenamiento.
Escalabilidad horizontal: Esto implica añadir uno o más nodos adicionales en lugar de añadir nuevas unidades de expansión a un único nodo. Este tipo de almacenamiento distribuido es más complejo de gestionar, pero puede conseguir un mayor rendimiento y eficacia.

Es sumamente importante que el sistema subyacente sea capaz de hacer frente al volumen y la velocidad que exigen las soluciones modernas, que tienen que trabajar en un entorno en el que los datos están explotando y su naturaleza está pasando del procesamiento por lotes al tiempo real: vivimos en un mundo en el que la mayoría de las personas generan y requieren continuamente acceso a la información aprovechando sus dispositivos inteligentes; las organizaciones tienen que ser capaces de proporcionar a sus usuarios (tanto internos como externos) soluciones capaces de dar respuestas en tiempo real a las distintas peticiones.

Rendimiento frente a coste

Identifica en los distintos tipos de datos que necesitas gestionar, y crea una jerarquía basada en la importancia empresarial de los datos, la frecuencia con que se accederá a ellos y el tipo de latencia que esperarán los usuarios de los datos.

Almacena los datos más importantes y a los que se accede con más frecuencia (datos calientes ) en un sistema de almacenamiento de alto rendimiento, como el almacenamiento nativo de un almacén de datos. Almacena los datos menos importantes (datos fríos ) en un sistema de almacenamiento menos caro, como el almacenamiento en la nube (que a su vez tiene varios niveles). Si necesitas un rendimiento aún mayor, como en los casos de uso interactivo, puedes utilizar técnicas de almacenamiento en caché para cargar una parte significativa de tus datos calientes en un nivel de almacenamiento volátil.

Alta disponibilidad

Alta disponibilidad significa tener la capacidad de estar operativo y proporcionar acceso a los datos cuando se solicite. Esto se consigue normalmente mediante redundancia de hardware para hacer frente a posibles fallos/interrupciones físicas. Esto se consigue en la nube almacenando los datos en al menos tres zonas de disponibilidad. Las zonas pueden no estar separadas físicamente (es decir, pueden estar en el mismo "campus"), pero tenderán a tener diferentes fuentes de alimentación, etc. La redundancia de hardware suele denominarse tiempo de actividad del sistema , y los sistemas modernos suelen venir con cuatro 9s o más.

Durabilidad

Durabilidad es la capacidad de almacenar datos durante un periodo prolongado sin que sufran degradación, corrupción o pérdida total. Esto se consigue normalmente almacenando múltiples copias de los datos en ubicaciones físicamente separadas. Esta redundancia de datos se implementa en la nube almacenando los datos en al menos dos regiones (por ejemplo, tanto en Londres como en Frankfurt). Esto es extremadamente importante cuando se trata de operaciones de restauración de datos ante catástrofes naturales: si el sistema de almacenamiento subyacente tiene una alta durabilidad (los sistemas modernos suelen venir con 11 9s), entonces todos los datos pueden restaurarse sin problemas, a menos que un cataclismo derribe incluso los centros de datos separados físicamente.

Apertura

En la medida de lo posible, utiliza formatos que no sean propietarios y que no generen lock-in. Idealmente, debería ser posible consultar los datos con una selección de motores de procesamiento sin generar copias de los datos ni tener que trasladarlos de un sistema a otro. Dicho esto, es aceptable utilizar sistemas que utilicen un formato de almacenamiento propietario o nativo, siempre que ofrezcan una capacidad de exportación sencilla.

Como ocurre con la mayoría de las decisiones tecnológicas, la apertura es un compromiso, y el ROI de una tecnología propietaria puede ser lo suficientemente alto como para que estés dispuesto a pagar el precio del bloqueo. Al fin y al cabo, una de las razones para pasar a la nube es reducir los costes operativos: estas ventajas de coste tienden a ser mayores en los sistemas totalmente gestionados/sin servidor que en los sistemas gestionados de código abierto. Por ejemplo, si tu caso de uso de datos requiere transacciones, Databricks (que utiliza un formato de almacenamiento casi abierto basado en Parquet llamado Delta Lake) podría implicar menores costes operativos que Amazon EMR o Google Dataproc (que almacenarán los datos en Parquet estándar en S3 o Google Cloud Storage [GCS] respectivamente)-las transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) que Databricks proporciona en Delta Lake serán caras de implementar y mantener en EMR o Dataproc. Si alguna vez necesitas migrar fuera de Databricks, exporta los datos a Parquet estándar. La apertura, per se, no es una razón para rechazar una tecnología que encaja mejor .

Proceso/Transformación

Aquí es donde ocurre la magia: los datos brutos se transforman en información útil para su posterior análisis. Esta es la etapa en la que los ingenieros de datos construyen canalizaciones de datos para hacer que los datos sean accesibles a un público más amplio de usuarios no técnicos de forma significativa. Esta etapa consiste en actividades que preparan los datos para su análisis y uso. La integración de datos implica combinar datos de múltiples fuentes en una única vista. La limpieza de datos puede ser necesaria para eliminar duplicados y errores de los datos. De forma más general, se llevan a cabo la manipulación, el procesamiento y la transformación de los datos para organizarlos en un formato estándar.

Hay varios marcos que se pueden utilizar, cada uno con sus propias capacidades que dependen del método de almacenamiento que hayas seleccionado en el paso anterior. En general, los motores que te permiten consultar y transformar tus datos utilizando comandos SQL puros (por ejemplo, AWS Athena, Google BigQuery, Azure DWH y Snowflake) son los más eficientes, rentables¹ y fáciles de usar. Sin embargo, las capacidades que ofrecen son limitadas en comparación con los motores basados en lenguajes de programación modernos, normalmente Java, Scala o Python (por ejemplo, Apache Spark, Apache Flink o Apache Beam que se ejecutan en Amazon EMR, Google Cloud Dataproc/Dataflow, Azure HDInsight y Databricks). Los motores de procesamiento de datos basados en código te permiten no sólo implementar transformaciones más complejas y ML por lotes y en tiempo real, sino también aprovechar otras características importantes, como pruebas unitarias y de integración adecuadas.

Otra consideración a la hora de elegir un motor adecuado es que los conocimientos de SQL suelen ser mucho más frecuentes en una organización que los de programación. Cuanto más cultura de datos quieras crear en tu organización, más deberías inclinarte por SQL para el procesamiento de datos. Esto es especialmente importante si los pasos del procesamiento (como la limpieza o la transformación de datos) requieren conocimientos del dominio.

Esta etapa también puede emplear soluciones de virtualización de datos que abstraen múltiples fuentes de datos, y la lógica relacionada para gestionarlas, con el fin de poner la información directamente a disposición de los usuarios finales para su análisis. No hablaremos más de la virtualización en este libro, ya que tiende a ser una solución provisional en el camino hacia la construcción de una plataforma totalmente flexible. Para más información sobre la virtualización de datos, sugerimos el Capítulo 10 del libro The Self-Service Data Roadmap de Sandeep Uttamchandani (O'Reilly).

Analizar/Visualizar

Una vez que llegas a esta fase, los datos empiezan por fin a tener valor en sí mismos: puedes considerarlos información. Los usuarios pueden aprovechar multitud de herramientas para bucear en el contenido de los datos y extraer ideas útiles, identificar tendencias actuales y predecir nuevos resultados. En esta fase, las herramientas y técnicas de visualización que permiten a los usuarios representar la información y los datos de forma gráfica (por ejemplo, tablas, gráficos, mapas, mapas de calor, etc.) desempeñan un papel importante porque proporcionan una forma fácil de descubrir y evaluar tendencias, valores atípicos, pautas y comportamientos.

Visualización y análisis de datos pueden ser realizados por varios tipos de usuarios. Por un lado, están las personas interesadas en comprender los datos empresariales y que quieren aprovechar las herramientas gráficas para realizar análisis comunes, como los roll-ups y los análisis hipotéticos. Por otro lado, puede haber usuarios más avanzados ("usuarios avanzados") que quieran aprovechar la potencia de un lenguaje de consulta como SQL para ejecutar análisis más finos y personalizados. Además, puede haber científicos de datos que puedan aprovechar las técnicas de ML para aplicar nuevas formas de extraer ideas significativas de los datos, descubrir patrones y correlaciones, mejorar la comprensión y la orientación de los clientes y, en última instancia, aumentar los ingresos, el crecimiento y la posición en el mercado de una empresa.

Activa

Este es el paso en el que los usuarios finales son capaces de tomar decisiones basadas en el análisis de datos y las predicciones ML, permitiendo así un proceso de toma de decisiones sobre los datos. A partir de las percepciones extraídas o predichas del conjunto de información disponible, es el momento de emprender algunas acciones.

Las acciones que se pueden llevar a cabo se dividen en tres categorías:

Acciones automáticas: Los sistemas automatizados de pueden utilizar los resultados de un sistema de recomendación para ofrecer recomendaciones personalizadas a los clientes. Esto puede ayudar a los beneficios de la empresa aumentando las ventas.
Integraciones SaaS: Acciones pueden realizarse mediante la integración con servicios de terceros. Por ejemplo, una empresa podría poner en marcha una campaña de marketing para intentar reducir la fuga de clientes. Podrían analizar los datos y aplicar un modelo de propensión para identificar a los clientes que probablemente respondan positivamente a una nueva oferta comercial. A continuación, la lista de direcciones de correo electrónico de los clientes puede enviarse automáticamente a una herramienta de marketing para activar la campaña.
Alerta: Puedes crear aplicaciones que monitoricen los datos en tiempo real y envíen mensajes personalizados cuando se cumplan determinadas condiciones. Por ejemplo, el equipo de precios puede recibir notificaciones proactivas cuando el tráfico a una página de listado de artículos supere un determinado umbral, lo que les permitirá comprobar si el artículo tiene el precio correcto.

La pila tecnológica para estos tres escenarios es diferente. Para las acciones automáticas, el "entrenamiento" del modelo ML se lleva a cabo periódicamente, normalmente programando una canalización ML de extremo a extremo (esto se tratará en el Capítulo 11). Las predicciones propiamente dichas se consiguen invocando el modelo ML desplegado como servicio web mediante herramientas como AWS SageMaker, Google Cloud Vertex AI o Azure Machine Learning. Las integraciones SaaS a menudo se llevan a cabo en el contexto de herramientas de flujo de trabajo de funciones específicas que permiten a un humano controlar qué información se recupera, cómo se transforma y la forma en que se activa. Además, el uso de grandes modelos de lenguaje (LLM) y sus capacidades generativas (profundizaremos más en esos conceptos en el Capítulo 10) puede ayudar a automatizar tareas repetitivas mediante una estrecha integración con los sistemas centrales. Las alertas se implementan mediante herramientas de orquestación como Apache Airflow, sistemas de eventos como Google Eventarc, o funciones sin servidor como AWS Lambda.

En esta sección, hemos visto las actividades que debe soportar una plataforma de datos moderna. A continuación, vamos a examinar los enfoques tradicionales en la implantación de plataformas analíticas y de IA para comprender mejor cómo ha evolucionado la tecnología y por qué el enfoque en la nube puede marcar una gran diferencia.

Limitaciones de los enfoques tradicionales

Tradicionalmente, los ecosistemas de datos de las organizaciones consisten en soluciones independientes que se utilizan para proporcionar distintos servicios de datos. Por desgracia, estos almacenes de datos específicos para cada tarea, que a veces pueden alcanzar un tamaño importante, pueden llevar a la creación de silos dentro de una organización. Los sistemas en silos resultantes funcionan como soluciones independientes que no trabajan juntas de forma eficiente. Los datos silenciados son datos silenciados:son datos de los que es difícil extraer ideas. Para ampliar y unificar la inteligencia empresarial, es fundamental compartir los datos de forma segura entre las unidades de negocio.

Si la mayoría de las soluciones se crean a medida, resulta difícil gestionar la escalabilidad, la continuidad empresarial y la recuperación ante desastres (DR). Si cada parte de la organización elige un entorno diferente para construir su solución, la complejidad se vuelve abrumadora. En un escenario así, es difícil garantizar la privacidad o auditar los cambios en los datos.

Una solución es desarrollar una plataforma de datos unificada y, más concretamente, una plataforma de datos en la nube (ten en cuenta que unificada no implica necesariamente centralizada, como se verá en breve). El propósito de la plataforma de datos es permitir que el análisis y el ML se lleven a cabo sobre todos los datos de una organización de forma coherente, escalable y fiable. Para ello, debes aprovechar, en la medida de lo posible, los servicios gestionados, de modo que la organización pueda centrarse en las necesidades empresariales en lugar de en el funcionamiento de la infraestructura. Las operaciones y el mantenimiento de la infraestructura deben delegarse totalmente en la plataforma en nube subyacente. En este libro, trataremos las decisiones fundamentales que debes tomar al desarrollar una plataforma unificada para consolidar los datos de todas las unidades de negocio en un entorno escalable y fiable.

Antipatrón: Romper silos mediante ETL

Es un reto para las organizaciones tener una visión unificada de sus datos, porque suelen tener multitud de soluciones para gestionarlos. Las organizaciones suelen resolver este problema utilizando herramientas de movimiento de datos. Las aplicaciones ETL permiten transformar y transferir datos entre distintos sistemas para crear una única fuente de verdad. Sin embargo, depender de ETL es problemático, y hay mejores soluciones disponibles en las plataformas modernas.

A menudo, se crea una herramienta ETL para extraer periódicamente las transacciones más recientes de una base de datos transaccional y almacenarlas en un almacén analítico al que puedan acceder los cuadros de mando. A continuación, esto se estandariza. Las herramientas ETL se crean para cada tabla de la base de datos necesaria para el análisis, de modo que éste pueda realizarse sin tener que ir cada vez al sistema fuente (ver Figura 1-3).

ETL tools can help break down data silos

El almacén central de análisis que recoge todos los datos de la organización se denomina DWH o lago de datos, según la tecnología utilizada. Una distinción de alto nivel entre los dos enfoques se basa en la forma en que se almacenan los datos en el sistema: si el almacén de análisis admite SQL y contiene datos gobernados y de calidad controlada, se denomina DWH. Si, por el contrario, admite herramientas del ecosistema Apache (como Apache Spark) y contiene datos sin procesar, se denomina lago de datos. La terminología para referirse a los almacenes de análisis intermedios (como los datos brutos gobernados o los datos de calidad controlada no gobernados) varía de una organización a otra: algunas organizaciones los llaman lagos de datos y otras DWH. Como verás más adelante en el libro, este vocabulario confuso no es un problema porque los enfoques de lago de datos(Capítulo 5) y DWH(Capítulo 6) están convergiendo en lo que se conoce como data lakehouse(Capítulo 7).

Confiar en las herramientas de movimiento de datos para intentar construir una visión coherente de los datos tiene algunos inconvenientes:

Calidad de los datos: Las herramientas ETL suelen estar escritas por consumidores de los datos que tienden a no entenderlos tan bien como los propietarios de los datos. Esto significa que, muy a menudo, los datos que se extraen no son los correctos.
Latencia: Las herramientas ETL introducen latencia. Por ejemplo, si la herramienta ETL para extraer transacciones recientes se ejecuta una vez cada hora y tarda 15 minutos en ejecutarse, los datos del almacén de análisis podrían estar obsoletos hasta 75 minutos. Este problema puede abordarse mediante ETL de flujo, en el que los eventos se procesan a medida que se producen.
Cuello de botella: Las herramientas ETL suelen implicar conocimientos de programación. Por ello, las organizaciones crean equipos de ingeniería de datos a medida para escribir el código de ETL. A medida que aumenta la diversidad de datos en una organización, es necesario escribir un número cada vez mayor de herramientas ETL. El equipo de ingeniería de datos se convierte en un cuello de botella en la capacidad de la organización para aprovechar los datos.
Mantenimiento: Las herramientas ETL deben ser ejecutadas rutinariamente y los administradores del sistema deben solucionar los problemas. El sistema de infraestructura subyacente debe actualizarse continuamente para hacer frente al aumento de la capacidad de cálculo y almacenamiento y garantizar la fiabilidad.
Gestión del cambio: Los cambios en el esquema de la tabla de entrada obligan a cambiar el código de extracción de la herramienta ETL. Esto dificulta los cambios o hace que la herramienta ETL se rompa por los cambios anteriores.
Lagunas en los datos: Es muy probable que muchos errores tengan que escalarse a los propietarios de los datos, a los creadores de la herramienta ETL o a los usuarios de los datos. Esto aumenta la sobrecarga de mantenimiento y, muy a menudo, el tiempo de inactividad de la herramienta. Por ello, con bastante frecuencia hay grandes lagunas en el registro de datos.
Gobernanza: A medida que proliferan los procesos ETL, es cada vez más probable que el mismo procesamiento lo lleven a cabo distintos procesos, lo que da lugar a múltiples fuentes de la misma información. Es habitual que los procesos diverjan con el tiempo para satisfacer distintas necesidades, lo que lleva a que se utilicen datos incoherentes para distintas decisiones.
Eficacia e impacto medioambiental: La infraestructura subyacente que soporta este tipo de transformaciones es motivo de preocupación, ya que suele funcionar 24 horas al día, 7 días a la semana, incurriendo en costes significativos y aumentando el impacto de la huella de carbono.

El primer punto de la lista anterior (calidad de los datos) suele pasarse por alto, pero tiende a ser el más importante con el tiempo. A menudo es necesario preprocesar los datos antes de que se pueda "confiar" en ellos para ponerlos a disposición en producción. Los datos procedentes de sistemas ascendentes suelen considerarse brutos, y pueden contener ruido o incluso mala información si no se limpian y transforman adecuadamente. Por ejemplo, puede ser necesario transformar los registros web de comercio electrónico antes de utilizarlos, por ejemplo extrayendo los códigos de producto de las URL o filtrando las transacciones falsas realizadas por bots. Las herramientas de procesamiento de datos deben construirse específicamente para la tarea en cuestión. No existe una solución global de calidad de datos ni un marco común para tratar los problemas de calidad.

Aunque esta situación es razonable cuando se considera una fuente de datos cada vez, la recopilación total (ver Figura 1-4) conduce al caos.

La proliferación de sistemas de almacenamiento, junto con las soluciones de gestión de datos hechas a medida y desarrolladas para satisfacer los deseos de las distintas aplicaciones posteriores, provocan una situación en la que los líderes analíticos y los directores de información (CIO) se enfrentan a los siguientes retos:

Su DWH/lago de datos es incapaz de seguir el ritmo de las crecientes necesidades empresariales.
Cada vez más, las iniciativas digitales (y la competencia con los nativos digitales) han transformado el negocio en uno en el que enormes volúmenes de datos inundan el sistema.
La necesidad de crear lagos de datos, DWH y almacenamientos especiales separados para las distintas tareas de la ciencia de datos acaba creando múltiples silos de datos.
Es necesario limitar o restringir el acceso a los datos debido a problemas de rendimiento, seguridad y gobernanza.
Renovar las licencias y pagar los costosos recursos de soporte se convierte en un reto.

Es evidente que este enfoque no puede ampliarse para satisfacer las nuevas necesidades empresariales, no sólo por la complejidad tecnológica, sino también por los requisitos de seguridad y gobernanza que este modelo conlleva .

Antipatrón: Centralización del control

Para intentar resolver el problema de tener datos en silos, dispersos y distribuidos, gestionados mediante soluciones de procesamiento de datos específicas para cada tarea, algunas organizaciones han intentado centralizar todo en una única plataforma monolítica bajo el control del departamento de TI. Como se muestra en la Figura 1-5, la solución tecnológica subyacente no cambia, sino que los problemas se hacen más manejables asignándolos a una única organización para que los resuelva.

Data ecosystem and challenges with IT centrally controlling data systems

Este control centralizado por parte de un único departamento conlleva sus propios retos y compensaciones. Todas las unidades de negocio (BU) -la propia TI, el análisis de datos y los usuarios empresariales- tienen dificultades cuando TI controla todos los sistemas de datos:

TI: El reto al que se enfrentan los departamentos de TI es el diverso conjunto de tecnologías implicadas en estos silos de datos. Los departamentos de TI rara vez disponen de las competencias necesarias para gestionar todos estos sistemas. Los datos se encuentran en múltiples sistemas de almacenamiento en las instalaciones y en nubes, lo que hace costosa la gestión de los DWH, los lagos de datos y los data marts. Además, no siempre está claro cómo definir la seguridad, la gobernanza, la auditoría, etc., en las distintas fuentes. Además, introduce un problema de escalabilidad a la hora de acceder a los datos: la cantidad de trabajo que debe realizar el departamento de TI aumenta linealmente con el número de sistemas de origen y destino que formarán parte de la imagen, porque seguramente aumentará el número de solicitudes de acceso a los datos por parte de todas las partes interesadas/usuarios empresariales relacionados.
Analítica: Uno de los principales problemas que obstaculizan los procesos analíticos eficaces es no tener acceso a los datos adecuados. Cuando existen varios sistemas, trasladar datos a/desde un sistema de datos monolítico resulta costoso, lo que da lugar a tareas ETL innecesarias, etc. Además, los datos preparados y fácilmente disponibles pueden no tener las fuentes más recientes, o puede haber otras versiones de los datos que proporcionen más profundidad e información más amplia, como tener más columnas o disponer de registros más granulares. Es imposible dar rienda suelta a tu equipo de análisis para que todo el mundo pueda acceder a todos los datos, debido a la gobernanza de los datos y a cuestiones operativas. A menudo, las organizaciones acaban limitando el acceso a los datos a expensas de la agilidad analítica.
Empresa: Obtener acceso a datos y análisis en los que tu empresa pueda confiar es difícil. Hay problemas a la hora de limitar los datos que das a la empresa para garantizar la máxima calidad. La alternativa es abrir el acceso a todos los datos que necesiten los usuarios de la empresa, aunque eso signifique sacrificar la calidad. El reto se convierte entonces en un acto de equilibrio entre la calidad de los datos y la cantidad de datos de confianza facilitados. A menudo ocurre que TI no tiene suficientes representantes empresariales cualificados para dirigir las prioridades y los requisitos. Esto puede convertirse rápidamente en un cuello de botella que ralentice el proceso de innovación dentro de la organización.

A pesar de tantos retos, varias organizaciones adoptaron este enfoque a lo largo de los años, creando, en algunos casos, frustraciones y tensiones para los usuarios empresariales que veían retrasado el acceso a los datos que necesitaban para cumplir sus tareas. Las unidades empresariales frustradas suelen arreglárselas mediante otro antipatrón-es decir, la TI en la sombra- en el quedepartamentos enteros desarrollan e implementan soluciones útiles para sortear tales limitaciones, pero acaban empeorando el problema de los datos en silos.

A veces se emplea un enfoque técnico denominadotejido de datos . Éste sigue basándose en la centralización, pero en lugar de trasladar físicamente los datos, el tejido de datos es una capa virtual para proporcionar un acceso unificado a los datos. El problema es que esta estandarización puede ser una pesada carga e introducir retrasos en el acceso a los datos en toda la organización. El tejido de datos es, sin embargo, un enfoque viable para los productos SaaS que intentan acceder a los datos propietarios de los clientes: los especialistas en integración proporcionan la traducción necesaria del esquema de los clientes al esquema esperado por la herramienta SaaS.

Antipatrón: Data Marts y Hadoop

Los retos en torno a un sistema centralizado y gestionado en silos crearon una enorme tensión y sobrecarga para TI. Para resolverlo, algunas empresas adoptaron otros dos antipatrones: los data marts y los data lakes no gestionados.

En el primer enfoque, los datos se extraían a bases de datos relacionales y analíticas locales. Sin embargo, a pesar de llamarse almacenes de datos, estos productos eran, en la práctica, marts de datos (un subconjunto de datos empresariales adaptados a cargas de trabajo específicas) debido a limitaciones de escalabilidad. Los data marts permiten a los usuarios empresariales diseñar e implementar sus propios datos empresariales en modelos de datos estructurados (por ejemplo, en el comercio minorista, la sanidad, la banca, los seguros, etc.). Esto les permite obtener fácilmente información sobre el negocio actual y el histórico (por ejemplo, la cantidad de ingresos del último trimestre, el número de usuarios que jugaron a tu último juego publicado en la última semana, la correlación entre el tiempo pasado en el centro de ayuda de tu sitio web y el número de tickets recibidos en los últimos seis meses, etc.). Durante muchas décadas, las organizaciones han desarrollado soluciones de mercado de datos utilizando diversas tecnologías (por ejemplo, Oracle, Teradata, Vertica) e implantando múltiples aplicaciones sobre ellas. Sin embargo, estas tecnologías locales están muy limitadas en cuanto a capacidad. Los equipos de TI y las partes interesadas en los datos se enfrentan a los retos de escalar la infraestructura (verticalmente), encontrar talentos críticos, reducir costes y, en última instancia, satisfacer la creciente expectativa de ofrecer perspectivas valiosas. Además, estas soluciones solían ser costosas porque, a medida que aumentaba el tamaño de los datos, necesitabas un sistema con más capacidad de cálculo para procesarlos.

Debido a problemas de escalabilidad y coste, se crearon soluciones de big data basadas en el ecosistema Apache Hadoop. Hadoop introdujo el procesamiento distribuido de datos (escalado horizontal) utilizando servidores básicos de bajo coste, permitiendo casos de uso que antes sólo eran posibles con hardware especializado de gama alta (y muy costoso). Todas las aplicaciones que se ejecutaban sobre Hadoop estaban diseñadas para tolerar fallos en los nodos, lo que las convertía en una alternativa rentable a algunas cargas de trabajo DWH tradicionales. Esto llevó al desarrollo de un nuevo concepto llamado lago de datos, que rápidamente se convirtió en un pilar básico de la gestión de datos junto al DWH.

La idea era que, mientras las principales divisiones de tecnología operativa seguían con sus tareas rutinarias, todos los datos se exportaban para su análisis a un lago de datos centralizado. La intención era que el lago de datos sirviera de repositorio central para las cargas de trabajo analíticas y para los usuarios empresariales. Los lagos de datos han pasado de ser meras instalaciones de almacenamiento de datos en bruto a plataformas que permiten la analítica avanzada y la ciencia de datos sobre grandes volúmenes de datos. Esto permitió la analítica de autoservicio en toda la organización, pero requirió un amplio conocimiento práctico de Hadoop avanzado y procesos de ingeniería para acceder a los datos. El ecosistema Hadoop Open Source Software (Hadoop OSS) creció en cuanto a sistemas de datos y marcos de procesamiento (HBase, Hive, Spark, Pig, Presto, SparkML y otros) en paralelo al crecimiento exponencial de los datos de las organizaciones, pero esto conllevó una complejidad y un coste de mantenimiento adicionales. Además, los lagos de datos se convirtieron en un caos desordenado de datos que pocos usuarios potenciales de los mismos podían comprender. La combinación de la falta de competencias y los problemas de calidad de los datos hizo que las empresas tuvieran dificultades para obtener un buen ROI de los lagos de datos en sus instalaciones.

Ahora que has visto varios antipatrones, centrémonos en cómo podrías diseñar una plataforma de datos que proporcione una visión unificada de los datos a lo largo de todo su ciclo de vida .

Crear una plataforma analítica unificada

Datos Las tecnologías de mart y lago de datos permitieron a TI construir la primera iteración de una plataforma de datos para romper los silos de datos y permitir a la organización obtener información de todos sus activos de datos. La plataforma de datos permitió a los analistas de datos, ingenieros de datos, científicos de datos, usuarios empresariales, arquitectos e ingenieros de seguridad obtener mejores perspectivas en tiempo real y predecir cómo evolucionará su negocio con el tiempo.

Nube en lugar de local

DWH y lagos de datos son el núcleo de las plataformas de datos modernas. Los DWH admiten datos estructurados y SQL, mientras que los lagos de datos admiten datos sin procesar y marcos de programación en el ecosistema Apache.

Sin embargo, ejecutar DWH y lagos de datos en un entorno local tiene algunos retos inherentes, como el escalado y los costes operativos. Esto ha llevado a las organizaciones a reconsiderar su enfoque y a empezar a considerar la nube (especialmente su versión pública) como el entorno preferido para una plataforma de este tipo. ¿Por qué? Porque les permite

Reduce los costes aprovechando los nuevos modelos de precios(modelo de pago por uso)
Acelera la innovación aprovechando las tecnologías más avanzadas
Escala los recursos locales utilizando un enfoque "bursting".
Planifica la continuidad de la actividad y la recuperación ante desastres almacenando los datos en varias zonas y regiones
Gestiona automáticamente la recuperación ante desastres mediante servicios totalmente gestionados

Cuando los usuarios ya no están limitados por la capacidad de su infraestructura, las organizaciones pueden democratizar los datos de en toda su organización y desbloquear perspectivas. La nube ayuda a las organizaciones en sus esfuerzos de modernización, ya que minimiza el trabajo y la fricción al descargar las tareas administrativas de poco valor. Una plataforma de datos en la nube promete un entorno en el que ya no tienes que hacer concesiones y puedes construir un ecosistema de datos integral que cubra las etapas de gestión y procesamiento de datos de principio a fin, desde la recogida hasta el servicio de datos. Y puedes utilizar tu plataforma de datos en la nube para almacenar grandes cantidades de datos en diversos formatos sin comprometer la latencia.

Las plataformas de datos en la nube prometen:

Gobierno y gestión de acceso centralizados
Aumento de la productividad y reducción de los costes operativos
Mayor intercambio de datos en toda la organización
Acceso ampliado por diferentes personas
Reducción de la latencia de acceso a los datos

En el entorno de la nube pública, las líneas divisorias entre las tecnologías DWH y de lago de datos se están difuminando porque la infraestructura de la nube (en concreto, la separación del cálculo y el almacenamiento) permite una convergencia que era imposible en el entorno local. Hoy es posible aplicar SQL a los datos almacenados en un lago de datos, y es posible ejecutar lo que tradicionalmente es una tecnología Hadoop (por ejemplo, Spark) contra los datos almacenados en un DWH . En esta sección te daremos una introducción a cómo funciona esta convergencia y cómo puede ser la base de enfoques totalmente nuevos que pueden revolucionar la forma en que las organizaciones contemplan los datos; obtendrás más detalles en los Capítulos 5 a 7.

Inconvenientes de los Data Marts y los Data Lakes

En los últimos 40 años, los departamentos informáticos han creado DWH específicos de cada dominio, llamados data marts, para ayudar a los analistas de datos. Se han dado cuenta de que esos mercados de datos son difíciles de gestionar y pueden llegar a ser muy costosos. Los sistemas heredados que funcionaron bien en el pasado (como los dispositivos Teradata y Netezza locales) han demostrado ser difíciles de escalar, ser muy caros y plantear una serie de retos relacionados con la frescura de los datos. Además, no pueden proporcionar fácilmente capacidades modernas, como acceso a IA/ML o funciones en tiempo real, sin añadir esa funcionalidad a posteriori.

Los usuarios del mercado de datos suelen ser analistas que están integrados en una unidad de negocio concreta. Pueden tener ideas sobre conjuntos de datos adicionales, análisis, procesamiento de datos y funcionalidades de inteligencia empresarial que serían muy beneficiosas para su trabajo. Sin embargo, en una empresa tradicional, a menudo no tienen acceso directo a los propietarios de los datos, ni pueden influir fácilmente en los responsables técnicos que deciden sobre los conjuntos de datos y las herramientas. Además, al no tener acceso a los datos brutos, no pueden probar hipótesis ni comprender en profundidad los datos subyacentes.

Los lagos de datos no son tan sencillos ni rentables como parecen. Aunque en teoría pueden escalarse fácilmente, las organizaciones suelen enfrentarse a retos a la hora de planificar y aprovisionar almacenamiento suficiente, sobre todo si producen cantidades muy variables de datos. Además, el aprovisionamiento de capacidad computacional para los periodos punta puede resultar caro, lo que lleva a una competencia por los escasos recursos entre las distintas unidades de negocio.

Los lagos de datos locales pueden ser frágiles y requerir un mantenimiento laborioso. Los ingenieros que podrían estar desarrollando nuevas funciones a menudo se ven relegados a mantener los clusters de datos y programar trabajos para las unidades de negocio. El coste total de propiedad suele ser más elevado de lo esperado para muchas empresas. En resumen, los lagos de datos no crean valor, y muchas empresas descubren que el ROI es negativo.

Con los lagos de datos, la gobernanza no se resuelve fácilmente, sobre todo cuando distintas partes de la organización utilizan modelos de seguridad diferentes. Entonces, los lagos de datos se convierten en silos y se segmentan, lo que dificulta compartir datos y modelos entre equipos.

Los usuarios de los lagos de datos suelen estar más cerca de las fuentes de datos brutos y necesitan conocimientos de programación para utilizar las herramientas y capacidades de los lagos de datos, aunque sólo sea para explorar los datos. En las organizaciones tradicionales, estos usuarios tienden a centrarse en los datos en sí y, con frecuencia, se mantienen a distancia del resto de la empresa. Por otra parte, los usuarios empresariales no tienen los conocimientos de programación necesarios para obtener información de los datos de un lago de datos. Esta desconexión significa que las unidades de negocio pierden la oportunidad de obtener perspectivas que impulsarían sus objetivos empresariales hacia mayores ingresos, menores costes, menor riesgo y nuevas oportunidades.

Convergencia de DWHs y Lagos de Datos

Ante estas disyuntivas, muchas empresas acaban adoptando un enfoque mixto, en el que un lago de datos se configura para graduar algunos datos en un DWH o un DWH tiene un lago de datos lateral para pruebas y análisis adicionales. Sin embargo, con múltiples equipos que fabrican sus propias arquitecturas de datos para adaptarse a sus necesidades individuales, la compartición y fidelidad de los datos se complica aún más para un equipo central de TI.

En lugar de tener equipos separados con objetivos separados -en los que uno explora el negocio y otro lo conoce-, puedes unir estas funciones y sus sistemas de datos para crear un círculo virtuoso en el que un conocimiento más profundo del negocio impulse la exploración y esa exploración impulse un mayor conocimiento del negocio.

Partiendo de este principio, la industria de los datos ha empezado a cambiar hacia un nuevo enfoque, el lakehouse y la malla de datos, que funcionan bien juntos porque ayudan a resolver dos retos distintos dentro de una organización:

Lakehouse permite a los usuarios con diferentes habilidades (analistas de datos e ingenieros de datos) acceder a los datos utilizando diferentes tecnologías.
La malla de datos permite a una empresa crear una plataforma de datos unificada sin centralizar todos los datos en TI: de este modo, las distintas unidades de negocio pueden ser propietarias de sus propios datos, pero permitiendo que otras unidades de negocio accedan a ellos de forma eficiente y escalable.

Como ventaja añadida, esta combinación de arquitecturas también aporta una gobernanza de datos más rigurosa, algo de lo que suelen carecer los lagos de datos. La malla de datos permite a las personas evitar el cuello de botella de un equipo y, por tanto, habilita toda la pila de datos. Rompe los silos en unidades organizativas más pequeñas en una arquitectura que proporciona acceso a los datos de forma federada.

Casa del Lago

La arquitectura de lago de datos es una combinación de las principales ventajas de los lagos de datos y los almacenes de datos (véase la Figura 1-6). Ofrece un formato de almacenamiento de bajo coste al que pueden acceder varios motores de procesamiento, como los motores SQL de los almacenes de datos, al tiempo que proporciona potentes funciones de gestión y optimización.

Databricks es partidaria de la arquitectura lakehouse porque se fundó en Spark y necesita dar soporte a usuarios empresariales que no son programadores. Como resultado, los datos de Databricks se almacenan en un lago de datos, pero los usuarios empresariales pueden utilizar SQL para acceder a ellos. Sin embargo, la arquitectura lakehouse no se limita a Databricks.

Los DWH que se ejecutan en soluciones en la nube como Google Cloud BigQuery, Snowflake o Azure Synapse te permiten crear una arquitectura de lago basada en el almacenamiento columnar optimizado para la analítica SQL: te permite tratar el DWH como un lago de datos al permitir también que los trabajos Spark que se ejecutan en entornos Hadoop paralelos aprovechen los datos almacenados en el sistema de almacenamiento subyacente, en lugar de requerir un proceso ETL o una capa de almacenamiento independientes.

El modelo de casa lacustre ofrece varias ventajas sobre los enfoques tradicionales:

Desacoplamiento del almacenamiento y la informática que permiten:
- Almacenamiento barato, prácticamente ilimitado y escalable sin fisuras
- Computación sin estado y resistente
- Operaciones de almacenamiento compatibles con ACID
- Un modelo de almacenamiento de base de datos lógico, en lugar de físico
Gobernanza de datos (por ejemplo, restricción de acceso a datos y evolución de esquemas)
Soporte para el análisis de datos mediante la integración nativa con herramientas de inteligencia empresarial
Soporte nativo del enfoque multiversión típico de un enfoque de lago de datos (es decir, bronce, plata y oro)
Almacenamiento y gestión de datos mediante formatos abiertos como Apache Parquet y Iceberg
Admite distintos tipos de datos en formato estructurado o no estructurado
Capacidades de streaming con capacidad para gestionar el análisis de los datos en tiempo real
Habilitación de un conjunto diverso de aplicaciones que van desde la inteligencia empresarial al ML

Sin embargo, el almacenamiento en la nube es inevitablemente un compromiso tecnológico. El uso de formatos estándar en el almacenamiento en la nube limita las optimizaciones de almacenamiento y la concurrencia de consultas que los DWH han dedicado años a perfeccionar. Por lo tanto, el SQL soportado por las tecnologías lakehouse no es tan eficiente como el de un DWH nativo (es decir, necesitará más recursos y costará más). Además, el soporte SQL tiende a ser limitado, con funciones como consultas geoespaciales, ML y manipulación de datos no disponibles o increíblemente ineficientes. Del mismo modo, el soporte Spark proporcionado por los DWH es limitado y tiende a no ser tan eficaz como el soporte Spark nativo proporcionado por un proveedor de lagos de datos.

El enfoque Lakehouse permite a las organizaciones implantar los pilares básicos de una plataforma de datos increíblemente variada que puede soportar cualquier tipo de carga de trabajo. Pero, ¿qué pasa con las organizaciones que están encima? ¿Cómo pueden los usuarios aprovechar lo mejor de la plataforma para ejecutar sus tareas? En este escenario está tomando forma un nuevo modelo operativo, y es la malla de datos.

Malla de datos

Malla de datos es un modelo operativo descentralizado de tecnología, personas y procesos para resolver el reto más común de la analítica: el deseo de centralización del control en un entorno en el que la propiedad de los datos está necesariamente distribuida, como se muestra en la Figura 1-7. Otra forma de ver la malla de datos es que introduce una forma de ver los datos como un producto autónomo en lugar de un producto de tuberías ETL.

A data mesh unifies data access across the company, while retaining ownership of the data in distributed domains

En este enfoque, los equipos distribuidos son propietarios de la producción de datos y sirven a los consumidores internos/externos mediante esquemas de datos bien definidos. En su conjunto, la malla de datos se basa en una larga historia de innovación de los DWH y los lagos de datos, combinada con la escalabilidad, los modelos de pago por consumo, las API de autoservicio y la estrecha integración asociada a las tecnologías DWH en la nube pública.

Con este enfoque, puedes crear eficazmente una solución de datos a la carta. Una malla de datos descentraliza la propiedad de los datos entre los propietarios de los datos del dominio, cada uno de los cuales es responsable de proporcionar sus datos como producto de una forma estándar (ver Figura 1-8). Una malla de datos también permite la comunicación entre varias partes de la organización para distribuir conjuntos de datos en diferentes ubicaciones.

En una malla de datos, la responsabilidad de generar valor a partir de los datos recae en las personas que mejor los entienden; en otras palabras, las personas que crearon los datos o los introdujeron en la organización también deben ser responsables de crear activos de datos consumibles como productos a partir de los datos que crean. En muchas organizaciones, establecer una "única fuente de verdad" o "fuente de datos autorizada" es complicado debido a la extracción y transformación repetidas de datos en toda la organización, sin responsabilidades claras de propiedad sobre los datos recién creados. En la malla de datos, la fuente autorizada de datos es el producto de datos publicado por el dominio de origen, con un propietario y un administrador de datos claramente asignados que son responsables de esos datos.

Una malla de datos es un principio organizativo sobre la propiedad y la responsabilidad de los datos. Lo más habitual es que una malla de datos se implemente utilizando un "lakehouse", en el que cada unidad de negocio tiene una cuenta en la nube independiente. Tener acceso a esta visión unificada desde una perspectiva tecnológica (lakehouse) y desde una perspectiva organizativa (malla de datos) significa que las personas y los sistemas reciben los datos de la forma más adecuada a sus necesidades. En algunos casos, este tipo de arquitectura tiene que abarcar múltiples entornos, generando, en algunos casos, una arquitectura muy compleja. Veamos cómo pueden gestionar las empresas este reto .

Nota

Para obtener más información sobre la malla de datos, te recomendamos que leas el libro de Zhamak Dehghani Data Mesh: Delivering Data-Driven Value at Scale (O'Reilly).

Nube híbrida

Cuando diseña una plataforma de datos en la nube, puede ocurrir que un único entorno no sea suficiente para gestionar una carga de trabajo de extremo a extremo. Esto puede deberse a restricciones normativas (por ejemplo, no puedes trasladar tus datos a un entorno fuera de los límites de la organización), o al coste (por ejemplo, la organización realizó algunas inversiones en la infraestructura que no llegaron al final de su vida útil), o porque necesitas una tecnología específica que no está disponible en la nube. En este caso, un posible enfoque es adoptar un patrón híbrido. Un patrón híbrido es aquel en el que las aplicaciones se ejecutan en una combinación de varios entornos. El ejemplo más común de patrón híbrido es combinar un entorno informático privado, como un centro de datos local, y un entorno informático de nube pública. En esta sección explicaremos cómo puede funcionar este enfoque en una empresa.

Razones por las que es necesario un híbrido

Los enfoques de nube híbrida están muy extendidos porque hoy en día casi ninguna gran empresa depende totalmente de la nube pública. Muchas organizaciones han invertido millones de dólares y miles de horas en infraestructura local durante las últimas décadas. Casi todas las organizaciones ejecutan algunas arquitecturas tradicionales y aplicaciones críticas para el negocio que quizá no puedan trasladar a la nube pública. También pueden tener datos sensibles que no pueden almacenar en una nube pública debido a restricciones normativas u organizativas.

Permitir que las cargas de trabajo transiten entre entornos de nube pública y privada proporciona un mayor nivel de flexibilidad y opciones adicionales para la implementación de datos. Hay varias razones que impulsan la adopción híbrida (es decir, una arquitectura que abarca las instalaciones, la nube pública y el perímetro) y multicloud (es decir, una arquitectura que abarca varios proveedores de nubes públicas como AWS, Microsoft Azure y Google Cloud Platform [GCP], por ejemplo).

He aquí algunas razones empresariales clave para elegir híbrido y/o multicloud:

Normativa sobre residencia de datos: Puede que algunos nunca lleguen a migrar totalmente a la nube pública, tal vez porque se dedican a las finanzas o la sanidad y necesitan seguir estrictas normativas del sector sobre dónde se almacenan los datos. También es el caso de las cargas de trabajo en países sin presencia en la nube pública y sin un requisito de residencia de datos.
Inversiones heredadas: Algunos clientes quieren proteger sus cargas de trabajo heredadas de como SAP, Oracle o Informatica on prem, pero quieren aprovechar las innovaciones de la nube pública como, por ejemplo, Databricks y Snowflake.
Transición: Las grandes empresas suelen necesitar un viaje de varios años para modernizarse hacia aplicaciones y arquitecturas nativas de la nube. Tendrán que adoptar arquitecturas híbridas como estado intermedio durante años.
Estallido en la nube: Hay clientes que están principalmente en las instalaciones y no desean migrar a la nube pública. Sin embargo, tienen dificultades para cumplir los acuerdos de nivel de servicio (SLA) de la empresa debido a trabajos ad hoc de grandes lotes, tráfico irregular durante periodos de gran actividad o trabajos de formación de ML a gran escala. Quieren aprovechar la capacidad escalable o el hardware personalizado de las nubes públicas y evitar el coste de ampliar la infraestructura local. Soluciones como MotherDuck, que adoptan un enfoque informático "local-first", se están haciendo populares.
El mejor de la raza: Algunas organizaciones eligen distintos proveedores de nube pública para distintas tareas, en una estrategia intencionada para elegir las tecnologías que mejor se adapten a sus necesidades. Por ejemplo, Uber utiliza AWS para sus aplicaciones web, pero utiliza Cloud Spanner en Google Cloud para su plataforma de cumplimiento. Twitter ejecuta su feed de noticias en AWS, pero ejecuta su plataforma de datos en Google Cloud.

Ahora que entiendes las razones por las que podrías elegir una solución híbrida, echemos un vistazo a los principales retos a los que te enfrentarás cuando utilices este patrón; estos retos son la razón por la que lo híbrido debería tratarse como una excepción, y el objetivo debería ser ser nativo de la nube.

Retos de la nube híbrida

Hay varios retos a los que se enfrentan las empresas cuando implantan arquitecturas híbridas o multicloud:

Gobernanza: Es difícil aplicar políticas de gobernanza coherentes en varios entornos. Por ejemplo, las políticas de seguridad de cumplimiento entre las instalaciones y la nube pública suelen tratarse de forma diferente. A menudo, partes de los datos se duplican entre las instalaciones y la nube. Imagina que tu organización está realizando un informe financiero: ¿cómo garantizarías que los datos utilizados son la copia actualizada más reciente si existen múltiples copias entre plataformas?
Control de acceso: Controles de acceso de usuarios y las políticas difieren entre los entornos locales y los de nube pública. Los proveedores de la nube tienen sus propios controles de acceso de usuarios (denominados gestión de identidades y accesos, o IAM) para los servicios prestados, mientras que en las instalaciones se utilizan tecnologías como el protocolo de acceso a directorios locales (LDAP) o Kerberos. ¿Cómo mantenerlos sincronizados o tener un único plano de control en distintos entornos?
Interoperabilidad de la carga de trabajo: Cuando se atraviesan varios sistemas, es inevitable tener entornos de ejecución incoherentes que hay que gestionar.
Movimiento de datos: Si tanto las aplicaciones locales como las de la nube necesitan acceder a algunos datos, los dos conjuntos de datos deben estar sincronizados. Es costoso mover datos entre varios sistemas: hay un coste humano para crear y gestionar la canalización, puede haber costes de licencia debido al software utilizado y, por último, pero no por ello menos importante, consume recursos del sistema como computación, red y almacenamiento. ¿Cómo puede tu organización hacer frente a los costes de múltiples entornos? ¿Cómo unes datos heterogéneos que están aislados en varios entornos? ¿Dónde acabas copiando los datos como resultado del proceso de unión?
Habilidades: Tener las dos nubes (o en las instalaciones y en la nube) significa que los equipos tienen que conocer y adquirir experiencia en dos entornos. Dado que la nube pública es un entorno que evoluciona con rapidez, la actualización y el mantenimiento de los conocimientos de los empleados en una nube, por no hablar de en dos, conlleva unos gastos generales considerables. Los conjuntos de competencias también pueden ser un reto para la contratación de integradores de sistemas (SI): aunque la mayoría de los grandes SI tienen prácticas para cada una de las principales nubes, muy pocos tienen equipos que conozcan dos o más nubes. A medida que pase el tiempo, prevemos que será cada vez más difícil contratar a personas dispuestas a aprender tecnologías locales a medida.
Economía: El hecho de que los datos estén divididos entre dos entornos puede acarrear costes imprevistos: tal vez tengas datos en una nube y quieras ponerlos a disposición de otra, incurriendo en costes de salida.

A pesar de estos retos, una configuración híbrida puede funcionar. Veremos cómo en la siguiente subsección.

Por qué puede funcionar lo híbrido

Los proveedores de la nube son conscientes de estas necesidades y estos retos. Por ello, ofrecen cierto apoyo a los entornos híbridos. Éstos se dividen en tres áreas:

Elección: Los proveedores de nubes suelen hacer grandes contribuciones a las tecnologías de código abierto. Por ejemplo, aunque Kubernetes y TensorFlow se desarrollaron en Google, son de código abierto, de modo que existen entornos de ejecución gestionados para ellos en todas las principales nubes y pueden aprovecharse incluso en los entornos locales.
Flexibilidad: Frameworks como Databricks y Snowflake te permiten ejecutar el mismo software en cualquiera de las principales plataformas de nube pública. Así, los equipos pueden aprender un conjunto de habilidades que funcionará en todas partes. Ten en cuenta que la flexibilidad que ofrecen las herramientas que funcionan en varias nubes no significa que te hayas librado del bloqueo. Tendrás que elegir entre (1) el bloqueo a nivel de marco y la flexibilidad a nivel de nube (que ofrecen tecnologías como Databricks o Snowflake) y (2) el bloqueo a nivel de nube y la flexibilidad a nivel de marco (que ofrecen las herramientas nativas de la nube).
Apertura: Incluso cuando la herramienta es propietaria, el código para ella se escribe de forma portátil debido a la adopción de estándares abiertos y mecanismos de importación/exportación. Así, por ejemplo, aunque Redshift sólo se ejecute en AWS, las consultas se escriben en SQL estándar y existen múltiples mecanismos de importación y exportación. En conjunto, estas capacidades hacen de Redshift y BigQuery y Synapse plataformas abiertas. Esta apertura permite casos de uso como Teads, donde los datos se recopilan utilizando Kafka en AWS, se agregan utilizando Dataflow y BigQuery en Google Cloud, y se escriben de nuevo en AWS Redshift (ver Figura 1-9).

Hybrid analytics pipeline at Teads (figure based on an article by Alban Perillat-Merceroz published in Teads Engineering)

Los proveedores de nubes están apostando por la capacidad de elección, la flexibilidad y la apertura, realizando fuertes inversiones en proyectos de código abierto que ayuden a los clientes a utilizar varias nubes. Por tanto, los DWH multicloud o marcos híbridos de procesamiento de datos se están haciendo realidad. Así que puedes crear Implementaciones híbridas y multicloud con una mejor producción, lanzamiento y gestión del software en la nube: como tú quieras, no como dicte un proveedor.

Computación de perímetro

Otra encarnación del patrón híbrido es cuando puedes querer disponer de potencia computacional que se extienda fuera del perímetro habitual de la plataforma de datos, quizá para interactuar directamente con algunos dispositivos conectados. En este caso hablamos de computación de perímetro. La computación de perímetro acerca la computación y el almacenamiento de datos al sistema donde se generan los datos y es necesario procesarlos. El objetivo de la computación de perímetro es mejorar los tiempos de respuesta y ahorrar ancho de banda. La computación de perímetro puede desbloquear muchos casos de uso y acelerar la transformación digital. Tiene muchas áreas de aplicación, como la seguridad, la robótica, el mantenimiento predictivo, los vehículos inteligentes, etc.

A medida que la computación de perímetro se adopta y se generaliza, hay muchas ventajas potenciales para una amplia gama de industrias:

Tiempo de respuesta más rápido: En la computación de perímetro, la potencia de almacenamiento y cálculo de los datos se distribuye y se pone a disposición en el punto donde hay que tomar la decisión. El hecho de no necesitar un viaje de ida y vuelta a la nube reduce la latencia y permite respuestas más rápidas. En el mantenimiento preventivo, ayudará a evitar que se averíen las operaciones críticas de las máquinas o que se produzcan incidentes peligrosos. En los juegos activos, la computación en el perímetro puede proporcionar los tiempos de respuesta de milisegundos que se necesitan. En la prevención del fraude y los escenarios de seguridad, puede proteger contra las violaciones de la privacidad y los ataques de denegación de servicio.
Conectividad intermitente: Una conectividad a Internet poco fiable en activos remotos como pozos petrolíferos, bombas agrícolas, granjas solares o molinos de viento puede dificultar el monitoreo de esos activos. La capacidad de los dispositivos de perímetro para almacenar y procesar datos localmente garantiza que no se produzcan pérdidas de datos ni fallos operativos en caso de conectividad limitada a Internet.
Seguridad y cumplimiento: El perímetro informático puede eliminar mucha transferencia de datos entre los dispositivos y la nube. Es posible filtrar la información sensible localmente y transmitir a la nube sólo la información crítica del modelo de construcción de datos. Por ejemplo, con los dispositivos inteligentes, el procesamiento de palabras clave como escuchar "OK Google" o "Alexa" puede ocurrir en el propio dispositivo. Los datos potencialmente privados no necesitan recopilarse ni enviarse a la nube. Esto permite a los usuarios crear un marco de seguridad y cumplimiento adecuado, esencial para la seguridad y las auditorías empresariales.
Soluciones rentables: Una de las preocupaciones prácticas en torno a la adopción de IoT es el coste inicial debido al ancho de banda de la red, el almacenamiento de datos y la potencia de cálculo. La informática de perímetro puede realizar localmente muchos cálculos de datos, lo que permite a las empresas decidir qué servicios ejecutar localmente y cuáles enviar a la nube, lo que reduce los costes finales de una solución global de IoT. Aquí es donde puede sobresalir la implementación binaria de baja memoria de modelos embebidos en un formato como Open Neural Network Exchange (ONNX), construido a partir de un lenguaje compilado moderno como Rust o Go.
Interoperabilidad: Los dispositivos de perímetro pueden actuar como enlace de comunicación entre las máquinas antiguas y las modernas. Esto permite que las máquinas industriales heredadas se conecten a máquinas modernas o soluciones IoT y proporciona beneficios inmediatos de captura de información de máquinas heredadas o modernas.

Todos estos conceptos permiten a los arquitectos ser increíblemente flexibles en la definición de su plataforma de datos. En el Capítulo 9 profundizaremos más en estos conceptos y veremos cómo este patrón se está convirtiendo en un estándar .

Aplicación de la IA

Muchas organizaciones de se ven empujadas a diseñar una plataforma de datos en la nube porque necesitan adoptar tecnologías de IA; al diseñar una plataforma de datos, es importante asegurarse de que estará preparada para el futuro al ser capaz de soportar casos de uso de IA. Teniendo en cuenta el gran impacto que la IA está teniendo en la sociedad y su difusión en los entornos empresariales, hagamos una rápida inmersión en cómo puede implantarse en un entorno empresarial. Encontrarás un debate más profundo en los Capítulos 10 y 11.

Aprendizaje automático

En la actualidad, una rama de la IA denominada aprendizaje automático supervisado ha alcanzado un enorme éxito, hasta el punto de que el término IA se utiliza más a menudo como término genérico para esta rama. El ML supervisado funciona mostrando al programa informático muchos ejemplos en los que se conocen las respuestas correctas (llamadas etiquetas). El modelo de ML es un algoritmo estándar (es decir, exactamente el mismo código) que tiene parámetros sintonizables que "aprenden" cómo pasar de la entrada proporcionada a la etiqueta. Este modelo aprendido se implementa para tomar decisiones sobre entradas de las que no se conocen las respuestas correctas.

A diferencia de los sistemas expertos, no es necesario programar explícitamente el modelo de IA con las reglas para tomar decisiones. Dado que muchos dominios del mundo real implican juicios humanos en los que los expertos tienen dificultades para articular su lógica, hacer que los expertos simplemente etiqueten los ejemplos de entrada es mucho más factible que capturar su lógica.

Los algoritmos modernos para jugar al ajedrez y las herramientas de diagnóstico médico utilizan el ML. Los algoritmos para jugar al ajedrez aprenden de los registros de partidas que los humanos han jugado en el pasado,² mientras que los sistemas de diagnóstico médico aprenden de médicos expertos que etiquetan datos de diagnóstico.

Generativa La IA, una rama de la IA/ML que recientemente se ha vuelto extremadamente capaz, es capaz no sólo de comprender imágenes y texto, sino de generar imágenes y texto realistas. Además de poder crear nuevos contenidos en aplicaciones como el marketing, la IA generativa agiliza la interacción entre máquinas y usuarios. Los usuarios pueden hacer preguntas en lenguaje natural y automatizar muchas operaciones utilizando el inglés, u otros idiomas, en lugar de tener que conocer lenguajes de programación.

Para que estos métodos de ML funcionen, requieren enormes cantidades de datos de entrenamiento y hardware personalizado fácilmente disponible. Por eso, las organizaciones que adoptan la IA empiezan construyendo una plataforma de datos/ML en la nube.

Usos del ML

Hay algunas razones clave para la espectacular adopción del ML en la industria:

Los datos son más fáciles.: Es más fácil recopilar datos etiquetados que capturar la lógica. Todo razonamiento humano tiene excepciones que se codificarán con el tiempo. Es más fácil conseguir que un equipo de oftalmólogos etiquete mil imágenes que conseguir que describan cómo identifican que un vaso sanguíneo tiene una hemorragia.
Reentrenar es más fácil.: Cuando el ML se utiliza para sistemas como recomendar artículos a los usuarios o realizar campañas de marketing, el comportamiento de los usuarios cambia rápidamente para adaptarse. Es importante entrenar continuamente los modelos. Esto es posible en ML, pero mucho más difícil con código.
Mejor interfaz de usuario.: Una clase de ML llamada aprendizaje profundo ha demostrado ser capaz de entrenarse incluso con datos no estructurados como imágenes, vídeo y texto en lenguaje natural. Estos tipos de entradas son notoriamente difíciles de programar. Esto te permite utilizar datos del mundo real como datos de entrada: piensa en lo mucho que mejora la interfaz de usuario del ingreso de cheques cuando puedes simplemente hacer una fotografía de un cheque en lugar de tener que teclear toda la información en un formulario web.
Automatización.: La capacidad de los modelos ML para comprender datos no estructurados permite automatizar muchos procesos empresariales. Los formularios pueden digitalizarse fácilmente, los diales de los instrumentos pueden leerse con mayor facilidad y las plantas de producción pueden monitorearse más fácilmente gracias a la capacidad de procesar automáticamente texto, imágenes o vídeo en lenguaje natural.
Coste-eficacia.: Las API de ML que dan a las máquinas la capacidad de comprender y crear texto, imágenes, música y vídeo cuestan una fracción de céntimo por invocación, mientras que pagar a un humano para hacerlo costaría varios órdenes de magnitud más. Esto permite el uso de la tecnología en situaciones como las recomendaciones, en las que un asistente personal de compras sería prohibitivamente caro.
Asistencia.: La IA generativa puede ayudar a desarrolladores, vendedores y otros trabajadores de cuello blanco a ser más productivos . Los asistentes de codificación y los copilotos de flujo de trabajo pueden simplificar partes de muchas funciones corporativas, como el envío de correos electrónicos de ventas personalizados.

Dadas estas ventajas, no es sorprendente que un artículode Harvard Business Review descubriera que la IA suele apoyar tres requisitos empresariales principales :

Automatización de los procesos empresariales: por lo general, automatización de las tareas administrativas y financieras de back-office.
Obtener información mediante el análisis de datos
Comprometerse con clientes y empleados

El ML aumenta la escalabilidad para resolver esos problemas utilizando ejemplos de datos y sin necesidad de escribir código personalizado para todo. Luego, las soluciones de ML, como el aprendizaje profundo, permiten resolver estos problemas incluso cuando esos datos consisten en información no estructurada, como imágenes, voz, vídeo, texto en lenguaje natural, etc. .

¿Por qué la nube para la IA?

Un impulso clave detrás del diseño de una plataforma de datos en la nube podría ser que la organización está adoptando rápidamente tecnologías de IA, como el aprendizaje profundo. Para que estos métodos funcionen, requieren enormes cantidades de datos de entrenamiento. Por lo tanto, una organización que planee construir modelos de ML necesitará construir una plataforma de datos para organizar y poner los datos a disposición de sus equipos de ciencia de datos. Los propios modelos de ML son muy complejos, y el entrenamiento de los modelos requiere grandes cantidades de hardware especializado llamado unidades de procesamiento gráfico (GPU). Además, las tecnologías de IA como la transcripción de voz, la traducción automática y la inteligencia de vídeo suelen estar disponibles como software SaaS en la nube. Además, las plataformas en la nube proporcionan capacidades clave como la democratización, una operacionalización más sencilla y la capacidad de mantenerse al día con el estado de la técnica.

Infraestructura en la nube

La conclusión es que la IA de alta calidad requiere muchos datos: un famoso artículo titulado "Deep Learning Scaling Is Predictable, Empirically" descubrió que para mejorar un 5% un modelo de lenguaje natural, era necesario entrenar el doble de datos de los que se utilizaron para obtener el primer resultado. Los mejores modelos de ML no son los más avanzados, sino los que se entrenan con más datos de calidad suficiente. La razón es que los modelos cada vez más sofisticados requieren más datos, mientras que incluso los modelos sencillos mejorarán su rendimiento si se entrenan con un conjunto de datos suficientemente grande.

Para que te hagas una idea de la cantidad de datos necesarios para completar el entrenamiento de los modelos modernos de ML, los modelos de clasificación de imágenes se entrenan habitualmente con un millón de imágenes y los principales modelos lingüísticos se entrenan con varios terabytes de datos.

Como se muestra en la Figura 1-10, este tipo de cantidad de datos requiere una gran cantidad de cálculo eficiente y a medida -proporcionado por aceleradores como las GPU y los circuitos integrados (ASIC) personalizados para aplicaciones específicas, denominadosunidades de procesamiento tensorial (TPU) - para aprovechar estos datos y darles sentido.

Muchos avances recientes de la IA pueden atribuirse al aumento del tamaño de los datos y de la potencia de cálculo. La sinergia entre los grandes conjuntos de datos en la nube y los numerosos ordenadores que los alimentan ha permitido enormes avances en el ML. Entre los avances se incluye la reducción de las tasas de error de las palabras en el reconocimiento del habla en un 30% con respecto a los enfoques tradicionales, la mayor ganancia en 20 años.

Democratización

La arquitectura de los modelos ML de , especialmente en dominios complejos como el procesamiento de series temporales o el procesamiento del lenguaje natural (PLN), requiere conocimientos de teoría ML. Escribir código para entrenar modelos de ML utilizando marcos como PyTorch, Keras o TensorFlow requiere conocimientos de programación en Python y álgebra lineal. Además, la preparación de datos para ML a menudo requiere conocimientos de ingeniería de datos, y la evaluación de modelos ML requiere conocimientos de estadística avanzada. La implementación de modelos de ML y su monitoreo requieren conocimientos de DevOps e ingeniería de software (a menudo denominados MLOps). Huelga decir que es raro que todas estas habilidades estén presentes en todas las organizaciones. Por ello, aprovechar el ML para los problemas empresariales puede resultar difícil para una empresa tradicional.

Las tecnologías en la nube ofrecen varias opciones para democratizar el uso del ML:

API ML: Los proveedores de la nube ofrecen modelos ML preconstruidos que pueden invocarse a través de las API. En ese momento, un desarrollador puede consumir el modelo ML como cualquier otro servicio web. Todo lo que necesitan es la capacidad de programar contra servicios web de transferencia de estado representacional (REST). Algunos ejemplos de tales API de ML son Google Translate, Azure Text Analytics y Amazon Lex; estas API pueden utilizarse sin ningún conocimiento de PNL. Los proveedores de la nube proporcionan modelos generativos para la generación de texto e imágenes como API en las que la entrada es sólo un mensaje de texto.
Modelos ML personalizables: Algunas nubes públicas ofrecen "AutoML," que son tuberías ML de extremo a extremo que pueden entrenarse e implementarse con un clic de ratón. Los modelos AutoML realizan una "búsqueda de arquitectura neuronal", automatizando esencialmente la arquitectura de los modelos de ML mediante un mecanismo de búsqueda. Aunque el entrenamiento lleva más tiempo que si un experto humano elige un modelo eficaz para el problema, el sistema AutoML puede ser suficiente para las líneas de negocio que no tienen capacidad para arquitecturar sus propios modelos. Ten en cuenta que no todos los AutoML son iguales: a veces, lo que se llama AutoML es sólo ajuste de parámetros. Asegúrate de que estás obteniendo una arquitectura personalizada en lugar de simplemente una elección entre modelos preconstruidos, comprobando que hay varios pasos que pueden automatizarse (por ejemplo, ingeniería de características, extracción de características, selección de características, selección de modelos, ajuste de parámetros, comprobación de problemas , etc.).
ML más sencillo: Algunos DWH (BigQuery y Redshift en el momento de escribir esto) ofrecen la posibilidad de entrenar modelos ML en datos estructurados utilizando sólo SQL. Redshift y BigQuery admiten modelos complejos delegando en Vertex AI y SageMaker respectivamente. Herramientas como DataRobot y Dataiku ofrecen interfaces de apuntar y hacer clic para entrenar modelos ML. Las plataformas en la nube facilitan enormemente el ajuste de los modelos generativos.
Soluciones ML: Algunas aplicaciones son tan comunes que las soluciones de ML de extremo a extremo están disponibles para su compra e implementación. Product Discovery en Google Cloud ofrece una experiencia de búsqueda y clasificación de extremo a extremo para minoristas. Amazon Connect ofrece un centro de contacto listo para su implementación basado en ML. Azure Knowledge Mining ofrece una forma de extraer diversos tipos de contenido. Además, empresas como Quantum Metric y C3 AI ofrecen soluciones basadas en la nube para problemas comunes en varios sectores.
Bloques de construcción del ML: Aunque no exista una solución para todo el flujo de trabajo de ML, algunas partes del mismo podrían aprovechar los bloques de construcción. Por ejemplo, los sistemas de recomendación requieren la capacidad de emparejar artículos y productos. En Google Cloud hay disponible un algoritmo de emparejamiento de uso general llamado codificador de dos torres. Aunque no existe un modelo ML de automatización de back-office de extremo a extremo, podrías aprovechar los analizadores sintácticos de formularios para ayudar a implementar ese flujo de trabajo más rápidamente.

Estas capacidades permiten a las empresas adoptar la IA aunque no tengan una gran experiencia en ella, lo que hace que la IA esté más ampliamente disponible.

Incluso si la empresa tiene experiencia en IA, estas capacidades resultan muy útiles porque aún tiene que decidir si compra o construye un sistema de ML. Suele haber más oportunidades de ML que personas para resolverlas. Teniendo esto en cuenta, es ventajoso permitir que las funciones no esenciales se lleven a cabo mediante herramientas y soluciones preconstruidas. Estas soluciones listas para usar pueden aportar mucho valor de forma inmediata, sin necesidad de escribir aplicaciones personalizadas. Por ejemplo, los datos de un texto en lenguaje natural pueden pasarse a un modelo preconstruido mediante una llamada a la API para traducir el texto de un idioma a otro. Esto no sólo reduce el esfuerzo de crear aplicaciones, sino que también permite a los no expertos en ML utilizar la IA. En el otro extremo del espectro, el problema puede requerir una solución personalizada. Por ejemplo, los minoristas suelen crear modelos de ML para prever la demanda y saber qué cantidad de producto deben almacenar. Estos modelos aprenden patrones de compra a partir de los datos históricos de ventas de una empresa, combinados con la intuición interna de expertos.

Otro patrón común es utilizar modelos preconstruidos y listos para usar para una experimentación rápida, y una vez que la solución de ML ha demostrado su valor, un equipo de ciencia de datos puede construirla a medida para obtener una mayor precisión y, con suerte, una mayor diferenciación frente a la competencia .

En tiempo real

Es necesario que la infraestructura de ML se integre con una plataforma de datos moderna, porque el ML personalizado y en tiempo real es donde está el valor. Como resultado, la velocidad de análisis se vuelve realmente importante, ya que la plataforma de datos debe ser capaz de ingerir, procesar y servir datos en tiempo real, o se perderán oportunidades. Esto se complementa con la velocidad de acción. El ML impulsa servicios personalizados, basados en el contexto del cliente, pero tiene que proporcionar inferencia antes de que el contexto del cliente cambie: hay una ventana de cierre para la mayoría de las transacciones comerciales dentro de la cual el modelo ML tiene que proporcionar al cliente una opción para actuar. Para conseguirlo, necesitas que los resultados de los modelos ML lleguen al punto de acción en tiempo real.

Poder suministrar datos a los modelos ML en tiempo real y obtener la predicción ML en tiempo real es la diferencia entre prevenir el fraude y descubrirlo. Para prevenir el fraude, es necesario ingerir toda la información sobre el pago y el cliente en tiempo real, ejecutar la predicción ML y devolver el resultado del modelo ML al sitio de pago en tiempo real, de modo que el pago pueda ser rechazado si se sospecha de fraude.

Otras situaciones en las que el procesamiento en tiempo real ahorra dinero son la atención al cliente y el abandono de carritos. Captar la frustración del cliente en un centro de llamadas y escalar inmediatamente la situación es importante para que el servicio sea eficaz: costará mucho más dinero volver a captar a un cliente una vez perdido que prestarle un buen servicio en el momento. Del mismo modo, si un carrito corre el riesgo de ser descartado, ofrecer un aliciente como un 5% de descuento o el envío gratuito puede costar menos que las promociones mucho mayores necesarias para que el cliente vuelva al sitio web.

En otras situaciones, el procesamiento por lotes simplemente no es una opción eficaz. Los datos de tráfico en tiempo real y los modelos de navegación en tiempo real son necesarios para que Google Maps permita a los conductores evitar el tráfico.

Como verás en el Capítulo 8, la capacidad de recuperación y autoescalado de los servicios en la nube es difícil de conseguir en las instalaciones. Por tanto, el ML en tiempo real se realiza mejor en la nube.

MLOps

Otra razón de que el ML es mejor en la nube pública es que operacionalizar el ML es difícil. Para que los proyectos de ML sean eficaces y tengan éxito, es necesario hacer operativos tanto los datos como el código. Observar, orquestar y actuar en el ciclo de vida del ML se denomina MLOps.

Construir, implementar y ejecutar aplicaciones de ML en producción conlleva varias etapas, como se muestra en la Figura 1-11. Todos estos pasos deben orquestarse y monitorearse; si, por ejemplo, se detecta una desviación de los datos, puede ser necesario reentrenar automáticamente los modelos. Los modelos tienen que reentrenarse constantemente y desplegarse, después de asegurarse de que su despliegue es seguro. Para los datos entrantes, tienes que realizar el preprocesamiento y la validación de datos para asegurarte de que no hay problemas de calidad de datos, seguido de la ingeniería de características, seguido del entrenamiento de modelos y terminando con el ajuste de hiperparámetros.

Además de los aspectos del monitoreo específicos de los datos que hemos comentado, también tienes el monitoreo y la operacionalización que son necesarios para cualquier servicio en funcionamiento. A menudo, una aplicación de producción se ejecuta continuamente, 24 horas al día, 7 días a la semana, 365 días al año, y recibe nuevos datos con regularidad. Por lo tanto, necesitas herramientas que faciliten la orquestación y gestión de estos flujos de trabajo ML multifase y su ejecución fiable y repetida.

Las plataformas de IA en la nube, como Vertex AI de Google, Azure Machine Learning de Microsoft y SageMaker de Amazon, ofrecen servicios gestionados para todo el flujo de trabajo de ML. Si lo haces in situ, tendrás que improvisar las tecnologías subyacentes y gestionar tú mismo las integraciones.

En el momento de escribir este libro, se están añadiendo capacidades de ML a un ritmo vertiginoso a las distintas plataformas en la nube. Esto plantea un punto secundario: con el rápido ritmo de cambio en ML, es mejor que delegues la tarea de construir y mantener la infraestructura y las herramientas de ML a un tercero y te centres en los datos y las perspectivas que son relevantes para tu negocio principal.

En resumen, una plataforma de datos e IA basada en la nube puede ayudar a resolver los retos tradicionales con los silos de datos, la gobernanza y la capacidad, al tiempo que permite a la organización prepararse para un futuro en el que las capacidades de IA adquieran más importancia .

Principios básicos

Al diseñar una plataforma de datos, puede ser útil establecer los principios clave de diseño a los que adherirse y el peso que deseas asignar a cada uno de estos principios. Es probable que tengas que hacer concesiones entre estos principios, y tener una tabla de puntuación predeterminada que todas las partes interesadas hayan acordado puede ayudarte a tomar decisiones sin tener que volver a los primeros principios o dejarte llevar por la rueda más chirriante.

He aquí los cinco principios de diseño clave para una pila de análisis de datos que sugerimos, aunque la ponderación relativa variará de una organización a otra:

Ofrece análisis sin servidor, no infraestructura.: Diseña soluciones analíticas para entornos totalmente gestionados y evita, en la medida de lo posible, un enfoque de "levantar y cambiar". Céntrate en una arquitectura moderna sin servidor para permitir que tus científicos de datos (utilizamos este término en sentido amplio para referirnos a ingenieros de datos, analistas de datos e ingenieros de ML) mantengan su atención puramente en la analítica y se alejen de las consideraciones de infraestructura. Por ejemplo, utiliza la transferencia automatizada de datos para extraer datos de tus sistemas y proporcionar un entorno para datos compartidos con consulta federada a través de cualquier servicio. Esto elimina la necesidad de mantener marcos personalizados y canalizaciones de datos.
Incorpora ML de extremo a extremo.: Permite que tu organización haga operativo ML de principio a fin. Es imposible construir todos los modelos de ML que tu organización necesita, así que asegúrate de que estás construyendo una plataforma en la que sea posible integrar opciones de ML democratizadas, como modelos de ML preconstruidos, bloques de construcción de ML y marcos más fáciles de usar. Asegúrate de que cuando se necesite formación personalizada, haya acceso a potentes aceleradores y modelos personalizables. Garantizar el soporte de MLOps para que los modelos de ML desplegados no se desvíen y dejen de ser adecuados para su propósito. Simplificar el ciclo de vida de ML en toda la pila para que la organización pueda obtener valor de sus iniciativas de ML más rápidamente.
Potencia la analítica en todo el ciclo de vida de los datos.: La plataforma de análisis de datos debe ofrecer un conjunto completo de cargas de trabajo de análisis de datos básicos. Asegúrate de que tu plataforma de datos ofrece almacenamiento de datos, almacenamiento de datos, análisis de datos en streaming, preparación de datos, procesamiento de big data, intercambio y monetización de datos, inteligencia empresarial (BI) y ML. Evita comprar soluciones puntuales que tendrás que integrar y gestionar. Considerar la pila analítica de forma mucho más holística te permitirá, a cambio, romper los silos de datos, potenciar las aplicaciones con datos en tiempo real, añadir conjuntos de datos de sólo lectura y hacer que los resultados de las consultas sean accesibles a cualquiera.
Habilitar las tecnologías de software de código abierto (OSS).: Siempre que sea posible, asegúrate de que el código abierto sea el núcleo de tu plataforma. Debes asegurarte de que cualquier código que escribas utilice estándares OSS, como SQL estándar, Apache Spark, TensorFlow, etc. Al habilitar las mejores tecnologías de código abierto, podrás proporcionar flexibilidad y capacidad de elección en los proyectos de análisis de datos.
Construye para crecer.: Asegúrate de que la plataforma de datos que construyas sea capaz de escalar al tamaño de los datos, el rendimiento y el número de usuarios simultáneos a los que se espera que se enfrente tu organización. A veces, esto implicará elegir diferentes tecnologías (por ejemplo, SQL para algunos casos de uso y NoSQL para otros casos de uso). Si lo haces, asegúrate de que las dos tecnologías que elijas interoperan entre sí. Aprovecha las soluciones y los marcos de trabajo probados y utilizados por las empresas más innovadoras del mundo para ejecutar sus aplicaciones analíticas de misión crítica.

En general, estos factores se enumeran en el orden en que solemos recomendarlos. Dado que las dos motivaciones principales de las empresas a la hora de elegir hacer una migración a la nube son el coste y la innovación, te recomendamos que des prioridad a la tecnología sin servidor (por el ahorro de costes y por liberar a los empleados del trabajo rutinario) y al ML de extremo a extremo (por la gran variedad de innovación que permite).

En algunas situaciones, puede que quieras dar prioridad a unos factores sobre otros. Para las startups, solemos recomendar que los factores más importantes sean la ausencia de servidor, el crecimiento y el ML de extremo a extremo. La exhaustividad y la apertura pueden sacrificarse por la velocidad. Las empresas muy reguladas pueden favorecer la exhaustividad, la apertura y el crecimiento frente a la ausencia de servidor y el ML (es decir, los organismos reguladores pueden exigir que la empresa esté en sus instalaciones). Para los nativos digitales, recomendamos, por orden, ML de extremo a extremo, sin servidor, crecimiento, apertura y exhaustividad.

Resumen

Se trató de una introducción de alto nivel a la modernización de la plataforma de datos. Partiendo de la definición del ciclo de vida de los datos, vimos la evolución del procesamiento de datos, las limitaciones de los enfoques tradicionales y cómo crear una plataforma analítica unificada en la nube. También vimos cómo ampliar la plataforma de datos en la nube para que sea híbrida y admita IA/ML. Los puntos clave de este capítulo son los siguientes:

El ciclo de vida de los datos tiene cinco etapas: recopilar, almacenar, procesar, analizar/visualizar y activar. Éstas deben estar respaldadas por una plataforma de datos y ML.
Tradicionalmente, los ecosistemas de datos de las organizaciones consisten en soluciones independientes que conducen a la creación de silos dentro de la organización.
Las herramientas de movimiento de datos pueden romper los silos de datos, pero imponen algunos inconvenientes: latencia, cuellos de botella en los recursos de ingeniería de datos, sobrecarga de mantenimiento, gestión de cambios y lagunas de datos.
Centralizar el control de los datos en TI conlleva retos organizativos. Los departamentos de TI no tienen las competencias necesarias, los equipos de análisis obtienen datos deficientes y los equipos empresariales no confían en los resultados.
Las organizaciones necesitan crear una plataforma de datos en la nube para obtener las mejores arquitecturas, gestionar la consolidación entre unidades de negocio, escalar los recursos on-prem y planificar la continuidad del negocio.
Una plataforma de datos en la nube aprovecha los enfoques modernos y tiene como objetivo permitir la innovación basada en los datos mediante la replanificación de los datos, la eliminación de los silos, la democratización de los datos, la aplicación de la gobernanza de los datos, la posibilidad de tomar decisiones en tiempo real y utilizando la información de localización, y el paso sin problemas de la analítica descriptiva a la analítica predictiva y prescriptiva.
Todos los datos pueden exportarse desde los sistemas operativos a un lago de datos centralizado para su análisis. El lago de datos sirve como repositorio central para las cargas de trabajo analíticas y para los usuarios empresariales. El inconveniente, sin embargo, es que los usuarios empresariales no tienen los conocimientos necesarios para programar contra un lago de datos.
Los DWH son almacenes analíticos centralizados que admiten SQL, algo con lo que los usuarios empresariales están familiarizados.
El lago de datos se basa en la idea de que todos los usuarios, independientemente de sus conocimientos técnicos, pueden y deben poder utilizar los datos. Al proporcionar un marco centralizado y subyacente para hacer accesibles los datos, se pueden utilizar distintas herramientas sobre el lago de datos para satisfacer las necesidades de cada usuario.
La malla de datos introduce una forma de ver los datos como un producto autónomo. Los equipos distribuidos en este enfoque son dueños de la producción de datos y sirven a consumidores internos/externos mediante esquemas de datos bien definidos.
Un entorno de nube híbrida es un enfoque pragmático para responder a las realidades del mundo empresarial, como las adquisiciones, las leyes locales y los requisitos de latencia.
La capacidad de la nube pública para proporcionar formas de gestionar grandes conjuntos de datos y suministrar GPU bajo demanda la hace indispensable para todas las formas de ML, pero en particular para el aprendizaje profundo y la IA generativa. Además, las plataformas en la nube proporcionan capacidades clave como la democratización, una operacionalización más sencilla y la capacidad de mantenerse al día con el estado de la técnica.
Los cinco principios básicos de una plataforma de datos en la nube son dar prioridad a la analítica sin servidor, el ML de extremo a extremo, la exhaustividad, la apertura y el crecimiento. El peso relativo variará de una organización a otra.

Ahora que ya sabes dónde quieres aterrizar, en el próximo capítulo veremos una estrategia para llegar hasta allí.

¹ No se trata sólo del coste de la tecnología o de los derechos de licencia: aquí se incluyen los costes de personal, y los conocimientos de SQL suelen costar menos a una organización que los de Java o Python.

² Los sistemas de ML recientes, como AlphaGo, aprenden observando las partidas que juegan las propias máquinas: se trata de un tipo avanzado de ML llamado aprendizaje por refuerzo, pero la mayoría de los usos industriales del ML son del tipo supervisado más sencillo.

Get Arquitectura de Plataformas de Datos y Aprendizaje Automático now with the O’Reilly learning platform.

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

Start your free trial