Observabilidade do Azure Databricks - System Tables Node_Timeline - Monitoramento de clusters #1

As System Tables do Databricks agrupam dados históricos (analíticos e operacionais) de todos seus workspaces em um único local, melhorando a sua observabilidade e monitoramento sem necessidade de ficar batendo nas APIs.

Vale ressaltar que as System tables só estão disponíveis para quem tem Unity Catalog habilitado, se você ainda não tem, corre.

Se você for no catálogo System encontrar possivelmente esses 11 schemas, possivelmente, pois, talvez você precise habilitar algum deles.

O nosso foco de hoje é para o schema Compute, dentro dele temos tabelas relacionada aos clusters, em específico vamos usar duas tabelas sendo uma delas a nova chamada node_timeline.

Vamos falar primeiro da tabela principal de Clusters (system.compute.clusters) ela é uma SCD (Slow changing dimension) que armazena o histórico de alterações dos seus clusters All purpose, Jobs Compute, DLT Compute e pipelines de manutenção (ex Predictive Optmization).

Nessa tabela então por ser uma SCD vamos encontrar mais de 1 linha para o mesmo cluster, sendo a mais recente (olhando pela coluna change_time) a versão mais recente do seu cluster.

Exemplo de um cluster que foi alterado o Auto Termination de 10 minutos para 15 minutos.

E o foco de hoje vai para a system table node_timeline (system.compute.node_timeline) que armazena 1 linha para cada minuto de uma instância ligada.

Para ficar mais claro, pense num cluster Single Node onde o Driver e Executor rodam na mesma VM, quando esse cluster estiver ligado, para cada minuto voce vai ter uma linha nessa tabela node_timeline com as métricas de performance a grupadas como CPU, Memoria, disco, rede etc.

Agora se seu cluster for Multi Node onde temos uma VM só para o Driver e N VMs para os Executors, você terá uma linha para o Driver separada dos Executors.

Somente com essas 2 tabelas podemos fazer inúmeras analises do nosso ambiente, além de monitorar a saúde dos clusters e poder pensar em melhorias, podemos pensar em coisas como:

1. Tempo total ligado por cluster por dia

2. Clusters que estão mais tempo ligados

3. Quais clusters estão mais onerados?

4. Quais horários de picos dos clusters?

5. Detectar sobrecarga nos Drivers

E muitas outras análises podem ser feitas, quem nunca precisou descobrir a média de utilização de um cluster e quanto tempo ele ficava ligado por dia e se deparava com a Metrics UI ou Event Logs, não é nada fácil minerar essa informação la dentro, agora podemos fazer isso via SQL.

Aqui alguns exemplos de análises que podemos fazer:

Quanto tempo um cluster fica ligado por dia? Nessa query filtro somente os Drivers, pois saberei quanto tempo o Cluster ficou ligado, não me interessa a informação dos Workers, aqui também já consigo ver uma média de utilização do Driver naquele dia.

Aqui o máximo que pode aparecer para um cluster é 1440 minutos por dia.

-- Filtra Somente Drivers
SELECT
cluster_name,
cast(start_time as date) as `date`,
count(*) as `minutes`,
avg(cpu_user_percent + cpu_system_percent) as `Avg CPU Utilization Driver`,
max(cpu_user_percent + cpu_system_percent) as `Peak CPU Utilization Driver`
FROM
system.compute.node_timeline nt
LEFT JOIN (
    SELECT *
    FROM (
        SELECT cluster_name, cluster_id,
               ROW_NUMBER() OVER (PARTITION BY cluster_id ORDER BY change_time DESC) AS rn
        FROM system.compute.clusters
    ) sub
    WHERE rn = 1
) c ON nt.cluster_id = c.cluster_id
WHERE start_time >= date_add(now(), -10) and driver = 'true'
GROUP BY all 
ORDER BY 2 desc, 3 desc;

Se quiser pode tentar validar essa informação na Metrics UI ou no Events Log, exemplo olhando no Metrics UI para confrontar as informações.

Você pode monitorar os clusters que estão mais onerados no dia a dia olhando pela sua métrica de performance média ou pelos picos para encontrar anomalias.

SELECT
cluster_name,
driver,
count(*) as `minutes`,
avg(cpu_user_percent + cpu_system_percent) as `Avg CPU Utilization`,
max(cpu_user_percent + cpu_system_percent) as `Peak CPU Utilization`,
        avg(cpu_wait_percent) as `Avg CPU Wait`,
        max(cpu_wait_percent) as `Max CPU Wait`,
        avg(mem_used_percent) as `Avg Memory Utilization`,
        max(mem_used_percent) as `Max Memory Utilization`,
avg(network_received_bytes)/(1024^2) as `Avg Network MB Received per Minute`,
avg(network_sent_bytes)/(1024^2) as `Avg Network MB Sent per Minute`
FROM
system.compute.node_timeline nt
LEFT JOIN (
    SELECT *
    FROM (
        SELECT cluster_name, cluster_id,
               ROW_NUMBER() OVER (PARTITION BY cluster_id ORDER BY change_time DESC) AS rn
        FROM system.compute.clusters
    ) sub
    WHERE rn = 1
) c
  ON nt.cluster_id = c.cluster_id
WHERE
        start_time >= date_add(now(), -1)
GROUP BY
        cluster_name,
        driver
ORDER BY
        3 desc;

Nessa visão note que você tem agrupado por Driver e Workers, pois se você não separar o Driver do Worker pode distorcer a sua análise.

Que achou dessas tabelas da system tables? Me conta aí que analises você acha que da pra fazer com elas?

Em breve trarei mais casos como esse.

#datainaction #databricks #systemtable #observability #monitoring