Migrer de SAP BO vers GCP Looker - Garder ses données en source ? Possible ?

 

Migrer de SAP BO vers GCP Looker -   Garder ses données en source ? Possible ?  BigQuery de GCP a une solide réputation en matière de base de données Cloud. Certaines entreprises vont opter pour le combo BigQuery + Looker, qui est proposé à des conditions ultra avantageuses. Dans ce cadre, quelques uns réfléchissent à une migration de SAP BO vers Looker. Et ils ont bien raison ! Les aficionados de la couche sémantique s’y retrouveront et BigQuery garantira des temps de réponse incroyables.   Si les données en source ont été migrées dans BigQuery, c'est parfait !  Dans ce cadre, nous préconisons de migrer la couche de dataviz As Is de SAP BO à Looker (dashboards reconstruits, prompts redéfinis, data model transposé en LookML, etc.).  Use  case : "Adeo / Leroy Merlin migre ses rapports BO vers GCP Looker par milliers" .... Mais dans la plupart des cas, la migration des multiples bases de données en source de SAP BO doit être opérée vers BigQuery en parallèle : dans ce cadre, le projet se complexifie fortement, donc s’étire, donc se renchérit, etc. En effet, on rencontre souvent en sources de SAP BO des bases Oracle, SQL Server, ou DB2, autres, des sources Excel, du « Freehand SQL » intégré dans BO, etc. : porter tout ça vers BigQuery, c’est le casse-tête assuré !  Si, par souci d’efficacité, on se laissait la possibilité de ne pas faire évoluer les sources de SAP BO (au moins dans un premier temps), mais de les rendre compatibles avec Looker ?  Il s'agira d'aller reproduire le comportement de SAP BO dans Looker, sans migrer immédiatement les données. .  Architecture technique préconisée  1. On va construire une couche de données intermédiaire, stockée dans Google Cloud Storage (GCS), au format Parquet :  >  Cela permettra une lecture efficace des données (stockage en colonne), un stockage économique, indépendant des bases sources et qui est compatible avec beaucoup d’outils (interopérabilité native).   2. On va adjoindre un moteur SQL distribué :   >  Il va rejouer toute la logique BO : prompts dynamiques (pushdown SQL), agrégations, joins multibases, etc. La plupart des requêtes sont mises en cache à la volée. Certaines peuvent être programmées selon le besoin.    3. Les connexion de Looker se feront sur cette couche :  > Looker se connecte à GCS, pas aux bases legacy : découplage complet (ce qui laisse entrevoir la possibilité d'interopérabilités techniques ultérieures). Les bénéfices attendus :    Suppression de la dépendance aux bases non migrées (Oracle, SQL Server, Excel, etc.) Reproduction partielle des dashboards BO, même complexes, sans surcharge de modélisation dans Looker. On évite les chargements systématiques : Parquet agit comme un cache, mais avec une "date de péremption".  On réduit la charge sur les sources, mais on maintient la logique utilisateur d’origine.  Mise à disposition d’une analyse d’impact et du data lineage directement dans cette couche,  avec l’intérêt de faciliter la compréhension des dépendances, de fiabiliser la maintenance et d’anticiper les évolutions.  En synthèse : vous disposez peut-être déjà de Looker via votre contrat GCP, sans l’exploiter pleinement, ou prévoyez de l’adopter. Plutôt qu’une migration lourde et coûteuse, nous proposons une approche pragmatique : avancer vite, sans tout reconstruire, en préservant la valeur de l’existant tout en préparant une architecture plus interopérable.