Monitore os pipelines Delta Live Tables
Este artigo descreve o uso de funções integradas de monitorização e observabilidade para pipelines Delta Live Tables. Esses recursos suportam tarefas como:
- Observar o progresso e o status das atualizações do pipeline. Consulte Quais detalhes do pipeline estão disponíveis na interface do usuário?.
- Alertar sobre eventos de pipeline, como o sucesso ou falha de atualizações de pipeline. Consulte Adicionar notificações por e-mail para eventos de pipeline.
- Visualização de métricas para fontes de streaming como Apache Kafka e Auto Loader (Public Preview). Consulte Ver métricas de streaming.
- Extração de informações detalhadas sobre atualizações de pipeline, como linhagem de dados, métricas de qualidade de dados e uso de recursos. Consulte O que é o log de eventos do Delta Live Tables?.
- Definição de ações personalizadas a serem executadas quando eventos específicos ocorrerem. Veja Definição de monitorização personalizada de pipelines Delta Live Tables com ganchos de eventos.
Para inspecionar e diagnosticar o desempenho de consultas, consulte o histórico de consultas de Delta Live para pipelines Tables. Esta funcionalidade está em Pré-visualização Pública.
Adicionar notificações por e-mail para eventos de pipeline
Você pode configurar um ou mais endereços de e-mail para receber notificações quando ocorrer o seguinte:
- O pipeline update é concluído com êxito.
- Um pipeline update falha, seja com um erro repetível ou não repetível. Select essa opção para receber uma notificação para todas as falhas de pipeline.
- Um pipeline update falha com um erro não reprovável (fatal). Select essa opção para receber uma notificação somente quando ocorrer um erro irrecuperável.
- Um único fluxo de dados falha.
Para configurar notificações por e-mail ao criar ou editar um pipeline:
- Clique em Adicionar notificação.
- Insira um ou mais endereços de e-mail para receber notificações.
- Clique na caixa de seleção para cada tipo de notificação para enviar para os endereços de e-mail configurados.
- Clique em Adicionar notificação.
Quais detalhes do pipeline estão disponíveis na interface do usuário?
O gráfico do pipeline aparece assim que um update para um pipeline é iniciado com sucesso. As setas representam dependências entre conjuntos de dados em seu pipeline. Por padrão, a página de detalhes do pipeline mostra os update mais recentes do table, mas você pode select atualizações mais antigas em um menu suspenso.
Os detalhes incluem o ID do pipeline, o código-fonte, o custo de computação, a edição do produto e o canal configurado para o pipeline.
Para ver uma vista tabular de conjuntos de dados, clique na guia
O usuário Executar como é o proprietário do pipeline e as atualizações do pipeline são executadas com as permissões desse usuário. Para alterar o run as
usuário, clique em Permissões e altere o proprietário do pipeline.
Como você pode visualizar os detalhes do conjunto de dados?
Clicar em um conjunto de dados no gráfico de pipeline ou conjunto de dados list mostra detalhes sobre o conjunto de dados. Os detalhes incluem o conjunto de dados schema, as métricas de qualidade de dados e um link para o código-fonte que define o conjunto de dados.
Ver update histórico
Para ver o histórico e o estado das atualizações do pipeline, clique no menu suspenso de histórico update na barra superior.
Select o update no menu suspenso para visualizar o gráfico, os detalhes e os eventos de um update. Para regressar à updatemais recente, clique em Mostrar a updatemais recente.
Ver métricas de streaming
Você pode visualizar métricas de streaming das fontes de dados suportadas pelo Spark Structured Streaming, como Apache Kafka, Amazon Kinesis, Auto Loader e Delta tables, para cada fluxo de streaming em seu pipeline de Tables Delta Live. As métricas são exibidas como gráficos no painel direito da interface de utilizador do Delta Live Tables e incluem segundos de atraso, bytes de atraso, registos de atraso e ficheiros de atraso. Os gráficos exibem o valor máximo agregado por minuto, e quando coloca o cursor sobre o gráfico, o máximo values é exibido. Os dados estão limitados às últimas 48 horas a partir da hora atual.
Cada fonte de streaming suporta apenas métricas específicas. As métricas não suportadas por uma fonte de streaming não estão disponíveis para visualização na interface do usuário. A table a seguir mostra as métricas disponíveis para fontes de streaming suportadas:
fonte | bytes da lista de pendências | Registos de pendências | segundos da lista de pendências | Arquivos de Pendências |
---|---|---|---|---|
Kafka | ✓ | ✓ | ||
Cinesis | ✓ | ✓ | ||
Delta; | ✓ | ✓ | ||
Carregador Automático | ✓ | ✓ | ||
Google Pub/Sub | ✓ | ✓ |
O que é o log de eventos do Delta Live Tables?
O log de eventos do Delta Live Tables contém todas as informações relacionadas a um pipeline, incluindo logs de auditoria, verificações de qualidade de dados, progresso do pipeline e linhagem de dados. Pode utilizar o registo de eventos para controlar, compreender e monitorizar o estado dos seus pipelines de dados.
Você pode visualizar as entradas do log de eventos na interface do usuário do Delta Live Tables, na API Delta Live Tables, ou consultando diretamente o log de eventos. Esta seção se concentra em consultar o log de eventos diretamente.
Você também pode definir ações personalizadas a serem executadas quando os eventos são registrados, por exemplo, enviando alertas, com ganchos de eventos.
Registo de eventos schema
O seguinte table descreve o log de eventos schema. Alguns desses campos contêm dados JSON que exigem análise para executar algumas consultas, como o details
campo. O Azure Databricks dá suporte ao :
operador para analisar campos JSON. Consulte : (sinal de dois pontos) operador.
Campo | Descrição |
---|---|
id |
Um identifier exclusivo para o registo do log de eventos. |
sequence |
Um documento JSON contendo metadados para identificar e ordenar eventos. |
origin |
Um documento JSON contendo metadados para a origem do evento, por exemplo, o provedor de nuvem, a região do provedor de nuvem, user_id , pipeline_id ou pipeline_type para mostrar que where o pipeline foi criado, seja DBSQL ou WORKSPACE . |
timestamp |
A hora em que o evento foi gravado. |
message |
Uma mensagem legível por humanos descrevendo o evento. |
level |
O tipo de evento, por exemplo, INFO , , WARN ERROR , ou METRICS . |
error |
Se ocorreu um erro, detalhes descrevendo o erro. |
details |
Um documento JSON contendo detalhes estruturados do evento. Este é o campo principal usado para analisar eventos. |
event_type |
O tipo de evento. |
maturity_level |
A estabilidade do evento schema. Os values possíveis são: - STABLE : O schema é estável e não mudará.- NULL : O schema é estável e não mudará. O valor pode ser NULL se o registro foi criado antes do maturity_level campo ser adicionado (versão 2022.37).- EVOLVING : O schema não é estável e pode mudar.- DEPRECATED : O schema foi preterido e o tempo de execução do Delta Live Tables pode parar de produzir esse evento a qualquer momento. |
Consultando o log de eventos
A localização do log de eventos e a interface para consultar o log de eventos dependem de se o pipeline está configurado para usar o metastore do Hive ou o Unity Catalog.
Metastore do Hive
Se o pipeline publicar tables no metastore do Hive, o log de eventos será armazenado em /system/events
na localização storage
. Por exemplo, se você tiver configurado sua configuração de pipeline storage
como /Users/username/data
, o log de eventos será armazenado no /Users/username/data/system/events
caminho no DBFS.
Se você não tiver configurado a storage
configuração, o local padrão do log de eventos estará /pipelines/<pipeline-id>/system/events
no DBFS. Por exemplo, se o ID do seu pipeline for 91de5e48-35ed-11ec-8d3d-0242ac130003
, o local de armazenamento será /pipelines/91de5e48-35ed-11ec-8d3d-0242ac130003/system/events
.
Você pode criar um modo de exibição para simplificar a consulta ao log de eventos. O exemplo a seguir cria um modo de exibição temporário chamado event_log_raw
. Esse modo de exibição é usado nas consultas de log de eventos de exemplo incluídas neste artigo:
CREATE OR REPLACE TEMP VIEW event_log_raw AS SELECT * FROM delta.`<event-log-path>`;
Substitua <event-log-path>
pelo local do log de eventos.
Cada instância de uma execução de pipeline é chamada de update. Muitas vezes, você deseja extrair informações para o updatemais recente. Execute a consulta a seguir para localizar o identifier do update mais recente e salvá-lo no modo de exibição latest_update_id
temporário. Esse modo de exibição é usado nas consultas de log de eventos de exemplo incluídas neste artigo:
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;
Você pode consultar o log de eventos em um bloco de anotações do Azure Databricks ou no editor SQL. Use um bloco de anotações ou o editor SQL para executar as consultas de log de eventos de exemplo.
Unidade Catalog
Se o pipeline publicar tables no Unity Catalog, você deverá usar a função com valor event_log
table (TVF) para buscar o log de eventos para o pipeline. Você recupera o log de eventos de um pipeline passando a ID do pipeline ou um nome de table para o TVF. Por exemplo, para recuperar os registros de log de eventos para o pipeline com ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b
:
SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")
Para recuperar os registos do log de eventos do pipeline que criou ou possui o tablemy_catalog.my_schema.table1
:
SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))
Para chamar o TVF, você deve usar um cluster compartilhado ou um SQL warehouse. Por exemplo, você pode usar um bloco de anotações anexado a um cluster compartilhado ou usar o editor SQL conectado a um SQL warehouse.
Para simplificar a consulta de eventos para um pipeline, o proprietário do pipeline pode criar uma exibição sobre o event_log
TVF. O exemplo a seguir cria uma exibição sobre o log de eventos para um pipeline. Esse modo de exibição é usado nas consultas de log de eventos de exemplo incluídas neste artigo.
Nota
O event_log
TVF pode ser chamado apenas pelo proprietário do pipeline e uma visão criada sobre o event_log
TVF pode ser consultada apenas pelo proprietário do pipeline. A vista não pode ser partilhada com outros utilizadores.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");
Substitua <pipeline-ID>
pelo identifier exclusivo para o pipeline Delta Live Tables. Você pode encontrar o ID no painel de detalhes do Pipeline na interface do utilizador do Delta Live Tables.
Cada instância de uma execução de pipeline é chamada de update. Muitas vezes, você deseja extrair informações para o updatemais recente. Execute a consulta a seguir para localizar o identifier do update mais recente e salvá-lo no modo de exibição latest_update_id
temporário. Esse modo de exibição é usado nas consultas de log de eventos de exemplo incluídas neste artigo:
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;
Consultar informações de linhagem do log de eventos
Os eventos que contêm informações sobre linhagem têm o tipo flow_definition
de evento . O details:flow_definition
objeto contém o output_dataset
e input_datasets
definindo cada relação no gráfico.
Você pode usar a seguinte consulta para extrair os conjuntos de dados de entrada e saída para ver informações de linhagem:
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"] |
Consultar a qualidade dos dados a partir do registo de eventos
Se você definir expectativas em conjuntos de dados em seu pipeline, as métricas de qualidade de details:flow_progress.data_quality.expectations
dados serão armazenadas no objeto. Os eventos que contêm informações sobre a qualidade dos dados têm o tipo flow_progress
de evento . O exemplo a seguir consulta as métricas de qualidade de dados para o último pipeline update:
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 |
Monitore a lista de pendências de dados consultando o log de eventos
O Delta Live Tables rastreia a quantidade de dados presentes na lista de pendências no objeto details:flow_progress.metrics.backlog_bytes
. Os eventos que contêm métricas de lista de pendências têm o tipo flow_progress
de evento . O exemplo a seguir consulta métricas de lista de pendências para o último pipeline update:
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
Nota
As métricas da lista de pendências podem não estar disponíveis dependendo do tipo de fonte de dados do pipeline e da versão do Databricks Runtime.
Monitore eventos de dimensionamento automático aprimorados do log de eventos para pipelines sem habilitação sem servidor
Para pipelines DLT que não usam computação sem servidor, o log de eventos captura redimensionamentos de cluster quando o dimensionamento automático avançado está habilitado em seus pipelines. Os eventos que contêm informações sobre o dimensionamento automático avançado têm o tipo autoscale
de evento . As informações de solicitação de redimensionamento do details:autoscale
cluster são armazenadas no objeto. O exemplo a seguir consulta as solicitações de dimensionamento automático do cluster para a última linha de produção update:
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
Monitorar a utilização de recursos de computação
cluster_resources
Os eventos fornecem métricas sobre o número de slots de tarefas no cluster, quanto esses slots de tarefa são utilizados e quantas tarefas estão esperando para serem agendadas.
Quando o dimensionamento automático avançado está habilitado, cluster_resources
os eventos também contêm métricas para o algoritmo de dimensionamento automático, incluindo latest_requested_num_executors
, e optimal_num_executors
. Os eventos também mostram o status do algoritmo como diferentes estados, como CLUSTER_AT_DESIRED_SIZE
, SCALE_UP_IN_PROGRESS_WAITING_FOR_EXECUTORS
e BLOCKED_FROM_SCALING_DOWN_BY_CONFIGURATION
.
Essas informações podem ser visualizadas em conjunto com os eventos de dimensionamento automático para fornecer uma imagem geral do dimensionamento automático aprimorado.
O exemplo a seguir consulta o histórico de tamanho da fila de tarefas para o último pipeline update:
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
O exemplo a seguir consulta o histórico de utilização do último pipeline update:
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
O exemplo a seguir consulta o histórico de contagem do executor, acompanhado por métricas disponíveis apenas para pipelines de dimensionamento automático aprimorados, incluindo o número de executores solicitados pelo algoritmo na solicitação mais recente, o número ideal de executores recomendado pelo algoritmo com base nas métricas mais recentes e o estado do algoritmo de dimensionamento automático:
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
Auditar oleodutos Delta Live Tables pipelines
Você pode usar os registros de log de eventos do Delta Live Tables e outros logs de auditoria do Azure Databricks para get uma imagem completa de como os dados estão sendo atualizados no Delta Live Tables.
O Delta Live Tables usa o credentials do proprietário do pipeline para executar atualizações. Você pode alterar o credentials usado atualizando o proprietário do pipeline. O Delta Live Tables registra o usuário para ações no pipeline, incluindo criação de pipeline, edições na configuração e disparo de atualizações.
Consulte eventos do Unity Catalog para obter uma referência dos eventos de auditoria do Unity Catalog.
Consultar ações de utilizador no registo de eventos
Você pode usar o log de eventos para auditar eventos, por exemplo, ações do usuário. Os eventos que contêm informações sobre as ações do usuário têm o tipo user_action
de evento .
As informações sobre a ação são armazenadas no user_action
objeto no details
campo. Use a consulta a seguir para construir um log de auditoria de eventos do usuário. Para criar o event_log_raw
modo de exibição usado nessa consulta, consulte Consultando o log de eventos.
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 |
Informações sobre o tempo de execução
Você pode exibir informações de tempo de execução para um pipeline update, por exemplo, a versão do Databricks Runtime para o update:
SELECT details:create_update:runtime_version:dbr_version FROM event_log_raw WHERE event_type = 'create_update'
dbr_version |
---|
11.0 |