Impostazioni di flusso di dati SSIS ottimali da caricare nella tabella stage in Azure SQL DW

Question

Ho una tabella 350MB abbastanza ampia con due colonne varchar (2000). Tramite un flusso di dati SSIS ci vogliono 60 minuti per caricare tramite la destinazione OLEDB "carico veloce" su Azure SQL DW. Ho cambiato la destinazione su quel flusso di dati come destinazione Azure Blob (da SSIS Azure feature pack) e lo stesso flusso di dati completato in 1,5 minuti (e Polybase da quel nuovo file flat impiega circa 2 minuti).

Per un'altra fonte, ho un file flat da 1 GB esistente. Il flusso di dati SSIS in una destinazione OLEDB in SQL SQL di Azure richiede 90 minuti. Copia il file nella memoria BLOB e il caricamento di Polybase richiede 5 minuti.

SSIS è SSIS 2014 ed è in esecuzione su una macchina virtuale di Azure nella stessa area di SQL SQL di Azure. So che il carico di massa è molto più lento di Polybase poiché le canalizzazioni di carico bulk attraverso il nodo di controllo, ma Polybase è parallelizzato su tutti i nodi di calcolo. Ma quei numeri di carico in serie sono estremamente lenti.

Quali sono le impostazioni ottimali per il flusso di dati SSIS e la destinazione per caricare in una tabella stage di Azure SQL DW il più velocemente possibile tramite il caricamento di massa? In particolare mi interessa il valore ottimale per le seguenti impostazioni in aggiunta a tutte le altre impostazioni non sto prendendo in considerazione:

• tavolo Fase geometria = MUCCHIO (è il più veloce credo)
• impostazioni del flusso di dati:
  • DefaultBufferMaxRows =?
  • DefaultBufferSize =?
• impostazioni di destinazione OLE DB
  • accesso ai dati mode = tabella o vista - caricamento rapido
  • Tenere Identità = incontrollati
  • Tenere Valori nulli I valori =?
  • Blocco tabella =?
  • Verifica vincoli =?
  • Righe per lotto =?
  • Dimensione massima commit inserto =?

Answer 1

Polybase è certamente il modo più veloce per caricare a SQL DW. HEAP come hai suggerito è anche il tipo di destinazione più veloce. Dai un'occhiata a questo articolo del team di Google CAT su best practices for loading to Clustered Columnstore using SSIS. La raccomandazione del team di ingegneri è di provare a regolare DefaultBufferMaxRows (l'impostazione predefinita è 10K), DefaultBufferSize (l'impostazione predefinita è 10 MB), Righe per batch e Dimensione massima di commit degli inserti.

Molti anni fa ho eseguito test approfonditi delle prestazioni di SSIS alla nostra versione on-site di Azure SQL Data Warehouse, PDW noto anche come Parallel Data Warehouse o APS, Appliance Platform System. In quel test ho trovato spesso che la CPU locale era il collo di bottiglia, in particolare un singolo core. Questo potrebbe chiaramente essere visto usando Perfmon se si monitora l'utilizzo della CPU per core.

Ci sono un paio di cose che sono riuscito a fare per migliorare il throughput. Se la CPU è vincolata su un singolo core, l'esecuzione di più pacchetti SSIS simultanei consentirà di utilizzare più core e verrà eseguito più rapidamente. Per fare ciò è necessario che i file di origine siano suddivisi in più file e che la destinazione sia costituita da più tabelle.Se si esegue il partizionamento della tabella di destinazione e ogni carico contiene una partizione diversa, è possibile utilizzare la commutazione delle partizioni dopo aver caricato i dati per consolidarli in un'unica tabella.

Puoi anche provare a creare più flussi di dati nel tuo pacchetto, che otterranno le stesse prestazioni di più caricatori SSIS in parallelo, ma credo che avrai ancora bisogno di avere il tuo file sorgente rotto in più file così come il destinazione, più tabelle per massimizzare il throughput.

Un altro approccio che ho provato era avere caricatori paralleli all'interno di un flusso di dati. Mentre questo era più veloce di un caricatore, era più lento dei precedenti due approcci che ho menzionato sopra.

Ho anche scoperto che se avessi SSIS fare la conversione del char in binario, questo ha accelerato i carichi. Inoltre, l'utilizzo di una fonte di SQL era più rapido dell'utilizzo di un file di testo come origine.

Un'altra cosa che puoi provare è la SSIS Balanced Data Distributor. BDD è un altro modo per utilizzare più core sul sistema di origine senza dover eseguire più pacchetti SSIS simultanei.

Quando si eseguono i pacchetti SSIS, monitorare la CPU utilizzando perfmon per verificare se si sta eseguendo su un singolo core o si sviluppa su più core. Se si sta pegging un singolo core, allora è molto probabilmente il collo di bottiglia.

Inoltre, relativo alle colonne VARCHAR (2000). Se non ci si aspetta veramente che i dati in arrivo abbiano queste dimensioni, ridurre le dimensioni delle colonne VARCHAR. Mentre miglioreremo questo comportamento in futuro, al momento il nostro servizio di trasferimento dati riempirà i tuoi dati VARCHAR a una lunghezza fissa. Questo ovviamente significa che più dati vengono spostati del necessario se il valore più ampio è molto inferiore a 2000 caratteri.

Spero che questo aiuti.