Ingérer des données dans l’entrepôt

S’applique à :✅Entrepôt dans Microsoft Fabric

L’entrepôt dans Microsoft Fabric fournit des outils d’ingestion de données intégrés. Utilisez ces outils pour ingérer des données dans des entrepôts à grande échelle à l’aide d’expériences sans code ou riches en code.

Choisir un outil d’ingestion de données

Choisissez une option d’ingestion de données en fonction des critères suivants :

  • Utilisez l’instruction COPY (Transact-SQL) pour les opérations d’ingestion de données riches en code. Il fournit le débit d’ingestion de données le plus élevé. Utilisez-la lorsque vous devez ajouter l’ingestion de données dans le cadre de votre logique de Transact-SQL.
    • Pour commencer, consultez Ingestion de données à l’aide de l’instruction COPY.
    • Le Warehouse prend également en charge l’instruction traditionnelle BULK INSERT à des fins de compatibilité. Dans Fabric Data Warehouse, cette instruction correspond au comportement COPY INTO avec les options de chargement classiques.
    • L’instruction COPY dans Warehouse prend en charge les sources de données à partir de comptes de stockage Azure et de dossiers OneLake lakehouse.
    • Spécifiez Workspace Identity dans la clause CREDENTIAL pour emprunter l’identité de l’espace de travail Fabric afin d’accéder à la source. Par exemple : CREDENTIAL = (IDENTITY = 'Workspace Identity'). La déclaration continue de s’exécuter dans le contexte de sécurité SQL de l’utilisateur actuel.
  • Utilisez l’API BCP (version préliminaire) pour l’ingestion directe côté client lorsque les données se trouvent dans votre couche applicative et que vous ne pouvez pas d’abord précharger les fichiers.
    • Pour commencer, consultez Ingestion de données à l’aide de l’API BCP (préversion).
    • L’API BCP prend en charge les scripts bcp.exe et les API d’application tels que C# SqlBulkCopy et JavaSQLServerBulkCopy.
    • Pour une ingestion de fichiers au débit le plus élevé, privilégiez COPY INTO chaque fois qu’une préparation intermédiaire est possible.
  • Utilisez des pipelines pour les processus d’ingestion de données fiables, sans code ou à faible code, qui s’exécutent à plusieurs reprises, selon une planification, ou qui impliquent de grands volumes de données.
    • Pour commencer, consultez Ingestion de données dans votre entrepôt à l’aide de pipelines.
    • En utilisant des pipelines, vous pouvez orchestrer des flux de travail robustes pour une expérience complète d’extraction, de transformation, de chargement (ETL). Cette expérience inclut des activités permettant de préparer l’environnement de destination, d’exécuter des instructions de Transact-SQL personnalisées, d’effectuer des recherches ou de copier des données d’une source vers une destination.
  • Utilisez des dataflows pour une expérience sans code qui permet des transformations personnalisées vers des données sources avant l’ingestion.
    • Pour commencer, consultez Ingestion de données à l’aide d’un dataflow.
    • Ces transformations incluent (mais ne sont pas limitées à) la modification des types de données, l’ajout ou la suppression de colonnes, ou l’utilisation de fonctions pour produire des colonnes calculées.
  • Utilisez l’ingestion T-SQL pour les expériences riches en code pour créer de nouvelles tables ou mettre à jour des tables existantes avec des données sources dans le même espace de travail ou le même stockage externe.
    • Pour commencer, consultez Ingestion de données dans votre entrepôt à l’aide de Transact-SQL.
    • Utilisez des fonctionnalités Transact-SQL telles que INSERT...SELECT, SELECT INTO ou CREATE TABLE AS SELECT (CTAS) pour lire les données des tables qui référencent d’autres entrepôts, lakehouses ou bases de données mises en miroir dans le même espace de travail. Vous pouvez également utiliser ces fonctionnalités pour lire les données de la fonction OPENROWSET qui référence des fichiers dans des comptes de stockage Azure externes.
    • Vous pouvez également écrire des requêtes inter-bases de données entre différents entrepôts de votre espace de travail Fabric.

Formats de données et sources pris en charge

L’ingestion de données pour Warehouse dans Microsoft Fabric prend en charge de nombreux formats et sources de données. Chaque option décrite dans cet article inclut sa propre liste de types de connecteurs de données et de formats de données pris en charge.

Pour l’ingestion T-SQL, les sources de données de table doivent se trouver dans le même espace de travail Microsoft Fabric et les sources de données de fichier doivent se trouver dans Azure Data Lake ou Azure Stockage Blob. Vous pouvez interroger des données à l’aide d’un nommage en trois parties ou de la OPENROWSET fonction pour les données sources. Les sources de données de table peuvent faire référence à des jeux de données Delta Lake, tandis que OPENROWSET peut faire référence à des fichiers Parquet, CSV ou JSONL dans Azure Data Lake ou Azure Blob Storage.

Par exemple, supposons qu’un espace de travail a deux entrepôts, nommés Inventory et Sales. Une requête telle que la suivante crée une table dans l’entrepôt Inventory avec le contenu d’une table dans l’entrepôt Inventory jointe à une table dans l’entrepôt Sales , ainsi que des fichiers externes contenant des informations client :

CREATE TABLE Inventory.dbo.RegionalSalesOrders
AS
SELECT 
    s.SalesOrders,
    i.ProductName,
    c.CustomerName
FROM Sales.dbo.SalesOrders s
JOIN Inventory.dbo.Products i
    ON s.ProductID = i.ProductID
JOIN OPENROWSET( BULK 'abfss://<container>@<storage>.dfs.core.windows.net/<customer-file>.csv' ) AS c
    ON s.CustomerID = c.CustomerID
WHERE s.Region = 'West region';

Note

La lecture des données à l’aide OPENROWSET peut être plus lente que l’interrogation de données à partir d’une table. Si vous envisagez d’accéder à plusieurs reprises aux mêmes données externes, envisagez de l’ingérer dans une table dédiée pour améliorer les performances et l’efficacité des requêtes.

L’instruction COPY (Transact-SQL) prend en charge les formats de fichiers CSV, JSONL et PARQUET. Les sources de données prises en charge incluent Azure Data Lake Storage (ADLS) Gen2, Stockage Blob Azure et OneLake.

Pour les scénarios d’ingestion directe côté client, l’API BCP (version préliminaire) prend en charge des outils et des API tels que bcp.exe, C# SqlBulkCopy et Java SQLServerBulkCopy via des connexions SQL, sans passer d’abord par des fichiers intermédiaires.

Les pipelines et les dataflows prennent en charge un large éventail de sources de données et de formats de données. Pour plus d’informations, consultez Pipelines et dataflows.

Utiliser l’identité de l’espace de travail avec COPY INTO

Utilisez Workspace Identity avec COPY INTO pour séparer l’accès aux données source de l’autorisation d’écriture dans la table cible de l’entrepôt de données. L’identité de l’espace de travail est prise en charge pour Stockage Blob Azure, ADLS Gen2 et les sources OneLake. La déclaration s’exécute dans le contexte de sécurité SQL de l’utilisateur actuel. La WITH (CREDENTIAL = (IDENTITY = 'Workspace Identity')) clause ne permet COPY INTO d’usurper l’identité de l’espace de travail que lorsqu’il accède à la source. Toutes les permissions SQL et l’attribution d’audit restent associées à l’utilisateur exécutant.

Sans l’identité de l’espace de travail, un utilisateur qui reçoit l’accès à l’entrepôt via le partage d’éléments peut fonctionner COPY INTO avec au moins la permission de lire l’élément et les permissions SQL requises.

Complétez la configuration suivante avant de lancer COPY INTO avec Workspace Identity :

  1. Configurez un identifiant d’espace de travail pour l’espace de travail contenant l’entrepôt cible.
  2. Accordez à l’identité de l’espace de travail l’accès à la source :
    • Pour Stockage Blob Azure et ADLS Gen2, trouvez l’identité de l’espace de travail par le nom de l’espace de travail, et attribuez le rôle Storage Blob Data Reader sur le compte ou conteneur de stockage. Pour l’accès au niveau de l’annuaire ADLS Gen2, accordez les autorisations ACL requises. Attribuez des permissions à l’identité de l’espace de travail comme vous le feriez à un utilisateur Microsoft Entra.
    • Pour OneLake, trouvez l’identité de l’espace de travail par le nom de l’espace de travail, ajoutez-le à l’espace de travail contenant les données sources, et attribuez au moins le rôle d’espace de travail contributeur.
  3. Attribuez à l’utilisateur exécutant au moins le rôle Visualiseur sur l’espace de travail contenant l’entrepôt cible. Les permissions d’éléments seules n’autorisent pas un utilisateur à usurper l’identité de l’espace de travail. L’exigence de rôle dans l’espace de travail ne s’applique que lorsque l’utilisateur spécifie l’identité de l’espace de travail.
  4. Accordez l’autorisation à l’utilisateur INSERT exécutant sur la table cible. Lorsque l’identité de l’espace de travail sert d’identifiant d’authentification, l’autorisation ADMINISTER DATABASE BULK OPERATIONS n’est pas requise.

L’exemple suivant charge un fichier CSV depuis OneLake en usurpant l’identité de l’espace de travail pour accéder au code source :

COPY INTO dbo.SalesOrders
FROM 'https://onelake.dfs.fabric.microsoft.com/<workspace-id>/<item-id>/Files/orders/*.csv'
WITH (
    FILE_TYPE = 'CSV',
    FIRSTROW = 2,
    CREDENTIAL = (IDENTITY = 'Workspace Identity')
);

Important

Les politiques d’étiquette de sensibilité varient selon les organisations. COPY INTO peut échouer lorsque la destination possède une étiquette de sensibilité avec des restrictions qui empêchent l’opération. Si une étiquette de sensibilité provoque la défaillance, retirez l’étiquette de la destination avant de réessayer la commande.

Meilleures pratiques

La COPY commande dans Warehouse dans Microsoft Fabric offre une interface simple, flexible et rapide pour l’ingestion de données à haut débit pour les charges SQL depuis stockage Azure et OneLake.

Vous pouvez également utiliser le langage T-SQL pour créer une table, puis l’insérer, puis mettre à jour et supprimer des lignes de données. Vous pouvez insérer des données à partir de n’importe quelle base de données dans l’espace de travail Microsoft Fabric à l’aide de requêtes inter-bases de données. Si vous souhaitez ingérer des données d’un lakehouse vers un entrepôt, vous pouvez le faire avec une requête inter-bases de données. Par exemple:

INSERT INTO MyWarehouseTable
SELECT * FROM MyLakehouse.dbo.MyLakehouseTable;
  • Évitez d’ingérer des données à l’aide d’instructions singleton INSERT , car cette approche entraîne des performances médiocres sur les requêtes et les mises à jour. Si vous utilisez des instructions singleton INSERT pour l’ingestion de données consécutivement, créez une table à l’aide des modèles CREATE TABLE AS SELECT (CTAS) ou INSERT...SELECT, supprimez la table d’origine, puis recréez votre table à partir de la table que vous avez créée à l’aide de CREATE TABLE AS SELECT (CTAS).
    • La suppression de votre table existante a un impact sur votre modèle sémantique, y compris les mesures personnalisées ou les personnalisations que vous avez peut-être apportées au modèle sémantique.
  • Lorsque vous utilisez des données externes sur des fichiers, vérifiez que les fichiers sont de taille d’au moins 4 Mo.
  • Pour les fichiers CSV compressés volumineux, envisagez de fractionner votre fichier en plusieurs fichiers.
  • Azure Data Lake Storage (ADLS) Gen2 offre de meilleures performances que l'ancien Stockage Blob Azure. Envisagez d’utiliser un compte ADLS Gen2 aussi souvent que possible.
  • Pour les pipelines qui s’exécutent fréquemment, envisagez d’isoler votre compte de stockage Azure d’autres services qui peuvent accéder aux mêmes fichiers en même temps.
  • Les transactions explicites vous permettent de regrouper plusieurs modifications de données afin qu’elles soient visibles uniquement lors de la lecture d’une ou plusieurs tables lorsque la transaction est entièrement validée. Vous avez également la possibilité de restaurer la transaction si l’une des modifications échoue.
  • Si un SELECT se trouve dans une transaction et a été précédé d’insertions de données, les statistiques générées automatiquement peuvent être inexactes après une annulation. Des statistiques inexactes peuvent entraîner des plans de requête et des temps d’exécution non optimisés. Si vous annulez une transaction avec SELECTs après un INSERT important, mettez à jour les statistiques pour les colonnes mentionnées dans votre SELECT.

Note

Quelle que soit la façon dont vous ingérez des données dans des entrepôts, la tâche d’ingestion des données optimise les fichiers parquet qu’elle produit à l’aide de l’optimisation d’écriture V-Order. V-Order optimise les fichiers Parquet pour permettre des lectures ultra-rapides sous les moteurs de calcul Microsoft Fabric tels que Power BI, SQL, Spark et autres. En général, les requêtes d’entrepôt bénéficient de temps de lecture plus rapides grâce à cette optimisation, tout en garantissant que les fichiers Parquet sont 100% conformes à leur spécification open source. Ne désactivez pas V-Order, car cela peut affecter les performances de lecture. Pour plus d’informations sur V-Order, consultez Comprendre et gérer V-Order pour les entrepôts.

Questions fréquemment posées sur l’ingestion des données pour Fabric Data Warehouse

Quelles sont les directives de division de fichier pour la commande COPY pendant le chargement de fichiers CSV ?

Envisagez de fractionner des fichiers CSV volumineux, en particulier lorsque le nombre de fichiers est petit, mais conservez au minimum 4 Mo chacun pour obtenir de meilleures performances.

Quelles sont les recommandations de fractionnement de fichiers pour la commande COPY lors du chargement de fichiers Parquet ?

Envisagez de fractionner des fichiers Parquet volumineux, en particulier lorsque le nombre de fichiers est petit.

Existe-t-il des restrictions quant au nombre ou à la taille des fichiers ?

Il n’existe aucune limitation quant au nombre ou à la taille des fichiers. Toutefois, pour des performances optimales, utilisez des fichiers d’au moins 4 Mo.

Quel identifiant la commande COPY utilise-t-il si je n’en spécifie pas un ?

Par défaut, COPY INTO il utilise l'identité Microsoft Entra de l'utilisateur exécutant pour l'accès au code source.