Procesamiento ELT con Couchbase y N1QL

Mover datos entre fuentes de datos. Se trata de una de las actividades clave en los proyectos de integración de datos. Tradicionalmente, las técnicas en torno al movimiento de datos han formado parte de Almacén de datosBI y análisis. Más recientemente, Big Data, Data Lakes, Hadoop, son actores frecuentes en este ámbito.

En esta entrada, discutiremos cómo el lenguaje N1QL de Couchbase puede ser usado para hacer manipulación masiva sobre los datos en este tipo de escenarios.

En primer lugar, recordemos los dos enfoques clásicos a la hora de realizar el movimiento de datos:

ETL (Extraer-Transformar-Cargar). Con este modelo los datos son extraído (de la fuente de datos original), transformado (los datos se reformatean para ajustarse al sistema de destino) y cargado (en el almacén de datos de destino).

ELT (Extraer-Cargar-Transformar). Con este modelo los datos son extraído (de la fuente de datos original), cargado en el mismo formato en el sistema de destino. A continuación, hacemos un transformación en el sistema de destino para obtener el formato de datos deseado.

Nos centraremos en un ELT en este ejemplo. Hagamos una simple exportación desde una base de datos relacional, y carguemos los datos en Couchbase. Utilizaremos Oracle Database como fuente de datos de entrada, con el clásico ejemplo de esquema HR incorporado, que modela un departamento de Recursos Humanos.

Este es el modelo de datos de origen:

En el primer paso, cargaremos los datos con la misma estructura. Existe una herramienta gratuita que puedes utilizar para realizar esta migración inicial aquí. Al final, tendremos documentos JSON mapeando este modelo de tabla:

Por ejemplo, un documento de localización tendrá el siguiente aspecto:

Este fue un primer paso fácil. Sin embargo, este mapeo de tabla a documento suele ser un mal diseño en el mundo NoSQL. En NoSQL es frecuente desnormalizar los datos en favor de una vía de acceso más directa, incrustando los datos referenciados. El objetivo es minimizar las interacciones con la base de datos y las uniones, buscando el mejor rendimiento.

Supongamos que nuestro caso de uso está motivado por un acceso frecuente a todo el historial laboral de los empleados. Decidimos cambiar nuestro diseño por éste:

Para las localizaciones, unimos en un único documento de localización los datos referenciados para el país y la región.

Para el documento del empleado, incrustaremos los datos del departamento, e incluiremos un array con todo el historial laboral de cada empleado. Este soporte de matrices en JSON es una buena mejora respecto a las referencias de clave foránea y las uniones en el mundo relacional.

Para el documento de trabajo, mantendremos la estructura de tablas original.

Así que tenemos extraído y cargado los datos, ahora vamos a transformar en este modelo para terminar nuestro ELT ejemplo. ¿Cómo podemos hacer este trabajo? Es hora de N1QL

N1QL es el lenguaje tipo SQL incluido con Couchbase para el acceso y manipulación de datos. En este ejemplo, utilizaremos dos buckets: HR, que corresponde al esquema original de Oracle HR, y HR_DNORM, que contendrá nuestro modelo de documento de destino.

Ya hemos cargado nuestro esquema HR. El siguiente paso es crear un bucket llamado HR_DNORM. Luego crearemos un índice primario en este nuevo bucket:

Ahora es el momento de crear los documentos de localización. Estos documentos se componen de ubicaciones originales, documentos de país y documentos de región:

Algunas cosas a tener en cuenta:

• Aquí estamos utilizando la proyección de una sentencia SELECT para realizar la inserción. En este ejemplo, los datos originales proceden de un bucket diferente.
• Los JOIN se utilizan en el cubo original para hacer referencia a países y regiones
• Función IFNULL utilizada para establecer explícitamente un valor nulo para el campo state_province
• Función TO_STRING aplicada a un campo numérico para hacer referencia a una clave

Nuestra muestra original se convierte en esto:

Ten en cuenta que hemos eliminado las referencias location_id y country_id.

Ahora es el momento de nuestros documentos de empleado. Lo haremos en varios pasos. El primero es crear los empleados a partir del cubo original de RRHH, incluyendo la información del departamento y del puesto real:

En segundo lugar, utilizaremos una construcción temporal para construir la matriz del historial de trabajos:

Ahora es fácil actualizar los documentos de nuestros empleados añadiendo un array job_history:

Este es el aspecto de nuestro documento de empleado:

Observe la matriz job_history de puestos anteriores.

Ahora podemos eliminar los documentos temporales de job_history:

Como último paso insertamos los documentos originales de los trabajos:

Hemos terminado. Este es un ejemplo simple, pero muestra lo poderosa que puede ser la manipulación de datos N1QL. ¡Feliz migración de datos!