Connecter, interroger et exporter des données avec PolyBase

S'applique à : SQL Server 2016 (13.x) et versions ultérieures Azure SQL DatabaseAzure SQL Managed InstanceBase de données SQL dans Microsoft Fabric

La virtualisation des données vous permet d’exécuter des requêtes Transact-SQL (T-SQL) sur des données externes sans les charger dans votre base de données. Vous définissez une source de données externe, un format de fichier facultatif et une table externe, puis interrogez la table externe comme SELECT n’importe quelle autre table.

Ce guide vous aide à :

Support de la plateforme

• PolyBase est une fonctionnalité du Microsoft SQL Moteur de base de données qui implémente la virtualisation des données.
• PolyBase est pris en charge dans SQL Server 2016 et les versions ultérieures sur Windows, ainsi que dans SQL Server 2019 et versions ultérieures sous Linux.
  • PolyBase n'est pas pris en charge dans SQL Server 2017 sous Linux.
• PolyBase n'est pas pris en charge par Azure SQL Database, mais Azure SQL Database offre des capacités de virtualisation des données associées via OPENROWSET des tables externes. Pour plus d’informations, consultez Virtualisation des données avec Azure SQL Database (préversion).
• PolyBase n'est pas une fonctionnalité nommée dans Azure SQL Managed Instance, mais Azure SQL Managed Instance propose des fonctionnalités de virtualisation de données qui fonctionnent de manière similaire. Pour plus d’informations, consultez Virtualisation des données avec Azure SQL Managed Instance (préversion).
• PolyBase n'est pas pris en charge dans la base de données SQL dans Fabric, mais la base de données SQL dans Fabric offre ses propres capacités de virtualisation des données dans OneLake. Pour plus d’informations, voir Virtualisation des données dans une base de données SQL dans Fabric.
• PolyBase n'est pas une fonctionnalité dans Fabric Data Warehouse. Pour la virtualisation des données dans Fabric Data Warehouse, envisagez les raccourcis OneLake de Fabric. Pour les articles sur le chargement de données en Fabric Data Warehouse, voir Ingestion de données avec T-SQL et Modélisation dimensionnelle : tables de chargement.

Cas d’utilisation courants

Le tableau suivant décrit les scénarios d’utilisation possibles.

• Pour l’exploration de fichiers ad hoc, utilisez OPENROWSET(BULK ...) pour inspecter des fichiers sans créer de table réutilisable.
• Pour les requêtes de fichiers réutilisables dans les scénarios de BI ou de reporting, utilisez des tables externes plutôt que des fichiers pour faire persister un schéma et partager les résultats entre requêtes.
• Pour l’interrogation multi-base de données, utilisez des connecteurs PolyBase avec des tables externes pour accéder à SQL Server, Oracle, Teradata, MongoDB ou ODBC.
• Pour exporter les résultats des requêtes vers des fichiers, utilisez CREATE EXTERNAL TABLE AS SELECT (CETAS) pour écrire des sorties Parquet ou CSV en dehors de la base de données.
• Pour l’ingestion massive dans les tables, utilisez BULK INSERT ou OPENROWSET(BULK ...) avec INSERT ... SELECT pour charger les données des fichiers dans les tables de la base de données.

Quelles fonctionnalités sont disponibles à quel endroit ?

Le tableau suivant montre quelles fonctionnalités principales de PolyBase et de virtualisation des données sont disponibles sur chaque plateforme SQL à partir de SQL Server 2019. Pour la disponibilité des fonctionnalités dans SQL Server 2016 et SQL Server 2017 sous Windows, voir fonctionnalités et limitations de PolyBase. Utilisez ce tableau pour déterminer ce que vous pouvez faire sur votre plateforme avant d’utiliser les guides détaillés.

¹ SQL Server 2019 (15.x) prend en charge OPENROWSET(BULK...) les chemins de fichiers locaux et réseau. Dans SQL Server 2022 (16.x) et versions ultérieures, OPENROWSET(BULK...) prend également en charge la lecture à partir du stockage cloud avec FORMAT = 'PARQUET', FORMAT = DELTAet FORMAT = 'CSV'.

La prise en charge des fichiers CSV par ² dans SQL Server 2019 (15.x) nécessitait Hadoop. Dans SQL Server 2022 (16.x) et versions ultérieures, CSV est pris en charge en mode natif sans Hadoop.

³ Utilise le connecteur SQL Server (sqlserver://). Les informations d’identification définies au niveau de la base de données pointent vers le point de terminaison SQL. Utilisez les mêmes étapes que pour la connexion à une autre instance de SQL Server.

⁴ L’authentification par Identité managée est prise en charge pour la connexion au stockage Blob Azure (ABS) et à ADLS Gen2. Il nécessite SQL Server activé par Azure Arc ou SQL Server sur une machine virtuelle Azure pour la gestion de SQL Server sur site. Il est disponible en mode natif sur Azure SQL Database et Azure SQL Managed Instance.

⁵ SQL Server 2019 CU11 et les versions ultérieures prennent en charge Azure Data Lake Storage Gen2 avec le préfixe abfs ou abfss. Dans SQL Server 2022 et les versions ultérieures, utilisez le adls préfixe.

• Les tables externes sont prises en charge dans SQL Server 2019, SQL Server 2022, SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance et la base de données SQL dans Microsoft Fabric.
• OPENROWSET (BULK) est pris en charge dans SQL Server 2019, SQL Server 2022, SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance et la base de données SQL dans Microsoft Fabric. SQL Server 2019 prend en charge les chemins de fichiers locaux et réseau, tandis que SQL Server 2022 et versions ultérieures prennent également en charge la lecture du stockage cloud avec FORMAT = 'PARQUET', FORMAT = DELTA, et FORMAT = 'CSV'.
• L'exportation CETAS n'est pas prise en charge dans SQL Server 2019, Azure SQL Database, ni SQL Database dans Microsoft Fabric. L’exportation CETAS est prise en charge dans SQL Server 2022, SQL Server 2025 et Azure SQL Managed Instance.
• Les fichiers CSV et délimités sont pris en charge dans SQL Server 2019, SQL Server 2022, SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Microsoft Fabric. SQL Server 2019 nécessite Hadoop pour la prise en charge du CSV, tandis que SQL Server 2022 et versions ultérieures prennent en charge le CSV nativement sans Hadoop.
• Les fichiers Parquet ne sont pas pris en charge dans SQL Server 2019. Les fichiers Parquet sont pris en charge dans SQL Server 2022, SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance et la base de données SQL dans Microsoft Fabric.
• Les tables Delta Lake ne sont pas prises en charge dans SQL Server 2019, Azure SQL Database, Azure SQL Managed Instance, ni SQL Database dans Microsoft Fabric. Les tables Delta Lake sont prises en charge dans SQL Server 2022 et SQL Server 2025.
• La connexion à une autre instance SQL Server est prise en charge dans SQL Server 2019, SQL Server 2022 et SQL Server 2025. La connexion à une autre instance SQL Server n'est pas prise en charge depuis Azure SQL Database, Azure SQL Managed Instance, ni la base de données SQL dans Microsoft Fabric.
• La connexion à Azure SQL Database ou Azure SQL Managed Instance est prise en charge depuis SQL Server 2019, SQL Server 2022 et SQL Server 2025 via le connecteur SQL Server. Les informations d’identification délimitées à la base de données ciblent le point de terminaison d’Azure SQL Database ou d’Azure SQL Managed Instance, et les étapes de configuration sont les mêmes que pour établir une connexion à une autre instance de SQL Server. Ces connexions ne sont pas prises en charge par Azure SQL Database, Azure SQL Managed Instance, ou SQL Database dans Microsoft Fabric.
• La connexion à Oracle, Teradata ou MongoDB est prise en charge depuis SQL Server 2019, SQL Server 2022 et SQL Server 2025. Ces connexions ne sont pas prises en charge par Azure SQL Database, Azure SQL Managed Instance, ou SQL Database dans Microsoft Fabric.
• La connexion à Stockage Blob Azure est prise en charge par SQL Server 2019, SQL Server 2022, SQL Server 2025, Azure SQL Database et Azure SQL Managed Instance. La connexion à Stockage Blob Azure n'est pas prise en charge depuis la base de données SQL dans Microsoft Fabric.
• La connexion à ADLS Gen2 n'est pas prise en charge dans les versions de SQL Server 2019 antérieures à CU11 ni depuis la base de données SQL dans Microsoft Fabric. La connexion à ADLS Gen2 est prise en charge à partir de SQL Server 2019 CU11, ainsi que dans SQL Server 2022, SQL Server 2025, Azure SQL Database et Azure SQL Managed Instance.
• La connexion à un stockage compatible S3 n'est pas prise en charge par SQL Server 2019, Azure SQL Database, Azure SQL Managed Instance, ni base de données SQL dans Microsoft Fabric. La connexion au stockage compatible S3 est prise en charge depuis SQL Server 2022 et SQL Server 2025.
• La connexion à OneLake est prise en charge depuis la base de données SQL dans Microsoft Fabric. La connexion à OneLake n'est pas prise en charge par SQL Server 2019, SQL Server 2022, SQL Server 2025, Azure SQL Database ou Azure SQL Managed Instance.
• Le calcul par poussée est pris en charge dans SQL Server 2019, SQL Server 2022 et SQL Server 2025. Le calcul pushdown n’est pas pris en charge dans Azure SQL Database, ni dans Azure SQL Managed Instance, ni dans la base de données SQL dans Microsoft Fabric.
• L'authentification par identité managée n'est pas prise en charge dans SQL Server 2019 ni SQL Server 2022. L’authentification par identité managée est prise en charge dans SQL Server 2025 pour les connexions à Stockage Blob Azure et ADLS Gen2, et nécessite SQL Server ou SQL Server compatibles Azure Arc sur une machine virtuelle Azure. L'authentification Managed Identity est également prise en charge dans Azure SQL Database et Azure SQL Managed Instance, mais elle n'est pas prise en charge dans la base de données SQL de Microsoft Fabric.

Interroger des données externes

Avant de choisir un scénario spécifique, comprenez les trois façons d’interroger des données externes :

¹ Pour l'accès aux fichiers cloud dans SQL Server 2022 (16.x), vous devez installer la fonctionnalité PolyBase, mais les connecteurs de stockage compatibles Stockage Blob Azure, ADLS Gen2 et S3 ne dépendent pas des services PolyBase. SQL Server 2025 (17.x) et versions ultérieures offrent un support natif pour CSV, Parquet et Delta sans installer ni exécuter les services PolyBase.

• Les requêtes ad hoc OLE DB permettent OPENROWSET(provider, connection, query) un accès rapide et unique à une source de données distante sans créer d’objets persistants. Ils peuvent utiliser l’authentification SQL, l’authentification Windows Authentication ou Microsoft Entra ID avec MSOLEDBSQL. Ce scénario ne nécessite pas d’installation de PolyBase.
• Les requêtes ad hoc sur des fichiers servent OPENROWSET(BULK ...) à explorer rapidement les données de fichiers ou à tester un schéma avant de créer une table. Ils peuvent utiliser des jetons SAS, des clés d’accès, une identité gérée ou Microsoft Entra ID. SQL Server 2022 nécessite l'installation de la fonctionnalité PolyBase pour les fichiers cloud, mais il ne nécessite pas les services PolyBase. SQL Server 2025 et les versions ultérieures ne nécessitent pas PolyBase pour les fichiers cloud. Les requêtes ad hoc de fichier sont intégrées à Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Fabric.
• Les connecteurs de données persistants utilisent CREATE EXTERNAL TABLE avec sqlserver://, oracle://, teradata://, et des emplacements similaires pour l’accès récurrent, la gouvernance, les statistiques et le calcul par poussée dans les charges de travail en production. Ils nécessitent une authentification SQL et des services PolyBase.

Guide de décision

• Si vous avez besoin d’une authentification Microsoft Entra ID pour SQL distant ou souhaitez éviter les services PolyBase, utilisez OPENROWSET(MSOLEDBSQL, ...) les requêtes distantes ad hoc sans objets persistants.
• Si vous avez besoin de tables persistantes, de statistiques ou de calculs en poussée vers des bases de données distantes, utilisez CREATE EXTERNAL TABLE avec PolyBase des connecteurs tels que sqlserver://, oracle://, teradata://, mongodb://, et odbc://. OPENROWSET ne prend pas en charge ces connecteurs.
• Si vous explorez un nouveau fichier ou testez un schéma, utilisez OPENROWSET(BULK ...) pour itération rapide et sans objets persistants.
• Si vous ingérez des données de fichier dans une table avec des transformations, utilisez INSERT ... SELECT à partir de OPENROWSET(BULK ...).
• Si vous avez besoin de gouvernance ou d’accès partagé pour de nombreux utilisateurs ou applications, utilisez CREATE EXTERNAL TABLE ainsi que les permissions et les métadonnées sont centralisés.
• Si vous travaillez dans une base de données SQL dans Fabric, utilisez OPENROWSET(BULK ...) des requêtes OneLake ad hoc ou des tables externes pour un accès réutilisable, et utilisez des raccourcis OneLake pour le stockage externe.

Choisir votre scénario

Maintenant que vous comprenez les trois approches, utilisez l’un des guides suivants pour implémenter votre cas d’usage spécifique.

Fichiers de requête (Parquet, CSV ou Delta)

Si vos données se trouvent dans des fichiers Parquet, CSV ou Delta sur stockage Blob Azure, ADLS Gen2, stockage compatible S3 ou OneLake, suivez l’un des guides suivants :

• Pour une requête rapide et ad hoc sur un fichier Parquet ou CSV, utilisez OPENROWSET. Cette méthode ne nécessite pas de table externe. SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database, Azure SQL Managed Instance et SQL database in Fabric supportent ce schéma.
• Pour les requêtes répétées sur des fichiers Parquet avec un schéma persistant, utilisez une table externe sur Parquet. SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database, Azure SQL Managed Instance et SQL database in Fabric supportent ce schéma.
• Pour une requête sur des fichiers CSV, utilisez une table externe avec un format de fichier pour le texte délimité. SQL Server 2019 (15.x) et versions ultérieures, Azure SQL Database, Azure SQL Managed Instance et SQL database in Fabric supportent ce schéma.
• Pour une requête sur les tables Delta Lake, utilisez une table externe avec FILE_FORMAT = DeltaLakeFileFormat. SQL Server 2022 (16.x) et les versions ultérieures prennent en charge ce schéma.
• Pour exporter les résultats de requête vers des fichiers Parquet ou CSV, utilisez CREATE EXTERNAL TABLE AS SELECT. SQL Server 2022 (16.x) et les versions ultérieures ainsi que Azure SQL Managed Instance prennent en charge ce schéma.

Vous pouvez également suivre l’un des didacticiels pas à pas suivants :

Se connecter à une autre instance SQL Server, Azure SQL Database ou SQL Managed Instance

Dans SQL Server 2019 (15.x) et versions ultérieures, PolyBase peut interroger des tables dans une autre instance SQL Server, Azure SQL Database ou Azure SQL Managed Instance, sans utiliser de serveurs liés.

• 1. Installez PolyBase sur Windows ou Linux en utilisant Installer PolyBase sur Windows ou installez PolyBase sur Linux avant de configurer l’accès aux données SQL externes.
• 2. Créez des informations d’identification limitées à la base de données pour la connexion cible en utilisant CREATE DATABASE SCOPED CREDENTIAL afin que le moteur puisse s’authentifier auprès du serveur distant.
• 3. Créez une source de données externe pour le SQL Server distant en utilisant CREATE EXTERNAL DATA SOURCE ... WITH (LOCATION = 'sqlserver://<server>').
• 4. Créez une table externe en utilisant CREATE EXTERNAL TABLE ... WITH (LOCATION = '<db>.<schema>.<table>') pour représenter la table distante.
• 5. Interrogez la table externe en utilisant SELECT * FROM <external_table>.

Pour obtenir un guide détaillé, consultez Configurer PolyBase pour accéder aux données externes dans SQL Server.

Se connecter à Oracle, Teradata ou MongoDB

SQL Server 2019 (15.x) et versions ultérieures peuvent interroger Oracle, Teradata, MongoDB et Cosmos DB via des connecteurs ODBC PolyBase.

• Les sources de données Oracle utilisent le Configure PolyBase pour accéder aux données externes dans le guide Oracle et nécessitent SQL Server 2019 (15.x) et versions ultérieures, ainsi que des pilotes clients Oracle.
• Les sources de données Teradata utilisent le Configure PolyBase pour accéder aux données externes du guide Teradata et nécessitent SQL Server 2019 (15.x) et versions ultérieures ainsi que le pilote ODBC de Teradata.
• Les sources de données MongoDB ou Cosmos DB utilisent Configure PolyBase pour accéder aux données externes dans le guide MongoDB et nécessitent SQL Server 2019 (15.x) et versions ultérieures, ainsi que le pilote ODBC MongoDB.
• Toute source ODBC peut utiliser le guide Configurer PolyBase pour accéder aux données externes avec des types génériques ODBC et nécessite SQL Server 2019 (15.x) ou version ultérieure sous Windows, ou SQL Server 2025 (17.x) ou version ultérieure sous Linux.

Se connecter à Stockage Blob Azure ou à Azure Data Lake Storage Gen2

• SQL Server 2022 et versions ultérieures prennent en charge l’authentification Stockage Blob Azure ou ADLS Gen2 en utilisant des jetons SAS, des clés d’accès ou une identité managée à partir de SQL Server 2025 (17.x). Pour plus d’informations, consultez Configurer PolyBase pour accéder aux données externes dans Stockage Blob Azure.
• SQL Server 2019 prend en charge Stockage Blob Azure ou ADLS Gen2 en utilisant une clé d’accès via le connecteur Hadoop. Pour plus d’informations, consultez Configurer PolyBase pour accéder aux données externes dans Stockage Blob Azure.
• Azure SQL Database prend en charge Stockage Blob Azure ou ADLS Gen2 en utilisant des jetons SAS, Managed Identity ou l’authentification Microsoft Entra pass-through. Pour plus d’informations, consultez Virtualisation des données avec Azure SQL Database (préversion).
• Azure SQL Managed Instance prend en charge Stockage Blob Azure ou ADLS Gen2 en utilisant des jetons SAS ou Managed Identity. Pour plus d’informations, consultez Virtualisation des données avec Azure SQL Managed Instance (préversion).

Dans SQL Server 2022 (16.x), les préfixes d’URI ont changé. Lors de la migration à partir de SQL Server 2019 (15.x) ou des versions antérieures :

• Stockage Blob Azure : définir wasb[s]:// sur abs://
• ADLS Gen2 : Passer abfs[s]:// à adls://

Pour plus d’informations, consultez Configurer PolyBase pour accéder aux données externes dans Stockage Blob Azure.

Se connecter au stockage d’objets compatible avec S3

SQL Server 2022 (16.x) et versions ultérieures prennent en charge le stockage compatible S3, tel qu’Amazon S3, MinIO et Ceph.

Pour plus d’informations, consultez Configurer PolyBase pour accéder aux données externes dans le stockage d’objets compatible S3.

Exporter des données avec CREATE EXTERNAL TABLE AS SELECT (CETAS)

CETAS exporte les résultats des requêtes vers des fichiers externes (Parquet ou CSV) dans stockage Blob Azure, ADLS Gen2 ou stockage compatible S3.

• SQL Server 2022 et versions ultérieures prennent en charge CETAS et exportent des fichiers Parquet et CSV. Le paramètre Configuration du serveur : autoriser l’exportation PolyBase est requis. L'exportation CETAS vers ADLS Gen2 n'est pas disponible dans les versions de SQL Server 2022 avant CU5.
• Azure SQL Managed Instance prend en charge CETAS et exporte des fichiers Parquet et CSV. La directive Désactivé par défaut décrit son état par défaut.
• Azure SQL Database ne prend pas en charge CETAS.
• La base de données SQL dans Fabric ne prend pas en charge CETAS.

Pour obtenir la référence Transact-SQL, consultez CREATE EXTERNAL TABLE AS SELECT (CETAS).

Exemples de démarrage rapide

Exemple 1 : Requête ad hoc sur un fichier Parquet (OPENROWSET)

Aucune table externe n’est nécessaire. Fonctionne sur SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Fabric.

SELECT TOP 10 *
FROM OPENROWSET (
    BULK 'abs://mycontainer@mystorageaccount.blob.core.windows.net/data/sales/*.parquet',
    FORMAT = 'PARQUET'
) AS [result];

Exemple 2 : Table externe de données en format CSV dans le Stockage Blob Azure

Cet exemple fonctionne sur toutes les plateformes SQL qui prennent en charge des tables externes sur des fichiers CSV.

• Étape 1 : Créer une clé principale de base de données (DMK). Cette étape est requise, car les informations d’identification stockent le secret d'un jeton SAS. Cependant, vous pouvez sauter cette étape si vous utilisez l’identité gérée ou l’authentification Microsoft Entra.

  CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';
  

• Étape 2 : Créer des informations d’identification avec un jeton SAP. Omettez le premier ?.

  CREATE DATABASE SCOPED CREDENTIAL MyStorageCred
  WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
       SECRET = '<your_SAS_token>'; -- omit the leading '?'
  

• Étape 3 : Créer une source de données externe.

  CREATE EXTERNAL DATA SOURCE MyAzureStorage
  WITH (
      LOCATION = 'abs://mycontainer@mystorageaccount.blob.core.windows.net',
      CREDENTIAL = MyStorageCred
  );
  

• Étape 4 : Créer un format de fichier pour le fichier CSV.

  CREATE EXTERNAL FILE FORMAT CsvFormat
  WITH (
      FORMAT_TYPE = DELIMITEDTEXT,
      FORMAT_OPTIONS (
          FIELD_TERMINATOR = ',',
          STRING_DELIMITER = '"',
          FIRST_ROW = 2
      )
  );
  

• Étape 5 : Créer la table externe.

  CREATE EXTERNAL TABLE dbo.SalesExternal
  (
      OrderId INT,
      OrderDate DATE,
      Amount DECIMAL (18, 2),
      Customer NVARCHAR (100)
  )
  WITH (
      DATA_SOURCE = MyAzureStorage,
      LOCATION = '/data/sales/',
      FILE_FORMAT = CsvFormat
  );
  

• Étape 6 : Interroger la table externe.

  SELECT *
  FROM dbo.SalesExternal
  WHERE OrderDate >= '2025-01-01';
  

Exemple 3 : Interroger une table dans un autre serveur SQL Server

Cet exemple fonctionne sur SQL Server 2019 (15.x) et les versions ultérieures.

• Étape 1 : Créez une clé principale de base de données (obligatoire, car les informations d’identification stockent un mot de passe).

  CREATE MASTER KEY ENCRYPTION
  BY PASSWORD = '<password>';
  

• Étape 2 : Créez des informations d’identification pour l’instance SQL Server distante.

  CREATE DATABASE SCOPED CREDENTIAL RemoteSqlCred
  WITH IDENTITY = 'remote_user',
       SECRET = '<password>';
  

• Étape 3 : Créer la source de données externe.

  CREATE EXTERNAL DATA SOURCE RemoteSqlServer
  WITH (
      LOCATION = 'sqlserver://remote-server.contoso.com',
      PUSHDOWN = ON,
      CREDENTIAL = RemoteSqlCred
  );
  

• Étape 4 : Créer la table externe (nom en trois parties dans LOCATION).

  CREATE EXTERNAL TABLE dbo.RemoteCustomers
  (
      CustomerId INT,
      CustomerName NVARCHAR (200)
          COLLATE SQL_Latin1_General_CP1_CI_AS
  )
  WITH (
      DATA_SOURCE = RemoteSqlServer,
      LOCATION = 'SalesDB.dbo.Customers'
  );
  

• Étape 5 : Interroger sur plusieurs serveurs.

  SELECT c.CustomerName,
         s.Amount
  FROM dbo.RemoteCustomers AS c
       INNER JOIN dbo.LocalSales AS s
           ON c.CustomerId = s.CustomerId;
  

Exemple 4 : Exporter des résultats vers Parquet avec CETAS

Fonctionne sur SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Managed Instance.

• Étape 1 : Activer CETAS (SQL Server uniquement).

  EXECUTE sp_configure 'allow polybase export', 1;
  RECONFIGURE;
  

• Étape 2 : Créer des informations d’identification et une source de données (réutilisation à partir d’exemples précédents).

• Étape 3 : créer un format de fichier pour l’exportation Parquet.

  CREATE EXTERNAL FILE FORMAT ParquetFormat
  WITH (
      FORMAT_TYPE = PARQUET
  );
  

• Étape 4 : Exporter les résultats de la requête.

  CREATE EXTERNAL TABLE dbo.Sales2025Export
  WITH (
      DATA_SOURCE = MyAzureStorage,
      LOCATION = '/exports/sales_2025.parquet',
      FILE_FORMAT = ParquetFormat
  ) AS
  SELECT *
  FROM Sales.Orders
  WHERE OrderDate >= '2025-01-01';
  

Blocs de construction T-SQL pour PolyBase

Avant d’implémenter un scénario, comprenez les objets T-SQL principaux que PolyBase utilise et comment ils s’intègrent :

• Pour la syntaxe des sources de données externes, voir CREATE EXTERNAL DATA SOURCE.
• Pour la syntaxe des formats de fichiers externes, voir CREATE EXTERNAL FILE FORMAT.
• Pour la syntaxe des tables externes, voir CREATE EXTERNAL TABLE.
• Pour la syntaxe d’accès ad hoc aux données, voir OPENROWSET.
• Pour la syntaxe CETAS, voir CREATE EXTERNAL TABLE AS SELECT (CETAS).

Pour obtenir une référence complète Transact-SQL pour tous les objets, consultez la référence Transact-SQL PolyBase.

Quand avez-vous besoin de CREATE MASTER KEY ?

Une clé principale de base de données (DMK) est créée à l’aide CREATE MASTER KEY de la syntaxe. Le DMK chiffre les secrets stockés dans les identifiants de portée de base de données. Elle n’est requise que lorsque les informations d’identification contiennent une valeur secrète, c’est-à-dire lorsqu’elle stocke un mot de passe, un jeton ou une clé d’accès.

• Le DMK est requis (les identifiants contiennent un secret) :

  Type d’authentification	Valeur IDENTITY	Possède un secret	DMK
  Jeton SAS	'SHARED ACCESS SIGNATURE'	Oui	Obligatoire
  Clé d'accès S3	'S3 ACCESS KEY'	Oui	Obligatoire
  Connexion SQL / authentification de base	'<username>'	Oui	Obligatoire
  Clé d’accès au compte de stockage	'<storage_account_name>'	Oui	Obligatoire

  • Un identifiant de jeton SAS utilise IDENTITY = 'SHARED ACCESS SIGNATURE' et stocke une valeur secrète, il nécessite donc une clé maîtresse de base de données.
  • Un identifiant de clé d’accès S3 utilise IDENTITY = 'S3 ACCESS KEY' et stocke une valeur secrète, il nécessite donc une clé maîtresse de base de données.
    • Un identifiant de connexion SQL ou d’authentification de base utilise IDENTITY = '<username>' et stocke une valeur secrète, il nécessite donc une clé maîtresse de base de données.
  • Un identifiant de clé d’accès à un compte de stockage utilise IDENTITY = '<storage_account_name>' et stocke une valeur secrète, il nécessite donc une clé maîtresse de base de données.

• Le DMK n’est pas obligatoire (aucun secret stocké) :

  Type d’authentification	Valeur IDENTITY	Possède un secret	DMK
  Identité gérée	'Managed Identity'	Non	Non requis
  Microsoft Entra ID (système d'identification de Microsoft)	'User Identity' ou 'Managed Identity'	Non	Non requis

  • Un identifiant géré n’utilise IDENTITY = 'Managed Identity' ni ne stocke aucun secret, il ne nécessite donc pas de clé maîtresse de base de données.
  • Un identifiant Microsoft Entra ID n'utilise IDENTITY = 'User Identity' ni IDENTITY = 'Managed Identity' ne stocke aucun secret, donc il ne nécessite pas de clé maîtresse de base de données.

Exemples :

Dans cet exemple de requête, le DMK est requis (Les informations d’identification stockent un jeton SAP).

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';

CREATE DATABASE SCOPED CREDENTIAL SasCred
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
     SECRET = '<your_SAS_token>';

Dans cet exemple de requête, le DMK n’est pas obligatoire (Identité managée, aucun secret).

CREATE DATABASE SCOPED CREDENTIAL ManagedIdentityCred
WITH IDENTITY = 'Managed Identity';

Dans cet exemple de requête, le DMK n’est pas obligatoire (pass-through Microsoft Entra, aucun secret).

CREATE DATABASE SCOPED CREDENTIAL EntraIdCred
WITH IDENTITY = 'User Identity';

Accès aux données à distance avec OPENROWSET et tables externes

SQL Server offre trois approches distinctes pour interroger des données distantes. Vous pouvez choisir la bonne approche lorsque vous comprenez les différences de syntaxe, d’authentification et d’architecture.

¹ Pour l’accès aux fichiers cloud dans SQL Server 2022 (16.x), la fonctionnalité PolyBase doit être installée.

• Les requêtes OLE DB utilisent OPENROWSET(provider, connection, query) pour se connecter à n’importe quelle source OLE DB via MSOLEDBSQL, SQLOLEDB ou un autre fournisseur sur toutes les versions prises en charge de SQL Server. Ils supportent l'authentification SQL, l'authentification Windows Authentication et Microsoft Entra ID avec MSOLEDBSQL, et ils ne nécessitent pas l'installation de services PolyBase.
• Les requêtes de fichiers servent OPENROWSET(BULK ...) à lire des fichiers sur disque local, partages réseau ou stockage cloud tels que Stockage Blob Azure, ADLS, S3 ou OneLake en utilisant un jeton SAS, une clé d’accès, une identité managée ou un Microsoft Entra ID. Ils sont pris en charge pour les fichiers locaux et réseau dans SQL Server 2005 et versions ultérieures, pour les fichiers cloud dans SQL Server 2022 (16.x) et versions ultérieures, ainsi que dans Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Fabric. Les requêtes de fichiers ne nécessitent pas de services PolyBase pour les fichiers locaux ou pour les fichiers cloud dans SQL Server 2022 (16.x) et versions ultérieures.
• Les connecteurs PolyBase utilisent CREATE EXTERNAL TABLE avec CREATE EXTERNAL DATA SOURCE et l’emplacement sqlserver://, oracle://, teradata://, mongodb:// ou odbc:// pour se connecter à des sources de données distantes SQL Server, Oracle, Teradata, MongoDB ou ODBC. Ils nécessitent l’authentification SQL et les services PolyBase dans SQL Server 2019 (15.x) et versions ultérieures sur Windows et SQL Server 2025 (17.x) et versions ultérieures sous Linux. Pour plus d’informations, consultez CREATE EXTERNAL DATA SOURCE (Transact-SQL).

Quand utiliser chaque approche

Utilisez OLE DB OPENROWSET pour :

• Utilisez OLE DB OPENROWSET pour des requêtes rapides et ponctuelles sans créer d’objets persistants.
• Utilisez OLE DB OPENROWSET pour l’authentification Microsoft Entra ID ou Managed Identity via MSOLEDBSQL.
• Utilisez OLE DB OPENROWSET pour éviter les dépendances de services PolyBase.
• Utilisez OLE DB OPENROWSET pour vous connecter à toute source de données qui possède un fournisseur OLE DB.

Utilisez le fichier OPENROWSET(BULK) pour :

• Utilisez le fichier OPENROWSET(BULK ...) pour l’exploration de fichiers ad hoc et la découverte de schéma.
• Utilisez fichier OPENROWSET(BULK ...) pour des transformations rapides et des aperçus avant de vous engager dans une définition de tableau.
• Utilisez le fichier OPENROWSET(BULK ...) pour des transformations flexibles de colonnes en ligne telles que le casting, le filtrage et les colonnes calculées.
• Utilisez un fichier OPENROWSET(BULK ...) pour des données qui ne changent pas fréquemment et qui n’ont pas besoin de métadonnées persistantes.

Utilisez les connecteurs PolyBase avec CREATE EXTERNAL TABLE pour :

• Utilisez des connecteurs PolyBase avec CREATE EXTERNAL TABLE pour des définitions de tables persistantes et réutilisables auxquelles plusieurs utilisateurs ou applications peuvent accéder.
• Utilisez les connecteurs PolyBase avec CREATE EXTERNAL TABLE pour les charges de travail de production qui nécessitent des statistiques et l’optimisation des plans de requête.
• Utilisez des connecteurs PolyBase avec CREATE EXTERNAL TABLE pour le calcul délégué sur des sources distantes telles qu’Oracle et SQL Server.
• Utilisez des connecteurs PolyBase avec CREATE EXTERNAL TABLE pour une gouvernance et une sécurité partagées ; une fois la table créée, les utilisateurs n’ont besoin que de l’autorisation SELECT.
• Utilisez les connecteurs PolyBase avec CREATE EXTERNAL TABLE lorsqu’une authentification SQL est possible sur la source distante.

OPENROWSET (OLE DB) - requêtes distantes ad hoc (aucun service PolyBase n’est requis)

La forme OLE DB de OPENROWSET se connecte à une source de données distante via un fournisseur OLE DB, exécute une requête directe et retourne les résultats sous forme d’ensemble de lignes. Il s’agit d’une alternative ponctuelle et ad hoc à un serveur lié. Aucune métadonnées persistantes ne sont créées. Cette syntaxe ne nécessite pas de services PolyBase et ne prend pas en charge les fichiers cloud ou les sources de données externes.

Cet exemple de requête se connecte à un serveur SQL Server distant via OLE DB (et non PolyBase).

SELECT *
FROM OPENROWSET (
    'MSOLEDBSQL',
    'Server=remote-server;Database=AdventureWorks;Trusted_Connection=yes;',
    'SELECT TOP 10 * FROM AdventureWorks.Sales.SalesOrderHeader'
);

OPENROWSET(BULK) - Requêtes basées sur des fichiers (PolyBase)

La forme BULK de OPENROWSET lit les données directement depuis les fichiers. Sur SQL Server 2019 (15.x) et les versions antérieures, il lit à partir des chemins de fichier local ou UNC et nécessite un fichier de format. Dans SQL Server 2022 (16.x) et versions ultérieures, vous pouvez lire à partir du stockage cloud en utilisant les paramètres DATA_SOURCE et FORMAT. Cette approche est la version intégrée à PolyBase utilisée pour la virtualisation des données.

Dans le contexte de PolyBase et de la virtualisation des données, lorsque ce guide fait référence à OPENROWSET, cela désigne la syntaxe OPENROWSET(BULK ...) avec une clause FORMAT pour interroger des fichiers externes.

Exemples :

Cet exemple de requête lit un fichier Parquet à partir d'Stockage Blob Azure (SQL Server 2022 et versions ultérieures).

SELECT TOP 10 *
FROM OPENROWSET (
    BULK 'data/sales/*.parquet',
    DATA_SOURCE = 'MyAzureStorage',
    FORMAT = 'PARQUET'
) AS [result];

Cet exemple de requête lit un fichier Parquet avec un chemin d’accès en ligne (Azure SQL Database, Azure SQL Managed Instance).

SELECT TOP 10 *
FROM OPENROWSET (
    BULK 'abs://mycontainer@mystorageaccount.blob.core.windows.net/data/sales/*.parquet',
    FORMAT = 'PARQUET'
) AS [result];

Quand utiliser OPENROWSET et les tables externes

Les deux, OPENROWSET(BULK ...) et les tables externes, vous permettent d’interroger des données externes avec T-SQL, mais ils sont conçus pour différents cas d’usage. Le tableau suivant récapitule les principales différences pour vous aider à décider quelle approche correspond à votre scénario.

• OPENROWSET(BULK ...) est idéal pour l’exploration ad hoc et les requêtes ponctuelles, tandis qu’une table externe est meilleure pour des définitions de tables persistantes et réutilisables.
• OPENROWSET(BULK ...) ne stocke pas les métadonnées dans la base de données après l’exécution de la requête, tandis qu’une table externe stocke la définition de la table, la source de données et le format de fichier sous forme d’objets de base de données.
• OPENROWSET(BULK ...) déduit automatiquement le schéma à partir d’un fichier Parquet ou définit le schéma en ligne avec une WITH clause, tandis qu’une table externe définit explicitement le schéma dans l’énoncé CREATE EXTERNAL TABLE .
• OPENROWSET(BULK ...) nécessite ADMINISTER BULK OPERATIONS ou ADMINISTER DATABASE BULK OPERATIONS, tandis qu’une table externe peut être interrogée par des utilisateurs qui n’ont besoin que d’une autorisation standard SELECT une fois la table existante.
• OPENROWSET(BULK ...) prend en compte les colonnes calculées dans les fonctions de requête et de métadonnées comme filename() et filepath(), tandis qu’une table externe possède une liste de colonnes fixe et nécessite des transformations dans une vue ou dans la requête qui lit la table externe.
• OPENROWSET(BULK ...)dispose d’un support limité des statistiques : Azure SQL Managed Instance peut être utilisé sys.sp_create_openrowset_statistics pour des statistiques à colonne unique, mais SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database et SQL Database dans Fabric créent automatiquement des statistiques sur les prédicats. Les statistiques manuelles OPENROWSET ne sont pas prises en charge sur SQL Server, Azure SQL Database et SQL Database dans Fabric. Une table externe offre une prise en charge complète de CREATE STATISTICS sur toutes les plateformes, ainsi que des statistiques automatiques dans SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database et la base de données SQL dans Fabric. Voir les statistiques créées manuellement pour OPENROWSET et Créer des statistiques créées manuellement pour une table externe.
• OPENROWSET(BULK ...) offre des capacités limitées de pushdown et n’autorise aucun pushdown vers des sources RDBMS distantes, tandis qu’une table externe prend en charge l’exécution des calculs par pushdown pour les connecteurs RDBMS.
• OPENROWSET(BULK ...) est idéal pour l’exploration de données, la découverte de schémas, le prototypage, les charges uniques et les transformations flexibles, tandis qu’une table externe est idéale pour les charges de travail, les requêtes répétées, l’accès partagé, les tableaux de bord et les rapports.

Utiliser OPENROWSET quand vous avez besoin de flexibilité

Permet OPENROWSET d’explorer un fichier, de tester différents schémas ou d’ajouter des colonnes et des transformations calculées sans créer d’objets persistants. Par exemple, vous pouvez extraire le chemin d’accès du fichier en tant que colonne, convertir des types de données en ligne ou filtrer sur des expressions calculées dans une seule requête.

Cet exemple de requête inclut des colonnes calculées et des transformations :

SELECT result.filename() AS [FileName],
       result.filepath(1) AS [Year],
       result.filepath(2) AS [Month],
       CAST (OrderDate AS DATE) AS OrderDate,
       Amount,
       OrderDate
FROM OPENROWSET (
    BULK 'abs://mycontainer@mystorageaccount.blob.core.windows.net/data/sales/*/*/*/*.parquet',
    FORMAT = 'PARQUET'
) AS result
WHERE result.filepath(1) = '2025';

Utiliser des tables externes lorsque vous avez besoin de persistance et de gouvernance

Utilisez des tables externes lorsque plusieurs utilisateurs ou applications doivent interroger les mêmes données externes à plusieurs reprises. Vous définissez le schéma, la source de données et les informations d’identification une fois et les stockez dans la base de données. Les consommateurs ont seulement besoin d’une autorisation SELECT sur la table.

Les tables externes prennent également en charge les statistiques que l’optimiseur de requête utilise pour générer de meilleurs plans d’exécution. Vous pouvez créer manuellement des statistiques ou laisser le moteur les créer automatiquement (SQL Server 2022 (16.x) et versions ultérieures).

Cet exemple de requête crée des statistiques sur une table externe pour de meilleurs plans de requête.

CREATE STATISTICS Stats_OrderDate
ON dbo.SalesExternal(OrderDate)
WITH FULLSCAN;

Pour plus d’informations sur les statistiques des deux approches, consultez les considérations relatives aux performances de PolyBase - Statistiques.

BULK INSERT vs. OPENROWSET(BULK) : Qu’est-ce que je dois utiliser ?

À la fois BULK INSERT et OPENROWSET(BULK ...) importez des données à partir de fichiers dans SQL Server à l’aide du même moteur de chargement en bloc sous-jacent. Toutefois, ils diffèrent de la syntaxe, de la flexibilité et de ce que vous pouvez faire avec les résultats. Le tableau suivant résume les principales différences :

• BULK INSERT charge les données d’un fichier directement dans une table de destination, tandis que OPENROWSET(BULK ...) renvoie un jeu de résultats que vous pouvez utiliser dans une instruction SELECT ou INSERT ... SELECT.
• BULK INSERT est une instruction autonome, tandis OPENROWSET(BULK ...) que doit être utilisée à l’intérieur d’une requête telle que SELECT * FROM OPENROWSET(BULK ...) ou INSERT INTO <table> SELECT * FROM OPENROWSET(BULK ...).
• BULK INSERT écrit toujours directement sur une table cible, tandis que OPENROWSET(BULK ...) peut SELECT depuis un fichier sans insérer nulle part ni insérer dans une table ou une table temporaire.
• BULK INSERT a un support limité pour les transformations de colonnes car les données circulent du fichier vers la table as-is, avec un mappage contrôlé par un ordre de fichier ou de colonne. OPENROWSET(BULK ...) prend en charge les expressions, CAST, les filtres WHERE, JOIN et les colonnes calculées dans l’environnement SELECT.
• BULK INSERT utilise une WITH clause pour BATCHSIZE, CHECK_CONSTRAINTS, FIRE_TRIGGERS, KEEPIDENTITY, KEEPNULLS, TABLOCK, , et d’autres indices. OPENROWSET(BULK ...) supporte les indices de table via INSERT ... SELECT * FROM OPENROWSET(BULK ...) WITH (TABLOCK, IGNORE_CONSTRAINTS, ...).
• BULK INSERT ne prend pas en charge l’importation de valeur unique d’objets volumineux. OPENROWSET(BULK ...) prend en charge SINGLE_BLOB, SINGLE_CLOB et SINGLE_NCLOB pour importer un fichier dans son intégralité sous la forme d’une valeur varbinary(max), varchar(max) ou nvarchar(max), respectivement.
• OPENROWSET(BULK ...) et BULK INSERT prennent tous deux en charge les fichiers aux formats XML et non XML.
• Pour l’accès aux fichiers cloud avec BULK INSERT, le DATA_SOURCE paramètre prend en charge Stockage Blob Azure dans SQL Server 2017 (14.x) et versions ultérieures, Azure SQL Database, et Azure SQL Managed Instance. SQL Server 2019 CU11 et les mises à jour ultérieures prennent également en charge ADLS Gen2, mais BULK INSERT ne supportent pas le stockage compatible S3. Pour OPENROWSET(BULK ...), DATA_SOURCE prend en charge Stockage Blob Azure dans SQL Server 2017 (14.x) et versions ultérieures, ADLS Gen2 dans SQL Server 2019 CU11 et versions ultérieures, ainsi que le stockage compatible S3 dans SQL Server 2022 (16.x) et versions ultérieures. Azure SQL Database et Azure SQL Managed Instance prennent en charge Stockage Blob Azure et ADLS Gen2. La base de données SQL dans Fabric prend en charge OneLake et le stockage externe via des raccourcis OneLake.
• BULK INSERT ne prend pas en compte les fichiers Parquet ou Delta et ne prend en charge que le CSV ou le texte délimité. OPENROWSET(BULK ...)prend en charge FORMAT = 'PARQUET' et FORMAT = 'DELTA' dans SQL Server 2022 (16.x) et versions ultérieures, Azure SQL Database et Azure SQL Managed Instance. La base de données SQL dans Fabric prend en charge FORMAT = 'PARQUET' mais pas FORMAT = 'DELTA'. Pour plus d’informations, consultez OPENROWSET BULK (Transact-SQL).
• BULK INSERT nécessite ADMINISTER BULK OPERATIONS ou ADMINISTER DATABASE BULK OPERATIONS plus INSERT permission sur la table cible, tandis que OPENROWSET(BULK ...) nécessite ADMINISTER BULK OPERATIONS ou ADMINISTER DATABASE BULK OPERATIONS.
• BULK INSERT Prend en charge la journalisation minimale sous le modèle de récupération simple ou en bloc avec TABLOCK. OPENROWSET(BULK ...) Prend en charge un minimum de journalisation lorsqu’il est utilisé avec INSERT ... SELECT et TABLOCK.

Quand choisir BULK INSERT

Utilisez cette option BULK INSERT lorsque vous disposez d’une charge de fichier à table simple et que vous n’avez pas besoin de transformer, de filtrer ou de joindre des données pendant l’importation. Il utilise une syntaxe plus simple pour csv ou d’autres fichiers délimités :

Cet exemple de requête charge un fichier CSV à partir du Stockage Blob Azure directement dans une table.

BULK INSERT Sales.Invoices
FROM 'invoices/inv-2025-01.csv'
WITH (
    DATA_SOURCE = 'MyAzureBlobStorage',
    FORMAT = 'CSV',
    FIRSTROW = 2,
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '\n'
);

Cet exemple de requête charge un fichier local avec un fichier de format pour le mappage de colonnes.

BULK INSERT dbo.Products
FROM 'C:\Data\products.csv'
WITH (
    FORMATFILE = 'C:\Data\products.fmt',
    FIRSTROW = 2,
    TABLOCK
);

Quand choisir OPENROWSET(BULK)

Utilisez OPENROWSET(BULK ...) quand vous avez besoin d’une ou plusieurs des conditions suivantes :

• Utilisez OPENROWSET(BULK ...) pour interroger ou prévisualiser des données de fichiers sans créer d’abord de tableau.
• À utiliser OPENROWSET(BULK ...) pour transformer, filtrer ou relier des données lors de l’importation.
• Utilisez OPENROWSET(BULK ...) pour charger des fichiers Parquet ou Delta, car BULK INSERT ne prend pas en charge ces formats.
• Utiliser OPENROWSET(BULK ...) pour importer un fichier entier en tant que valeur LOB unique avec SINGLE_BLOB, SINGLE_CLOB, ou SINGLE_NCLOB.

Cet exemple de requête affiche un aperçu d’un fichier CSV à partir du Stockage Blob Azure sans insérer les données n’importe où.

SELECT TOP 10 *
FROM OPENROWSET (
    BULK 'invoices/inv-2025-01.csv',
    DATA_SOURCE = 'MyAzureBlobStorage',
    FORMAT = 'CSV',
    FIRSTROW = 2,
    FIELDTERMINATOR = ','
) AS src;

Cet exemple de requête insère des données avec transformation et filtrage.

INSERT INTO Sales.Invoices (InvoiceDate, Amount, Customer)
SELECT CAST (InvoiceDate AS DATE),
       Amount * 1.1, -- Apply a 10% markup
       UPPER(Customer)
FROM OPENROWSET (
    BULK 'invoices/inv-2025-01.csv',
    DATA_SOURCE = 'MyAzureBlobStorage',
    FORMAT = 'CSV',
    FIRSTROW = 2
) WITH (
    InvoiceDate VARCHAR (10),
    Amount DECIMAL (18, 2),
    Customer VARCHAR (100)
) AS src
WHERE Amount IS NOT NULL;

Cet exemple de requête charge un fichier Parquet (pas possible avec BULK INSERT).

INSERT INTO Sales.Invoices
SELECT *
FROM OPENROWSET (
    BULK 'data/invoices/*.parquet',
    DATA_SOURCE = 'MyAzureStorage',
    FORMAT = 'PARQUET') AS src;

Cet exemple de requête importe un fichier XML entier sous forme de valeur varbinary(max).

INSERT INTO dbo.XmlDocuments (DocContent)
SELECT BulkColumn
FROM OPENROWSET (
    BULK 'C:\Data\catalog.xml',
    SINGLE_BLOB
) AS x;

Pour plus d’informations, consultez les guides connexes suivants :

• L’article Utiliser BULK INSERT ou OPENROWSET(BULK...) pour importer des données dans SQL Server fournit un guide comparatif détaillé, avec des considérations relatives à la sécurité.
• L’article Bulk Import and Export of Data (SQL Server) offre un aperçu de toutes les méthodes de transfert massif de données, y compris bcp, BULK INSERT, et OPENROWSET.
• L’articleBULK INSERT (Transact-SQL) fournit la référence complète T-SQL pour BULK INSERT.
• L’article OPENROWSET BULK (Transact-SQL) fournit la référence T-SQL complète pour OPENROWSET(BULK ...).
• L’article Exemples d’accès en masse aux données dans Stockage Blob Azure fournit des exemples côte à côte utilisant les deux méthodes avec stockage Azure.
• L’article Importation en bloc de données d’objets volumineux avec le fournisseur de jeux de lignes en bloc OPENROWSET (SQL Server) fournit SINGLE_BLOB, SINGLE_CLOB et SINGLE_NCLOB exemples.
• L’article « Utiliser un fichier de formatage pour importer des données en masse » (SQL Server) explique l’utilisation des fichiers formatés avec les deux méthodes.
  • Pour des conseils sur la conservation des valeurs nulles ou l’application des valeurs par défaut lors de l’importation en masse, voir Conserver les valeurs nulles ou valeurs par défaut lors de l’importation en masse (SQL Server).
  • Pour des conseils sur la préservation des valeurs d’identité lors de l’importation en masse, voir Conserver les valeurs d’identité lors de l’importation massive de données (SQL Server).

Fonctions de métadonnées utiles

Lorsque vous interrogez des fichiers externes à l’aide de OPENROWSET ou de tables externes, utilisez les fonctions et procédures intégrées pour inspecter les métadonnées des fichiers, détecter les schémas et mettre en œuvre des requêtes tenant compte du partitionnement.

filepath() et filename()

Les fonctions filepath() et les fonctions filename() retournent des parties du chemin d'accès du fichier ou du nom de fichier pour chaque ligne du jeu de résultats. Ils sont particulièrement utiles pour :

• Élimination de partition : filtrez les segments de dossiers (par exemple, les partitions année/mois/jour) afin que le moteur lit uniquement les fichiers correspondants au lieu d’analyser tout.

• Exposition des métadonnées sources : incluez le nom ou le chemin d’accès du fichier d’origine en tant que colonne dans les résultats de la requête, ce qui est utile pour l’audit ou le débogage.

S’applique à : Azure SQL Database, Azure SQL Managed Instance, SQL Server 2022 (16.x) et versions ultérieures, base de données SQL dans Fabric.

Cet exemple de requête utilise filepath() pour l’élimination de partition et filename() pour identifier les fichiers sources. Il lit uniquement les fichiers sous le /2025/ dossier et lit uniquement les fichiers sous le /06/ sous-dossier.

SELECT result.filename() AS SourceFile,
       result.filepath(1) AS [Year],
       result.filepath(2) AS [Month],
       *
FROM OPENROWSET (
    BULK 'abs://mycontainer@mystorageaccount.blob.core.windows.net/data/sales/*/*/*.parquet',
    FORMAT = 'PARQUET'
) AS result
WHERE result.filepath(1) = '2025' 
      AND result.filepath(2) = '06';

sp_describe_first_result_set - découvrir les types de colonnes OPENROWSET

Lorsque vous utilisez des fichiers Parquet avec OPENROWSET, le moteur infère automatiquement les types de données de colonne (inférence de schéma). Les types déduits peuvent être plus grands que nécessaire. Par exemple, les colonnes de caractères sont souvent déduites en tant que varchar(8000), car les métadonnées Parquet n’incluent pas de longueur maximale. Ce choix peut dégrader les performances et consommer plus de mémoire.

Permet sp_describe_first_result_set d’inspecter le schéma déduit avant de finaliser votre requête. Après avoir vu les types déduits, spécifiez des types plus étroits dans une WITH clause pour améliorer les performances.

• Étape 1 : Inspecter le schéma déduit.

  EXECUTE sp_describe_first_result_set N'
  SELECT *
  FROM OPENROWSET(
      BULK ''abs://mycontainer@mystorageaccount.blob.core.windows.net/data/sales/*.parquet'',
      FORMAT = ''PARQUET''
  ) AS result';
  

  La sortie affiche le nom de chaque colonne, le type de données déduit, la longueur maximale, la précision et l’échelle de chaque colonne. Si vous voyez varchar(8000) où un varchar(100) suffirait, supplantez-le.

• Étape 2 : Utiliser des types explicites pour améliorer les performances.

  SELECT TOP 100 *
  FROM OPENROWSET (
      BULK 'abs://mycontainer@mystorageaccount.blob.core.windows.net/data/sales/*.parquet',
      FORMAT = 'PARQUET'
  ) WITH (
      OrderId INT,
      OrderDate DATE,
      Amount DECIMAL (18, 2),
      Customer VARCHAR (100) -- much narrower than the inferred varchar(8000)
  ) AS result;
  

L’inférence de schéma fonctionne uniquement avec les fichiers Parquet. Pour les fichiers CSV, spécifiez toujours des définitions de colonne dans une WITH clause (for OPENROWSET) ou dans l’instruction CREATE EXTERNAL TABLE . sp_describe_first_result_set est une procédure générale pour SQL Server, Azure SQL Database, Azure SQL Managed Instance et les bases de données SQL dans Fabric, mais elle est particulièrement utile pour les requêtes OPENROWSET. Pour plus d’informations, voir sp_describe_first_result_set.

Performances, résolution des problèmes et meilleures pratiques

Après avoir implémenté la virtualisation des données, utilisez ces guides pour optimiser les performances, diagnostiquer les problèmes et garantir la préparation de la production :

Contenu connexe

• Vue d’ensemble PolyBase
• Démarrer avec PolyBase dans SQL Server 2022
• Référence PolyBase Transact-SQL
• Mappage de types avec PolyBase
• Installer PolyBase sur Windows
• Installer PolyBase sur Linux