Zarządzanie kosztami usługi Feature Store

Na tej stronie opisano, w jaki sposób usługa Azure Databricks Feature Store nalicza opłaty za zasoby obliczeniowe oraz jak monitorować i optymalizować te koszty. Usługa Feature Store jest rozliczana po kosztach: płacisz za bazowe bezserwerowe zasoby obliczeniowe, magazyn online i infrastrukturę serwowania, bez dodatkowego narzutu.

  • Materializacja cech działa w modelu obliczeń bezserwerowych i pojawia się na rozliczeniu pod pozycją FEATURE_STORE, rozliczana według tej samej stawki co zadania bezserwerowe i potoki Lakeflow.
  • Opłaty za punkty końcowe obsługujące funkcje są naliczane względem jednostki SKU obsługującej model.
  • Sklepy internetowe są rozliczane na podstawie mocy obliczeniowej Lakebase, z uwzględnieniem liczby jednostek pojemności (CU) i liczby replik.

Rozliczanie usługi Feature Store

Materializacja atrybutów

Gdy materializujesz widoki cech, usługa Azure Databricks uruchamia bezserwerowy pipeline służący do obliczania i zapisywania wartości cech w lokalizacjach docelowych offline i online. Obejmuje to zadania wsadowej materializacji, potoki strumieniowe i pobieranie danych za pomocą platformy Kafka. Te potoki działają w oparciu o bezserwerowe zasoby obliczeniowe i są rozliczane po kosztach, z mnożnikiem 1x i bez dodatkowej marży względem bazowej platformy bezserwerowej.

W tabeli systemowej rozliczanego użycia użycie materializacji jest wyświetlane z wartością billing_origin_product ustawioną na FEATURE_STORE oraz z bezserwerową jednostką SKU zasobów obliczeniowych (JOBS_SERVERLESS_COMPUTE, z prefiksem zawierającym warstwę i region obszaru roboczego). Użycie to is_serverless i is_photon, a usage_metadata obejmuje data_source (DELTA_TABLE_SOURCE lub KAFKA_SOURCE) oraz operation (FEATURE_MATERIALIZATION lub KAFKA_INGESTION), dzięki czemu można podzielić koszty na obciążenia wsadowe i strumieniowe.

Aby zmniejszyć koszt obliczeń, pogrupuj funkcje, które współdzielą miejsce docelowe offline, miejsce docelowe online i wyzwalacz, w jedno wywołanie materialize_features, tak aby były uruchamiane w jednym potoku. Zobacz Materialize Feature Views. Aby uzyskać więcej informacji na temat sposobu naliczania opłat za zasoby obliczeniowe bezserwerowe, zobacz Run your Lakeflow Jobs with serverless compute for workflows (Uruchamianie zadań lakeflow z bezserwerowymi obliczeniami dla przepływów pracy).

Funkcje obsługujące punkty końcowe

Funkcje obsługujące punkty końcowe obsługują funkcje wstępnie skompilowane i na żądanie dla aplikacji w czasie rzeczywistym. Działają w usłudze Model Serving i są rozliczane w ramach jednostki SKU usługi Model Serving (SERVERLESS_REAL_TIME_INFERENCE), tak samo jak punkty końcowe obsługi modeli niestandardowych. Opłaty zależą od zasobów obliczeniowych udostępnianych przez punkt końcowy w celu obsługi ruchu żądań. Zobacz tabele funkcji Serve oraz stronę cen Model Serving.

Sklepy internetowe

Sklepy online obsługują funkcje z małym opóźnieniem w przypadku wnioskowania online. Magazyn online Azure Databricks jest obsługiwany przez usługę Lakebase i jest rozliczany względem zasobów obliczeniowych usługi Lakebase na podstawie jednostek wydajności (CU) i replik do odczytu, które aprowizuje. Każda jednostka wydajności przydziela instancji zasoby obliczeniowe, pamięć i przestrzeń dyskową, a także umożliwia dodanie replik do odczytu w celu zwiększenia dostępności i przepustowości odczytu. Zobacz Databricks Online Feature Stores, aby uzyskać wskazówki dotyczące ustalania rozmiaru, Zarządzanie zasobami obliczeniowymi, aby dowiedzieć się, jak jednostki pojemności przekładają się na zasoby obliczeniowe, oraz stronę cennika usługi Lakebase.

Koszty atrybutów z tagami i politykami użycia bezserwerowego

Ważne

Ta funkcja jest dostępna w prywatnej wersji zapoznawczej. Aby ją wypróbować, skontaktuj się z osobą kontaktową usługi Azure Databricks.

Podczas tworzenia materializacji lub obiektu Stream przekaż niestandardowe tagi, zasady użycia w modelu serverless albo oba te elementy. Azure Databricks przypisuje je do zadania lub potoku Lakeflow, które tworzy, dzięki czemu powiązane z nimi koszty zawierają przypisaną atrybucję w tabeli systemowej rozliczanego użycia. Aby utworzyć zasady i uzyskać ich identyfikator, zobacz Tworzenie zasad użycia bezserwerowego.

Obie wartości są stosowane podczas tworzenia zadania lub potoku. Aby przypisać istniejące obliczenia w inny sposób, stwórz nową materializację lub strumień.

Obliczenia materializacji atrybutów

Przekażmy tags, budget_policy_id, lub oba do materialize_features:

materialized = fe.materialize_features(
    features=features,
    offline_config=offline_config,
    trigger=trigger,
    tags={"team": "ml-platform", "project": "churn"},
    budget_policy_id="555e8888-e999-4444-a777-446655440000",
)

Pełny podpis można znaleźć w sekcji Materialize Feature Views.

Obliczenia zarządzane przez pobieranie atrybutów

Dla strumienia ustaw tags i budget_policy_id w obiekcie IngestionConfig, który przekazujesz do create_stream:

from databricks.feature_engineering.entities import IngestionConfig, IngestionDestination

ingestion_config = IngestionConfig(
    ingestion_destination=IngestionDestination(
        delta_table_name="my_catalog.my_schema.events_ingestion"
    ),
    tags={"team": "ml-platform", "project": "churn"},
    budget_policy_id="555e8888-e999-4444-a777-446655440000",
)

Informacje o pozostałych opcjach pozyskiwania danych znajdziesz w sekcji Konfigurowanie strumienia.

Obliczanie atrybucji ma zastosowanie do

Tagi i zasady korzystania z bezserwerowości mają zastosowanie do zasobów obliczeniowych, które materializują cechy danych lub obsługują import danych strumienia: zadania materializacji wsadowej, potoku Lakeflow do przetwarzania strumieniowego oraz zadania koordynującego jego działanie, a także potoku Lakeflow do importu danych strumienia wraz z zadaniami wypełniania w przód i uzupełniania historycznego. Gdy materializujesz się do nowej tabeli online, stosują one także do pipeline'u Lakeflow, który utrzymuje tę tabelę w synchronizacji.

Nie dotyczą one samego sklepu internetowego. Aby przypisać sklepowi internetowemu własne zasoby obliczeniowe, ustaw dla niego politykę korzystania z architektury bezserwerowej. Zobacz Repozytoria funkcji online Databricks.

Limitations

  • Materializowanie do tabeli online, która już istnieje, nie stosuje ani tags, ani budget_policy_id i nie zwraca błędu. Potok Lakeflow, który utrzymuje tę tabelę zsynchronizowaną, zachowuje tagi, z którymi został utworzony. Aby zmienić atrybucję, zmaterializuj dane w nowej tabeli w trybie online.
  • Możesz przekazać maksymalnie 25 tagów.
  • Klucz tagu może mieć do 127 znaków, a wartość tagu do 65 535 znaków. Żadne z nich nie może być puste.
  • Klucz tagowy nie może zaczynać się od .databricks: Ten prefiks jest zarezerwowany, a czek ignoruje przypadki.

Monitorowanie użycia i kosztów

Koszty usługi Feature Store można monitorować przy użyciu tabeli systemowej rozliczanego użycia, system.billing.usage. Użycie materializacji jest oznaczane za pomocą billing_origin_product = 'FEATURE_STORE':

SELECT
  usage_date,
  usage_metadata.data_source,
  usage_metadata.operation,
  usage_metadata.job_id,
  usage_metadata.dlt_pipeline_id,
  identity_metadata.run_as,
  sum(usage_quantity) AS dbus,
  usage_unit
FROM system.billing.usage
WHERE billing_origin_product = 'FEATURE_STORE'
GROUP BY ALL;

Użyj funkcji usage_metadata.data_source i operation , aby podzielić koszty według partii i przesyłania strumieniowego. Pola usage_metadata.job_id i usage_metadata.dlt_pipeline_id identyfikują konkretne zadanie materializacji lub pipeline, które utworzyły każdy wiersz kosztowy, dzięki czemu można grupować według tych pól, aby przypisywać koszty do poszczególnych pipeline’ów.

Kolumna custom_tags zawiera tagi, które przekazałeś, wraz z tagami przypisanymi przez zasady użycia środowiska serverless, dzięki czemu możesz grupować lub filtrować według custom_tags['<key>'], aby przypisać koszty. Informacje o tym, jak tagi zasad trafiają do rekordów rozliczeniowych, znajdziesz w artykule Analiza tagów zasad użycia technologii bezserwerowej w rekordach rozliczeniowych.

Obsługa funkcji i koszty sklepu online są śledzone oddzielnie:

  • Punkty końcowe obsługujące funkcje są wyświetlane w ramach jednostki SKU obsługującej model. Zobacz Monitorowanie kosztów obsługi modelu.
  • Zasoby obliczeniowe sklepu online pojawiają się w bezserwerowej jednostce SKU usługi Lakebase (baza danych).

Aby uzyskać szczegółowe informacje na temat tabeli rozliczanego użycia i sposobu wykonywania względem niej zapytań, zobacz Billable usage system table reference (Dokumentacja tabeli systemu rozliczanego użycia).

Najlepsze rozwiązania dotyczące optymalizacji kosztów

  • Grupowanie funkcji w udostępnionych potokach materializacji: funkcje, które współużytkują miejsce docelowe w trybie offline, miejsce docelowe online i wyzwalacz, mogą zmaterializować się w jednym potoku, co zmniejsza liczbę płatnych potoków.
  • Wykorzystanie sklepów online: możesz opublikować wiele tabel cech w jednym sklepie online. Do programowania, testowania i szkolenia używaj jednego sklepu internetowego we wszystkich projektach, zamiast tworzyć oddzielne sklepy.
  • Odpowiedni rozmiar pojemności sklepu online: zacznij od małej jednostki pojemności na potrzeby testowania i skalowania w górę lub w dół na podstawie wydajności i kosztów.
  • Usuwanie zasobów, które nie są używane: sklepy online stale generują koszty. Usuń sklepy internetowe i potoki przetwarzania, które nie są już potrzebne.
  • Wybierz odpowiedni wyzwalacz materializacji: rzadziej uruchamiane wyzwalacze według harmonogramu kosztują mniej niż ciągła lub częsta ponowna materializacja. Dopasuj wyzwalanie do tego, jak aktualne muszą być Twoje funkcje.

Dodatkowe zasoby

  • Ostatnia aktualizacja o