Oracle Warehouse Builder (OWB) vs Oracle Data Integrator (ODI)
15/02/2013 -
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.
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.
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.
| OWB |
ODI |
Pros y Contras | |
| Fuentes de Datos (Source Technology) | – Oracle Database- Otras bases de datos accesibles a través de Oracle Database Heterogeneous Services (Oracle Gateway o conexión ODBC) como IBM DB2, Informix, Teradata, etc.- Microsoft Excel y Access a través de ODBC- Ficheros de texto plano | – Todo lo suportado por OWB- Oracle Exadata- Oracle eBusiness Suite- Oracle Peoplesoft- Oracle JD Edwards- Oracle Hyperion Essbase, Planning, Financial Management- XML files- SAP ERP, SAP BW- LDAP Directory | ODI suporta un número de tecnologías considerablemente superior. |
| Destinos(Target Technology) | – Oracle Database- Otras bases de datos accesibles a través de Oracle Database Heterogeneous Services (Oracle Gateway o conexión ODBC) como IBM DB2, Informix, Teradata, etc. | Las mismas tecnologías suportadas como Source | La mayor limitación de OWB es que puede utilizar como target únicamente tablas Oracle o de una BBDD accesible a través de Oracle Databasa Heterogeneous Services.ODI es mucho más flexible y permite utilizar tanto como Source que como Target cualquier tecnología accesible a través de JDBC. |
| CDC (Change Data Capture) | Change Data Capture no está suportado | Soporta CDC | En ODI existen Módulos de Conocimiento dedicados. Se puede aplicar CDC a una tabla o a múltiples tablas a la vez. |
| Versioning | OWB no implementa Control de Version | Integra un sistema de versionado | ODI suporta un sistema de versionado interno que permite crear versiones de cada objeto, interfaz o proyecto. Las versiones se pueden restaurar y comparar adentro del mismo ODI. El sistema de versionado de ODI no es muy sofisticado comparado con otras soluciones de versioning en el mercado. |
| Error Monitoring | La interfaz para monitorizar los errores en OWB es bastante limitada y pesada | ODI integra un modulo dedicado a la monitorización de sesiones | La monitorización de ejecuciones en ODI es más “ligera” e intuitiva. A través de un modulo dedicado (ODI Operator), integrado en la consola, se puede monitorizar en tiempo real el estado de cada ejecución. |
| Customización | Las posibilidades de customización son muy limitadas | Los Módulos de Conocimientos son personalizables, incluso se pueden desarrollar Módulos de Conocimiento ad hoc | Los módulos de conocimiento (Knowledge Modules -KM) de ODI realizan la extracción de los datos y la carga en los sistemas target. Los KMs están escritos en varios lenguajes (Jython, SQL, etc.) y se pueden personalizar para adaptarlos a las exigencias de carga que puedan surgir. |
| Tiempos de desarrollo | Los mappings de OWB tienen que ser desplegados para generar el código ejecutable. Esta operación tiene que ser repetida cada vez que se realiza un cambio. El despliegue de los objetos suele ser una operación que impacta negativamente en los tiempos de desarrollo | ODI introduce un entorno de desarrollo basado en JDeveloper que reduce los tiempos de desarrollo y permite diseñar de forma intuitiva procesos de transformación. Las interfaces no necesitan ser desplegadas. | En ODI el diseñador tiene que configurar la conexión a los entornos de origen y destino y el proceso de integración. ODI genera el código para la ejecución sin tener que desplegar cada cambio como en OWB. |
| Licencias | Incluido en la licencia del Oracle Database 11gR2 | Licenciado a parte de la BBDD Oracle y de Weblogic Server | OWB no tiene costes de licencia adicionales |
En conclusión, Oracle Warehouse Builder es una herramienta pensada para trabajar con BBDD Oracle. Es una solución que lleva tiempo en el mercado y que cumple con todas las funcionalidades para diseñar y administrar un DW, tanto ROLAP como MOLAP. Por otro lado, ODI es la apuesta de Oracle para el futuro en el campo de las herramientas ETL y asegura alta escalabilidad, total integración con la Oracle SOA Suite y capacidad de utilizar motores de BBDD heterogéneos tanto como target de la integración que para realizar las transformaciones de los datos.
Entonces, ¿qué hacer? Si hay que cargar datos a una BBDD non-Oracle, no hay margen de elección. Solo podemos recurrir a ODI.
Si nuestro target es Oracle, el gran dilema es: ¿ahorrar ahora los costes de licenciamiento o enfrentarse a una migración futura cuyas modalidades (y obviamente los costes) no podemos definir? En estos tiempos críticos, la última palabra la tienen los presupuestos.
