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 utworzyć nowych zasobów usługi Machine Learning Studio (klasycznej) (plan obszaru roboczego i usługi internetowej). Do 31 sierpnia 2024 r. możesz 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 wysokiego punktu widzenia odbywa się to w trzech krokach:

  1. Tworzenie eksperymentu szkoleniowego. Ten krok należy wykonać przy użyciu programu ML Studio (klasycznego). Studio (wersja klasyczna) to wspólne środowisko programistyczne, którego używasz do trenowania i testowania modelu analizy predykcyjnej przy użyciu danych szkoleniowych.
  2. Przekonwertuj go na eksperyment predykcyjny. Gdy model został wytrenowany przy użyciu istniejących danych i możesz go użyć do oceniania nowych danych, przygotujesz i usprawnisz eksperyment na potrzeby oceniania.
  3. Wdróż go 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 fro 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 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ługa Data Factory i usługa Machine Learning Studio (wersja klasyczna) razem

Azure Data Factory umożliwia łatwe tworzenie potoków korzystających z opublikowanej usługi internetowej ML Studio (klasycznej) na potrzeby 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 w programie Studio (klasycznym) 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 należy 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 studio (klasycznego), aby wywołać usługę internetową na potrzeby eksperymentu szkoleniowego. Zasadniczo można użyć działania Wykonywania wsadowego w programie Studio (klasycznym), aby wywołać zarówno usługę internetową trenowania, jak i usługę internetową oceniania.

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 .

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 (klasycznego). Poniżej przedstawiono kroki najwyższego poziomu:

  1. Utwórz połączoną usługę ML Studio (klasyczną). Potrzebne są następujące wartości:

    1. Identyfikator URI żądania dla interfejsu API wykonywania usługi Batch. 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 internetowa 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 z działaniem AzureMLBatchExecution. Działanie ma 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 JSON webServiceInput. 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 za pomocą 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łują się właściwości webServiceInputs webServiceInputs/ iwebServiceOutputs (w typIeWłaściwości), również muszą być uwzględnione w danych wejściowych i wyjściowych działania.

W eksperymencie 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": "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 niektórych innych zestawów danych usługi Data Factory te zestawy danych muszą zawierać zarówno wartości folderPath , jak i fileName . Partycjonowania można użyć do spowodowania każdego wykonania wsadowego (każdego wycinka danych) w celu przetworzenia lub wygenerowania 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 uwzględnisz ustawień zewnętrznych i zewnętrznych Danych pokazanych 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
          }
        }
      }
    }
    

    Plik csv danych wejściowych musi mieć wiersz nagłówka kolumny. Jeśli używasz działania kopiowania do tworzenia/przenoszenia pliku CSV do magazynu obiektów blob, należy ustawić 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: Ciąg odczytu błędu. 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 wartości 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żesz na przykład utworzyć eksperyment z modułem czytelnika, który używa wystąpienia bazy danych Azure SQL: XXX.database.windows.net. Po wdrożeniu usługi internetowej chcesz umożliwić konsumentom usługi internetowej określenie innego wystąpienia logicznego SQL Server 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 nad 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 w tej sekcji.

Działanie oceniania usługi Batch 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 internetowej, dodaj sekcję typeProperties do sekcji AzureMLBatchScoringActivity w pliku JSON potoku, 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

W parametrach usługi sieci Web jest rozróżniana wielkość liter, dlatego upewnij się, że nazwy określone w kodzie JSON działania są zgodne z nazwami udostępnianymi przez usługę sieci Web.

Zobacz też