Skip to main content

Overview

The Metrics view helps you understand both the current health of an Iceberg table and the impact of optimization runs.

There are two types of metrics:

  • Table Metrics – always available for a table, showing its current state.
  • Run Metrics – measurements for a single optimization run: input vs output data and delete files (counts and sizes) for that run.

Table Metrics

You can see table-level metrics from the Tables page by clicking the View Metrics button for a table.

Table metrics button

These metrics describe the current layout and size of the Iceberg table:

Table metrics view

MetricDescription
File CountTotal number of data and delete files that currently make up the table.
Total SizeCombined on-disk size of all files that belong to the table.
Average File SizeAverage size of files; useful to see if the table has many small files.
Last Commit TimeTime of the last successful Iceberg commit for the table.
Data Files CountNumber of data files that store actual table rows.
Delete Files CountNumber of delete files(equality+position) that track removed or filtered-out rows.
Health ScoreCombined score based on Small Files Score, Eq Delete Score, and Pos Delete Score.
Health Score appears in the Tables page, not in the View Metrics modal.

Health Score column on the Tables page

Run Metrics

Run Metrics describe what one optimization run did to the table: how many data and delete files went in, and how many data and delete files came out. Open them from the Runs page via the View Metrics action for the run you want to inspect.

Run metrics view

These metrics help you see how much a specific run improved the table:

Run metrics view

Size units

All size fields in Table metrics and Run metrics are shown in bytes.

MetricDescription
Input data filesCount of input data files
Input data sizeTotal size of input data files
Input equality delete filesCount of input equality delete files (Count of equality delete files in the current snapshot * No.of sub-tasks)
Input equality delete sizeTotal size of input equality delete files
Input position delete filesCount of input position delete files (Count of position delete files in the current snapshot * No.of sub-tasks)
Input position delete sizeTotal size of input position delete files
Output data filesCount of output data files produced
Output data sizeTotal size of output data files produced
Output delete filesCount of output delete files produced
Output delete sizeTotal size of output delete files produced

Interpreting Metrics

  • A high Delete Files Count or very low Average File Size can indicate fragmentation and metadata overhead.
  • After a successful optimization run, compare Input vs Output.
  • A smaller Output delete size (and/or fewer Output delete files) typically indicates the run reduced delete-file fragmentation.
  • Changes in Input/Output data file counts and data size show how much data was rewritten/compacted for that run’s scope.


💡 Join the OLake Community!

Got questions, ideas, or just want to connect with other data engineers?
👉 Join our Slack Community to get real-time support, share feedback, and shape the future of OLake together. 🚀

Your success with OLake is our priority. Don’t hesitate to contact us if you need any help or further clarification!