Guide de décision Microsoft Fabric : activité de copie, 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 flux de données ou de 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 de lac de données et d’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 de données, profilage des données |
| Personnage de développeur principal | Ingénieur des données, intégrateur de données |
Ingénieur des données, intégrateur de données, analyste d'entreprise |
Ingénieur des données, scientifique des données, développeur de données |
| Ensemble de compétences de développeur principal | ETL, SQL, JSON |
ETL, M, SQL |
Spark (Scala, Python, Spark SQL, R) |
| Code écrit | Pas de code, peu de code |
Pas de code, peu de code |
Code |
| Volume de données | Faible à élevé | Faible à élevé | Faible à élevé |
| Interface de développement | Assistant, canevas |
Power Query | Notebook, Définition d’un travail Spark |
| Sources | Plus de 30 connecteurs | Plus de 150 connecteurs | Des 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 |
Des centaines de bibliothèques Spark |
| Complexité de la transformation | Basse : léger : conversion de type, mappage de colonnes, fusion/fractionnement de fichiers, hiérarchie aplatie |
Faible à élevé : Plus de 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 vous aider à décider comment utiliser vos données dans Fabric.
Scénario 1
Leo, un 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 connecteur ou opération de déplacement de données. Il veut suivre les meilleures pratiques des couches de médaillon, avec le bronze, l’argent et l’or. Leo n’ayant aucune expérience avec Spark, il préfère autant que possible l’interface utilisateur glisser-déplacer, avec un codage minimal. Et 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énario 2
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 que Azure SQL DB, ADX et un lakehouse) en préparation pour leurs équipes de création de rapports respectives.
Mary est une utilisatrice Power Query expérimentée, et le volume de données est dans la plage faible à moyenne pour atteindre les performances souhaitées. Les flux de données fournissent des interfaces sans code ou à faible code pour l’ingestion de données à partir de centaines de sources de données. Avec les flux de données, vous pouvez transformer des données à l’aide de plus de 300 options de transformation de données 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énario 3
Adam est un ingénieur de 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 est d’analyser les avis 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 de calcul 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 à partir 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’analyse en aval.