Muistiinpano
Tämän sivun käyttö edellyttää valtuutusta. Voit yrittää kirjautua sisään tai vaihtaa hakemistoa.
Tämän sivun käyttö edellyttää valtuutusta. Voit yrittää vaihtaa hakemistoa.
Important
This system table is in Public Preview.
Note
To have access to this table, your region must support predictive optimization. See Azure Databricks regions.
This article outlines the predictive optimization operation history table schema and provides sample queries. Predictive optimization optimizes your data layout for peak performance and cost efficiency. The system table tracks the operation history of this feature. For information on predictive optimization, see Predictive optimization for Unity Catalog managed tables.
Table path: This system table is located at system.storage.predictive_optimization_operations_history.
Delivery considerations
- The predictive optimization system table updates within two hours. However, billing information can take up to 24 hours to populate the data.
- Predictive optimization might run multiple operations on the same cluster. If so, the share of DBUs attributed to each of the multiple operations is approximated. This is why the
usage_unitis set toESTIMATED_DBU. Still, the total number of DBUs spent on the cluster will be accurate.
Predictive optimization table schema
The predictive optimization operation history system table uses the following schema:
| Column name | Data type | Description | Example |
|---|---|---|---|
account_id |
string | The ID of the account. | 11e22ba4-87b9-4cc2-9770-d10b894b7118 |
workspace_id |
string | The ID of the workspace in which predictive optimization ran the operation. | 1234567890123456 |
start_time |
timestamp | The time at which the operation started. Timezone information is recorded at the end of the value with +00:00 representing UTC. |
2023-01-09 10:00:00.000+00:00 |
end_time |
timestamp | The time at which the operation ended. Timezone information is recorded at the end of the value with +00:00 representing UTC. |
2023-01-09 11:00:00.000+00:00 |
metastore_name |
string | The name of the metastore to which the optimized table belongs. | metastore |
metastore_id |
string | The ID of the metastore to which the optimized table belongs. | 5a31ba44-bbf4-4174-bf33-e1fa078e6765 |
catalog_name |
string | The name of the catalog to which the optimized table belongs. | catalog |
schema_name |
string | The name of the schema to which the optimized table belongs. | schema |
table_id |
string | The ID of the optimized table. | 138ebb4b-3757-41bb-9e18-52b38d3d2836 |
table_name |
string | The name of the optimized table. | table1 |
operation_type |
string | The optimization operation performed. Must be one of the following values: COMPACTION, VACUUM, ANALYZE, CLUSTERING, AUTO_CLUSTERING_COLUMN_SELECTION, DATA_SKIPPING_COLUMN_SELECTION, COMPATIBILITY_MODE_REFRESH, DELETE, or PURGE. |
COMPACTION |
operation_id |
string | The ID for the optimization operation. | 4dad1136-6a8f-418f-8234-6855cfaff18f |
operation_status |
string | The status of the optimization operation. Must be one of the following values: SUCCESSFUL, FAILED: INTERNAL_ERROR, FAILED: AUTO_TTL_COLUMN_DOES_NOT_EXIST_ERROR, or FAILED: PRIVATE_LINK_SETUP_ERROR. |
SUCCESSFUL |
operation_metrics |
map[string, string] | The additional details about the specific optimization that was performed. See Operation metrics. | {"number_of_output_files":"100","number_of_compacted_files":"1000","amount_of_output_data_bytes":"4000","amount_of_data_compacted_bytes":"10000"} |
usage_unit |
string | The unit of usage incurred. Must be the following value: ESTIMATED_DBU. |
ESTIMATED_DBU |
usage_quantity |
decimal | The amount of the usage unit used. | 2.12 |
Operation metrics
The metrics recorded in the operation_metrics column vary depending on the operation type:
| Operation name | Operation description | Operation metrics | Description |
|---|---|---|---|
COMPACTION |
Improves query performance by optimizing file sizes. See Optimize data file layout. | number_of_compacted_files |
The number of files removed. |
amount_of_data_compacted_bytes |
The number of bytes removed. | ||
number_of_output_files |
The number of new files added. | ||
amount_of_output_data_bytes |
The number of bytes added. | ||
VACUUM |
Reduces storage costs by deleting data files no longer referenced by the table. See Remove unused data files with vacuum. | number_of_deleted_files |
The number of files garbage collected. |
amount_of_data_deleted_bytes |
The number of bytes garbage collected. | ||
ANALYZE |
Triggers incremental update of statistics to improve query performance. See ANALYZE TABLE … COMPUTE STATISTICS. | amount_of_scanned_bytes |
The number of bytes scanned. |
number_of_scanned_files |
The number of files scanned. | ||
staleness_percentage_reduced |
The reduction in the staleness percentage. This statistic can range from 0 to 100 based on the frequency that ANALYZE is run. |
||
CLUSTERING |
Triggers incremental clustering for enabled tables. See Use liquid clustering for tables. | number_of_removed_files |
The number of files removed. |
number_of_clustered_files |
The number of new files added. | ||
amount_of_data_removed_bytes |
The number of bytes removed. | ||
amount_of_clustered_data_bytes |
The number of bytes added. | ||
AUTO_CLUSTERING_COLUMN_SELECTION |
Evaluates whether to evolve clustering columns. See Automatic liquid clustering. | old_clustering_columns |
The previous data layout, which can be old clustering keys or "None" if unpartitioned. |
new_clustering_columns |
The new clustering columns. | ||
has_column_selection_changed |
The indicator of whether the clustering columns changed. | ||
additional_reason |
The reasons for the change or no change in clustering columns. | ||
DATA_SKIPPING_COLUMN_SELECTION |
Detects columns with missing data skipping statistics from workload and backfills them. See Data skipping. | amount_of_scanned_bytes |
The number of bytes scanned. |
number_of_scanned_files |
The number of files scanned. | ||
added_data_skipping_columns |
The data skipping columns added. | ||
removed_data_skipping_columns |
The data skipping columns removed. | ||
old_data_skipping_columns |
The previous exhaustive list of data skipping columns. | ||
new_data_skipping_columns |
The current exhaustive list of data skipping columns. | ||
COMPATIBILITY_MODE_REFRESH |
Detects whether Compatibility Mode is out of date and refreshes the table. See Compatibility Mode. | N/A | The Compatibility Mode refresh operations. |
DELETE |
Removes rows that have passed the auto time-to-live expiration period. See Automatic row deletion with auto time-to-live. | number_of_deleted_rows |
The number of rows removed. This is 0 when no rows were eligible for deletion. |
amount_of_data_deleted_bytes |
The number of bytes removed. | ||
PURGE |
Rewrites data files to physically remove rows already deleted with deletion vectors. Runs before VACUUM on tables with deletion vectors enabled. See Automatic row deletion with auto time-to-live. |
number_of_purged_rows |
The number of rows purged. This is 0 when no rows were eligible to purge. See Automatic row deletion with auto time-to-live. |
Example queries
The following sections include sample queries you can use to gain insights into the predictive optimization system table. For these queries to work, you need to replace the parameter values with your own values.
This article includes the following example queries:
- How many estimated DBUs has predictive optimization used in the last 30 days?
- On which tables did predictive optimization spend the most in the last 30 days (estimated cost)?
- On which tables is predictive optimization performing the most operations?
- For a given catalog, how many total bytes have been compacted?
- What tables had the most bytes vacuumed?
- What is the success rate for operations run by predictive optimization?
How many estimated DBUs has predictive optimization used in the last 30 days?
SELECT SUM(usage_quantity)
FROM system.storage.predictive_optimization_operations_history
WHERE
usage_unit = "ESTIMATED_DBU"
AND timestampdiff(day, start_time, Now()) < 30;
To find the same value for a specific ETL pipeline, you can first find the tables in that pipeline, and then search for the DBUs:
-- 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;
On which tables did predictive optimization spend the most in the last 30 days (estimated cost)?
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;
On which tables is predictive optimization performing the most operations?
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;
For a given catalog, how many total bytes have been compacted?
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;
What tables had the most bytes vacuumed?
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;
What is the success rate for operations run by predictive optimization?
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;