Data Warehouse y Data Lake: Big Data para gente de Marketing (2):

El mundo de los datos es un terreno pantanoso para aquellos que venimos del mundo del marketing. Uno de temas que a menudo generan un gran número de preguntas es tratar de entender las diferencias entre algunos conceptos fundamentales como los Data Warehouse, los Data Mart y los recientemente llegados Data Lakes. En este artículo voy a intentar describir cada opción con la esperanza de ayudar a aclarar dudas.

Los Data Warehouse y los Data Marts

En un mundo donde trabajar con cantidades disparatadas de datos empieza a ser la norma más que la excepción era necesario buscar una solución más eficiente de almacenar y procesar grandes volúmenes de información. Los modelos tradicionales corporativos de Business Intelligence (BI) han operado a través del almacenamiento de la información crítica para el negocio en los Data Warehouse corporativos (Enterprise DW o EDW). Estas soluciones han sido, y son, formas eficientes de manejar volúmenes relativamente altos de datos en un formato estructurado, en filas y columnas organizados en tablas, con un esquema relacional.

El término Data Warehouse fue acuñado en un artículo de diario de Sistemas de IBM de 1988  en el que analizaba las necesidades de las organizaciones de mantener sus bases de datos operacionales así como la necesidad de proporcionar capacidades de acceso y análisis a los usuarios finales.

Generalmente los departamentos de Business Intelligence (BI) creaban subconjuntos de la información contenida en el DW para hacerla accesible a ciertas partes del negocio en respuesta a las necesidades específicas de información de sus procesos de negocio. A esta estructura de datos ad hoc se la denomina Data Mart. Es habitual que una empresa cuente con diferentes Data Marts para diferentes unidades de negocio con distintas estructuras de datos. De esta manera se hacia accesible en un formato más eficiente la explotación de los datos de interés para cada unidad de negocio.

La forma habitual de hacer llegar la información a un DW es a través de procesos ETL, es decir realizar una extracción de los datos (Extract) de bases de datos heterogéneas (CRM, ERP…), Transformar los datos (Transform), un proceso en el que se aplican una serie de reglas a los datos para adaptarlos a la estructura de datos de la base de datos de destino, y finalmente Cargarlos (Load) fisicamente en el Data Warehouse. Estos procesos son requeridos precisamente por la necesidad que tienen los DW de mantener sus datos conforme a una estructura definida.

Un ejemplo del proceso de transformación de los datos podría ser el de la fecha de nacimiento, un dato que en origen puede estar en formato fecha se puede transformar en un tramo de edad en la base de datos de destino (18–24 años), al discretizar la variable se esta reduciendo la dimensionalidad lo que tendrá un impacto en el consumo computacional a la hora de trabajar con los datos.

La ambición de capturar e incorporar a nuestras bases de datos fuentes de datos que no estaban estructuradas en origen, y cuya transformación para trabajar con esos datos excedía lo que se puede abordar con un sistema de reglas, ha sido un reto para el que el modelo de Data Warehouse no ha encontrado una buena respuesta. Generalmente esta necesidad es precisamente uno de los factores que suele estar en el origen de muchos proyectos de Big Data. Algunos defienden incluso que es precisamente en el mundo de la información desestructurada o semi-estructurada en el que tiene sentido hablar realmente de Big Data.

Otro de los drivers en la búsqueda de soluciones alternativas a los DW ha sido, sin lugar a dudas, las diferencia de costes a la hora de escalar capacidades comparadas con el mundo del Big Data. Según algunas estimaciones los ahorros están en el orden entre 10 y 100 veces menos costoso desarrollar una solución de Big Data tipo Hadoop.

Hadoop y los Data Lakes

En los últimos años se ha empezado a oír hablar de los Data Lakes, inmensos repositorios de datos que son capaces de almacenar información tal y cómo llega sin preocuparse de si los datos son estructurados, desestructurados o semi-estructurados. El término Data Lake es atribuido a Peter Dixon CTO de Pentaho que en su blog realizaba la siguiente analogía:

Desde un punto de vista técnico quizá sea una definición muy vaga, sin embargo resulta muy intuitiva para entender algunos de los puntos clave para diferenciar un Data Lake de un Data Warehouse (y por supuesto un Data Mart).

En primer lugar la información llega al Data Lake tal y como viene de la fuente original (raw data), sin procesos intermedios de transformación. Esta filosofía implica la segunda característica del Data Lake, su capacidad para  recoger los datos de diversas fuentes sin preocuparse de la estructura o la ausencia de estructura del dato que le llega, se lo traga todo por decirlo de alguna manera.

Otra característica de los Data Lakes es su flexibilidad ya que los datos están en formato raw mientras que un Data Warehouse ha realizado un proceso de transformación y adaptación (ETL) a una determinada estructura antes de guardar los datos. Este es un punto fundamental en la diferencia entre los modelos de un DW y un Data Lake.

Tradicionalmente los Data Warehouse han trabajado en una arquitectura denominada schema-on-write, el fundamento detrás del modelo ETL de la carga de datos en un Data Warehouse. Este modelo obliga a la empresa a definir un modelo de datos y crear un marco analítico previo a la carga de ningún dato, es decir, necesitamos definir que vamos a querer hacer con los datos antes de cargarlos en la base de datos. Evidentemente la definición no es inamovible pero el esfuerzo en tiempo y dinero para cambiar el esquema de un Data Warehouse es mucho mayor.

La filosofía de la ingesta de datos de un Data Lake se basa en otro modelo de arquitectura denominado schema-on-read. En esta alternativa se sigue otra secuencia diferente a la anterior, es decir, en lugar de marcar la estructura de los datos en la entrada a la base de datos es cuando se quieren usar los datos cuando se aplica el proceso de transformación de los datos.

Precisamente al estar el dato en formato bruto (raw data) tenemos la posibilidad de poder adaptarnos para prácticamente cualquier proceso analítico. De esta manera podemos dar respuesta a las necesidades de un usuario típico de negocio a la vez que le damos solución a las mucho más complejas y exigentes necesidades de un científico de datos (Data Scientist).

Un resumen de estas diferencias aparece en el post de Tamara Dull, Directora de Tecnologías Emergentes en SAS, y que recoge este cuadro:

En su artículo Tamara añade varias diferencias a las mencionadas pero quizá quepa destacar la que hace referencia a la madurez por su impacto en la seguridad, un requerimiento fundamental en cualquier entorno profesional. Así mismo también son destacables los retos para establecer un modelo de Gobierno del Dato, un problema que cualquier usuario de datos te puede decir hasta que punto puede convertirse en un problema de cara a garantizar la calidad de los datos.

Es importante saber que al igual que cuando hablamos de Data Warehouse por detrás hay una solución que soporta el modelo (Teradata, Oracle Exadata, SAP Hana, Microsoft SQL Server…) muy habitualmente detrás de un Data Lake lo que está es la infraestructura del sistema de archivos HDFS (Hadoop Distributed File System) que tu utiliza Hadoop. Cuando hablamos de Hadoop en entornos corporativos generalmente hablamos de alguna de las soluciones comerciales de Hadoop tales como Cloudera, Hortonworks, MapR, IBM o Pivotal, las 5 opciones más destacadas en el último informe disponible de Forrester del Q1 de 2016 que puedes descargar desde Cloudera en este enlace.

Funciones de un Data Lake

Tomando como referencia la excelente explicación que hacen Alice LaPlante y Ben Sharma en el capítulo del libro de O’Reilly  Architecting Data Lakes hay cuatro grandes funciones de un Data Lake: La gestión del ingesta de datos, el almacenamiento y procesado posterior de los datos y, por último, el acceso a los datos:

Ingesta de Datos

En esta parte del proceso se definen las reglas mediante las cuales se va a realizar la transferencia de datos a un Data Lake. Una solución de gestión de un Data Lake debe proporcionar control sobre como los datos son ingestados en función de su fuente de origen, el momento en que llegan y donde queremos guardarlos en el Data Lake.

Generalmente la ingestión de datos se realiza en una tabla gigante que se organiza mediante etiquetas de metadatos. Cada dato pieza de dato que llega se aloja en una celda de esa enorme tabla sin importar donde está esa celda, de donde viene el dato o su formato.

Normalmente es en esta fase donde se aplica cierta lógica de Gobierno del Dato. Siguiendo la lógica de la arquitectura de un Data Lake los datos son alojados previamente en un área de staging antes de decidir incorporarlos al Data Lake.

Almacenamiento y Retención de datos

Según parece en el modelo del DW grandes cantidades de espacio de almacenamiento pueden desperdiciarse debido a un problema denominado «sparce table», o traducido de andar por casa, tablas poco densas. La cuestión es que en un Data Warehouse si tenemos que almacenar una tabla que combina datos de dos fuentes diferentes., una que tenga 200 filas y la otra con  400 campos. Para ser capaz de combinarlas tendríamos que añadir 400 columnas en la tabla original de 200 filas. Las filas originales no contendrían datos para esas nuevas columnas y las filas de la segunda fuente no tendrían datos de las 200 columnas originales. El resultado: un montón de celdas vacías.

En un Data Lake, al no necesitar tratar los datos en la ingesta, cada dato ocuparía su celda y no habría desperdicio de espacio. Además al separar el almacenamiento del procesado se puede pagar por espacio de almacenamiento a un coste inferior.

Procesamiento de los datos

Al guardar los datos tal y como le llegar el usuario de los datos en un Data Lake tiene que procesarlos cuando quiere acceder a ellos. Este es la clave de la flexibilidad de este tipo de almacenamiento de datos, cada usuario puede aplicar su estandarización y transformación de los datos según sus necesidades.

Perfectamente se podría realizar sobre el Data Lake un proceso de ETL para cargar los datos que se precisen en un Data Warehouse y proporcionar acceso a la información en un modelo combinado de almacenamiento en el Data Lake y consumo en un Data Mart a partir del Data Warehouse.

Con las herramientas adecuadas se puede procesar los datos en formato Batch o en Streaming, para aquellas aplicaciones que requieran de utilización de los datos en tiempo real. Generalmente para procesos Batch usaremos Pig, Hive, Spark y MapReduce. Para Streaming podemos pensar en Kafka, Flume o Storm.

 Acceso a los Datos

Esta es la fase en la que consumimos los datos del Data Lake. Para acceder a los datos alojados allí tenemos todo tipo de herramientas: consultas a la base de datos, herramientas específicas de extracción de datos e incluso el acceso a través de API.

También ss bastante habitual dar acceso a los datos a usuarios de negocio a través de algún tipo de herramienta de visualización de datos como Qlik o Tableau.