Archive

Posts Tagged ‘ODI 12C’

Uso de servicios REST y ficheros complejos con ODI 12c (I)

odirwsHace unos días me encontré frente a una tabla de direcciones con coordenadas UTMS en la que faltaban las coordenadas de diez registros de entre más de tres mil. Iniciar el proceso para que los usuarios afectados actualizasen los datos de los registros de su responsabilidad llevaría inevitablemente cierto tiempo hasta su resolución, así que decidí echar mano de Google.
Rápidamente identifiqué la API necesaria (Geocoding) y elegí el formato  para la respuesta. Verifiqué el funcionamiento con una invocación manual, exploré el fichero .json de respuesta (> 6Kb) y hallé los 50 bytes con los datos que buscaba. Los comprobé con la función inversa, introduciendo las coordenadas obtenidas en Google Maps, que me ubicó en la dirección original. Veamos un ejemplo:

https://maps.googleapis.com/maps/api/geocode/json?address=Aragó+180,+Barcelona&key=************************

Tras esta verificación pensé: ya sólo me faltan nueve. Así que siendo pragmático, hice unos cuantos cut&paste y completé en unos minutos las coordenadas de los diez registros. Pero me quedé con una inquietud: ¿qué habría ocurrido si en lugar de sólo diez hubieran habido más de tres mil registros sin coordenadas?
La respuesta fue clara: automatizarlo con ODI. Y así fue como se originó la decisión de escribir este post, ilustrando la solución a dos necesidades bastante cotidianas:

  • Utilizar un servicio REST para obtener datos de la web
  • Procesar un fichero JSON

Tanto el orden de las necesidades como “el sentido” del flujo de datos pueden variar, así como su relación con alguna de las tablas en BD (que en nuestro caso, será una tabla con direcciones), no obstante espero que el ejemplo sea suficientemente ilustrativo.
Una segunda motivación para este post es la “actualización de conocimientos”. Estas dos tareas ya eran posibles con ODI 11g, pero veremos que ODI 12c simplifica su ejecución y a la vez nos ayuda a conservar los desarrollos más ordenados.

Utilizar un servicio REST para obtener datos externos

La llamada es sencilla, la API sólo requiere dos parámetros:

  • la dirección buscada (formateando adecuadamente los espacios, numeración y comas)
  • la clave de desarrollador para poder utilizar la API (que es constante)

Quizá lo más complicado sea parsear la respuesta, pues hay cierta redundancia de datos, y utilizar el formato XML en lugar de JSON tampoco variaría mucho. Así pues, iremos por partes: primero obtendremos los datos de la respuesta del servicio y después procesaremos la respuesta (fichero .json).
Para configurar el servicio, lo primero que necesitamos crear es un “Data Server” al que llamaremos “GoogleGeocod”, que apuntará a la URL del endpoint del servicio REST: https://maps.googleapis.com.
Acto seguido, crearemos un esquema físico bajo el nuevo servicio:

ps_geocode

Leer más…

Big Data Discovery, su papel en proyectos con volúmenes grandes de datos

septiembre 28, 2015 Deja un comentario

Oracle Big Data Discoverycon sus respectivas vinculaciones a Hadoop, Oracle Big Data SQL 1.1 y Oracle NoSQL Database 3.2.5, es una de las herramientas que ha introducido Oracle en el mercado, para el fortalecimiento y reestructuración de los grandes almacenes de datos en las empresas. Gracias a ella, se puede ver y entender rápidamente el potencial de los datos en bruto desde Hadoop  y convertir los datos en conocimiento en cuestión de minutos.

Sin una gran dificultad de aprendizaje, y mediante un diseño gráfico muy intuitivo, se puede compartir y obtener datos realmente interesantes.

1

Funciona de forma nativa con Hadoop, transformando datos rápidamente y procesando el conocimiento del negocio en cinco fases. Cualquiera puede encontrar, explorar, transformar y analizar datos para obtener nuevas perspectivas, las cuales pueden ser compartidas en proyectos de gran interés para el negocio.

 

Coherencia de la analítica Big Data

Oracle Big Data Discovery ofrece tremenda velocidad a escala masiva, permitiendo dedicar un 20% al desarrollo y un 80% al análisis.

Big Data Discovery está compuesto por los siguientes tres componentes básicos y es posible su interacción con otras herramientas:

2

  • Discovery Studio, es una interfaz de usuario intuitiva y visual para encontrar y explorar grandes volúmenes de datos, de tal forma que cualquier persona pueda rápidamente transformar, descubrir y compartir el valor del conocimiento del negocio a gran escala.
  • DGraph, es la tecnología líder en la industria Oracle Big Data; (Endeca Server); que simplifica la complejidad de organización y búsqueda de datos para su análisis.
  • Capa de Procesamiento de Datos, utiliza el componente Spark de Hadoop para realizar perfiles de datos a alta velocidad, transformación y enriquecimiento de la información.
  • Diseñado para trabajar junto a:
    • ODI 12c y GoldenGate: una vez que haya definido sus flujos de datos principales de transformación.
    • Oracle Big Data SQL: acceso BI de la aplicación a la totalidad del “Almacén de datos” (DWH + Hadoop).

La mejor manera de pensar en Big Data Discovery es “Endeca Hadoop”

La herramienta web Discovery Studio es una versión de Endeca Server para:

  1. Analizar y visualizar conjuntos de muestras de datos desde el clúster Hadoop, el cual ejecuta sus elementos sobre DGraph (Servidor Endeca) en uno o más nodos.
  2. Leer datos desde Hadoop mediante Hive y luego escribir de nuevo las transformaciones planificadas (utilizando Apache Spark para recuperar datos de Hadoop).
  3. Transformar esos datos de forma que sea más adecuado para su análisis con Big Data Discovery.

3

Leer más…

Oracle Data Integrator Enterprise Edition 12.1.3.0.1 – Instalación y detalle de opciones avanzadas para Big Data

Oracle anunció recientemente las opciones avanzadas de Oracle Data Integrador Enterprise Edition para Oracle Big Data. La nueva versión (12.1.3.0.1) de ODI, incorpora funcionalidades para trabajar en entornos Hadoop. En este post vamos a estudiarlas, así como la forma de instalar esta versión sobre la Virtual Machine Big Data Lite 4.1, que incluye la última versión CDH5.3.0 de Cloudera Hadoop, donde ya está instalado ODI 12.1.3, así como todos los componentes de Hadoop que necesitamos.

odi12c_logo_ds1big-data

 

Conceptos previos a tener en cuenta

Antes de entrar en detalle en la instalación de componentes Big data de ODI 12c, es conveniente hacer un resumen de conceptos previos a tener en cuenta sobre Big Data:

  • Hadoop: Es un framework para computación distribuida que permite a las aplicaciones trabajar con miles de nodos y petabytes de datos. Hadoop no es un tipo de base de datos, aunque sobre él se ejecutan ciertos tipos de bases de datos NoSQL (tales como HBase), que permiten que los datos se distribuyan sobre miles de servidores. Sobre la base del Hadoop Distributed File System (HDFS), un sistema de archivos distribuido, Hadoop permite el acceso de alto rendimiento a los datos a la vez que ofrece un cierto nivel de disponibilidad. Al igual que otras tecnologías relacionadas con Hadoop, HDFS se ha convertido en una herramienta clave para la gestión de grandes volúmenes de datos y el apoyo a las grandes aplicaciones de análisis de datos.
  • NoSQL: Es una BD del tipo Key-Value en memoria, que ofrece alto rendimiento y procesamiento ágil de la información a escala masiva. En otras palabras, se trata de una infraestructura de base de datos que ha sido muy bien adaptada a las exigencias de Big Data.
  • HBase: Es una BBDD que corre sobre Hadoop. Almacena datos estructurados y semiestructurados de forma natural, y está diseñado para correr en un clúster de ordenadores en lugar de una sola computadora. Características principales:
    • Almacenamiento NoSQL.
    • Provee una API Clave –Valor.
    • Corre en múltiples nodos en un clúster.
    • Nuestra aplicación no sabe si estamos tratando con 1 nodo o con 100 nodos.
    • HBase está diseñado y optimizado para manejar terabytes o petabytes de datos. Es una parte del ecosistema Hadoop por lo que depende de algunas de sus características clave, como redundancia de datos y procesos en segundo plano.
  • MapReduce: Es un modelo de programación para el procesamiento y tratamiento de grandes cantidades de datos no estructurados, en paralelo a través de un grupo distribuido de procesadores u ordenadores independientes (clústeres de servidores). MapReduce basa su funcionalidad en complejos algoritmos matemáticos que permite distribuir una tarea a través de múltiples nodos de manera transparente al desarrollador. El proceso MapReduce se compone de tres fases:
    • 1º fase es la función “map” o “mapper” en la que cada tarea opera sobre un único bloque HDFS y se ejecuta sobre el nodo dónde el bloque está almacenado, generando conjuntos de pares clave/valor intermedios.
    • 2º fase es la denominada “shuffle& sort” y es la encargada de ordenar y consolidar los datos intermedios generados por los “mapper” una vez han finalizado.
    • 3º fase se denomina “reduce” y opera sobre los datos generados en la fase “shuffle& sort” produciendo la salida del resultado final.
    • JobTracker: (Nodo Maestro).
    • TaskTracker: (Nodos Esclavos)
    • El nodo maestro consiste en un servicio demonio llamado JobTracker, el cual se encarga de asignar las tareas a los nodos esclavos.
  • Hive: es una interface que facilita la estructura de datos y permite la escritura de programas MapReduce. Hive utiliza una especia de lenguaje SQL denominado HiveQL, y comparte algunas de sus características, como el uso de tipos de datos primitivos o conectores JDBC y ODBC. Hive es un gran interface para cualquiera que provenga del mundo de las bases de datos relacionales.
  • Pig: es un lenguaje de flujo de datos especialmente diseñado para simplificar la escritura de aplicaciones MapReduce. PIG es una simplificación de MapReduce, que combina dos elementos: el compilador PIG y el lenguaje de script PIG Latin. PIG Latin está basado en el paradigma de flujo de datos, este paradigma se asemeja a las señales eléctricas que fluyen a través de los circuitos eléctricos. El procesamiento en Pig Latin se realiza mediante operadores tales como “Join”, “Filter”, “GroupBy” y “Union”. PIG aporta las siguientes ventajas y características:
    • Es un lenguaje similar a SQL
    • Soporta tipos complejos de datos que pueden ser embebidos como campos de una tabla
    • Soporta la creación de funciones definidas por el usuario
    • Aporta una característica especial llamada “Illustrate” que permite al desarrollador escribir código rápidamente utilizando datos de muestra
  • Spark: Se trata de otra plataforma que proporciona soporte para la implementación de aplicaciones según el modelo MapReduce sobre un clúster Hadoop, pero Spark lleva a  MapReduce al siguiente nivel en el procesamiento de datos, con capacidades como el almacenamiento y procesamiento de datos en memoria y en tiempo real, ofreciendo tasas de rendimiento varias veces más rápidas que otras tecnologías big data.
  • Oozie: Es una aplicación Web basada en Java que permite controlar y programar flujos de tareas dentro del sistema Hadoop, así como la toma de decisiones en tiempo de ejecución.

Pig y Spark support

Hasta ahora ODI12c nos permitió utilizar Hive para cualquier transformación basada en Hadoop. Con esta nueva versión, podemos utilizar también Pig  y Spark, dependiendo del caso de uso, para dar un mejor rendimiento.

Estas dos tecnologías ya están disponibles en la topología, junto con el servidor de datos Hadoop para poder definir dónde extraer los datos, y podemos importar también algunos módulos con los KM para Pig y Spark. Por lo que para trabajar con Pig y Spark con ODI, todo lo que se necesita es crear un flujo de datos lógico en el mapping y elegir su tecnología.

odi1

Pig es un lenguaje de flujo de datos, esto hace que encaje perfectamente con el nuevo modelo de programación orientado a “flujo” recientemente añadido en ODI 12c. La idea es escribir un flujo de datos en Pig latín, donde la carga de trabajo se ejecutará en MapReduce.

Leer más…

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).

Tipos de agentes en ODI 12c

noviembre 25, 2013 Deja un comentario

ofmw12 Son bastantes las nuevas funcionalidades que ofrece el reciente Oracle Data Integrator 12c, por lo que vamos a tratar de una novedad relativa a la arquitectura para asegurarnos de que no pasa desapercibida.

En las versiones anteriores de ODI había 2 tipos de agente:

* Standalone: Un agente ligero, fácil de desplegar, multiplataforma (se ejecuta sobre una JVM), y que básicamente se encarga de ejecutar los procesos ELT asignados en el momento indicado.

* J2EE: Aplicación J2EE que se despliega sobre un dominio WLS, con la misma capacidad de ejecutar procesos ELT que el standalone, más un webservice para publicar los contextos y escenarios disponibles en el repositorio, acompañado además de ODI Console y un Plug-in para EM. Pero que se beneficia del soporte para alta disponibilidad y servicios ofrecidos por el dominio de WLS (clustering, data sources, …) sobre el que se ejecuta.

Entre la simplicidad de la instalación del agente Standalone y la complejidad (relativa) de instalar un dominio de WLS para desplegar el J2EE agent, para disponer de las mínimas garantías de disponibilidad/monitorizacion/gestión  exigibles en un entorno corporativo, había una cierta distancia que quedaba medianamente cubierta a través de la integración del standalone agent con OPMN, lo que permitía dotar al standalone agent de esa mínima monitorización y capacidad de arrancar en background al iniciar el sistema (en el caso de MS-Windows) (https://blog.avanttic.com/2012/09/26/integracion-de-odi-11g-standalone-agent-con-opmn-2/).

La versión 12c introduce un nuevo tipo de agente y ciertos cambios al standalone agent, relacionado todo con el despliegue y la gestión de los agentes:

* J2EE: Se mantiene esencialmente igual.

* Standalone Agent: Pasa a ser un proceso gestionado por la Weblogic Management Framework (WMF), que es una plataforma que ofrece las funciones básicas de administración a los productos de la familia FMW. WMF puede gestionar tanto dominios de WLS (pueden tener componentes Java y/o de sistema) como dominios Standalone (sólo contienen componentes de sistema y cuentan con menor funcionalidad: no tiene consola, pero si Nodemanager, WLST y asistente de configuración, entre otras diferencias). A partir de la versión 12c, el standalone agent ya no será una aplicación java aislada sino que  se desplegará sobre un dominio Standalone.

* Collocated Agent: El collocated Agent es un standalone Agent que se ejecuta sobre un dominio de WLS y es administrado por su AdminServer, y que puede acceder a los servicios ofrecidos por el dominio.

Como conclusión, es  una buena noticia el que a partir de ahora todos los agentes se ejecutarán bajo un dominio (WLS o Standalone), mejorando las capacidades de gestión.

Para acabar, recordar que al crear los repositorios con RCU va a ser necesario incluir los siguientes esquemas, requeridos tanto para la instalación del agente standalone como del collocated:

odi12_rcu