Runtime di integrazione in Azure Data Factory

Applicabile a: Azure Data Factory Azure Synapse Analytics

Suggerimento

Data Factory in Microsoft Fabric è la nuova generazione di Azure Data Factory, con un'architettura più semplice, un'intelligenza artificiale predefinita e nuove funzionalità. Se non si ha familiarità con l'integrazione dei dati, iniziare con Fabric Data Factory. I carichi di lavoro di Azure Data Factory esistenti possono eseguire l'aggiornamento a Fabric per accedere a nuove funzionalità tra data science, analisi in tempo reale e creazione di report.

L'runtime di integrazione (IR) è l'infrastruttura di calcolo utilizzata dalle pipeline di Azure Data Factory e Azure Synapse per fornire le seguenti capacità di integrazione dati attraverso diversi ambienti di rete:

  • Flusso di dati: eseguire un Flusso di dati in un ambiente di calcolo di Azure gestito.
  • Trasferimento dati: copiare dati tra archivi di dati in una rete pubblica o privata (sia per le reti locali che per le reti private virtuali). Il servizio fornisce il supporto per i connettori predefiniti, la conversione del formato, il mapping delle colonne e il trasferimento di dati scalabile ed efficiente.
  • Invio attività: inviare e monitorare le attività di trasformazione in esecuzione in vari servizi di calcolo, ad esempio Azure Databricks, Azure HDInsight, ML Studio (versione classica), database SQL di Azure, SQL Server e altro ancora.
  • Esecuzione di pacchetti SSIS: eseguire in modo nativo i pacchetti SQL Server Integration Services (SSIS) in un ambiente di calcolo Azure gestito.

Nelle pipeline di Data Factory e Synapse un'attività definisce l'azione da eseguire. Un servizio collegato definisce un archivio dati o un servizio di calcolo di destinazione. Un runtime di integrazione fornisce il bridge tra le attività e i servizi collegati. Il servizio collegato o l'attività fa riferimento e forniscono l'ambiente di calcolo dove l'attività viene eseguita direttamente oppure inviata. Questa associazione consente di eseguire l'attività nell'area più vicina possibile all'archivio dati o al servizio di calcolo di destinazione per ottimizzare le prestazioni, consentendo al tempo stesso la flessibilità di soddisfare i requisiti di sicurezza e conformità.

I runtime di integrazione possono essere creati nell'interfaccia utente di Azure Data Factory e Azure Synapse tramite l'hub di gestione direttamente e da qualsiasi attività, set di dati o flussi di dati che vi fanno riferimento.

Tipi di runtime di integrazione

Data Factory offre tre tipi di runtime di integrazione (IR), e dovresti scegliere quello che meglio soddisfa le tue capacità di integrazione dati e i requisiti dell'ambiente di rete. I tre tipi di IR sono:

  • Azure
  • Autogestito
  • Azure-SSIS

Nota

La pipeline di Synapse attualmente supporta solo i runtime di integrazione di Azure o self-hosted.

Nella tabella seguente vengono descritte le funzionalità e il supporto di rete per ogni tipo di runtime di integrazione:

Tipo IR Supporto della rete pubblica Supporto per il collegamento privato
Azure Flusso di dati
Spostamento dei dati
Distribuzione di attività		 Flusso di dati
Spostamento dei dati
Distribuzione di attività
Autogestito Spostamento dei dati
Distribuzione di attività		 Spostamento dei dati
Distribuzione di attività
Azure-SSIS Esecuzione pacchetti SSIS Esecuzione pacchetti SSIS

Nota

I controlli in uscita variano in base al servizio per il runtime di integrazione di Azure. In Synapse, gli spazi di lavoro hanno opzioni per limitare il traffico in uscita dalla rete virtuale gestita quando si utilizza Azure IR. In Data Factory, tutte le porte vengono aperte per le comunicazioni in uscita quando usi Azure IR. Azure-SSIS IR può essere integrato con la rete virtuale per fornire controlli di comunicazione in uscita.

Runtime di integrazione di Azure

Un runtime di integrazione di Azure può:

  • Eseguire Flussi di dati in Azure
  • Eseguire attività di copia tra archivi dati cloud
  • Inviare le attività di trasformazione seguenti in una rete pubblica:
    • Attività personalizzata .NET
    • Attività della funzione di Azure
    • Attività di Databricks Notebook/ Jar/ Python
    • Attività di recupero dei metadati
    • Attività Hive di HDInsight
    • Attività Pig di HDInsight
    • Attività MapReduce di HDInsight
    • Attività HDInsight Spark
    • Attività di streaming di HDInsight
    • Attività di Ricerca
    • Attività Batch Execution di Machine Learning Studio (versione classica)
    • Attività di aggiornamento delle risorse di Machine Learning Studio (versione classica)
    • Attività stored procedure
    • Attività di convalida
    • Attività Web

Ambiente di rete Azure IR

L'integrazione di runtime di Azure supporta la connessione a archivi dati e servizi di calcolo con endpoint accessibili pubblicamente. Quando abiliti Managed Rete virtuale, il runtime di integrazione di Azure supporta la connessione agli archivi dati utilizzando collegamento privato in un ambiente di rete privata. In Synapse, le aree di lavoro hanno opzioni per limitare il traffico in uscita dalla rete virtuale gestita del runtime di integrazione. In Data Factory tutte le porte vengono aperte per le comunicazioni in uscita. L'Azure-SSIS IR può essere integrato con la rete virtuale per fornire controlli di comunicazione in uscita.

Risorsa di calcolo e ridimensionamento del runtime di integrazione di Azure

Il runtime di integrazione di Azure fornisce un calcolo senza server completamente gestito in Azure. Non è necessario preoccuparsi del provisioning dell'infrastruttura, dell'installazione del software, dell'applicazione di patch o del ridimensionamento della capacità. Inoltre, paghi solo per ciò che usi.

Il runtime di integrazione di Azure fornisce il calcolo nativo per spostare i dati tra gli archivi dati cloud in modo sicuro, affidabile e ad alte prestazioni. Puoi impostare quante unità di integrazione dati usare sull'attività di copia, e la dimensione di calcolo di Azure IR viene scalata elasticamente di conseguenza senza dover regolare esplicitamente la dimensione del runtime di integrazione di Azure.

Il dispatch di attività è un'operazione leggera per instradare l'attività al servizio di calcolo target, quindi non è necessario ingrandire la dimensione di calcolo in questo scenario.

Per informazioni su come creare e configurare un'istanza di Azure Integration Runtime, consultare Come creare e configurare Azure Integration Runtime.

Nota

L'runtime di integrazione Azure ha proprietà relative al runtime di Flusso di dati, che definisce l'infrastruttura di calcolo sottostante utilizzata per eseguire i flussi di dati.

Runtime di integrazione self-hosted

Un runtime di integrazione self-hosted è in grado di eseguire queste operazioni:

  • Esecuzione di attività di copia tra un cloud data store e un data store in una rete privata.
  • Inviare le attività di trasformazione seguenti a risorse di calcolo in locale o in Rete virtuale di Azure:
    • Attività della funzione di Azure
    • Attività personalizzata (eseguita in Azure Batch)
    • Attività di recupero dei metadati
    • Attività Hive di HDInsight (BYOC, Bring Your Own Cluster)
    • Attività Pig di HDInsight (BYOC)
    • Attività MapReduce di HDInsight (BYOC)
    • Attività Spark di HDInsight (BYOC)
    • Attività di streaming di HDInsight (BYOC)
    • Attività di Ricerca
    • Attività Batch Execution di Machine Learning Studio (versione classica)
    • Attività di aggiornamento delle risorse di Machine Learning Studio (versione classica)
    • Attività di esecuzione della pipeline di Machine Learning
    • Attività stored procedure
    • Attività di convalida
    • Attività Web

Nota

Utilizza runtime di integrazione auto-ospitata per supportare archivi dati che richiedono un driver bring-your-thar, come SAP HANA e MySQL. Per ulteriori informazioni, consulta archivi dati supportati.

Nota

L'Ambiente di Esecuzione Java (JRE) è una dipendenza dall'IR auto-ospitato. Assicurarsi che JRE sia installato nello stesso host.

Ambiente di rete del runtime di integrazione self-hosted

Se si vuole eseguire l'integrazione dei dati in modo sicuro in un ambiente di rete privata che non dispone di una linea diretta dall'ambiente cloud pubblico, è possibile installare un runtime di integrazione self-hosted nell'ambiente locale dietro un firewall o all'interno di una rete privata virtuale. Il runtime di integrazione self-hosted stabilisce solo connessioni basate su HTTP in uscita per accedere a Internet.

Risorsa di calcolo e ridimensionamento del runtime di integrazione self-hosted

Installare un runtime di integrazione self-hosted su un computer locale o una macchina virtuale all'interno di una rete privata. Attualmente il runtime di integrazione self-hosted è supportato solo in un sistema operativo Windows. In termini di disponibilità elevata e scalabilità è possibile aumentare il numero di istanze per il runtime di integrazione self-hosted associando l'istanza logica a più computer locali in modalità attivo-attivo. Per ulteriori informazioni, vedere l'articolo su come creare e configurare un runtime di integrazione self-hosted.

Runtime di integrazione Azure-SSIS

Per eseguire in modalità lift-and-shift il carico di lavoro SSIS esistente, è possibile creare un runtime di integrazione Azure-SSIS per l'esecuzione di pacchetti SSIS in modo nativo.

Ambiente di rete del runtime di integrazione Azure-SSIS

È possibile effettuare il provisioning di Azure-SSIS IR in una rete pubblica o privata. L'accesso ai dati locali è supportato aggiungendo Azure-SSIS IR a una rete virtuale connessa alla rete locale.

Risorsa di calcolo e ridimensionamento del runtime di integrazione Azure-SSIS

Azure-SSIS IR è un cluster completamente gestito di macchine virtuali di Azure dedicate per eseguire i pacchetti SSIS. È possibile utilizzare il database SQL di Azure o Istanza gestita di SQL per il catalogo dei progetti/pacchetti SSIS (SSISDB). È possibile aumentare la potenza di calcolo specificando la dimensione del nodo e scalare orizzontalmente specificando il numero di nodi nel cluster. Puoi gestire il costo di esecuzione del runtime di integrazione Azure-SSIS fermandolo e avviandolo secondo le tue esigenze.

Per altre informazioni, vedere Come creare e configurare Azure-SSIS IR. Dopo la creazione, è possibile distribuire e gestire i pacchetti SSIS esistenti senza alcuna modifica usando strumenti familiari, ad esempio SQL Server Data Tools (SSDT) e SQL Server Management Studio (SSMS), proprio come l'uso di SSIS in locale.

Per altre informazioni sul runtime Azure-SSIS, vedere gli articoli seguenti:

Località del runtime di integrazione

Relazione tra la posizione della fabbrica e la posizione dell'infrarosso

Quando crei un'istanza di Data Factory o un workspace Synapse, devi specificarne la posizione. I metadati per l'istanza vengono archiviati qui e l'attivazione della pipeline viene avviata da qui. I metadati vengono archiviati solo nell'area scelta e non vengono archiviati in altre aree.

Nel frattempo, una pipeline può accedere agli archivi dati e ai servizi di calcolo in altre aree di Azure per spostare i dati tra archivi dati o elaborare i dati usando i servizi di calcolo. Questo comportamento viene attuato tramite l'IR disponibile a livello globale per garantire la conformità dei dati, l'efficienza e la riduzione dei costi di uscita della rete.

La posizione IR definisce la posizione del calcolo back-end e dove vengono eseguiti il movimento dei dati, il dispatching delle attività e l'esecuzione del pacchetto SSIS. La località del runtime di integrazione può essere diversa dalla località della Data Factory a cui appartiene.

Località del runtime di integrazione di Azure

È possibile impostare la regione geografica di un Azure Integration Runtime, nel qual caso l'esecuzione o il rilascio dell'attività avviene nella regione selezionata.

Per impostazione predefinita, il runtime di integrazione di Azure viene risolto automaticamente nella rete pubblica. Con questa opzione:

  • Per l'attività Copy, viene fatto il miglior tentativo possibile per rilevare automaticamente la posizione dell'archivio dati del sink. Viene quindi utilizzato il runtime di integrazione nella stessa area, se disponibile, altrimenti in quella più vicina nella stessa area geografica. Se l'area dell'archivio dati del sink non è rilevabile, viene invece usato il runtime di integrazione nell'area dell'istanza.

    Ad esempio, è stato creato un Data Factory o uno spazio di lavoro Synapse nell'est degli Stati Uniti,

    • Quando si copiano dati in un BLOB di Azure negli Stati Uniti occidentali, se viene rilevato che il BLOB si trova nell'area Stati Uniti occidentali, l'attività di copia viene eseguita nel runtime di integrazione negli Stati Uniti occidentali; se il rilevamento dell'area ha esito negativo, l'attività di copia viene eseguita nel runtime di integrazione negli Stati Uniti orientali.
    • Quando si copiano dati in Salesforce, per cui la regione non è rilevabile, l'attività Copy viene eseguita sul runtime di integrazione negli Stati Uniti orientali.

    Suggerimento

    Se hai requisiti rigorosi di conformità ai dati e devi assicurarti che i dati non escano da una certa geografia, puoi creare esplicitamente un IR Azure in una certa regione e indirizzare il servizio collegato a questo IR usando la proprietà ConnectVia. Ad esempio, se vuoi copiare dati da un blob nel Sud del Regno Unito a uno spazio di lavoro Azure Synapse nel Sud del Regno Unito e vuoi assicurarti che i dati non escano dal Regno Unito, crea un IR Azure nel Sud del Regno Unito e collega entrambi i servizi collegati a questo IR.

  • Per l'esecuzione di attività Lookup/GetMetadata/Delete (attività Pipeline), dispatching di attività di trasformazione (attività esterne) e operazioni di authoring (connessione di test, lista di cartelle e lista di tabelle, e anteprima dati), viene utilizzato l'IR nella stessa regione del Data Factory o dello spazio di lavoro Synapse.

  • Per Flusso di dati, viene utilizzato l'IR nella Data Factory o nella regione dello spazio di lavoro Synapse.

    Suggerimento

    Una procedura consigliata consiste nel garantire che i flussi di dati vengano eseguiti nella stessa area degli archivi dati corrispondenti, quando possibile. Puoi ottenerlo con l'autoresolve per Azure IR (se la posizione del data store è la stessa di Data Factory o Synapse workspace), oppure creando una nuova istanza Azure IR nella stessa regione dei tuoi archivi dati ed eseguindo i flussi di dati su di essa.

Se abiliti Managed Rete virtuale con autoresolve per Azure IR, viene utilizzato l'IR nella Data Factory o nella regione dello spazio di lavoro Synapse.

È possibile monitorare quale posizione del runtime di integrazione (IR) ha effetto durante l'esecuzione dell'attività nella visualizzazione di monitoraggio delle attività della pipeline in Data Factory Studio o Synapse Studio o nel payload di monitoraggio delle attività.

Località del runtime di integrazione self-hosted

L'IR auto-ospitato viene logicamente registrato presso la Data Factory o lo spazio di lavoro Synapse, e tu fornisci il calcolo utilizzato per supportarne le funzionalità. Pertanto non esiste una proprietà posizione esplicita per il runtime di integrazione self-hosted.

Quando viene usato per eseguire lo spostamento di dati, il runtime di integrazione self-hosted estrae i dati dall'origine e li scrive nella destinazione.

Località del runtime di integrazione Azure-SSIS

Nota

I runtime di integrazione SSIS di Azure non sono attualmente supportati nelle pipeline di Synapse.

Selezionando la località corretta per il runtime di integrazione Azure-SSIS è fondamentale ottenere prestazioni elevate per ei flussi di lavoro di estrazione, trasformazione e caricamento (ETL).

  • La posizione del runtime di integrazione Azure-SSIS non deve essere uguale alla posizione di Data Factory, ma deve essere uguale alla posizione del proprio database SQL di Azure o dell'istanza gestita di SQL in cui si trova SSISDB. In questo modo, il runtime di integrazione del Azure-SSIS può accedere facilmente all'SSISDB senza incorrere in traffico eccessivo tra le diverse località.
  • Se non si dispone di un database SQL o di un Istanza gestita di SQL esistente, ma si dispone di origini dati/destinazioni locali, è necessario creare un nuovo database SQL di Azure o Istanza gestita di SQL nella stessa posizione di una rete virtuale connessa all'ambiente locale rete. In questo modo, è possibile creare il runtime di integrazione di Azure-SSIS usando il nuovo database SQL di Azure o l'Istanza SQL gestita e unirsi a quella rete virtuale. Tutto si trova nella stessa posizione, riducendo al minimo lo spostamento dei dati e i costi associati, ottimizzando al contempo le prestazioni.
  • Se la posizione del tuo database SQL di Azure o Istanza gestita di SQL attuale non è la stessa di quella di una rete virtuale collegata alla tua rete on-premise, crea prima il tuo IR Azure-SSIS usando un database SQL di Azure o un Istanza gestita di SQL esistente e unirsi a un'altra rete virtuale nella stessa posizione. Configurare quindi una rete virtuale per la connessione di rete virtuale tra le diverse posizioni.

Il diagramma seguente illustra le impostazioni di posizione per Data Factory e i relativi runtime di integrazione:

Diagramma che mostra le impostazioni di posizione per Data Factory e i suoi runtime di integrazione.

Determinare quale IR utilizzare

Se un'attività è associata a più tipi di runtime di integrazione, viene risolta in uno di essi. L'runtime di integrazione auto-ospitata ha la precedenza rispetto all'runtime di integrazione Azure in Azure Data Factory o nelle istanze di workspace Synapse che utilizzano una rete virtuale gestita. Quest'ultimo ha la precedenza sul runtime di integrazione globale di Azure.

Ad esempio, un'attività di copia viene utilizzata per trasferire i dati dall'origine alla destinazione. Il runtime di integrazione globale di Azure è associato al servizio collegato all'origine, e un runtime di integrazione di Azure in una rete virtuale gestita di Azure Data Factory è associato al servizio collegato per il sink. Di conseguenza, sia i servizi collegati di origine che di sink usano il runtime di integrazione di Azure nella rete virtuale gestita di Azure Data Factory. Tuttavia, se un runtime di integrazione self-hosted è associato al servizio collegato per l'origine, allora sia l'origine che il sink utilizzano il runtime di integrazione self-hosted.

Attività di copia

L'attività Copy richiede sia i servizi collegati di origine e sink per definire la direzione del flusso di dati. Per determinare l'istanza del runtime di integrazione usata per eseguire la copia, viene usata la logica seguente:

  • Copia tra due sorgenti dati cloud: se entrambi i servizi collegati di origine e sink usano il runtime di integrazione di Azure, il runtime di integrazione di Azure a livello di area viene usato se è stato specificato o la posizione del runtime di integrazione di Azure viene determinata automaticamente se è stata scelta l'opzione runtime di integrazione ad autoresoluzione (predefinito) come descritto nella sezione Posizione del runtime di integrazione.
  • Copia dei dati tra un'origine dati cloud e un'origine dati in una rete privata: se il servizio collegato di origine o sink punta a un runtime di integrazione self-hosted, l'attività Copy viene eseguita sul runtime di integrazione self-hosted.
  • Copia tra due origini dati in una rete privata: sia il servizio collegato di origine che quello sink devono puntare alla stessa istanza del runtime di integrazione e questo runtime di integrazione viene usato per eseguire l'attività Copy.

Attività Lookup e GetMetadata

L'attività Lookup e GetMetadata viene eseguita sul runtime di integrazione associato al servizio collegato dell'archivio dati.

Attività di trasformazione esterna

Ogni attività di trasformazione esterna che utilizza un motore di calcolo esterno ha un servizio collegato di calcolo di destinazione, che indica un runtime di integrazione. Questa istanza IR determina la posizione da cui viene inviata l'attività di trasformazione esterna codificata manualmente.

Attività di flusso di dati

Le attività di flusso di dati vengono eseguite nel runtime di integrazione Azure associato. Le proprietà del flusso dati nel tuo Azure IR determinano il calcolo Spark utilizzato e sono completamente gestite dal servizio.

Runtime di integrazione in CI/CD

I runtime di integrazione non cambiano spesso e sono simili in tutte le fasi di CI/CD. Data Factory richiede che l'utente abbia lo stesso nome e lo stesso tipo di runtime di integrazione in tutte le fasi di CI/CD. Se si vogliono condividere i runtime di integrazione in tutte le fasi, è consigliabile usare una factory dedicata solo per contenere i runtime di integrazione condivisa. È quindi possibile usare questa factory condivisa in tutti gli ambienti come tipo di runtime di integrazione collegato.

Contenuto correlato

Fai riferimento ai seguenti articoli:

  • Last updated on