In a Hudi Merge-on-Read table, how do snapshot and read-optimized queries differ?

## What a file slice contains In an Apache Hudi `MERGE_ON_READ` table, records in a partition are organized into **file groups** identified by a file ID. Each version of a group is a **file slice**: one Parquet **base file** plus zero or more **log files** holding blocks appended since that base file was written. Ingestion never rewrites the base file — it appends log blocks and records a `deltacommit` — so at any moment a slice can hold committed changes that are not yet inside its Parquet file. Everything about the two query types follows from that. ## Snapshot queries A snapshot query returns the table as of the latest committed instant, which is what a SQL user normally expects. To do that it must open each relevant file slice, read the base file, replay every log block on top, and resolve conflicts by record key using the precombine field. Delete blocks remove rows from the result. What comes out is correct and fresh, including deletes issued seconds ago. The cost is real work per query: the reader materializes a merged view in memory, and both CPU time and memory grow with the number and size of log files on each slice. A table whose compaction has fallen behind can make the same dashboard query take several times longer than it did the previous day, without any change to the query or the data volume. ## Read-optimized queries A read-optimized query deliberately ignores the log files. It scans only the base Parquet files of the current file slices, which means the engine does exactly what it would do on a plain Parquet dataset: column pruning, predicate pushdown, vectorized reads, nothing else. Performance is essentially Copy-on-Write performance. The tradeoff is staleness with a very specific meaning: the result reflects the table **as of the last completed compaction** on each file group, not as of a wall-clock time you chose. Updates that arrived after compaction are missing, and rows deleted after compaction still appear, because the delete lives only in a log block the query is not reading. That last point traps people: it looks like a correctness bug in the table, and it is actually the documented behaviour of the query type. ## How engines expose the two views When Hudi syncs a Merge-on-Read table to a Hive metastore, it registers two table names: `<name>_rt` for the real-time (snapshot) view and `<name>_ro` for the read-optimized view. Both point at the same underlying data; they differ only in which reader is used. Spark's Hudi datasource selects the view through a query-type option instead. Engine support varies, and some engines historically exposed only the read-optimized view of a Merge-on-Read table — so "which views does this engine actually support" is a question worth answering before you commit a platform to Merge-on-Read. ## The third query type Hudi also offers **incremental** queries, which return only the records changed between two instants on the timeline rather than a full table state. That is a different axis from the snapshot/read-optimized freshness tradeoff and belongs with the timeline and indexing material; mention it as a third option and move on. ## Copy-on-Write collapses the distinction In a `COPY_ON_WRITE` table, every file slice is just a base file — updates were merged in at write time. There are no logs, so the snapshot view and the read-optimized view return exactly the same rows, and asking for the read-optimized view buys nothing. This is a useful sanity check in an interview: if someone claims read-optimized queries speed up a Copy-on-Write table, they have not understood where the merge cost comes from. ## Using the choice in practice A sensible pattern is to route by workload. Interactive dashboards, BI extracts and large scans that tolerate compaction-interval staleness use the read-optimized view and get predictable latency. Operational lookups, correctness-critical reconciliation and anything that must reflect a delete immediately use the snapshot view. Make the staleness explicit: if compaction runs after every few delta commits, read-optimized staleness is bounded by that interval, and you can publish it as an SLA. If compaction is unmonitored, the read-optimized view silently drifts arbitrarily far behind — which is why the two topics, query type and compaction health, are always discussed together. A final operational note: the read-optimized view is also the emergency lever. When snapshot queries degrade because logs have accumulated, pointing heavy readers at `_ro` restores their latency immediately while you fix compaction — at the cost of freshness, and with the deleted-rows caveat clearly communicated to whoever reads the result.