Référence de la table système d'optimisation prédictive
Aperçu
Cette table système est en aperçu public.
Pour avoir accès à cette table, votre région doit prendre en charge l'optimisation prédictive. Voir clouds et régions Databricks.
Cet article décrit le schéma de la table d'historique des opérations d'optimisation prédictive et fournit des exemples de requêtes. L'optimisation prédictive optimise le layout de vos données pour des performances optimales et une efficacité des coûts. La table du système enregistre l'historique des opérations de cette fonctionnalité. Pour plus d'informations sur l'optimisation prédictive, consultez l'optimisation prédictive pour les tables gérées par Unity Catalog.
**Chemin de la table** : Cette table système est située system.storage.predictive_optimization_operations_history à.
Considérations de livraison
- La table système d'optimisation prédictive se met à jour dans un délai de deux heures. Toutefois, les informations de facturation peuvent prendre jusqu'à 24 heures pour que les données soient renseignées.
- L'optimisation prédictive peut exécuter plusieurs opérations sur le même cluster. Dans ce cas, la part des DBU attribuées à chacune des opérations multiples est approximée. C'est pourquoi le
usage_unitest défini surESTIMATED_DBU. Néanmoins, le nombre total d'unités de consommation (DBU) dépensées sur le cluster sera précis.
Schéma de table d'optimisation prédictive
La table système d’historique des opérations d’optimisation prédictive utilise le schéma suivant :
Nom de colonne | Type de données | Description | Exemple |
|---|---|---|---|
| chaîne | L'ID du compte. |
|
| chaîne | L'ID du workspace dans lequel l'optimisation prédictive a exécuté l'opération. |
|
| Horodatage | L'heure à laquelle l'Opération a start. Les informations de fuseau horaire sont enregistrées à la fin de la valeur, où |
|
| Horodatage | L'heure à laquelle l'opération s'est terminée. Les informations de fuseau horaire sont enregistrées à la fin de la valeur, où |
|
| chaîne | Le nom du métastore auquel la table optimisée appartient. |
|
| chaîne | L'ID du métastore auquel appartient la table optimisée. |
|
| chaîne | Le nom du catalogue auquel la table optimisée appartient. |
|
| chaîne | Le nom du schéma auquel appartient la table optimisée. |
|
| chaîne | L'ID de la table optimisée. |
|
| chaîne | Le nom de la table optimisée. |
|
| chaîne | L’opération d’optimisation effectuée. Doit faire partie des valeurs suivantes : |
|
| chaîne | L'ID de l'opération d'optimisation. |
|
| chaîne | L'état de l'opération d'optimisation. Doit être l'une des valeurs suivantes : |
|
| map[chaîne, chaîne] | Les détails supplémentaires concernant l'optimisation spécifique qui a été effectuée. Voir Métriques des Opérations. |
|
| chaîne | L'unité d'utilisation facturée. Doit être la valeur suivante : |
|
| décimal | La quantité d'unités d'utilisation consommées. |
|
Métriques des opérations
Les métriques enregistrées dans la colonne operation_metrics varient en fonction du type d'opération :
Nom de l'opération | Description des opérations | Métriques des opérations | Description |
|---|---|---|---|
| Améliore les performances des requêtes en optimisant la taille des fichiers. Voir Optimiser le Layout des fichiers de données. |
| Le nombre de fichiers supprimés. |
| Le nombre d'octets supprimés. | ||
| Nombre de nouveaux fichiers ajoutés. | ||
| Le nombre d’octets ajoutés. | ||
| Réduit les coûts de stockage en supprimant les fichiers de données qui ne sont plus référencés par la table. Consultez Supprimer les fichiers de données inutilisés avec vacuum. |
| Le nombre de fichiers collectés par la récupération de mémoire. |
| Le nombre d’octets récupérés par la collecte des déchets. | ||
| Trigger la mise à jour incrémentielle des statistiques pour améliorer les performances des requêtes. Voir ANALYZE TABLE … COMPUTE STATISTICS. |
| Le nombre d’octets analysés. |
| Nombre de fichiers analysés. | ||
| La réduction du pourcentage d'obsolescence. Cette statistique peut varier de 0 à 100 en fonction de la fréquence d'exécution de | ||
| Déclenche le clustering incrémental pour les tables activées. Voir Utiliser le clustering liquide pour les tables. |
| Le nombre de fichiers supprimés. |
| Nombre de nouveaux fichiers ajoutés. | ||
| Le nombre d'octets supprimés. | ||
| Le nombre d’octets ajoutés. | ||
| Évalue la nécessité de faire évoluer les colonnes de clusters. Voir le clustering liquide automatique. |
| La Layout des données précédente, qui peut correspondre à d’anciennes clés de clustering ou à « None » si elles ne sont pas partitionnées. |
| Les nouvelles colonnes de clustering. | ||
| L’indicateur précisant si les colonnes de clustering ont été modifiées. | ||
| Les raisons du changement ou de l’absence de changement dans les colonnes de clustering. | ||
| Détecte les colonnes avec des données manquantes, en ignorant les statistiques de la charge de travail, et les remplit. Voir Saut de données. |
| Le nombre d’octets analysés. |
| Nombre de fichiers analysés. | ||
| Les colonnes d'évitement de données ajoutées. | ||
| Les colonnes d'évitement de données supprimées. | ||
| La liste exhaustive précédente des colonnes de saut de données. | ||
| La liste exhaustive actuelle des colonnes d’omission de données. | ||
| Détecte si le Mode de compatibilité est obsolète et refresh la table. Consultez Mode de compatibilité. | N/A | Les opérations de refresh du Mode de compatibilité. |
| Supprime les lignes ayant dépassé la période d'expiration de la durée de vie automatique. Voir Suppression automatique des lignes avec durée de vie automatique. |
| Le nombre de lignes supprimées. Ceci est |
| Le nombre d'octets supprimés. | ||
| Réécrit les fichiers de données pour supprimer physiquement les lignes déjà supprimées avec des vecteurs de suppression. S'exécute avant |
| Le nombre de lignes purgées. Ceci est |
Exemples de requêtes
Les sections suivantes incluent des exemples de queries que vous pouvez utiliser pour obtenir des insights sur la table système d'optimisation prédictive. Pour que ces queries fonctionnent, vous devez remplacer les valeurs des parameters par vos propres valeurs.
Cet article comprend les exemples de queries suivants :
- Combien de DBU estimées l'optimisation prédictive a-t-elle utilisées au cours des 30 derniers jours ?
- Sur quelles tables l'optimisation prédictive a-t-elle le plus dépensé au cours des 30 derniers jours (coût estimé) ?
- Sur quelles tables l'optimisation prédictive effectue-t-elle le plus d'Opérations ?
- Pour un catalogue donné, combien d'octets au total ont été compactés ?
- Quelles tables ont eu le plus d'octets vacuum ?
- Quel est le taux de réussite des Opérations exécutées par l'optimisation prédictive ?
Combien de DBUs estimées l'optimisation prédictive a-t-elle utilisées au cours des 30 derniers jours ?
SELECT SUM(usage_quantity)
FROM system.storage.predictive_optimization_operations_history
WHERE
usage_unit = "ESTIMATED_DBU"
AND timestampdiff(day, start_time, Now()) < 30;
Pour trouver la même valeur pour un pipeline ETL spécifique, vous pouvez d'abord trouver les tables dans ce pipeline, puis rechercher les DBU :
-- Find all full table names for the pipeline:
WITH pipeline_mapping AS (
SELECT DISTINCT target_table_full_name AS target_table_name
FROM system.access.table_lineage
WHERE entity_type = 'PIPELINE' AND entity_id = :pipeline_id
)
-- Select all operations for any table in that pipeline:
SELECT SUM(usage_quantity)
FROM system.storage.predictive_optimization_operations_history
WHERE
CONCAT_WS('.', catalog_name, schema_name, table_name)
IN ( SELECT target_table_name FROM pipeline_mapping)
AND usage_unit = "ESTIMATED_DBU"
AND timestampdiff(day, start_time, Now()) < 30;
Sur quelles tables l'optimisation prédictive a-t-elle le plus dépensé au cours des 30 derniers jours (coût estimé) ?
SELECT
metastore_name,
catalog_name,
schema_name,
table_name,
SUM(usage_quantity) as totalDbus
FROM system.storage.predictive_optimization_operations_history
WHERE
usage_unit = "ESTIMATED_DBU"
AND timestampdiff(day, start_time, Now()) < 30
GROUP BY ALL
ORDER BY totalDbus DESC;
Sur quelles tables l'optimisation prédictive effectue-t-elle le plus d'Opérations ?
SELECT
metastore_name,
catalog_name,
schema_name,
table_name,
operation_type,
COUNT(DISTINCT operation_id) as operations
FROM system.storage.predictive_optimization_operations_history
GROUP BY ALL
ORDER BY operations DESC;
Pour un catalogue donné, combien d'octets au total ont été compactés ?
SELECT
schema_name,
table_name,
SUM(operation_metrics["amount_of_data_compacted_bytes"]) as bytesCompacted
FROM system.storage.predictive_optimization_operations_history
WHERE
metastore_name = :metastore_name
AND catalog_name = :catalog_name
AND operation_type = "COMPACTION"
GROUP BY ALL
ORDER BY bytesCompacted DESC;
Quelles tables contenaient le plus d’octets vacuum ?
SELECT
metastore_name,
catalog_name,
schema_name,
table_name,
SUM(operation_metrics["amount_of_data_deleted_bytes"]) as bytesVacuumed
FROM system.storage.predictive_optimization_operations_history
WHERE operation_type = "VACUUM"
GROUP BY ALL
ORDER BY bytesVacuumed DESC;
Quel est le taux de réussite des Opérations exécutées par l'optimisation prédictive ?
WITH operation_counts AS (
SELECT
COUNT(DISTINCT (CASE WHEN operation_status = "SUCCESSFUL" THEN operation_id END)) as successes,
COUNT(DISTINCT operation_id) as total_operations
FROM system.storage.predictive_optimization_operations_history
)
SELECT successes / total_operations as success_rate
FROM operation_counts;