Iceberg

Your team just migrated a 4TB events table from Hive/Parquet to Iceberg. In the old world, a junior analyst once renamed a column with ALTER TABLE ... CHANGE and silently corrupted six months of queries — reads started returning the wrong column's data, and nobody noticed for a week. Leadership wants a guarantee that "rename a column" is now a safe, zero-rewrite operation. The interviewer wants you to explain WHY Iceberg makes schema changes safe when Hive didn't, which specific changes are free vs. which still cost you, and where the remaining footguns are.

A Flink job writes a clickstream into an Iceberg table with a 30-second checkpoint interval, partitioned by day(event_ts). After three months the table has ~2 million data files averaging 180KB each, and ~40,000 manifest files. Analysts complain that even a trivial SELECT count(*) WHERE day = today now spends 60–90 seconds in query planning before a single row is scanned. Nothing is "broken" — the table just got slow. Walk through why this happens, the compaction strategy you'd run, and how you'd stop it recurring without throttling the stream.

Finance flags that one Iceberg table is costing 45× what its data size suggests: SELECT count(*) and the table stats say ~200GB of current data, but the S3 prefix holds ~9TB. The table is updated hourly with MERGE upserts and has been live for 14 months. Nobody set up any maintenance jobs. The interviewer wants you to account for the missing 8.8TB precisely — there's more than one source — and design a retention + cleanup policy that reclaims it WITHOUT breaking the team's time-travel and incremental-read use cases.

A CDC pipeline replicates a high-churn OLTP accounts table (500M rows) into Iceberg via a 5-minute micro-batch MERGE INTO. Each batch carries ~2M changed rows spread randomly across the keyspace. The table is copy-on-write, and a single MERGE now takes 35–40 minutes — it can't keep up with a 5-minute cadence, so lag is growing. Someone suggests "switch the table to merge-on-read." The interviewer wants you to decide that trade-off with eyes open: WHY CoW is slow here, what MoR actually changes (and costs), and the maintenance you'd have to commit to before you'd recommend it.

One Iceberg orders table is written by TWO engines: a Flink job appending new orders every 30s, and a Spark job that runs hourly compaction + GDPR DELETEs. Intermittently, the team sees Flink commits "succeed" but their rows vanish after the Spark job runs, and Spark jobs sometimes fail with CommitFailedException after 20 minutes of work. They're on a Hadoop catalog pointing at S3. The interviewer wants you to explain Iceberg's concurrency model precisely, identify the very likely root cause of the LOST commits, and design the fix so two engines can write one table safely.