Cómo migrar tu DWH a un Data Lake sin morir en el intento: Parte 3 – factores clave

En esta tercera parte de la serie de artículos sobre «cómo migrar un Data Warehouse a un Data Lake«, vamos a comentar los aspectos clave sobre los que hay que prestar especial atención a la hora de abordar con éxito un proyecto de esta envergadura. Estos factores constituyen una serie de puntos que, en caso de no revisarlos, entenderlos y tenerlos en cuenta en el proyecto de manera temprana, podrían generarnos quebraderos de cabeza en el proceso de migración del DWH a un Data Lake. 

Particularidades de los sistemas

Habitualmente los sistemas de una organización son muy diferentes y han ido evolucionando de manera distinta. Esto provoca que existan muchas particularidades que, si no se detectan en la fase Discover, puede hacer que el diseño de la arquitectura deseada no se sostenga a la hora de implantarlo. Para evitarlo, es necesario hacer hincapié con los responsables de cada área en que se describan todos los procesos, ya sean manuales o automáticos, en los que tienen implicación.

Procesos manuales

Es un hecho que en todas las organizaciones existen procesos manuales. Todo el mundo se lleva las manos a la cabeza, “pero ¿cómo se está haciendo esto a mano?”, hasta en los mejores staff tecnológicos puede existir alguna manualidad. La realidad es que el problema no suele acabar aquí, el problema se suele agravar porque solo conocen dicha manualidad un grupo reducido de personas en la organización.

Documentación necesaria

Enlazando con el punto anterior, en la fase de análisis inicial los problemas suelen venir derivados por una carencia de documentación de procesos que permita conocer el correcto funcionamiento de cualquier sistema. De igual modo, en caso de existir documentación ésta suele estar desactualizada, lo que ralentiza el proceso de análisis por la necesidad de tener que actualizarla. Es importante tener una metodología de actualización de documentación firme y aplicarla cada vez que se modifique un proceso para poder evitar este tipo de problemas. Por pequeñas que sean las modificaciones hay que hacer el esfuerzo de actualizar la documentación. Nunca ser sabe cuando puede llegar la necesidad de tener que consultarla y esta migración de un DWH  a un Data Lake es un ejemplo claro.

Definición detallada de cada uno de los proyectos

Uno de los grandes pilares que aseguran que el proyecto salga según los cauces iniciales establecidos es la definición, tanto técnica como funcional, del proyecto. Como comentábamos, en la fase Delivery es imprescindible tener clara la situación actual y deseada, pudiendo así dividir el proceso de migración en líneas de trabajo intermedias o fases que permitan abordar cada una de ellas con garantías de éxito. En caso de no realizarse minuciosamente este análisis y definición, se pueden generar situaciones en las que haya que rehacer parte de dichas definiciones, lo que provocaría que el proyecto se retrasara o incluso que pudiera llegar a tener que cancelarse. Por tanto, resulta evidente la importancia de que todos los integrantes del equipo estén de acuerdo con las definiciones del usuario y que el equipo de desarrollo no tenga ninguna duda sobre lo que debe hacer porque, si una de las dos patas cojea, la mesa no se sostendrá en el futuro.

Metodología de trabajo acorde a cada fase del proyecto

Cada tipo de proyecto necesita una metodología concreta para funcionar de manera óptima, logrando que las metas establecidas se cumplan en los plazos establecidos. Para seleccionar la metodología que mejor se adapta a un proyecto es necesario tener en cuenta una serie de factores: nivel de definición inicial de las necesidades, probabilidad de cambios de prioridades, posibles cambios en las definiciones ante nuevas necesidades o cambios en el contexto de la compañía (aspectos regulatorio, cambios de mercado, etc), demanda de nuevas funcionalidades…

Una migración de un DWH a un Data Lake constituye un proyecto de gran envergadura. Nuestra recomendación siempre es abordarlo en fases incrementales. De esta manera, comenzaríamos por un proyecto inicial, que implique el desarrollo de los pilares del futuro Data Lake. Este primer proyecto también podría abordarse para acometer un primer caso de uso que sirva como base para luego ir incorporando el resto. Básicamente, lo estaríamos enfocando como un MVP, producto mínimo viable, en el que el alcance estaría bien definido. Aquí suelen funcionar bien las metodologías tradicionales, directas y rápidas. Por otro lado, cuando se empieza a evolucionar el MVP con nuevas funcionalidades y nuevos casos de uso, tienen mejor encaje las metodologías ágiles.

Cambios de esquema en orígenes de datos

Habitualmente suelen producirse cambios de esquema en las fuentes de origen. Esto puede impactar directamente sobre la información que ya esté siendo consumida por herramientas de reporting, por lo que se deben establecer procedimientos técnicos y funcionales para mitigar su riesgo. Diseñar técnicamente el proceso de ingesta en el Data Lake para que sea dinámico y no se vea afectado por estos cambios debe ser uno de los principales objetivos. Es necesario establecer procedimientos para detectar cuándo se producen estos cambios y si pueden impactar o no al correcto funcionamiento del sistema. En este sentido, se pueden automatizar procesos técnicos que manden notificaciones a las áreas implicadas que usan esa información para que tomen las medidas necesarias, evitando que se den cuenta de manera reactiva cuando su sistema ha dejado de funcionar. Habitualmente, las empresas con mayor cultura del dato suelen tener políticas y procedimientos que mitigan este tipo de problemas. Sin embargo, en empresas menos maduras en lo relativo a la gestión del dato estos cambios pueden suponer problemas serios necesarios de solucionar.

Gobierno de Dato

Al principio del artículo hemos comentado que la diferencia entre un Data Lake y un DWH, entre otras cosas, radica en la dicotomía schema on-read y schema on-write, de manera que se ingestan fuentes de datos en el Data Lake sin verificar su esquema previamente. Esto puede derivar en que el Data Lake quede inservible si se llena de “basura” que ocupa espacio y nunca es consumida. De igual modo, si no existe un control sobre lo que hay, quién accede, los permisos que tienen los usuarios, quién es el dueño de la información, cómo se comparten los datos en la organización, etc., el sistema informacional queda inservible. Es de vital importancia establecer unas políticas y procedimientos de gobierno del dato que hagan que el sistema informacional funcione correctamente y se garantice su estabilidad a largo plazo.

Normativas de protección de datos

Las normativas de protección de datos son cada vez más exigentes debido a los recientes escándalos relacionados con el uso de los datos, como el de Cambridge Analytica y Facebook. La normativa europea, GDPR, es una de las más restrictivas sobre la gestión del dato. El Data Lake que se diseñe debe estar perfectamente alineado con la normativa y ser capaz de responder tecnológicamente a las necesidades de la misma. Un ejemplo claro es tener trazabilidad de toda la información de cada usuario, de manera que, si el usuario se da de baja o modifica sus permisos de acceso, el sistema responda rápidamente y ejecute las acciones pertinentes. 

Otra de las consideraciones es la gestión de los datos personales PII (Personally identifiable information). Si se ingestan todas las fuentes de datos sin tener un control exhaustivo sobre qué se está metiendo en el Data Lake se puede estar incurriendo en un problema si hay datos PII. Por tanto, es necesario establecer controles técnicos que comprueben si existen datos PII sin proteger y lanzar alertas para desencadenar acciones que solucionen el problema.

El proceso de migración de un DWH a un Data Lake es un proyecto muy complejo. Sin embargo, los beneficios que presenta hacen que compense con creces el esfuerzo de abordarlo. Eso sí, queda claro que es imprescindible realizar un proceso de análisis profundo sobre las implicaciones que tiene y sobre la mejor manera de implementarlo, dado que de lo contrario podemos no cumplir las expectativas generadas. 

"¡Analiza, Define, Planifica y Construye!"

El primer paso es definir la Data Strategy para dotar a la organización de una visión estratégica sobre cómo se va a abordar el proceso de transformación, proceso que consta de tres fases: Discover, Develop y Delivery.

Desde BI Geek llevamos varios años ejecutando este tipo de proyectos, lo que nos ha dotado de una visión amplia y de una metodología propia que nos permite optimizar al máximo la ejecución de estos proyectos de manera satisfactoria.

Esperamos que esta serie de artículos te haya resultado útil para entender mejor el proceso de migración de un DWH a un Data Lake. Ante cualquier duda o sugerencia no dudéis en poneros en contacto con nosotros, estaremos encantados de responderlas.

 

En BI Geek, consultora de Analítica Avanzada y Big Data, apostamos por un modelo de consultoría orientado a hacer accesibles este tipo de soluciones para cualquier tipo de empresa.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.