http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> Hi in 3.5.17 version min/max values...
# questions-and-troubleshooting
z
@Rocky Hi in 3.5.17 version min/max values on iceberg tables gives "<failed to load> java.lang.NumberFormatException: Invalid integer format for value '�9�3' at com.mysql.cj.protocol.a.MysqlTextValueDecoder.getLong(MysqlTextValueDecoder.java:241) at com.mysql.cj.protocol.a.MysqlTextValueDecoder.getInt(MysqlTextValueDecoder.java:170) at com.mysql.cj.protocol.a.MysqlTextValueDecoder.getTimestamp(MysqlTextValueDecoder.java:376) at com.mysql.cj.protocol.a.MysqlTextValueDecoder.decodeDatetime(MysqlTextValueDecoder.java:86) at com.mysql.cj.protocol.result.AbstractResultsetRow.decodeAndCreateReturnValue(AbstractResultsetRow.java:78) at com.mysql.cj.protocol.result.AbstractResultsetRow.getValueFromBytes(AbstractResultsetRow.java:235) at com.mysql.cj.protocol.a.result.TextBufferRow.getValue(TextBufferRow.java:122) at com.mysql.cj.jdbc.result.ResultSetImpl.getString(ResultSetImpl.java:909) in JdbcHelperImpl.createUnparsedValue(JdbcHelperImpl.java:375) ",0000-01-01 000000
r
The error you are encountering—`java.lang.NumberFormatException: Invalid integer format for value '93'`—indicates that your SQL client (likely a GUI tool like DBeaver or DataGrip using the MySQL JDBC driver) is receiving binary data for a field it expects to be a numeric or date/time type. The specific characters 
93
are the UTF-8 replacement characters for invalid bytes, which strongly suggests that StarRocks is returning raw binary metadata (Iceberg statistics) in a column where the client expects a formatted string or timestamp. Why this is happening This issue typically occurs when querying Iceberg Metadata Tables (such as 
my_table$files
or 
my_table$partitions
) or when a GUI tool attempts to "load statistics" or "metadata" for an Iceberg table in the background. 1. Binary Stats: Iceberg stores column min/max bounds as raw binary in its manifest files. 2. Metadata Tables: In StarRocks versions around 3.5.x, the 
$files
metadata table includes columns like 
lower_bounds
and 
upper_bounds
which are maps of binary data. 3. Driver Mismatch: The MySQL JDBC driver (specifically 
MysqlTextValueDecoder
as seen in your stack trace) tries to decode these bytes into a readable format. If the driver thinks the column is a 
TIMESTAMP
or 
LONG
based on the metadata StarRocks provides, but the bytes are the raw Iceberg physical encoding, the parser fails. Suggested Workarounds 1. Avoid GUI Metadata/Stats Tabs: If you are seeing this error while clicking through table properties in a tool like DBeaver, avoid the "Statistics" or "Data" tab for Iceberg metadata tables. 2. Explicit Selection: If you are querying metadata tables manually (e.g., 
SELECT _ FROM table$files
), do not use 
_
. Explicitly select the columns you need and skip binary columns like 
lower_bounds
, 
upper_bounds
, or 
partition_summaries
. 3. Check FE Configuration: In some 3.5.x versions, StarRocks introduced optimizations for Iceberg min/max values. Try setting the following session variable to see if it bypasses the issue for query execution:
Copy code
sql
    SET statistic_use_meta_statistics = false;
4. Version Update: Note that StarRocks 3.5.17 included several fixes for Iceberg statistics (#71913, #71856). However, if you are still seeing this, it may be a regression or a mismatch in how metadata types are reported to the MySQL protocol. There was a related fix in more recent versions (#69207) that corrected how Iceberg file bounds are populated with logical values instead of physical bytes. Recommendation If this error prevents you from querying the table normally (not just metadata), please provide the specific query you are running. If it only occurs in a GUI tool, it is likely a bug in the metadata serialization for Iceberg tables in that specific patch. You may want to report this on the StarRocks GitHub or Slack community, as 
3.5.17
is a very recent release-specific context. References • quick_start/iceberg.md • data_source/catalog/iceberg/iceberg_meta_table.md • sql-reference/data-types/numeric/BIGINT.md • sql-reference/data-types/numeric/INT.md • data_source/catalog/iceberg/iceberg_catalog.md
z
@Rocky
Copy code
SELECT MIN(_kafka_timestamp), MAX(_kafka_timestamp) from table1
r
This error occurs because of an optimization in StarRocks that attempts to answer `MIN`/`MAX` queries on Iceberg tables by reading statistics (min/max bounds) directly from Iceberg manifest files instead of scanning the data. In some versions (including 3.5.x), if the column type (like your 
_kafka_timestamp
) contains binary-encoded metadata that isn't correctly decoded by the Frontend (FE) before being sent to the client, the MySQL JDBC driver throws a 
NumberFormatException
while trying to parse those raw bytes as a number or timestamp. Immediate Workaround You can disable this metadata-only optimization for your session to force StarRocks to scan the data files (which will resolve the decoding error):
Copy code
sql
SET enable_iceberg_metadata_query_optimization = false;
If the error persists, you can also try disabling the use of external metadata for statistics:
Copy code
sql
SET enable_get_stats_from_external_metadata = false;
Why this happens 1. Binary Stats: Iceberg manifest files store column bounds as raw physical bytes (e.g., Parquet encoding). 2. Decoding Issue: When the `MIN`/`MAX` optimization is active, StarRocks FE reads these bytes. If there is a mismatch in how it interprets the 
_kafka_timestamp
type (often a 
BIGINT
or 
DATETIME
), it may pass the raw binary string back to your SQL client. 3. Driver Failure: Your SQL client (likely using the MySQL Connector/J driver) receives these bytes (indicated by the 
93
characters in your error, which are UTF-8 replacement characters for non-textual bytes) and fails when it tries to call 
getLong()
or 
getTimestamp()
on them. Known Fixes This behavior is often related to a bug where Iceberg file bounds were populated with physical encoding bytes instead of logical typed values (related to StarRocks issue #69207). * If your table was populated using the 
add_files
procedure, this is a known risk. * More comprehensive fixes for 
DATETIME
min/max optimizations on Iceberg were introduced in later versions (e.g., StarRocks 4.0+ / PR #71870). If you are on an LTS version like 3.5.17, it is recommended to check for more recent 3.5.x patch releases (such as 3.5.20+) which may contain backported fixes for Iceberg metadata decoding. References • data_source/catalog/iceberg/iceberg_catalog.md • sql-reference/System_variable.md • release_notes/release-2.4.md • using_starrocks/Cost_based_optimizer.md • release_notes/release-3.2.md
z
@Rocky table is partitioned may be thats the issue?
r
Yes, the fact that your table is partitioned is likely the direct cause of this specific error in version 3.5.17. Why Partitioning Matters When you run 
SELECT MIN(col), MAX(col)
on a partitioned Iceberg table, StarRocks attempts an optimization called Metadata Query Optimization. Instead of reading the actual data files, it tries to answer the query by looking at the Partition Summaries stored in the Iceberg manifest files. The problem in version 3.5.x is a known bug in how StarRocks decodes those partition values: 1. Binary Encoding: Iceberg stores partition values (especially timestamps or bigints) as raw binary bytes in the manifest. 2. Decoding Failure: In 3.5.17, the FE (Frontend) may fail to correctly decode these bytes into a readable timestamp string. Instead, it passes the raw, unparsed bytes to your SQL client. 3. Driver Error: Your MySQL JDBC driver receives these raw bytes (represented as 
93
in your error message) and attempts to parse them as a standard integer or timestamp format. Since 
93
is not a valid number/date string, it throws the 
java.lang.NumberFormatException
. How to Fix It You can bypass this metadata-level bug by forcing StarRocks to read the data files instead of the manifest summaries. Run this command before your query:
Copy code
sql
-- Disable the optimization that reads MIN/MAX from Iceberg metadata
SET enable_iceberg_metadata_query_optimization = false;
Permanent Resolution * Check your Data Type: Ensure 
_kafka_timestamp
is defined as a consistent type (e.g., 
BIGINT
or 
DATETIME
) across both the StarRocks schema and the underlying Iceberg table. * Upgrade: This issue is addressed in more recent patches of the 3.5.x line and in the 4.0+ versions (see StarRocks issues #69207 and #69880). Updating to the latest 3.5.x patch (e.g., 3.5.20 or later) is recommended if you want to use this optimization safely. * Re-sync Metadata: If you recently used a procedure like 
add_files
to populate this table, the metadata bounds might have been written in an incompatible format. Running a 
REFRESH EXTERNAL TABLE table1
might help, though disabling the variable above is the most reliable immediate fix. References • quick_start/iceberg.md • data_source/catalog/iceberg/DML.md • data_source/catalog/iceberg/iceberg_catalog.md
z
@Rocky I dont have this variable in 3.5.17 SET enable_iceberg_metadata_query_optimization = false;
r
In StarRocks version 3.5.x, the error you are seeing—`java.lang.NumberFormatException: Invalid integer format for value '93'`—is a known issue caused by an optimization called Metadata Query Optimization (also known as MetaScan). Why this is happening When you run a simple 
SELECT MIN(col), MAX(col)
on an Iceberg table, StarRocks attempts to answer the query by reading the 
lower_bounds
and 
upper_bounds
directly from the Iceberg manifest files instead of scanning the actual data files. In version 3.5.17 (and some earlier 3.x patches), the Frontend (FE) may fail to decode these bounds correctly if they are stored in the manifest using certain physical encodings (like those produced by Spark or StarRocks' own 
add_files
procedure). Instead of sending a formatted string or timestamp to your SQL client, it sends the raw binary bytes. Your MySQL JDBC driver then attempts to parse these bytes as a number or date, leading to the 
NumberFormatException
. Solution: Disable the Optimization If 
enable_iceberg_metadata_query_optimization
is not recognized in your specific build of 3.5.17, the variable is likely named without the "iceberg" prefix. Try the following session variables to force a data scan (which will return correct results): 1. Primary Variable:
Copy code
sql
    SET enable_metadata_query_optimization = false;
2. Fallback (if the above doesn't work):
Copy code
sql
    SET enable_get_stats_from_external_metadata = false;
    SET enable_iceberg_column_statistics = false;
Permanent Fix * Upgrade: This decoding issue has been refined in later 3.5.x patches (specifically related to issues #71856 and #71870). Check for StarRocks 3.5.20 or later, where better support for Iceberg datetime and partition-level min/max decoding was backported. * Refresh Metadata: If the table metadata was corrupted during an ingestion process (like 
add_files
), try refreshing the table to re-sync the statistics:
Copy code
sql
    REFRESH EXTERNAL TABLE table1;
Summary of variables for Iceberg in 3.5.x: • `enable_metadata_query_optimization`: Controls whether simple aggregations (`min`/`max`/`count`) use metadata-only scans. • `plan_mode`: Can be set to 
distributed
or 
local
to change how metadata is parsed, which sometimes bypasses local decoding bugs. • `enable_get_stats_from_external_metadata`: Controls whether the optimizer uses Iceberg manifest stats for query planning. References • sql-reference/System_variable.md • data_source/catalog/iceberg/iceberg_catalog.md • release_notes/release-3.5.md • data_source/catalog/iceberg/iceberg_meta_table.md References • sql-reference/System_variable.md
z
@Rocky Ive disabled this SET enable_iceberg_column_statistics = false; and it didnt help
r
z
@Rocky may be I can manually delete external column stats for this table?
r
Yes, you can manually delete the statistics that StarRocks has collected for your external Iceberg table. In StarRocks 3.5.x, statistics for external tables are stored in the internal system table 
default_catalog._statistics_.external_column_statistics
. 1. How to Delete Statistics You can delete the statistics using the following SQL command:
Copy code
sql
-- Delete basic statistics (min, max, ndv, null_count) for the entire table
DROP STATS [catalog_name.][db_name.]table_name;
If you only want to check what is stored before deleting, you can query the system table:
Copy code
sql
SELECT * FROM default_catalog._statistics_.external_column_statistics 
WHERE table_name = 'your_table_name';
2. Why this might not fix the "93" error Even if you delete these statistics, the 
NumberFormatException: Invalid integer format for value '93'
may persist. This is because StarRocks has two ways of getting metadata for queries like `MIN/MAX`: 1. StarRocks Statistics: These are the stats you just deleted (stored in the 
_statistics_
database). 2. Iceberg Manifest Summaries (MetaScan): This is the direct optimization where the StarRocks Frontend (FE) reads the 
lower_bounds
and 
upper_bounds
from the Iceberg 
.avro
manifest files on your storage (S3/HDFS/OSS). The error involving "93" (which is the ASCII character 
]
) usually indicates the FE is failing to decode the binary-encoded bounds inside the Iceberg manifest file itself. Deleting StarRocks' internal stats doesn't remove the data from the manifest files. 3. Better Variables to Try (StarRocks 3.5.17) If 
enable_iceberg_column_statistics
didn't work and you don't have 
enable_iceberg_metadata_query_optimization
, try these exact names which were standard in the 3.5.x line:
Copy code
sql
-- This is the most likely variable to stop the FE from reading bounds from manifests
SET enable_metadata_query_optimization = false;

-- Disable using stats from the external metastore/manifests for planning
SET enable_get_stats_from_external_metadata = false;

-- Force the use of the scan-based approach
SET enable_column_statistics = false;
Summary Recommendation 1. Run 
DROP STATS your_table;
to clear the StarRocks cache. 2. Run 
SET enable_metadata_query_optimization = false;
to stop the engine from trying to be "smart" with the Iceberg manifest files. 3. If the query works after step 2, it confirms the bug is in the Iceberg Manifest decoding (MetaScan). This is a known issue in some 3.5 patches when handling specific Iceberg encoding versions and was fixed in later 3.5.x sub-versions (3.5.20+). References • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cbo_stats/DROP_STATS.md • sql-reference/System_variable.md References • administration/management/FE_configuration.md • sql-reference/System_variable.md • administration/management/BE_configuration.md
z
@Rocky even drop stats does not help
r
z
@Rocky even DROP stats does not help!
r
The reason 
DROP STATS
didn't help is that StarRocks uses two different layers of statistics for Iceberg tables: 1. Internal StarRocks Stats: These are statistics collected by StarRocks and stored in its own system tables (cleared by 
DROP STATS
). 2. Iceberg Native Metadata (MetaScan): These are the 
min
, 
max
, and 
null_count
values stored directly in the Iceberg 
.avro
manifest files on your storage (S3/HDFS). The 
NumberFormatException: Invalid integer format for value '93'
error occurs because the StarRocks Frontend (FE) is trying to parse the binary-encoded bounds in your Iceberg manifests and failing to decode them into the expected type. Deleting internal stats doesn't fix this because the engine is still reading the "faulty" metadata directly from the manifest files to optimize the query. Recommended Fix: Disable Metadata Optimizations To bypass this error, you need to tell StarRocks to stop using the metadata from the manifest files for query planning. Run these session variables before your query:
Copy code
sql
-- 1. Disable the engine's attempt to answer queries using ONLY metadata
SET enable_metadata_query_optimization = false;

-- 2. Stop StarRocks from reading manifest min/max/ndv for planning
SET enable_get_stats_from_external_metadata = false;

-- 3. Clear the FE's metadata cache for this specific table
REFRESH EXTERNAL TABLE catalog_name.db_name.table_name;
Why "93"? The value 
93
is the ASCII code for the character 
]
. This suggests that the FE is reading raw bytes from a binary field (likely a column with a complex type or a decimal/int encoding it doesn't recognize) and trying to pass them to a string-to-integer parser. This is a known issue in some 3.5.x versions when handling specific Iceberg metadata encodings (e.g., bug #69207) and is typically fixed by upgrading to a later patch of 3.5 (v3.5.20+) or v4.x. If you still want to "delete" the stats: There is no way to "delete" the stats from the Iceberg manifest files via StarRocks; those files are managed by the writer (e.g., Spark, Flink, or StarRocks 
INSERT
). * If you can, try to rewrite the Iceberg manifests from the writer side (e.g., using Spark's 
rewriteManifests
action). * Alternatively, check if the table has a Schema Evolution history where a column type was changed from a string to an integer, as this often causes the manifest decoder to trip. If the session variables above do not work, please check if 
enable_iceberg_metadata_distributed_plan
is set to 
true
and try setting it to 
false
. References • administration/management/FE_configuration.md • release_notes/release-3.5.md • sql-reference/System_variable.md • administration/management/BE_configuration.md
z
@Rocky enable_min_max_optimization = false this helped and why?
r
The reason 
SET enable_min_max_optimization = false;
worked where 
DROP STATS
failed is that it targets the source of the faulty data rather than the cache. Why this helped In StarRocks, the 
enable_min_max_optimization
variable controls whether the engine uses Zonemaps (min/max values) to prune data at the planning or scan stage. For Iceberg tables, StarRocks tries to be efficient by reading the 
lower_bounds
and 
upper_bounds
directly from the Iceberg Manifest files (
.avro
files) stored on your S3/HDFS. 1. The Source of the Error: The error 
NumberFormatException: Invalid integer format for value '93'
happens because the StarRocks Frontend (FE) is trying to decode a binary-encoded bound from the Iceberg manifest and interpret it as an integer. The value 
"93"
is actually the ASCII character 
]
. The FE is essentially "misreading" the binary metadata. 2. Why 
DROP STATS
didn't work: 
DROP STATS
only deletes the statistics StarRocks manually collected and stored in its internal 
_statistics_
database. It does not modify or hide the metadata that is natively part of the Iceberg manifest files. 3. What the optimization toggle does: By setting 
enable_min_max_optimization = false
, you are telling the StarRocks optimizer: "Do not look at the min/max values in the manifest files to prune data." This forces StarRocks to skip the buggy decoding logic and just scan the data files directly, which avoids the crash. Is there a permanent fix? While this session variable is a valid workaround, it may lead to slower query performance because StarRocks can no longer "skip" reading files that don't match your 
WHERE
clause filters. To fix this permanently without losing performance, you should: * Check for Schema Evolution: This error often occurs if a column was changed (e.g., from 
string
to 
int
) in the source system, leaving behind manifest files with mixed encoding types. * Upgrade StarRocks: This is a known manifest-parsing bug in earlier 3.5.x patches. It is addressed in version 3.5.20 and later, where the manifest decoder was made more robust against unexpected binary formats. * Rewrite Manifests: If possible, use Spark or another Iceberg engine to run a metadata maintenance task:
Copy code
sql
    -- Example Spark SQL
    CALL catalog.system.rewrite_manifests('db.table_name');
Summary: You effectively bypassed a metadata decoding bug by telling the engine to ignore the metadata entirely. References • data_source/catalog/iceberg/iceberg_catalog.md • sql-reference/System_variable.md • administration/management/FE_configuration.md • release_notes/release-3.5.md References • sql-reference/System_variable.md • administration/management/FE_configuration.md • using_starrocks/sorted_aggregate.md • administration/management/BE_configuration.md • release_notes/release-2.4.md
z
@Rocky there was no schema change and what I see strange is that in statistics.external_column_statistics partition_column isnot correct
r
The observation that the 
partition_column
(or 
partition_name
) in 
_statistics_.external_column_statistics
looks "different" or "strange" is a major clue. This usually happens because of how StarRocks handles Iceberg Partition Transforms and a known metadata-parsing bug. 1. Why the "partition_column" looks different In Iceberg, partitioning is often "hidden" or "transformed" (e.g., 
day(timestamp_col)
or 
bucket(10, id)
). * StarRocks Mapping: When StarRocks collects statistics for an Iceberg table, it doesn't always use the raw column name. If a transform is used, StarRocks may store the statistic against the transformed partition name defined in the Iceberg spec, rather than your original source column. * The "Strange" Value: If you see values like 
93
or other odd characters in these fields, it confirms that StarRocks is incorrectly reading the physical binary bytes from the Iceberg manifest and trying to treat them as a string or integer. 2. The Link to the 
NumberFormatException
 There is a documented bug (e.g., #69207) in the StarRocks Iceberg connector where the metadata collector populates file bounds with Parquet physical encoding bytes instead of the logical typed values. * The Crash: When you run a query, the Optimizer looks at these statistics. It sees the physical byte 
93
(which is the ASCII for 
]
) and tries to parse it as an 
INT
or 
DECIMAL
. Since 
]
is not a valid number, it throws the 
NumberFormatException
. * Why 
DROP STATS
failed: 
DROP STATS
only clears the statistics StarRocks manually collected. However, StarRocks also performs *"MetaScan"*—it reads the `min`/`max` bounds directly from the Iceberg 
.avro
manifest files at query time. Since the "bad" data is physically inside your Iceberg metadata files, StarRocks keeps "re-learning" the bad stats every time you query. 3. Why 
enable_min_max_optimization = false
worked This variable tells the StarRocks Optimizer: "Ignore the min/max values in the metadata entirely." By turning it off, you skip the code path that attempts to decode those binary bytes, thus avoiding the 
NumberFormatException
. The query succeeds because StarRocks stops trying to be "smart" with the metadata and just reads the raw data files. Recommended Permanent Solution Since you've confirmed that the stats look incorrect/different in the system tables: 1. Check for Partition Evolution: Even if you didn't change the schema, check if the table was created with transforms. Run 
DESC [catalog].[db].[table]
or check the Iceberg metadata directly to see if the partition spec matches your expectations. 2. Upgrade: This specific issue with binary encoding in manifests was heavily addressed in v3.5.20+ and v4.x. 3. Manual Refresh: After setting the optimization to false, try a hard refresh of the metadata to see if it clears the FE's internal mapping:
Copy code
sql
    REFRESH EXTERNAL TABLE catalog.db.table;
4. Rewrite Manifests (External): If the Iceberg manifests themselves contain corrupt bounds (common if they were written by an older Spark/Flink version), you may need to use an Iceberg maintenance tool to 
rewrite_manifests
. References • data_source/catalog/iceberg/iceberg_meta_table.md • data_source/feature-support-data-lake-analytics.md • sql-reference/information_schema/partitions_meta.md • sql-reference/sql-statements/table_bucket_part_index/SHOW_PARTITIONS.md • sql-reference/sql-functions/meta-functions/inspect_hive_part_info.md
The fact that you see "incorrect" information in 
_statistics_.external_column_statistics
confirms that the Statistics Collector is suffering from the same metadata-parsing bug as the Query Optimizer. 1. Why the 
partition_column
looks "incorrect" When StarRocks runs an 
ANALYZE
task (manual or automatic) on an Iceberg table, it reads the Iceberg Manifest files to populate the 
_statistics_
system tables. There are two specific reasons you are seeing incorrect partition data: * The Binary Decoding Bug (The '93' Error): The value 
93
is the ASCII for the character 
]
. This happens because StarRocks is reading the raw binary bytes from the Parquet/Iceberg 
lower_bounds
or 
upper_bounds
fields. Instead of decoding the bytes into a number or date, it is treating the raw byte (0x5D = 93) as the value. This results in gibberish values appearing in your 
partition_name
or `max`/`min` columns in the statistics table. * Partition Value Shifting: There is a known issue (e.g., bug #63029) where if a partition contains a 
NULL
value, the StarRocks collector may misalign the array of partition values. This causes values to "shift" to the wrong column name (e.g., a value belonging to 
column_B
is stored under 
column_A
), making the 
partition_name
entries in your stats table look physically wrong. 2. Why 
DROP STATS
didn't help 1. Auto-Analyze: By default (since v3.4), StarRocks uses Query-Triggered Analyze. As soon as you run a query after dropping stats, StarRocks immediately launches a background task to re-collect them. Since the underlying Iceberg manifests still contain the "binary" data StarRocks is struggling to read, it simply writes the same "incorrect" stats back into the table. 2. MetaScan Pruning: Even without the statistics table, the StarRocks engine performs "MetaScan" during the planning phase. It reads the 
.avro
manifest files directly to prune files based on your 
WHERE
clause. The 
NumberFormatException
occurs during this direct read, which 
DROP STATS
cannot prevent. 3. Why 
enable_min_max_optimization = false
fixed it This variable is the "kill switch" for this entire logic. It tells the engine: _ _"Do not trust the statistics in 
_statistics_.external_column_statistics
."* _ _"Do not attempt to read the min/max bounds from the Iceberg manifest files."* By disabling this, you bypass the code that tries to parse those binary bytes (the 
93
), allowing the query to proceed by scanning the actual data files instead of the metadata. Recommended Next Steps * Identify the offending column: Check your Iceberg table for any columns that are 
DECIMAL
, 
UUID
, or 
FIXED
types, or columns with 
NULL
values in the partition spec. These are the most common triggers for decoding bugs. * Upgrade StarRocks: This metadata parsing logic was significantly overhauled in v3.2.11+, v3.3.5+, and v3.5.20+. Upgrading to the latest patch of your current major version is the only permanent way to fix the "incorrect" statistics collection. * Hard Refresh: After upgrading, you should run:
Copy code
sql
    DROP STATS catalog.db.table;
    REFRESH EXTERNAL TABLE catalog.db.table;
And then ensure 
enable_query_trigger_analyze
is working correctly to re-populate the stats with the correct logic fix. References • data_source/catalog/iceberg/iceberg_catalog.md • sql-reference/information_schema/partitions_meta.md • using_starrocks/Cost_based_optimizer.md • administration/management/FE_configuration.md • data_source/catalog/iceberg/iceberg_meta_table.md References
z
@Rocky yes that partition is hide partition and starrocks cant map it so it takes other column and thats why it has problem I guess
r
Your theory is correct. The issue is a combination of Iceberg Hidden Partitioning and a metadata alignment bug in StarRocks. Here is exactly why that "strange" mapping is causing your `NumberFormatException`: 1. The "Hidden Partition" Mismatch In Iceberg, partitions are often "hidden" transforms (e.g., 
day(timestamp_col)
or 
bucket(10, id)
). * The Bug: In some StarRocks versions (notably early 3.x patches), there is a bug (#63029) where the Statistics Collector fails to correctly map these transformed values back to their source columns. * The Result: If you have a hidden partition, StarRocks might accidentally "shift" the statistics. It takes a value that belongs to a hidden partition field and tries to store it under a different physical column in the 
_statistics_.external_column_statistics
table. 2. Why the Value is 
93
 The reason you see 
93
(and why it causes a 
NumberFormatException
) is due to Physical vs. Logical encoding: * Iceberg stores min/max bounds in manifest files as raw binary bytes. * The ASCII character for 
]
is 
93
in decimal. * Because of the mapping mismatch mentioned above, StarRocks is taking raw binary bytes (like 
]
) from one metadata field and trying to "force" them into a column it thinks is an 
INT
or 
DECIMAL
. * When the Query Optimizer tries to read these statistics to plan your query, it sees the string 
"93"
(the misinterpreted byte) and tries to parse it as a number. If the column type doesn't match or the decoding logic fails, it throws 
java.lang.NumberFormatException: For input string: "93"
. 3. Why 
enable_min_max_optimization = false
is the only thing that helps * 
DROP STATS
fails because StarRocks doesn't just use the stats table; it also does a "MetaScan" of the Iceberg manifest files at runtime. Since the "bad" mapping logic is in the engine's manifest-parsing code, it will keep hitting the same error even if the statistics table is empty. * Disabling the optimization tells StarRocks: "Do not look at the min/max metadata in the manifests or the stats table." This forces it to skip the broken decoding logic entirely and just scan the data files. Permanent Fix To fix this without losing the performance of min/max pruning: 1. Upgrade: This is a known issue with Iceberg metadata parsing. It has been fixed in v3.2.11+, v3.3.5+, and v3.5.20+. 2. Clear the "Bad" Stats Cache: After upgrading, you must clear the incorrect mappings:
Copy code
sql
    DROP STATS [catalog].[db].[table];
    REFRESH EXTERNAL TABLE [catalog].[db].[table];
3. Check for NULLs: These shifts are often triggered if your partition columns contain 
NULL
values. Ensure your Iceberg table maintenance (like 
rewrite_manifests
via Spark) is run periodically to keep the metadata clean. References • data_source/catalog/iceberg/iceberg_meta_table.md • knowledge/admin_and_operation/shared_data_compaction.md
2 Views
Open in Slack
PreviousNext
Powered by