Monitorowanie potoków Delta Live Tables

W tym artykule opisano, jak można używać wbudowanych funkcji monitorowania i obserwacji potoków tabel delta Live Tables, w tym pochodzenia danych, historii aktualizacji i raportowania jakości danych.

Większość danych monitorowania można przejrzeć ręcznie za pomocą interfejsu użytkownika szczegółów potoku. Niektóre zadania są łatwiejsze do wykonania przez wykonywanie zapytań dotyczących metadanych dziennika zdarzeń. Zobacz Co to jest dziennik zdarzeń tabel delta live?.

Jakie szczegóły potoku są dostępne w interfejsie użytkownika?

Wykres potoku jest wyświetlany natychmiast po pomyślnym uruchomieniu aktualizacji potoku. Strzałki reprezentują zależności między zestawami danych w potoku. Domyślnie na stronie szczegółów potoku jest wyświetlana najnowsza aktualizacja tabeli, ale możesz wybrać starsze aktualizacje z menu rozwijanego.

Wyświetlane szczegóły obejmują identyfikator potoku, biblioteki źródłowe, koszt obliczeniowy, wydanie produktu i kanał skonfigurowany dla potoku.

Aby wyświetlić tabelaryczny widok zestawów danych, kliknij kartę Lista . Widok Lista umożliwia wyświetlanie wszystkich zestawów danych w potoku reprezentowanych jako wiersz w tabeli i jest przydatne, gdy potok DAG jest zbyt duży, aby zwizualizować w widoku programu Graph . Zestawy danych wyświetlane w tabeli można kontrolować przy użyciu wielu filtrów, takich jak nazwa zestawu danych, typ i stan. Aby wrócić do wizualizacji DAG, kliknij pozycję Graf.

Użytkownik Uruchom jako jest właścicielem potoku, a aktualizacje potoku są uruchamiane z uprawnieniami tego użytkownika. Aby zmienić run as użytkownika, kliknij pozycję Uprawnienia i zmień właściciela potoku.

Jak można wyświetlić szczegóły zestawu danych?

Kliknięcie zestawu danych na wykresie potoku lub na liście zestawów danych powoduje wyświetlenie szczegółowych informacji o zestawie danych. Szczegóły obejmują schemat zestawu danych, metryki jakości danych i link z powrotem do kodu źródłowego, który definiuje zestaw danych.

Wyświetlanie historii aktualizacji

Aby wyświetlić historię i stan aktualizacji potoku, kliknij menu rozwijane Historia aktualizacji na górnym pasku.

Aby wyświetlić wykres, szczegóły i zdarzenia aktualizacji, wybierz aktualizację w menu rozwijanym. Aby powrócić do najnowszej aktualizacji, kliknij pozycję Pokaż najnowszą aktualizację.

Pobieranie powiadomień dotyczących zdarzeń potoku

Aby otrzymywać powiadomienia w czasie rzeczywistym dla zdarzeń potoku, takich jak pomyślne ukończenie aktualizacji potoku lub niepowodzenie aktualizacji potoku, dodaj opcję Dodaj powiadomienia e-mail dla zdarzeń potoku podczas tworzenia lub edytowania potoku.

Co to jest dziennik zdarzeń tabel delta live?

Dziennik zdarzeń usługi Delta Live Tables zawiera wszystkie informacje związane z potokiem, w tym dzienniki inspekcji, kontrole jakości danych, postęp potoku i pochodzenie danych. Dziennik zdarzeń umożliwia śledzenie, zrozumienie i monitorowanie stanu potoków danych.

Wpisy dziennika zdarzeń można wyświetlić w interfejsie użytkownika usługi Delta Live Tables, interfejsie API usługi Delta Live Tables lub bezpośrednio wysyłając zapytanie do dziennika zdarzeń. Ta sekcja koncentruje się na bezpośrednim wysyłaniu zapytań do dziennika zdarzeń.

Można również zdefiniować akcje niestandardowe do uruchamiania, gdy zdarzenia są rejestrowane, na przykład wysyłanie alertów z użyciem punktów zaczepienia zdarzeń.

Schemat dziennika zdarzeń

W poniższej tabeli opisano schemat dziennika zdarzeń. Niektóre z tych pól zawierają dane JSON, które wymagają analizowania w celu wykonywania niektórych zapytań, takich jak details pole. Usługa Azure Databricks obsługuje : operator do analizowania pól JSON. Zobacz operator : (znak dwukropka).

Pole	opis
id	Unikatowy identyfikator rekordu dziennika zdarzeń.
sequence	Dokument JSON zawierający metadane służące do identyfikowania i zamawiania zdarzeń.
origin	Dokument JSON zawierający metadane źródła zdarzenia, na przykład dostawca usług w chmurze, region dostawcy usług w chmurze, , lub, aby pokazać miejsce utworzenia potoku lub DBSQLWORKSPACE.pipeline_typepipeline_iduser_id
timestamp	Godzina zarejestrowania zdarzenia.
message	Czytelny dla człowieka komunikat opisujący zdarzenie.
level	Typ zdarzenia, na przykład INFO, WARN, ERRORlub METRICS.
error	Jeśli wystąpił błąd, szczegóły opisujące błąd.
details	Dokument JSON zawierający ustrukturyzowane szczegóły zdarzenia. Jest to pole podstawowe używane do analizowania zdarzeń.
event_type	Typ zdarzenia.
maturity_level	Stabilność schematu zdarzeń. Możliwe wartości to: * STABLE: Schemat jest stabilny i nie zmieni się. * NULL: Schemat jest stabilny i nie zmieni się. Wartość może być NULL widoczna, jeśli rekord został utworzony przed maturity_level dodaniu pola (wersja 2022.37). * EVOLVING: Schemat nie jest stabilny i może ulec zmianie. * DEPRECATED: Schemat jest przestarzały, a środowisko uruchomieniowe delta Live Tables może w dowolnym momencie przestać produkować to zdarzenie.

Wykonywanie zapytań względem dziennika zdarzeń

Lokalizacja dziennika zdarzeń i interfejs do wykonywania zapytań w dzienniku zdarzeń zależy od tego, czy potok jest skonfigurowany do używania magazynu metadanych Hive, czy wykazu aparatu Unity.

Magazyn metadanych Hive

Jeśli potok publikuje tabele w magazynie metadanych Hive, dziennik zdarzeń jest przechowywany w /system/events lokalizacji storage . Jeśli na przykład skonfigurowano ustawienie potoku storage jako /Users/username/data, dziennik zdarzeń jest przechowywany w ścieżce /Users/username/data/system/events w systemie plików DBFS.

Jeśli ustawienie nie zostało skonfigurowane, domyślna storage lokalizacja dziennika zdarzeń znajduje się /pipelines/<pipeline-id>/system/events w systemie plików DBFS. Jeśli na przykład identyfikator potoku to 91de5e48-35ed-11ec-8d3d-0242ac130003, lokalizacja magazynu to /pipelines/91de5e48-35ed-11ec-8d3d-0242ac130003/system/events.

Widok można utworzyć, aby uprościć wykonywanie zapytań w dzienniku zdarzeń. Poniższy przykład tworzy widok tymczasowy o nazwie event_log_raw. Ten widok jest używany w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule:

CREATE OR REPLACE TEMP VIEW event_log_raw AS SELECT * FROM delta.`<event-log-path>`;

Zastąp element <event-log-path> lokalizacją dziennika zdarzeń.

Każde wystąpienie przebiegu potoku jest nazywane aktualizacją. Często chcesz wyodrębnić informacje dotyczące najnowszej aktualizacji. Uruchom następujące zapytanie, aby znaleźć identyfikator najnowszej aktualizacji i zapisać go w widoku tymczasowym latest_update_id . Ten widok jest używany w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule:

CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;

Możesz wykonać zapytanie dotyczące dziennika zdarzeń w notesie usługi Azure Databricks lub edytorze SQL. Użyj notesu lub edytora SQL, aby uruchomić przykładowe zapytania dziennika zdarzeń.

Wykaz aparatu Unity

Jeśli potok publikuje tabele w wykazie aparatu Unity, należy użyć event_logfunkcji table valued (TVF), aby pobrać dziennik zdarzeń dla potoku. Dziennik zdarzeń dla potoku można pobrać, przekazując identyfikator potoku lub nazwę tabeli do programu TVF. Aby na przykład pobrać rekordy dziennika zdarzeń dla potoku o identyfikatorze 04c78631-3dd7-4856-b2a6-7d84e9b2638b:

SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")

Aby pobrać rekordy dziennika zdarzeń dla potoku utworzonego lub będącego właścicielem tabeli my_catalog.my_schema.table1:

SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))

Aby wywołać program TVF, należy użyć udostępnionego klastra lub magazynu SQL Warehouse. Możesz na przykład użyć notesu dołączonego do udostępnionego klastra lub użyć edytora SQL połączonego z usługą SQL Warehouse.

Aby uprościć wykonywanie zapytań dotyczących zdarzeń dla potoku, właściciel potoku może utworzyć widok na event_log platformie TVF. Poniższy przykład tworzy widok dziennika zdarzeń dla potoku. Ten widok jest używany w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule.

Uwaga

TvF event_log może być wywoływany tylko przez właściciela potoku, a widok utworzony przez event_log TVF może być odpytywane tylko przez właściciela potoku. Nie można udostępnić widoku innym użytkownikom.

CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");

Zastąp <pipeline-ID> element unikatowym identyfikatorem potoku Delta Live Tables. Identyfikator można znaleźć w panelu Szczegóły potoku w interfejsie użytkownika tabel delta Live Tables.

Każde wystąpienie przebiegu potoku jest nazywane aktualizacją. Często chcesz wyodrębnić informacje dotyczące najnowszej aktualizacji. Uruchom następujące zapytanie, aby znaleźć identyfikator najnowszej aktualizacji i zapisać go w widoku tymczasowym latest_update_id . Ten widok jest używany w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule:

CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;

Wykonywanie zapytań dotyczących informacji o pochodzeniem z dziennika zdarzeń

Zdarzenia zawierające informacje o pochodzenia mają typ flow_definitionzdarzenia . Obiekt details:flow_definition zawiera i output_datasetinput_datasets definiuje każdą relację na grafie.

Aby wyodrębnić wejściowe i wyjściowe zestawy danych, możesz użyć następującego zapytania, aby wyświetlić informacje o pochodzenia:

SELECT
  details:flow_definition.output_dataset as output_dataset,
  details:flow_definition.input_datasets as input_dataset
FROM
  event_log_raw,
  latest_update
WHERE
  event_type = 'flow_definition'
  AND
  origin.update_id = latest_update.id

	output_dataset	input_datasets
1	customers	null
2	sales_orders_raw	null
3	sales_orders_cleaned	["customers", "sales_orders_raw"]
100	sales_order_in_la	["sales_orders_cleaned"]

Wykonywanie zapytań dotyczących jakości danych z dziennika zdarzeń

Jeśli zdefiniujesz oczekiwania dotyczące zestawów danych w potoku, metryki jakości danych są przechowywane w details:flow_progress.data_quality.expectations obiekcie. Zdarzenia zawierające informacje o jakości danych mają typ flow_progresszdarzenia . Poniższy przykład wykonuje zapytania dotyczące metryk jakości danych dla ostatniej aktualizacji potoku:

SELECT
  row_expectations.dataset as dataset,
  row_expectations.name as expectation,
  SUM(row_expectations.passed_records) as passing_records,
  SUM(row_expectations.failed_records) as failing_records
FROM
  (
    SELECT
      explode(
        from_json(
          details :flow_progress :data_quality :expectations,
          "array<struct<name: string, dataset: string, passed_records: int, failed_records: int>>"
        )
      ) row_expectations
    FROM
      event_log_raw,
      latest_update
    WHERE
      event_type = 'flow_progress'
      AND origin.update_id = latest_update.id
  )
GROUP BY
  row_expectations.dataset,
  row_expectations.name

	dataset	expectation	passing_records	failing_records
1	sales_orders_cleaned	valid_order_number	4083	0

Monitorowanie listy prac danych przez wykonywanie zapytań w dzienniku zdarzeń

Delta Live Tables śledzi ilość danych znajdujących się na liście prac w details:flow_progress.metrics.backlog_bytes obiekcie. Zdarzenia zawierające metryki listy prac mają typ flow_progresszdarzenia . Poniższy przykład wykonuje zapytania dotyczące metryk listy prac dla ostatniej aktualizacji potoku:

SELECT
  timestamp,
  Double(details :flow_progress.metrics.backlog_bytes) as backlog
FROM
  event_log_raw,
  latest_update
WHERE
  event_type ='flow_progress'
  AND
  origin.update_id = latest_update.id

Uwaga

Metryki listy prac mogą być niedostępne w zależności od typu źródła danych potoku i wersji środowiska Databricks Runtime.

Monitorowanie zdarzeń rozszerzonego skalowania automatycznego z dziennika zdarzeń

Dziennik zdarzeń przechwytuje zmiany rozmiaru klastra po włączeniu rozszerzonego skalowania automatycznego w potokach. Zdarzenia zawierające informacje o rozszerzonym skalowaniu automatycznym mają typ autoscalezdarzenia . Informacje o żądaniu zmiany rozmiaru klastra details:autoscale są przechowywane w obiekcie . W poniższym przykładzie zapytania dotyczące żądań zmiany rozmiaru klastra rozszerzonego automatycznego skalowania dla ostatniej aktualizacji potoku:

SELECT
  timestamp,
  Double(
    case
      when details :autoscale.status = 'RESIZING' then details :autoscale.requested_num_executors
      else null
    end
  ) as starting_num_executors,
  Double(
    case
      when details :autoscale.status = 'SUCCEEDED' then details :autoscale.requested_num_executors
      else null
    end
  ) as succeeded_num_executors,
  Double(
    case
      when details :autoscale.status = 'PARTIALLY_SUCCEEDED' then details :autoscale.requested_num_executors
      else null
    end
  ) as partially_succeeded_num_executors,
  Double(
    case
      when details :autoscale.status = 'FAILED' then details :autoscale.requested_num_executors
      else null
    end
  ) as failed_num_executors
FROM
  event_log_raw,
  latest_update
WHERE
  event_type = 'autoscale'
  AND
  origin.update_id = latest_update.id

Monitorowanie wykorzystania zasobów obliczeniowych

cluster_resources zdarzenia udostępniają metryki dotyczące liczby miejsc zadań w klastrze, ilości tych miejsc zadań oraz liczby zadań oczekujących na zaplanowanie.

Po włączeniu cluster_resources rozszerzonego skalowania automatycznego zdarzenia zawierają również metryki algorytmu skalowania automatycznego, w tym latest_requested_num_executorsi optimal_num_executors. Zdarzenia pokazują również stan algorytmu jako różne stany, takie jak CLUSTER_AT_DESIRED_SIZE, SCALE_UP_IN_PROGRESS_WAITING_FOR_EXECUTORSi BLOCKED_FROM_SCALING_DOWN_BY_CONFIGURATION. Te informacje można wyświetlić w połączeniu ze zdarzeniami skalowania automatycznego, aby zapewnić ogólny obraz rozszerzonego skalowania automatycznego.

Poniższy przykład wykonuje zapytanie dotyczące historii rozmiaru kolejki zadań dla ostatniej aktualizacji potoku:

SELECT
  timestamp,
  Double(details :cluster_resources.avg_num_queued_tasks) as queue_size
FROM
  event_log_raw,
  latest_update
WHERE
  event_type = 'cluster_resources'
  AND
  origin.update_id = latest_update.id

Poniższy przykład wykonuje zapytanie dotyczące historii wykorzystania ostatniej aktualizacji potoku:

SELECT
  timestamp,
  Double(details :cluster_resources.avg_task_slot_utilization) as utilization
FROM
  event_log_raw,
  latest_update
WHERE
  event_type = 'cluster_resources'
  AND
  origin.update_id = latest_update.id

Poniższy przykład wykonuje zapytania dotyczące historii liczby funkcji wykonawczej, wraz z metrykami dostępnymi tylko dla potoków rozszerzonego skalowania automatycznego, w tym liczby funkcji wykonawczych żądanych przez algorytm w najnowszym żądaniu, optymalnej liczby funkcji wykonawczych zalecanych przez algorytm na podstawie najnowszych metryk i stanu algorytmu skalowania automatycznego:

SELECT
  timestamp,
  Double(details :cluster_resources.num_executors) as current_executors,
  Double(details :cluster_resources.latest_requested_num_executors) as latest_requested_num_executors,
  Double(details :cluster_resources.optimal_num_executors) as optimal_num_executors,
  details :cluster_resources.state as autoscaling_state
FROM
  event_log_raw,
  latest_update
WHERE
  event_type = 'cluster_resources'
  AND
  origin.update_id = latest_update.id

Przeprowadzanie inspekcji potoków tabel na żywo funkcji Delta

Możesz użyć rekordów dziennika zdarzeń usługi Delta Live Tables i innych dzienników inspekcji usługi Azure Databricks, aby uzyskać pełny obraz sposobu aktualizowania danych w usłudze Delta Live Tables.

Usługa Delta Live Tables używa poświadczeń właściciela potoku do uruchamiania aktualizacji. Możesz zmienić używane poświadczenia przez zaktualizowanie właściciela potoku. Usługa Delta Live Tables rejestruje użytkownika na potrzeby akcji w potoku, w tym tworzenia potoku, edycji konfiguracji i wyzwalania aktualizacji.

Zobacz Zdarzenia wykazu aparatu Unity, aby uzyskać informacje o zdarzeniach inspekcji wykazu aparatu Unity.

Wykonywanie zapytań dotyczących akcji użytkownika w dzienniku zdarzeń

Możesz użyć dziennika zdarzeń do inspekcji zdarzeń, na przykład akcji użytkownika. Zdarzenia zawierające informacje o akcjach użytkownika mają typ user_actionzdarzenia .

Informacje o akcji są przechowywane w user_action obiekcie w details polu. Użyj następującego zapytania, aby utworzyć dziennik inspekcji zdarzeń użytkownika. Aby utworzyć event_log_raw widok używany w tym zapytaniu, zobacz Wykonywanie zapytań w dzienniku zdarzeń.

SELECT timestamp, details:user_action:action, details:user_action:user_name FROM event_log_raw WHERE event_type = 'user_action'

	timestamp	action	user_name
1	2021-05-20T19:36:03.517+0000	START	user@company.com
2	2021-05-20T19:35:59.913+0000	CREATE	user@company.com
3	2021-05-27T00:35:51.971+0000	START	user@company.com

Informacje o środowisku uruchomieniowym

Możesz wyświetlić informacje o czasie wykonywania aktualizacji potoku, na przykład wersję środowiska Uruchomieniowego usługi Databricks dla aktualizacji:

SELECT details:create_update:runtime_version:dbr_version FROM event_log_raw WHERE event_type = 'create_update'

	dbr_version
1	11,0