El Lago de Grandes Datos de la Empresa

Capítulo 1. Introducción a los lagos de datos

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

La toma de decisiones basada en datos está cambiando nuestra forma de trabajar y de vivir. Desde la ciencia de datos, el aprendizaje automático y la analítica avanzada hasta los cuadros de mando en tiempo real, los responsables de la toma de decisiones exigen datos que les ayuden a tomar decisiones. Empresas como Google, Amazon y Facebook son gigantes de los datos que se están apoderando de los negocios tradicionales aprovechando los datos. Las organizaciones de servicios financieros y las compañías de seguros siempre han estado impulsadas por los datos, con los cuantos y el comercio automatizado a la cabeza. El Internet de las Cosas (IoT) está cambiando la fabricación, el transporte, la agricultura y la sanidad. Desde los gobiernos y las empresas de todos los sectores verticales hasta las organizaciones sin ánimo de lucro y las instituciones educativas, los datos están cambiando las reglas del juego. La inteligencia artificial y el aprendizaje automático están impregnando todos los aspectos de nuestras vidas. El mundo se está dando un atracón de datos por el potencial que representan. Incluso tenemos un término para este atracón: big data, definido por Doug Laney de Gartner en términos de las tres V (volumen, variedad y velocidad), a las que más tarde añadió una cuarta y, en mi opinión, la más importante V: la capacidad.

Con tanta variedad, volumen y velocidad, los antiguos sistemas y procesos ya no son capaces de soportar las necesidades de datos de la empresa. La veracidad es un problema aún mayor para la analítica avanzada y la inteligencia artificial, donde el principio de "GIGO" (basura dentro = basura fuera) es aún más crítico, porque es prácticamente imposible saber si los datos eran malos y causaron malas decisiones en los modelos estadísticos y de aprendizaje automático, o si el modelo era malo.

Para apoyar estos esfuerzos y afrontar estos retos, se está produciendo una revolución en la gestión de datos en torno a cómo se almacenan, procesan, gestionan y proporcionan los datos a los responsables de la toma de decisiones. La tecnología de big data está permitiendo una escalabilidad y eficiencia de costes órdenes de magnitud superiores a lo que es posible con la infraestructura tradicional de gestión de datos. El autoservicio está tomando el relevo de los enfoques cuidadosamente elaborados y laboriosos del pasado, en los que ejércitos de profesionales de TI creaban almacenes de datos y marts de datos bien gestionados, pero tardaban meses en realizar cualquier cambio.

El lago de datos es un nuevo y atrevido enfoque que aprovecha el poder de la tecnología de big data y lo combina con la agilidad del autoservicio. En la actualidad, la mayoría de las grandes empresas han implementado o están implementando lagos de datos.

Este libro se basa en conversaciones con más de cien organizaciones, desde las nuevas empresas impulsadas por los datos, como Google, LinkedIn y Facebook, hasta gobiernos y empresas corporativas tradicionales, sobre sus iniciativas de lagos de datos, proyectos analíticos, experiencias y buenas prácticas. El libro está dirigido a ejecutivos y profesionales de TI que estén considerando la posibilidad de construir un lago de datos, estén en proceso de construirlo o ya lo tengan pero estén luchando para que sea productivo y se adopte ampliamente.

¿Qué es un lago de datos? ¿Por qué lo necesitamos? ¿En qué se diferencia de lo que ya tenemos? Este capítulo ofrece un breve resumen que se ampliará en detalle en los capítulos siguientes. En un intento de mantener el resumen sucinto, no voy a explicar y explorar cada término y concepto en detalle aquí, sino que guardaré la discusión en profundidad para capítulos posteriores.

La toma de decisiones basada en datos está de moda. Desde la ciencia de datos, el aprendizaje automático y la analítica avanzada hasta los cuadros de mando en tiempo real, los responsables de la toma de decisiones exigen datos que les ayuden a tomar decisiones. Estos datos necesitan un hogar, y el lago de datos es la solución preferida para crear ese hogar. El término fue inventado y descrito por primera vez por James Dixon, CTO de Pentaho, que escribió en su blog: "Si piensas en un datamart como un almacén de agua embotellada -limpiada y envasada y estructurada para su fácil consumo-, el lago de datos es una gran masa de agua en un estado más natural. El contenido del lago de datos fluye desde una fuente para llenar el lago, y varios usuarios del lago pueden venir a examinarlo, sumergirse en él o tomar muestras". He puesto en cursiva los puntos críticos, que son:

• Los datos están en su forma y formato originales( datosnaturales o brutos).

• Los datos son utilizados por varios usuarios (es decir, una gran comunidad de usuarios tiene acceso a ellos).

Este libro trata de cómo construir un lago de datos que ponga los datos brutos (y procesados) a disposición de una gran comunidad de usuarios de analistas empresariales, en lugar de utilizarlos sólo para proyectos impulsados por TI. La razón para poner los datos brutos a disposición de los analistas es que puedan realizar análisis de autoservicio. El autoservicio ha sido una importante megatendencia hacia la democratización de los datos. Comenzó en el punto de uso con herramientas de visualización de autoservicio como Tableau y Qlik (a veces llamadas herramientas de descubrimiento de datos ) que permiten a los analistas analizar los datos sin tener que obtener ayuda de TI. La tendencia al autoservicio continúa con herramientas de preparación de datos que ayudan a los analistas a dar forma a los datos para el análisis, y herramientas de catálogo que ayudan a los analistas a encontrar los datos que necesitan y herramientas de ciencia de datos que ayudan a realizar análisis avanzados. Para realizar análisis aún más avanzados, generalmente denominados ciencia de datos, una nueva clase de usuarios llamados científicos de datos también suelen hacer de un lago de datos su principal fuente de datos.

Por supuesto, un gran reto del autoservicio es la gobernanza y la seguridad de los datos. Todo el mundo está de acuerdo en que los datos deben mantenerse seguros, pero en muchas industrias reguladas, hay políticas de seguridad de datos prescritas que deben aplicarse y es ilegal dar a los analistas acceso a todos los datos. Incluso en algunas industrias no reguladas, se considera una mala idea. La pregunta es: ¿cómo ponemos los datos a disposición de los analistas sin infringir las normativas internas y externas de cumplimiento de datos? Esto se denomina a veces democratización de los datos y se tratará en detalle en capítulos posteriores.

Madurez del lago de datos

El lago de datos es un concepto relativamente nuevo, por lo que resulta útil definir algunas de las etapas de madurez que se pueden observar y articular claramente en las diferencias entre estas etapas:

• Un charco de datos es básicamente un mercado de datos de un solo propósito o un solo proyecto construido con tecnología de big data. Suele ser el primer paso en la adopción de la tecnología de big data. Los datos de un charco de datos se cargan con el propósito de un único proyecto o equipo. Suele ser bien conocido y comprendido, y la razón por la que se utiliza la tecnología de big data en lugar del almacén de datos tradicional es para abaratar costes y ofrecer un mejor rendimiento.

• Un estanque de datos es una colección de estanques de datos. Puede ser como un almacén de datos mal diseñado, que es efectivamente una colección de data marts colocados, o puede ser una descarga de un almacén de datos existente. Aunque unos costes tecnológicos más bajos y una mejor escalabilidad son ventajas claras y atractivas, estas construcciones siguen requiriendo un alto nivel de participación de TI. Además, los estanques de datos limitan los datos sólo a los que necesita el proyecto, y utilizan esos datos sólo para el proyecto que los requiere. Dados los elevados costes de TI y la limitada disponibilidad de datos, los estanques de datos no nos ayudan realmente con los objetivos de democratizar el uso de los datos o impulsar el autoservicio y la toma de decisiones basada en datos para los usuarios empresariales.

• Un lago de datos se diferencia de un estanque de datos en dos aspectos importantes. En primer lugar, admite el autoservicio, en el que los usuarios empresariales pueden encontrar y utilizar los conjuntos de datos que deseen sin tener que depender de la ayuda del departamento de TI. En segundo lugar, su objetivo es contener datos que los usuarios empresariales puedan desear aunque no haya ningún proyecto que los requiera en ese momento.

• Un océano de datos amplía el autoservicio de datos y la toma de decisiones basada en datos a todos los datos de la empresa, estén donde estén, independientemente de que se hayan cargado o no en el lago de datos.

La Figura 1-1 ilustra las diferencias entre estos conceptos. A medida que la madurez pasa de un charco a un estanque, de un lago a un océano, la cantidad de datos y el número de usuarios crecen, a veces de forma espectacular. El patrón de uso pasa de una implicación de TI de alto contacto a un autoservicio, y los datos se expanden más allá de lo necesario para los proyectos inmediatos.

Figura 1-1. Las cuatro etapas de la madurez

La diferencia clave entre el estanque de datos y el lago de datos es el enfoque. Los estanques de datos ofrecen una alternativa tecnológica menos costosa y más escalable a los almacenes de datos relacionales y los data marts existentes. Mientras que estos últimos se centran en ejecutar consultas rutinarias, listas para la producción, los lagos de datos permiten a los usuarios empresariales aprovechar los datos para tomar sus propias decisiones, realizando análisis ad hoc y experimentando con una variedad de nuevos tipos de datos y herramientas, como se ilustra en la Figura 1-2.

Antes de entrar en lo que se necesita para crear con éxito un lago de datos, veamos más de cerca las dos etapas de madurez que conducen a él.

Figura 1-2. Propuesta de valor del lago de datos

Charcos de datos

Los "charcos" de datos suelen construirse para un pequeño equipo centrado o un caso de uso especializado. Estos "charcos" son colecciones de datos de tamaño modesto, propiedad de un solo equipo, construidos frecuentemente en la nube por unidades de negocio que utilizan TI en la sombra. En la era del almacenamiento de datos, cada equipo estaba acostumbrado a construir un mercado de datos relacional para cada uno de sus proyectos. El proceso de construcción de un charco de datos es muy similar, salvo que utiliza tecnología de big data. Normalmente, los charcos de datos se construyen para proyectos que requieren la potencia y la escala de los big data. Muchos proyectos de análisis avanzados, como los centrados en la rotación de clientes o el mantenimiento predictivo, entran en esta categoría.

A veces, los charcos de datos se construyen para ayudar al departamento informático con procesos automatizados de cálculo y datos intensivos, como la descarga de extracción, transformación y carga (ETL), que se tratará en detalle en capítulos posteriores, donde todo el trabajo de transformación se traslada desde el almacén de datos o las costosas herramientas ETL a una plataforma de big data. Otro uso común de es servir a un solo equipo proporcionando un área de trabajo, llamada sandbox, en la que los científicos de datos pueden experimentar.

Los charcos de datos suelen tener un alcance reducido y una variedad limitada de datos; están poblados por pequeños flujos de datos dedicados, y construirlos y mantenerlos requiere un equipo muy técnico o una gran implicación de TI.

Estanques de datos

Un estanque de datos es una colección de estanques de datos. Del mismo modo que puedes pensar en los charcos de datos como mercados de datos construidos con tecnología de big data, puedes pensar en un estanque de datos como un almacén de datos construido con tecnología de big data. Puede surgir orgánicamente, a medida que se añaden más estanques a la plataforma de big data. Otro enfoque popular para crear un estanque de datos es como descarga de un almacén de datos. A diferencia de la descarga ETL, que utiliza la tecnología de big data para realizar parte del procesamiento necesario para poblar un almacén de datos, la idea aquí es tomar todos los datos del almacén de datos y cargarlos en una plataforma de big data. La visión suele ser deshacerse finalmente del almacén de datos para ahorrar costes y mejorar el rendimiento, ya que las plataformas de big data son mucho menos caras y mucho más escalables que las bases de datos relacionales. Sin embargo, la mera descarga del almacén de datos no da a los analistas acceso a los datos en bruto. Como se siguen manteniendo la arquitectura y la gobernanza rigurosas aplicadas al almacén de datos, la organización no puede abordar todos los retos del almacén de datos, como los ciclos de cambio largos y costosos, las transformaciones complejas y la codificación manual como base de todos los informes. Por último, a los analistas no les suele gustar pasar de un almacén de datos afinado, con consultas a la velocidad del rayo, a una plataforma de big data mucho menos predecible, donde las consultas por lotes enormes pueden ejecutarse más rápido que en un almacén de datos, pero las consultas más típicas de menor tamaño pueden tardar minutos. La Figura 1-3 ilustra algunas de las limitaciones típicas de los estanques de datos: falta de previsibilidad, agilidad y acceso a los datos originales sin tratar.

Figura 1-3. Los inconvenientes de la descarga del almacén de datos

Crear un lago de datos con éxito

¿Qué hace falta para que un lago de datos tenga éxito? Como con cualquier proyecto, es imprescindible alinearlo con la estrategia empresarial y contar con el patrocinio ejecutivo y una amplia participación. Además, basándonos en conversaciones con docenas de empresas que están implementando lagos de datos con distintos niveles de éxito, se pueden identificar tres requisitos previos clave:

• La plataforma adecuada

• Los datos correctos

• Las interfaces adecuadas

La plataforma adecuada

Las tecnologías de big data como Hadoop y las soluciones en la nube como Amazon Web Services (AWS), Microsoft Azure y Google Cloud Platform son las plataformas más populares para un lago de datos. Estas tecnologías comparten varias ventajas importantes:

Volumen

Estas plataformas se diseñaron en para escalarse, es decir, para escalarse indefinidamente sin una degradación significativa del rendimiento.

Coste

Siempre hemos tenido la capacidad de almacenar muchos datos en sistemas de almacenamiento bastante baratos, como cintas, discos WORM y discos duros. Pero no fue hasta las tecnologías de big data que tuvimos la capacidad de almacenar y procesar enormes volúmenes de datos de forma tan barata, normalmente por una décima o una centésima parte del coste de una base de datos relacional comercial.

Variedad

Estas plataformas utilizan sistemas de archivos o almacenes de objetos que les permiten almacenar todo tipo de archivos: Hadoop HDFS, MapR FS, el Servicio de Almacenamiento Simple (S3) de AWS, etc. A diferencia de una base de datos relacional, que requiere que la estructura de datos esté predefinida(esquema en escritura), a un sistema de archivos o a un almacén de objetos no le importa realmente lo que escribas. Por supuesto, para procesar los datos de forma significativa necesitas conocer su esquema, pero eso sólo ocurre cuando utilizas los datos. Este enfoque se denomina esquema en lectura y es una de las ventajas importantes de las plataformas de big data, permitiendo lo que se denomina "ingestión sin fricción". En otras palabras, los datos pueden cargarse sin ningún tipo de procesamiento, a diferencia de lo que ocurre en una base de datos relacional, donde los datos no pueden cargarse hasta que se convierten al esquema y formato esperados por la base de datos.

A prueba de futuro

Como nuestras necesidades y el mundo en que vivimos están en constante cambio, es fundamental asegurarse de que los datos de que tenemos puedan utilizarse para ayudarnos con nuestras necesidades futuras. Hoy en día, si los datos se almacenan en una base de datos relacional, sólo se puede acceder a ellos desde esa base de datos relacional. En cambio, Hadoop y otras plataformas de big data son muy modulares. El mismo archivo puede ser utilizado por varios motores de procesamiento y programas: desde consultas Hive (Hive proporciona una interfaz SQL a los archivos Hadoop) a scripts Pig o trabajos Spark y MapReduce personalizados, todo tipo de herramientas y sistemas diferentes pueden acceder a los mismos archivos y utilizarlos. Dado que la tecnología de big data evoluciona rápidamente, esto permite confiar en que cualquier proyecto futuro podrá seguir accediendo a los datos del lago de datos.

Los datos correctos

La mayoría de los datos que recogen las empresas hoy en día se tiran. Un pequeño porcentaje se agrega y se guarda en un almacén de datos durante unos años, pero la mayoría de los datos operativos detallados, los datos generados por máquinas y los datos históricos antiguos se agregan o se tiran por completo. Esto dificulta el análisis. Por ejemplo, si un analista reconoce el valor de unos datos que tradicionalmente se desechaban, puede tardar meses o incluso años en acumular suficiente historial de esos datos para hacer análisis significativos. La promesa del lago de datos, por tanto, es poder almacenar tantos datos como sea posible para su uso futuro.

Así pues, el lago de datos es algo así como una hucha(Figura 1-4): a menudo no sabes para qué guardas los datos, pero los quieres por si algún día los necesitas. Además, como no sabes cómo vas a utilizar los datos, no tiene sentido convertirlos o tratarlos antes de tiempo. Puedes pensar en ello como si viajaras con tu hucha por distintos países, añadiendo dinero en la moneda del país en el que te encuentres en ese momento y manteniendo el contenido en sus monedas nativas hasta que decidas en qué país quieres gastar el dinero; entonces puedes convertirlo todo a esa moneda, en lugar de convertir innecesariamente tus fondos (y pagar comisiones de conversión) cada vez que cruces una frontera. En resumen, el objetivo es guardar tantos datos como sea posible en su formato nativo.

Figura 1-4. Un lago de datos es como una hucha, que te permite conservar los datos en su formato nativo o crudo

Otro reto a la hora de obtener los datos adecuados son los silos de datos. Los distintos departamentos pueden acaparar sus datos, tanto porque es difícil y caro proporcionarlos como porque a menudo existe una reticencia política y organizativa a compartirlos. En una empresa típica, si un grupo necesita datos de otro grupo, tiene que explicar qué datos necesita y luego el grupo propietario de los datos tiene que implementar trabajos ETL que extraigan y empaqueten los datos requeridos. Esto es caro, difícil y lleva mucho tiempo, por lo que los equipos pueden retrasar al máximo las solicitudes de datos y luego tardar todo lo que puedan en proporcionarlos. Este trabajo extra se utiliza a menudo como excusa para no compartir los datos.

Con un lago de datos, como el lago consume datos en bruto mediante una ingestión sin fricciones (básicamente, se ingieren tal cual sin ningún procesamiento), ese reto (y esa excusa) desaparece. Un lago de datos bien gestionado también está centralizado y ofrece un proceso transparente a las personas de toda la organización sobre cómo obtener los datos, por lo que la propiedad se convierte en una barrera mucho menor.

La interfaz adecuada

Una vez que tenemos la plataforma adecuada y hemos cargado los datos, llegamos a los aspectos más difíciles del lago de datos, donde la mayoría de las empresas fracasan: elegir la interfaz adecuada. Para conseguir una amplia adopción y cosechar los beneficios de ayudar a los usuarios empresariales a tomar decisiones basadas en datos, las soluciones que ofrecen las empresas deben ser de autoservicio, para que sus usuarios puedan encontrar, comprender y utilizar los datos sin necesidad de ayuda de TI. El departamento de TI simplemente no podrá escalar para dar soporte a una comunidad de usuarios tan grande y a una variedad de datos tan grande.

Hay dos aspectos a la hora de permitir el autoservicio: proporcionar datos con el nivel adecuado de conocimientos para los usuarios, y garantizar que los usuarios puedan encontrar los datos adecuados.

Proporcionar datos con el nivel adecuado de conocimientos

Para conseguir una amplia adopción del lago de datos, queremos que lo utilicen desde los científicos de datos hasta los analistas empresariales. Sin embargo, al considerar audiencias tan divergentes con necesidades y niveles de destreza diferentes, tenemos que tener cuidado de poner los datos adecuados a disposición de las poblaciones de usuarios adecuadas.

Por ejemplo, los analistas no suelen tener las habilidades necesarias para utilizar datos brutos. Los datos brutos suelen tener demasiados detalles, son demasiado granulares y, con frecuencia, presentan demasiados problemas de calidad como para poder utilizarlos fácilmente. Por ejemplo, si recopilamos datos de ventas de distintos países que utilizan aplicaciones diferentes, esos datos vendrán en formatos diferentes con campos diferentes (por ejemplo, un país puede tener impuestos sobre las ventas mientras que otro no) y unidades de medida diferentes (por ejemplo, lb frente a kg, $ frente a €).

Para que los analistas puedan utilizar estos datos, hay que armonizarlos -ponerlosen el mismo esquema con los mismos nombres de campo y unidades de medida- y con frecuencia también agregarlos a las ventas diarias por producto o por cliente. En otras palabras, los analistas quieren platos preparados "cocinados", no datos brutos.

Los científicos de datos, en cambio, son todo lo contrario. Para ellos, los datos cocinados a menudo pierden las pepitas de oro que buscan. Por ejemplo, si quieren ver con qué frecuencia se compran juntos dos productos, pero la única información que pueden obtener son los totales diarios por producto, los científicos de datos se quedarán atascados. Son como chefs que necesitan ingredientes crudos para crear sus obras maestras culinarias o analíticas.

En este libro veremos cómo satisfacer necesidades divergentes estableciendo varias zonas, o áreas que contienen datos que cumplen requisitos particulares. Por ejemplo, la zona bruta o de aterrizaje contiene los datos originales ingeridos en el lago, mientras que la zona de producción u oro contiene datos gobernados de alta calidad. Echaremos un vistazo rápido a las zonas en "Organizar el lago de datos"; encontrarás un análisis más detallado en el Capítulo 7.

Llegar a los datos

La mayoría de las empresas con las que he hablado se están decantando por el paradigma de la "compra de datos", en el que los analistas utilizan una interfaz al estilo de Amazon.com para encontrar, comprender, valorar, anotar y consumir datos. Las ventajas de este enfoque son múltiples, entre ellas:

Una interfaz familiar

La mayoría de la gente está familiarizada con las compras online y se siente cómoda buscando con palabras clave y utilizando facetas, valoraciones y comentarios, por lo que no necesitan formación o ésta es mínima.

Búsqueda facetada

Los motores de búsqueda están optimizados para la búsqueda facetada. La búsqueda facetada es muy útil cuando el número de posibles resultados de la búsqueda es grande y el usuario intenta centrarse en el resultado correcto. Por ejemplo, si buscaras tostadoras en Amazon(Figura 1-5), las facetas enumerarían los fabricantes, si la tostadora acepta bagels, cuántas rebanadas debe tostar, etc. Del mismo modo, cuando los usuarios buscan los conjuntos de datos adecuados, las facetas pueden ayudarles a especificar qué atributos les gustaría que tuviera el conjunto de datos, el tipo y el formato del conjunto de datos, el sistema que lo contiene, el tamaño y la frescura del conjunto de datos, el departamento que lo posee, qué derechos tiene y cualquier otra serie de características útiles.

Clasificación y ordenación

La capacidad de presentar y clasificar activos de datos, ampliamente admitida por los motores de búsqueda, es importante para elegir el activo adecuado basándose en criterios específicos.

Búsqueda contextual

A medida que los catálogos sean más inteligentes, la capacidad de encontrar activos de datos utilizando una comprensión semántica de lo que buscan los analistas de será más importante. Por ejemplo, un vendedor que busca clientes puede estar buscando realmente clientes potenciales, mientras que una persona de soporte técnico que busca clientes puede estar buscando realmente clientes existentes.

Figura 1-5. Una interfaz de compra online

El pantano de los datos

Aunque los lagos de datos siempre empiezan con buenas intenciones, a veces toman un rumbo equivocado y acaban siendo pantanos de datos. Un pantano de datos es un estanque de datos que ha crecido hasta alcanzar el tamaño de un lago de datos, pero que no ha conseguido atraer a una amplia comunidad de analistas, normalmente debido a la falta de autoservicio y de facilidades de gobierno. En el mejor de los casos, el pantano de datos se utiliza como un lago de datos, y en el peor, no se utiliza en absoluto. A menudo, mientras varios equipos utilizan pequeñas zonas del lago para sus proyectos (la zona blanca del estanque de datos de la Figura 1-6), la mayoría de los datos son oscuros, no están documentados y son inutilizables.

Figura 1-6. Un pantano de datos

Cuando los lagos de datos aparecieron por primera vez en escena, muchas empresas se apresuraron a comprar clusters Hadoop y llenarlos de datos en bruto, sin una comprensión clara de cómo se utilizarían. Esto condujo a la creación de enormes pantanos de datos con millones de archivos que contenían petabytes de datos y ninguna forma de darles sentido.

Sólo los usuarios más sofisticados eran capaces de navegar por los pantanos, normalmente excavando pequeños charcos que ellos y sus equipos podían aprovechar. Además, las normas de gobernanza impedían abrir los pantanos a un público amplio sin proteger los datos sensibles. Como nadie podía saber dónde estaban los datos sensibles, no se podía dar acceso a los usuarios y los datos permanecían en gran medida inutilizables y sin usar. Un científico de datos compartió conmigo su experiencia de cómo su empresa construyó un lago de datos, encriptó todos los datos del lago para protegerlos, y exigió a los científicos de datos que demostraran que los datos que querían no eran sensibles antes de desencriptarlos y dejarles utilizarlos. Esto resultó ser una trampa: como todo estaba encriptado, el científico de datos con el que hablé no podía encontrar nada, y mucho menos demostrar que no era sensible. Como resultado, nadie utilizaba el lago de datos (o, como él lo llamaba, el pantano).

Hoja de ruta hacia el éxito del lago de datos

Ahora que sabemos lo que hace falta para que un lago de datos tenga éxito y qué escollos hay que tener en cuenta, ¿cómo se construye uno? Normalmente, las empresas siguen este proceso

1. Prepara la infraestructura (pon en marcha el clúster Hadoop).

2. Organiza el lago de datos (crea zonas para uso de diversas comunidades de usuarios e ingiere los datos).

3. Configura el lago de datos para el autoservicio (crea un catálogo de activos de datos, establece permisos y proporciona herramientas que puedan utilizar los analistas).

4. Abre el lago de datos a los usuarios.

Poner en marcha un lago de datos

Cuando empecé a escribir este libro en 2015, la mayoría de las empresas construían lagos de datos locales utilizando el código abierto o distribuciones comerciales de Hadoop. En 2018, al menos la mitad de las empresas estaban construyendo sus lagos de datos enteramente en la nube o construyendo lagos de datos híbridos, tanto locales como en la nube. Muchas empresas también tienen varios lagos de datos. Toda esta variedad está llevando a las empresas a redefinir lo que es un lago de datos. Ahora estamos viendo el concepto de lago de datos lógico: una capa de lago de datos virtual a través de múltiples sistemas heterogéneos. Los sistemas subyacentes pueden ser Hadoop, bases de datos relacionales o NoSQL, en las instalaciones o en la nube.

La Figura 1-7 compara los tres enfoques. Todos ellos ofrecen un catálogo que los usuarios consultan para encontrar los activos de datos que necesitan. Estos activos de datos ya están en el lago de datos Hadoop o se aprovisionan en él, donde los analistas pueden utilizarlos.

Figura 1-7. Diferentes arquitecturas de lago de datos

Organizar el Lago de Datos

La mayoría de los lagos de datos que he encontrado están organizados más o menos de la misma manera, en varias zonas:

• Una zona bruta o de aterrizaje donde se ingieren los datos de y se mantienen lo más cerca posible de su estado original.

• Una zona aurífera o de producción donde se guardan los datos limpios y procesados de .

• Una zona de desarrollo o trabajo donde los usuarios más técnicos, como los científicos de datos y los ingenieros de datos, realizan su trabajo. Esta zona puede organizarse por usuario, por proyecto, por tema o de muchas otras formas. Una vez que el trabajo analítico realizado en la zona de trabajo se hace productivo, se traslada a la zona de oro.

• Una zona sensible que contiene datos sensibles.

La Figura 1-8 ilustra esta organización.

Figura 1-8. Zonas de un lago de datos típico

Durante muchos años, la idea predominante para los equipos de gobierno de datos era que los datos debían estar sujetos al mismo gobierno independientemente de su ubicación o finalidad. En los últimos años, sin embargo, los analistas del sector de Gartner han estado promoviendo el concepto de TI multimodal: básicamente, la idea de que la gobernanza debe reflejar el uso de los datos y los requisitos de la comunidad de usuarios. Este enfoque ha sido ampliamente adoptado por los equipos de los lagos de datos, con diferentes zonas que tienen diferentes niveles de gobernanza y acuerdos de nivel de servicio (SLA). Por ejemplo, los datos de la zona dorada suelen estar fuertemente gobernados, están bien curados y documentados, y conllevan ANS de calidad y frescura, mientras que los datos de la zona de trabajo tienen una gobernanza mínima (sobre todo para asegurarse de que no hay datos sensibles) y ANS que pueden variar de un proyecto a otro.

Las distintas comunidades de usuarios gravitan naturalmente hacia zonas diferentes. Los analistas empresariales utilizan los datos principalmente en la zona dorada, los ingenieros de datos trabajan con los datos en la zona bruta (convirtiéndolos en datos de producción destinados a la zona dorada), y los científicos de datos realizan sus experimentos en la zona de trabajo. Aunque en todas las zonas se requiere cierta gobernanza para garantizar que se detectan y protegen los datos sensibles, los administradores de datos se centran sobre todo en los datos de las zonas sensibles y de oro, para asegurarse de que cumplen las normativas de la empresa y del gobierno. La Figura 1-9 ilustra los distintos niveles de gobernanza y las distintas comunidades de usuarios para las distintas zonas.

Figura 1-9. Expectativas de gobernanza, zona por zona

Configurar el lago de datos para el autoservicio

Los analistas, ya sean analistas de negocio, analistas de datos o científicos de datos, suelen pasar por cuatro pasos para realizar su trabajo. Estos pasos se ilustran en la Figura 1-10.

Figura 1-10. Las cuatro etapas del análisis

El primer paso es encontrar y comprender los datos. Una vez que encuentran los conjuntos de datos adecuados, tienen que aprovisionarlos, es decir, acceder a ellos. Una vez que tienen los datos, a menudo necesitan prepararlos, es decir, limpiarlos y convertirlos a un formato adecuado para el análisis. Por último, necesitan utilizar los datos para responder a preguntas o crear visualizaciones e informes.

En teoría, los tres primeros pasos son opcionales: si el analista conoce y comprende bien los datos, ya tiene acceso a ellos y ya están en la forma adecuada para el análisis, puede limitarse a realizar el último paso. En realidad, muchos estudios han demostrado que los tres primeros pasos ocupan hasta el 80% del tiempo de un analista típico, con el mayor gasto (60%) en el primer paso de encontrar y comprender los datos (véase, por ejemplo, "Boost Your Business Insights by Converging Big Data and BI" de Boris Evelson, Forrester Research, 25 de marzo de 2015).

Vamos a desglosarlas, para que tengas una mejor idea de lo que ocurre en cada una de las cuatro etapas.

Encontrar y comprender los datos

¿Por qué es tan difícil encontrar datos en la empresa? Porque la variedad y complejidad de los datos disponibles supera con creces la capacidad humana para recordarlos. Imagina una base de datos muy pequeña, con sólo cien tablas (algunas bases de datos tienen miles o incluso decenas de miles de tablas, por lo que se trata realmente de una base de datos real muy pequeña). Ahora imagina que cada tabla tiene cien campos -una suposición razonable para la mayoría de las bases de datos, especialmente las analíticas, donde los datos tienden a desnormalizarse-. Eso nos da 10.000 campos. ¿Hasta qué punto es realista que alguien recuerde qué significan 10.000 campos y en qué tablas están esos campos, y que luego haga un seguimiento de ellos cada vez que utilice los datos para algo nuevo?

Ahora imagina una empresa que tiene varios miles (o varios cientos de miles) de bases de datos, la mayoría un orden de magnitud mayor que nuestra hipotética base de datos de 10.000 campos. Una vez trabajé con un banco pequeño que sólo tenía 5.000 empleados, pero consiguió crear 13.000 bases de datos. Sólo puedo imaginar cuántas podría tener un gran banco con cientos de miles de empleados. La razón por la que digo "sólo imaginar" es porque ninguna de las cientos de grandes empresas con las que he trabajado en mis 30 años de carrera fue capaz de decirme cuántas bases de datos tenían, y mucho menos cuántas tablas o campos.

Esperemos que esto te dé una idea del reto al que se enfrentan los analistas cuando buscan datos.

Un proyecto típico implica que los analistas "pregunten por ahí" para ver si alguien ha utilizado alguna vez un tipo concreto de datos. Van de persona en persona hasta que tropiezan con un conjunto de datos que alguien ha utilizado en uno de sus proyectos. Normalmente, no tienen ni idea de si es el mejor conjunto de datos que se puede utilizar, cómo se generó o incluso si los datos son fiables. Entonces se enfrentan a la terrible disyuntiva de utilizar ese conjunto de datos o preguntar un poco más y quizás no encontrar nada mejor.

Una vez que deciden utilizar un conjunto de datos, pasan mucho tiempo intentando descifrar qué significan los datos que contiene. Algunos datos son bastante obvios (por ejemplo, los nombres de los clientes o los números de cuenta), mientras que otros son crípticos (por ejemplo, ¿qué significa un código de cliente 1126?). Por eso, los analistas dedican aún más tiempo a buscar personas que puedan ayudarles a comprender los datos. Llamamos a esta información "conocimiento tribal". En otras palabras, el conocimiento suele existir, pero está repartido por toda la tribu y hay que volver a ensamblarlo mediante un proceso de descubrimiento doloroso, largo y propenso a errores.

Afortunadamente, hay nuevas herramientas de crowdsourcing de analistas que están abordando este problema mediante la recopilación de conocimientos tribales a través de un proceso que permite a los analistas documentar conjuntos de datos utilizando descripciones sencillas compuestas de términos empresariales, y construye un índice de búsqueda para ayudarles a encontrar lo que buscan. Herramientas como éstas se han desarrollado a medida en empresas modernas basadas en datos, como Google y LinkedIn. Como los datos son tan importantes en esas empresas y "todo el mundo es analista", la conciencia del problema y la voluntad de contribuir a la solución es mucho mayor que en las empresas tradicionales. También es mucho más fácil documentar los conjuntos de datos cuando se crean por primera vez, porque la información es reciente. Sin embargo, incluso en Google, aunque algunos conjuntos de datos populares están bien documentados, sigue habiendo una gran cantidad de datos oscuros o sin documentar.

En las empresas tradicionales, la situación es mucho peor. Hay millones de conjuntos de datos existentes (archivos y tablas) que nunca serán documentados por los analistas a menos que se utilicen, pero nunca se encontrarán y utilizarán a menos que se documenten. La única solución práctica es combinar el crowdsourcing con la automatización. Waterline Data es una herramienta que mi equipo y yo hemos desarrollado para ofrecer esa solución. Toma la información obtenida mediante crowdsourcing de los analistas que trabajan con sus conjuntos de datos y la aplica a todos los demás conjuntos de datos oscuros. El proceso se denomina fingerprinting: la herramienta rastrea todos los datos estructurados de la empresa, añadiendo un identificador único a cada campo, y a medida que los analistas anotan o etiquetan los campos, busca campos similares y sugiere etiquetas para ellos. Cuando los analistas buscan conjuntos de datos, ven tanto conjuntos de datos etiquetados por analistas como conjuntos de datos etiquetados por la herramienta automáticamente, y tienen la oportunidad de aceptar o rechazar estas etiquetas sugeridas. A continuación, la herramienta aplica el aprendizaje automático (ML) para mejorar su etiquetado automático basándose en los comentarios de los usuarios.

La idea central es que la anotación humana por sí sola no es suficiente, dado el alcance y la complejidad de los datos, mientras que la anotación puramente automatizada no es fiable dadas las características únicas e impredecibles de los datos, por lo que hay que unir ambas para conseguir los mejores resultados. La figura 1-11 ilustra el círculo virtuoso.

Figura 1-11. Aprovechar tanto el conocimiento humano como el aprendizaje automático

Acceso y suministro de los datos

Una vez identificados los conjuntos de datos adecuados, los analistas deben poder utilizarlos. Tradicionalmente, el acceso se concede a los analistas cuando empiezan o se incorporan a un proyecto. Luego rara vez se les retira, de modo que los veteranos acaban teniendo acceso a prácticamente todos los datos de la empresa que pueden ser remotamente útiles, mientras que los novatos prácticamente no tienen acceso y, por tanto, no pueden encontrar ni utilizar nada. Para resolver el problema del acceso a los datos del lago de datos, las empresas suelen optar por uno de los dos extremos: o bien conceden a todo el mundo acceso completo a todos los datos, o bien restringen todo el acceso a menos que un analista pueda demostrar una necesidad. Conceder acceso total funciona en algunos casos, pero no en los sectores regulados. Para hacerlo más aceptable, las empresas a veces desidentifican los datos sensibles, pero eso significa que tienen que trabajar ingiriendo datos que puede que nadie necesite. Además, a medida que cambian las normativas, es posible que haya que desidentificar cada vez más datos (este tema se tratará en profundidad en capítulos posteriores).

Un enfoque más práctico consiste en publicar información sobre todos los conjuntos de datos en un catálogo de metadatos, para que los analistas puedan encontrar conjuntos de datos útiles y luego solicitar el acceso según sus necesidades. Las solicitudes suelen incluir la justificación del acceso, el proyecto que requiere los datos y la duración del acceso requerido. Estas solicitudes se envían a los administradores de los datos solicitados. Si aprueban el acceso, se concede por un periodo de tiempo. Este periodo puede ampliarse, pero no es indefinido, lo que elimina el problema del acceso heredado. Una solicitud entrante también puede desencadenar el trabajo de desidentificación de datos sensibles, pero ahora sólo se hace si y cuando es necesario.

El aprovisionamiento o acceso físico puede concederse a los datos de varias formas:

• Se puede conceder a los usuarios acceso de lectura a todo el conjunto de datos.

• Si sólo debe concederse un acceso parcial, puede crearse (y mantenerse actualizada) una copia del archivo que contenga sólo los datos apropiados para el usuario, o puede crearse una tabla o vista Hive que contenga sólo los campos y filas que el analista deba ver.

• Si es necesario, se puede generar una versión desidentificada del conjunto de datos que sustituya la información sensible por información equivalente generada aleatoriamente, de modo que todas las aplicaciones sigan funcionando, pero no se filtren datos sensibles.

Preparación de los datos

En ocasiones, los datos llegan perfectamente limpios y listos para el análisis. Por desgracia, la mayoría de las veces, los datos necesitan trabajo para que sean apropiados para los analistas. La preparación de los datos suele implicar las siguientes operaciones

Dando forma a

Seleccionar un subconjunto de campos y filas sobre los que trabajar, combinar varios archivos y tablas en uno (unir), transformar y agregar, bucketizar (por ejemplo, pasar de valores discretos a rangos o buckets -por ejemplo, poner de 0 a 18 años en el bucket "juvenil", de 19 a 25 años en el bucket "adulto joven", etc.), convertir variables en características (por ejemplo, convertir la edad en una característica que tenga un valor de 0 si una persona tiene más de 65 años y de 1 si no), y muchos otros pasos posibles.

Limpieza

Rellenar los valores que faltan (por ejemplo, adivinar un sexo que falta a partir del nombre de pila o buscar la dirección en una base de datos de direcciones), corregir los valores erróneos de, resolver datos contradictorios, normalizar las unidades de medida y los códigos a unidades comunes, etc.

Mezcla

Armonizar diferentes conjuntos de datos de con el mismo esquema, las mismas unidades de medida, los mismos códigos, etc.

Como puedes deducir de estos pocos ejemplos, la preparación de los datos conlleva mucho trabajo y reflexión sofisticados. La automatización es crucial, para aprovechar las lecciones aprendidas con las transformaciones y evitar repetir los mismos pasos tediosos en miles de tablas y conjuntos de datos.

La herramienta de preparación de datos más común es Excel. Desgraciadamente, Excel no se adapta a los tamaños de los lagos de datos, pero una plétora de nuevas herramientas proporcionan capacidades similares a las de Excel para conjuntos de datos a gran escala. Algunas, como Trifacta, aplican sofisticadas técnicas de aprendizaje automático para sugerir transformaciones y ayudar a los analistas a preparar los datos. Muchos grandes proveedores también han estrenado herramientas de preparación de datos, y los proveedores de análisis como Tableau y Qlik también están mejorando las capacidades de preparación de datos en sus herramientas.

Análisis y visualización

Una vez preparados los datos, se pueden analizar. El análisis abarca desde la creación de informes y visualizaciones sencillas hasta sofisticados análisis avanzados y aprendizaje automático. Se trata de un espacio muy maduro, con cientos de proveedores que ofrecen soluciones para cada tipo de análisis. Específicamente para los lagos de datos Hadoop, Arcadia Data, AtScale y otros proporcionan herramientas de análisis y visualización diseñadas para ejecutarse de forma nativa y aprovechar la potencia de procesamiento de Hadoop.

Arquitecturas de lagos de datos

Al principio, la mayoría de las empresas con las que hablé pensaban que tendrían un enorme lago de datos local que contendría todos sus datos. A medida que evolucionaron sus conocimientos y buenas prácticas, la mayoría de las empresas se dieron cuenta de que un único punto de acceso no era lo ideal. Entre las normativas sobre soberanía de datos (por ejemplo, no está permitido sacar datos de Alemania) y las presiones organizativas, los lagos de datos múltiples resultaron ser normalmente una solución mejor. Además, a medida que las empresas se daban cuenta de la complejidad de dar soporte a un clúster masivamente paralelo y experimentaban la frustración de su incapacidad para encontrar y contratar administradores experimentados para Hadoop y otras plataformas de big data, empezaron a optar por los lagos de datos basados en la nube, donde la mayoría de los componentes de hardware y plataforma son gestionados por los expertos que trabajan para Amazon, Microsoft, Google y otros.

Lagos de datos en la nube pública

Aparte de las ventajas del acceso a la experiencia en tecnología de big data y de los breves plazos de implementación, el bajo coste del almacenamiento y la naturaleza elástica de la computación en nube hacen que sea una opción muy atractiva para implementar un lago de datos. Dado que se almacenan muchos datos para su uso futuro, tiene sentido almacenarlos de la forma más barata posible. Esto funciona bien con las posibilidades de optimización de costes que ofrecen los distintos niveles de almacenamiento de Amazon y otros: el acceso va de la alta velocidad a la velocidad glacial, siendo los medios de acceso más lento significativamente más baratos.

Además, la elasticidad de la computación en nube permite poner en marcha un clúster muy grande bajo demanda, cuando sea necesario. Compáralo con un clúster local, que tiene un tamaño fijo y almacena sus datos en almacenamiento conectado (aunque se están explorando nuevas arquitecturas con almacenamiento conectado a la red). Esto significa que a medida que los nodos se llenan de datos, hay que añadir nuevos nodos sólo para el almacenamiento. Además, si las cargas analíticas son pesadas para la CPU y necesitas más potencia de cálculo, necesitas añadir nodos aunque sólo los utilices durante un breve periodo de tiempo.

En la nube, sólo pagas por el almacenamiento que necesitas (es decir, no tienes que comprar nodos de cálculo adicionales sólo para obtener más almacenamiento) y puedes poner en marcha clusters enormes durante periodos cortos de tiempo. Por ejemplo, si tienes un clúster local de 100 nodos y un trabajo que dura 50 horas, no es práctico comprar e instalar 1.000 nodos sólo para que este único trabajo se ejecute más rápido. En la nube, sin embargo, pagarías más o menos lo mismo por la potencia de cálculo de 100 nodos durante 50 horas que por 1.000 nodos durante 5 horas. Esta es la gran ventaja de la computación elástica.

Lagos de datos lógicos

Cuando las empresas se dieron cuenta de que tener un lago de datos centralizado no era una buena solución, se impuso la idea del lago de datos lógico. Con este enfoque, en lugar de cargar todos los datos en el lago de datos por si acaso alguien pudiera necesitarlos en algún momento, se ponen a disposición de los analistas a través de un catálogo central o mediante un software de virtualización de datos.

Los lagos de datos lógicos abordan las cuestiones de integridad y redundancia, como se ilustra en la Figura 1-12.

Figura 1-12. Problemas de integridad y redundancia

Estas cuestiones pueden resumirse como sigue:

Integridad

¿Cómo encuentran los analistas el mejor conjunto de datos? Si los analistas sólo pueden encontrar los datos que ya están en el lago de datos, no encontrarán ni utilizarán otros datos que no hayan sido ingeridos en el lago de datos (la zona creciente de la derecha en la Figura 1-12).

Redundancia

Si ingerimos todos los datos en el lago de datos, tendremos redundancia entre las fuentes de datos y el lago de datos (ilustrada como el área de solapamiento entre los dos círculos de la Figura 1-12). Con varios lagos de datos, para lograr la exhaustividad tendríamos que ingerir los mismos datos en cada lago de datos.

Para empeorar las cosas, ya existe mucha redundancia en la empresa. Tradicionalmente, cuando se inicia un nuevo proyecto, lo más conveniente y políticamente sencillo es que el equipo del proyecto cree un nuevo mercado de datos, copie los datos de otras fuentes o del almacén de datos, y añada sus propios datos exclusivos. Esto es mucho más fácil que estudiar los mercados de datos existentes y negociar el uso compartido con los propietarios y usuarios actuales. Como resultado, hay una proliferación de mercados de datos que, en su mayoría, son iguales. Si cargamos ciegamente todos los datos de estos mercados de datos en el lago de datos, tendremos niveles extremadamente altos de redundancia en nuestro lago.

El mejor enfoque de los retos de integridad y redundancia que he visto implica un par de reglas sencillas:

• Para resolver el problema de la exhaustividad, crea un catálogo de todos los activos de datos, para que los analistas puedan encontrar y solicitar cualquier conjunto de datos que esté disponible en la empresa.

• Para resolver el problema de la redundancia, sigue el proceso que se muestra en la Figura 1-13:

  • Almacena datos que no estén almacenados en ningún otro lugar del lago de datos.

  • Lleva los datos almacenados en otros sistemas al lago de datos siempre y cuando se necesiten, y mantenlos sincronizados mientras se necesiten.

  • Introduce cada conjunto de datos una sola vez para todos los usuarios.

Figura 1-13. Gestionar los datos en el lago de datos lógico

Virtualización frente a un lago de datos lógico basado en catálogos

La virtualización (a veces también llamada federación o IIE, por integración de la información empresarial) es una tecnología desarrollada en la década de 1980 y mejorada a través de varias generaciones hasta la década de 2010. Básicamente, crea una vista o tabla virtual que oculta la ubicación y la implementación de las tablas físicas. En la Figura 1-14, se crea una vista uniendo dos tablas de bases de datos diferentes. La consulta consultaría entonces esa vista y dejaría en manos del sistema de virtualización de datos la tarea de averiguar cómo acceder a los datos de las dos bases de datos y unirlos.

Figura 1-14. Crear un conjunto de datos personalizado a través de una vista

Aunque esta tecnología funciona bien para algunos casos de uso, en un lago de datos lógico, para lograr la exhaustividad, requeriría que cada conjunto de datos se publicara como una tabla virtual y se mantuviera actualizado a medida que cambiaran los esquemas de las tablas subyacentes.

Aunque se resolviera el problema inicial de publicar cada activo de datos, las vistas siguen presentando problemas importantes:

• Crear una vista virtual no facilita la búsqueda de datos.

• Unir datos de múltiples sistemas heterogéneos es complejo y requiere muchos cálculos, lo que a menudo provoca cargas masivas en los sistemas y largos ciclos de ejecución. Las llamadas uniones distribuidas de tablas que no caben en memoria son notoriamente intensivas en recursos.

Por el contrario, en el enfoque basado en catálogos, sólo se publican los metadatos sobre cada conjunto de datos, para que sean localizables. A continuación, los conjuntos de datos se suministran al mismo sistema (por ejemplo, un clúster Hadoop) para ser procesados localmente, como se muestra en la Figura 1-15.

Figura 1-15. Proporcionar metadatos a través de un catálogo

Además de hacer que todos los datos sean localizables y accesibles para los analistas, un catálogo empresarial puede servir como punto único de acceso, gobierno, y auditoría, como se muestra en la Figura 1-16. En la parte superior, sin un catálogo centralizado, el acceso a los activos de datos está disperso y es difícil de gestionar y controlar. En la parte inferior, con el catálogo centralizado, todas las solicitudes de acceso pasan por el catálogo. El acceso se concede bajo demanda durante un periodo de tiempo determinado y es auditado por el sistema.

Figura 1-16. Aprovisionamiento y gobierno de datos a través del catálogo

Conclusión

En resumen, conseguir en la plataforma adecuada, cargarla en con los datos adecuados, y organizarla y configurarla para el autoservicio con una interfaz adecuada a las habilidades y necesidades, son las claves para crear un lago de datos de éxito. En el resto de este libro, exploraremos cómo llevar a cabo estas tareas.