Et si la vraie complexité des migrations BI se jouait dans les sources ?

 

Et si la vraie complexité des migrations BI se jouait dans les sources ?

Dans tout projet de migration de solution de dataviz, on a tendance à penser que l’écueil principal réside dans le changement d’outil. Oui, mais « pas que »  ! Passer de SAP Business Objects à Looker, par exemple, pourrait être une affaire de « traduction » de dashboards et de couche sémantique. On sait d’ailleurs très bien le faire .

REX : migration SAP BO vers GCP Looker

Mais notre expérience montre qu’il y a un aspect structurant qui ajoute de la complexité à la complexité dans le cadre d'une migration technique : la gestion des sources de données dans la cible.  Dans le cas d’une migration de SAP BO vers Looker, elles sont rarement migrées à 100 % dans GCP BigQuery. Les sources peuvent rester sur Oracle par exemple, reposer pour partie sur du SQL personnalisé (freehand SQL), ou combiner plusieurs bases. Les cas complexes sont nombreux.    Nous avons construit une solution technique permettant de traiter efficacement l'ensemble de ces cas de figure.

Un nouveau paradigme : Créer une couche d’abstraction interopérable

Dans le contexte que nous évoquons, nous avons imaginé mettre en place une couche intermédiaire de données au format Parquet, stockée dans Google Cloud Storage (GCS).  Parquet est un format de fichier en colonne, compressé et qui du coup a un vrai intérêt pour les requêtes analytiques.    Cette couche intermédiaire sera requêtée à travers un orchestrateur de SQL, i.e. un moteur de requêtes SQL distribué. Il interrogera ce cache optimisé (construit à la volée - ou schédulé) en tenant compte des valeurs de prompt BO d'origine pour appliquer dynamiquement la logique des rapports BO. Les résultats seront ensuite transmis à Looker (dans le cas évoqué). Cette infra pourra être conteneurisée pour mieux gérer les montées en charge.

Les résultats :  Une valeur ajoutée indéniable à différents niveaux

Découplage technologique : on supprimera le lien direct entre Looker et les bases legacy (Oracle pour reprendre notre exemple), en créant un format pivot lisible par tous les outils.

Efficacité : les fichiers Parquet seront générés à la volée (i.e. à la demande). La base source ne sera ensuite plus sollicitée. Ils agiront comme un cache. Cela évitera les sollicitations répétées des bases sources. Les fichiers Parquet pourront néanmoins être schedulés si besoin.

Réduction de charge : on ira appliquer les filtres BO en amont, au plus près des data providers, pour limiter les volumes à traiter.

Déplacer l’intelligence : l'orchestrateur de SQL fusionnera les différentes sources et reproduira l’intelligence des dashboards BO, même complexes. Ça permettra un vrai gain de performance.

Cette stratégie permettra non seulement de traiter les cas exclus du scope initial de migration, elle ouvrira aussi la porte à une interopérabilité large des sources dataviz : les outils de ne se connecteront plus aux bases, mais à une couche d’abstraction agnostique.

Pour résumer, la migration de l’outil de dataviz ne conditionnera pas à elle seule la réussite complète d’un projet de transformation data. La complexité quasi systématique des sources dans l’architecture cible imposera souvent la mise en œuvre de mécanismes adaptatifs. L’anticipation d’évolutions architecturales futures pourra aussi justifier la mise en œuvre de la solution que nous avons décrite.    L’étape d’après sera de construire une couche sémantique universelle qui viendra chapeauter l'orchestrateur de SQL (in progress), pour une interopérabilité complète, des sources mais aussi de la couche sémantique.