Key Tips #1: Evita estos errores al configurar Data Lakehouse en Microsoft Fabric

¡Hola de nuevo! ✨

En la serie pasada de Microsoft Fabric de 0 a 100 les conté -a alto nivel- sobre Lakehouse y mostré como crear uno fácilmente.

Conceptualmente hablando Lakehouse proviene de dos cosas: Data Lake + Data Warehouse, combinando lo mejor de ambos mundos (el almacenamiento a gran escala de Data Lake + la estructuración de datos y capacidad de realizar consultas y análisis avanzados de Data Warehouse).
En resumen, Lakehouse nos permitirá almacenar, administrar y analizar todo tipo de datos (estructurados y no estructurados) en la misma plataforma de Microsoft Fabric.

Pero como dicen no existe el bien sin el mal o mejor dicho, todo poder conlleva una responsabilidad jaja…

¿A que me refiero? Pues, así como existen muchos beneficios y sobre todo tenemos la facilidad y rapidez para aprovisionar uno, casi siempre nos vamos a topar con algunos errores que son más comunes de los que se imaginan; errores que a mediano o largo plazo pueden ocasionar problemas como rendimiento o complicarnos la vida al momento de administrar nuestros datos.

Errores más comunes al implementar un Data Lakehouse

A continuación, intentaré listar algunos de los más frecuentes con los que me he encontrado o me han hablado:

• Error 1: Mala organización de la estructura de carpetas en OneLake
  

No planificar bien el cómo almacenar los datos es algo tan común, sobre todo en organizaciones que hicieron una migración “rápida” a la nube y/o fueron construyendo todo sobre la marcha.

¿Resultados? Un Lakehouse sin taxonomías definidas, esquemas “temporales” o que funcionan como sandbox, tablas duplicadas o peor aún tablas de las que nadie sabe que existen, pero están ahí, ocupando espacio, entre otros.

Siempre digo que la planificación es algo muy importante en cualquier aspecto en nuestra vida, y nuestro Lakehouse no se escapa de ello, o mejor dicho la solución de datos que vamos a implementar debe pasar por una etapa de diseño y estructuración de: jerarquías de datos, tipos de almacenamientos a usar, definir taxonomías tanto para esquemas, tablas y/o columnas, tipos de datos, campos comunes para particionar la data, etc. Esto es un trabajo que aparenta ser sencillo pero la realidad es diferente, ya que aquí deben participar diferentes roles para ponernos en diferentes situaciones de “qué pasa sí…”. ¿Para una “taxonomía”? Si, inclusive para ello. ¿Porque imagínate tener que compartir algunas tablas con otra subsidiaria o proveedor, etc.? Necesitas contemplar diferentes escenarios y sobre todo que quede a modo de estándar y lineamiento documentado al cual cualquier colaborador pueda acceder.

• Error 2: No optimizar el formato de archivo para grandes volúmenes de datos

Si bien es cierto -pensando en una arquitectura medallion- tenemos una primera zona de datos (bronze o raw) donde llegan o aterrizan nuestros datos de diversas aplicaciones sin ningún tipo de transformación, no debemos olvidar el formato en el que se alojarán en el lakehouse. 

El uso de delta parquet es el más recomendable en estos escenarios. Trabajar con formatos de tipo delta parquet nos permite realizar transacciones ACID, tener un control de los metadatos o realizar time travel, sin mencionar el hecho de este formato está optimizado para procesos de análisis de datos a gran escala, también es una pieza fundamental para mejorar el rendimiento en la lectura y/o escritura de datos.

• Error 3: Ignorar las configuraciones de seguridad y permisos

Creo que no hace falta explicar a detalle por qué el dejar acceso “abierto” o no establecer roles específicos para que los usuarios y grupos accedan y/o operen sobre los activos de datos en un riesgo latente.

Definir y configurar políticas y procedimientos para brindar accesos es una tarea que debe realizarse desde el principio con la finalidad de proteger a la empresa de posibles fugas de información, errores humanos, acceso a información sensible, etc.

El trabajo colaborativo con seguridad, gobierno, arquitectura de datos, entre otros roles es vital en este punto.

• Error 4: No implementar particionamiento adecuado en tablas

Si quieres evitar ser un número más en las estadísticas de empresas que sobrepasan “accidentalmente” su presupuesto mensual respecto al consumo en nube, particionar las tablas grandes es algo igual de importante que los puntos anteriores.

Recuerda que hay servicios que cobrar inclusive por TB de consulta o por tiempo de operación y leer una tabla de TBs de manera recurrente puede implicar elevar tu factura mensual.

Revisa constantemente el volumen de tus tablas, la frecuencia con la que acceden a ellos y sobretodo los campos más utilizados en tus procesos de integración y análisis para crear tus particiones.

• Error 5: Configuración incorrecta de pipelines de datos

Otro error bastante común es dejarnos llevar por el tiempo. A más de uno le ha pasado que con tal de entregar un producto rápido porque “lo queremos ASAP”, lo desarrolló sin evaluar o implementar mejores prácticas, sin monitorear el rendimiento, entre otros, y solo se enfocó en que el proceso termine “en verde”, osea todo bien.

Valida y asegúrate siempre que tus pipelines o tu desarrollo en general: cumpla con los lineamientos existentes, se cifre la información sensible de ser necesario, optimizar pasos en la ejecución, parametrizar todo lo que se pueda dentro de un marco aceptable y sostenible, validar tiempos de ejecución y plantear escenarios de fallos, entre otros. Caso contrario, esto impactará en tiempos de ejecución, posibles errores en la integridad o disponibilidad de datos y por tanto -y en resumen- en dinero y tiempo para corregir dichos problemas.

Conclusiones

La experiencia que adquirimos a partir de aciertos y desaciertos propios (o ajenos) es algo que nos ayudará a interiorizar y mejorar estos puntos.
Los lineamientos, políticas, procedimientos o planificaciones son amigos, no enemigos. Créeme, el tú o los “ustedes” del futuro sentirán alivio de no experimentar las consecuencias de estos errores.

Hemos llegado al final del post. Cuéntame, ¿tienes alguna anécdota o error que también hayas visto?

– Key