Tworzenie potoków predykcyjnych przy użyciu usługi Machine Learning Studio (klasycznej) i Azure Data Factory

Ważne

Obsługa programu Machine Learning Studio (wersja klasyczna) zakończy się 31 sierpnia 2024 r. Zalecamy przejście do usługi Azure Machine Learning przed tym terminem.

Od 1 grudnia 2021 r. nie będzie można tworzyć nowych zasobów usługi Machine Learning Studio (klasycznych) (obszar roboczy i plan usługi internetowej). Do 31 sierpnia 2024 r. można nadal korzystać z istniejących eksperymentów i usług internetowych usługi Machine Learning Studio (klasycznej).

Dokumentacja programu ML Studio (wersja klasyczna) jest wycofywana i może nie być aktualizowana w przyszłości.

Wprowadzenie

Uwaga

Ten artykuł dotyczy wersji 1 usługi Data Factory. Jeśli używasz bieżącej wersji usługi Data Factory, zobacz przekształcanie danych przy użyciu uczenia maszynowego w usłudze Data Factory.

Usługa Machine Learning Studio (klasyczna)

Usługa ML Studio (klasyczna) umożliwia tworzenie, testowanie i wdrażanie rozwiązań analizy predykcyjnej. Z punktu widzenia wysokiego poziomu odbywa się to w trzech krokach:

  1. Tworzenie eksperymentu szkoleniowego. Ten krok można wykonać przy użyciu programu ML Studio (wersja klasyczna). Studio (wersja klasyczna) to wizualne środowisko programistyczne, którego używasz do trenowania i testowania modelu analizy predykcyjnej przy użyciu danych treningowych.
  2. Przekonwertuj go na eksperyment predykcyjny. Gdy model zostanie wytrenowany przy użyciu istniejących danych i wszystko będzie gotowe do oceny nowych danych, przygotujesz i usprawnisz eksperyment pod kątem oceniania.
  3. Wdróż ją jako usługę internetową. Eksperyment oceniania można opublikować jako usługę internetową platformy Azure. Dane można wysyłać do modelu za pośrednictwem tego punktu końcowego usługi internetowej i otrzymywać przewidywania wyników dla modelu.

Azure Data Factory

Data Factory to oparta na chmurze usługa integracji danych, która organizuje i automatyzuje przenoszenie i przekształcanie danych. Rozwiązania do integracji danych można tworzyć przy użyciu Azure Data Factory, które mogą pozyskiwać dane z różnych magazynów danych, przekształcać/przetwarzać dane oraz publikować dane wynikowe w magazynach danych.

Usługa Data Factory pozwala tworzyć potoki danych służące do przenoszenia i przekształcania danych, a następnie uruchamiać te potoki zgodnie z zaplanowanym harmonogramem (co godzinę, codziennie, co tydzień itp.). Usługa ta udostępnia również rozbudowane wizualizacje umożliwiające wyświetlanie elementów powiązanych i zależności między potokami danych oraz monitorowanie wszystkich potoków danych w jednym zintegrowanym widoku, który ułatwia wykrywanie problemów i konfigurowanie alertów monitorowania.

Zobacz Wprowadzenie do Azure Data Factory i Tworzenie pierwszych artykułów potoku, aby szybko rozpocząć pracę z usługą Azure Data Factory.

Usługi Data Factory i Machine Learning Studio (klasyczne)

Azure Data Factory umożliwia łatwe tworzenie potoków korzystających z opublikowanej usługi internetowej ML Studio (klasycznej) do analizy predykcyjnej. Za pomocą działania wykonywania wsadowego w potoku Azure Data Factory można wywołać usługę internetową Studio (klasyczną), aby przewidywać dane w partii. Aby uzyskać szczegółowe informacje, zobacz Wywoływanie usługi internetowej ML Studio (klasycznej) przy użyciu działania wykonywania wsadowego.

W miarę upływu czasu modele predykcyjne w eksperymentach oceniania programu Studio (klasycznego) muszą zostać ponownie wytrenowane przy użyciu nowych wejściowych zestawów danych. Możesz ponownie wytrenować model studio (klasyczny) z potoku usługi Data Factory, wykonując następujące czynności:

  1. Opublikuj eksperyment szkoleniowy (nie eksperyment predykcyjny) jako usługę internetową. Ten krok można wykonać w programie Studio (klasycznym), tak jak w przypadku uwidocznienia eksperymentu predykcyjnego jako usługi internetowej w poprzednim scenariuszu.
  2. Użyj działania wykonywania wsadowego programu Studio (klasycznego), aby wywołać usługę internetową na potrzeby eksperymentu szkoleniowego. Zasadniczo można użyć działania wykonywania usługi Batch Studio (klasycznej), aby wywołać zarówno usługę internetową trenowania, jak i usługę internetową oceniania.

Po zakończeniu ponownego trenowania zaktualizuj usługę internetową oceniania (eksperyment predykcyjny uwidoczniony jako usługa internetowa) przy użyciu nowo wytrenowanego modelu przy użyciu działania aktualizacji zasobu usługi ML Studio (klasycznej). Aby uzyskać szczegółowe informacje, zobacz Artykuł Aktualizowanie modeli przy użyciu działania aktualizacji zasobów .

Wywoływanie usługi internetowej przy użyciu działania wykonywania wsadowego

Używasz Azure Data Factory do organizowania przenoszenia i przetwarzania danych, a następnie wykonywania wsadowego przy użyciu programu Studio (wersja klasyczna). Poniżej przedstawiono kroki najwyższego poziomu:

  1. Tworzenie połączonej usługi ML Studio (klasycznej). Potrzebne są następujące wartości:

    1. Identyfikator URI żądania dla interfejsu API wykonywania wsadowego. Identyfikator URI żądania można znaleźć, klikając link WYKONYWANIE usługi BATCH na stronie usług internetowych.

    2. Klucz interfejsu API dla opublikowanej usługi internetowej Studio (klasycznej). Klucz interfejsu API można znaleźć, klikając opublikowaną usługę internetową.

    3. Użyj działania AzureMLBatchExecution .

      Pulpit nawigacyjny usługi Machine Learning Studio (klasyczny)

      Batch URI

Scenariusz: Eksperymenty przy użyciu danych wejściowych/wyjściowych usługi internetowej odwołujących się do danych w Azure Blob Storage

W tym scenariuszu usługa sieci Web Studio (klasyczna) tworzy przewidywania przy użyciu danych z pliku w magazynie obiektów blob platformy Azure i przechowuje wyniki przewidywania w magazynie obiektów blob. Poniższy kod JSON definiuje potok usługi Data Factory za pomocą działania AzureMLBatchExecution. Działanie zawiera zestaw danych DecisionTreeInputBlob jako dane wejściowe i DecisionTreeResultBlob jako dane wyjściowe. Obiekt DecisionTreeInputBlob jest przekazywany jako dane wejściowe do usługi internetowej przy użyciu właściwości webServiceInput JSON. Obiekt DecisionTreeResultBlob jest przekazywany jako dane wyjściowe do usługi sieci Web przy użyciu właściwości JSON webServiceOutputs.

Ważne

Jeśli usługa internetowa przyjmuje wiele danych wejściowych, użyj właściwości webServiceInputs zamiast funkcji webServiceInput. Zobacz sekcję Usługa sieci Web wymaga wielu danych wejściowych , aby zapoznać się z przykładem użycia właściwości webServiceInputs.

Zestawy danych, do których odwołuje się webServiceInputs/webServiceInputs i webServiceOutputs (w typWłaściwości) również muszą być uwzględnione w danych wejściowych i wyjściowych działania.

W eksperymencie programu Studio (wersja klasyczna) porty wejściowe i wyjściowe usługi internetowej oraz parametry globalne mają domyślne nazwy ("input1", "input2"), które można dostosować. Nazwy używane dla ustawień webServiceInputs, webServiceOutputs i globalParameters muszą być dokładnie zgodne z nazwami w eksperymentach. Przykładowy ładunek żądania można wyświetlić na stronie Pomocy dotyczącej wykonywania wsadowego dla punktu końcowego programu Studio (klasycznego), aby zweryfikować oczekiwane mapowanie.

{
  "name": "PredictivePipeline",
  "properties": {
    "description": "use AzureML model",
    "activities": [
      {
        "name": "MLActivity",
        "type": "AzureMLBatchExecution",
        "description": "prediction analysis on batch input",
        "inputs": [
          {
            "name": "DecisionTreeInputBlob"
          }
        ],
        "outputs": [
          {
            "name": "DecisionTreeResultBlob"
          }
        ],
        "linkedServiceName": "MyAzureMLLinkedService",
        "typeProperties":
        {
            "webServiceInput": "DecisionTreeInputBlob",
            "webServiceOutputs": {
                "output1": "DecisionTreeResultBlob"
            }
        },
        "policy": {
          "concurrency": 3,
          "executionPriorityOrder": "NewestFirst",
          "retry": 1,
          "timeout": "02:00:00"
        }
      }
    ],
    "start": "2016-02-13T00:00:00Z",
    "end": "2016-02-14T00:00:00Z"
  }
}

Uwaga

Tylko dane wejściowe i wyjściowe działania AzureMLBatchExecution można przekazać jako parametry do usługi sieci Web. Na przykład w powyższym fragmencie kodu JSON element DecisionTreeInputBlob jest danymi wejściowymi działania AzureMLBatchExecution, które jest przekazywane jako dane wejściowe do usługi internetowej za pośrednictwem parametru webServiceInput.

Przykład

W tym przykładzie użyto usługi Azure Storage do przechowywania zarówno danych wejściowych, jak i wyjściowych.

Zalecamy zapoznanie się z samouczkiem Tworzenie pierwszego potoku za pomocą usługi Data Factory przed przejściem do tego przykładu. Użyj Edytora fabryki danych, aby utworzyć artefakty usługi Data Factory (połączone usługi, zestawy danych, potok) w tym przykładzie.

  1. Utwórz połączoną usługę dla usługi Azure Storage. Jeśli pliki wejściowe i wyjściowe znajdują się na różnych kontach magazynu, potrzebne są dwie połączone usługi. Oto przykład JSON:

    {
      "name": "StorageLinkedService",
      "properties": {
        "type": "AzureStorage",
        "typeProperties": {
          "connectionString": "DefaultEndpointsProtocol=https;AccountName= [acctName];AccountKey=[acctKey]"
        }
      }
    }
    
  2. Utwórz wejściowy zestaw danych Azure Data Factory. W przeciwieństwie do innych zestawów danych usługi Data Factory te zestawy danych muszą zawierać wartości folderPath i fileName . Partycjonowania można użyć do spowodowania każdego wykonania wsadowego (każdego wycinka danych) do przetwarzania lub tworzenia unikatowych plików wejściowych i wyjściowych. Może być konieczne uwzględnienie niektórych działań nadrzędnych, aby przekształcić dane wejściowe w format pliku CSV i umieścić je na koncie magazynu dla każdego wycinka. W takim przypadku nie zostaną uwzględnione ustawienia zewnętrzne i externalData pokazane w poniższym przykładzie, a obiekt DecisionTreeInputBlob będzie wyjściowym zestawem danych innego działania.

    {
      "name": "DecisionTreeInputBlob",
      "properties": {
        "type": "AzureBlob",
        "linkedServiceName": "StorageLinkedService",
        "typeProperties": {
          "folderPath": "azuremltesting/input",
          "fileName": "in.csv",
          "format": {
            "type": "TextFormat",
            "columnDelimiter": ","
          }
        },
        "external": true,
        "availability": {
          "frequency": "Day",
          "interval": 1
        },
        "policy": {
          "externalData": {
            "retryInterval": "00:01:00",
            "retryTimeout": "00:10:00",
            "maximumRetry": 3
          }
        }
      }
    }
    

    Wejściowy plik CSV musi mieć wiersz nagłówka kolumny. Jeśli używasz działania kopiowania do tworzenia/przenoszenia pliku CSV do magazynu obiektów blob, ustaw właściwość ujścia blobWriterAddHeader na wartość true. Przykład:

    sink:
    {
      "type": "BlobSink",
      "blobWriterAddHeader": true
      }
    

    Jeśli plik CSV nie ma wiersza nagłówka, może zostać wyświetlony następujący błąd: Błąd w działaniu: Błąd podczas odczytywania ciągu. Nieoczekiwany token: StartObject. Ścieżka "", wiersz 1, pozycja 1.

  3. Utwórz wyjściowy zestaw danych Azure Data Factory. W tym przykładzie użyto partycjonowania w celu utworzenia unikatowej ścieżki wyjściowej dla każdego wykonania wycinka. Bez partycjonowania działanie spowoduje zastąpienie pliku.

    {
      "name": "DecisionTreeResultBlob",
      "properties": {
        "type": "AzureBlob",
        "linkedServiceName": "StorageLinkedService",
        "typeProperties": {
          "folderPath": "azuremltesting/scored/{folderpart}/",
          "fileName": "{filepart}result.csv",
          "partitionedBy": [
            {
              "name": "folderpart",
              "value": {
                "type": "DateTime",
                "date": "SliceStart",
                "format": "yyyyMMdd"
              }
            },
            {
              "name": "filepart",
              "value": {
                "type": "DateTime",
                "date": "SliceStart",
                "format": "HHmmss"
              }
            }
          ],
          "format": {
            "type": "TextFormat",
            "columnDelimiter": ","
          }
        },
        "availability": {
          "frequency": "Day",
          "interval": 15
        }
      }
    }
    
  4. Utwórz połączoną usługę typu : AzureMLLinkedService, podając klucz interfejsu API i adres URL wykonywania wsadowego modelu.

    {
      "name": "MyAzureMLLinkedService",
      "properties": {
        "type": "AzureML",
        "typeProperties": {
          "mlEndpoint": "https://[batch execution endpoint]/jobs",
          "apiKey": "[apikey]"
        }
      }
    }
    
  5. Na koniec utwórz potok zawierający działanie AzureMLBatchExecution . W czasie wykonywania potok wykonuje następujące kroki:

    1. Pobiera lokalizację pliku wejściowego z wejściowych zestawów danych.

    2. Wywołuje interfejs API wykonywania wsadowego programu Studio (wersja klasyczna)

    3. Kopiuje dane wyjściowe wykonywania wsadowego do obiektu blob podanego w wyjściowym zestawie danych.

      Uwaga

      Działanie AzureMLBatchExecution może mieć zero lub więcej danych wejściowych i co najmniej jedno wyjście.

      {
        "name": "PredictivePipeline",
        "properties": {
          "description": "use AzureML model",
          "activities": [
            {
              "name": "MLActivity",
              "type": "AzureMLBatchExecution",
              "description": "prediction analysis on batch input",
              "inputs": [
                {
                  "name": "DecisionTreeInputBlob"
                }
             	],
              "outputs": [
                {
                  "name": "DecisionTreeResultBlob"
                }
             	],
              "linkedServiceName": "MyAzureMLLinkedService",
              "typeProperties":
             	{
                "webServiceInput": "DecisionTreeInputBlob",
                "webServiceOutputs": {
                  "output1": "DecisionTreeResultBlob"
                }
             	},
              "policy": {
                "concurrency": 3,
                "executionPriorityOrder": "NewestFirst",
                "retry": 1,
                "timeout": "02:00:00"
              }
            }
          ],
          "start": "2016-02-13T00:00:00Z",
          "end": "2016-02-14T00:00:00Z"
        }
      }
      

      Zarówno daty rozpoczęcia , jak i zakończenia muszą mieć format ISO. Na przykład: 2014-10-14T16:32:41Z. Godzina zakończenia jest opcjonalna. Jeśli nie określisz wartości właściwości końcowej , zostanie ona obliczona jako "start + 48 godzin". Aby uruchomić potok na czas nieokreślony, określ wartość 9999-09-09 jako wartość właściwości końcowej . Szczegółowe informacje dotyczące właściwości kodu JSON znajdują się w artykule JSON Scripting Reference (Dokumentacja dotycząca skryptów JSON).

      Uwaga

      Określanie danych wejściowych dla działania AzureMLBatchExecution jest opcjonalne.

Scenariusz: Eksperymenty korzystające z modułów czytelnika/modułów zapisywania w celu odwoływania się do danych w różnych magazynach

Innym typowym scenariuszem podczas tworzenia eksperymentów w programie Studio (klasycznym) jest użycie modułów Czytelnik i Moduł zapisywania. Moduł czytnika służy do ładowania danych do eksperymentu, a moduł zapisywania służy do zapisywania danych z eksperymentów. Aby uzyskać szczegółowe informacje na temat modułów czytelnika i modułów zapisywania, zobacz Tematy dotyczące czytelnika i zapisywania w bibliotece MSDN.

W przypadku korzystania z modułów czytnika i modułów zapisywania warto użyć parametru usługi sieci Web dla każdej właściwości tych modułów czytelnika/modułu zapisywania. Te parametry sieci Web umożliwiają skonfigurowanie wartości podczas wykonywania. Można na przykład utworzyć eksperyment z modułem czytelnika, który używa Azure SQL Database: XXX.database.windows.net. Po wdrożeniu usługi internetowej chcesz umożliwić konsumentom usługi internetowej określenie innego logicznego serwera SQL o nazwie YYY.database.windows.net. Możesz użyć parametru usługi sieci Web, aby umożliwić skonfigurowanie tej wartości.

Uwaga

Dane wejściowe i wyjściowe usługi sieci Web różnią się od parametrów usługi sieci Web. W pierwszym scenariuszu pokazano, jak można określić dane wejściowe i wyjściowe dla usługi internetowej Studio (klasycznej). W tym scenariuszu przekazujesz parametry dla usługi sieci Web, która odpowiada właściwościom modułów czytnika/modułów zapisywania.

Przyjrzyjmy się scenariuszowi używania parametrów usługi sieci Web. Masz wdrożona usługa sieci Web Studio (klasyczna), która używa modułu czytnika do odczytywania danych z jednego ze źródeł danych obsługiwanych przez program Studio (klasyczny) (na przykład: Azure SQL Database). Po wykonaniu wykonywania wsadowego wyniki są zapisywane przy użyciu modułu zapisywania (Azure SQL Database). W eksperymentach nie zdefiniowano żadnych danych wejściowych i wyjściowych usługi internetowej. W takim przypadku zalecamy skonfigurowanie odpowiednich parametrów usługi internetowej dla modułów czytnika i modułów zapisywania. Ta konfiguracja umożliwia skonfigurowanie modułów czytnika/zapisywania podczas korzystania z działania AzureMLBatchExecution. Parametry usługi sieci Web można określić w sekcji globalParameters w formacie JSON działania w następujący sposób.

"typeProperties": {
    "globalParameters": {
        "Param 1": "Value 1",
        "Param 2": "Value 2"
    }
}

Funkcje usługi Data Factory można również używać w przekazywaniu wartości parametrów usługi internetowej, jak pokazano w poniższym przykładzie:

"typeProperties": {
	"globalParameters": {
       "Database query": "$$Text.Format('SELECT * FROM myTable WHERE timeColumn = \\'{0:yyyy-MM-dd HH:mm:ss}\\'', Time.AddHours(WindowStart, 0))"
    }
}

Uwaga

Parametry usługi sieci Web są uwzględniane w wielkości liter, dlatego upewnij się, że nazwy określone w kodzie JSON działania są zgodne z parametrami udostępnianymi przez usługę sieci Web.

Używanie modułu Czytelnik do odczytywania danych z wielu plików w usłudze Azure Blob

Potoki danych big data z działaniami, takimi jak Pig i Hive, mogą tworzyć co najmniej jeden plik wyjściowy bez rozszerzeń. Na przykład po określeniu zewnętrznej tabeli Hive dane dla zewnętrznej tabeli Hive mogą być przechowywane w usłudze Azure Blob Storage o następującej nazwie 000000_0. Moduł czytelnika można użyć w eksperymencie, aby odczytać wiele plików i użyć ich do przewidywania.

W przypadku korzystania z modułu czytelnika w eksperymencie klasycznym (klasycznym) można określić obiekt blob platformy Azure jako dane wejściowe. Pliki w usłudze Azure Blob Storage mogą być plikami wyjściowymi (na przykład: 000000_0), które są tworzone przez skrypt pig i Hive uruchomiony w usłudze HDInsight. Moduł czytnika umożliwia odczytywanie plików (bez rozszerzeń) przez skonfigurowanie ścieżki do kontenera, katalogu/obiektu blob. Ścieżka do kontenera wskazuje kontener i katalog/obiekt blob do folderu zawierającego pliki, jak pokazano na poniższej ilustracji. Gwiazdka, która ma wartość *) określa, że wszystkie pliki w kontenerze/folderze (czyli dane/zagregowane dane/rok=2014/miesiąc-6/*) są odczytywane w ramach eksperymentu.

Właściwości obiektu blob platformy Azure

Przykład

Potok z działaniem AzureMLBatchExecution z parametrami usługi internetowej

{
  "name": "MLWithSqlReaderSqlWriter",
  "properties": {
    "description": "ML Studio (classic) model with sql azure reader/writer",
    "activities": [
      {
        "name": "MLSqlReaderSqlWriterActivity",
        "type": "AzureMLBatchExecution",
        "description": "test",
        "inputs": [
          {
            "name": "MLSqlInput"
          }
        ],
        "outputs": [
          {
            "name": "MLSqlOutput"
          }
        ],
        "linkedServiceName": "MLSqlReaderSqlWriterDecisionTreeModel",
        "typeProperties":
        {
            "webServiceInput": "MLSqlInput",
            "webServiceOutputs": {
                "output1": "MLSqlOutput"
            }
              "globalParameters": {
                "Database server name": "<myserver>.database.windows.net",
                "Database name": "<database>",
                "Server user account name": "<user name>",
                "Server user account password": "<password>"
              }
        },
        "policy": {
          "concurrency": 1,
          "executionPriorityOrder": "NewestFirst",
          "retry": 1,
          "timeout": "02:00:00"
        },
      }
    ],
    "start": "2016-02-13T00:00:00Z",
    "end": "2016-02-14T00:00:00Z"
  }
}

W powyższym przykładzie JSON:

  • Wdrożona usługa sieci Web studio (klasyczna) używa czytnika i modułu zapisywania do odczytu/zapisu danych z/do bazy danych Azure SQL. Ta usługa sieci Web uwidacznia następujące cztery parametry: nazwa serwera bazy danych, nazwa bazy danych, nazwa konta użytkownika serwera i hasło konta użytkownika serwera.
  • Zarówno daty rozpoczęcia , jak i zakończenia muszą mieć format ISO. Na przykład: 2014-10-14T16:32:41Z. Godzina zakończenia jest opcjonalna. Jeśli nie określisz wartości właściwości końcowej , zostanie ona obliczona jako "start + 48 godzin". Aby uruchomić potok na czas nieokreślony, określ wartość 9999-09-09 jako wartość właściwości końcowej . Szczegółowe informacje dotyczące właściwości kodu JSON znajdują się w artykule JSON Scripting Reference (Dokumentacja dotycząca skryptów JSON).

Inne scenariusze

Usługa sieci Web wymaga wielu danych wejściowych

Jeśli usługa internetowa przyjmuje wiele danych wejściowych, użyj właściwości webServiceInputs zamiast za pomocą funkcji webServiceInput. Zestawy danych, do których odwołuje się webServiceInputs , również muszą być uwzględnione w danych wejściowych działania.

W eksperymencie ML Studio (klasycznym) porty wejściowe i wyjściowe usługi internetowej oraz parametry globalne mają nazwy domyślne ("input1", "input2"), które można dostosować. Nazwy używane dla parametrów webServiceInputs, webServiceOutputs i globalParameters muszą być dokładnie zgodne z nazwami w eksperymentach. Przykładowy ładunek żądania można wyświetlić na stronie Pomocy dotyczącej wykonywania usługi Batch dla punktu końcowego programu Studio (klasycznego), aby zweryfikować oczekiwane mapowanie.

{
    "name": "PredictivePipeline",
    "properties": {
        "description": "use AzureML model",
        "activities": [{
            "name": "MLActivity",
            "type": "AzureMLBatchExecution",
            "description": "prediction analysis on batch input",
            "inputs": [{
                "name": "inputDataset1"
            }, {
                "name": "inputDataset2"
            }],
            "outputs": [{
                "name": "outputDataset"
            }],
            "linkedServiceName": "MyAzureMLLinkedService",
            "typeProperties": {
                "webServiceInputs": {
                    "input1": "inputDataset1",
                    "input2": "inputDataset2"
                },
                "webServiceOutputs": {
                    "output1": "outputDataset"
                }
            },
            "policy": {
                "concurrency": 3,
                "executionPriorityOrder": "NewestFirst",
                "retry": 1,
                "timeout": "02:00:00"
            }
        }],
        "start": "2016-02-13T00:00:00Z",
        "end": "2016-02-14T00:00:00Z"
    }
}

Usługa sieci Web nie wymaga danych wejściowych

Usługi sieci Web wykonywania wsadowego ml Studio (klasyczne) mogą służyć do uruchamiania dowolnych przepływów pracy, na przykład skryptów języka R lub Python, które mogą nie wymagać żadnych danych wejściowych. Można też skonfigurować eksperyment za pomocą modułu Czytelnik, który nie uwidacznia żadnych parametrów globalnych. W takim przypadku działanie AzureMLBatchExecution zostanie skonfigurowane w następujący sposób:

{
    "name": "scoring service",
    "type": "AzureMLBatchExecution",
    "outputs": [
        {
            "name": "myBlob"
        }
    ],
    "typeProperties": {
        "webServiceOutputs": {
            "output1": "myBlob"
        }
     },
    "linkedServiceName": "mlEndpoint",
    "policy": {
        "concurrency": 1,
        "executionPriorityOrder": "NewestFirst",
        "retry": 1,
        "timeout": "02:00:00"
    }
},

Usługa sieci Web nie wymaga danych wejściowych/wyjściowych

Usługa sieci Web wykonywania wsadowego w programie ML Studio (klasyczna) może nie mieć skonfigurowanych żadnych danych wyjściowych usługi sieci Web. W tym przykładzie nie ma żadnych danych wejściowych ani wyjściowych usługi sieci Web ani żadnych parametrów globalnych. Nadal istnieją dane wyjściowe skonfigurowane dla samego działania, ale nie są podane jako webServiceOutput.

{
    "name": "retraining",
    "type": "AzureMLBatchExecution",
    "outputs": [
        {
            "name": "placeholderOutputDataset"
        }
    ],
    "typeProperties": {
     },
    "linkedServiceName": "mlEndpoint",
    "policy": {
        "concurrency": 1,
        "executionPriorityOrder": "NewestFirst",
        "retry": 1,
        "timeout": "02:00:00"
    }
},

Usługa sieci Web używa czytelników i pisarzy, a działanie jest uruchamiane tylko wtedy, gdy inne działania zakończyły się pomyślnie

Moduły zapisywania i czytnika usług internetowych programu ML Studio (klasycznego) mogą być skonfigurowane do uruchamiania z użyciem lub bez żadnych parametrów globalnych. Jednak możesz chcieć osadzić wywołania usługi w potoku, który używa zależności zestawu danych do wywołania usługi tylko wtedy, gdy niektóre nadrzędne przetwarzanie zostało zakończone. Możesz również wyzwolić inną akcję po zakończeniu wykonywania wsadowego przy użyciu tego podejścia. W takim przypadku można wyrazić zależności przy użyciu danych wejściowych i wyjściowych działań bez nazewnictwa żadnego z nich jako danych wejściowych lub wyjściowych usługi sieci Web.

{
    "name": "retraining",
    "type": "AzureMLBatchExecution",
    "inputs": [
        {
            "name": "upstreamData1"
        },
        {
            "name": "upstreamData2"
        }
    ],
    "outputs": [
        {
            "name": "downstreamData"
        }
    ],
    "typeProperties": {
     },
    "linkedServiceName": "mlEndpoint",
    "policy": {
        "concurrency": 1,
        "executionPriorityOrder": "NewestFirst",
        "retry": 1,
        "timeout": "02:00:00"
    }
},

Wnioski są następujące:

  • Jeśli punkt końcowy eksperymentu używa elementu webServiceInput: jest reprezentowany przez zestaw danych obiektów blob i jest uwzględniany w danych wejściowych działań i właściwości webServiceInput. W przeciwnym razie właściwość webServiceInput zostanie pominięta.
  • Jeśli punkt końcowy eksperymentu używa składników webServiceOutput: są one reprezentowane przez zestawy danych obiektów blob i są uwzględniane w danych wyjściowych działań i we właściwości webServiceOutputs. Dane wyjściowe działania i webServiceOutputs są mapowane według nazwy poszczególnych danych wyjściowych w eksperymencie. W przeciwnym razie właściwość webServiceOutputs zostanie pominięta.
  • Jeśli punkt końcowy eksperymentu uwidacznia parametry globalne, są one podane we właściwości globalParameters działania jako pary klucz, wartości. W przeciwnym razie właściwość globalParameters zostanie pominięta. Klucze są uwzględniane w wielkości liter. Azure Data Factory funkcje mogą być używane w wartościach.
  • Dodatkowe zestawy danych mogą być uwzględniane we właściwościach Dane wejściowe i dane wyjściowe działania bez przywoływanie w typie działaniaWłaściwości. Te zestawy danych zarządzają wykonywaniem przy użyciu zależności wycinka, ale w przeciwnym razie są ignorowane przez działanie AzureMLBatchExecution.

Aktualizowanie modeli przy użyciu działania aktualizacji zasobu

Po zakończeniu ponownego trenowania zaktualizuj usługę internetową oceniającą (eksperyment predykcyjny uwidoczniony jako usługa internetowa) przy użyciu nowo wytrenowanego modelu przy użyciu działania aktualizacji zasobu usługi ML Studio (klasycznej). Aby uzyskać szczegółowe informacje, zobacz Aktualizowanie modeli przy użyciu aktualizacji działania zasobu .

Moduły czytelnika i modułów zapisywania

Typowym scenariuszem korzystania z parametrów usługi sieci Web jest użycie Azure SQL Czytelników i pisarzy. Moduł czytnika służy do ładowania danych do eksperymentu z usług zarządzania danymi poza programem Studio (wersja klasyczna). Moduł zapisywania polega na zapisywaniu danych z eksperymentów w usługach zarządzania danymi poza programem Studio (klasycznym).

Aby uzyskać szczegółowe informacje o usłudze Azure Blob/Azure SQL czytelnika/zapisywania, zobacz Tematy czytelnika i zapisywania w bibliotece MSDN. W przykładzie w poprzedniej sekcji użyto czytnika obiektów blob platformy Azure i modułu zapisywania obiektów blob platformy Azure. W tej sekcji omówiono używanie Azure SQL czytelnika i Azure SQL zapisywania.

Często zadawane pytania

P: Mam wiele plików generowanych przez potoki danych big data. Czy mogę użyć działania AzureMLBatchExecution do pracy ze wszystkimi plikami?

Odpowiedź: tak. Aby uzyskać szczegółowe informacje, zobacz moduł Using a Reader to read data from multiple files in Azure Blob (Używanie czytnika do odczytywania danych z wielu plików w usłudze Azure Blob ).

Działanie oceniania wsadowego w usłudze ML Studio (wersja klasyczna)

Jeśli używasz działania AzureMLBatchScoring do integracji z programem ML Studio (wersja klasyczna), zalecamy użycie najnowszego działania AzureMLBatchExecution .

Działanie AzureMLBatchExecution zostało wprowadzone w wersji zestawu Azure SDK z sierpnia 2015 r. i Azure PowerShell.

Jeśli chcesz kontynuować korzystanie z działania AzureMLBatchScoring, kontynuuj czytanie tej sekcji.

Działanie oceniania wsadowego w usłudze ML Studio (wersja klasyczna) przy użyciu usługi Azure Storage na potrzeby danych wejściowych/wyjściowych

{
  "name": "PredictivePipeline",
  "properties": {
    "description": "use AzureML model",
    "activities": [
      {
        "name": "MLActivity",
        "type": "AzureMLBatchScoring",
        "description": "prediction analysis on batch input",
        "inputs": [
          {
            "name": "ScoringInputBlob"
          }
        ],
        "outputs": [
          {
            "name": "ScoringResultBlob"
          }
        ],
        "linkedServiceName": "MyAzureMLLinkedService",
        "policy": {
          "concurrency": 3,
          "executionPriorityOrder": "NewestFirst",
          "retry": 1,
          "timeout": "02:00:00"
        }
      }
    ],
    "start": "2016-02-13T00:00:00Z",
    "end": "2016-02-14T00:00:00Z"
  }
}

Parametry usługi sieci Web

Aby określić wartości parametrów usługi sieci Web, dodaj sekcję typeProperties do sekcji AzureMLBatchScoringActivity w potoku JSON, jak pokazano w poniższym przykładzie:

"typeProperties": {
    "webServiceParameters": {
        "Param 1": "Value 1",
        "Param 2": "Value 2"
    }
}

Funkcje usługi Data Factory można również używać w przekazywaniu wartości parametrów usługi internetowej, jak pokazano w poniższym przykładzie:

"typeProperties": {
    "webServiceParameters": {
       "Database query": "$$Text.Format('SELECT * FROM myTable WHERE timeColumn = \\'{0:yyyy-MM-dd HH:mm:ss}\\'', Time.AddHours(WindowStart, 0))"
    }
}

Uwaga

Parametry usługi sieci Web są uwzględniane w wielkości liter, dlatego upewnij się, że nazwy określone w kodzie JSON działania są zgodne z parametrami udostępnianymi przez usługę sieci Web.

Zobacz też