Tworzenie działań i potoków fabryki danych
Działania w usłudze Azure Data Factory definiują akcje, które będą wykonywane na danych i istnieją trzy kategorie, w tym:
- Działania dotyczące przenoszenia danych
- Działania dotyczące przekształcania danych
- Działania sterowania
Działania dotyczące przenoszenia danych
Działania przenoszenia danych po prostu przenoszą dane z jednego magazynu danych do innego. Działanie kopiowania umożliwia wykonywanie działań przenoszenia danych lub przy użyciu formatu JSON. Istnieje wiele magazynów danych, które są obsługiwane jako źródło i jako ujście. Ta lista stale rośnie i można znaleźć najnowsze informacje tutaj.
Działania dotyczące przekształcania danych
Działania przekształcania danych można wykonywać natywnie w narzędziu do tworzenia usługi Azure Data Factory przy użyciu Przepływ danych mapowania. Alternatywnie możesz wywołać zasób obliczeniowy, aby zmienić lub ulepszyć dane za pomocą transformacji lub przeprowadzić analizę danych. Obejmują one technologie obliczeniowe, takie jak Azure Databricks, Azure Batch, SQL Database i Azure Synapse Analytics, Machine Edukacja Services, Azure Virtual Machines i HDInsight. Do wykonania na platformie Azure można używać dowolnych istniejących pakietów usług SQL Server Integration Services (SSIS) przechowywanych w katalogu
Ponieważ ta lista zawsze ewoluuje, możesz uzyskać najnowsze informacje tutaj.
Działania sterowania
Podczas graficznego tworzenia rozwiązań usługi ADF można użyć przepływu sterowania w projekcie do organizowania działań potoku, które obejmują działania łańcucha w sekwencji, rozgałęzianie, definiowanie parametrów na poziomie potoku i przekazywanie argumentów podczas wywoływania potoku na żądanie lub z wyzwalacza. Bieżące możliwości obejmują:
| Działanie sterujące | opis |
|---|---|
| Działanie Execute Pipeline | Działanie Execute Pipeline umożliwia potokowi usługi Data Factory wywoływanie innego potoku. |
| Działanie ForEach | Działanie ForEach definiuje powtarzający się przepływ sterowania w potoku. To działanie służy do wykonywania iteracji po kolekcji i wykonuje określone działania w pętli. Implementacja pętli tego działania przypomina strukturę pętli Foreach w językach programowania. |
| Działanie WebActivity | Działanie WebActivity może być używane do wywoływania niestandardowego punktu końcowego REST z potoku usługi Data Factory. Można przekazywać zestawy danych i połączone usługi do zużycia i dostępu przez działanie. |
| Działanie Lookup | Działanie Lookup może być używane do odczytywania lub wyszukiwania rekordu/nazwy tabeli/wartości z dowolnego źródła zewnętrznego. Do tych danych wyjściowych mogą także odwoływać się kolejne działania. |
| Działanie GetMetadata | Działanie GetMetadata umożliwia pobieranie metadanych dowolnych danych z usługi Azure Data Factory. |
| Działanie Until | Wprowadza pętlę Do-Until, przypominającą strukturę pętli Do-Until w językach programowania. Służy do wykonywania zestawu działań w pętli do momentu, gdy warunek skojarzony z działaniem zostanie obliczony na wartość true. W usłudze Data Factory można określić wartość limitu czasu działania Until. |
| Działanie If Condition | Działanie If Condition umożliwia tworzenie gałęzi na podstawie warunków, które są obliczane na wartość true lub false. Działanie If Condition pełni taką samą rolę, co instrukcja if w językach programowania. Ocenia zestaw działań, gdy warunek ma wartość true, a inny zestaw działań, gdy warunek daje wartość false. |
| Działanie Wait | Gdy używasz działania Wait w potoku, potok czeka przez określony okres z kontynuowaniem wykonywania kolejnych działań. |
Najnowsze informacje można znaleźć tutaj.
Działania i potoki
Definiowanie działań
W przypadku korzystania z notacji JSON sekcja działań może zawierać co najmniej jedną zdefiniowaną w niej czynności. Istnieją dwa główne typy działań: działania wykonywania i sterowania. Działania wykonywania (nazywane również obliczeniami) obejmują działania przenoszenia danych i przekształcania danych. Ich struktura najwyższego poziomu wygląda następująco:
{
"name": "Execution Activity Name",
"description": "description",
"type": "<ActivityType>",
"typeProperties":
{
},
"linkedServiceName": "MyLinkedService",
"policy":
{
},
"dependsOn":
{
}
}
W poniższej tabeli opisano właściwości powyższego kodu JSON:
| Właściwości | Opis | Wymagania |
|---|---|---|
| name | Nazwa działania. | Tak |
| opis | Tekst opisujący, do czego służy działanie lub dla którego jest używane. | Nie. |
| type | Definiuje typ działania. | Tak |
| linkedServiceName | Nazwa połączonej usługi używana na potrzeby działania. | Tak w przypadku usługi HDInsight, działania oceniania wsadowego Edukacja maszyny i działania procedury składowanej |
| typeProperties | Właściwości w sekcji typeProperties zależą od typu działania. | Nie. |
| policy | Zasady, które mają wpływ na zachowanie działania w czasie wykonania. Ta właściwość zawiera zachowania związane z limitem czasu i ponownymi próbami. | Nie. |
| dependsOn | Ta właściwość jest używana do definiowania zależności działania oraz sposobu, w jaki kolejne działania zależą od poprzednich działań. | Nie. |
Definiowanie działań sterujących
Działanie kontrolki w usłudze Data Factory jest definiowane w formacie JSON w następujący sposób:
{
"name": "Control Activity Name",
"description": "description",
"type": "<ActivityType>",
"typeProperties":
{
},
"dependsOn":
{
}
}
W poniższej tabeli opisano właściwości powyższego kodu JSON:
| Właściwości | Opis | Wymagania |
|---|---|---|
| name | Nazwa działania. | Tak |
| opis | Tekst opisujący, do czego służy działanie lub dla którego jest używane. | Tak |
| type | Definiuje typ działania. | Tak |
| typeProperties | Właściwości w sekcji typeProperties zależą od typu działania. | Nie. |
| dependsOn | Ta właściwość jest używana do definiowania zależności działania oraz sposobu, w jaki kolejne działania zależą od poprzednich działań. | Nie. |
Definiowanie potoków
Poniżej przedstawiono sposób definiowania potoku w formacie JSON:
{
"name": "PipelineName",
"properties":
{
"description": "pipeline description",
"activities":
[
],
"parameters": {
}
}
}
W poniższej tabeli opisano właściwości powyższego kodu JSON:
| Właściwości | Opis | Wymagania |
|---|---|---|
| name | Nazwa potoku. | Tak |
| opis | Tekst opisujący, do czego służy potok. | Nie. |
| activities | W sekcji activities można zdefiniować jedno lub więcej działań. | Tak |
| parameters | Sekcja parameters może zawierać jeden lub kilka parametrów zdefiniowanych w potoku, co zwiększa elastyczność i możliwość ponownego zastosowania potoku. | Nie. |
Przykład
Poniższy kod JSON definiuje potok o nazwie "MyFirstPipeline", który zawiera jeden typ działania usługi HDInsightHive, który będzie wywoływać zapytanie z nazwy skryptu "partitionweblogs.hql", która jest przechowywana w połączonej usłudze o nazwie "StorageLinkedService", z danymi wejściowymi o nazwie "AzureBlobInput" i danymi wyjściowymi o nazwie "AzureBlobOutput". Wykonuje to względem zasobu obliczeniowego zdefiniowanego w połączonej usłudze o nazwie "HDInsightOnDemandLinkedService"
Potok jest zaplanowany do wykonania co miesiąc i podejmie próbę wykonania 3 razy, jeśli zakończy się niepowodzeniem.
{
"name": "MyFirstPipeline",
"properties": {
"description": "My first Azure Data Factory pipeline",
"activities": [
{
"type": "HDInsightHive",
"typeProperties": {
"scriptPath": "adfgetstarted/script/partitionweblogs.hql",
"scriptLinkedService": "StorageLinkedService",
"defines": {
"inputtable": "wasb://adfgetstarted@ctostorageaccount.blob.core.windows.net/inputdata",
"partitionedtable": "wasb://adfgetstarted@ctostorageaccount.blob.core.windows.net/partitioneddata"
}
},
"inputs": [
{
"name": "AzureBlobInput"
}
],
"outputs": [
{
"name": "AzureBlobOutput"
}
],
"policy": {
"concurrency": 1,
"retry": 3
},
"scheduler": {
"frequency": "Month",
"interval": 1
},
"name": "RunSampleHiveActivity",
"linkedServiceName": "HDInsightOnDemandLinkedService"
}
],
"start": "2017-04-01T00:00:00Z",
"end": "2017-04-02T00:00:00Z",
"isPaused": false,
"hubName": "ctogetstarteddf_hub",
"pipelineMode": "Scheduled"
}
}