Search before asking
Motivation
For AI training scenarios, it is necessary to read all data from a sample table in either append or DE format for training. The training process reads data sequentially in batches according to the training layer's batch size. If an original Parquet file contains many rows, each batch only reads a specific range of rows within it. Under the current interface, users can only skip unwanted rows one by one, which is a significant waste.
Solution
We can utilize the Parquet footer information to directly filter out unnecessary page data. Therefore, we propose adding a new method to the TableRead interface:
RecordReader<InternalRow> createReader(Split split, RowRange rowRange) throws IOException;
Here, RowRange describes the row range for this split, e.g., [300, 500], allowing Paimon to accelerate the read process based on the underlying data format. If the underlying storage cannot support this optimization (e.g., primary key tables), it should fall back to the original naive implementation that skips rows based on row numbers.
Anything else?
No response
Are you willing to submit a PR?
Search before asking
Motivation
For AI training scenarios, it is necessary to read all data from a sample table in either append or DE format for training. The training process reads data sequentially in batches according to the training layer's batch size. If an original Parquet file contains many rows, each batch only reads a specific range of rows within it. Under the current interface, users can only skip unwanted rows one by one, which is a significant waste.
Solution
We can utilize the Parquet footer information to directly filter out unnecessary page data. Therefore, we propose adding a new method to the
TableReadinterface:RecordReader<InternalRow> createReader(Split split, RowRange rowRange) throws IOException;Here,
RowRangedescribes the row range for this split, e.g., [300, 500], allowing Paimon to accelerate the read process based on the underlying data format. If the underlying storage cannot support this optimization (e.g., primary key tables), it should fall back to the original naive implementation that skips rows based on row numbers.Anything else?
No response
Are you willing to submit a PR?