In Apache Hudi, how does the bulk_insert operation differ from upsert?

## The three write paths `hoodie.datasource.write.operation` selects how a batch is written. Three values matter for ingest, and they differ mainly in how much work Hudi does *before* it writes a byte. ### upsert (the default) The full path. For every incoming record Hudi: 1. **Tags** it — asks the index which file group already holds this record key. This is a lookup against the whole table's index structure and is usually the dominant cost of the job. 2. **Routes** tagged records to their existing file group. On a Copy-on-Write table that means reading the current base file, merging the updates in, and writing a new version of it; on Merge-on-Read it means appending to a log file in that file group. 3. **Places** untagged records as inserts, preferring file groups that are below the target file size so the table does not accumulate small files. 4. **Deduplicates** within the batch using the precombine field, so one commit never writes the same key twice. You get correctness — one row per key — and self-maintaining file sizes, and you pay for both. ### bulk_insert The loading path. It does none of steps 1–3. There is no index lookup, so Hudi has no idea whether a key already exists; there is no read-modify-write of existing files, so nothing is merged; and there is no small-file handling in the upsert sense — file sizing comes from how the input is partitioned and sorted plus the target file size, not from probing existing files. What it does do is arrange the input before writing, via `hoodie.bulkinsert.sort.mode`: a global sort across the whole input, a sort within each output partition, or none. Global sorting produces well-bounded record-key ranges per file, which directly helps a bloom index prune candidate files later; it also costs a full shuffle. bulk_insert can also use a row-writing path that avoids converting each record into Hudi's internal record representation, which is a large part of why it is fast. Use it for: the initial load of a table, migrating an existing dataset into Hudi, or rewriting a table under a new key or partitioning scheme. Do not use it as a steady-state ingest path over live data — it will happily write a second copy of a key that already exists, and nothing will tell you. ### insert The middle path. No index lookup against existing data, so it also cannot update or deduplicate against what is stored, but it *does* apply small-file handling like upsert, and it can deduplicate within the incoming batch when combine-before-insert is enabled. It suits append-only fact streams where the source guarantees no re-delivery of a key and you still want reasonable file sizes. ## Choosing between them The decision is driven by one question: can this batch contain a key that already exists in the table? - **Yes, routinely** (CDC, mutable dimensions, late-arriving events) → upsert. The index cost is the price of correctness. - **Never, by construction** (immutable event log with a unique key from the source) → insert, and you get file sizing without paying for tagging. - **The table is empty or is being rebuilt** → bulk_insert, with global sort if a bloom index will serve later reads. A very common production shape is bulk_insert once for the backfill, then upsert forever after. Another is bulk_insert into a staging table followed by a single upsert into the target, when the incoming volume is far larger than the mutable slice it touches. ## Failure modes to name - **Duplicates after "a quick reload".** Someone re-ran the initial load with bulk_insert against a table that already had data. There is no index check, so every key exists twice and only a rewrite or a deduplicating job fixes it. - **A bulk_insert that leaves thousands of tiny files.** Sort mode `none` with a highly parallel input writes one file per task per partition. Either sort, or reduce write parallelism, or follow with clustering. - **An upsert job whose runtime is nearly all tagging.** That is not the write path's fault; it is the index choice, and the fix is a different index or a key layout that lets ranges prune. - **Assuming bulk_insert is "upsert but faster".** It is a different operation with different guarantees. Faster is a consequence of doing less, and the thing it skips is exactly what makes upserts correct. ## Interview framing Interviewers use this question to check whether you understand *why* Hudi upserts cost more than a plain Parquet write. The answer is the tagging step and the merge it enables. Candidates who describe bulk_insert as an optimisation flag rather than a semantically different operation get caught by the follow-up: what happens if you bulk_insert a key that already exists?