Lire en anglais

Partager via

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

  • Article

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

Warehouse in Microsoft Fabric propose des outils d’ingestion de données intégrés qui permettent aux utilisateurs d’ingérer des données dans des entrepôts à grande échelle à l’aide d’expériences sans code ou riches en code.

Options d’ingestion des données

Vous pouvez ingérer des données dans un entrepôt à l’aide de l’une des options suivantes :

  • COPY (Transact-SQL) : l’instruction COPY offre une ingestion de données flexible et à haut débit à partir d’un compte de stockage Azure externe. Vous pouvez utiliser l’instruction COPY dans le cadre de votre logique ETL/ELT existante dans le code Transact-SQL.
  • Pipelines de données : les pipelines offrent une expérience sans code ou à faible code pour l’ingestion de données. À l’aide de pipelines, vous pouvez orchestrer des workflows robustes pour une expérience d’extraction, de transformation, de chargement (ETL) complète qui inclut des activités pour préparer l’environnement de destination, exécuter des instructions Transact-SQL personnalisées, effectuer des recherches ou copier des données d’une source vers une destination.
  • Flux de données : alternative aux pipelines, les flux de données facilitent la préparation, le nettoyage et la transformation des données à l’aide d’une expérience sans code.
  • Ingestion entre entrepôts : l’ingestion de données à partir de sources d’espace de travail est également possible. Ce scénario peut être nécessaire lorsqu’il est nécessaire de créer une table avec un sous-ensemble d’une autre table, ou en raison de la jointure de différentes tables dans l’entrepôt et dans le lakehouse. Pour l’ingestion entre entrepôts, en plus des options mentionnées, les fonctionnalités Transact-SQL telles que INSERT... SELECT, SELECT INTO ou CREATE TABLE AS SELECT (CTAS) fonctionnent entre entrepôts au sein du même espace de travail.

Déterminer l’outil d’ingestion de données à utiliser

Pour déterminer l’option d’ingestion de données à utiliser, vous pouvez utiliser les critères suivants :

  • Utilisez l’instruction COPY (Transact-SQL) pour les opérations d’ingestion de données riches en code, pour obtenir le débit d’ingestion de données le plus élevé possible ou lorsque vous devez ajouter une ingestion de données dans le cadre d’une logique Transact-SQL. Pour plus d’informations sur la syntaxe, consultez COPY INTO (Transact-SQL).
  • Utilisez des pipelines de données pour les workflows d’ingestion de données robustes ou sans code ou à faible code qui s’exécutent à plusieurs reprises, selon une planification ou qui impliquent de grands volumes de données. Pour plus d’informations, consultez Ingérer des données à l’aide de pipelines de données.
  • Utilisez des flux de données pour une expérience sans code qui permet des transformations personnalisées dans les données sources avant qu’elles ne soit ingérées. 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. Pour plus d’informations, consultez Flux de données.
  • Utilisez l’ingestion entre entrepôts pour des expériences riches en code afin de créer de nouvelles tables avec des données sources dans le même espace de travail. Pour plus d’informations, consultez Ingérer des données à l’aide de Transact-SQL et Écrire une requête inter-bases de données.

Note

L’instruction COPY dans l’entrepôt prend en charge uniquement les sources de données sur les comptes de stockage Azure ; les sources OneLake ne sont actuellement pas prises en charge.

Formats de données et sources pris en charge

L’ingestion de données pour Warehouse dans Microsoft Fabric offre un grand nombre de formats et de sources de données que vous pouvez utiliser. Chacune des options décrites inclut sa propre liste de types de connecteurs de données et de formats de données pris en charge.

Pour l’ingestion entre entrepôts, les sources de données doivent se trouver dans le même espace de travail Microsoft Fabric. Les requêtes peuvent être effectuées à l’aide d’un nommage en trois parties pour les données sources.

Par exemple, supposons qu’il y ait deux entrepôts nommés Stock et Sales dans un espace de travail. Une requête telle que la suivante crée une table dans l’entrepôt d’inventaire avec le contenu d’une table dans l’entrepôt Stock, jointe à une table dans l’entrepôt Sales :

SQL 
CREATE TABLE Inventory.dbo.RegionalSalesOrders
AS
SELECT s.SalesOrders, i.ProductName
FROM Sales.dbo.SalesOrders s
JOIN Inventory.dbo.Products i
WHERE s.ProductID = i.ProductID
    AND s.Region = 'West region'

L’instruction COPY (Transact-SQL) prend actuellement en charge les formats de fichiers PARQUET et CSV. Pour les sources de données, Azure Data Lake Storage (ADLS) Gen2 et Stockage Blob Azure sont actuellement pris en charge.

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

Bonnes pratiques

La fonctionnalité de commande COPY dans Warehouse dans Microsoft Fabric utilise une interface simple, flexible et rapide pour l’ingestion de données à haut débit pour les charges de travail SQL. Dans la version actuelle, nous prenons uniquement en charge le chargement de données à partir de comptes de stockage externes.

Vous pouvez également utiliser TSQL pour créer une table, puis y insérer, puis mettre à jour et supprimer des lignes de données. Les données peuvent être inséré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 :

SQL 
INSERT INTO MyWarehouseTable
SELECT * FROM MyLakehouse.dbo.MyLakehouseTable;
  • Évitez d’ingérer des données à l’aide d’instructions INSERT singleton, car cela entraîne des performances médiocres sur les requêtes et les mises à jour. Si des instructions INSERT singleton ont été utilisées pour l’ingestion des données consécutivement, nous vous recommandons de créer une table à l’aide des modèles CREATE TABLE AS SELECT (CTAS) ou INSERT... SELECT, en supprimant la table d’origine, puis en créant à nouveau 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, nous vous recommandons d’avoir une taille de fichiers 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 Stockage Blob Azure (hérité). 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 élément 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 restauration. Des statistiques inexactes peuvent entraîner des plans de requête et des temps d’exécution non optimisés. Si vous restaurez une transaction avec des SELECT après un insert volumineux, mettez à jour les statistiques pour les colonnes mentionnées dans votre fichier SELECT.

Note

Quelle que soit la manière dont vous ingérez les données dans les entrepôts, les fichiers parquet produits par la tâche d'ingestion de données seront optimisés à 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. Les requêtes d'entrepôt bénéficient en général de temps de lecture plus rapides pour les requêtes avec cette optimisation, tout en garantissant que les fichiers parquet sont 100 % conformes à sa spécification open source. Contrairement à l’ingénierie des données Fabric, V-Order est un paramètre global dans l’entrepôt de données Fabric qui ne peut pas être désactivé. Pour plus d’informations sur V-Order, consultez Comprendre et gérer V-Order pour les entrepôts.

Contenu connexe