Integration Runtime i Azure Data Factory

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

Integration Runtime (IR) ä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:

  • Dataflöde: Kör en Dataflöde i en hanterad Azure-beräkningsmiljö.
  • Dataflytt: Kopiera data mellan datalager i ett offentligt eller privat nätverk (för både lokala eller virtuella privata nätverk). Tjänsten har stöd för inbyggda anslutningsappar, formatkonvertering, kolumnmappning och högpresterande och skalbar dataöverföring.
  • Aktivitetssändning: Skicka och övervaka omvandlingsaktiviteter som körs på en mängd olika beräkningstjänster, till exempel 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. En integrationskörning tillhandahåller bryggan mellan aktiviteter 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 direkt eller skickas. Detta gör att aktiviteten kan utföras i närmaste möjliga region till måldatalagret eller beräkningstjänsten för att maximera prestanda samtidigt som flexibiliteten kan uppfylla säkerhets- och efterlevnadskraven.

Integreringskörningar kan skapas i Azure Data Factory och Azure Synapse användargränssnittet direkt via hanteringshubben, samt från 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 hanterar dina dataintegreringsfunktioner och nätverksmiljökrav. De tre typerna av IR är:

  • Azure
  • Egen värd
  • Azure-SSIS

Anteckning

Synapse-pipelines stöder för närvarande endast Azure eller lokalt installerade integrationskörningar.

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

IR-typ Stöd för offentligt nätverk Private Link support
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

Anteckning

Utgående kontroller varierar beroende på tjänst för Azure IR. I Synapse har arbetsytor alternativ för att begränsa utgående trafik från det hanterade virtuella nätverket när du använder Azure IR. I Data Factory öppnas alla portar för utgående kommunikation vid användning av Azure IR. Azure-SSIS IR kan integreras med ditt virtuella nätverk för att tillhandahålla utgående kommunikationskontroller.

Azure Integration Runtime

En Azure-integrationskörning kan:

  • Köra dataflöden i Azure
  • Köra kopieringsaktiviteter mellan molndatalager
  • Skicka följande transformeringsaktiviteter i ett 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) Batch-körningsaktivitet, ML Studio(klassisk) Uppdateringsresursaktiviteter, Aktivitet för lagrad procedur Data Lake Analytics U-SQL-aktivitet, anpassad .NET-aktivitet, webbaktivitet, sökningsaktivitet och hämta metadataaktivitet.

Azure IR-nätverksmiljö

Azure Integration Runtime stöder anslutning till datalager och beräkningstjänster med offentliga tillgängliga slutpunkter. Azure Integration Runtime aktiverar hanterade Virtual Network och stöder anslutning till datalager med hjälp av private link-tjänsten i en privat nätverksmiljö. I Synapse har arbetsytor alternativ för att begränsa utgående trafik från det IR-hanterade virtuella nätverket. I Data Factory öppnas alla portar för utgående kommunikation. Azure-SSIS IR kan integreras med ditt virtuella nätverk för att tillhandahålla utgående kommunikationskontroller.

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 upp elastiskt utan att du uttryckligen behöver justera storleken på Azure-Integration Runtime.

Aktivitetssändning är en enkel åtgärd för att dirigera aktiviteten till målberäkningstjänsten, så det finns inget behov av att 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 relaterade till Dataflöde körning, som definierar den underliggande beräkningsinfrastrukturen som ska användas för att köra dataflödena.

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 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) Batch Execution-aktivitet, ML Studio (klassisk) Uppdateringsresursaktiviteter, lagrad proceduraktivitet, Data Lake Analytics U-SQL-aktivitet, anpassad aktivitet (körs på Azure Batch), uppslagsaktivitet och hämta metadataaktivitet.

Anteckning

Använd lokalt installerad integrationskörning för att stödja datalager som kräver egen drivrutin, till exempel SAP Hana, MySQL osv. Mer information finns i datalager som stöds.

Anteckning

Java Runtime Environment (JRE) är ett beroende av lokalt installerad IR. 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 direkt siktlinje från den offentliga molnmiljön kan du installera en lokalt installerad IR i din lokala miljö bakom en brandvägg eller i ett virtuellt privat nätverk. IR med egen värd utför bara utgående HTTP-baserade anslutningar till internet.

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

Installera en lokalt installerad IR på en lokal dator eller en virtuell dator i ett privat nätverk. För närvarande stöds den lokalt installerade IR:en endast 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 om hur du skapar och konfigurerar en lokalt installerad IR för mer information.

Azure SSIS Integration Runtime

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 antingen offentligt nätverk eller privat nätverk. Lokal dataåtkomst stöds genom att ansluta Azure-SSIS IR till ett virtuellt nätverk som är anslutet till ditt lokala nätverk.

Beräkningsresurs och skalning i Azure-SSIS IR

Azure-SSIS IR är ett fullständigt hanterat kluster med virtuella Azure-datorer som är dedikerade för att köra dina SSIS-paket. Du kan ta med egna 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 behov.

Mer information finns i Skapa och konfigurera Azure-SSIS IR. När du har skapat dem kan du distribuera och hantera befintliga SSIS-paket med små eller inga ändringar med hjälp av välbekanta verktyg som SQL Server Data Tools (SSDT) och SQL Server Management Studio (SSMS), precis som att använda SSIS lokalt.

Mer information om Azure-SSIS-körningen 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-databas som värd för SSIS-katalogen.
  • Så här skapar du en Azure-SSIS Integration Runtime. Den här artikeln går vidare med 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 ger 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 Portal för att konfigurera ett virtuellt nätverk och ansluta en Azure-SSIS IR till det.

Integration Runtime-plats

Relation mellan fabriksplats och IR-plats

När du skapar en instans av Data Factory eller en Synapse-arbetsyta måste du ange dess plats. Metadata för instansen lagras här och utlösande av pipelinen initieras härifrån. Metadata lagras bara i den valda regionen och lagras inte i andra regioner.

Under tiden kan en pipeline 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 dess serverdelsberäkning och var dataflytten, aktivitetssändningen och SSIS-paketkörningen utförs. IR-platsen kan skilja sig från platsen för datafabriken som den tillhör.

Azure IR-plats

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

Standardinställningen är att automatiskt matcha Azure IR i det offentliga nätverket. Med det här alternativet:

  • För kopieringsaktivitet görs ett bästa försök att automatiskt identifiera platsen för ditt mottagardatalager och sedan använda IR:en i samma region, om den är tillgänglig, eller den närmaste i samma geografiska område, annars. Om mottagardatalagrets region inte kan identifieras används IR i instansens region i stället.

    Till exempel skapades en Data Factory- eller Synapse-arbetsyta i USA, östra,

    • När du kopierar data till en Azure-blob i USA, västra körs kopieringsaktiviteten på IR i USA, västra om blobben identifieras vara i regionen USA, västra. Om regionidentifieringen misslyckas körs kopieringsaktiviteten på IR i USA, östra.
    • När du kopierar data till Salesforce, där regionen inte kan identifieras, körs kopieringsaktiviteten på IR i USA, östra.

    Tips

    Om du har strikta krav på dataefterlevnad och behöver se till att data inte lämnar ett visst geografiskt område kan du uttryckligen skapa en Azure IR i en viss region och peka den länkade tjänsten till denna IR med egenskapen ConnectVia. Om du till exempel vill kopiera data från en blob i Storbritannien, södra till en Azure Synapse arbetsyta 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 länkade tjänster till denna IR.

  • För körning av Lookup/GetMetadata/Delete-aktivitet (pipelineaktiviteter), sändning av transformeringsaktivitet (externa aktiviteter) och redigeringsåtgärder (testanslutning, bläddra i mapplista och tabelllista och förhandsgranskningsdata) används IR i samma region som Data Factory eller Synapse-arbetsytan.

  • För Dataflöde används IR i datafabriken eller Synapse-arbetsytan.

    Tips

    Bästa praxis är att se till att dataflöden körs i samma region som motsvarande datalager när det är möjligt. Du kan antingen uppnå detta med automatisk matchning för Azure IR (om datalagringsplatsen är samma som Data Factory- eller Synapse Workspace-platsen) eller genom att skapa en ny Azure IR-instans i samma region som dina datalager och sedan köra dataflödena på den.

Om du aktiverar hanterade Virtual Network med automatisk matchning för Azure IR används IR i datafabriken eller Synapse-arbetsytan.

Du kan övervaka vilken IR-plats som börjar gälla under aktivitetskörningen i övervakningsvyn för pipelineaktivitet i Data Factory Studio eller Synapse Studio, eller i nyttolasten för aktivitetsövervakning.

Namn på IR med egen värd

Den lokalt installerade IR:en är logiskt registrerad 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-integreringskörningar stöds för närvarande inte 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-databas eller SQL Managed Instance där SSISDB finns. På så sätt kan din Azure-SSIS-Integration Runtime enkelt komma åt SSISDB utan att orsaka överdriven trafik mellan olika platser.
  • Om du inte har någon befintlig SQL Database eller SQL Managed Instance, men du har lokala datakällor/mål, bör du skapa en ny Azure SQL-databas eller SQL Managed Instance 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-databasen eller SQL Managed Instance och ansluta till det virtuella nätverket. Allt kommer att finnas på samma plats, vilket minimerar dataflytt och associerade kostnader, samtidigt som prestanda maximeras.
  • Om platsen för din befintliga Azure SQL-databas 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 hjälp av en befintlig Azure SQL-databas eller SQL Managed Instance och anslut till ett annat virtuellt nätverk på samma plats. Konfigurera sedan ett virtuellt nätverk till en virtuell nätverksanslutning mellan de olika platserna.

Följande diagram visar platsinställningarna för Data Factory och dess integreringskörningar:

Visar Data Factory Integration Runtime-platser.

Bestämma vilken IR som ska användas

Om en aktivitet associeras med mer än en typ av integrationskörning kommer den att matcha en av dem. Integration Runtime med egen värd har företräde framför Azure Integration Runtime i Azure Data Factory- eller Synapse Workspace-instanser med hjälp av ett hanterat virtuellt nätverk. Och det senare har företräde framför den globala Azure-integreringskörningen.

En kopieringsaktivitet används till exempel för att kopiera data från källa till mottagare. Den globala Azure-integreringskörningen är associerad med den länkade tjänsten till källan och en Azure Integration Runtime i ett Azure Data Factory hanterat virtuellt nätverk associeras med den länkade tjänsten för mottagare. Resultatet är att både käll- och mottagarlänkade tjänster använder Azure Integration Runtime i Azure Data Factory hanterade virtuella nätverket. Men om en lokalt installerad integrationskörning associerar den länkade tjänsten för källan använder både käll- och mottagarlänktjänsten den lokalt installerade integrationskörningen.

Kopieringsaktivitet

Den aktiviteten Kopiera kräver att både käll- och mottagarlänkade tjänster definierar 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:

  • Kopiera mellan två molndatakällor: om både käll- och mottagarlänkade tjänster använder Azure IR används den regionala Azure IR om den har angetts, eller om platsen för Azure IR automatiskt bestäms om alternativet för automatisk matchning av IR (standard) har valts enligt beskrivningen i avsnittet Integration Runtime location (Plats för integreringskörning ).
  • Kopiera mellan en molndatakälla och en datakälla i ett privat nätverk: om den länkade käll- eller mottagartjänsten pekar på en lokalt installerad IR körs kopieringsaktiviteten på den lokalt installerade IR:n.
  • Kopiering mellan två datakällor i ett privat nätverk: både den länkade käll- och mottagartjänsten måste peka på samma instans av integrationskörningen och att IR 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ålberäkningstjänst som pekar på en integrationskörning. Den här IR-instansen avgör varifrån den externa handkodade transformeringsaktiviteten skickas.

Dataflöde aktivitet

Dataflöde aktiviteter körs på deras associerade Azure Integration Runtime. Spark-beräkningen som används av dataflöden bestäms av dataflödesegenskaperna i din Azure IR och hanteras fullständigt av tjänsten.

Integration Runtime i CI/CD

Integreringskörningar ändras inte ofta och liknar dem i alla faser i din CI/CD. Data Factory kräver att du har samma namn och typ av integreringskörning i alla faser av CI/CD. Om du vill dela integreringskörningar i alla faser bör du överväga att använda en dedikerad fabrik som bara innehåller de delade integreringskörningarna. Du kan sedan använda den här delade fabriken i alla dina miljöer som en länkad integrationskörningstyp.

Nästa steg

Se följande artiklar: