Włącz wnioskowanie tables na punktach końcowych obsługujących model za pomocą interfejsu API

Artykuł
12/27/2024

Ważne

Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

W tym artykule wyjaśniono, jak używać interfejsu API usługi Databricks do włączania wnioskowania tables dla modelu obsługującego punkt końcowy. Aby uzyskać ogólne informacje na temat korzystania z tableswnioskowania, w tym sposobu włączania ich przy użyciu interfejsu użytkownika usługi Databricks, zobacz Wnioskowanie tables na potrzeby monitorowania i debugowania modeli.

Wnioskowanie można włączyć tables podczas tworzenia nowego punktu końcowego lub w istniejącym punkcie końcowym. Databricks zaleca utworzenie punktu końcowego z jednostką usługi, aby wnioskowanie table nie zostało zakłócone w przypadku usunięcia użytkownika, który utworzył punkt końcowy, z obszaru roboczego.

Właścicielem tables wnioskowania jest użytkownik, który utworzył punkt końcowy. Wszystkie listy kontroli dostępu (ACL) na table są zgodne ze standardowymi uprawnieniami Catalog systemu Unity i mogą być modyfikowane przez właściciela table.

Wymagania

Twój obszar roboczy musi mieć włączoną funkcję Unity Catalog.
Zarówno twórca punktu końcowego, jak i modyfikator musi mieć uprawnienie Może zarządzać w punkcie końcowym. Zobacz Listy kontroli dostępu.
Zarówno twórca punktu końcowego, jak i modyfikator muszą mieć następujące uprawnienia w Catalogaparatu Unity:
- USE CATALOG uprawnienia do catalogokreślonego.
- USE SCHEMA uprawnienia w odniesieniu do określonego schema.
- CREATE TABLE uprawnienia w schema.

Włącz wnioskowanie tables podczas tworzenia punktu końcowego przy użyciu API

Podczas tworzenia punktu końcowego można włączyć wnioskowanie tables dla punktu końcowego przy użyciu interfejsu API. Aby uzyskać instrukcje dotyczące tworzenia punktu końcowego, zobacz Tworzenie niestandardowych punktów końcowych obsługujących model.

W interfejsie API treść żądania musi auto_capture_config określać:

Unity Catalogcatalog: ciąg znaków reprezentujący catalog do przechowywania table
Aparat Unity Catalogschema: ciąg reprezentujący schema do przechowywania table
(opcjonalnie) table prefiks: ciąg używany jako prefiks dla nazwy wnioskowania table. Jeśli nie zostanie określona, zostanie użyta nazwa punktu końcowego.
(opcjonalnie) włączone: wartość logiczna używana do włączania lub wyłączania wnioskowania tables. To prawda domyślnie.

Po określeniu prefiksów catalog, schemai opcjonalnie table, table zostanie utworzony w <catalog>.<schema>.<table_prefix>_payload. Ta table automatycznie tworzy zarządzane CatalogtableUnity. Właścicielem table jest użytkownik, który tworzy punkt końcowy.

Uwaga

Określanie istniejącego table nie jest obsługiwane, ponieważ wnioskowanie table jest zawsze tworzone automatycznie podczas tworzenia punktu końcowego lub aktualizacji punktów końcowych.

Ostrzeżenie

Wnioskowanie table może ulec uszkodzeniu, jeśli wykonasz dowolną z następujących czynności:

Zmień tableschema.
Zmień nazwę table.
Usuń table.
Utracić uprawnienia do Unity Catalog,catalog lub schema.

W tym przypadku auto_capture_config stanu punktu końcowego pokazuje stan FAILED ładunku table. W takim przypadku należy utworzyć nowy punkt końcowy, aby nadal korzystać z wnioskowania tables.

W poniższym przykładzie pokazano, jak włączyć wnioskowanie tables podczas tworzenia punktu końcowego.

POST /api/2.0/serving-endpoints

{
  "name": "feed-ads",
  "config":
  {
    "served_entities": [
      {
       "entity_name": "ads1",
       "entity_version": "1",
       "workload_size": "Small",
       "scale_to_zero_enabled": true
      }
    ],
    "auto_capture_config":
    {
       "catalog_name": "ml",
       "schema_name": "ads",
       "table_name_prefix": "feed-ads-prod"
    }
  }
}

Odpowiedź wygląda następująco:

{
  "name": "feed-ads",
  "creator": "customer@example.com",
  "creation_timestamp": 1666829055000,
  "last_updated_timestamp": 1666829055000,
  "state": {
    "ready": "NOT_READY",
    "config_update": "IN_PROGRESS"
  },
  "pending_config": {
    "start_time": 1666718879000,
    "served_entities": [
      {
        "name": "ads1-1",
        "entity_name": "ads1",
        "entity_version": "1",
        "workload_size": "Small",
        "scale_to_zero_enabled": true,
        "state": {
          "deployment": "DEPLOYMENT_CREATING",
          "deployment_state_message": "Creating"
        },
        "creator": "customer@example.com",
        "creation_timestamp": 1666829055000
    }
   ],
   "config_version": 1,
   "traffic_config": {
     "routes": [
       {
         "served_model_name": "ads1-1",
         "traffic_percentage": 100
       }
      ]
   },
   "auto_capture_config": {
     "catalog_name": "ml",
     "schema_name": "ads",
     "table_name_prefix": "feed-ads-prod",
     "state": {
       "payload_table": {
         "name": "feed-ads-prod_payload"
       }
     },
     "enabled": true
   }
  },
  "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "permission_level": "CAN_MANAGE"
}

Po włączeniu logowania do wnioskowania tables poczekaj, aż punkt końcowy będzie gotowy. Następnie możesz zacząć go wywoływać.

Po utworzeniu wnioskowania table, system powinien zająć się schema ewolucji i dodawaniem danych.

Następujące operacje nie mają wpływu na integralność table:

Uruchamianie OPTIMIZE, ANALIZUJ i VACUUM na table.
Usuwanie starych nieużywanych danych.

Jeśli nie określisz auto_capture_configelementu , domyślnie konfiguracja ustawień z poprzedniej wersji konfiguracji zostanie ponownie użyta. Jeśli na przykład wnioskowanie tables zostało już włączone, te same ustawienia są używane na następnym punkcie końcowym update, albo jeśli wnioskowanie tables zostało wyłączone, to nadal jest wyłączone.

{
  "served_entities": [
    {
      "name":"current",
      "entity_name":"model-A",
      "entity_version":"1",
      "workload_size":"Small",
      "scale_to_zero_enabled":true
    }
  ],
  "auto_capture_config": {
    "enabled": false
  }
}

Włączanie wnioskowania tables w istniejącym punkcie końcowym przy użyciu interfejsu API

Możesz również włączyć wnioskowanie tables w istniejącym punkcie końcowym za pomocą API. Po włączeniu wnioskowania tables, wskazuj tę samą treść auto_capture_config w przyszłych wywołaniach API dla punktu końcowego update dla dalszego korzystania z wnioskowania tables.

Uwaga

Zmiana lokalizacji table po włączeniu wnioskowania tables nie jest obsługiwana.

PUT /api/2.0/serving-endpoints/{name}/config

{
  "served_entities": [
    {
      "name":"current",
      "entity_name":"model-A",
      "entity_version":"1",
      "workload_size":"Small",
      "scale_to_zero_enabled":true
    },
    {
      "name":"challenger",
      "entity_name":"model-B",
      "entity_version":"1",
      "workload_size":"Small",
      "scale_to_zero_enabled":true
    }
  ],
  "traffic_config":{
    "routes": [
      {
        "served_model_name":"current",
        "traffic_percentage":"50"
      },
      {
        "served_model_name":"challenger",
        "traffic_percentage":"50"
      }
    ]
  },
  "auto_capture_config":{
   "catalog_name": "catalog",
   "schema_name": "schema",
   "table_name_prefix": "my-endpoint"
  }
}

Wyłącz wnioskowanie tables

Podczas wyłączania wnioskowania tablesnie trzeba określać prefiksu catalog, schemalub table. Jedynym wymaganym polem jest enabled: false.

POST /api/2.0/serving-endpoints

{
  "name": "feed-ads",
  "config":{
    "served_entities": [
      {
       "entity_name": "ads1",
       "entity_version": "1",
       "workload_size": "Small",
       "scale_to_zero_enabled": true
      }
    ],
    "auto_capture_config":{
       "enabled": false
    }
  }
}

Aby ponownie włączyć wyłączone wnioskowanie table, postępuj zgodnie z instrukcjami w Włączanie wnioskowania tables w istniejącym punkcie końcowym. Możesz użyć tego samego table lub określić nowy table.

Następne kroki

Po włączeniu wnioskowania tablesmożna monitorować obsługiwane modele w modelu obsługującym punkt końcowy za pomocą usługi Databricks Lakehouse Monitoring. Aby uzyskać szczegółowe informacje, zobacz Workflow: Monitorowanie wydajności modelu przy użyciu wnioskowania tables.

Udostępnij za pośrednictwem