Explain the internal working of the multi-modal indexing subsystem in Hudi?

Hudi's multi-modal index is the framework that lets several different index types — files, bloom filters, column stats, record-level index, secondary index, expression index, and more — all live as separate partitions within the single Metadata Table, rather than as one-off, index-specific structures.

Internally, each index type is implemented as its own partition inside the HFile-backed Metadata Table, and each is built and kept in sync asynchronously relative to the main write path, so enabling a new index type doesn't stall ingestion. When a query or write needs a particular kind of lookup — a key-to-file mapping, a column's min/max range, or a bloom filter — it reads from the matching metadata partition instead of scanning data files directly. This extensible, partitioned design is what let the project add the Record-Level Index and secondary/expression indexes on top of the original bloom-filter and column-stats indexes without redesigning the storage layer each time.