Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Utilisez ce guide de référence et les exemples de scénarios pour vous aider à déterminer si vous avez besoin d’une activité de copie, d’un travail de copie, d’un flux de données, d’un flux d’événements ou de Spark pour vos charges de travail Microsoft Fabric.
Activité de copie, travail de copie, flux de données, flux d’événements et propriétés Spark
| Activité de copie de pipeline | Tâche de copie | Dataflow Gen 2 | Eventstream | Étincelle | |
|---|---|---|---|---|---|
| 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, Copie incrémentielle, Réplication Migration de Data Lake et data Warehouse, transformation légère |
Ingestion des données, transformation des données, préparation des données profilage des données |
ingestion des données d’événement, transformation des données d’événement |
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 |
Analyste d'affaires Intégrateur de données, Ingénieur Data |
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 |
Intégrateur de données, ingénieur données |
| ensemble de compétences principal du développeur | ETL, SQL JSON |
ETL, SQL JSON |
ETL, M, SQL |
SQL, JSON, messagerie | Spark (Scala, Python, Spark SQL, R) |
| Code écrit | Aucun code, peu de code |
Aucun code, peu de code |
Aucun code, peu de code |
Aucun code, peu de code |
Code |
| Volume de données | De faible à élevé | De faible à élevé | De faible à élevé | Moyenne à élevée | De faible à élevé |
| Interface de développement | Sorcier canevas |
Sorcier canevas |
Power Query | Toile | Carnet de notes Définition du travail Spark |
| Sources | 50+ connecteurs | 50+ connecteurs | 150+ connecteurs | Base de données prenant en charge cdc (capture de données modifiées), Kafka, systèmes de messagerie qui prennent en charge le modèle de publication et d’abonnement, flux d’événements | Centaines de bibliothèques Spark |
| Destinations | 40+ connecteurs | 40+ connecteurs | Lakehouse, Base de données Azure SQL, Explorateur de données Azure, Azure Synapse Analytics |
Eventhouse, Lakehouse, Alert Activateor, Stream dérivé, point de terminaison personnalisé | 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 : léger : conversion de type, mappage de colonnes, fusion/fractionnement de fichiers, hiérarchie aplate |
Faible à élevé : 300+ fonctions de transformation |
Bas: léger |
Faible à élevé : prise en charge des bibliothèques Spark natives et open source |
Scénarios
Passez en revue les scénarios suivants pour obtenir de l’aide sur le choix de l’utilisation de vos données dans Fabric.
Scénario 1
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é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 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énario 3
Prashant, intégrateur de données avec une expertise approfondie dans les processus et systèmes métier. Une équipe en amont a correctement exposé les données d’événements des applications métier en tant que messages qui peuvent être consommés via des systèmes en aval. Prashant a été affecté pour intégrer des données d’événements à partir d’applications métier dans Microsoft Fabric pour prendre en charge les décisions en temps réel.
Compte tenu du volume de données moyen à élevé et de la préférence de l’organisation pour les solutions sans code, Prashant cherche un moyen de transférer en toute transparence les événements au fur et à mesure qu’ils se produisent sans gérer les planifications d’extraction. Pour répondre à ce besoin, il choisit Eventstreams dans Microsoft Fabric. Les flux d’événements au sein de l’expérience Real-Time Intelligence permettent l’ingestion, la transformation et le routage en temps réel des données vers différentes destinations, sans écrire de code.
Scénario 4
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 qui extraient, transforment et chargent des données dans la 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.
Scénario 5
Rajesh, ingénieur données, est chargé d’ingérer des données incrémentielles à partir d’un serveur SQL Server local dans une base de données Azure SQL Database. L’instance SQL Server locale de Rajesh a déjà activé la capture de données modifiées (CDC) sur les tables clés.
Rajesh recherche une solution simple, faible en code et guidée par un assistant qui lui permet de :
- Sélectionnez plusieurs tables sources natives avec CDC activé
- Effectuer une charge complète initiale
- Passer automatiquement à des chargements de données incrémentielles basés sur la CDC
- Planifier les actualisations des données pour les mises à jour périodiques
Il souhaite éviter d’écrire du code personnalisé ou de gérer des orchestrations complexes. Idéalement, il veut un « Assistant 5x5 » où il peut accomplir la configuration en quelques clics.
Rajesh choisit la fonctionnalité Copier le travail dans Microsoft Fabric. Avec la prise en charge de la passerelle locale, il se connecte en toute sécurité à son SQL Server, sélectionne les tables souhaitées et configure le flux pour être intégré dans la base de données cible Azure SQL Database.
Le travail de copie offre une expérience de déplacement de données à faible friction et évolutive, répondant aux exigences de Rajesh sans avoir à gérer des pipelines complexes.