Oracle Data Integrator Enterprise Edition

En janvier 2009 Oracle a publié un document : « statement of direction » pour ODI et OWB dans lequel il est mentionné : « Today Oracle includes Oracle Data Integrator (ODI) and Oracle Warehouse Builder (OWB) as the two components of ODI-EE and will merge them into a single unified data integration technology platform. This strategy fully preserves any existing development investments of all Oracle data integration customers and will provide a seamless, easy upgrade path from the current components to the unified platform and beyond. » Conformement à l’annonce faite après l’acquisition de l’éditeur de data integrator, Sunopsis SA en octobre 2006. En effet oracle avait annoncé que ODI viendrait comme complément à OWB dans le cadre du projet fusion middleware, que les deux produits devraient converger ; sans vraiment dire comment. (Voir cet article)

Approche par règles déclaratives vs. ETL traditionnel

Oracle Data Integrator repose sur une approche par les règles déclaratives. C’est la différence clé entre les deux produits et qui donne à Oracle Data Integrator un avantage claire sur Oracle Warehouse Builder. Cette approche sépare la définition des processus de leur implémentation, et sépare les règles déclaratives (le “quoi”) des flux de données (le “comment”). Que signifie exactement cela ? Dans les projets d’intégration de données, les stratégies de chargement et d’intégration sont souvent similaires, ex. dans un projet data warehouse, 80 à 90% les tables fact suivent la même stratégie de chargement : d’abord on désactive les contraints de clés secondaires et indexes, ensuite on regarde les autres clés dérivées et finalement on charge les données dans la table fact. Dans un ETL traditionnel, nous devrions créer un module de « mapping » pour chaque table fact. Ce qui prend vraiment du temps. Dans ODI nous définissons simplement la stratégie de chargement dans un « Template » (appelée knowledge module) et par simple click nous l’appliquons au chargement de chaque table fact. Les « knowledge module» sont créés par un mélange de langages de programmation tels SQL, PL/SQL, Python, les API de substitution de ODI, les commandes OS, ou Java. cette approche d’intégration de données est très rapide a implémenter et extrêmement flexible.

Dans un projet où la majeure partie du « flux de données » suit une transformation similaire, l’approche par règles déclaratives de ODI pourra diminuer le temps de développement de vos transformations de 30 à 40%. Par contre dans un projet ou chaque transformation est unique (ce qui est vraiment rare), vous ne gagnerez pas « grand chose » de cette approche en terme de productivité.

Serveurs de données

Une des raisons pour lesquelles Oracle Warehouse Builder n’avait jamais été au top des ETL était sa limitation au SGBD Oracle comme base de données cible. Vous n’avez pas cette limitation avec Oracle Data Integrator. ODI vous permet d’utiliser n’importe quelle technologie comme Teradata, IBM DB2, Netezza, Oracle, Sybase IQ et de nombreuses autres technologies telles que les fichiers plats, les ERPs et CRMs, LDAP, XML, et tout autre qu’on peut accéder via JDBC comme base source ou cible des données.

L’approche ELT

Les deux produits sont les outils ELT. L’architecture ELT supprime le besoin d’un serveur ETL centralisé entre les sources et le serveur cible. Elle utilise le serveur cible et son SGBDR pour exécuter des transformations complexes (pour la plupart exécutées en batch quand le serveur n’est pas en train d’exécuter des requêtes utilisateur). C’est une différence clé avec d’autre produit comme Business Objects Data Integrator.

Change Data Capture (CDC)

Oracle Data Integrator inclus un « knowledge module » CDC qui permet un « data warehousing » presqu’en temps réel. Bien que ODI vous permette de paramétrer CDC rapidement, vous n’irez pas plus loin dans votre projet sans une compréhension claire du principe de la technologie « change data capture » : Dans le monde Oracle, voir Oracle Streams. Oracle Warehouse builder n’a pas d’interface CDC. Bien sure vous pouvez l’utiliser au dessus de CDC comme le décrit cet article de Mark Rittman.

Modélisation des données.

Les deux produits contiennent un « data modeler ». Le Common Format Designer (CDF) de ODI pour la modélisation des données est assez limité. Bien que vous pouvez définir la fonctionnalité basic et les modèles logiques (attributs, contraintes, relations entre table..) ODI ne vous permettra pas de définir les attributs physiques de vos tables comme tablespaces, partitions… Cette fonctionnalité étant disponible au niveau du modeler de OWB.

OLAP

Dans OWB vous pouvez créer des cubes OLAP multidimensionnels directement à partir d’un schéma relationnel. Cela ce fait à travert les workspaces analytiques et Oracle OLAP. Vous ne pouvez pas charger directement dans les cubes Essbase. Avec ODI vous pouvez irectement charger les données dans les cubes Essbase. Plusieurs « knowledge modules » sont disponibles pour Essbase. Vous pouvez aussi charger directement dans les cubes OLAP.

Scripts des objets

Oracle Warehouse Builder est basé sur OMB+ et TCL pour les scripts. Cela est util pour la mise à jour de plusieurs objets ex : si vous voulez spécifier un tablespace pour un groupe de tables. Une des inconvénients est que vous ne pouvez pas créer des scripts TCL à partir de vos objets. Il serait vraiment intéressant de pouvoir créer un script à partir des « mappings » créés dans OWB. ODI se base sur XML pour importer et exporter les objets. En théorie vous pouvez « scripter » vos objets via XML et les importer dans ODI.

Que faire alors ?

Dans les deux ans a venir Oracle Data Integrator et Oracle Warehouse Builder seront fusionner en un seul produit. En 2011 nous aurons une plateforme unifiée. Les comparaisons ci dessus montre que parmi les deux produits, ODI offre le plus de possibilités. Cela signifie la majeur partie des fonctionnalités de la future plateforme unifiée viendra de ODI (Normal sinon à quoi aura servit l’acquisition de ce produit ?).

Pour moi, seuls les projets d’intégration de données basés sur les fonctionnalités de OWB disponibles gratuitement avec le SGBDR devrait utiliser une implémentation de Oracle Warehouse Builder. SI vous avez une License Oracle Data Intégrator Enterprise Edition, vous devriez utiliser Oracle Data Integrator pour vos nouveaux projets et pensez a migrer vos projets existants vers ODI.