Informations de référence sur les tables système de calcul

Article
05/23/2024

Important

Cette fonctionnalité est disponible en préversion publique.

Cet article vous donne une vue d’ensemble des tables système de calcul, y compris les schémas et des exemples de requêtes. Il y a deux tables système de cluster disponibles actuellement : clusters et node_types.

Schéma de table de cluster

La table de cluster est une table de dimension à variation lente qui contient l’historique complet des configurations de cluster au fil du temps pour les clusters universels et les clusters de travaux.

La table système des clusters se trouve sur system.compute.clusters et a le schéma suivant :

Nom de la colonne	Type de données	Description	Exemple :
`account_id`	string	ID du compte où ce cluster a été créé.	`23e22ba4-87b9-4cc2-9770-d10b894b7118`
`workspace_id`	string	ID de l’espace de travail où ce cluster a été créé.	`1234567890123456`
`cluster_id`	string	ID du cluster pour lequel cet enregistrement est associé.	`0000-123456-xxxxxxxx`
`cluster_name`	string	Nom du cluster défini par l’utilisateur.	`My cluster`
`owned_by`	string	Nom d’utilisateur du propriétaire du cluster. Il s’agit du créateur du cluster par défaut, mais vous pouvez le changer avec l’API Clusters.	`sample_user@email.com`
`create_time`	timestamp	Horodatage du changement de cette définition de calcul.	`2023-01-09 11:00:00.000`
`delete_time`	timestamp	Horodatage de la suppression du cluster. La valeur est `null` si le cluster n’est pas supprimé.	`2023-01-09 11:00:00.000`
`driver_node_type`	string	Nom du type de nœud pilote. Correspond au nom du type d’instance du fournisseur de cloud.	`Standard_D16s_v3`
`worker_node_type`	string	Nom du type de nœud worker. Correspond au nom du type d’instance du fournisseur de cloud.	`Standard_D16s_v3`
`worker_count`	bigint	Nombre de workers. Défini uniquement pour les clusters de taille fixe.	`4`
`min_autoscale_workers`	bigint	Nombre de workers minimal défini. Ce champ est valide uniquement pour les clusters avec mise à l’échelle automatique.	`1`
`max_autoscale_workers`	bigint	Nombre de workers maximal. Ce champ est valide uniquement pour les clusters avec mise à l’échelle automatique.	`1`
`auto_termination_minutes`	bigint	Durée de fin automatique configurée.	`120`
`enable_elastic_disk`	boolean	État d’activation du disque avec mise à l’échelle automatique.	`true`
`tags`	map	Balises définies par l’utilisateur pour le cluster (n’inclut pas les balises par défaut).	`{"ResourceClass":"SingleNode"}`
`cluster_source`	string	Indique le créateur du cluster : `UI`, `API`, `JOB`, etc.	`UI`
`init_scripts`	tableau	Ensemble de chemins des scripts init.	`"/Users/example@email.com/files/scripts/install-python-pacakges.sh"`
`aws_attributes`	struct	Paramètres propres à AWS.	`null`
`azure_attributes`	struct	Paramètres propres à Azure.	`{` `"first_on_demand": "0",` `"availability": "ON_DEMAND_AZURE",` `"spot_bid_max_price": "—1"` `}`
`gcp_attributes`	struct	Paramètres propres à GCP. Ce champ est vide.	`null`
`driver_instance_pool_id`	string	ID du pool d’instances si le pilote est configuré par-dessus un pool d’instances.	`1107-555555-crhod16-pool-DIdnjazB`
`worker_instance_pool_id`	string	ID du pool d’instances si le worker est configuré par-dessus un pool d’instances.	`1107-555555-crhod16-pool-DIdnjazB`
`dbr_version`	string	Databricks Runtime du cluster.	`14.x-snapshot-scala2.12`
`change_time`	timestamp	Horodatage du changement de la définition de calcul.	`2023-01-09 11:00:00.000`
`change_date`	date	Date de changement. Utilisé pour la conservation des données.	`2023-01-09`

Schéma de la table des types de nœud

La table des types de nœud capture les types de nœud actuellement disponibles avec leurs informations matérielles de base. La table système des types de nœud se trouve sur system.compute.node_types et a le schéma suivant :

Nom de la colonne	Type de données	Description	Exemple :
`account_id`	string	ID du compte où ce cluster a été créé.	`23e22ba4-87b9-4cc2-9770-d10b894b7118`
`node_type_name`	string	Identificateur unique de ce type de nœud.	`Standard_D16s_v3`
`core_count`	double	Nombre de processeurs virtuels de l’instance.	`48.0`
`memory_mb`	long	Mémoire totale de l’instance.	`393216`
`gpu_count`	long	Nombre de processeurs graphiques de l’instance.	`0`

Limitations connues

Les clusters qui ont été marqués comme supprimés avant le 23 octobre 2023 ne sont pas indiqués dans la table des clusters. Cela peut entraîner des jointures à partir de la table system.billing.usage qui ne correspondent pas aux enregistrements de cluster dans la table des clusters. Tous les clusters actifs ont été renvoyés.
La table des clusters comprend uniquement les enregistrements des clusters universels et des clusters de travaux. Elle ne contient pas de clusters Delta Live Tables ni d’entrepôts SQL.

Exemples de requêtes

Vous pouvez utiliser les exemples de requêtes suivants pour répondre aux questions courantes sur les clusters :

Joindre les enregistrements de cluster et les enregistrements d’utilisation facturable
Attribuer les coûts d’un cluster au propriétaire du cluster

Remarque

Ces exemples joignent la table de clusters à la table system.billing.usage. Comme les enregistrements de facturation sont interrégionaux et que les enregistrements de cluster sont propres à la région, les enregistrements de facturation correspondent uniquement aux enregistrements de cluster de la région que vous interrogez. Pour voir les enregistrements d’une autre région, exécutez la requête dans cette région.

Joindre les enregistrements de cluster aux enregistrements de facturation les plus récents

Cette requête peut vous aider à comprendre les dépenses au fil du temps. Dès que vous mettez à jour usage_start_time sur la période de facturation la plus récente, il récupère les mises à jour les plus récentes des enregistrements de facturation à joindre aux données de clusters.

Chaque enregistrement est associé au propriétaire du cluster pendant cette exécution particulière. Par conséquent, si le propriétaire du cluster change, les coûts sont regroupés pour le propriétaire approprié en fonction de l’utilisation du cluster.

SELECT
  u.record_id,
  c.cluster_id,
  c.owned_by,
  c.change_time,
  u.usage_start_time,
  u.usage_quantity
FROM
  system.billing.usage u
  JOIN system.compute.clusters c
  JOIN (SELECT u.record_id, c.cluster_id, max(c.change_time) change_time
    FROM system.billing.usage u
    JOIN system.compute.clusters c
    WHERE
      u.usage_metadata.cluster_id is not null
      and u.usage_start_time >= '2023-01-01'
      and u.usage_metadata.cluster_id = c.cluster_id
      and date_trunc('HOUR', c.change_time) <= date_trunc('HOUR', u.usage_start_time)
    GROUP BY all) config
WHERE
  u.usage_metadata.cluster_id is not null
  and u.usage_start_time >= '2023-01-01'
  and u.usage_metadata.cluster_id = c.cluster_id
  and u.record_id = config.record_id
  and c.cluster_id = config.cluster_id
  and c.change_time = config.change_time
ORDER BY cluster_id, usage_start_time desc;

Attribuer les coûts d’un cluster au propriétaire du cluster

Si vous voulez réduire les coûts de calcul, vous pouvez utiliser cette requête pour déterminer les propriétaires de cluster dans votre compte qui utilisent les plus de DBU.

SELECT
  u.record_id record_id,
  c.cluster_id cluster_id,
  max_by(c.owned_by, c.change_time) owned_by,
  max(c.change_time) change_time,
  any_value(u.usage_start_time) usage_start_time,
  any_value(u.usage_quantity) usage_quantity
FROM
  system.billing.usage u
  JOIN system.compute.clusters c
WHERE
  u.usage_metadata.cluster_id is not null
  and u.usage_start_time >= '2023-01-01'
  and u.usage_metadata.cluster_id = c.cluster_id
  and c.change_time <= u.usage_start_time
GROUP BY 1, 2
ORDER BY cluster_id, usage_start_time desc;

Partager via