El Lago de Grandes Datos de la Empresa

Capítulo 4. Poner en marcha un lago de datos

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

Como se ha comentado en el capítulo anterior, la promesa del lago de datos es almacenar los datos de la empresa de forma que se maximice su disponibilidad y accesibilidad para el análisis y la ciencia de datos. Pero, ¿cuál es la mejor forma de empezar? En este capítulo se analizan los distintos caminos que siguen las empresas para construir un lago de datos.

Apache Hadoop es un proyecto de código abierto que se utiliza con frecuencia para este fin. Aunque existen muchas otras alternativas, especialmente en la nube, los lagos de datos basados en Hadoop ofrecen una buena representación de las ventajas que proporcionan, por lo que vamos a utilizar Hadoop como ejemplo. Empezaremos repasando qué es y algunas de sus ventajas clave para dar soporte a un lago de datos.

El qué y el porqué de Hadoop

Hadoop es una plataforma de almacenamiento y ejecución masivamente paralela que automatiza muchos de los aspectos difíciles de crear un clúster altamente escalable y disponible. Tiene su propio sistema de archivos distribuido, HDFS (aunque algunas distribuciones de Hadoop, como MapR e IBM, proporcionan sus propios sistemas de archivos para sustituir a HDFS). HDFS replica automáticamente los datos en el clúster para lograr un alto paralelismo y disponibilidad. Por ejemplo, si Hadoop utiliza el factor de replicación predeterminado de tres, almacena cada bloque en tres nodos diferentes. De este modo, cuando un trabajo necesita un bloque de datos, el programador puede elegir entre tres nodos diferentes y decidir cuál es el mejor en función de qué otros trabajos se están ejecutando en él, qué otros datos se encuentran allí, etc. Además, si falla uno de los tres nodos, el sistema se reconfigura dinámicamente para crear otra réplica de cada bloque que solía estar en ese nodo, mientras ejecuta los trabajos actuales en los dos nodos restantes.

Como vimos en el capítulo anterior, MapReduce es un modelo de programación que se ha implementado para ejecutarse sobre Hadoop y aprovechar HDFS para crear aplicaciones masivamente paralelas. Permite a los desarrolladores crear dos tipos de funciones, conocidas como mapeadores y reductores. Los mapeadores trabajan en paralelo para procesar los datos y enviar los resultados a los reductores que ensamblan los datos para la salida final. Por ejemplo, un programa que cuenta palabras en un archivo puede tener una función mapeadora que lea un bloque de un archivo, cuente el número de palabras y emita el nombre del archivo y el número de palabras que contó en ese bloque. A continuación, los reductores obtendrán un flujo de recuentos de palabras de los mapeadores y sumarán los bloques de cada archivo antes de emitir los recuentos finales. Un servicio intermedio llamado ordenar y mezclar se asegura de que los recuentos de palabras del mismo archivo se dirijan al mismo reductor. Lo bonito de Hadoop es que los trabajos MapReduce individuales no tienen que saber ni preocuparse de la ubicación de los datos, de optimizar qué funciones se ejecutan en qué nodos, ni de qué nodos fallaron y se están recuperando: Hadoop se ocupa de todo eso de forma transparente.

Apache Spark, que se incluye en todas las distribuciones Hadoop de, proporciona un motor de ejecución que puede procesar grandes cantidades de datos en memoria a través de múltiples nodos. Spark es más eficiente y fácil de programar que MapReduce, mucho más adecuado para el procesamiento ad hoc o casi en tiempo real y, al igual que Map-Reduce, aprovecha la localidad de datos que proporciona HDFS para optimizar el procesamiento. Spark viene con una serie de módulos útiles, como SparkSQL, que proporciona una interfaz SQL a los programas Spark, y admite el procesamiento universal de fuentes de datos heterogéneas mediante DataFrames.

Sin embargo, el principal atractivo de Hadoop es que, como demuestra la Figura 4-1, es toda una plataforma y un ecosistema de herramientas de código abierto y propietarias que resuelven una gran variedad de casos de uso. Entre los proyectos más destacados se encuentran:

Colmena

Una interfaz similar a SQL a archivos Hadoop

Chispa

Un sistema de ejecución en memoria

Hilo

Un gestor de recursos distribuido

Oozie

Un sistema de flujo de trabajo

Figura 4-1. Un ejemplo de arquitectura Hadoop

Varias propiedades de Hadoop lo hacen atractivo como plataforma de almacenamiento y gestión de datos a largo plazo. Entre ellas:

Escalabilidad extrema

En la mayoría de las empresas los datos no hacen más que crecer, y a menudo de forma exponencial. Este crecimiento significa que cada vez se necesita más potencia de cálculo para procesar los datos. Hadoop está diseñado para seguir escalando simplemente añadiendo más nodos (lo que a menudo se denomina "escalar"). Se utiliza en algunos de los mayores clusters del mundo, en empresas como Yahoo! y Facebook.

Relación coste-eficacia

Hadoop está diseñado para funcionar con hardware comercial de bajo coste, ejecutarse sobre Linux y utilizar muchos proyectos gratuitos de código abierto. Esto lo hace muy rentable.

Modularidad

Los sistemas tradicionales de gestión de datos son monolíticos. Por ejemplo, en una base de datos relacional tradicional sólo se puede acceder a los datos mediante consultas relacionales, de modo que si alguien desarrolla una herramienta de procesamiento de datos mejor o un motor de consultas más rápido, no puede aprovechar los archivos de datos existentes. Los RDBMS también exigen un estricto control del esquema: antes de que puedas añadir cualquier dato, tienes que predefinir la estructura de esos datos (llamada esquema), y tienes que cambiar cuidadosamente esa estructura si los datos cambian. Este enfoque se denomina "esquema en escritura". Hadoop, en cambio, está diseñado desde cero para ser modular, de modo que cualquier aplicación pueda acceder al mismo archivo. Por ejemplo, Hive puede acceder a un archivo para realizar una consulta relacional o un trabajo MapReduce personalizado para realizar un análisis pesado. Esta modularidad hace que Hadoop sea extremadamente atractivo como plataforma a largo plazo para la gestión de datos, ya que las nuevas tecnologías de gestión de datos podrán utilizar los datos almacenados en Hadoop a través de interfaces abiertas.

Acoplamiento suelto de esquemas, o "esquema en lectura"

A diferencia de una base de datos relacional tradicional, Hadoop no impone ningún tipo de esquema cuando se escriben los datos. Esto permite la llamada ingesta sin fricción: los datosse pueden ingerir sin ninguna comprobación ni procesamiento. Puesto que no sabemos necesariamente cómo se van a utilizar los datos, utilizar la ingesta sin fricción nos permite evitar el coste de procesar y conservar datos que quizá no necesitemos, y potencialmente procesarlos de forma incorrecta para futuras aplicaciones. Es mucho mejor dejar los datos en su estado original o bruto y hacer el trabajo según sea necesario cuando los requisitos y el caso de uso estén solidificados.

Si estás construyendo un sistema de almacenamiento y análisis a largo plazo para tus datos, querrás que sea rentable, altamente escalable y disponible. También querrás que añadir datos requiera un trabajo mínimo, y que el sistema sea extensible para admitir futuras tecnologías, aplicaciones y proyectos. Como puedes ver en la breve discusión anterior, Hadoop se ajusta perfectamente a este perfil.

Evitar la proliferación de charcos de datos

Con todo el entusiasmo que rodea a los macrodatos, hay muchos proveedores e integradores de sistemas que ofrecen valor inmediato a las empresas. Esta gente suele prometer un rápido retorno de la inversión (ROI), con soluciones basadas en la nube. Para muchos equipos empresariales cuyos proyectos languidecen en las colas de trabajo de TI y que están cansados de luchar por la prioridad y la atención o de comprobar que sus equipos de TI carecen de las capacidades necesarias para hacer lo que les piden, esto puede parecer un sueño hecho realidad. En semanas o meses, consiguen los proyectos que llevan años exigiendo a TI.

Muchos de estos proyectos se ponen en marcha y producen ganancias rápidas, haciendo que otros equipos emprendan proyectos similares. Muy pronto, muchos grupos empresariales tienen su propia "TI en la sombra" y sus propios pequeños clústeres Hadoop (a veces llamados charcos de datos) en las instalaciones y en la nube. Estos clústeres de propósito único suelen ser pequeños y se construyen a propósito utilizando cualquier tecnología con la que estén familiarizados los integradores de sistemas (SI) o los desarrolladores de la empresa, y se cargan con datos que pueden o no tener un origen riguroso.

La desafortunada realidad de la tecnología de código abierto es que aún no es lo suficientemente estable, o estándar, para esta proliferación. Una vez que los SI se marchan y llega el primer gran reto técnico -los trabajos no se ejecutan, las bibliotecas necesitan actualizarse, las tecnologías ya no son compatibles-, estos charcos de datos acaban abandonados o devueltos a TI. Además, como los charcos de datos crean silos, es difícil reutilizar los datos de esos charcos y los resultados del trabajo realizado con esos datos.

Para evitar este escenario, muchas empresas prefieren adelantarse al tren y construir un lago de datos centralizado. Entonces, cuando los equipos empresariales deciden que necesitan Hadoop, los recursos informáticos y los datos para sus proyectos ya están disponibles en el lago de datos. Al proporcionar recursos informáticos gestionados con datos precargados, pero dando autonomía a los usuarios mediante el autoservicio, un lago de datos empresarial ofrece a las empresas lo mejor de ambos mundos: soporte para los componentes que les resultan difíciles de mantener (mediante la plataforma Hadoop y el aprovisionamiento de datos), y libertad para no esperar a TI antes de trabajar en sus proyectos.

Aunque se trata de una estrategia defensiva sólida, y a veces necesaria, para aprovechar al máximo lo que ofrecen los macrodatos debe combinarse con una de las estrategias descritas en la sección siguiente.

Aprovechar el Big Data

En esta sección, cubriremos algunos de los escenarios más populares para la adopción de un lago de datos. En las empresas en las que los líderes empresariales están impulsando la adopción generalizada de big data, el lago de datos suele ser construido por TI para tratar de evitar la proliferación de charcos de datos (pequeños clusters independientes construidos con diferentes tecnologías, a menudo por SI que ya no participan en los proyectos).

Para las empresas que intentan introducir big data, hay algunos enfoques populares:

• Empieza descargando algunas funciones existentes a Hadoop y luego añade más datos y amplíalos a un lago de datos.

• Empieza con una iniciativa de ciencia de datos, demuestra un gran retorno de la inversión, y luego amplíala a un lago de datos completo.

• Construye el lago de datos desde cero como punto central de gobierno.

¿Cuál es la adecuada para ti? Depende de la fase en que se encuentre tu empresa en la adopción de big data, de tu función y de otras consideraciones que examinaremos en esta sección.

Liderar con Ciencia de Datos

Identificar una iniciativa de ciencia de datos de gran visibilidad que afecte a la línea superior es una estrategia muy atractiva. La ciencia de datos es un término general para aplicar la analítica avanzada y el aprendizaje automático a los datos. A menudo, los almacenes de datos que empiezan como un imperativo estratégico que promete hacer más eficaz el negocio acaban apoyando la elaboración de informes y la analítica operativa. Por tanto, aunque los almacenes de datos siguen siendo esenciales para el funcionamiento de la empresa, se perciben sobre todo como un gasto general necesario, más que como una inversión estratégica. Como tales, no reciben respeto, aprecio ni prioridad de financiación. Muchos equipos de análisis y almacenamiento de datos ven la ciencia de los datos como una forma de influir visiblemente en el negocio y en los beneficios, y de volver a ser estratégicamente importantes.

La forma más práctica de introducir la ciencia de datos en una organización es encontrar un problema muy visible que:

• Está bien definido y se entiende bien

• Puede mostrar beneficios rápidos y cuantificables

• Pueden resolverse mediante el aprendizaje automático o la analítica avanzada

• Requiere datos que el equipo pueda obtener fácilmente

• Sería muy difícil o llevaría mucho tiempo resolverlo sin aplicar técnicas de ciencia de datos

Aunque pueda parecer desalentador encontrar un proyecto de este tipo, la mayoría de las organizaciones suelen poder identificar una serie de problemas bien conocidos y de gran visibilidad que pueden demostrar rápidamente los beneficios, ocupándose de los dos primeros requisitos.

Para el tercer requisito, a menudo es posible identificar a un buen candidato de dos maneras: buscando en sitios y publicaciones del sector otras empresas que hayan resuelto problemas similares utilizando el aprendizaje automático, o contratando a consultores experimentados que puedan recomendarte cuáles de esos problemas se prestan al aprendizaje automático o a la analítica avanzada. Una vez seleccionados uno o varios proyectos candidatos e identificados los datos que necesitas para entrenar los modelos o aplicar otras técnicas de aprendizaje automático, se pueden revisar los conjuntos de datos en términos de facilidad de obtención. Esto suele depender de quién sea el propietario de los datos, del acceso a personas que los entiendan y de los retos técnicos que plantee su obtención.

Algunos ejemplos de proyectos comunes impulsados por la ciencia de datos para diferentes verticales son:

Servicios financieros

Gobernanza, gestión del riesgo y cumplimiento (GRC), incluyendo el análisis del riesgo de la cartera y garantizando el cumplimiento de una miríada de normativas (Basilea 3, Conoce a tu cliente, Antiblanqueo de Capitales y muchas otras); detección del fraude; optimización de la ubicación de las sucursales; negociación automatizada

Sanidad

Gobernanza y cumplimiento , investigación médica, analítica de la atención al paciente, dispositivos médicos IoT, dispositivos wearables, teleasistencia sanitaria

Productos farmacéuticos

Investigación del genoma, optimización del proceso de fabricación

Fabricación

Recopilación de información de dispositivos IoT, control de calidad, mantenimiento preventivo, Industria 4.0

Educación

Admisiones, éxito de los estudiantes

Venta al por menor

Optimización de precios, recomendaciones de compra , propensión a comprar

Adtech

Puja automatizada, intercambios

Una vez identificado el problema, la mayoría de las organizaciones invierten en un pequeño clúster Hadoop, ya sea en las instalaciones o en la nube (dependiendo de la sensibilidad de los datos). Contratan a consultores de ciencia de datos, llevan a cabo el proceso y obtienen rápidamente resultados que demuestran el valor de un lago de datos.

Normalmente, se realizan dos o tres de estos proyectos, y luego se utiliza su éxito para justificar un lago de datos. Esto se conoce a veces como el modelo "Xerox PARC". Xerox creó el PARC (Centro de Investigación de Palo Alto, California) para investigar "la oficina del futuro" en 1970. En 1971, un investigador del PARC construyó la primera impresora láser, que se convirtió en el principal elemento básico del negocio de Xerox en los años venideros. Pero aunque en PARC se inventaron muchas otras tecnologías que cambiaron la industria, ninguna fue monetizada con éxito por Xerox a la escala de la impresión láser. El objetivo de comparar los experimentos de la ciencia de datos con PARC es destacar que los resultados de la ciencia de datos son inherentemente impredecibles. Por ejemplo, un proyecto largo y complejo puede producir un modelo predictivo estable con una alta tasa de predicciones acertadas, o el modelo puede producir sólo una mejora marginal (por ejemplo, si el modelo acierta el 60% de las veces, eso es sólo una mejora del 10% sobre la elección aleatoria del resultado, que acertará el 50% de las veces). Básicamente, el éxito inicial en unos pocos proyectos de poca monta no garantiza el éxito a gran escala de un gran número de otros proyectos de ciencia de datos.

Este enfoque de invertir para el futuro suena bien. Puede ser muy tentador construir un gran lago de datos, cargarlo de datos y declarar la victoria. Desgraciadamente, he hablado con docenas de empresas en las que se dio exactamente este patrón: tuvieron unos cuantos pilotos de ciencia de datos que rápidamente produjeron resultados asombrosos. Utilizaron estos pilotos para asegurarse presupuestos multimillonarios para lagos de datos, construyeron grandes clusters, cargaron petabytes de datos, y ahora están luchando por conseguir uso o mostrar valor adicional.

Si optas por la vía analítica, ten en cuenta las siguientes recomendaciones que varios líderes de TI y de la ciencia de datos han compartido conmigo:

• Ten un pipeline de proyectos de ciencia de datos muy prometedores que puedas ejecutar mientras construyes el lago de datos para seguir mostrando valor. Idealmente, asegúrate de que puedes demostrar un conocimiento valioso por trimestre mientras dure la construcción del lago de datos.

• Amplía el lago de datos más allá de los casos de uso originales de la ciencia de datos tan pronto como sea posible, trasladando otras cargas de trabajo al lago, desde trabajos operativos como ETL a la gobernanza, pasando por el BI simple y la elaboración de informes.

• No intentes hervir el océano de inmediato. Sigue construyendo el clúster y añadiendo fuentes de datos a medida que vayas mostrando más valor.

• Céntrate en conseguir que otros departamentos, equipos y proyectos utilicen el lago de datos.

En resumen, la ciencia de datos es una forma muy atractiva de llegar al lago de datos. A menudo afecta a la línea superior, creando ROI a través del valor de la perspectiva empresarial y aumentando la concienciación sobre el valor de los datos y los servicios ofrecidos por el equipo de datos. La clave para construir un lago de datos con éxito es asegurarse de que el equipo pueda seguir produciendo perspectivas tan valiosas hasta que el lago de datos se diversifique a más casos de uso y cree un valor sostenible para una amplia gama de equipos y proyectos.

Estrategia 1: Descargar la funcionalidad existente

Una de las ventajas más convincentes de la tecnología big data es su coste, que puede ser 10 o más veces inferior al coste de un almacén de datos relacional de rendimiento y capacidad similares. Como el tamaño de un almacén de datos no hace más que aumentar, y los presupuestos de TI suelen incluir el coste de la ampliación, resulta muy atractivo descargar parte del procesamiento de un almacén de datos en lugar de hacer crecer el almacén de datos. La ventaja de este enfoque es que no requiere un patrocinador empresarial, porque el coste suele salir totalmente del presupuesto de TI, y porque el éxito del proyecto depende principalmente de TI: la descarga debe ser transparente para los usuarios empresariales.

La tarea de procesamiento más común para descargar a un sistema de big data es la parte T de ETL (extraer, transformar, cargar).

Teradata es el principal proveedor de grandes almacenes de datos masivamente paralelos. Durante años, Teradata ha defendido un enfoque ELT para cargar el almacén de datos: extraer y cargar los datos en el almacén de datos de Teradata y luego transformarlos utilizando los potentes motores multinodo de Teradata. Esta estrategia se adoptó ampliamente porque las herramientas ETL generales no se escalaban bien para manejar el volumen de datos que había que transformar. Los sistemas de big data, en cambio, pueden manejar el volumen con facilidad y de forma muy rentable. Por tanto, Teradata aboga ahora por hacer las transformaciones en un marco de big data -en concreto, Hadoop- y luego cargar los datos en el almacén de datos de Teradata para realizar consultas y análisis.

Otra práctica habitual es trasladar el procesamiento de datos no tabulares a Hadoop. Muchas fuentes de datos modernas, desde los registros web hasta los feeds de Twitter, no son tabulares. En lugar de las columnas y filas fijas de los datos relacionales, tienen estructuras de datos complejas y una gran variedad de registros. Estos tipos de datos pueden procesarse muy eficazmente en Hadoop en su formato nativo, en lugar de requerir su conversión a un formato relacional y su carga en un almacén de datos para que estén disponibles para su procesamiento mediante consultas relacionales.

Una tercera clase de procesamiento que suele trasladarse a las plataformas de big data es el procesamiento en tiempo real o streaming. Las nuevas tecnologías como Spark, que permite el procesamiento masivo paralelo de datos en memoria en múltiples nodos, y Kafka, un sistema de colas de mensajes, están haciendo muy atractivo el procesamiento de datos en memoria a gran escala para el análisis en tiempo real, el procesamiento de eventos complejos (CEP) y los cuadros de mando.

Por último, las soluciones de big data pueden utilizarse para ampliar proyectos existentes a una fracción del coste de las tecnologías heredadas. Una empresa con la que hablé había trasladado a Hadoop un complejo procesamiento de detección de fraudes. Hadoop fue capaz de procesar 10 veces más datos, 10 veces más rápido por el mismo coste de recursos informáticos que una base de datos relacional, creando modelos y detección órdenes de magnitud más precisos.

Un ejemplo de las ventajas del paso a un lago de datos es el de un gran fabricante de dispositivos, cuyos aparatos envían diariamente sus registros a la fábrica (se denominan "registros de llamadas a casa"). El fabricante solía procesar los registros y almacenar sólo el 2% de los datos en una base de datos relacional para utilizarlos en modelos predictivos. Los modelos predecían cuándo fallaría un aparato, cuándo necesitaría mantenimiento, etc. Cada vez que cambiaba el formato o el contenido del registro o los analistas necesitaban otro dato para sus modelos predictivos, los desarrolladores tenían que cambiar la lógica de procesamiento y los analistas tenían que esperar meses para reunir suficientes datos antes de poder ejecutar nuevos análisis. Con Hadoop, esta empresa puede almacenar todos los archivos de registro por una fracción del coste anterior de almacenar sólo el 2%. Como ahora los analistas pueden acceder a todos los datos tan atrás como quieran, pueden implementar rápidamente nuevos análisis para las iniciativas internas de calidad de datos, así como para las orientadas al cliente.

Una vez que los equipos informáticos pasan de ese procesamiento automatizado a los marcos de big data y acumulan grandes conjuntos de datos, se ven presionados para poner estos datos a disposición de los científicos y analistas de datos. Para pasar del procesamiento automatizado a un lago de datos, normalmente tienen que seguir los siguientes pasos:

• Añade datos que no estén siendo procesados por trabajos automatizados para crear un lago de datos completo.

• Proporcionar acceso a los datos a los no programadores, permitiéndoles crear visualizaciones de datos, informes, cuadros de mando y consultas SQL.

• Para facilitar la adopción por parte de los analistas, proporciona un catálogo completo en el que se puedan realizar búsquedas.

• Automatiza las políticas que rigen el acceso a los datos, la gestión de datos sensibles, la calidad de los datos y la gestión del ciclo de vida de los datos.

• Asegúrate de que los acuerdos de nivel de servicio (SLA) de los trabajos automatizados no se ven afectados por el trabajo que realizan los analistas, estableciendo esquemas de ejecución priorizada y gobernanza de recursos.

Estrategia 2: Lagos de datos para nuevos proyectos

En lugar de descargar la funcionalidad existente en una plataforma de big data, algunas empresas la utilizan para respaldar un nuevo proyecto operativo, como la ciencia de datos, la analítica avanzada, el procesamiento de datos de máquinas y registros de dispositivos IoT, o la analítica de clientes de medios sociales. Estos proyectos suelen estar impulsados por equipos de ciencia de datos o equipos de línea de negocio, y suelen empezar como charcos de datos, es decir, pequeños entornos de big data de un solo propósito. Luego, a medida que se añaden más y más casos de uso, acaban evolucionando hasta convertirse en auténticos lagos de datos.

En muchos sentidos, el camino de empezar con un nuevo proyecto operativo es similar al proceso de descarga de un proyecto existente. La ventaja de un nuevo proyecto es que crea un nuevo valor visible para la empresa. El inconveniente es que requiere un presupuesto adicional. Además, el fracaso de un proyecto, aunque no tenga nada que ver con el lago de datos, puede empañar la visión que la empresa tiene de la tecnología de big data y afectar negativamente a su adopción.

Estrategia 3: Establecer un Punto Central de Gobernanza

Con cada vez más normativas gubernamentales e industriales y una aplicación cada vez más estricta de las mismas, la gobernanza se está convirtiendo en en uno de los principales focos de atención de muchas empresas. El objetivo de la gobernanza es proporcionar a los usuarios un acceso seguro y gestionado a los datos que cumpla la normativa gubernamental y empresarial. Generalmente incluye la gestión de datos sensibles y personales, la calidad de los datos, el ciclo de vida de los datos, los metadatos y el linaje de los datos.(El Capítulo 6 tratará este tema con mucho más detalle.) Dado que la gobernanza garantiza el cumplimiento de las normativas gubernamentales y corporativas, y que estas normativas se aplican a todos los sistemas de la empresa, la gobernanza exige que las empresas apliquen y mantengan políticas coherentes. Desgraciadamente, implantar y mantener políticas de gobierno coherentes en sistemas heterogéneos que utilizan tecnologías diferentes y son gestionados por equipos distintos con prioridades diferentes supone un problema formidable para la mayoría de las empresas.

Los profesionales del gobierno de datos a veces consideran que los big data y Hadoop son un problema lejano y futuro. Creen que primero tienen que implantar políticas de gobierno de datos para los sistemas heredados antes de abordar las nuevas tecnologías. Este enfoque, aunque no carece de mérito, desaprovecha la oportunidad de utilizar Hadoop como plataforma rentable para proporcionar gobernanza y cumplimiento centralizados a la empresa.

Tradicionalmente, la gobernanza ha requerido convencer a los equipos responsables de los sistemas heredados de que dediquen sus limitados recursos de personal a adaptar sus sistemas para que cumplan las políticas de gobernanza, y que dediquen costosos recursos informáticos a ejecutar las reglas, comprobaciones y auditorías asociadas a esas políticas. A menudo es mucho más sencillo y rentable decir a los equipos responsables de los sistemas heredados que ingieran sus datos en Hadoop para que un conjunto estándar de herramientas pueda aplicar políticas de gobierno coherentes. Este enfoque tiene las siguientes ventajas:

• Los datos pueden ser perfilados y procesados por un conjunto estándar de tecnologías de calidad de datos con reglas uniformes de calidad de datos.

• Los datos sensibles pueden ser detectados y tratados por un conjunto estándar de herramientas de seguridad de datos.

• Las funciones de retención y eDiscovery pueden implementarse de forma uniforme en todos los sistemas.

• Los informes de cumplimiento pueden elaborarse con un único sistema unificado.

Además, los sistemas de big data basados en archivos, como Hadoop, se prestan bien a la idea de TI bimodal, un enfoque que recomienda crear zonas diferentes con distintos grados de gobernanza. Al crear y mantener zonas separadas para los datos brutos y limpios, un lago de datos admite varios grados de gobernanza en un clúster.

¿Qué camino es el adecuado para ti?

Cualquiera de estos enfoques puede conducir a un lago de datos exitoso. ¿Qué camino debes seguir? Normalmente depende de tu función, tu presupuesto y los aliados que puedas reclutar. Generalmente, lo más fácil es empezar un lago de datos utilizando el presupuesto que controlas. Sin embargo, independientemente de por dónde empieces, para que un lago de datos despegue y sea sostenible, necesitarás un plan para convencer a los analistas de toda la empresa de que empiecen a utilizarlo para sus proyectos.

Si eres un ejecutivo de TI o un campeón de big data, el árbol de decisiones de la Figura 4-2 debería ayudarte a formular una estrategia de lago de datos.

A alto nivel, los pasos a dar son los siguientes:

1. Determina si hay algún charco de datos (es decir, ¿los equipos de negocio están utilizando clusters Hadoop por su cuenta?)

   1. Si los hay, ¿hay proyectos que estarían de acuerdo en pasar a una agrupación centralizada?

      1. Si es así, utiliza el coste del proyecto para justificar un clúster centralizado.

      2. Si no es así, justifica la construcción de un lago de datos para evitar la proliferación de charcos de datos. Utiliza como ejemplo proliferaciones anteriores (por ejemplo, data marts, bases de datos de informes). Si no puedes obtener la aprobación, espera a que los charcos den problemas: no tardarán mucho.

   2. Si no hay charcos de datos, ¿hay grupos que pidan big data y/o ciencia de datos? Si no es así, ¿puedes venderles que lo patrocinen?

2. Busca la fruta al alcance de la mano. Intenta identificar proyectos de bajo riesgo y gran visibilidad.

3. Intenta alinear más de un proyecto por equipo y más de un equipo para maximizar las posibilidades de éxito.

4. Sigue el camino de la ciencia de datos/analítica:

   1. Si no hay grupos dispuestos a patrocinar un proyecto de big data, ¿existe una iniciativa de gobierno de datos? En caso afirmativo, intenta proponer y conseguir la aprobación de la vía del punto único de gobierno.

   2. Si no, revisa los proyectos más importantes e identifica los que requieran computación paralela masiva y grandes conjuntos de datos, y que serían más rentables utilizando Hadoop.

5. Por último, busca cargas de trabajo existentes para descargarlas.

Figura 4-2. Árbol de decisión de la estrategia del lago de datos

Conclusión

Hay muchas formas de llegar a un lago de datos. Aunque cada situación es diferente, las Implementaciones con éxito tienden a compartir varios rasgos: un plan claro y deliberado, la contratación de entusiastas adaptadores tempranos de y la demostración de un valor inmediato.