Guide de décision Microsoft Fabric : l'activité de copie, le flux de données ou Spark
Utilisez ce guide de référence et les exemples de scénarios pour vous aider à décider si vous avez besoin d’une activité de copie, d’un dataflow ou d’Spark pour vos charges de travail Microsoft Fabric.
Activité de copie, flux de données et propriétés Spark
| Activité de copie de pipeline | Dataflow Gen 2 | Spark | |
|---|---|---|---|
| Cas d'utilisation | Migration du lac de données et de l’entrepôt de données, ingestion des données, transformation légère |
Ingestion des données, transformation des données, data wrangling, profilage des données |
Ingestion des données, transformation des données, traitement des données profilage des données |
| Personnage de développeur principal | Ingénieur données, intégrateur de données |
Ingénieur données, intégrateur de données, analyste d'affaires |
Ingénieur données, scientifique des données, développeur de données |
| ensemble de compétences principal du développeur | ETL, SQL, JSON |
ETL, M, SQL |
Spark (Scala, Python, Spark SQL, R) |
| Code écrit | Aucun code, peu de code |
Aucun code, peu de code |
Code |
| Volume de données | De faible à élevé | Faible à élevé | Faible à élevé |
| Interface de développement | Sorcier canevas |
Power Query | Carnet de notes Définition du travail Spark |
| Sources | Plus de 30 connecteurs | 150+ connecteurs | Centaines de bibliothèques Spark |
| Destinations | Plus de 18 connecteurs | Lakehouse, Base de données Azure SQL, Explorateur de données Azure, Azure Synapse Analytics |
Centaines de bibliothèques Spark |
| complexité de la transformation | Faible : léger : conversion de type, mappage de colonnes, fusion/fractionnement de fichiers, hiérarchie aplate |
Faible à élevé : 300+ fonctions de transformation |
Faible à élevé : prise en charge des bibliothèques Spark natives et open source |
Passez en revue les trois scénarios suivants pour obtenir de l’aide sur le choix de l’utilisation de vos données dans Fabric.
Scénario1
Leo, ingénieur données, doit ingérer un grand volume de données à partir de systèmes externes, à la fois locaux et cloud. Ces systèmes externes incluent des bases de données, des systèmes de fichiers et des API. Leo ne souhaite pas écrire et gérer du code pour chaque opération de déplacement de données ou de connecteur. Il veut suivre les meilleures pratiques des couches de médaillon, avec le bronze, l’argent et l’or. Leo n’a pas d’expérience avec Spark. Il préfère donc l’interface utilisateur glisser-déplacer autant que possible, avec un codage minimal. Il souhaite également traiter les données selon une planification.
La première étape consiste à obtenir les données brutes dans le lakehouse de couche bronze à partir de ressources de données Azure et de diverses sources tierces (comme Snowflake Web, REST, AWS S3, GCS, etc.). Il souhaite un lakehouse consolidé, afin que toutes les données de différentes sources d’application métier, locales et cloud se trouvent dans un emplacement unique. Leo passe en revue les options et sélectionne l’activité de copie de pipeline comme choix approprié pour sa copie binaire brute. Ce modèle s’applique à l’actualisation des données historiques et incrémentielles. Avec l’activité de copie, Leo peut charger des données or dans un entrepôt de données sans code si le besoin se présente et les pipelines fournissent une ingestion de données à grande échelle qui peut déplacer des données à l’échelle du pétaoctet. L’activité de copie est le meilleur choix à faible code et sans code pour déplacer des pétaoctets de données vers des lakehouses et des entrepôts à partir de différentes sources, soit ad hoc, soit via une planification.
Scénario2
Mary est une ingénieure données avec une connaissance approfondie des multiples exigences en matière de création de rapports analytiques d’application métier. Une équipe en amont a correctement implémenté une solution pour migrer les données historiques et incrémentielles de plusieurs applications métier vers un lakehouse commun. Mary a été chargée de nettoyer les données, d’appliquer des logiques métier et de les charger dans plusieurs destinations (telles qu’Azure SQL DB, ADX et un lakehouse) en préparation de leurs équipes de création de rapports respectives.
Mary est un utilisateur Power Query expérimenté, et le volume de données se trouve dans la plage faible à moyenne pour atteindre les performances souhaitées. Les dataflows fournissent des interfaces sans code ou à faible code pour l’ingestion de données à partir de centaines de sources de données. Avec les dataflows, vous pouvez transformer des données à l’aide des options de transformation de données 300+ et écrire les résultats dans plusieurs destinations avec une interface utilisateur très visuelle et facile à utiliser. Mary passe en revue les options et décide qu’il est judicieux d’utiliser Dataflow Gen 2 comme option de transformation préférée.
Scénario3
Adam est ingénieur données travaillant pour une grande entreprise de vente au détail qui utilise un lakehouse pour stocker et analyser ses données client. Dans le cadre de son travail, Adam est responsable de la création et de la maintenance des pipelines de données qui extraient, transforment et chargent des données dans le lakehouse. L’une des exigences métier de l’entreprise consiste à effectuer des analyses de révision des clients pour obtenir des informations sur les expériences de leurs clients et améliorer leurs services.
Adam décide que la meilleure option consiste à utiliser spark pour générer la logique d’extraction et de transformation. Spark fournit une plateforme informatique distribuée qui peut traiter de grandes quantités de données en parallèle. Il écrit une application Spark à l’aide de Python ou Scala, qui lit des données structurées, semi-structurées et non structurées de OneLake pour les avis et commentaires des clients. L’application nettoie, transforme et écrit des données dans des tables Delta dans le lakehouse. Les données sont ensuite prêtes à être utilisées pour l’analytique en aval.