Voy a empezar con un «DISCLAIMER». Esto es, más que una metodología, una forma de pensar en como empezar a llevar adelante la incógnita en el titulo. Parto de la base que si estamos aquí, es por qué ya sabemos que es un Data Lake y no voy a entrar en demasiado detalle aunque si repasar algunos conceptos para poder entender por qué tomo alguna decisiones a la hora del diseño. Este no es un método infalible y lo voy a ir modificando a medida que gane experiencia al diseñar los mismos. Con mi corta experiencia, si alguien tiene alguna sugerencia, les pido que comenten para aportar a la discusión. Probablemente esto se convierta en una cadena de posts.
Empezando, deberíamos repasar una serie de preguntas:
- ¿Como se va a usar el Data Lake? O en otras palabras ¿Que uso le van a dar los usuarios a los datos?
- ¿Que información vamos a guardar?
Estas son en realidad, dos preguntas clásicas para diseñar una base de datos. La primera habla de la perspectiva de como los clientes usan los datos, y la segunda nos habla de que información necesita el cliente para hacer sus reportes o análisis. La realidad, es que el cliente siempre va a pedir algo del estilo «pone todo en el Data Lake» pero es nuestro trabajo tratar de enfocar al cliente primero en conseguir lo que el realmente necesita y no otra cosa. Lo primero que tenemos que entender es que el Data Lake no es un tacho donde ponemos cualquier cosa. Al Data Lake, solo va la información que entendemos para que sirve y como se combina con el resto de la data que esta ahí, sino se convierte en el infame «Data Swamp».
Ahora ¿para que se usa un Data Lake? En general, en base a experiencia personal, para análisis lo que quiere decir una cosa a nivel diseño de bases de datos: es un modelo desnormalizado. Esto se debe principalmente a dos motivos:
- El cliente va a estar consultando mucha información a la vez en el DataLake, por lo tanto tenemos que evitar que tenga que hacer muchos JOINs.
- Para hacer análisis, es poco probable que la información se actualice en vivo. En general, los analistas hacen escaneos de información en rangos grandes de tiempo, por lo tanto tener hasta el ultimo segundo, no suele ser relevante para ellos.
En principio, podemos asumir que vamos a diseñar las tablas en el Data Lake, como si fuera un Data Warehouse (DW), pero esto no quiere decir que el Data Lake entero va a estar compuesto de varios DW. Es una buena idea crear un DW cuando necesitamos el histórico de ciertos valores, en general los que se representan en las dimensiones de un modelo estrella o cuando tenemos una serie de métricas que se pueden agregar en base a algún parámetro. Por ejemplo, si queremos saber el histórico completo de lo que se facturo para un cliente por día en un rango de fechas, el modelo estrella es un excelente modelo para esto. Ecosistemas hechos en Hadoop, tienen herramientas como Hive que son ideales para esto. En un DW, no necesitamos hacer updates excepto en algunos valores en las dimensiones (y dependiendo el tipo de dimensión), pero en la tabla de hechos que es la mas grande y la mas consultada, solo se corren INSERTS (o quizás algún DELETE de vez en cuando).
Hay otras fuentes de datos que quizás no convenga esforzarse por insertar en formato estrella. Supongamos que tenemos un proyecto de «Internet of Things» (IOT) en donde tenemos una serie de artefactos que insertan registros de manera continua. Tener simplemente una tabla donde se loguean todos los eventos con sus descripciones, etc, quizás sea lo mejor para leer e insertar rápido en la misma. Si están trabajando sobre Hadoop, recuerden que necesitan un proceso batch que corra periódicamente para extraer la información. Esto quiere decir que van a necesitar «algo» que funcione como buffer. Si necesitan insertar y consultar la información en vivo (por ejemplo para un sistema de monitoreo en vivo), quizás una tecnología como Cassandra sea mucho mas útil para el caso.
Por otro lado, el caso mas complejo que me encontré hasta ahora fue el siguiente: Mi cliente tenia dos bases de datos relacionales grandes que se ocupaban de dos áreas del negocio que eran fundamentales para ellos. Dando un poco de contexto, mi cliente ofrece tarjetas de crédito. Un área se ocupaba de lo que seria «adquisición de nuevos clientes» y la otra de «datos sobre clientes actuales». Por diversos motivos, mi cliente pidió distintas columnas que estaban relacionadas de muchas maneras distintas entre si en estas bases relacionales. En este caso, trate de encarar el problema por el lado de encontrar las entidades que eran principales dentro de cada sistema. Todas las bases de datos tienen tablas que son más importantes que otras en términos del negocio. Lo que hice luego, fue desnormalizar los datos que estaban referenciados a estas tablas y recrear estas mismas en mi Data Lake con todos sus atributos dentro (en otras palabras sin ids con FK). Si bien esto no le permite a mi cliente ver el histórico completo (haría un DW para eso), les permite de manera fácil, ver el estado actual de cada área del negocio. Entonces, lo que queda, son entidades principales con todos sus valores dentro con los identificadores que las relaciona entre si. Esto le permite a mi cliente correr un reporte diario con el estado del negocio a la mañana antes que todos sus empleados entren a trabajar en poco tiempo. El problema, es obviamente el procesamiento y actualización de estos datos periódicamente.
Por ahora esto parece suficiente. Acepto cualquier tipo de crítica o sugerencia respecto a los temas expuestos y desde ya le agradezco por cualquier sugerencia que puedan aportarme.
Saludos,
Alejandro
SQAleTec 