Voici maintenant un peu plus d’un mois que Microsoft a annoncé Microsoft Fabric, avec comme objectifs :
Unify your data estate
Establish an open and lake-centric hub that helps data engineers connect and curate data from different sources—eliminating sprawl and creating custom views for everyone.
Manage powerful AI models
Accelerate analysis by developing AI models on a single foundation without data movement—reducing the time data scientists need to deliver value.
Empower everyone in your business
Innovate faster by helping every person in your organization act on insights from within Microsoft 365 apps, such as Microsoft Excel and Microsoft Teams.
Govern data across your organization
Responsibly connect people and data using an open and scalable solution that gives data stewards additional control with built-in security, governance, and compliance.
All your data. All your teams. All in one place.
https://www.microsoft.com/en-us/microsoft-fabric
Vous reconnaissez sûrement une ambition similaire à Azure Synapse Analytics, n’est-ce pas ? Après avoir essayé d’intégrer Power BI dans Synapse Analytics, Microsoft s’est rendu compte que faire converger une plateforme de données en PaaS en capitalisant sur ses moteurs historiques (ADF, SQLDW, ADLS Gen 2) ne serait pas suffisant ni en termes d’usage, ni en termes d’efficacité financière pour ses clients.
C’est pourquoi avec Microsoft Fabric, le paradigme change complètement. L’objectif est d’intégrer tous les personae (renomés expériences pour l’occasion) dans une solution SaaS à l’image de Power BI.
Je trouve le choix extrêmement judicieux de la part de Microsoft, se concentrer sur les expériences et non plus sur la stack technologique. Ainsi, avec la même capacité Fabric ou Premium, il devient possible d’exécuter une multitude de workloads. Du data lake aux rapports, en passant par les modèles de ML. C’est extrêmement ambitieux, mais la promesse est fantastique.
Bien sûr, cela vient avec un lot d’inconvénients qui ne manqueront pas de rendre la solution inadaptée à certains contextes d’entreprise. Dans Microsoft Fabric, il n’y a pas qu’une solution technologique, il y a aussi une manière d’utiliser et d’implémenter sa plateforme d’analyse de données.
Certains diront que les services de base permettent de nombreuses implémentations en tordant légèrement le model, mais faut-il pour autant le faire ? Microsoft propose une solution qui met en avant les notions de lac centralisé, de Lakehouse, de Datawarehouse et de Datamart. De cette organisation va découler une manière reconnue par le marché d’organiser sa plateforme, un vocabulaire et des pratiques.
Pour le bien de la maintenance, de la sémantique et de votre entreprise, collez à ces pratiques reconnues ! Ne jouez pas aux apprentis sorciers qui voudront utiliser uniquement le Lakehouse parce que vous faisiez ça dans votre solution précédente…
Pour revenir au sujet, avec Microsoft Fabric, Synapse Analytics devient obsolète. Si certains termes et écrans sont ressemblants, si des intégrations sont possibles (SQL Pool Dédié), commencez à penser migration, car comme Azure Analysis Services, Synapse Analytics ne va nulle part.
Ne pensez pas avoir un chemin de migration simple, Microsoft Fabric est un nouvel outil, il va falloir revoir une grosse partie des implémentations. Et si vous commencez à vouloir diverger de l’approche d’implémentation inhérente à Microsoft Fabric, rappelez-vous, Azure Databricks, Azure SQLDB et Azure Data Factory continueront d’exister et d’évoluer. Peut-être que votre bonheur se situe dans ces implémentations plutôt que dans l’approche SaaS de Microsoft Fabric…
Vous êtes nombreux à me demander mon sentiment sur Microsoft Fabric, je l’ai partagé déjà à deux occasions :
- Sur le podcast du BigDataHebdo
- Lors d’un Meetup du Club Power BI
En substance, je crois beaucoup en ce produit, il suit des standards auxquels je crois beaucoup :
- Une approche où le lac doit être accessible pour être valorisé et donc un point d’entrée central ! Et un moyen d’accéder facilement aux données (Lakehouse)
- La nécessité d’avoir accès à des Data Warehouse pour implémenter les préceptes de Kimball, la modélisation dimensionnelle, l’historisation et l’implémentation de règles métiers
- La nécessité de laisser la main plus finement au métier via les Datamart avec une vision très proche et spécifique des besoins opérationnels
- Une intégration native de toutes ces couches pour un usage facilité et sécurisé
- En trame de fond, l’avènement d’un vrai poste d’Analytics Engineer plutôt que des Data Engineers actuels qui ne sont valorisés qu’à travers une connaissance technique (Spark, Python, Software) que par la capacité à rendre les données accessibles et centrées sur le métier (SQL, Modélisation Dimensionnelle, DAX).
Toutefois, Microsoft nous laisse aujourd’hui dans une situation inconfortable. Il est clair que Microsoft Fabric est l’avenir de la plateforme de données managée, et le service est actuellement en version preview. Mon optimisme est principalement basé sur les promesses marketing de la build… Il est maintenant temps de concrétiser ces promesses (One Security, DirectLake sur les DWH et DMT, intégration à la hauteur d’ADF…) et d’annoncer la date de sortie officielle de la solution !
2 Comments
Bonjour Charles-Henri, a quoi consiste le métier d’Analytics Engineer? et quelle différence avec le BI Engineer ?
Hello Amal,
C’est une terminologie proposée entre autre par dbt lab dont tu retrouves un comparatif ici > https://www.getdbt.com/ui/img/guides/analytics-engineering/analytics-engineer-role.png
Cela ressemble beaucoup à la vieille définition du BI Engineer en effet mais qui c’est lentement renommé Data Scientist, Data Engineer en fonction des projets et personnes.
Pas de rapports Power BI pour l’Analytics Engineer par ailleurs, vraiment centré sur la récupération et la valorisation des données aux seins de modèles de données propres et compréhensibles.