What changes were proposed in this pull request?

(Fixes: #8846)

Summary of Changes

This commit primarily:

1. Fixes directory name capitalization from "iceberg" to "Iceberg" across the codebase
2. Reorganizes and improves include statements in several files
3. Adds new benchmark tests for Iceberg with delete operations
4. Makes minor code improvements and bug fixes

Key Changes

Directory Structure and Naming

• Renamed iceberg directory to Iceberg with proper capitalization
• Updated all include paths to reflect this change
• Updated CMakeLists.txt to use the new capitalized directory name

Code Improvements

• Fixed typo: begion → begin in BlockTypeUtils.h
• Added assertion to verify input_format is not null in NormalFileReader constructor
• Improved readability of DeltaReader::create by splitting a long line
• Simplified row counting in ParquetFormatFile.cpp using std::ranges::fold_left
• Added null check before using input in IcebergReader::create

New Functionality: Added code for benchmarking Iceberg read operations with equality deletes and position deletes

These two benchmark functions (BM_IcebergReadWithPositionDeletes and BM_IcebergReadWithEqualityDeletes) are designed to evaluate the performance of ClickHouse when integrated with Apache Iceberg delete operations. Supports parameterized testing with different deletion ratios (0% to 100%)

Run on (24 X 1285.69 MHz CPU s)
CPU Caches:
  L1 Data 48 KiB (x12)
  L1 Instruction 32 KiB (x12)
  L2 Unified 1280 KiB (x12)
  L3 Unified 30720 KiB (x1)
Load Average: 2.34, 1.91, 2.30
----------------------------------------------------------------------------------------------
Benchmark                                                    Time             CPU   Iterations
----------------------------------------------------------------------------------------------
BM_IcebergReadWithPositionDeletes/0/iterations:10         39.3 ms         39.3 ms           10
BM_IcebergReadWithPositionDeletes/1/iterations:10          156 ms          155 ms           10
BM_IcebergReadWithPositionDeletes/10/iterations:10         148 ms          145 ms           10
BM_IcebergReadWithPositionDeletes/50/iterations:10         273 ms          267 ms           10
BM_IcebergReadWithPositionDeletes/100/iterations:10        347 ms          335 ms           10
BM_IcebergReadWithEqualityDeletes/0/iterations:10         36.8 ms         36.8 ms           10
BM_IcebergReadWithEqualityDeletes/1/iterations:10          192 ms          191 ms           10
BM_IcebergReadWithEqualityDeletes/5/iterations:10          617 ms          616 ms           10
BM_IcebergReadWithEqualityDeletes/10/iterations:10        1821 ms         1817 ms           10
BM_IcebergReadWithEqualityDeletes/50/iterations:10        9716 ms         9703 ms           10

Position Delete Performance (BM_IcebergReadWithPositionDeletes)

Position delete tests show performance decreases as deletion ratio increases, but the growth is relatively slow:

• Only 39.3ms required with no deletions
• Performance drops significantly to 156ms when deleting 1%, profiler shows hot pot is in bitmap contain test
• Remains relatively stable (148ms) when deleting 10% of data
• Increases to 273ms when deleting 50%
• Reaches 347ms for complete deletion (100%), profiler shows 2 hot pots: one is in reading file column of position file, and another is in creating bitmap.

This indicates that for position deletes, performance degradation has a near-linear relationship with deletion ratio, with processing time increasing approximately 8.8 times from 0 to 100% deletion ratio.

Equality Delete Performance (BM_IcebergReadWithEqualityDeletes)

Equality delete tests demonstrate a dramatic performance decline:

• 36.8ms with no deletions (similar to position deletes)
• Increases to 192ms when deleting 1%
• Reaches 617ms when deleting 5%
• Spikes to 1821ms when deleting 10%
• Reaches 9716ms when deleting 50%

Equality delete performance degradation shows exponential growth, with processing time increasing approximately 264 times from 0 to 50% deletion ratio.

Analysis

There is only one hotpot, i.e. DB::Set::executeImplCase which is part of the logic for checking if elements in a set of columns belong to a predefined set, and supporting both positive and negative set operations.

How was this patch tested?

Existed UTs