DLT-pijplijnen bewaken

Artikel
03/05/2025

In dit artikel wordt beschreven hoe u ingebouwde bewakings- en waarneembaarheidsfuncties gebruikt voor DLT-pijplijnen. Deze functies ondersteunen taken zoals:

De voortgang en status van pijplijnupdates observeren. Zie Welke pijplijndetails zijn beschikbaar in de gebruikersinterface?.
Waarschuwingen over pijplijnevenementen, zoals het slagen of mislukken van pijplijnupdates. Zie E-mailmeldingen toevoegen voor pijplijn gebeurtenissen.
Metrische gegevens weergeven voor streamingbronnen zoals Apache Kafka en Automatisch laden (openbare preview). Zie Metrische gegevens voor streaming weergeven.
Gedetailleerde informatie extraheren over pijplijnupdates, zoals gegevensherkomst, metrische gegevens over gegevenskwaliteit en resourcegebruik. Zie Wat is het DLT-gebeurtenislogboek?.
Aangepaste acties definiëren die moeten worden uitgevoerd wanneer specifieke gebeurtenissen plaatsvinden. Zie Aangepaste bewaking van DLT-pijplijnen definiëren met gebeurtenishaakjes.

Zie Toegang tot querygeschiedenis voor DLT-pijplijnenom de prestaties van queries te diagnosticeren en controleren. Deze functie bevindt zich in openbare preview.

e-mailmeldingen toevoegen voor pijplijn gebeurtenissen

U kunt een of meer e-mailadressen configureren om meldingen te ontvangen wanneer het volgende gebeurt:

Een pijplijnupdate is voltooid.
Een pijplijnupdate mislukt, hetzij met een herstelbare fout hetzij met een niet-herstelbare fout. Selecteer deze optie om een melding te ontvangen voor alle pijplijnfouten.
Een pijplijnupdate mislukt met een niet-herstelbare (fatale) fout. Selecteer deze optie om alleen een melding te ontvangen wanneer er een fout optreedt die niet opnieuw kan worden geprobeerd.
Eén gegevensstroom mislukt.

Om e-mailmeldingen te configureren wanneer u een pijplijn maakt of bewerkt:

Klik op Melding toevoegen.
Voer een of meer e-mailadressen in om meldingen te ontvangen.
Klik op het selectievakje voor elk meldingstype dat u naar de geconfigureerde e-mailadressen wilt verzenden.
Klik op Melding toevoegen.

Welke pijplijndetails zijn beschikbaar in de gebruikersinterface?

De pijplijngrafiek wordt weergegeven zodra een update van een pijplijn is gestart. Pijlen vertegenwoordigen afhankelijkheden tussen gegevenssets in uw pijplijn. Op de pagina met pijplijndetails wordt standaard de meest recente update voor de tabel weergegeven, maar u kunt oudere updates selecteren in een vervolgkeuzelijst.

Details zijn de pijplijn-id, broncode, rekenkosten, producteditie en het kanaal dat is geconfigureerd voor de pijplijn.

Als u een tabelweergave van gegevenssets wilt bekijken, klikt u op het tabblad Lijst. Met de weergave List kunt u alle gegevenssets in uw pijplijn zien die als een rij in een tabel worden weergegeven. Dit is handig wanneer uw pijplijn DAG te groot is om te visualiseren in de Graph weergave. U kunt bepalen welke gegevenssets in de tabel worden weergegeven met behulp van meerdere filters, zoals de naam van de gegevensset, het type en de status. Als u wilt teruggaan naar de DAG-visualisatie, klikt u op Graph.

De Uitvoeren als gebruiker is de eigenaar van de pijplijn, en pijplijnupdates worden met de rechten van deze gebruiker uitgevoerd. Als u de run as gebruiker wilt wijzigen, klikt u op Machtigingen en wijzigt u de eigenaar van de pijplijn.

Hoe kunt u gegevenssetgegevens weergeven?

Als u op een gegevensset in de pijplijngrafiek of gegevenssetlijst klikt, ziet u details over de gegevensset. Details omvatten het gegevenssetschema, metrische gegevens van gegevenskwaliteit en een koppeling naar de broncode die de gegevensset definieert.

Updategeschiedenis weergeven

Als u de geschiedenis en status van pijplijnupdates wilt weergeven, klikt u op de vervolgkeuzelijst updategeschiedenis in de bovenste balk.

Selecteer de update in de vervolgkeuzelijst om de grafiek, details en gebeurtenissen voor een update weer te geven. Als u wilt terugkeren naar de meest recente update, klikt u op De meest recente update weergeven.

metrische streaminggegevens weergeven

Belangrijk

Streaming-waarneembaarheid voor DLT bevindt zich in Openbare Preview.

U kunt streaminggegevens bekijken uit de gegevensbronnen die worden ondersteund door Spark Structured Streaming, zoals Apache Kafka, Amazon Kinesis, Auto Loader en Delta-tabellen, voor elke streamingstroom in uw DLT-pijplijn. Metrische gegevens worden weergegeven als grafieken in het rechterdeelvenster van de DLT-gebruikersinterface en bevatten backlogseconden, backlogbytes, backlogrecords en backlogbestanden. In de grafieken wordt de maximumwaarde per minuut geaggregeerd weergegeven en er verschijnt een tooltip met maximumwaarden wanneer u over de grafiek beweegt. De gegevens zijn beperkt tot de afgelopen 48 uur vanaf de huidige tijd.

Tabellen in uw pijplijn met beschikbare streaminggegevens geven het pictogram weer wanneer u de pijplijn DAG bekijkt in de ui Graph weergave. Als u de streamingmetrische gegevens wilt weergeven, klikt u op de om de streamingmetriekgrafiek weer te geven in het tabblad Stromen in het rechterdeelvenster. U kunt ook een filter toepassen om alleen tabellen met streaming metrieken weer te geven door te klikken op Lijst en vervolgens te klikken op Heeft streaminggegevens.

Elke streamingbron ondersteunt alleen specifieke metrische gegevens. Metrische gegevens die niet worden ondersteund door een streamingbron, zijn niet beschikbaar om weer te geven in de gebruikersinterface. In de volgende tabel ziet u de metrische gegevens die beschikbaar zijn voor ondersteunde streamingbronnen:

bron	achterstandsbytes	achterstandenlijst	achterstandsseconden	achterstandsbestanden
Kafka	✓	✓
Kinesis	✓		✓
Delta	✓			✓
Automatische lader	✓			✓
Google Pub/Sub (een berichten- en gebeurtenissenservice van Google)	✓	✓

Wat is het DLT-gebeurtenislogboek?

Het DLT-gebeurtenislogboek bevat alle informatie met betrekking tot een pijplijn, waaronder auditlogboeken, controles van gegevenskwaliteit, voortgang van pijplijnen en gegevensherkomst. U kunt het gebeurtenislogboek gebruiken om de status van uw gegevenspijplijnen bij te houden, te begrijpen en te bewaken.

U kunt vermeldingen in gebeurtenislogboeken bekijken in de DLT-gebruikersinterface, de DLT-APIof door rechtstreeks een query uit te voeren op het gebeurtenislogboek. Deze sectie is gericht op het rechtstreeks opvragen van het gebeurtenislogboek.

U kunt ook aangepaste acties definiëren die moeten worden uitgevoerd wanneer gebeurtenissen worden geregistreerd, bijvoorbeeld het verzenden van waarschuwingen, met gebeurtenishook.

Belangrijk

Verwijder niet het gebeurtenislogboek, de bovenliggende catalogus of het schema waarin het gebeurtenislogboek wordt gepubliceerd. Als u het gebeurtenislogboek verwijdert, kan dit ertoe leiden dat uw pijplijn niet kan worden bijgewerkt tijdens toekomstige uitvoeringen.

schema voor gebeurtenislogboeken

In de volgende tabel wordt het schema van het gebeurtenislogboek beschreven. Sommige van deze velden bevatten JSON-gegevens waarvoor parsering is vereist om bepaalde query's uit te voeren, zoals het details veld. Azure Databricks ondersteunt de :-operator om JSON-velden te parseren. Zie : (dubbelepuntteken) operator.

Veld	Beschrijving
`id`	Een unieke id voor de gebeurtenislogboekrecord.
`sequence`	Een JSON-document met metagegevens voor het identificeren en orden van gebeurtenissen.
`origin`	Een JSON-document met metagegevens voor de oorsprong van de gebeurtenis, bijvoorbeeld de cloudprovider, de regio van de cloudprovider, `user_id`, `pipeline_id`of `pipeline_type` om weer te geven waar de pijplijn is gemaakt, `DBSQL` of `WORKSPACE`.
`timestamp`	De tijd waarop de gebeurtenis is opgenomen.
`message`	Een door mensen leesbaar bericht waarin de gebeurtenis wordt beschreven.
`level`	Het gebeurtenistype, bijvoorbeeld `INFO`, `WARN`, `ERROR`of `METRICS`.
`maturity_level`	De stabiliteit van het gebeurtenisschema. De mogelijke waarden zijn: `STABLE`: het schema is stabiel en verandert niet. `NULL`: het schema is stabiel en verandert niet. De waarde kan worden `NULL` als de record is gemaakt voordat het `maturity_level` veld is toegevoegd (release 2022.37). `EVOLVING`: het schema is niet stabiel en kan veranderen. `DEPRECATED`: het schema is afgeschaft en de DLT-runtime kan op elk gewenst moment stoppen met het produceren van deze gebeurtenis.
`error`	Als er een fout is opgetreden, worden de details beschreven die de fout beschrijven.
`details`	Een JSON-document met gestructureerde details van de gebeurtenis. Dit is het primaire veld dat wordt gebruikt voor het analyseren van gebeurtenissen.
`event_type`	Het gebeurtenistype.

het gebeurtenislogboek opvragen

Notitie

In deze sectie worden het standaardgedrag en de syntaxis beschreven voor het werken met gebeurtenislogboeken voor pijplijnen die zijn geconfigureerd met Unity Catalog en de standaardpublicatiemodus.

Zie voor gedrag voor Unity Catalog-pijplijnen die gebruikmaken van de verouderde publicatiemodus Werken met gebeurtenislogboek voor pijplijnen in de verouderde publicatiemodus van Unity Catalog.
Zie Werken met gebeurtenislogboek voor Hive-metastore-pijplijnenvoor gedrag en syntaxis voor Hive-metastore-pijplijnen.

Standaard schrijft DLT het gebeurtenislogboek naar een verborgen Delta-tabel in de standaardcatalogus en het schema dat is geconfigureerd voor de pijplijn. Hoewel de tabel is verborgen, kan de tabel nog steeds worden opgevraagd door alle gebruikers met voldoende bevoegdheden. Standaard kan alleen de eigenaar van de pijplijn een query uitvoeren op de tabel van het gebeurtenislogboek.

Standaard wordt de naam voor het verborgen evenementlogboek opgemaakt als event_log_{pipeline_id}, waarbij het pipeline-ID de door het systeem toegewezen UUID is, met streepjes vervangen door onderstrepingstekens.

U kunt communiceren met de JSON-configuratie om het gebeurtenislogboek te publiceren. Wanneer u een gebeurtenislogboek publiceert, geeft u de naam op voor het gebeurtenislogboek en kunt u desgewenst een catalogus en schema opgeven, zoals in het volgende voorbeeld:

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

De locatie van het gebeurtenislogboek fungeert ook als de schemalocatie voor alle AutoLoader-query's in de pijplijn. Databricks raadt aan om een weergave te maken van de gebeurtenislogboektabel voordat u de bevoegdheden wijzigt, omdat sommige rekeninstellingen gebruikers mogelijk toegang geven tot schemametagegevens als de gebeurtenislogboektabel rechtstreeks wordt gedeeld. De volgende voorbeeldsyntaxis maakt een weergave in een gebeurtenislogboektabel en wordt gebruikt in de voorbeeldquery's voor gebeurtenislogboeken die in dit artikel zijn opgenomen.

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

Elk exemplaar van een pijplijnuitvoering wordt een updategenoemd. U wilt vaak informatie extraheren voor de meest recente update. Voer de volgende query uit om de id voor de meest recente update te vinden en op te slaan in de latest_update tijdelijke weergave. Deze weergave wordt gebruikt in de voorbeeldquery's voor gebeurtenislogboeken die zijn opgenomen in dit artikel:

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;

In Unity Catalog bieden weergaven ondersteuning voor streamingquery's. In het volgende voorbeeld wordt Structured Streaming gebruikt om een query uit te voeren op een weergave die is gedefinieerd boven op een gebeurtenislogboektabel:

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

De eigenaar van de pijplijn kan het gebeurtenislogboek publiceren als een openbare Delta-tabel door de optie Publish event log to metastore in te schakelen in het gedeelte Advanced van de pijplijnconfiguratie. U kunt desgewenst een nieuwe tabelnaam, catalogus en schema opgeven voor het gebeurtenislogboek.

Afstammingsinformatie opvragen uit het gebeurtenislogboek

Gebeurtenissen met informatie over herkomst hebben het gebeurtenistype flow_definition. Het details:flow_definition-object bevat de output_dataset en input_datasets die elke relatie in de grafiek definiëren.

U kunt de volgende query gebruiken om de invoer- en uitvoer datasets te extraheren om herkomstinformatie te bekijken.

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"]`

Gegevenskwaliteit opvragen van het gebeurtenislogboek

Als u verwachtingen definieert voor gegevenssets in uw pijplijn, worden de metrische gegevens over de gegevenskwaliteit opgeslagen in het details:flow_progress.data_quality.expectations-object. Gebeurtenissen met informatie over de gegevenskwaliteit hebben het gebeurtenistype flow_progress. In het volgende voorbeeld worden de metrische gegevens van de gegevenskwaliteit voor de laatste pijplijnupdate opgevraagd:

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

Query's uitvoeren op gebeurtenissen van automatische laadprogramma's uit het gebeurtenislogboek

DLT genereert gebeurtenissen wanneer Auto Loader bestanden verwerkt. Voor Auto Loader-gebeurtenissen is de event_typeoperation_progress en de details:operation_progress:type is AUTO_LOADER_LISTING of AUTO_LOADER_BACKFILL. Het object details:operation_progress bevat ook status, duration_ms, auto_loader_details:source_pathen auto_loader_details:num_files_listed velden.

In het volgende voorbeeld worden automatisch laadprogramma-gebeurtenissen voor de meest recente update opgevraagd:

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')

Gegevensachterstand bewaken door een query uit te voeren op het gebeurtenislogboek

DLT houdt bij hoeveel gegevens aanwezig zijn in de wachtrij in het details:flow_progress.metrics.backlog_bytes-object. Gebeurtenissen met metrische gegevens over achterstand hebben het gebeurtenistype flow_progress. In het volgende voorbeeld worden metrische gegevens over achterstand opgevraagd voor de laatste pijplijnupdate:

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

Notitie

De metrische gegevens over achterstand zijn mogelijk niet beschikbaar, afhankelijk van het gegevensbrontype van de pijplijn en de Databricks Runtime-versie.

Verbeterde automatische schaalaanpassing controleren via het gebeurtenislogboek voor pijplijnen zonder ingeschakelde serverless-functionaliteit

Voor DLT-pijplijnen die geen serverloze berekening gebruiken, worden in het gebeurtenislogboek de grootte van het cluster vastgelegd wanneer verbeterde automatische schaalaanpassing is ingeschakeld in uw pijplijnen. Gebeurtenissen met informatie over verbeterde automatische schaalaanpassing hebben het gebeurtenistype autoscale. De aanvraaggegevens voor het wijzigen van het formaat van het cluster worden opgeslagen in het details:autoscale-object. In het volgende voorbeeld wordt een query uitgevoerd op de verbeterde aanvragen voor automatisch schalen van clusters voor de laatste pijplijnupdate:

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

Het gebruik van rekenresources bewaken

cluster_resources gebeurtenissen verschaffen meetgegevens over het aantal taakslots in het cluster, hoeveel deze taakslots gebruikt worden, en hoeveel taken wachten om ingepland te worden.

Wanneer verbeterde automatische schaalaanpassing is ingeschakeld, bevatten cluster_resources gebeurtenissen ook metrische gegevens voor het algoritme voor automatisch schalen, waaronder latest_requested_num_executorsen optimal_num_executors. De gebeurtenissen geven ook de status van het algoritme weer, zoals CLUSTER_AT_DESIRED_SIZE, SCALE_UP_IN_PROGRESS_WAITING_FOR_EXECUTORSen BLOCKED_FROM_SCALING_DOWN_BY_CONFIGURATION. Deze informatie kan worden weergegeven in combinatie met de gebeurtenissen voor automatisch schalen om een algemeen beeld te geven van verbeterde automatische schaalaanpassing.

In het volgende voorbeeld wordt de geschiedenis van de taakwachtrijgrootte voor de laatste pijplijnupdate opgevraagd:

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

In het volgende voorbeeld wordt de gebruiksgeschiedenis voor de laatste pijplijnupdate opgevraagd:

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

In het volgende voorbeeld wordt de geschiedenis van het aantal uitvoerders opgevraagd, vergezeld van metrische gegevens die alleen beschikbaar zijn voor verbeterde pijplijnen voor automatisch schalen, inclusief het aantal uitvoerders dat is aangevraagd door het algoritme in de meest recente aanvraag, het optimale aantal uitvoerders dat wordt aanbevolen door het algoritme op basis van de meest recente metrische gegevens en de status van het algoritme voor automatisch schalen:

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

DLT-pijplijnen controleren

U kunt DLT-gebeurtenislogboekrecords en andere Auditlogboeken van Azure Databricks gebruiken om een volledig beeld te krijgen van hoe gegevens worden bijgewerkt in DLT.

DLT gebruikt de referenties van de eigenaar van de pijplijn om updates uit te voeren. U kunt de inloggegevens wijzigen door de eigenaar van de pijplijn bij te werken. DLT registreert de gebruiker voor acties in de pijplijn, inclusief het maken van pijplijnen, wijzigingen in de configuratie en het activeren van updates.

Zie Unity Catalog-gebeurtenissen voor een verwijzing naar Unity Catalog-auditgebeurtenissen.

U kunt het gebeurtenislogboek gebruiken om gebeurtenissen te controleren, bijvoorbeeld gebruikersacties. Gebeurtenissen met informatie over gebruikersacties hebben het gebeurtenistype user_action.

Informatie over de actie wordt opgeslagen in het user_action-object in het veld details. Gebruik de volgende query om een auditlogboek van gebruikersgebeurtenissen samen te stellen. Om de event_log_raw weergave te maken die in deze query wordt gebruikt, zie Query uitvoeren op het gebeurtenislogboek.

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`

Runtime-gegevens

U kunt runtime-informatie voor een pijplijnupdate bekijken, bijvoorbeeld de Databricks Runtime-versie voor de update:

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

`dbr_version`
11.0

Delen via