Life Hacks for Developers: Utilisation efficace de SQ (Source Qualifier) ​​chez Informatica Power Center

Bonjour à tous les Habroresidents!

Nous ouvrons le premier blog de la société RDTEX avec des hacks de vie pour les développeurs. Nous espérons que l'un des lecteurs en profitera.

Les hacks de vie ont été inventés au cours des travaux sur un projet de transfert de données d'un système à un autre pour la construction ultérieure de rapports dans l'une des principales banques de la Fédération de Russie.

Technologies utilisées:

Système de source de données - Oracle RDBMS (version 11.2.0.4.0)
Système de réception de données - RDBMS Oracle (version 11.2.0.4.0)
Bus d'intégration - Informatica (version 10.1.1)

Lors de la mise en œuvre d'un grand projet d'intégration, nous avons rencontré les problèmes suivants:

1. Utilisation inefficace de SQ [Source Qualifier] dans Informatica Power Center

Lors de l'utilisation de SQ [Source Qualifier] dans Informatica Power Center, une restriction sur le nombre de caractères d'entrée a été révélée. Le nombre maximal de caractères autorisé est de 32 767. Un exemple d'utilisation irrationnelle de Source Qualifier est illustré dans la figure ci-dessous:


Figure 1 Capture d'écran de SQ Informatica Power Center

Cette capture d'écran montre que les espaces consomment de l'espace de caractères, ce qui fait que les requêtes SQL complexes ne correspondent pas complètement (c'est-à-dire qu'elles sont tronquées lorsqu'elles sont insérées dans le qualificateur de source).

La figure ci-dessous montre l'utilisation correcte du qualificatif source (les modifications sont surlignées en rouge):


Figure 2 Capture d'écran de SQ Informatica Power Center avec une requête modifiée

Aller à la ligne suivante et à l'alignement a coûté le Nième nombre de caractères, ce qui nous a permis d'adapter tout le code SQL.

2. Conversion incorrecte de nombres infiniment grands

Des nombres infiniment grands ont été téléchargés dans la base de données Oracle au format suivant:

1267650600228230000000000000000

Et ils doivent être chargés au format:

1267650600228229401496703205376
C'est-à-dire les valeurs ont été arrondies à partir d'une certaine position numérique.

Nous proposons la solution suivante:

Lors du développement des mappages dans Informatica Power Center, le format de champ (par exemple, chaîne) est immédiatement défini à un certain stade pour les valeurs qui deviendront certainement importantes, tandis que:

• Si nous utilisons le format décimal et si les valeurs peuvent avoir jusqu'à 28 caractères, nous devons alors activer Propriétés → «Activer haute précision» → «Oui» dans les propriétés du workflow dans Workflow Manager.
• Si nous utilisons le format double, dans ce cas, des valeurs dépassant 15 caractères (par exemple, 20) peuvent arriver à cet attribut, alors la valeur sera coupée à 15 chiffres significatifs et mettra zéro (0) dans le reste (c'est-à-dire que les 5 derniers caractères seront zéro ) Dans ce cas, il est préférable de réduire le format de chaîne et d'augmenter la taille au format souhaité (par exemple, string20).

Si, pour résumer l'utilisation de l'outil, on peut distinguer les avantages suivants:

1. l'outil est pratique pour transférer une grande quantité de données, calculées en téraoctets (par exemple, jusqu'à 25-30 tb), surtout si vous devez les transférer avec un nombre minimum de conversions (presque une à une);
2. Possibilité de «tirer» automatiquement des attributs (option Propager les attributs), ainsi que de «surligner» à l'intérieur de la cartographie (d'où et d'où les données sont tirées);
3. la possibilité de sélectionner le mode de fonctionnement d'un outil ETL et d'un outil ELT (en fonction du projet informatique spécifique).

Et quelques inconvénients pour l'objectivité de l'image:

1. absence de logique de transformation de données «complexe»;
2. Du point de vue du support de l'outil lui-même et de la compréhension de la logique des transformations individuelles, il est inférieur à certains concurrents (par exemple, Oracle Data Integrator).