Monitoruj potoki DLT

Artykuł
03/11/2025

W tym artykule opisano używanie wbudowanych funkcji monitorowania i obserwacji dla potoków DLT. Te funkcje obsługują zadania, takie jak:

Monitorowanie postępu i stanu aktualizacji pipeline'u. Zobacz Jakie szczegóły pipeline'u są dostępne w interfejsie użytkownika?.
Alerty dotyczące zdarzeń przepływu, takich jak powodzenie lub niepowodzenie aktualizacji przepływu. Sprawdź Dodanie powiadomień e-mail dotyczących zdarzeń potoku.
Wyświetlanie metryk dla źródeł przesyłania strumieniowego, takich jak Apache Kafka i Auto Loader (publiczna wersja zapoznawcza). Zobacz Wyświetl metryki przesyłania strumieniowego.
Wyodrębnianie szczegółowych informacji na temat aktualizacji rurociągu, takich jak pochodzenie danych, metryki jakości danych i użycie zasobów. Zobacz Co to jest dziennik zdarzeń DLT?.
Definiowanie akcji niestandardowych do wykonania w przypadku wystąpienia określonych zdarzeń. Zobacz Definiowanie niestandardowego monitorowania potoków DLT za pomocą haków zdarzeń.

Aby sprawdzić i zdiagnozować wydajność zapytań, zobacz Historia zapytań programu Access dla potoków DLT. Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

Dodaj powiadomienia e-mail dotyczące zdarzeń potoku

Możesz skonfigurować co najmniej jeden adres e-mail, aby otrzymywać powiadomienia, gdy wystąpią następujące czynności:

Aktualizacja potoku zostanie ukończona pomyślnie.
Aktualizacja potoku kończy się niepowodzeniem z możliwością ponowienia próby lub błędem, który nie można ponowić. Wybierz tę opcję, aby otrzymywać powiadomienia o wszystkich awariach przepływu pracy.
Aktualizacja potoku kończy się niepowodzeniem z błędem niemożliwym do ponowienia próby (krytycznym). Wybierz tę opcję, aby otrzymywać powiadomienie tylko wtedy, gdy wystąpi błąd niemożliwy do ponowienia próby.
Pojedynczy przepływ danych kończy się niepowodzeniem.

Aby skonfigurować powiadomienia e-mail podczas tworzenia lub edycji potoku:

Kliknij pozycję Dodaj powiadomienie.
Wprowadź co najmniej jeden adres e-mail, aby otrzymywać powiadomienia.
Kliknij pole wyboru dla każdego typu powiadomienia, aby wysłać do skonfigurowanych adresów e-mail.
Kliknij pozycję Dodaj powiadomienie.

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

Graf rurociągu pojawi się, gdy tylko pomyślnie rozpocznie się aktualizacja rurociągu. Strzałki reprezentują zależności między zestawami danych w ramach potoku. Domyślnie na stronie szczegółów potoku jest wyświetlana najnowsza aktualizacja tabeli, ale możesz wybrać starsze aktualizacje z menu rozwijanego.

Szczegóły obejmują identyfikator przepływu pracy, kod źródłowy, koszt obliczeniowy, wydanie produktu i kanał skonfigurowany dla przepływu pracy.

Aby wyświetlić tabelaryczny widok zestawów danych, kliknij kartę List. Widok List umożliwia wyświetlanie wszystkich zestawów danych w potoku reprezentowanych jako wiersz w tabeli i jest przydatny, gdy grupa DAG potoku jest zbyt duża do wizualizacji w widoku 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ę Graph.

Użytkownik korzystający z funkcji Uruchom jako jest właścicielem potoku, a aktualizacje potoku są przeprowadzane z uprawnieniami tego użytkownika. Aby zmienić użytkownika run as, 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 pokazuje szczegóły dotyczące zestawu danych. Szczegóły obejmują schemat zestawu danych, metryki jakości danych oraz link do kodu źródłowego definiującego zestaw danych.

Wyświetl historię aktualizacji

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

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

Wyświetlanie metryk przesyłania strumieniowego

Ważny

Możliwość monitorowania w czasie rzeczywistym dla technologii DLT jest dostępna w publicznej wersji zapoznawczej.

Metryki strumieniowe można wyświetlać ze źródeł danych obsługiwanych przez Spark Structured Streaming, takich jak Apache Kafka, Amazon Kinesis, Auto Loader i tabele Delta, dla każdego przepływu strumieniowego w potoku DLT. Metryki są wyświetlane jako wykresy w prawym panelu interfejsu użytkownika DLT i obejmują sekundy zaległości, bajty zaległości, rekordy zaległości oraz pliki zaległości. Wykresy wyświetlają maksymalną wartość zagregowaną przez minutę, a etykietka narzędzia pokazuje maksymalne wartości po umieszczeniu wskaźnika myszy na wykresie. Dane są ograniczone do ostatnich 48 godzin od bieżącego czasu.

Tabele w potoku z dostępnymi metrykami przesyłania strumieniowego wyświetlają ikonę podczas przeglądania potoku DAG w widoku Grafu w interfejsie użytkownika. Aby wyświetlić metryki przesyłania strumieniowego, kliknij ikonę wykresu , co spowoduje pokazanie wykresu w zakładce Przepływy w okienku po prawej stronie. Filtr można również zastosować, aby wyświetlić tylko tabele z metrykami przesyłania strumieniowego, klikając pozycję Lista, a następnie klikając pozycję Ma metryki przesyłania strumieniowego.

Każde źródło przesyłania strumieniowego obsługuje tylko określone metryki. Metryki nieobsługiwane przez źródło przesyłania strumieniowego nie są dostępne do wyświetlenia w interfejsie użytkownika. W poniższej tabeli przedstawiono metryki dostępne dla obsługiwanych źródeł przesyłania strumieniowego:

źródło	bajty zaległości	zapisy zaległości	sekundy zaległego czasu	Zaległe pliki
Kafka	✓	✓
Kinesis	✓		✓
Delta	✓			✓
Moduł automatycznego ładowania	✓			✓
Google Pub/Sub	✓	✓

Co to jest dziennik zdarzeń DLT?

Dziennik zdarzeń DLT zawiera wszystkie informacje związane z potokiem, w tym dzienniki inspekcji, kontrole jakości danych, postęp potoku i pochodzenie danych. Możesz użyć dziennika zdarzeń, aby śledzić, interpretować i monitorować stan potoków danych.

Wpisy dziennika zdarzeń można wyświetlić w interfejsie użytkownika DLT, interfejsie API DLTlub 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łając alerty z hakami zdarzeń.

Ważny

Nie usuwaj dziennika zdarzeń ani katalogu nadrzędnego ani schematu, w którym jest publikowany dziennik zdarzeń. Usunięcie dziennika zdarzeń może spowodować niepowodzenie aktualizacji ciągu podczas przyszłych przebiegów.

schemat dziennika zdarzeń

W poniższej tabeli opisano schemat dziennika zdarzeń. Niektóre z tych pól zawierają dane JSON, które wymagają analizowania niektórych zapytań, takich jak pole details. 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 dotyczące źródła zdarzenia, takie jak dostawca chmury, region tego dostawcy, `user_id`, `pipeline_id`lub `pipeline_type`, aby wskazać miejsce utworzenia potoku, `DBSQL` lub `WORKSPACE`.
`timestamp`	Godzina zarejestrowania zdarzenia.
`message`	Czytelny dla człowieka komunikat opisujący zdarzenie.
`level`	Typ zdarzenia, na przykład `INFO`, `WARN`, `ERROR`lub `METRICS`.
`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`, jeśli rekord został utworzony przed dodaniu pola `maturity_level` (wydanie 2022.37). `EVOLVING`: schemat nie jest stabilny i może ulec zmianie. `DEPRECATED`: schemat jest przestarzały, a środowisko uruchomieniowe DLT może w dowolnym momencie przestać produkować to zdarzenie.
`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.

Wykonywanie zapytań w dzienniku zdarzeń

Notatka

W tej sekcji opisano domyślne zachowanie i składnię pracując z dziennikami zdarzeń dla potoków skonfigurowanych w Unity Catalog i domyślnym trybem publikowania.

Aby uzyskać informacje o zachowaniu potoków Unity Catalog korzystających ze starszego trybu publikowania, zobacz Praca z dziennikiem zdarzeń dla potoków starszego trybu publikowania w Unity Catalog.
Aby uzyskać informacje o zachowaniu i składni potoków magazynu metadanych Hive, zobacz Work with event log for Hive metastore pipelines (Praca z dziennikiem zdarzeń dla potoków magazynu metadanych Hive).

Domyślnie, DLT zapisuje dziennik zdarzeń w ukrytej tabeli Delta w domyślnym katalogu i schemacie skonfigurowanym dla potoku. Mimo że tabela jest ukryta, nadal może być odpytywana przez wszystkich wystarczająco uprzywilejowanych użytkowników. Domyślnie tylko właściciel potoku może wysyłać zapytania do tabeli dziennika zdarzeń.

Domyślnie nazwa ukrytego dziennika zdarzeń jest formatowana jako event_log_{pipeline_id}, gdzie identyfikator potoku jest identyfikatorem UUID przypisanym przez system z kreską zastąpioną podkreśleniami.

Aby opublikować dziennik zdarzeń, możesz wchodzić w interakcję z konfiguracją JSON. Podczas publikowania dziennika zdarzeń należy określić nazwę dziennika zdarzeń i opcjonalnie określić wykaz i schemat, jak w poniższym przykładzie:

{
  "id": "ec2a0ff4-d2a5-4c8c-bf1d-d9f12f10e749",
  "name": "billing_pipeline",
  "event_log": {
    "catalog": "catalog_name",
    "schema": "schema_name",
    "name": "event_log_table_name"
  }
}

Lokalizacja dziennika zdarzeń służy również jako lokalizacja schematu dla wszystkich zapytań Auto Loader w ramach potoku. Usługa Databricks zaleca utworzenie widoku w tabeli dziennika zdarzeń przed zmodyfikowaniem uprawnień, ponieważ niektóre ustawienia obliczeniowe mogą umożliwić użytkownikom uzyskanie dostępu do metadanych schematu, jeśli tabela dziennika zdarzeń jest udostępniana bezpośrednio. Poniższa przykładowa składnia tworzy widok w tabeli dziennika zdarzeń i jest używana w przykładowych zapytaniach dziennika zdarzeń zawartych w tym artykule.

CREATE VIEW event_log_raw
AS SELECT * FROM catalog_name.schema_name.event_log_table_name;

Każde wystąpienie uruchomienia 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. 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;

W katalogu Unity widoki obsługują zapytania przesyłane strumieniowo. W poniższym przykładzie użyto przesyłania strumieniowego ze strukturą do wykonywania zapytań dotyczących widoku zdefiniowanego na podstawie tabeli dziennika zdarzeń:

df = spark.readStream.table("event_log_raw")

Właściciel rurociągu może opublikować dziennik zdarzeń jako publiczną tabelę delty, przełączając opcję Publish event log to metastore w sekcji Zaawansowane konfiguracji rurociągu. Opcjonalnie możesz określić nową nazwę tabeli, wykaz i schemat dziennika zdarzeń.

Śledzenie pochodzenia zapytań w dzienniku zdarzeń

Zdarzenia zawierające informacje o pochodzeniu mają typ flow_definition. Obiekt details:flow_definition zawiera output_dataset i input_datasets definiujące każdą relację w grafie.

Możesz użyć następującego zapytania, aby wyodrębnić wejściowe i wyjściowe zestawy danych oraz zobaczyć informacje o pochodzeniu.

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`
`customers`	`null`
`sales_orders_raw`	`null`
`sales_orders_cleaned`	`["customers", "sales_orders_raw"]`
`sales_order_in_la`	`["sales_orders_cleaned"]`

Wykonywanie zapytań o jakość danych z dziennika zdarzeń

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

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`
`sales_orders_cleaned`	`valid_order_number`	4083	0

Wykonywanie zapytań o zdarzenia Auto Loader z dziennika zdarzeń

DlT generuje zdarzenia, gdy moduł ładujący automatycznie przetwarza pliki. W przypadku zdarzeń automatycznego modułu ładującego event_type jest operation_progress, a details:operation_progress:type jest AUTO_LOADER_LISTING lub AUTO_LOADER_BACKFILL. Obiekt details:operation_progress zawiera również pola status, duration_ms, auto_loader_details:source_pathi auto_loader_details:num_files_listed.

W poniższym przykładzie zapytania dotyczą zdarzeń Auto Loader dla najnowszej aktualizacji:

SELECT
  timestamp,
  details:operation_progress.status,
  details:operation_progress.type,
  details:operation_progress:auto_loader_details
FROM
  event_log_raw,
  latest_update
WHERE
  event_type like 'operation_progress'
  AND
  origin.update_id = latest.update_id
  AND
  details:operation_progress.type in ('AUTO_LOADER_LISTING', 'AUTO_LOADER_BACKFILL')

Monitorowanie zaległości danych poprzez zapytanie dziennika zdarzeń

DLT śledzi ilość danych obecnych w backlogu w obiekcie details:flow_progress.metrics.backlog_bytes. Zdarzenia zawierające metryki listy zaległości mają typ zdarzenia flow_progress. Poniższy przykład wykonuje zapytania dotyczące metryk backlogu 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

Notatka

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

Monitorowanie rozszerzonych zdarzeń skalowania automatycznego z dziennika zdarzeń dla potoków bez włączonej bezserwerowej

W przypadku potoków DLT, które nie korzystają z przetwarzania bezserwerowego, dziennik zdarzeń przechwytuje zmiany rozmiaru klastra po włączeniu rozszerzonego skalowania automatycznego w potokach. Zdarzenia zawierające informacje o rozszerzonym skalowaniu automatycznym mają typ zdarzenia autoscale. Informacje o żądaniu zmiany rozmiaru klastra są przechowywane w obiekcie details:autoscale. Poniższy przykład przedstawia zapytania dotyczące rozszerzonych żądań zmiany rozmiaru klastra z automatycznym skalowaniem 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 zapewniają metryki dotyczące liczby miejsc zadań w klastrze, stopnia wykorzystania tych miejsc i liczby zadań oczekujących na zaplanowanie.

Po włączeniu rozszerzonego skalowania automatycznego zdarzenia cluster_resources 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 w związku z ostatnią aktualizacją 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 wykonawczych, wraz z metrykami dostępnymi tylko dla rozszerzonych potoków 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

Audyt potoków DLT

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

DLT używa poświadczeń właściciela potoku w celu przeprowadzania aktualizacji. Możesz zmienić używane poświadczenia, aktualizując właściciela kanału. DLT rejestruje użytkownika w kontekście działań na potoku, w tym tworzenia, edytowania konfiguracji i wyzwalania aktualizacji.

Zobacz zdarzenia katalogu Unity, aby uzyskać informacje o zdarzeniach inspekcji katalogu Unity.

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 zdarzenia user_action.

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

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

`timestamp`	`action`	`user_name`
2021-05-20T19:36:03.517+0000	`START`	`user@company.com`
2021-05-20T19:35:59.913+0000	`CREATE`	`user@company.com`
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`
11.0

Udostępnij za pośrednictwem