ETL, les questions à se poser

Deux cas sont à prendre en compte, le chargement initial et les chargements incrémentiels.
Le chargement initial est effectué au tout premier chargement de l'entrepôt et dans des cas spéciaux comme après la perte des données de l'entrepôt. Dans ce cas, on charge toutes les données de l'entreprise dans l'entrepôt.
Le chargement incrémentiel est le fait d'ajouter des données à un entrepôt existant, c'est l'opération qui va se répéter dans le temps (chaque jour par exemple). Il faudra faire attention dans ce cas à ne charger que les informations nouvelles, et ne pas charger deux fois la même information.

Avant de faire un ETL, il faut bien étudier les sources de données. En effet, c'est d'après les sources que les stratégies de chargement vont se faire.

Il est à noter que le rapatriement des données peut se faire de trois façons différentes :

• Push : dans cette méthode, la logique de chargement est dans le système de production, il « pousse » les données vers le Staging quand il en a l'occasion. L'inconvénient est que si le système est occupé, il ne poussera jamais les données ;
• Pull : au contraire de la méthode précédente, le Pull « tire » les données de la source vers le Staging. L'inconvénient de cette méthode est qu'elle peut surcharger le système s'il est en cours d'utilisation ;
• Push-Pull : vous le devinez, c'est le mélange des deux méthodes. La source prépare les données à envoyer et prévient le Staging qu'elle est prête. Le Staging va récupérer les données. Si la source est occupée, le Staging fera une autre demande plus tard.

Une fois la bonne stratégie choisie (en fonction de vos spécificités en entreprise), il est temps de se poser les questions fondamentales qui dessineront les caractéristiques de votre système :

• quelle est la disponibilité de mes sources de données ?
• comment y accéder ?
• comment faire des chargements incrémentiels ?
• quel est le temps d'un chargement incrémentiel moyen, ai-je la possibilité de recharger des données dans le cas où mon processus de chargement échoue ?
• quelle politique vais-je utiliser dans le cas d'échec de chargement ?

Ces questionnements vous aideront à établir une stratégie de chargement des données sources dans le Staging.

Maintenant que les données sont dans le Staging, va falloir nettoyer tout ça ! C'est l'opération la plus importante (et la plus casse-tête) du processus. En effet, une erreur dans un champ affecte forcément les analyses (exemple de Canada et Canonda). Voici les questions à se poser à cette étape :

• quels sont les champs les plus sujets à erreurs ?
• ai-je les moyens de corriger les erreurs automatiquement ?
• comment permettre à un utilisateur de corriger les erreurs ?
• quelle politique vais-je utiliser pour le traitement des erreurs (fichier log, table dans BD) ?
• comment montrer à l'utilisateur final que des données n'ont pas été totalement chargées à cause d'erreurs ?

La dernière mission de l'ETL, charger les données dans le DW. Le point critique dans cette étape est qu'il faut avoir, à tout moment, un contrôle total sur les processus. Exemple : pendant un projet de construction d'entrepôt, vous commencez à automatiser les chargements incrémentiels. Mais un jour, la machine plante au beau milieu du chargement, c'est-à-dire qu'une partie des données a été chargée et une autre non (c'est du vécu). Que faire ??

Et bien si vous n'aviez pas prévu cela, pauvre de vous ! Vous n'avez qu'à vider la base et la recharger, avec toutes les pertes d'historique que cela implique, ou sinon prendre le temps et chercher une à une, les informations qui ont été chargées.
Voici les questions qu'il faut se poser pour cette étape :

• que faire si un chargement échoue ?
• ai-je les moyens de revenir à l'état avant le chargement ?
• puis-je revenir dans le temps d'un chargement donné ?
• comment valider mon chargement, comment détecter les erreurs ?

Eh oui ! On n'en parle jamais assez ! Et quand on en parle, ben on ne sait pas forcément ce que ça veut dire ! C'est pourtant une des clés du succès de tout projet décisionnel.
Les métas donnés, en informatique décisionnelle, sont des informations décrivant notre environnement décisionnel. Je ne parle pas seulement des informations concernant le schéma des entrepôts ou la politique d'attribution de noms aux champs de l'entrepôt, mais de tout ce qui, de près ou de loin, peut ajouter de la compréhension aux chiffres présentés.

En effet, il est peut être pertinent pour notre ami analyste de savoir que la colonne prix qu'il est en train d'analyser provient des archives et non des données courantes. Il est peut-être utile aussi de savoir que les chiffres devant nos yeux sont issus d'un chargement qui a échoué, mais qu'on a réussi à recharger correctement. Il est important pour le grand patron d'une entreprise d'avoir une petite info bulle qui lui indique que les données de son tableau de bord sont celles de l'avant-veille, car le chargement ne s'est pas bien déroulé. Imaginez la catastrophe si le décideur prenait des décisions sur des données erronées !!

Il est très important, dans un environnement décisionnel, de non seulement documenter tout le projet (des processus d'ETL aux logs de chargements), mais de rendre aussi disponible toutes ces métas données aux utilisateurs de l'environnement pour générer encore plus de connaissance. Car n'oubliez pas que c'est le but finalement, créer de la connaissance.

Dans tout ce que vous ferez dans la vie, le contrôle est la clé du succès. Le non-contrôle amenant inévitablement le risque et le risque entraînant l'erreur. Si vous ne savez pas d'où provient une erreur, il est fort probable qu'elle soit du côté d'un élément dont vous n'avez pas le contrôle. Le meilleur système étant celui qui laisse le moins de place au risque.
La partie philosophie à la matrix étant dite. Intéressons nous à comment contrôler un ETL, quels sont les points clés à surveiller et, surtout, que faire lorsqu'un élément ne fait pas son travail correctement.

Les ETL sont, malheureusement, la plus grande faiblesse des environnements décisionnels. Tout est critique et sujet à contrôle dans un ETL. Sans oublier que le contrôle sans action ne nous est en rien utile !

Comment retourner en arrière, c'est la principale question que je me pose et à laquelle j'essaye de répondre quand je conçois un ETL. Comment retourner en arrière si un chargement s'arrête brusquement, comment revenir à l'état initial si les données semblent incohérentes, comment valider mes transformations…

Le but de tous ces questionnements est de préserver l'intégrité et la « vérité » de l'entrepôt de données. Car c'est le seul point de défaillance de l'environnement (à par la phase de chargement, tout le système est en lecture seule).

Nous avons la chance d'évoluer, à l'heure où j'écris ces mots, dans un domaine en pleine effervescence, les solutions d'ETL existent, sont nombreuses et répondent à toutes les demandes de performance et de portefeuille (c'est important !).

Cependant, devant un choix si diversifié, on se retrouve un peu perdu : Open Source ou payant, solution intégrée ou indépendante, sous-traitance ou développement. Les éléments à prendre en compte dans le choix de votre ETL sont les suivants :

• taille de l'entreprise : j'entends par là taille des structures. S'il s'agit d'une multinationale avec des milliers de succursales à travers le monde, on ira plus pour une solution complète et, en général, très coûteuse. Si on est une PME, on optera plutôt pour des solutions payantes (comme Microsoft Integration Services) assurant un certain niveau de confort sans impliquer des mois de développement ;
• taille de la structure informatique : une entreprise avec une grosse structure informatique pourra se permettre d'opter pour une solution Open Source et la personnaliser selon les besoins de l'entreprise. Une PME ne pourra sûrement pas faire cela ;
• culture d'entreprise : évidement, si une entreprise à une culture de l'Open Source très prononcée, l'application d'une solution payante risquera fortement de subir un phénomène de rejet ;
• maturité des solutions : il existe des solutions bien rodées, qui fonctionnent bien et qui bénéficient d'un bon retour d'expérience, c'est en général les plus chères (Business Objects, Oracle, SAP). Il existe d'autres solutions, moins matures, bénéficiant d'un « effet de mode » et qui semble offrir de très bonnes performances (Microsoft). Enfin, il existe des solutions Open Source qui, de par leur jeunesse, n'offrent pas autant de flexibilité et de facilité de mise en œuvre que les solutions précédemment citées. Il faudra compter avec le temps pour que ces solutions émergent et arrivent à un niveau de maturité acceptable…