¿Está muerto el lago de datos?

Suposición #1: "El almacenamiento de datos es caro, así que construyamos nuestro lago de datos Hadoop, donde la economía se vea mucho más atractiva."

¿Cómo se ve esta asunción en retrospectiva?

Para estar seguro, mi experiencia ha sido que el TCO por GB de almacenamiento en Hadoop puede ser del 5 por ciento o menos que el costo de los sistemas tradicionales de RDBMS. Pero, incluso las empresas más experimentadas aprendieron rápidamente lo difícil que era operar un cluster empresarial. Las constantes actualizaciones del software de código abierto, la escasez de conocimientos para gestionar un entorno y la relativa inmadurez del ecosistema crearon fallos técnicos y dependencias difíciles de gestionar. Además, una vez que Hadoop había completado la replicación de datos tres veces y los administradores requerían instantáneas y copias para superar las limitaciones de las actualizaciones de Hadoop, 1 TB de datos de RDBMS podía convertirse en 50 TB en el lago. Hasta ahí llegó ese ahorro.

La Realidad Emergente: Nube y almacén de datos en la nube

Amazon, Microsoft y Google se apresuraron a llenar estos vacíos de productividad con entornos gestionados y basados en la nube, lo que simplificó la administración e hizo que los científicos de datos fueran más productivos con mayor rapidez. Luego, los modelos de consumo reemplazaron los costos de capital de los ambientes Hadoop on-prem, lo que significó que la gente estaba menos inclinada a simplemente volcar todos sus grandes conjuntos de datos en un ambiente central. Más bien, cargaron los datos según lo requerido para el análisis. Esto, como resultado, tuvo el efecto de alejarse de los grandes lagos de datos on-prem a estanques de datos más pequeños basados en nubes que fueron construidos con ese propósito. Llevando esto un paso más allá, los nuevos almacenes de nubes han hecho que el acceso y la consulta de estos datos sea simple con herramientas basadas en SQL, que liberan aún más el valor de los datos a los consumidores no técnicos.

Suposición #2: "Los grandes datos son demasiado grandes para moverlos. Mueve los datos una vez y mueve la computadora a los datos."

¿Cómo se ve esta asunción en retrospectiva?

Una suposición clave del lago de datos fue que las limitaciones en la red y la velocidad de procesamiento significarían que no podríamos tomar grandes copias de los datos, como los archivos de registro, y moverlos a un clúster para el análisis de datos. Hadoop también estaba orientado a lotes, lo que significa que grandes lotes de estos tipos de datos eran muy poco prácticos. Resulta que las mejoras en la replicación y el flujo de datos, así como los tremendos beneficios en la red, han hecho que esto sea menos cierto de lo que pensábamos.

La Realidad Emergente: Virtualización y transmisión de datos

Las mejoras en la tecnología han hecho que las empresas tengan opciones en cuanto a la forma de acceder a los datos. Tal vez quieran descargar las consultas de los sistemas transaccionales a un entorno de nube; la duplicación y la transmisión de datos son ahora soluciones fáciles. Tal vez, se construye un sistema transaccional para consultas de alto rendimiento; en ese caso, las capacidades de virtualización de datos pueden hacer que esos datos estén disponibles a pedido. Como resultado, las empresas tienen ahora opciones para hacer que los datos estén más disponibles a pedido para los procesos de DataOps, lo que significa que no siempre existe la necesidad de centralizar todos los datos de la empresa físicamente en un solo lugar.

Supuesto #3: "El esquema del lago de datos en lectura reemplazará al esquema del almacén de datos en escritura".

¿Cómo se ve esta asunción en retrospectiva?

La gente estaba harta de cuánto tiempo le tomaba a los equipos de IT escribir ETL en los almacenes de datos y estaban desesperados por simplemente liberar a los científicos de los datos en bruto. Había dos grandes puntos de fricción. En primer lugar, los científicos de datos a menudo no podían encontrar fácilmente los datos que estaban buscando. En segundo lugar, una vez que tenían los datos, los líderes analíticos pronto descubrieron que su ETL fue simplemente reemplazado por herramientas de disputa de datos porque la ciencia de los datos todavía requería limpieza, como la estandarización y la coincidencia de claves extranjeras.

La realidad emergente: Catálogos de datos y DataOps

Un catálogo de datos inteligente se ha vuelto esencial para encontrar los datos que necesitas. Las empresas ahora están tratando de establecer el mismo tipo de búsqueda en Google que un usuario disfruta en su casa o en su lugar de trabajo con soluciones sencillas para encontrar y acceder a los datos, independientemente de la ubicación física de los almacenes de datos que los contienen. Los procesos de DataOps también han surgido como una forma de establecer conjuntos de datos basados en dominios que son cuidadosamente planificados y gobernados para permitir la máxima productividad analítica. Así pues, un científico de datos debe poder encontrar fácilmente y confiar en los datos que está utilizando para descubrir nuevos conocimientos, y una combinación bien pensada de tecnología y procesos debe permitir la rápida puesta en marcha de conductos de datos y conductos de análisis para apoyar estos nuevos descubrimientos. Este proceso puede permitir el análisis en tiempo real.

A medida que en Qlik buscamos modernizar nuestra arquitectura analítica de datos, estas realidades emergentes clave están en la vanguardia de nuestro pensamiento:

• Arquitecturas analíticas y de aplicaciones basadas en la nube

• Un resurgimiento de las estructuras de Data Warehouse/RDBMS en la nube para maximizar el valor (piensa en Snowflake)

• Transmisión de datos para reducir la latencia de los datos clave

• Virtualización de datos para reducir la copia de datos hasta que se requiera

• Catálogos de datos para inventariar y gestionar cuidadosamente el acceso a los datos de la empresa

• El surgimiento de procesos de DataOps para crear un rápido tiempo de comercialización de los datos y de las tuberías de análisis.