Partage via

Guide de décision Microsoft Fabric : activité de copie, flux de données ou Spark

  • Article

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.

Contenu connexe