El lago de datos en la nube

Capítulo 1. Big Data: más allá del rumor

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

Sin big data, estás ciego y sordo y en medio de una autopista.

Geoffrey Moore

Si jugáramos al bingo en el lugar de trabajo, hay muchas posibilidades de que ganaras tachando todos estos términos que has oído en tu organización en los últimos tres meses: transformación digital, estrategia de datos, visión transformadora, lago de datos, almacén, ciencia de datos, aprendizaje automático e inteligencia. Ya es de dominio público que los datos son un ingrediente clave para que las organizaciones tengan éxito, y las organizaciones que se basan en los datos y la IA superan claramente a sus contendientes. Según un estudio de IDC patrocinado por Seagate, se espera que la cantidad de datos que se capturan, recopilan o replican crezca hasta 175 zettabytes (ZB) en el año 2025. Estos datos capturados, recogidos o replicados se denominan la Esfera Global de Datos. Estos datos proceden de tres clases de fuentes:

El núcleo

Centros de datos tradicionales o en la nube

El perímetro

Infraestructuras reforzadas, como torres de telefonía móvil

Los puntos finales

PCs, tablets, smartphones y dispositivos del Internet de las Cosas (IoT)

Este estudio también predice que el 49% de esta DataSphere Global residirá en entornos de nube pública para el año 2025.

Si alguna vez te has preguntado: "¿Por qué hay que almacenar estos datos? ¿Para qué sirven?", la respuesta es muy sencilla. Piensa en todos estos datos como trozos de palabras esparcidos por el mundo en diferentes idiomas, cada uno compartiendo una brizna de información, como piezas de un puzzle. Unirlas de forma significativa cuenta una historia que no sólo informa, sino que también podría transformar las empresas, las personas e incluso la forma en que funciona el mundo. La mayoría de las organizaciones de éxito ya aprovechan los datos para comprender los factores que impulsan el crecimiento de sus negocios y las experiencias percibidas de los clientes, y para tomar las medidas adecuadas; observar "el embudo", o la adquisición, adopción, compromiso y retención de los clientes, es ahora en gran medida la lingua franca de la financiación de las inversiones en productos. Estos tipos de procesamiento y análisis de datos se denominan inteligencia empresarial, o BI, y se clasifican como "insights offline". Esencialmente, los datos y los insights son cruciales para presentar la tendencia que muestra el crecimiento, de modo que los líderes empresariales puedan tomar medidas; sin embargo, esta corriente de trabajo está separada de la lógica empresarial central utilizada para dirigir el negocio en sí. A medida que crece la madurez de la plataforma de datos, una señal inevitable que recibimos de todos los clientes es que empiezan a recibir más solicitudes para ejecutar más escenarios en sus lagos de datos, adhiriéndose verdaderamente al modismo "Los datos son el nuevo petróleo".

Las organizaciones aprovechan los datos para comprender los factores de crecimiento de sus negocios y la experiencia percibida por los clientes. A continuación, pueden utilizar los datos para establecer objetivos e impulsar mejoras en la experiencia del cliente con una mejor asistencia y nuevas funciones. También pueden crear mejores estrategias de marketing para hacer crecer sus negocios e impulsar la eficiencia para reducir los costes de creación de sus productos y organizaciones. Starbucks, la cafetería presente en todo el mundo, utiliza datos en todos los lugares posibles para medir y mejorar continuamente su negocio. Como se explica en este vídeo de YouTube, Starbucks utiliza los datos de sus aplicaciones móviles y los correlaciona con su sistema de pedidos para comprender mejor los patrones de uso de los clientes y enviar campañas de marketing específicas. Utiliza sensores en sus máquinas de café que emiten datos de salud cada pocos segundos, y estos datos se analizan para impulsar mejoras en su mantenimiento predictivo. También utiliza estas máquinas de café conectadas para descargarles recetas sin intervención humana.

Mientras el mundo está aprendiendo a hacer frente a la pandemia de COVID-19, las organizaciones están aprovechando mucho los datos, no sólo para transformar sus negocios, sino también para medir la salud y la productividad de sus organizaciones, a fin de ayudar a sus empleados a sentirse conectados y minimizar el agotamiento. En general, los datos también se utilizan para iniciativas que salvan el mundo, como el Proyecto Zamba, que utiliza la IA para la investigación y conservación de la vida salvaje en las remotas selvas de África, así como aprovecha el IoT y la ciencia de datos para crear una economía circular que promueva la sostenibilidad medioambiental.

¿Qué es el Big Data?

Todos los ejemplos citados anteriormente tienen algunas cosas en común:

• Estos escenarios ilustran que los datos pueden explorarse y consumirse de diversas formas, y cuando se generan los datos, no se tiene realmente una idea clara de los patrones de consumo. Esto difiere de los sistemas tradicionales de procesamiento de transacciones en línea (OLTP) y de procesamiento analítico en línea (OLAP), en los que los datos se diseñan y elaboran específicamente para resolver problemas empresariales concretos.

• Los datos pueden venir en todo tipo de formas y formatos: Pueden ser unos pocos bytes emitidos por un sensor IoT, volcados de datos de redes sociales, archivos de sistemas de línea de negocio (LOB) y bases de datos relacionales, y a veces incluso contenido de audio y vídeo.

• Los escenarios de procesamiento de big data son muy diferentes, ya se trate de ciencia de datos, consultas tipo SQL o cualquier otro procesamiento personalizado.

• Como demuestran los estudios, los big data no son sólo grandes volúmenes, sino que también pueden llegar a distintas velocidades: como un gran volcado, como los datos ingeridos por lotes desde bases de datos relacionales, o en flujo continuo, como los datos de clics o de IoT.

Estas son algunas de las características de los big data. El procesamiento de big data se refiere al conjunto de herramientas y tecnologías utilizadas para almacenar, gestionar y analizar datos sin plantear ninguna restricción o suposición sobre la fuente, el formato o el tamaño de los datos.

El objetivo del procesamiento de big data es analizar una gran cantidad de datos de calidad variable y generar perspectivas de alto valor. Las fuentes de datos que vimos anteriormente, ya sean sensores IoT o volcados de medios sociales, contienen señales valiosas para la empresa. Por ejemplo, las fuentes de los medios sociales tienen indicadores de los sentimientos de los clientes: si les encantó un producto y tuitearon sobre él o si tuvieron problemas de los que se quejaron. Estas señales están ocultas en medio de un gran volumen de otros datos, lo que crea una densidad de valor inferior: tienes que depurar una gran cantidad de datos para obtener una pequeña cantidad de señal. En algunos casos, lo más probable es que no tengas ninguna señal. ¿Una aguja en un pajar?

Además, una señal por sí sola puede no decirte mucho; sin embargo, cuando combinas dos señales débiles, obtienes una señal más fuerte. Por ejemplo, los datos de los sensores de los vehículos te dicen con qué frecuencia se usan los frenos o se pisan los aceleradores, los datos de tráfico te dan patrones de tráfico y los datos de ventas de coches te informan de quién ha comprado qué coches. Aunque estas fuentes de datos son dispares, las compañías de seguros podrían correlacionar los datos de los sensores de los vehículos y los patrones de tráfico para construir un perfil de lo seguro que es el conductor, ofreciendo así tarifas de seguro más bajas a los conductores con perfiles de conducción seguros.

Como se ve en la Figura 1-1, un sistema de procesamiento de big data permite correlacionar una gran cantidad de datos con una densidad de valor variada (la densidad de valor puede considerarse como la relación señal-ruido) para generar percepciones con una densidad de alto valor definido. Estas percepciones tienen el poder de impulsar transformaciones críticas de productos, procesos y culturas organizativas.

Figura 1-1. Visión general del procesamiento de big data

Los grandes datos suelen caracterizarse por seis V. Dato curioso: hace unos años, caracterizábamos los grandes datos con sólo tres V: volumen, velocidady variedad. Ya hemos añadido tres V más: valor, veracidady variabilidad. Esto sólo demuestra cómo se han desvelado más dimensiones en sólo unos años. Bueno, quién sabe, para cuando se publique este libro, ¡quizá se añadan más Vs! Echemos ahora un vistazo a las Vs:

Volumen

Esta es la parte "grande" de los grandes datos, refiriéndose al tamaño de los conjuntos de datos que se procesan. Cuando las bases de datos o los almacenes de datos se refieren a hiperescala, eso podría significar decenas o cientos de terabytes (TB) y, en raras ocasiones, petabytes (PB), de datos. Además, podrías tener miles de columnas en tus conjuntos de datos que contribuyen a otra dimensión del volumen. En el mundo del procesamiento de big data, los PB de datos son más bien la norma, y los lagos de datos más grandes crecen fácilmente hasta cientos de PB a medida que se ejecutan más y más escenarios en el lago de datos. Algo a tener en cuenta aquí es que el volumen es un espectro en big data. Necesitas tener un sistema que funcione bien para TBs de datos y que pueda escalar igual de bien a medida que estos TBs se acumulan hasta cientos de PBs. Esto permite a tu organización empezar poco a poco y escalar a medida que crecen tu negocio y tu patrimonio de datos.

Velocidad

Los datos en el ecosistema de big data tienen asociadas diferentes "velocidades", en cuanto a la rapidez con que se generan y la rapidez con que se mueven y cambian. Por ejemplo, piensa en las tendencias en las redes sociales. Mientras que un vídeo en TikTok puede hacerse viral, unos días después es completamente irrelevante, dejando espacio a la siguiente tendencia. En la misma línea, piensa en los datos sanitarios como tus pasos diarios; aunque es una información crítica para medir tu actividad en ese momento, es menos señal unos días después. En estos ejemplos, tienes millones, a veces incluso miles de millones, de eventos generados a escala que necesitan ser ingeridos, y conocimientos generados casi en tiempo real, ya sean recomendaciones en tiempo real sobre qué hashtags son tendencia o a qué distancia estás de tu objetivo diario. Por otro lado, tienes escenarios en los que el valor de los datos persiste durante mucho tiempo. Por ejemplo, la previsión de ventas y la planificación presupuestaria se basan en gran medida en las tendencias de años anteriores y aprovechan los datos que han persistido durante los últimos meses o años. Un sistema de big data que admita estos dos escenarios -el almacenamiento de una gran cantidad de datos en lotes, así como el flujo continuo de datos y la capacidad de procesarlos- te permite tener la flexibilidad de ejecutar una variedad de escenarios en tu lago de datos y correlacionar datos de estas diversas fuentes para generar perspectivas que antes no habrían sido posibles. Por ejemplo, podrías predecir las ventas basándote en patrones a largo plazo, así como en tendencias rápidas de las redes sociales, utilizando el mismo sistema.

Variedad

Como vimos en la primera V, los sistemas de procesamiento de grandes datos de se adaptan a un espectro de escenarios. La clave para ello es admitir una gran variedad de datos. Los sistemas de procesamiento de big data tienen la capacidad de procesar datos sin imponer ninguna restricción en cuanto al tamaño, la estructura o el origen de los datos. Te ofrecen la posibilidad de trabajar con datos estructurados (tablas de bases de datos, sistemas LOB) que tienen una estructura tabular definida y sólidas garantías, datos semiestructurados (datos en estructuras definidas de forma flexible, como CSV y JSON) y datos no estructurados (imágenes, feeds de redes sociales, vídeo, archivos de texto, etc.). Esto te permite obtener señales de fuentes que son valiosas (piensa en documentos de seguros o hipotecas) sin hacer ninguna suposición sobre cuál es el formato de los datos.

Nota

La mayoría de los almacenes de datos prometen la capacidad de escalar a múltiples PBs de datos y operar con datos no estructurados, y están mejorando incesantemente el soporte tanto para un mayor volumen como para una mayor variedad. Es importante recordar que los almacenes de datos no están diseñados para almacenar y procesar decenas o cientos de PBs, al menos en su versión actual. Una consideración adicional es el coste, donde, dependiendo de tus escenarios, podría ser mucho más barato almacenar los datos en tu lago de datos en comparación con el almacén de datos. Además, aunque los almacenes de datos ofrecen soporte para datos no estructurados, su camino altamente optimizado es procesar datos estructurados que están en un formato propietario específico de ese almacén. Aunque la línea entre los lagos de datos y los almacenes de datos sigue difuminándose, es importante tener en cuenta estas propuestas de valor originales a la hora de elegir la arquitectura adecuada para tu plataforma de datos.

Veracidad

La veracidad se refiere a la calidad y al origen de los big data. Un sistema de análisis de big data acepta datos sin ninguna suposición sobre el formato o la fuente, lo que significa que, naturalmente, no todos los datos están alimentados con información altamente estructurada. Por ejemplo, tu frigorífico inteligente podría enviar unos cuantos bytes de información indicando el estado de salud de su dispositivo, y parte de esta información podría perderse o ser imperfecta dependiendo de la implementación. Los sistemas de procesamiento de big data deben incorporar una fase de preparación de los datos, en la que se examinan, limpian y curan antes de realizar operaciones complejas.

Variabilidad

Ya sea el tamaño, la estructura, la fuente o la calidad, la variabilidad es el nombre del juego en los sistemas de big data. Cualquier sistema de procesamiento de big data necesita incorporar variabilidad para poder operar con todos y cada uno de los tipos de datos. Además, los sistemas de procesamiento pueden definir la estructura de los datos que deseen bajo demanda, lo que se denomina aplicar un esquema bajo demanda. Por ejemplo, si tienes datos de taxis en un CSV con cientos de puntos de datos, un sistema de procesamiento podría centrarse en los valores correspondientes a origen y destino ignorando el resto, y otro podría centrarse en la identificación del conductor y la tarificación ignorando el resto. Éste es el mayor poder: cada sistema contiene por sí mismo una pieza del rompecabezas, y juntándolos todos revelan perspectivas como nunca antes. Una vez trabajé con una empresa de servicios financieros que recopilaba datos de varios condados sobre viviendas y terrenos; obtenían los datos como archivos de Microsoft Excel, volcados CSV o copias de seguridad de bases de datos muy estructuradas. Procesaban estos datos y los agregaban para generar excelentes perspectivas sobre el valor del suelo, el valor de la vivienda y las pautas de compra según la zona, que les permitían establecer adecuadamente los tipos hipotecarios.

Valor

Probablemente esto ya se ha subrayado en los puntos anteriores, pero la V más importante que hay que destacar es el valor de los datos en los sistemas de big data. Lo mejor de los sistemas de big data es que el valor no es único. Los datos se recopilan y almacenan asumiendo que tienen valor para distintos públicos. El valor de los datos también cambia con el tiempo, ya sea volviéndose irrelevantes a medida que cambian las tendencias o mostrando patrones que tienen precedencia en el pasado. Tomemos el ejemplo de los datos de ventas. Los datos de ventas se utilizan para impulsar los cálculos de ingresos e impuestos, así como para calcular las comisiones de los empleados de ventas. Además, un análisis de las tendencias de ventas a lo largo del tiempo puede utilizarse para proyectar tendencias futuras y fijar objetivos de ventas. Aplicando técnicas de aprendizaje automático a los datos de ventas y correlacionándolos con datos aparentemente no relacionados, como las tendencias de las redes sociales o los datos meteorológicos, se pueden predecir tendencias únicas en las ventas. Una cosa importante que hay que recordar es que el valor de los datos puede depreciarse con el tiempo, dependiendo del problema que intentes resolver. Por ejemplo, el conjunto de datos que contiene los patrones meteorológicos de todo el mundo tiene mucho valor si estás analizando cómo cambian las tendencias climáticas a lo largo del tiempo. Sin embargo, si intentas predecir los patrones de venta de paraguas, los patrones meteorológicos de hace cinco años son menos relevantes.

La Figura 1-2 ilustra estos conceptos de big data.

Figura 1-2. Las seis V del big data

Infraestructura de datos elástica: el reto

Para que las organizaciones aprovechen el valor de los datos, la infraestructura de almacenamiento, procesamiento y análisis de datos, al tiempo que se adapta a las crecientes demandas de volumen y diversidad de formatos, se convierte en un elemento crítico. Esta infraestructura debe tener la capacidad no sólo de almacenar datos de cualquier formato, tamaño y forma, sino también de ingerir, procesar y consumir esta gran variedad de datos para extraer ideas valiosas.

Además, esta infraestructura tiene que seguir el ritmo de la proliferación de los datos y su creciente variedad, y ser capaz de escalar elásticamente a medida que crecen las necesidades de las organizaciones y aumenta la demanda de datos y conocimientos.

Fundamentos de la computación en nube

Términos como computación en nube e infraestructura elástica son tan omnipresentes hoy en día que se han convertido en parte de nuestro lenguaje natural, igual que "Pregúntale a Siri" o "¿Has buscado eso en Google?". Aunque no nos detenemos ni un segundo cuando oímos o utilizamos estos términos, ¿qué significan y por qué son los que marcan las tendencias de la transformación? Pongamos un poco la cabeza en las nubes y conozcamos los fundamentos de la computación en la nube antes de sumergirnos en los lagos de datos en la nube.

La computación en nube supone un gran cambio en la forma en que las organizaciones pensaban tradicionalmente sobre los recursos informáticos. En un enfoque tradicional, las organizaciones tenían departamentos de TI que compraban dispositivos o aparatos para ejecutar software. Estos dispositivos eran ordenadores portátiles o de sobremesa que se proporcionaban a los desarrolladores y trabajadores de la información, o eran centros de datos que los departamentos de TI mantenían y proporcionaban acceso al resto de la organización. Los departamentos de TI disponían de presupuestos para adquirir hardware y gestionaban el soporte con los proveedores de hardware. También disponían de procedimientos operativos y de la mano de obra asociada para instalar y actualizar los sistemas operativos y el software que se ejecutaban en este hardware. Esto planteaba algunos problemas: la continuidad de la empresa se veía amenazada por los fallos del hardware, el desarrollo y el uso del software se veían bloqueados por disponer de recursos limitados de un pequeño departamento de TI para gestionar la instalación y las actualizaciones y, lo más importante, no había forma de escalar el hardware, lo que impedía el crecimiento de la empresa.

Terminología de la computación en nube

En pocas palabras, la computación en nube puede entenderse en como hacer que tu departamento informático proporcione recursos informáticos a través de Internet. Los propios recursos informáticos de la nube son propiedad de un proveedor de la nube, que los gestiona y mantiene. La nube no es homogénea: también hay distintos tipos de nubes:

Nube pública

Los proveedores de nubes públicas incluyen Microsoft Azure, Amazon Web Services (AWS) y Google Cloud Platform (GCP), por nombrar algunos. Los proveedores de nubes públicas poseen centros de datos que alojan bastidores y bastidores de ordenadores en regiones de todo el mundo, y pueden tener recursos informáticos de distintas organizaciones aprovechando el mismo conjunto de infraestructuras, lo que se denomina un sistema multiarrendatario. Los proveedores de nubes públicas ofrecen garantías de aislamiento para asegurar que, aunque distintas organizaciones puedan utilizar la misma infraestructura, una organización no pueda acceder a los recursos de otra.

Nube privada

Proveedores como VMware ofrecen nubes privadas, en las que los recursos informáticos se alojan en centros de datos locales dedicados por completo a una organización. Como analogía, piensa en un proveedor de nube pública como un centro comercial, que puede albergar tiendas de bocadillos, panaderías, consultas de dentistas, clases de música y peluquerías en el mismo edificio físico. En cambio, una nube privada es como un edificio escolar en el que todo el edificio se utiliza sólo para la escuela. Los proveedores de nubes públicas también ofrecen versiones de nube privada de sus servicios.

Tu organización podría utilizar más de un proveedor de la nube para satisfacer sus necesidades, lo que se denomina un enfoque multicloud. Por otra parte, algunas organizaciones optan por lo que se denomina una nube híbrida, en la que tienen una nube privada en una infraestructura local y aprovechan un servicio de nube pública, y sus recursos se mueven entre los dos entornos según sea necesario. La Figura 1-3 ilustra estos conceptos.

Figura 1-3. Conceptos de nube

Hemos hablado de recursos informáticos, pero ¿qué son exactamente? Los recursos informáticos en la nube pertenecen a tres categorías diferentes:

Infraestructura como servicio, o IaaS

Para cualquier oferta, tiene que haber una infraestructura básica que consista en recursos que ofrezcan computación (procesamiento), almacenamiento (datos) y redes (conectividad). Las ofertas IaaS se refieren a recursos virtualizados de computación, almacenamiento y redes que puedes crear en la nube pública para construir tu propio servicio o solución aprovechando estos recursos.

Plataforma como servicio, o PaaS

Los recursos PaaS son esencialmente herramientas que ofrecen los proveedores, que los desarrolladores de aplicaciones pueden aprovechar para construir sus propias soluciones. Estos recursos PaaS pueden ser proporcionados por los proveedores de nubes públicas o por proveedores que ofrecen exclusivamente estas herramientas. Algunos ejemplos de recursos PaaS son las bases de datos operativas ofrecidas como servicio, como Azure Cosmos DB de Microsoft, Redshift de Amazon, MongoDB de Atlas, o el almacén de datos de Snowflake, que lo construye como servicio en todas las nubes públicas.

Software como servicio, o SaaS

Los recursos SaaS ofrecen a servicios de software listos para usar por una suscripción. Puedes utilizarlos en cualquier lugar sin tener que instalar nada en tus ordenadores, y aunque podrías aprovechar a tus desarrolladores para personalizar las soluciones, hay capacidades listas para usar que puedes empezar a utilizar de inmediato. Algunos ejemplos de servicios SaaS son Microsoft 365, Netflix, Salesforce y Adobe Creative Cloud.

Como analogía, supongamos que quieres cenar pizza. Si aprovecharas el IaaS, comprarías harina, levadura, queso y verduras y harías tu propia masa, añadirías ingredientes y hornearías tu pizza. Necesitas ser un experto cocinero para hacerlo bien. Si utilizaras PaaS, comprarías una pizza para llevar y la meterías en el horno. No necesitas ser un cocinero experto; sin embargo, necesitas saber lo suficiente para manejar un horno y vigilar que la pizza no se queme. Si utilizaras SaaS, llamarías a la pizzería local y te llevarían la pizza caliente a casa. No necesitas tener conocimientos de cocina, y tienes pizza lista para comer.

Propuesta de valor de la nube

Una de las primeras preguntas que siempre me hacen a los clientes y organizaciones que dan los primeros pasos en su viaje a la nube es por qué pasarse a la nube en primer lugar. Aunque el retorno de la inversión puede ser múltiple, el valor puede dividirse en tres categorías clave:

Menor TCO

El TCO se refiere al coste total de propiedad de la solución técnica que mantienes en , incluidos los costes del centro de datos, los costes del software y los salarios de las personas que hay que emplear para gestionar las operaciones. En casi todos los casos, salvo algunas excepciones, el coste total de propiedad es significativamente inferior para crear soluciones en la nube, en comparación con las soluciones que se crean internamente y se implementan en tu centro de datos local. Esto se debe a que puedes centrarte en contratar equipos de software para que escriban el código de tu lógica empresarial, mientras que los proveedores de la nube se encargan de todas las demás necesidades de hardware y software por ti. Algunos de los factores que contribuyen a esta reducción de costes son los siguientes:

Coste del hardware

Los proveedores de la nube poseen, construyen y dan soporte a los recursos de hardware a un coste menor que si tuvieras que construir y gestionar tus propios centros de datos, mantener el hardware y renovarlo cuando se agote el soporte. Además, con los avances realizados en hardware, los proveedores de la nube permiten acceder a hardware más nuevo mucho más rápido que si tuvieras que construir tus propios centros de datos.

Coste del software

Además de construir y mantener el hardware, uno de los principales esfuerzos de una organización de TI es dar soporte e implementar sistemas operativos y mantenerlos actualizados. Normalmente, estas actualizaciones implican tiempos de inactividad planificados que también pueden ser perjudiciales para tu organización. Los proveedores de la nube se encargan de este ciclo sin sobrecargar a tu departamento de TI. En casi todos los casos, estas actualizaciones se producen de forma abstracta para que no tengas que verte afectado por ningún tiempo de inactividad.

Paga por lo que utilizas

La mayoría de los servicios en la nube funcionan con un modelo de facturación basado en suscripciones, lo que significa que pagas por lo que utilizas. Si tienes recursos que se utilizan durante determinadas horas del día o determinados días de la semana, sólo pagas por ese tiempo, lo que resulta mucho menos caro que tener hardware todo el tiempo aunque no lo utilices.

Escala elástica

Los recursos que necesitas para tu empresa son muy dinámicos por naturaleza, y hay veces en que necesitas aprovisionar recursos para aumentos de uso planificados y no planificados. Cuando mantienes y ejecutas tu hardware, estás atado al hardware que tienes como techo para el crecimiento que puedes soportar en tu negocio. Los recursos en la nube tienen una escala elástica, y puedes irrumpir en la alta demanda aprovechando recursos adicionales con unos pocos clics.

Capacidad para seguir el ritmo de las innovaciones

Los proveedores de la nube innovan constantemente y añaden nuevos servicios y tecnologías a su oferta en función de lo que aprenden de múltiples clientes. Aprovechar los servicios y tecnologías más avanzados te ayuda a innovar más rápidamente para tus escenarios empresariales, en comparación con tener desarrolladores internos que podrían no tener la amplitud de conocimientos necesaria en todo el sector.

Arquitectura del lago de datos en la nube

Para entender cómo los lagos de datos en la nube ayudan a con las crecientes necesidades de datos de una organización, es importante que entendamos primero cómo funcionaban el procesamiento de datos y los conocimientos hace unas décadas. Las empresas solían pensar en los datos como algo que complementaba un problema empresarial que había que resolver. El enfoque se centraba en el problema empresarial e implicaba los siguientes pasos:

1. Identifica el problema a resolver.

2. Define una estructura para los datos que pueda ayudar a resolver el problema.

3. Recoge o genera los datos que se adhieran con la estructura.

4. Almacena los datos en una base de datos OLTP, como Microsoft SQL Server.

5. Utiliza otro conjunto de transformaciones (filtrado, agregaciones, etc.) para almacenar datos en bases de datos OLAP; aquí también se utilizan servidores SQL.

6. Construye cuadros de mando y consultas a partir de estas bases de datos OLAP para resolver tus problemas empresariales.

Por ejemplo, cuando una organización quería conocer las ventas, creaba una aplicación para que los vendedores introdujeran sus clientes potenciales, clientes y compromisos junto con los datos de ventas, y esta aplicación se apoyaba en una o varias bases de datos operativas. Podía haber una base de datos que almacenara la información de los clientes, otra que almacenara la información de los empleados de la fuerza de ventas, y una tercera que almacenara la información de las ventas haciendo referencia tanto a la base de datos de los clientes como a la de los empleados. En las instalaciones (denominadas "on prem") hay tres capas, como se muestra en la Figura 1-4:

Almacén de datos de empresa

Este es el componente donde se almacenan los datos. Contiene un componente de base de datos para almacenar los datos y un componente de metadatos para describir los datos almacenados en la base de datos.

Mercados de datos

Los marts de datos son un segmento del almacén de datos de la empresa que contiene bases de datos centradas en el negocio o en un tema, que tienen datos listos para servir a la aplicación. Los datos del almacén pasan por otro conjunto de transformaciones para almacenarse en los mercados de datos.

Capa de consumo/inteligencia empresarial (BI)

Consiste en diversas herramientas de visualización y consulta utilizadas por los analistas de BI para consultar los datos de los marts de datos (o del almacén) y generar perspectivas.

Figura 1-4. Almacén de datos local tradicional

Limitaciones de las soluciones de almacén de datos in situ

Aunque esto funciona bien para proporcionar información sobre el negocio, hay algunas limitaciones clave con esta arquitectura:

Datos muy estructurados

Esta arquitectura espera que los datos de estén altamente estructurados en todo momento. Como hemos visto en los ejemplos anteriores, esta suposición ya no es realista; los datos pueden proceder de cualquier fuente, como sensores IoT, fuentes de redes sociales y archivos de vídeo/audio, y pueden tener cualquier formato (JSON, CSV, PNG; completa esta lista con todos los formatos que conozcas). En la mayoría de los casos, no se puede imponer una estructura estricta.

Almacenes de datos en silos

Múltiples copias de los mismos datos se almacenan en almacenes de datos especializados para fines específicos. Esto resulta ser una desventaja porque el almacenamiento de estas copias de los mismos datos tiene un coste elevado, y el proceso de copiar datos de un lado a otro es caro y propenso a errores, lo que da lugar a versiones incoherentes de los datos en múltiples almacenes de datos mientras se copian los datos.

Aprovisionamiento de hardware para picos de utilización

Los almacenes de datos locales requieren que las organizaciones instalen y mantengan el hardware necesario para ejecutar estos servicios. Cuando esperas ráfagas de demanda (piensa en el cierre del presupuesto para el año fiscal o en la proyección de más ventas durante las vacaciones), tienes que planificar con antelación este pico de utilización y comprar el hardware, aunque ello signifique que parte de tu hardware permanecerá infrautilizado durante el resto del tiempo. Esto aumenta tu TCO. Ten en cuenta que esto es específicamente una limitación con respecto al hardware local, más que una diferencia entre la arquitectura de un almacén de datos y la de un lago de datos.

¿Qué es una arquitectura de lago de datos en la nube?

Como vimos en "¿Qué son los Big Data?", los escenarios de big data van mucho más allá de los confines de los almacenes de datos empresariales tradicionales. Las arquitecturas de los lagos de datos en la nube están pensadas para resolver exactamente estos problemas, ya que se diseñaron para satisfacer las necesidades del crecimiento explosivo de los datos y sus fuentes, sin hacer ninguna suposición sobre la fuente, los formatos, el tamaño o la calidad de los datos. En contraste con el enfoque de "primero los problemas" adoptado por los almacenes de datos tradicionales, los lagos de datos en la nube adoptan un enfoque de "primero los datos". En una arquitectura de lago de datos en la nube, todos los datos se consideran útiles, ya sea inmediatamente o para satisfacer una necesidad futura. El primer paso en una arquitectura de datos en la nube implica la ingesta de datos en su estado bruto y natural, sin ninguna restricción en cuanto a la fuente, el tamaño o el formato de los datos. Estos datos se almacenan en un lago de datos en la nube, un sistema de almacenamiento que es altamente escalable y puede almacenar cualquier tipo de datos. Estos datos en bruto tienen una calidad y un valor variables y necesitan más transformaciones para generar perspectivas de alto valor.

Como se muestra en la Figura 1-5, los sistemas de procesamiento de un lago de datos en la nube trabajan sobre los datos almacenados en el lago de datos y permiten a que el desarrollador de datos defina un esquema bajo demanda, es decir, que describa los datos en el momento del procesamiento. Estos sistemas de procesamiento operan entonces sobre los datos no estructurados de bajo valor para generar datos de alto valor que a menudo están estructurados y contienen perspectivas significativas. A continuación, estos datos estructurados de alto valor se cargan en un almacén de datos de la empresa para su consumo o se consumen directamente desde el lago de datos. Si todos estos conceptos te parecen muy complejos de entender, no te preocupes: entraremos en muchos detalles sobre este procesamiento en los Capítulos 2 y3.

Figura 1-5. Arquitectura de lago de datos en la nube

Ventajas de una arquitectura de lago de datos en la nube

A alto nivel, la arquitectura de lago de datos en la nube aborda las limitaciones de las arquitecturas tradicionales de almacén de datos de las siguientes maneras:

Sin restricciones en los datos

Como hemos visto, la arquitectura de un lago de datos consiste en herramientas diseñadas para ingerir, almacenar y procesar todo tipo de datos sin imponer ninguna restricción sobre la fuente, el tamaño o la estructura de los datos. Además, estos sistemas están diseñados para trabajar con datos que entran en el lago de datos a cualquier velocidad: datos en tiempo real emitidos continuamente, así como volúmenes de datos ingeridos por lotes de forma programada. Además, el almacenamiento del lago de datos tiene un coste extremadamente bajo, lo que nos permite almacenar todos los datos por defecto sin preocuparnos de las facturas. Recuerda cómo antes tenías que pensártelo dos veces antes de hacer fotos con aquellas viejas cámaras de rollo de película, pero hoy en día haces clic sin pensártelo dos veces con la cámara de tu teléfono.

Una sola capa de almacenamiento sin silos

Ten en cuenta que en una arquitectura de lago de datos en la nube, tu procesamiento tiene lugar en los datos del mismo almacén, por lo que ya no necesitas almacenes de datos especializados para fines especializados. Esto no sólo reduce tus costes, sino que también evita los errores que conlleva mover los datos de un lado a otro a través de diferentes sistemas de almacenamiento.

Flexibilidad para ejecutar diversos cálculos en el mismo almacén de datos

Como puedes ver, una arquitectura de lago de datos en la nube desacopla intrínsecamente el cálculo y el almacenamiento, de modo que mientras la capa de almacenamiento sirve como repositorio sin silos, puedes ejecutar diversas herramientas computacionales de procesamiento de datos en la misma capa de almacenamiento. Por ejemplo, puedes aprovechar la misma capa de almacenamiento de datos para realizar consultas de BI similares a las de un almacén de datos, aprendizaje automático avanzado y cálculos de ciencia de datos, o incluso cálculos específicos de un dominio, como la informática de alto rendimiento, como el procesamiento de medios o el análisis de datos sísmicos.

Paga por lo que utilizas

Los servicios y herramientas en la nube siempre están diseñados para escalar elásticamente hacia arriba y hacia abajo bajo demanda, y puedes crear y eliminar sistemas de procesamiento bajo demanda. Esto significa que para esas ráfagas de demanda durante las vacaciones o el cierre del presupuesto, puedes optar por poner en marcha estos sistemas sin tenerlos el resto del año. Esto reduce drásticamente el coste total de propiedad.

Escala de forma independiente el cálculo y el almacenamiento

En una arquitectura de lago de datos en la nube, la informática y el almacenamiento son tipos de recursos diferentes, y pueden escalarse independientemente, lo que te permite escalar tus recursos en función de las necesidades. Los sistemas de almacenamiento en la nube son muy baratos y te permiten almacenar una gran cantidad de datos sin arruinarte. Los recursos informáticos son tradicionalmente más caros que el almacenamiento; sin embargo, pueden iniciarse o detenerse bajo demanda, ofreciendo así economía a escala.

Nota

Técnicamente, también es posible escalar el cálculo y el almacenamiento de forma independiente en una arquitectura Apache Hadoop local. Sin embargo, esto implica una cuidadosa consideración de las opciones de hardware que están optimizadas específicamente para el cálculo y el almacenamiento y tienen una conectividad de red optimizada. Esto es exactamente lo que ofrecen los proveedores de la nube con sus servicios de infraestructura en la nube. Muy pocas organizaciones tienen este tipo de experiencia y optan explícitamente por ejecutar sus servicios in situ.

Esta flexibilidad para procesar todo tipo de datos de forma rentable ayuda a las organizaciones a darse cuenta del valor de los datos y a convertirlos en valiosos conocimientos transformadores.

Definir tu viaje al lago de datos en la nube

He hablado con cientos de clientes sobre sus escenarios de análisis de big data y les he ayudado con partes de sus viajes de lago de datos en la nube. Estos clientes tienen diferentes motivaciones y problemas que resolver: algunos clientes son nuevos en la nube y quieren dar sus primeros pasos con los lagos de datos, otros tienen un lago de datos implementado en la nube que soporta algunos escenarios básicos y no están seguros de qué hacer a continuación, algunos son clientes nativos de la nube que quieren empezar directamente con los lagos de datos como parte de sus arquitecturas de aplicaciones, y otros ya tienen una implementación madura de sus lagos de datos en la nube y quieren aprovechar el poder de los datos para ofrecer el siguiente nivel de valor diferenciado en comparación con sus pares y competidores. Si tuviera que resumir lo que he aprendido de todas estas conversaciones, básicamente se reduce a dos cosas clave:

• Independientemente de tu nivel de madurez en la nube, diseña tu lago de datos para el futuro de la empresa.

• ¡Haz tus elecciones de implementación basándote en lo que necesitas inmediatamente!

Puede que pienses que esto suena demasiado obvio y demasiado genérico. Sin embargo, en el resto del libro, observarás que el marco y la orientación que prescribo para diseñar y optimizar los lagos de datos en la nube van a suponer que te estás cotejando constantemente con estas dos preguntas:

1. ¿Cuál es el problema empresarial que impulsa las decisiones sobre el lago de datos?

2. Cuando resuelva este problema, ¿qué más puedo hacer para diferenciar mi negocio con el lago de datos?

Te daré un ejemplo concreto. Un escenario común que lleva a los clientes a implantar un lago de datos en la nube es que el hardware local que soporta su clúster Hadoop está llegando al final de su vida útil. Este clúster Hadoop es utilizado principalmente por la plataforma de datos y los equipos de BI para crear cuadros de mando y cubos con datos obtenidos de sus sistemas de almacenamiento transaccional locales, y la empresa necesita decidir si comprar más hardware y seguir manteniendo su hardware local o invertir en este lago de datos en la nube del que todo el mundo habla, donde la promesa es escala elástica, menor coste de propiedad, un mayor conjunto de funciones y servicios que pueden aprovechar, y todas las demás bondades que vimos en la sección anterior. Cuando estos clientes deciden pasarse a la nube, tienen un reloj en marcha que deben respetar cuando su hardware llegue al final de su vida útil, así que eligen una estrategia de "levantar y cambiar" que toma su implementación local existente y la traslada a la nube. Es un planteamiento perfectamente correcto, sobre todo si se tiene en cuenta que se trata de sistemas de producción que cumplen una función empresarial crítica. Sin embargo, estos clientes pronto se dan cuenta de tres cosas:

• Se necesita mucho esfuerzo incluso para levantar y desplazar su aplicación.

• Si se dan cuenta del valor de la nube y quieren añadir más escenarios, se ven limitados por sus elecciones de diseño, como los modelos de seguridad, la organización de los datos, etc., que originalmente suponían un conjunto de escenarios de BI ejecutándose en el lago de datos.

• En algunos casos, las arquitecturas lift-and-shift acaban siendo más caras tanto en coste como en mantenimiento, anulando el propósito original.

Es sorprendente, ¿verdad? Estas sorpresas se deben principalmente a las diferencias de arquitectura entre los sistemas locales y en la nube. En un clúster Hadoop local, la informática y el almacenamiento están colocados y estrechamente acoplados, mientras que en la nube, la idea es tener una capa de almacenamiento de objetos/almacenamiento de lago de datos, como Amazon S3, Azure Data Lake Store (ADLS) y Google Cloud Storage (GCS), y disponer de una plétora de opciones informáticas disponibles como IaaS (aprovisionar máquinas virtuales y ejecutar tu propio software) o PaaS (por ejemplo, Azure HDInsight, Amazon EMR, etc.), como se muestra en la Figura 1-6. En la nube, tu solución de lago de datos es esencialmente una estructura que construyes con piezas de Lego, que pueden ser ofertas IaaS, PaaS o SaaS.

Figura 1-6. Arquitecturas locales frente a arquitecturas en la nube

Ya vimos las ventajas de las arquitecturas desacopladas de cálculo y almacenamiento en términos de escalado independiente y reducción de costes; sin embargo, esto requiere que la arquitectura y el diseño de tu lago de datos en la nube respeten esta arquitectura desacoplada. Por ejemplo, en la implementación del lago de datos en la nube, los sistemas informáticos hablan con los sistemas de almacenamiento a través de los sistemas de red, en lugar de realizar llamadas locales. Si no optimizas esto, tanto tu coste como tu rendimiento se verán afectados. Del mismo modo, una vez que hayas completado la implementación de tu lago de datos para tus escenarios principales de BI, ahora puedes obtener más valor de tu lago de datos habilitando más escenarios, trayendo conjuntos de datos dispares o realizando más análisis exploratorios de ciencia de datos sobre los datos de tu lago. Al mismo tiempo, debes asegurarte de que un trabajo exploratorio de ciencia de datos no elimine accidentalmente los conjuntos de datos que alimentan el cuadro de mando que tu vicepresidente de ventas quiere ver cada mañana. Tienes que asegurarte de que la organización de los datos y los modelos de seguridad que tienes implantados garantizan este aislamiento y control de acceso.

Vinculando estas increíbles oportunidades con la motivación original que tenías para trasladarte a la nube, que era que tus servidores locales llegaran al final de su vida útil, tienes que formular un plan que te ayude a cumplir tus plazos al tiempo que te prepara para el éxito en la nube. Tu paso al lago de datos en la nube implica dos objetivos:

• Apagar tus sistemas locales

• Preparándote para el éxito en la nube

La mayoría de los clientes acaban centrándose sólo en el primer objetivo y se sumen en una enorme deuda técnica antes de tener que volver a diseñar sus aplicaciones. Cuando pienses en una arquitectura de lago de datos en la nube, asegúrate de que tienes lo siguiente como objetivo:

• Migra tu lago de datos a la nube.

• Moderniza tu lago de datos para adaptarlo a la arquitectura de la nube.

Estos dos objetivos irán de la mano para ayudarte a identificar una arquitectura que sea robusta para la escala y las necesidades crecientes de tu empresa.

Para comprender cómo lograr ambos objetivos, tendrás que entender qué es la arquitectura de la nube, cuáles son las consideraciones de diseño para la implementación y cómo optimizar tu lago de datos para la escala y el rendimiento. Abordaremos estas cuestiones en detalle en los Capítulos 2-4. También nos centraremos en proporcionar un marco que te ayude a considerar los diversos aspectos de tu viaje al lago de datos en la nube.

Resumen

En este capítulo, empezamos hablando de la propuesta de valor de los datos y de los conocimientos transformadores que pueden dar un vuelco a las organizaciones. También hemos construido una comprensión fundamental de la computación en la nube y las diferencias entre un almacén de datos tradicional y una arquitectura de lago de datos en la nube. Por último, analizamos qué son los big data, la nube y los lagos de datos. Dada la diferencia entre las arquitecturas locales y en la nube, hicimos hincapié en la importancia de un cambio de mentalidad que, a su vez, define un cambio de arquitectura a la hora de diseñar un lago de datos en la nube. Este cambio de mentalidad es lo único que te imploro que hagas mientras profundizamos en los detalles de las arquitecturas de los lagos de datos en la nube y sus consideraciones de implementación en los próximos capítulos.