Delta Live Tables-automatiseringen bijhouden
In dit artikel wordt beschreven hoe u ingebouwde bewakings- en waarneembaarheidsfuncties gebruikt voor Delta Live Tables-pijplijnen. Deze functies ondersteunen taken zoals:
- De voortgang en status van pijplijnupdates observeren. Zie welke pijplijndetails beschikbaar zijn in de gebruikersinterface?
- Waarschuwingen over pijplijnevenementen, zoals het slagen of mislukken van pijplijnupdates. Zie E-mailmeldingen toevoegen voor pijplijn gebeurtenissen.
- Gedetailleerde informatie extraheren over pijplijnupdates, zoals gegevensherkomst, metrische gegevens over gegevenskwaliteit en resourcegebruik. Zie Wat is het gebeurtenislogboek van Delta Live Tables?
- Aangepaste acties definiëren die moeten worden uitgevoerd wanneer specifieke gebeurtenissen plaatsvinden. Zie Aangepaste bewaking van Delta Live Tables-pijplijnen definiëren met gebeurtenishook.
Als u de queryprestaties wilt controleren en diagnosticeren, raadpleegt u de Access-querygeschiedenis voor Delta Live Tables-pijplijnen. Deze functie is beschikbaar als 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, met een nieuwe poging of een fout die niet opnieuw kan worden geprobeerd. Selecteer deze optie om een melding te ontvangen voor alle pijplijnfouten.
- Een pijplijnupdate mislukt met een onherstelbare (onherstelbare) 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.
E-mailmeldingen 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 zien, klikt u op het tabblad Lijst . Met de lijstweergave kunt u alle gegevenssets in uw pijplijn zien die worden weergegeven als een rij in een tabel en is handig wanneer uw pijplijn DAG te groot is om te visualiseren in de grafiekweergave . 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 Run as-gebruiker is de eigenaar van de pijplijn en pijplijnupdates worden uitgevoerd met de machtigingen van deze gebruiker. 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, worden details over de gegevensset weergegeven. 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. Klik op De meest recente update weergeven om terug te keren naar de meest recente update.
Wat is het gebeurtenislogboek van Delta Live Tables?
Het Delta Live Tables-gebeurtenislogboek bevat alle informatie met betrekking tot een pijplijn, waaronder auditlogboeken, kwaliteitscontroles van gegevens, pijplijnvoortgang en gegevensherkomst. U kunt het gebeurtenislogboek gebruiken om de status van uw gegevenspijplijnen bij te houden, te begrijpen en te bewaken.
U kunt gebeurtenislogboekvermeldingen weergeven in de Delta Live Tables-gebruikersinterface, de Delta Live Tables-API of 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.
Gebeurtenislogboekschema
In de volgende tabel wordt het schema van het gebeurtenislogboek beschreven. Sommige van deze velden bevatten JSON-gegevens waarvoor parsering nodig is om bepaalde query's uit te voeren, zoals het details
veld. Azure Databricks ondersteunt de operator voor het :
parseren van JSON-velden. Zie de operator : (dubbele puntteken).
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 of pipeline_id pipeline_type om weer te geven waar de pijplijn is gemaakt, of .DBSQL 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 , of ERROR METRICS . WARN |
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. |
maturity_level |
De stabiliteit van het gebeurtenisschema. Mogelijke waarden zijn: - STABLE : Het schema is stabiel en verandert niet.- NULL : Het schema is stabiel en verandert niet. De waarde kan zijn NULL als de record is gemaakt voordat het maturity_level veld werd toegevoegd (release 2022.37).- EVOLVING : Het schema is niet stabiel en kan veranderen.- DEPRECATED : Het schema is afgeschaft en de Delta Live Tables-runtime kan op elk gewenst moment stoppen met het produceren van deze gebeurtenis. |
Query's uitvoeren op het gebeurtenislogboek
De locatie van het gebeurtenislogboek en de interface voor het uitvoeren van query's op het gebeurtenislogboek is afhankelijk van of uw pijplijn is geconfigureerd voor het gebruik van de Hive-metastore of Unity Catalog.
Hive-metastore
Als uw pijplijn tabellen publiceert naar de Hive-metastore, wordt het gebeurtenislogboek opgeslagen /system/events
onder de storage
locatie. Als u bijvoorbeeld uw pijplijninstelling storage
hebt geconfigureerd als /Users/username/data
, wordt het gebeurtenislogboek opgeslagen in het /Users/username/data/system/events
pad in DBFS.
Als u de storage
instelling niet hebt geconfigureerd, bevindt de standaardlocatie van het gebeurtenislogboek zich /pipelines/<pipeline-id>/system/events
in DBFS. Als de id van uw pijplijn bijvoorbeeld is 91de5e48-35ed-11ec-8d3d-0242ac130003
, is /pipelines/91de5e48-35ed-11ec-8d3d-0242ac130003/system/events
de opslaglocatie.
U kunt een weergave maken om het uitvoeren van query's op het gebeurtenislogboek te vereenvoudigen. In het volgende voorbeeld wordt een tijdelijke weergave gemaakt met de naam event_log_raw
. Deze weergave wordt gebruikt in de voorbeeldquery's voor gebeurtenislogboeken die zijn opgenomen in dit artikel:
CREATE OR REPLACE TEMP VIEW event_log_raw AS SELECT * FROM delta.`<event-log-path>`;
Vervang door <event-log-path>
de locatie van het gebeurtenislogboek.
Elk exemplaar van een pijplijnuitvoering wordt een update genoemd. 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_id
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;
U kunt een query uitvoeren op het gebeurtenislogboek in een Azure Databricks-notebook of de SQL-editor. Gebruik een notebook of de SQL-editor om de voorbeeldquery's voor gebeurtenislogboeken uit te voeren.
Unity-catalogus
Als uw pijplijn tabellen publiceert naar Unity Catalog, moet u de event_log
functie met tabelwaarde (TVF) gebruiken om het gebeurtenislogboek voor de pijplijn op te halen. U haalt het gebeurtenislogboek voor een pijplijn op door de pijplijn-id of een tabelnaam door te geven aan de TVF. Als u bijvoorbeeld de gebeurtenislogboekrecords voor de pijplijn met id 04c78631-3dd7-4856-b2a6-7d84e9b2638b
wilt ophalen:
SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")
De gebeurtenislogboekrecords ophalen voor de pijplijn die de tabel heeft gemaakt of die eigenaar is van de tabel my_catalog.my_schema.table1
:
SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))
Als u de TVF wilt aanroepen, moet u een gedeeld cluster of een SQL Warehouse gebruiken. U kunt bijvoorbeeld een notebook gebruiken dat is gekoppeld aan een gedeeld cluster of de SQL-editor gebruiken die is verbonden met een SQL Warehouse.
Om het uitvoeren van query's op gebeurtenissen voor een pijplijn te vereenvoudigen, kan de eigenaar van de pijplijn een weergave maken via de event_log
TVF. In het volgende voorbeeld wordt een weergave gemaakt van het gebeurtenislogboek voor een pijplijn. Deze weergave wordt gebruikt in de voorbeeldquery's voor gebeurtenislogboeken die zijn opgenomen in dit artikel.
Notitie
De event_log
TVF kan alleen worden aangeroepen door de eigenaar van de pijplijn en een weergave die via de event_log
TVF is gemaakt, kan alleen worden opgevraagd door de eigenaar van de pijplijn. De weergave kan niet worden gedeeld met andere gebruikers.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");
Vervang door <pipeline-ID>
de unieke id voor de Delta Live Tables-pijplijn. U vindt de id in het deelvenster Pijplijndetails in de gebruikersinterface van Delta Live Tables.
Elk exemplaar van een pijplijnuitvoering wordt een update genoemd. 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_id
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;
Gegevens over herkomst uit het gebeurtenislogboek opvragen
Gebeurtenissen met informatie over herkomst hebben het gebeurtenistype flow_definition
. Het details:flow_definition
object bevat de output_dataset
relatie en input_datasets
definieert elke relatie in de grafiek.
U kunt de volgende query gebruiken om de invoer- en uitvoergegevenssets te extraheren om herkomstgegevens 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 uit 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 |
Gegevensachterstand bewaken door een query uit te voeren op het gebeurtenislogboek
Delta Live Tables houdt bij hoeveel gegevens aanwezig zijn in de achterstand 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 gebeurtenissen voor automatisch schalen bewaken vanuit het gebeurtenislogboek voor pijplijnen zonder serverloos
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
Rekenresourcegebruik bewaken
cluster_resources
gebeurtenissen bieden metrische gegevens over het aantal taaksites in het cluster, hoeveel deze taaksites worden gebruikt en hoeveel taken er moeten worden gepland.
Wanneer verbeterde automatische schaalaanpassing is ingeschakeld, cluster_resources
bevatten gebeurtenissen ook metrische gegevens voor het algoritme voor automatisch schalen, waaronder latest_requested_num_executors
en optimal_num_executors
. De gebeurtenissen geven ook de status van het algoritme weer als verschillende statussen, zoals CLUSTER_AT_DESIRED_SIZE
, SCALE_UP_IN_PROGRESS_WAITING_FOR_EXECUTORS
en 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
Delta Live Tables-pijplijnen controleren
U kunt gebeurtenislogboekrecords van Delta Live Tables en andere Azure Databricks-auditlogboeken gebruiken om een volledig beeld te krijgen van hoe gegevens worden bijgewerkt in Delta Live Tables.
Delta Live Tables gebruikt de referenties van de eigenaar van de pijplijn om updates uit te voeren. U kunt de gebruikte referenties wijzigen door de eigenaar van de pijplijn bij te werken. Delta Live Tables registreert de gebruiker voor acties in de pijplijn, waaronder het maken van pijplijnen, het bewerken van configuraties en het activeren van updates.
Zie Unity Catalog-gebeurtenissen voor een verwijzing naar Unity Catalog-controlegebeurtenissen.
Query's uitvoeren op gebruikersacties in het gebeurtenislogboek
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 details
veld. Gebruik de volgende query om een auditlogboek van gebruikersgebeurtenissen samen te stellen. Zie Query's uitvoeren op het gebeurtenislogboek om de event_log_raw
weergave te maken die in deze query wordt gebruikt.
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-informatie
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 |