Review this lakehouse table as a concurrency and isolation problem, not a file-format tutorial. Readers must see a consistent snapshot even while writers, compactors, and expire-snapshot jobs run.
Format and catalog: [Iceberg / Delta / Hudi + Glue/Nessie/Hive/Unity]
Table size, snapshot rate, and writer count: [details]
Isolation expectation: [snapshot, serializable, append-only]
Operations in play: [MERGE, overwrite partitions, compaction, expire, rollback]
Query engines: [Spark, Trino, warehouse external tables]
Current table properties and job code:
[Paste]
Recent incidents: [planning timeouts, conflicting commits, missing files, or none]
Produce:
1. Isolation model: what a reader can and cannot observe mid-commit
2. Commit conflict analysis for overlapping MERGE, partition overwrite, and compaction
3. Snapshot expiration vs time-travel and downstream clone/time-travel jobs
4. Manifest, metadata, and planning-cost risks at current snapshot/file counts
5. Safe compaction and clustering schedule that does not starve writers
6. Position-delete / equality-delete / change-data implications if used
7. Rollback and cherry-pick procedure with data-loss warnings
8. Engine-specific gotchas (partial vended credentials, metadata caching)
9. Checks: snapshot history, orphan files, failed-but-visible commits
10. Prioritized property and job changes with blast radius
Call out any setting that makes expire_snapshots or vacuum irreversible. Prefer fewer, larger commits over chatty micro-commits when planning time is the incident.