Prepare Iceberg and Hudi exports
How to export an Iceberg or Hudi table so updates and deletes are applied and you can name the exact snapshot you sent.
Prove the reader preserves the table's meaning
Your table engine reads the snapshot; Lithi does not read your catalog or infer its transaction history. Your agent keeps the task goal and final decision, while your application or a supported client prepares the fixed export. Lithi accepts the approved artifact reference and returns a result for you to reconcile against the snapshot evidence.
Use a small disposable dataset in your own test environment before a production export. Start with IDs a, b and c, update b, then delete c. A correct logical snapshot contains a and the updated b; it does not contain the deleted row or an older duplicate. This check shows why an Iceberg- or Hudi-aware reader matters: these formats are not interchangeable collections of Parquet files.
For Iceberg, record the table identity, snapshot ID, schema and reader version. The reader must apply the snapshot's manifests and relevant row-level deletion information. The Iceberg specification distinguishes equality deletes, position deletes and version-dependent deletion vectors. A reader must support the features actually present in your table.
For Hudi, record the table identity, completed commit or time-travel instant, table type, query mode and engine version. A merge-on-read snapshot query and a read-optimized query can return different freshness. The Hudi query guide explains how base files and logs contribute to those results.
Choose the reader before choosing files
Use your own Iceberg- or Hudi-aware engine to produce a fixed export. A file adapter does not become a native catalog connector or a transaction-aware table reader.
Keep catalog credentials and storage permissions in your existing environment. Prepare only authorized rows, then use the normal encrypted artifact handoff for Compute.
Define incremental windows explicitly
For incremental work, define the beginning, end and inclusion rules of the window. State whether exported rows represent latest values or change events. Include the operation type for a reviewed change-event mapping. Don't treat deletes as empty text or silently discard them.
Freeze the export and map its fields
Retain exact exported files, byte counts, digests, row count and stable item IDs. Keep the snapshot or commit evidence with the export. Map selected fields, nulls, timestamps, decimals and nested values explicitly to the workflow's accepted format.
Follow file preparation, rather than submitting a catalog URL, table directory or credential in the job body. Review the workflow, availability and quote before approving paid work. Lithi processes the admitted artifact; your table engine remains responsible for snapshot interpretation.
Reconcile output and recover
Verify accepted output and join by item ID. Check exceptions and missing IDs before loading a separate staging dataset. An output file doesn't authorize a table merge, compaction or delete operation.
If a snapshot expires or required files disappear, stop rather than substituting current data. Review a new export and its quote. If a result import fails after Compute completes, recover that import from the existing accepted result. Keep delivery retries distinct from deliberately new work.
How do I trace a result back to the table?
Keep the snapshot or commit evidence beside the exported file digests and your item-ID mapping. After reviewing the result, join its item IDs to that export before using your table tooling to stage any changes. The first test offers a small way to practice result review.
Next, check tabular representations before transferring the export.