apache / apache/iceberg

Spark: MERGE INTO Statements with only WHEN NOT MATCHED Clauses are always executed at Snapshot Isolation

オープン
#12,653 コメント 17 件 リアクション 0 件 担当者 0 名 GitHub で見る
bug spark
主要言語
Java
スター
9.2k
フォーク
3.5k
平均マージ
2日 11時間
マージ済み PR(30日)
132

説明

### Apache Iceberg version

1.8.1 (latest release)

### Query engine

Spark

### Please describe the bug 🐞

When running two concurrent `MERGE INTO` operations on an Apache Iceberg table, I expect them to be **idempotent** -- meaning Iceberg should either detect conflicts and resolve them or fail one of the jobs to prevent data inconsistencies.

However, Iceberg determines the **operation type dynamically** based on the result of the join condition, which can lead to unexpected behavior:
- If a match is found, Iceberg treats it as an **overwrite** operation and fails the second job due to conflicting commits.
- If no match is found, Iceberg considers it an **append** operation and attempts to resolve conflicts by creating a new manifest for appended data, as explained in the [Cost of Retries doc](https://iceberg.apache.org/docs/latest/reliability/#cost-of-retries).

This behavior introduces a problem:
If the dataset is large enough and neither job finds a match, both will proceed with appending data independently, causing **duplicate records**.

#### **Reproduction Steps**
Running the following query in concurrent jobs can result in duplicate data if no matching records exist in `dest`:
```SQL
MERGE INTO dest
USING src
ON dest.id = src.id
WHEN NOT MATCHED THEN
INSERT *
-- even with update action, we'll have the same issue
-- WHEN MATCHED THEN
-- UPDATE SET *
```
I initially expected the **operation type** to be determined by the query itself (i.e., always "append" in the query without `UPDATE` action). However, through testing, I found that Iceberg decides the operation type **at runtime**, based on the actual join results. This makes `MERGE INTO` **non-idempotent**, leading to unintended duplicate inserts.

#### **Expected Behavior**
Iceberg should ensure idempotency for `MERGE INTO`, preventing duplicate data when no matches are found.

#### **Additional Context**
- Iceberg version: 1.8.1
- Iceberg catalog: Glue catalog (type `glue`) with S3 FileIO
- Spark version: 3.5.5

Would love to hear if others have encountered this or if there's a recommended workaround.

### Willingness to contribute

- [ ] I can contribute a fix for this bug independently
- [x] I would be willing to contribute a fix for this bug with guidance from the Iceberg community
- [ ] I cannot contribute a fix for this bug at this time

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

issue に記載されている Iceberg テーブルに対する同時実行 Spark MERGE INTO の再現から始めます。WHEN NOT MATCHED のみを使用するクエリと、指定された Spark および Iceberg のバージョンを使用してください。Cost of Retries のドキュメントを読み、runtime の join 結果が append または overwrite の動作をどのように選択するかを追跡します。同時実行の no-match merge で重複レコードが作成されず、その動作が回帰テストでカバーされれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java, spark, sql
領域
data-engineering, databases, distributed-systems
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
48/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。