Virtualizzazione dei dati con Istanza gestita di SQL di Azure

  • Articolo

Si applica a:Istanza gestita di SQL di Azure

La funzionalità di virtualizzazione dei dati di Istanza gestita di SQL di Azure consente di eseguire query Transact-SQL (T-SQL) su file che archiviano dati in formati di dati comuni in Azure Data Lake Storage Gen2 o Archiviazione BLOB di Azure e combinarli con dati relazionali archiviati in locale usando join. In questo modo è possibile accedere in modo trasparente ai dati esterni (in modalità di sola lettura) mantenendolo nel formato e nella posizione originali, noto anche come virtualizzazione dei dati.

Panoramica

La virtualizzazione dei dati offre due modi per eseguire query sui file destinati a diversi set di scenari:

  • Sintassi OPENROWSET: ottimizzata per le query di file. Usato in genere per esplorare velocemente il contenuto e la struttura di un nuovo set di file.
  • Sintassi CREATE EXTERNAL TABLE: ottimizzate per l'esecuzione ripetitiva di query sui file usando una sintassi identica a quella dei dati archiviati in locale nel database. Le tabelle esterne richiedono una preparazione maggiore rispetto alla sintassi OPENROWSET, ma consentono un maggiore controllo sull'accesso ai dati. Le tabelle esterne vengono in genere usate per i carichi di lavoro analitici e i report.

In entrambi i casi, è necessario creare un'origine dati esterna usando la sintassi T-SQL CREATE EXTERNAL DATA SOURCE, come illustrato in questo articolo.

È disponibile anche la sintassi CREATE EXTERNAL TABLE AS edizione SELECT per Istanza gestita di SQL di Azure, per esportare i risultati di un'istruzione T-SQL edizione Standard SELECT nei file Parquet o CSV in Archiviazione BLOB di Azure o Azure Data Lake Storage (ADLS) Gen 2 e creare una tabella esterna sopra tali file.

Formati di file

Sono supportati direttamente i formati di file Parquet e di testo delimitato (CSV). Il formato di file JSON è supportato indirettamente specificando il formato di file CSV quando le query restituiscono ogni documento come riga separata. È possibile analizzare ulteriormente le righe usando JSON_VALUE e OPENJSON.

Tipi di archiviazione

È possibile archiviare i file in Archiviazione BLOB di Azure, File di Azure o Azure Data Lake Storage Gen2. Per eseguire query sui file, è necessario specificare il percorso in un formato specifico e usare il prefisso del tipo di posizione corrispondente al tipo di origine esterna e endpoint/protocollo, ad esempio gli esempi seguenti:

--Blob Storage endpoint
abs://<container>@<storage_account>.blob.core.windows.net/<path>/<file_name>.parquet

--Data Lake endpoint
adls://<container>@<storage_account>.dfs.core.windows.net/<path>/<file_name>.parquet

Importante

Il prefisso del tipo di posizione specificato viene usato per scegliere il protocollo ottimale per la comunicazione e sfruttare tutte le funzionalità avanzate offerte dal tipo di archiviazione specifico. L'uso del prefisso generico https:// è disabilitato. Usare sempre prefissi specifici dell'endpoint.

Operazioni preliminari

Se non si ha familiarità con la virtualizzazione dei dati e si vuole testare rapidamente le funzionalità, iniziare eseguendo query sui set di dati pubblici disponibili in Set di dati aperti di Azure, ad esempio il set di dati Bing COVID-19 che consente l'accesso anonimo.

Usare gli endpoint seguenti per eseguire query sui set di dati Bing COVID-19:

  • Parquet: abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/bing_covid-19_data.parquet
  • CSV: abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/bing_covid-19_data.csv

Per una guida introduttiva, eseguire questa semplice query T-SQL per ottenere informazioni dettagliate sul set di dati. Questa query usa OPENROWSET per eseguire query su un file archiviato in un account di archiviazione disponibile pubblicamente:

--Quick query on a file stored in a publicly available storage account:
SELECT TOP 10 *
FROM OPENROWSET(
 BULK 'abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/bing_covid-19_data.parquet',
 FORMAT = 'parquet'
) AS filerows

È possibile continuare l'esplorazione dei set di dati aggiungendo WHERE, GROUP BY e altre clausole in base al set di risultati della prima query.

Se la prima query ha esito negativo nell'istanza gestita, tale istanza probabilmente ha accesso limitato agli account di archiviazione di Azure ed è necessario rivolgersi all'esperto di rete per abilitare l'accesso prima di poter procedere con l'esecuzione di query.

Dopo aver acquisito familiarità con l'esecuzione di query sui set di dati pubblici, è consigliabile passare a set di dati non pubblici che richiedono l'inserimento di credenziali, concedere diritti di accesso e configurare le regole del firewall. In molti scenari reali si opera principalmente con set di dati privati.

Accesso agli account di archiviazione non pubblici

Un utente connesso a un'istanza gestita deve essere autorizzato ad accedere ai file di query archiviati in un account di archiviazione non pubblico. I passaggi di autorizzazione dipendono dal modo in cui l'istanza gestita esegue l'autenticazione nell'archiviazione. Il tipo di autenticazione e gli eventuali parametri correlati non vengono forniti direttamente con ogni query. Vengono incapsulati nell'oggetto credenziale con ambito database archiviato nel database utente. Le credenziali vengono usate dal database per accedere all'account di archiviazione ogni volta che viene eseguita la query. Istanza gestita di SQL di Azure supporta i seguenti tipi di connessione:

Un'identità gestita è una funzionalità di Microsoft Entra ID (in precedenza Azure Active Directory) che fornisce servizi di Azure, ad esempio Istanza gestita di SQL di Azure, con un'identità gestita in Microsoft Entra ID. Questa identità può essere usata per autorizzare la richiesta di accesso ai dati negli account di archiviazione non pubblici. I servizi come Istanza gestita di SQL di Azure, dispongono di un'identità gestita assegnata dal sistema e possono avere anche una o più identità gestite assegnate dall'utente. È possibile usare identità gestite assegnate dal sistema o identità gestite assegnate dall'utente per la virtualizzazione dei dati con Istanza gestita di SQL di Azure.

L'amministratore di Archiviazione di Azure deve concedere le apposite autorizzazioni all'identità gestita per accedere ai dati. La concessione di autorizzazioni all'identità gestita assegnata dal sistema dell’istanza gestita viene eseguita allo stesso modo che per qualsiasi altro utente di Microsoft Entra. Ad esempio:

  1. Nella pagina Controllo di accesso (IAM) di un account di archiviazione dell portale di Azure selezionare Aggiungi assegnazione di ruolo.
  2. Scegliere il ruolo predefinito Di controllo degli accessi in base al ruolo di Ruolo di Azure per lettore di dati BLOB Archiviazione. In questo modo, viene fornito l'accesso in lettura all'identità gestita per i contenitori di Archiviazione BLOB di Azure necessari.
    • Invece di concedere all'identità gestita il lettore dati del BLOB di archiviazione del ruolo Controllo degli accessi in base al ruolo di Azure, è possibile concedere autorizzazioni più granulari su un sottoinsieme di file. Tutti gli utenti che devono accedere a Leggere singoli file alcuni dati in questo contenitore devono disporre anche dell'autorizzazione Esegui per tutte le cartelle padre fino alla radice (il contenitore). Altre informazioni su come impostare gli elenchi di controllo di accesso in Azure Data Lake Storage Gen2.
  3. Nella pagina successiva, in Assegna accesso aIdentità gestita. + Selezionare i membri e nell'elenco a discesa Identità gestita selezionare l'identità gestita desiderata. Per ulteriori informazioni, vedi Assegnare ruoli di Azure usando il portale di Azure.
  4. Quindi, la creazione delle credenziali con ambito database per l'autenticazione dell'identità gestita è semplice. Si noti nell'esempio seguente che 'Managed Identity' è una stringa hardcoded.
-- Optional: Create MASTER KEY if it doesn't exist in the database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Some Very Strong Password Here>'
GO
CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'Managed Identity'

Origine dati esterna

Un'origine dati esterna è un'astrazione che consente di fare facilmente riferimento a un percorso di file tra più query. Per eseguire query sui percorsi pubblici, è sufficiente specificare durante la creazione di un'origine dati esterna:

CREATE EXTERNAL DATA SOURCE MyExternalDataSource
WITH (
    LOCATION = 'abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest'
)

Quando si accede ad account di archiviazione non pubblici, insieme al percorso, è anche necessario fare riferimento a una credenziale con ambito database con parametri di autenticazione incapsulati. Lo script seguente crea un'origine dati esterna che punta al percorso del file e fa riferimento a una credenziale con ambito database.

--Create external data source pointing to the file path, and referencing database-scoped credential:
CREATE EXTERNAL DATA SOURCE MyPrivateExternalDataSource
WITH (
    LOCATION = 'abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest'
        CREDENTIAL = [MyCredential];
)

Eseguire query sulle origini dati con OPENROWSET

L’uso della sintassi OPENROWSET consente l'esecuzione immediata di query ad hoc, creando al tempo stesso solo il numero minimo di oggetti di database necessari.

OPENROWSET richiede solo la creazione dell'origine dati esterna (e possibilmente la credenziale) anziché l'approccio alla tabella esterna, che richiede un formato di file esterno e la tabella esterna stessa.

Il valore del parametro DATA_SOURCE viene automaticamente anteposto al parametro BULK per formare il percorso completo del file.

Quando si usa OPENROWSET specificare il formato del file, come illustrato nell’esempio seguente, che esegue una query su un singolo file:

SELECT TOP 10 *
FROM OPENROWSET(
 BULK 'bing_covid-19_data.parquet',
 DATA_SOURCE = 'MyExternalDataSource',
 FORMAT = 'parquet'
) AS filerows;

Esecuzione di query su più file o cartelle

Il comando OPENROWSET consente anche di eseguire query su più file o cartelle usando caratteri jolly nel percorso BULK.

Nell'esempio seguente viene usato il set di dati aperto per i record delle corse dei taxi di New York.

Innanzitutto creare l'origine dati esterna:

--Create the data source first:
CREATE EXTERNAL DATA SOURCE NYCTaxiExternalDataSource
WITH (LOCATION = 'abs://nyctlc@azureopendatastorage.blob.core.windows.net');

È ora possibile eseguire query su tutti i file con estensione parquet nelle cartelle. Ad esempio, in questo caso si eseguirà una query solo sui file corrispondenti a un modello di nome:

--Query all files with .parquet extension in folders matching name pattern:
SELECT TOP 10 *
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet'
) AS filerows;

Quando si eseguono query su più file o cartelle, tutti i file a cui si accede con il singolo OPENROWSET devono avere la stessa struttura, ad esempio lo stesso numero di colonne e tipi di dati. Le cartelle non possono essere attraversate in modo ricorsivo.

Inferenza dello schema

L'inferenza automatica dello schema consente di scrivere velocemente le query ed esplorare i dati quando non si conoscono gli schemi di file. L'inferenza dello schema funziona solo con i file Parquet.

Per quanto comodo, i tipi di dati dedotti potrebbero essere maggiori dei tipi di dati effettivi perché potrebbero essere presenti informazioni sufficienti nei file di origine per garantire l'uso del tipo di dati appropriato. Ciò può comportare prestazioni di query scarse. Ad esempio, i file Parquet non contengono metadati sulla lunghezza massima delle colonne di caratteri, quindi l’istanza deduce che si tratta di varchar (8000).

Usare la stored procedure sp_describe_first_results_set per controllare i tipi di dati risultanti della query, come l'esempio seguente:

EXEC sp_describe_first_result_set N'
 SELECT
 vendorID, tpepPickupDateTime, passengerCount
 FROM
 OPENROWSET(
  BULK ''yellow/*/*/*.parquet'',
  DATA_SOURCE = ''NYCTaxiExternalDataSource'',
  FORMAT=''parquet''
 ) AS nyc';

Dopo aver appreso i tipi di dati, è possibile specificarli usando la clausola WITH per migliorare le prestazioni:

SELECT TOP 100
 vendorID, tpepPickupDateTime, passengerCount
FROM
OPENROWSET(
 BULK 'yellow/*/*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT='PARQUET'
 )
WITH (
vendorID varchar(4), -- we're using length of 4 instead of the inferred 8000
tpepPickupDateTime datetime2,
passengerCount int
) AS nyc;

Poiché lo schema dei file CSV non può essere determinato automaticamente, le colonne devono essere sempre specificate usando la clausola WITH:

SELECT TOP 10 id, updated, confirmed, confirmed_change
FROM OPENROWSET(
 BULK 'bing_covid-19_data.csv',
 DATA_SOURCE = 'MyExternalDataSource',
 FORMAT = 'CSV',
 FIRSTROW = 2
)
WITH (
 id int,
 updated date,
 confirmed int,
 confirmed_change int
) AS filerows;

Funzioni per i metadati dei file

Quando si eseguono query su più file o cartelle, è possibile usare le funzioni filepath() e filename() per leggere i metadati dei file e ottenere parte del percorso o del percorso completo e del nome del file da cui ha origine la riga nel set di risultati:

--Query all files and project file path and file name information for each row:
SELECT TOP 10 filerows.filepath(1) as [Year_Folder], filerows.filepath(2) as [Month_Folder],
filerows.filename() as [File_name], filerows.filepath() as [Full_Path], *
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet') AS filerows;
--List all paths:
SELECT DISTINCT filerows.filepath(1) as [Year_Folder], filerows.filepath(2) as [Month_Folder]
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet') AS filerows;

Se viene chiamata senza un parametro, la funzione filepath() restituisce il percorso completo del file da cui ha origine la riga. Quando DATA_SOURCE viene usato in OPENROWSET, restituisce il percorso relativo all'oggetto DATA_SOURCE, in caso contrario restituisce il percorso completo del file.

Se viene chiamata con un parametro, viene restituita una parte del percorso che corrisponde al carattere jolly nella posizione specificata nel parametro. Ad esempio, il valore del parametro 1 restituisce la parte del percorso che corrisponde al primo carattere jolly.

La funzione filepath() può essere usata anche per filtrare e aggregare righe:

SELECT
 r.filepath() AS filepath
 ,r.filepath(1) AS [year]
 ,r.filepath(2) AS [month]
 ,COUNT_BIG(*) AS [rows]
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
DATA_SOURCE = 'NYCTaxiExternalDataSource',
FORMAT = 'parquet'
 ) AS r
WHERE
 r.filepath(1) IN ('2017')
 AND r.filepath(2) IN ('10', '11', '12')
GROUP BY
 r.filepath()
 ,r.filepath(1)
 ,r.filepath(2)
ORDER BY
 filepath;

Creare una visualizzazione all'inizio di OPENROWSET

È possibile creare e usare viste per eseguire il wrapping di query OPENROWSET in modo da poter riutilizzare facilmente la query sottostante:

CREATE VIEW TaxiRides AS
SELECT *
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet'
) AS filerows

È anche utile aggiungere colonne con i dati del percorso del file a una visualizzazione usando la funzione filepath() per un filtro più semplice ed efficiente. L'uso delle visualizzazioni consente di ridurre il numero di file e la quantità di dati di cui la query deve essere usata per la lettura e l'elaborazione quando viene filtrata in base a una di queste colonne:

CREATE VIEW TaxiRides AS
SELECT *
 , filerows.filepath(1) AS [year]
 , filerows.filepath(2) AS [month]
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet'
) AS filerows

Le visualizzazioni consentono anche di creare report e strumenti analitici come Power BI per usare i risultati di OPENROWSET.

Tabelle esterne

Le tabelle esterne incapsulano i file di accesso rendendo l'esperienza di query quasi identica all'esecuzione di query sui dati relazionali locali archiviati nelle tabelle utente. Per la creazione di una tabella esterna è necessario che gli oggetti di formato di file esterni e origine dati esterna esistano:

--Create external file format
CREATE EXTERNAL FILE FORMAT DemoFileFormat
WITH (
 FORMAT_TYPE=PARQUET
)
GO

--Create external table:
CREATE EXTERNAL TABLE tbl_TaxiRides(
 vendorID VARCHAR(100) COLLATE Latin1_General_BIN2,
 tpepPickupDateTime DATETIME2,
 tpepDropoffDateTime DATETIME2,
 passengerCount INT,
 tripDistance FLOAT,
 puLocationId VARCHAR(8000),
 doLocationId VARCHAR(8000),
 startLon FLOAT,
 startLat FLOAT,
 endLon FLOAT,
 endLat FLOAT,
 rateCodeId SMALLINT,
 storeAndFwdFlag VARCHAR(8000),
 paymentType VARCHAR(8000),
 fareAmount FLOAT,
 extra FLOAT,
 mtaTax FLOAT,
 improvementSurcharge VARCHAR(8000),
 tipAmount FLOAT,
 tollsAmount FLOAT,
 totalAmount FLOAT
)
WITH (
 LOCATION = 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = NYCTaxiExternalDataSource,
 FILE_FORMAT = DemoFileFormat
);
GO

Dopo aver creato la tabella esterna, è possibile eseguirvi le query come su qualsiasi altra tabella:

SELECT TOP 10 *
FROM tbl_TaxiRides;

Analogamente a OPENROWSET, le tabelle esterne consentono di eseguire query su più file e cartelle usando caratteri jolly. L'inferenza dello schema non è supportata con le tabelle esterne.

Considerazioni sulle prestazioni

Non esiste alcun limite rigido al numero di file o alla quantità di dati su cui è possibile eseguire query, ma le prestazioni delle query dipendono dalla quantità di dati, dal formato dei dati, dalla modalità di organizzazione dei dati e dalla complessità delle query e dei join.

Eseguire query su dati partizionati

I dati sono spesso organizzati in sottocartelle denominate anche partizioni. È possibile indicare a un’istanza gestita di eseguire query su cartelle e file specifici. Questa operazione ridurrà il numero di file e la quantità di dati che la query deve leggere ed elaborare, garantendo prestazioni migliori. Questo tipo di ottimizzazione delle query è noto come eliminazione di partizioni o eliminazione di partizioni. È possibile eliminare le partizioni dall'esecuzione di query usando la funzione filepath() di metadati nella clausola WHERE della query.

L'esempio seguente legge i file di dati dei taxi di New York solo per gli ultimi tre mesi del 2017:

SELECT
    r.filepath() AS filepath
    ,r.filepath(1) AS [year]
    ,r.filepath(2) AS [month]
    ,COUNT_BIG(*) AS [rows]
FROM OPENROWSET(
        BULK 'yellow/puYear=*/puMonth=*/*.parquet',
        DATA_SOURCE = 'NYCTaxiExternalDataSource',
        FORMAT = 'parquet'
    )
WITH (
    vendorID INT
) AS [r]
WHERE
    r.filepath(1) IN ('2017')
    AND r.filepath(2) IN ('10', '11', '12')
GROUP BY
    r.filepath()
    ,r.filepath(1)
    ,r.filepath(2)
ORDER BY
    filepath;

Se i dati archiviati non sono partizionati, prendere in considerazione di partizionarli al fine di migliorare le prestazioni.

Se si usano tabelle, le funzioni filepath() e filename() sono supportate, ma non nella clausola WHERE. È comunque possibile filtrare in base filename a o filepath se vengono usate nelle colonne calcolate. Questo concetto è illustrato nell'esempio seguente:

CREATE EXTERNAL TABLE tbl_TaxiRides (
 vendorID VARCHAR(100) COLLATE Latin1_General_BIN2,
 tpepPickupDateTime DATETIME2,
 tpepDropoffDateTime DATETIME2,
 passengerCount INT,
 tripDistance FLOAT,
 puLocationId VARCHAR(8000),
 doLocationId VARCHAR(8000),
 startLon FLOAT,
 startLat FLOAT,
 endLon FLOAT,
 endLat FLOAT,
 rateCodeId SMALLINT,
 storeAndFwdFlag VARCHAR(8000),
 paymentType VARCHAR(8000),
 fareAmount FLOAT,
 extra FLOAT,
 mtaTax FLOAT,
 improvementSurcharge VARCHAR(8000),
 tipAmount FLOAT,
 tollsAmount FLOAT,
 totalAmount FLOAT,
 [Year]  AS CAST(filepath(1) AS INT), --use filepath() for partitioning
 [Month]  AS CAST(filepath(2) AS INT) --use filepath() for partitioning
)
WITH (
 LOCATION = 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = NYCTaxiExternalDataSource,
 FILE_FORMAT = DemoFileFormat
);
GO

SELECT *
      FROM tbl_TaxiRides
WHERE
      [year]=2017            
      AND [month] in (10,11,12);

Se i dati archiviati non sono partizionati, prendere in considerazione di partizionarli al fine di migliorare le prestazioni.

Statistiche

Raccogliere le statistiche sui dati esterni è una delle attività più importanti per ottimizzare le query. Più informazioni sui dati sono a disposizione dell’istanza, più rapidamente può eseguire le query. Il motore Query Optimizer di SQL è un ottimizzatore basato sui costi. Esegue un confronto fra i costi dei vari piani di query e poi sceglie quello che costa meno, Nella maggior parte dei casi, scegliere il piano eseguito più velocemente.

Creazione automatica di statistiche

Istanza gestita di SQL di Azure analizza le query utente in ingresso alla ricerca di statistiche mancanti. Se non sono presenti, Query Optimizer creerà automaticamente delle statistiche su singole colonne nel predicato della query o nella condizione di join per migliorare le stime di cardinalità del piano di query. La creazione automatica di statistiche viene generata in modo sincrono; se nelle colonne non sono presenti tutte le statistiche, quindi, è possibile che si verifichi un leggero peggioramento delle prestazioni delle query. Il tempo necessario per creare le statistiche relative a una colonna dipende dalle dimensioni dei file di destinazione.

Statistiche manuali OPENROWSET

È possibile creare statistiche a colonna singola per il percorso OPENROWSET usando la stored procedure sys.sp_create_openrowset_statistics, passando la query select con una singola colonna come parametro:

EXEC sys.sp_create_openrowset_statistics N'
SELECT pickup_datetime
FROM OPENROWSET(
 BULK ''abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/*.parquet'',
 FORMAT = ''parquet'') AS filerows
';

Per impostazione predefinita, l'istanza usa il 100% dei dati forniti nel set di dati per creare statistiche. Facoltativamente, è possibile specificare le dimensioni del campione come percentuale usando le opzioni TABLESAMPLE. Per creare statistiche a colonna singola per più colonne, eseguire sys.sp_create_openrowset_statistics per ognuna delle colonne. Non è possibile creare statistiche su più colonne per il percorso OPENROWSET.

Per aggiornare le statistiche esistenti, eliminarle prima usando la stored procedure sys.sp_drop_openrowset_statistics e quindi ricrearle usando sys.sp_create_openrowset_statistics:

EXEC sys.sp_drop_openrowset_statistics N'
SELECT pickup_datetime
FROM OPENROWSET(
 BULK ''abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/*.parquet'',
 FORMAT = ''parquet'') AS filerows
';

Statistiche manuali della tabella esterna

La sintassi per la creazione di statistiche su tabelle esterne è simile a quella usata per le normali tabelle utente. Per creare statistiche su una colonna, fornire un nome per l'oggetto statistiche e il nome della colonna:

CREATE STATISTICS sVendor
ON tbl_TaxiRides (vendorID)
WITH FULLSCAN, NORECOMPUTE;

Le opzioni WITH sono obbligatorie e, per le dimensioni del campione, le opzioni consentite sono FULLSCAN e SAMPLE n percento.

  • Per creare statistiche a colonna singola per più colonne, eseguire CREATE STATISTICS per ognuna delle colonne.
  • Le statistiche su più colonne non sono supportate.

Risoluzione dei problemi

I problemi relativi all'esecuzione di query in genere si verificano quando un'istanza gestita non è in grado di accedere a un percorso di file. I messaggi di errore correlati potrebbero indicare diritti di accesso insufficienti, percorso o percorso di file inesistente, file usato da un altro processo o che la directory non può essere elencata. Nella maggior parte dei casi indica che l'accesso ai file è bloccato dai criteri di controllo del traffico di rete o che non sono presenti diritti di accesso. Ecco cosa deve essere controllato:

  • Percorso errato o non corretto.
  • Validità della chiave di firma di accesso condiviso: potrebbe essere scaduta, contenente un errore di digitazione, a partire da un punto interrogativo.
  • Autorizzazioni della chiave SAS consentite: Lettura come minimo, ed Elenco se vengono usati caratteri jolly.
  • Traffico in ingresso bloccato nell'account di archiviazione. Per altri dettagli, vedere Gestione delle regole di rete virtuale per Archiviazione di Azure e assicurarsi che l'accesso dalla rete virtuale dell'istanza gestita sia consentito.
  • Il traffico in uscita viene bloccato nell'istanza gestita usando i criteri dell'endpoint di archiviazione. Consentire il traffico in uscita verso l'account di archiviazione.
  • Diritti di accesso all'identità gestita: assicurarsi che all'identità gestita dell'istanza vengano concessi diritti di accesso all'account di archiviazione.
  • Il livello di compatibilità del database deve essere 130 o superiore per il funzionamento delle query di virtualizzazione dei dati.

CREATE EXTERNAL TABLE AS SELECT (CETAS)

CREATE EXTERNAL TABLE AS SELECT (CETAS) consente di esportare dati dall'istanza gestita di SQL in un account di archiviazione esterno. È possibile usare CETAS per creare una tabella esterna sopra i file Parquet o CSV di Archiviazione BLOB di Azure o Azure Data Lake Storage (ADLS) Gen2. CETAS è inoltre in grado di esportare in parallelo i risultati di un'istruzione T-SQL SELECT nella tabella esterna che è stata creata. Esiste un potenziale rischio di esfiltrazione dei dati con queste funzionalità, quindi CETAS è disabilitato per impostazione predefinita per Istanza gestita di SQL di Azure. Per abilitarlo, vedere CREATE EXTERNAL TABLE AS SELECT (CETAS).

Limiti

Problemi noti

  • Quando la parametrizzazione per Always Encrypted è abilitata in SQL Server Management Studio (SSMS), le query di virtualizzazione dei dati hanno esito negativo con messaggio di errore Incorrect syntax near 'PUSHDOWN'.

Contenuto correlato