Integration Runtime i Azure Data Factory

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

IR (Integration Runtime) är den beräkningsinfrastruktur som används av Azure Data Factory- och Azure Synapse-pipelines för att tillhandahålla följande dataintegreringsfunktioner i olika nätverksmiljöer:

  • Data Flow: Kör ett data Flow i en hanterad Azure-beräkningsmiljö.
  • Dataförflyttning: Kopiera data mellan datalager i offentliga nätverk och datalager i privat nätverk (lokalt eller virtuellt privat nätverk). Den ger stöd åt inbyggda anslutningsappar, konvertering av format, kolumnmappning och bättre och skalbar dataöverföring.
  • Aktivitetssändning: Skicka och övervaka transformeringsaktiviteter som körs på en mängd olika beräkningstjänster som Azure Databricks, Azure HDInsight, ML Studio (klassisk), Azure SQL Database, SQL Server med mera.
  • SSIS paketkörning: Internt köra SQL Server Integration Services-paket (SSIS) i en hanterad Azure-beräkningsmiljö.

I Data Factory och Synapse-pipelines definierar en aktivitet den åtgärd som ska utföras. En länkad tjänst definierar ett datalager som mål eller en beräkningstjänst. Integration Runtime utgör bryggan mellan aktiviteten och länkade tjänster. Den refereras av den länkade tjänsten eller aktiviteten och tillhandahåller beräkningsmiljön där aktiviteten antingen körs eller skickas från. På så sätt kan aktiviteten utföras i regionen som är den närmaste möjliga till måldatalagret eller beräkningstjänsten på det bästa sättet samtidigt som den uppfyller säkerhets- och efterlevnadsbehoven.

Integreringskörningar kan skapas i Azure Data Factory och Azure Synapse via hanteringshubben och alla aktiviteter, datauppsättningar eller dataflöden som refererar till dem.

Integration Runtime

Data Factory erbjuder tre typer av Integration Runtime (IR) och du bör välja den typ som bäst passar de dataintegreringsfunktioner och nätverksmiljöbehov som du letar efter. Dessa tre typer är:

  • Azure
  • Egen värd
  • Azure-SSIS

Anteckning

Synapse-pipelines stöder för närvarande endast Azure eller integrationskörningar med egen värd.

I följande tabell beskrivs funktioner och nätverksstöd för varje Integration Runtime-typ:

IR-typ Offentligt nätverk Privat nätverk
Azure Dataflöde
Dataförflyttning
Aktivitetssändning
Dataflöde
Dataförflyttning
Aktivitetssändning
Egen värd Dataförflyttning
Aktivitetssändning
Dataförflyttning
Aktivitetssändning
Azure-SSIS Körning av SSIS-paket Körning av SSIS-paket

Azure Integration Runtime

En Azure Integration Runtime kan:

  • Köra dataflöden i Azure
  • Köra kopieringsaktivitet mellan molndatalager
  • Skicka följande transformeringsaktiviteter i offentligt nätverk: Databricks Notebook/Jar/Python-aktivitet, HDInsight Hive-aktivitet, HDInsight Pig-aktivitet, HDInsight MapReduce-aktivitet, HDInsight Spark-aktivitet, HDInsight Streaming-aktivitet, ML Studio (klassisk) aktiviteten Batch Execution, ML Studio (klassisk) Uppdatera resursaktiviteter, Aktiviteten Lagrad procedur, Data Lake Analytics U-SQL-aktivitet, anpassad .NET-aktivitet, Webbaktivitet, Sökningsaktivitet och Aktiviteten Hämta metadata.

Azure IR-nätverksmiljö

Azure Integration Runtime stöder anslutning till datalager och beräkningstjänster med offentliga tillgängliga slutpunkter. Om du aktiverar Managed Virtual Network stöder Azure Integration Runtime anslutning till datalager med hjälp av private link-tjänsten i den privata nätverksmiljön.

Beräkningsresurs och skalning i Azure IR

Med Azure Integration Runtime får du en helt hanterad, serverlös beräkning i Azure. Du behöver inte bekymra dig om infrastrukturetablering, programvaruinstallation, korrigering eller kapacitetsskalning. Dessutom betalar du bara för den faktiska användningen.

Med Azure Integration Runtime får du interna beräkningsfunktioner för att flytta data mellan molndatalager på ett säkert, pålitligt sätt med höga prestanda. Du kan ange hur många dataintegreringsenheter som ska användas för kopieringsaktiviteten, och beräkningsstorleken för Azure IR skalas elastiskt upp efter detta utan att du behöver justera storleken på Azure Integration Runtime.

Aktivitetssändning är en enkel åtgärd för att dirigera aktiviteten till målbearbetningstjänsten, så du behöver inte skala upp beräkningsstorleken för det här scenariot.

Information om hur du skapar och konfigurerar en Azure IR finns i Så här skapar och konfigurerar du Azure Integration Runtime.

Anteckning

Azure Integration Runtime har egenskaper som är relaterade till Data Flow Runtime, som definierar den underliggande beräkningsinfrastruktur som används för att köra dataflöden på.

Integration Runtime med egen värd

En IR med egen värd kan:

  • Köra kopieringsaktivitet mellan molndatalager och ett datalager i privat nätverk.
  • Skicka följande transformeringsaktiviteter mot beräkningsresurser lokalt eller i Azure Virtual Network: HDInsight Hive-aktivitet (BYOC-Bring Your Own Cluster), HDInsight Pig-aktivitet (BYOC), HDInsight MapReduce-aktivitet (BYOC), HDInsight Spark-aktivitet (BYOC), HDInsight Streaming-aktivitet (BYOC), ML Studio (klassisk) aktiviteten Batch Execution, ML Studio (klassisk) Uppdatera resursaktiviteter, Lagrad procedur-aktivitet, Data Lake Analytics U-SQL-aktivitet, Anpassad aktivitet (körs på Azure Batch), Sökningsaktivitet och Hämta metadata-aktivitet.

Anteckning

Använd integration runtime med egen värd för att stödja datalager som kräver bring-your-own-drivrutin som SAP Hana, MySQL osv. Mer information finns i Datalager som stöds.

Anteckning

Java Runtime Environment (JRE) är ett beroende av IR med egen värd. Kontrollera att JRE är installerat på samma värd.

IR-nätverksmiljö med egen värd

Om du vill utföra dataintegrering på ett säkert sätt i en privat nätverksmiljö, som inte har en direkt syn från den offentliga molnmiljön, kan du installera en lokal IR med egen värd bakom företagets brandvägg eller i ett virtuellt privat nätverk. IR med egen värd utför bara utgående HTTP-baserade anslutningar till öppet internet.

Beräkningsresurs och skalning i IR med egen värd

Installera lokalt värdbaserade IR på en lokal dator eller en virtuell dator i ett privat nätverk. För närvarande stöder vi bara att IR med egen värd körs på ett Windows-operativsystem.

För hög tillgänglighet och skalbarhet kan du skala ut IR med egen värd genom att associera den logiska instansen med flera lokala datorer i aktiv/aktiv-läge. Mer information finns i artikeln skapa och konfigurera IR med egen värd under guiderna.

Azure-SSIS Integration Runtime

Anteckning

Azure-SSIS Integration Runtimes stöds inte för närvarande i Synapse-pipelines.

Om du vill lyfta och skifta befintlig SSIS-arbetsbelastning kan du skapa en Azure-SSIS IR för att köra SSIS-paket internt.

Azure-SSIS IR-nätverksmiljö

Azure-SSIS IR kan etableras i offentliga eller privata nätverk. Åtkomst till lokala data stöds genom att koppla Azure-SSIS IR till ett virtuellt nätverk som är anslutet till det lokala nätverket.

Beräkningsresurs och skalning i Azure-SSIS IR

Azure-SSIS IR är ett helt hanterat kluster av virtuella Azure-datorer särskilt avsedda att köras SSIS-paketen. Du kan använda en egen Azure SQL Database eller SQL Managed Instance för katalogen med SSIS-projekt/-paket (SSISDB). Du kan skala upp kraften i beräkningen genom att ange nodstorlek och skala ut den genom att ange antalet noder i klustret. Du kan hantera kostnaden för att köra Azure-SSIS Integration Runtime genom att stoppa och starta den efter önskemål.

Om du vill ha mer information läser du artikeln om hur du skapar och konfigurerar Azure-SSIS IR under ”så här gör du”-guiderna. När du har skapat den kan du distribuera och hantera dina befintliga SSIS-paket med få eller inga ändringar med välbekanta verktyg, som SQL Server Data Tools (SSDT) och SQL Server Management Studio (SSMS), precis som när du använder SSIS lokalt.

Mer information om Azure-SSIS runtime finns i följande artiklar:

  • Självstudie: distribuera SSIS-paket till Azure. Den här artikeln innehåller stegvisa instruktioner för att skapa en Azure-SSIS IR och använder en Azure SQL Database som värd för SSIS-katalogen.
  • Så här skapar du en Azure-SSIS Integration Runtime. Den här artikeln utökar självstudien och innehåller instruktioner om hur du använder SQL Managed Instance och ansluter IR till ett virtuellt nätverk.
  • Övervaka en Azure-SSIS IR. Den här artikeln visar hur du hämtar information om en Azure-SSIS IR och innehåller beskrivningar av statusar i den returnerade informationen.
  • Hantera en Azure-SSIS IR. Den här artikeln visar hur du stoppar, startar eller tar bort en Azure-SSIS IR. Den också visar hur du skalar ut Azure-SSIS IR genom att lägga till fler noder i IR.
  • Anslut Azure-SSIS IR till ett virtuellt nätverk. Den här artikeln innehåller begreppsrelaterad information om att ansluta Azure-SSIS IR till ett virtuellt Azure-nätverk. Den innehåller också steg för att använda Azure-portalen för att konfigurera ett virtuellt nätverk så att Azure-SSIS IR kan ansluta till ett virtuellt nätverk.

Integration Runtime-plats

Relationen mellan fabriksplatsen och IR-platsen

När kunden skapar en Data Factory instans måste de ange platsen för Data Factory eller Synapse Workspace. Metadata för Data Factory eller Synapse Workspace lagras här och utlösningen av pipelinen initieras härifrån. Metadata lagras bara i den region som kunden väljer och lagras inte i andra regioner.

Under tiden kan en Azure Data Factory eller Azure Synapse komma åt datalager och beräkningstjänster i andra Azure-regioner för att flytta data mellan datalager eller bearbeta data med hjälp av beräkningstjänster. Det här beteende realiseras via globalt tillgängligt IR för att säkerställa dataefterlevnad, effektivitet och minskade kostnader för nätverksegress.

IR-platsen definierar platsen för backend-beräkningen och i stort sett platsen där dataflytt, aktivitetssändning och SSIS-paketkörning utförs. IR-platsen kan vara annorlunda än platsen för den Data Factory den tillhör.

Azure IR-plats

Du kan ange en viss plats för en Azure IR, i vilket fall aktivitetskörningen eller sändningen sker i den specifika regionen.

Om du väljer att använda den automatiska Azure IR i det offentliga nätverket, vilket är standard,

  • För kopieringsaktivitet görs ett bästa försök att automatiskt identifiera platsen för mottagarens datalager och sedan använda IR i antingen samma region om det är tillgängligt eller det närmaste inom samma geografiska område. Om det inte går att identifiera måldatalagrets region används IR i Data Factory region som alternativ.

    Till exempel har du din Data Factory synapse-arbetsyta har skapats i USA, östra,

    • När du kopierar data till Azure Blob i USA, västra körs kopieringsaktiviteten på IR i USA, västra om bloben identifieras i USA, västra. Om regionidentifiering misslyckas körs kopieringsaktiviteten på IR i USA, östra.
    • När du kopierar data till Salesforce som regionen inte kan identifieras av körs kopieringsaktiviteten på IR i USA, östra.

    Tips

    Om du måste efterleva strikta datakrav och måste säkerställa att data inte lämnar ett visst område kan du uttryckligen skapa en Azure IR i den regionen och hänvisa den länkade tjänsten till denna IR med egenskapen ConnectVia. Om du till exempel vill kopiera data från Blob i Storbritannien, södra till Azure Synapse Analytics i Storbritannien, södra och vill se till att data inte lämnar Storbritannien skapar du en Azure IR i Storbritannien, södra och länkar båda de länkade tjänsterna till denna IR.

  • För lookup/GetMetadata/Delete-aktivitetskörning (kallas även pipelineaktiviteter), sändning av transformeringsaktivitet (även kallat externa aktiviteter) och redigeringsåtgärder (testanslutning, bläddringsmapplista och tabelllista, förhandsgranskningsdata), används IR i samma region som Data Factory- eller Synapse-arbetsytan.

  • För data Flow används IR i Data Factory eller Synapse-arbetsyta.

    Tips

    En bra idé är att se till att dataflödet körs i samma region som dina motsvarande datalager (om möjligt). Du kan antingen åstadkomma detta genom att automatiskt lösa Azure IR (om datalagerplatsen är samma som platsen för Data Factory- eller Synapse-arbetsytan) eller genom att skapa en ny Azure IR-instans i samma region som dina datalager och sedan köra dataflödet på den.

Om du aktiverar Hanterade Virtual Network för automatisk Azure IR används IR i Data Factory eller Synapse-arbetsytan.

Du kan övervaka vilken IR plats som börjar gälla under körning av aktiviteten i övervakningsvyn för pipeline-aktivitet i gränssnittet eller en aktivitetsövervakningsnyttolast.

Namn på IR med egen värd

Den lokala IR:en registreras logiskt på Data Factory eller Synapse-arbetsytan och den beräkning som används för att stödja dess funktioner tillhandahålls av dig. Det finns därför ingen uttrycklig platsegenskapen för IR med egen värd.

När IR med egen värd används för att utföra dataflyttning extraherar den data från källan och skriver dem till målet.

Azure-SSIS IR-plats

Anteckning

Azure-SSIS Integration Runtimes stöds inte för närvarande i Synapse-pipelines.

Att välja rätt plats för Azure-SSIS IR är viktigt för att uppnå höga prestanda i dina arbetsflöden för extrahering, transformering och laddning (ETL).

  • Platsen för din Azure-SSIS IR behöver inte vara samma som platsen för din Data Factory, men den bör vara samma som platsen för din egen Azure SQL Database eller SQL Managed Instance där SSISDB. På så sätt kan din Azure-SSIS Integration Runtime enkelt få åtkomst till SSISDB utan att det medför överdriven trafik mellan olika platser.
  • Om du inte har en befintlig SQL Database- eller SQL-hanterad instans, men du har lokala datakällor/-mål, bör du skapa en ny Azure SQL Database- eller SQL-hanterad instans på samma plats som ett virtuellt nätverk som är anslutet till ditt lokala nätverk. På så sätt kan du skapa din Azure-SSIS IR med hjälp av den nya Azure SQL Database- eller SQL-hanterade instansen och ansluta det virtuella nätverket på samma plats, vilket effektivt minimerar dataförflyttningar mellan olika platser.
  • Om platsen för din befintliga Azure SQL Database eller SQL Managed Instance inte är samma som platsen för ett virtuellt nätverk som är anslutet till ditt lokala nätverk, skapar du först din Azure-SSIS IR med en befintlig Azure SQL Database eller SQL-hanterad instans och ansluter till ett annat virtuellt nätverk på samma plats och konfigurerar sedan en virtuell nätverk till virtuell nätverksanslutning mellan olika platser.

I följande diagram visas platsinställningar för Data Factory och dess Integration Runtime-instanser:

Integration Runtime-plats

Bestämma vilken IR som ska användas

Om en aktivitet associeras med mer än en typ av Integration Runtime matchas den till en av dem. Integration Runtime med egen värd har företräde framför Azure Integration Runtime i Azure Data Factory eller Synapse-arbetsytor med hjälp av ett hanterat virtuellt nätverk. Och det senare har företräde framför global Azure Integration Runtime.

En kopieringsaktivitet används till exempel för att kopiera data från källa till mottagare. Den globala Azure Integration Runtime är associerad med den länkade tjänsten till källan och en Azure Integration Runtime i Azure Data Factory-hanterat virtuellt nätverk associeras med den länkade tjänsten för mottagare. Resultatet är att den länkade tjänsten för både källa och mottagare använder Azure Integration Runtime i Azure Data Factory- eller Synapse-arbetsytor med hjälp av ett hanterat virtuellt nätverk. Men om en integrationskörning med egen värd associerar den länkade tjänsten för källan använder både den länkade käll- och mottagartjänsten integration runtime med egen värd.

Kopieringsaktivitet

För kopieringsaktiviteten kräver den länkade tjänster-källa och länkade tjänster-mottagare för att definiera dataflödets riktning. Följande logik används till att bestämma vilken Integration Runtime-instans som används för att utföra kopieringen:

  • Kopiering mellan två molndatakällor: när både länkade käll- och måltjänster använder Azure IR används den regionala Azure IR om den har angetts eller platsen för Azure IR automatiskt om den automatisktlösa IR:n (standard) har valts enligt beskrivningen i avsnittet Integration Runtime location (Integration Runtime-plats).
  • Kopiera mellan molndatalager och datakälla i privat nätverk: om den länkade källtjänsten eller den länkade mottagartjänsten pekar på en IR med egen värd körs kopieringsaktiviteten på den Integration Runtime med egen värd.
  • Kopiera mellan två datakällor i privat nätverk: både den länkade käll- och mottagarens tjänst måste peka på samma instans av Integration Runtime, och denna Integration Runtime används för att köra kopieringsaktiviteten.

Lookup och GetMetadata-aktivitet

Aktiviteterna Lookup och GetMetadata har körts på integreringskörningsmiljön som är associerad med den länkade datalagringstjänsten.

Extern transformeringsaktivitet

Varje extern transformeringsaktivitet som använder en extern beräkningsmotor har en länkad målbearbetningstjänst som pekar på en integreringskörning. Den här Integration Runtime-instansen avgör var den externa handkodade transformeringsaktiviteten skickas från.

Data Flow aktivitet

Data Flow aktiviteter körs på den Azure Integration Runtime som är associerad med den. Den Spark-beräkning som används av dataflöden bestäms av dataflödesegenskaperna i Azure Integration Runtime och hanteras helt av ADF.

Nästa steg

Se följande artiklar: