Lagos de datos, almacenes de datos, centros de datos: ¿son necesarios?
Existe un debate de larga data, que se remonta a los inicios de Hadoop, sobre qué tipo de repositorio de datos es el más adecuado para un caso de uso concreto de análisis de datos. ¿ Un lago de datos? ¿Un centro de datos? ¿Un almacén de datos? A pesar del declive de Hadoop, el debate no solo persiste, sino que se complica cada vez más. Los repositorios actuales basados en la nube, como AWS S3, Microsoft Azure ADLS y Google Cloud Storage, se parecen mucho a los lagos de datos en la nube. Del mismo modo, las ofertas basadas en la nube como Snowflake se parecen mucho a los almacenes de datos empresariales, pero en la nube. Es cierto que, para realizar una comparación equitativa con los lagos de datos, habría que reducir Hadoop a solo HDFS o añadir las herramientas de gestión del repositorio de datos, consulta, etc., asociadas a las carteras de los tres proveedores de nube pública.
Al mismo tiempo, cabe señalar que ninguno de los proveedores que promocionan estas ofertas utiliza esos términos... Microsoft, Amazon y Google denominan a sus repositorios en la nube «centros de datos empresariales». Snowflake se posiciona como un almacén de datos en la nube, pero está dando un giro para autodenominarse «plataforma de datos en la nube» gracias a su amplio ecosistema; sin embargo, por sí solo, es en realidad un «motor de análisis».
Cambiar el descriptor no cambia la cuestión que impulsa el debate, sin embargo, y la simple verdad es que ningún lago de datos, centro de datos, ni un almacén de datos - sur site o en la nube - ha sido capaz de apoyar eficazmente a todos los equipos multidisciplinares de analistas de negocio, ingenieros de datos, científicos de datos y usuarios avanzados dentro de las diferentes líneas de negocio. Eso era evidente antes de que existiera la nube, y se ha hecho más evidente a medida que los equipos tratan de incorporar nuevos conjuntos de datos (piense en servicios web e IoT) y tratan de fusionar datos semiestructurados en repositorios estructurados. No quiero ni hablar del torrente de hojas de datos de Excel que se suponía que iban a desaparecer (pero nunca lo hicieron) cuando nos volvimos más sofisticados en el análisis y la gestion des données.
Pero la cuestión es la siguiente: existen diferencias reales entre estas plataformas, y es importante comprenderlas. Sin embargo, al final —fíjate bien—, las diferencias operativas entre estas plataformas no son la causa principal de que no estén ofreciendo el apoyo que esperan todas las partes interesadas.
Ajuste del nivel
Empecemos por hablar de lo que realmente estamos hablando:
Centro de datos
Aquí definiremos un concentrador de datos como una pasarela a través de la cual los datos virtuales o físicos pueden fusionarse, transformarse y ponerse en cola para su paso a otro destino. Ese destino puede ser una aplicación, una base de datos u otro tipo de repositorio (como un lago de datos o un almacén de datos). En cualquier caso, los datos en un concentrador de datos son transitorios; no se almacenan localmente y no tienen persistencia.
Un ejemplo de centro de datos sería algo como Informatica, que puede gestionar cualquier tipo de datos imaginable y conectar fuentes y destinos de datos tanto en sentido ascendente como descendente. Históricamente, los centros de datos han sido gestionados y utilizados por personal de TI que trabaja con grupos aislados de toda la empresa para crear integraciones donde, de forma natural, no existían.
Lago de datos
A diferencia de un centro de datos, un lago de datos actúa como un repositorio de datos persistentes. No es simplemente un punto de paso. Los lagos de datos suelen ser capaces de incorporar y gestionar casi cualquier tipo de datos y, tal y como ilustra el ejemplo de Hadoop (históricamente el tipo de lago de datos más popular), proporcionan herramientas para enriquecer, consultar y analizar los datos que contienen. El problema es que los lagos de datos suelen ser entornos de pruebas en los que se vierten grandes conjuntos de datos utilizados en proyectos experimentales por personal técnico altamente cualificado, principalmente de TI y desarrolladores.
Almacén de datos
Un almacén de datos se diferencia de un lago de datos en que actúa como repositorio de datos persistentes y, principalmente, estructurados, que se van acumulando de forma incremental a lo largo del tiempo a partir de múltiples silos de fuentes de datos posteriores. Un almacén de datos también se diferencia de un lago de datos en que requiere algún tipo de tecnología de centro de datos para preparar los datos para su ingesta. Los almacenes de datos locales, como los de los grandes proveedores tradicionales —Oracle, IBM y Teradata—, están muy centrados en las TI y son gestionados por uno o varios administradores de bases de datos (DBA). Aunque la mayor parte de los datos que utilizan los usuarios empresariales puede residir en última instancia en un almacén de datos, la mayoría de estos usuarios no interactúan directamente con él y es posible que ni siquiera sepan que lo tienen o qué es.
El caucho virtual se encuentra con la carretera virtual
Históricamente, los centros de datos, los lagos de datos y los almacenes de datos tienen varios puntos en común: todos ellos requieren personal con competencias especializadas para su configuración, mantenimiento y gestión. Se trata de expertos capaces de convertir las solicitudes de los usuarios empresariales y analistas sin conocimientos técnicos en consultas e informes que puedan ejecutarse en estos repositorios de datos.
Por cierto, la complejidad de estas plataformas es una de las razones del declive de Hadoop. Los lagos de datos de Hadoop tendían a convertirse en vertederos de datos, y solo podían gestionarlos los desarrolladores y el personal de TI muy cualificado (y costoso), lo que limitaba el valor empresarial que un lago de datos de Hadoop podía generar. No es del todo sorprendente que, como consecuencia, de los tres grandes proveedores que antes daban soporte a Hadoop, solo Cloudera siga siendo el último «superviviente».
Esta necesidad de recursos especializados ha influido también en el uso de los centros de datos, los lagos de datos y los almacenes de datos de otras formas, lo que a su vez ha complicado aún más la cuestión inicial sobre qué plataforma es la más adecuada para los distintos casos de uso. Con el paso de las infraestructuras locales a las basadas en la nube, se ha producido una reducción de la demanda de todos estos recursos especializados. Los proveedores de servicios en la nube han ido proporcionando cada vez más apoyo operativo, lo que ha contribuido a reducir los costes operativos. Además, los cambios arquitectónicos en las últimas generaciones de ofertas en la nube (ofertas separadas de computación y almacenamiento, pago por uso, etc.) han creado nuevos incentivos para migrar a la nube con el fin de reducir costes.
Aumentar aún más la complejidad
Sin embargo, aunque se han producido todos estos cambios estructurales, la necesidad fundamental de obtener información basada en datos no ha cambiado. La respuesta a la pregunta sobre cuál es la mejor forma de obtener esa información se ha vuelto aún más difícil de dar. Los datos que antes se almacenaban en lagos de datos o almacenes de datos locales (a través de centros de datos) ahora se trasladan a la nube, pero las ofertas en la nube no son exactamente iguales a las que había en las instalaciones locales. Sus modelos de almacenamiento de objetos difieren. Microsoft, Amazon y Google ofrecen almacenes de datos persistentes y, en ese sentido, pueden parecerse a un lago de datos, pero dependen de otras herramientas para desempeñar las funciones de centro de datos y, por lo tanto, no pueden definirse como nada más que almacenes de datos. Siguen requiriendo integración de datos o funcionalidad de centro de datos, y su valor empresarial es limitado, tal y como siempre lo ha sido. Las personas que generan directamente valor empresarial —los analistas de negocio, los científicos de datos y (a falta de un título específico), los demás usuarios avanzados de las líneas de negocio— siguen sin poder acceder fácilmente a la información contenida en los datos ni extraerla.
Hoy en día, la mayoría de los analistas de negocio y usuarios avanzados utilizan las funciones integradas de análisis y visualización de aplicaciones aisladas, como Salesforce, Marketo o cualquier plataforma ERP que necesiten para comprender las operaciones empresariales o los resultados históricos. Al mismo tiempo, se esfuerzan por ir más allá. Los usuarios empresariales pueden intentar incorporar datos de archivos planos, como Excel, o datos JSON semiestructurados a los que se accede a través de API de servicios web. A menudo, recurren al departamento de TI para exportar datos de uno o varios sistemas, combinarlos con hojas de cálculo de Excel y enviarlos periódicamente a un cubo. El resultado es dolorosamente familiar: flujos de datos aislados vinculados a resultados de análisis y visualización igualmente aislados. Sin que estos usuarios empresariales lo sepan, cuando recurren a la ayuda del departamento de TI, es posible que en realidad estén utilizando un centro de datos, ya que en este no hay persistencia de datos; simplemente han utilizado el centro como un conector para unir un conjunto de silos de datos y un silo de análisis con el fin de crear un silo ad hoc para la organización o el proyecto.
Es posible que los científicos de datos y los ingenieros de datos utilicen muchos de los mismos silos de datos, pero también pueden recurrir a datos procedentes de conjuntos de datos semiestructurados, como flujos de clics, el Internet de las cosas (IoT) y servicios web, y sus destinos pueden incluir las mismas herramientas de visualización, aunque, por supuesto, también incluyen herramientas de análisis avanzadas para dar soporte a la IA y el aprendizaje automático (ML). Pueden recurrir al departamento de TI para que les facilite los datos y, a su vez, crear la misma red de conexiones punto a punto, similar a un «espagueti».
Dicho de otro modo y simplificando, el repositorio único compartido de datos prometido por los lagos de datos, los almacenes de datos y los concentradores de datos sigue siendo un sueño irrealizable. Todavía no se ha creado un verdadero centro de análisis, ni en las instalaciones ni en la nube.
Todavía.
Cambiar el enfoque
Los proveedores de servicios en la nube están empezando a darse cuenta del problema y algunos están cambiando rápidamente para solucionarlo. Sin embargo, la forma en que lo están haciendo la mayoría de ellos es asegurándose de que un almacén de datos en la nube pueda actuar como un repositorio de datos ascendente para cualquier herramienta descendente de análisis, informes y visualización. A menudo esto se intenta a través de un ecosistema de socios, como en Snowflake. Esto es necesario, pero insuficiente para el centro de análisis que todos necesitamos.
Pero espere. ¿Un centro de análisis? ¿Dónde estaba eso en las definiciones anteriores?
La realidad es que el almacén de datos en la nube es, en la actualidad, un motor de análisis, pero sin un centro de datos integrado en el back-end y centrado en conexiones puntuales independientes con diversas herramientas de BI y análisis en el front-end. Proveedores como Snowflake no mencionan los centros de análisis, y mucho menos afirman serlo. Además, sin la capacidad de obtener fácilmente datos de las fuentes de datos y vincular elementos compuestos de datos procedentes de esas diversas fuentes para su presentación en las herramientas de análisis, no se dispone realmente de un centro de análisis, principalmente porque no se cuenta con un centro de datos.
En lugar de limitarse a un centro de datos o a un centro de análisis —ambos exclusivos del departamento de TI—, lo que realmente se necesita es un centro de análisis de datos que puedan utilizar una amplia variedad de usuarios, tanto del departamento de TI como del ámbito empresarial. En la próxima entrada del blog te contaremos más sobre qué es esto y por qué es importante.
Mantente conectado
Te ofrecemos información detallada sobre los datos.
(por ejemplo, sales@..., support@...)
