commit | b03cfcf2ade6dea7fed10f4a3db5c58ddf2c6bd2 | [log] [tgz] |
---|---|---|
author | Zoltan Borok-Nagy <boroknagyz@cloudera.com> | Fri Mar 22 19:16:07 2024 +0100 |
committer | Impala Public Jenkins <impala-public-jenkins@cloudera.com> | Thu Mar 28 15:17:40 2024 +0000 |
tree | ffedc647e0074fcb6fa9301e57f94c1f58bf2bb1 | |
parent | 73171cb7164573349bd53a996a51bb7058b778e0 [diff] |
IMPALA-12894: (part 2) Fix optimized count(*) for Iceberg tables with dangling delete files Impala can return incorrect results if a table has dangling delete files. Dangling delete files are delete files that are part of the snapshot but they are not applicable to any of the data files. We can have such delete files after Spark's rewrite_data_files action. During analysis we check the existence of delete files based on the snapshot summary. If there are no delete files in the table, we just replace the count(*) expression with NumericLiteral($record_count). If there are delete files in the table (based on the summary), we set optimize_count_star_for_iceberg_v2 in the query context. Without optimize_count_star_for_iceberg_v2 in the query context, the IcebergScanPlanner would create the following plan. AGGREGATE COUNT(*) | UNION ALL / \ / \ / \ SCAN all ANTI JOIN datafiles / \ without / \ deletes SCAN SCAN datafiles deletes with deletes With optimize_count_star_for_iceberg_v2 the final plan looks like the following: ArithmeticExpr(ADD) / \ / \ / \ record_count AGGREGATE of all COUNT(*) datafiles | without ANTI JOIN deletes / \ / \ SCAN SCAN datafiles deletes with deletes The ArithmeticExpr(ADD) and its left child (record_count) is created by the analyzer, IcebergScanPlanner is responsible in creating the plan under AGGREGATE COUNT(*). And if it has delete files and optimize_count_star_for_iceberg_v2 is true, it knows it can omit the original UNION ALL and its left child. However, IcebergScanPlanner checks delete file existence based on the result of planFiles(), hence dangling delete files are eliminated. And if there are no delete files, IcebergScanPlanner assumes that case is already handled by the Analyzer (i.e. it replaced count(*) with NumericLiteral($record_count)). So it will incorrectly create a normal SCAN plan of the table under COUNT(*), i.e. we end up with this: ArithmeticExpr(ADD) / \ / \ / \ record_count AGGREGATE of all COUNT(*) datafiles | without SCAN deletes datafiles without deletes Which means Impala will yield $record_count * 2 as a result. This patch fixes the FeIcebergTable.hasDeleteFiles() method, so it also ignores dangling delete files. Therefore, the analyzer will just substitute count(*) with NumericLiteral($record_count) if all deletes are dangling, i.e. no need to involve the IcebergScanPlanner at all. The patch also introduces a new query option, "iceberg_disable_count_star_optimization", so users can completely disable the statistic-based count(*)-optimization if necessary. Testing: * e2e tests * planner tests Change-Id: Ie3aca0b0a104f9ca4589cde9643f3f341d4ff99f Reviewed-on: http://gerrit.cloudera.org:8080/21190 Reviewed-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Lightning-fast, distributed SQL queries for petabytes of data stored in open data and table formats.
Impala is a modern, massively-distributed, massively-parallel, C++ query engine that lets you analyze, transform and combine data from a variety of data sources:
The fastest way to try out Impala is a quickstart Docker container. You can try out running queries and processing data sets in Impala on a single machine without installing dependencies. It can automatically load test data sets into Apache Kudu and Apache Parquet formats and you can start playing around with Apache Impala SQL within minutes.
To learn more about Impala as a user or administrator, or to try Impala, please visit the Impala homepage. Detailed documentation for administrators and users is available at Apache Impala documentation.
If you are interested in contributing to Impala as a developer, or learning more about Impala's internals and architecture, visit the Impala wiki.
Impala only supports Linux at the moment. Impala supports x86_64 and has experimental support for arm64 (as of Impala 4.0). Impala Requirements contains more detailed information on the minimum CPU requirements.
Impala runs on Linux systems only. The supported distros are
Other systems, e.g. SLES12, may also be supported but are not tested by the community.
This distribution uses cryptographic software and may be subject to export controls. Please refer to EXPORT_CONTROL.md for more information.
See Impala's developer documentation to get started.
Detailed build notes has some detailed information on the project layout and build.