Archivo

Posts Tagged ‘ETL’

Upgrade desde ODI 11g a ODI 12c

Hace unos meses Oracle presentó la nueva versión de Oracle Data Integrator. En este post vamos a detallar los pasos necesarios para migrar los objetos de ODI desde la versión 11g a la versión 12c.

En la instalación de ODI 11g que queremos migrar tenemos creadas tres interfaces que cargan datos de ficheros de texto y tablas Oracle a tablas Oracle. Las interfaces son sencillas, pero tienen joins, filtros y expresiones que necesitamos que se traspasen correctamente si no queremos perder la funcionalidad implementada.

ODI 11g Interface

Para poder migrar una instalación de ODI 11g a 12c es necesario que se cumplan unos requisitos:

  1. La versión de la base de datos donde se instalaron los Master y el Work Repository para ODI 11G tiene que estar soportada y certificada para Oracle Fusion Middleware 12c (comprobarlo en http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html).
  2. La base de datos de los esquemas del Master y del Work Repository 11g tiene que ser UTF-8.

Si así no fuera, hay que migrar previamente a una base de datos que tenga estas características.

Antes de empezar, es aconsejable realizar un backup tanto del Master como del Work Repository 11g porque después de que se haya realizado el upgrade ya no será posible utilizar los esquemas en una instalación de ODI 11g. Para clonar los esquemas involucrados, se han seguido los siguientes pasos:

  1. Export de los esquemas del Master (ODIM) y del Work (ODIW) Repository

    exp userid=ODIM/ODIM file=ODIM11.dmp

    exp userid=ODIW/ODIW file=ODIW11.dmp

  2. Creación de nuevos usuarios

    create user ODIM11 identified by …;
    create user ODIW11 identified by …;
    grant connect, resource to ODIM11, ODIW11;

  3. Import de los esquemas copiados

    imp userid=’system/xxx’ touser=ODIM11 fromuser=ODIM file=ODIM11.dmp

    imp userid=’system/xxx’ touser=ODIW11 fromuser=ODIW file=ODIW11.dmp

  4. Reconfigurar la conexión de ODI 11 a los nuevos esquemas ODIM11 y ODIW11 para comprobar que se hayan clonado correctamente.

Para ejecutar el upgrade, hay que ejecutar el fichero ua.bat (Upgrade Assistant) que se encuentra en la carpeta

    <Oracle_Middleware_Home>\oracle_common\upgrade\bin\ua.bat

de la instalación de ODI 12c. Para poder ejecutar el Upgrade Assistant es imprescindible instalar las parches que vienen con el installer de ODI 12c.

Leer más…

Categorías:Business Analytics Etiquetas: , , , , ,

De Oracle Warehouse Builder (OWB) a Oracle Data Integrator (ODI)

odiHace tiempo que estaba anunciado y el roadmap de OWB y ODI lo dejaba claro: 11.2 es la versión terminal de Warehouse Builder, no habrá mejoras funcionales más allá de dicha versión (aunque su soporte está garantizado a lo largo de todo el ciclo de vida de la BD 11g) y estará certificado con la versión 12.1, pero no más allá del release 1.

A partir de la versión 12c de la BD ya no se incluye OWB en la instalación y para utilizarlo debe ser descargado de OTN e instalado adicionalmente.
¿Y ahora qué? ¿Qué alternativas tiene nuestra organización si cuenta con numerosos ETL desarrollados con OWB?

En realidad, la única opción viable es migrar a ODI, pero existen diversas maneras de realizar la transición:

  1. La más drástica: abandonar OWB y rediseñar todos los procesos ETL con ODI. La enunciamos como opción, pero sólo parece viable si nos encontramos en un estado bastante embrionario del proyecto ETL.
  2. Continuar ejecutando los paquetes ETL desarrollados con OWB desde ODI, ya que ODI 12c puede coordinar su ejecución. Esta característica nos abre la posibilidad de realizar los nuevos desarrollos con ODI y continuar ejecutando la funcionalidad existente mientras no requiera modificaciones, momento en el que sería necesario plantear su migración o rediseño. De esta manera ganamos el tiempo necesario para el aprendizaje y despliegue de ODI (si no lo hemos iniciado aún) y podemos realizar la transición paulatinamente (dentro del plazo establecido por el soporte a la BD 11g).
  3. Migrar los desarrollos existentes de OWB a ODI con la utilidad proporcionada por Oracle. Como en cualquier proceso de migración automatizada … será necesario un piloto con muestras significativas de las diferentes casuísticas de cada proyecto para verificar el % de cobertura sobre “nuestro estilo de desarrollo”. En síntesis, la idea es, a partir de un fichero de exportación de los metadatos de un proyecto OWB 11.2.0.4, mediante una utilidad de línea de comandos, se generen los objetos para ODI 12.1.2.0. Son necesarios determinados parches sobre las versiones indicadas de ambas herramientas, y la utilidad está disponible sólo sobre Linux-64. Además, si nuestro desarrollo no está en 11.2.0.4, deberemos subirlo primero hasta dicha versión.
  4. Migrar los desarrollos existentes de OWB a ODI mediante utilidades desarrolladas por terceros. Ciertamente no son muchas las alternativas y por diversos motivos no vamos a referenciarlas aquí, pero es una opción puesto que existe alguna herramienta.

Planteado el escenario, dedicaremos futuros posts a ilustrar brevemente cómo sería el proceso a seguir por nuestra organización si decidiéramos implementar alguna de las opciones (2. Ejecutar paquetes OWB desde ODI) o (3. Migrar los desarrollos OWB a ODI con la utilidad de Oracle), con el objetivo de ofrecer visibilidad suficiente sobre ambas opciones para facilitar la elección, si es que nos encontrásemos en la necesidad de tomarla.

Debug con Oracle Data Integrator 12c

odiEntre las novedades que más nos han llamado la atención de ODI 12c está la incorporación de la capacidad de debugar (añorada en alguna ocasión por los que hemos trabajado con OWB, que contaba con ella).

ODI 12c permite depurar la ejecución de los siguientes elementos: mappings, escenarios, procesos y paquetes, sobre el esquema (blueprint) de la sesión en ejecución.

Podemos tener varias sesiones en ejecución a la vez, pero “sólo” podremos depurar una de ellas (aunque podremos conectarnos a cualquier sesión en ejecución o reiniciar una finalizada), así como lanzar una nueva sesión de cualquiera de los objetos mencionados desde diferentes puntos de ODI Studio, y lógicamente, habrá algunas diferencias entre las opciones de cada uno de ellos (p.ej. dónde establecer un breakpoint).

La imagen a continuación corresponde a una captura de pantalla de la depuración de un sencillo mapping de carga de un fichero de texto en el filesystem a una tabla.

Pasos de depuración

Si nos fijamos en la barra de herramientas del depurador, encontraremos las funciones típicas (iniciar, ejecutar, ejecutar un paso, hasta el siguiente paso, hasta el final, … establecer breakpoint) que se irán activando y desactivando según el contexto y estado de la ejecución y que nos permitirán desplazarnos rápidamente y de manera visual hasta el paso que intuyamos conflictivo.

En la siguiente captura, un ejemplo de clicar el botón “Get Data”  Get Data que se habilita durante la ejecución de los pasos de acceso a datos y que recupera en la pestaña “Debug Data”, en la parte inferior, las sentencias SQL que ejecutará el paso (tanto en la fuente de datos origen como en la de destino), donde tendremos la posibilidad de editarlas y ejecutar el código modificado. De manera similar, podemos también inspeccionar los valores de las variables y los hilos en ejecución, en las otras pestañas.

Debug DataTambién es interesante saber que, además de iniciar sesiones de depuración en el propio Studio (sin agente), también podremos depurar sesiones sobre cualquiera de los agentes de nuestra topología al conectarnos a una sesión en ejecución.

Acabaremos el post con una pequeña reflexión: aunque es una buena noticia la incorporación del debug, no debemos descuidar el correcto diseño y validación de los procesos antes de abordar los proyectos de ETL, así como la ejecución del perfilado de datos (bien sea manualmente, bien sea mediante las opciones de Data Quality disponibles para Oracle Data Integrator).

Normalización de cadenas de texto en PL/SQL

octubre 16, 2013 5 comentarios

La normalización de cadenas de texto es uno de los temas recurrentes en el desarrollo de procesos ETL. Cuando se tratan datos anagráficos, es muy común encontrarse con duplicados debidos a errores tipográficos y de data entry.

Consideremos el siguiente ejemplo:

Ejemplo Datos Duplicados

Se puede ver que los dos registros se refieren a la misma persona física, pero hay elementos que impiden considerar los registros como duplicados perfectos. El NIF ha sido transcrito mal. Es presumible que el error venga de una introducción manual de los datos ya que la N y la H están muy cerca en el teclado español. Tanto el nombre como el domicilio aparecen en dos formatos distintos, mientras que en el caso de la población es el acento el que hace que no coincidan las dos cadenas.

¿Qué herramientas tenemos en PL/SQL para matchear los dos registros y eliminar los duplicados?

La función SOUNDEX devuelve una representación fonética de una cadena. El resultado es la codificación de cómo se pronunciaría un texto en inglés. A pesar de que estemos trabajando con texto en otro idioma, la función puede resultar útil.

Si la aplicamos por ejemplo a la población, tendremos:

SELECT POBLACIO, SOUNDEX(POBLACIO)
FROM CLIENTES
WHERE NOMDES LIKE '%SCOTT%'

Ejemplo SOUNDEX

En este caso, el código resultante es el mismo y podríamos utilizarlo para considerar que tienen igual valor.

En otros casos, como el nombre, el resultado de la función SOUNDEX no nos ayuda.

SELECT NOMDES, SOUNDEX(nomdes)
FROM CLIENTES
WHERE NOMDES LIKE '%SCOTT%'

El package UTL_MATCH contiene unas funciones desarrolladas para facilitar la detección de duplicados. Hay cuatro funciones:

  • EDIT_SIMILARITY: la función calcula la distancia de Levenshtein. Esta medida debe el nombre al científico ruso que desarrolló un algoritmo para medir la distancia entre dos cadenas de texto s1 y s2. La distancia se calcula como numero de inserciones, cambios, cancelaciones de caracteres que permiten pasar de la cadena s1 a la cadena s2. La función devuelve un número que representa la distancia entre las dos cadenas: 0 indica dos cadenas idénticas. En el ejemplo, si asumimos que el formato correcto es “NOMBRE APELLIDO”, la función devuelve:
SELECT nomdes, utl_match.edit_distance(NOMDES, 'SCOTT TIGER')
FROM clientes
WHERE NOMDES LIKE '%SCOTT%'Ejemplo EDIT_DISTANCE

La distancia entre las dos cadenas no es muy grande y podríamos considerar las dos cadenas como coincidentes.

  • EDIT_DISTANCE_SIMILARITY: actúa como la función EDIT_SIMILARITY pero devuelve un valor normalizado entre 100 (cadenas coincidentes) y 0 (total discordancia).
  • JARO_WINKLER: esta función utiliza el algoritmo de Jaro-Winkler que calcula un índice de similitud entre dos cadenas, para intentar tener en cuenta posibles errores tipográficos. El valor 1 representa dos cadenas coincidentes.
    Ejemplo JARO-WINKLER
  • JARO_WINKLER_SIMILARITY: la función utiliza el algoritmo de Jaro-Winkler y normaliza los resultados entre 0 y 100.

Las funciones del paquete UTL_MATCH permiten definir un umbral de aceptabilidad para establecer si dos cadenas coinciden “lógicamente” y pueden resultar una herramienta muy útil en el proceso de data cleansing.

Categorías:SQL Etiquetas: , ,

Generar documentación con Oracle Data Integrator

DocumentacionLa parte menos divertida del trabajo de un programador es generar la documentación de los proyectos. En los proyectos de ETL, describir cada proceso, las fuentes de datos y las transformaciones aplicadas puede llegar a ser un proceso muy laborioso, sobre todo teniendo en cuenta que,  en la mayoría de las circunstancias, se da más prioridad a desarrollar el software y a producir resultados que a documentar cada paso que nos lleva a la solución final.

Oracle Data Integrator permite generar documentación en formato PDF. Para poder utilizar esta funcionalidad, hay que configurarla en las propiedades de ODI.

En ODI -> Parámetros del Usuario, editar las siguientes opciones:

  • Visor PDF: ruta de acceso completa al Visor PDF (ej. Adobe Acrobat Reader,  C:\Program Files (x86)\Adobe\Reader 10.0\Reader\AcroRd32.exe)
  • Directorio por Defecto de Generación de PDF: ruta local donde se guardan los informes PDF generados

Edición Parametros Usuario

ODI permite generar documentación para los siguientes objectos:

  • Knowledge Modules (módulos de conocimiento): clic derecho en un proyecto y seleccionar Imprimir -> Imprimir Módulos de Conocimiento
  • Packages (paquetes): clic derecho en una carpeta de un proyecto y seleccionar Imprimir -> Imprimir Paquetes
  • Procedures: clic derecho en una carpeta de un proyecto y seleccionar Imprimir -> Procedimientos
  • Interfaces: clic derecho en una carpeta de un proyecto y seleccionar Imprimir -> Interfaces
  • Folders (carpetas): clic derecho en una carpeta de un proyecto y seleccionar Imprimir -> Carpeta

Leer más…

Oracle Warehouse Builder (OWB) vs Oracle Data Integrator (ODI)

febrero 15, 2013 5 comentarios

En la implementación de un Data Warehouse (DW) es imprescindible disponer de una herramienta para la extracción, transformación y carga de los datos. Este proceso se conoce por el acrónimo ETL (del inglés Extraction-Transformation-Loading).

Históricamente la herramienta ETL de Oracle ha sido Oracle Warehouse Builder (OWB). Lanzado en el 2000, OWB es el producto tradicional para la creación del esquema del DW, definición de dimensiones y medidas, mapeo de las fuentes de datos y scheduling de los procesos de carga para bases de datos Oracle.

Con la adquisición de la empresa Sunopsis en octubre 2006, Oracle lanza en el mercado otra herramienta ELT, Oracle Data Integrator (ODI). ODI introduce el concepto innovador de E-LT (Extract-Load-Transform). Las transformaciones de los datos pueden ser realizadas directamente en el sistema destino, sin necesidad de un área intermedia. Otro punto de fuerza de la nueva solución es la capacidad de conectar fuentes de datos heterogéneas, superando la limitación de OWB de utilizar la base de datos Oracle como único sistema target.

En el 2009 Oracle definió ODI y OWB como dos componentes de ODI-EE (Oracle Data Integrator Enterprise Edition) y declaró que los dos productos iban a ser fusionados en la misma plataforma de integración. La estrategia de Oracle a largo plazo es reemplazar por completo OWB con ODI.

post_img1

En el momento actual, OWB y ODI siguen formando parte de la oferta de Oracle como dos productos independientes. La última versión de ODI es la 11g y está totalmente integrada en la plataforma Fusion Middleware.

post_img2

OWB 11gR2 está incluido en la licencia del database 11gR2 e incluye algunas features que permitirán una migración más ágil hacia ODI. Sin embargo, todavía no existen herramientas ni Oracle ha especificado las modalidades para realizar tal migración.

Los clientes que se enfrentan a la implementación de un nuevo Data Warehouse o necesitan desarrollar un nuevo proceso de ETL tienen que elegir entre dos productos que tienen muchas características similares. Para poder asesorar el cliente en la elección de herramienta que más se ajusta a las necesidades del proyecto, vamos a analizar en la siguiente tabla los pros y los contras de las dos.

Leer más…

Changed Data Capture (CDC) con Oracle Data Integrator (ODI)

diciembre 13, 2012 1 comentario

cdc_petitEn los proyectos de integración de datos, una optimización muy importante es la detección de cambios (CDC) producidos por otras aplicaciones en el origen de datos, ya que si somos capaces de aislar los registros modificados (nuevos o eliminados) podremos reducir drásticamente el volumen de datos a procesar para tener las BD de origen y destino “sincronizadas”, tratando sólo los datos realmente necesarios.

En líneas generales, un mecanismo de CDC debería:

  • Detectar y registrar los cambios producidos en el origen.
  • Trasladar la información modificada a la BD destino.
  • Purgar el registro de cambios una vez procesados en destino.

CDC es una de las características estándar de Oracle Data Integrator (ODI), y vamos a explicar a continuación su arquitectura y funcionamiento.

ODI ofrece dos modos de registro de cambios (journalizing) en el origen de datos:

  • Simple: Registra los cambios en cada tabla de manera independiente.
  • Consistente: Registra los cambios en conjuntos de tablas, manteniendo la integridad referencial en el conjunto.

CDC funciona siguiendo un modelo de publicación/suscripción, en el que participan los siguientes elementos:

  • Journals (registro de cambios): Una relación de registros modificados con el tipo de cambio (alta/baja/modificación).
  • Procesos de captura: Son los responsables de mantener los “Journals” y pueden implementarse de diferentes maneras, condicionados principalmente por la tecnología de la BD origen. Pueden capturar los cambios mediante triggers en diversos motores de BD (método intrusivo, ya que impacta notablemente en el rendimiento de la BD origen) o analizando los logs de transacciones (siendo la manera óptima ya que su impacto es insignificante). Disponible para Oracle >= 10.2.0.4, IBM DB2/400 y mediante un conector (a licenciar) también para IBM DB2/Mainframe, IMS DB, VSAM Batch y CICS, MS-SQL Server >= 2005. Los cambios en un “Journal” sólo se capturan cuando tiene algún Suscriptor registrado.
  • Suscriptores: Son las entidades (aplicaciones, procesos de integración, …) que van a consumir la información de los “Journals”. Una vez que el último suscriptor ha procesado todos los cambios registrados, éstos son purgados del “Journal”.
  • Vistas del “Journal”: Son la interface de los suscriptores al contenido del “Journal”, a través de ellas se da acceso a los cambios registrados para su consumo.

cdc_flux

El proceso básico de configuración de CDC es el siguiente:

  • Configurar parámetros de CDC en el modelo de datos origen (modo de Journalizing y KM –Knowledge Module– correspondiente a la tecnología a utilizar en la captura, trigger o log, y configurar sus opciones).
  • Añadir las tablas para las que se desean registrar los cambios.
  • Si el modo de Journalizing elegido es el consistente, establecer el orden en qué procesar las tablas (de manera que se asegure la integridad referencial).
  • Añadir suscriptores (a una tabla o a un modelo, si hemos elegido el modo consistente).
  • Iniciar el Journalizing (la escucha de los procesos de captura, especificando el contexto de ejecución y el Agente que se responsabilizará de las actualizaciones).

El proceso de journalizing requiere de unas estructuras de datos, que son creadas automáticamente al iniciarlo y que se ubican en un esquema independiente a modo de staging area (diferente a la staging area del modelo destino utilizada en la integración), de manera que todos los objetos temporales necesarios son creados en ese esquema.

Únicamente en el caso de captura de cambios mediante triggers se modifica el esquema de datos origen, añadiéndole los triggers. Al eliminar el “Journal”, dichas estructuras son eliminadas también de manera automática.

Cuando existan varios contextos de ejecución, el despliegue del “Journal” en un contexto puede automatizarse en forma de paquete, y de idéntica manera, también su eliminación.

Una vez configurado el Journalizing, estará listo para ser utilizado en el desarrollo de interfaces.

De manera resumida, la utilización de CDC se traduce en la aparición en las tablas que están bajo Journalizing de atributos adicionales para su filtrado y proceso selectivo, excluyendo los registros no modificados. También contaremos con la posibilidad de utilizar las Journalizing Tools en el desarrollo de paquetes, para controlar el flujo de ejecución (y decidir si existen o no cambios para una tabla y si se debe lanzar o no su interface de carga). Al final del flujo de carga se invocará el proceso de purga del “Journal” para que elimine los cambios ya procesados, una vez concluido el tratamiento por el último suscriptor.