Nested columns are not repartitioned: one chunk per batch instead of Rust's ~1 MB chunks

未關閉
#723 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
55/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
java
領域
data

研究方向

Start with Repartitioner.supports and the byte sizing and head/tail slicing paths for StructData, ListData, and FixedSizeListData. Extend RepartitionInteropIntegrationTest with list<struct<utf8>> and struct columns, then compare chunk row counts and sizes with vortex-jni. Done means nested columns are repartitioned into comparable ~1 MB chunks.

由索引模型根據 Issue 內容生成。

描述

bug

Repartitioner.supports covers Primitive, Bool, Decimal, Utf8 and Binary; struct, list, fixed-size-list, map and variant columns are written one chunk per input batch. Rust's RepartitionStrategy coalesces every column, nested ones included, into ~1 MB chunks of 8192-row multiples.

Found on Raincloud coig: conversations (list<struct<question: utf8, answer: utf8>>) is written as 3 chunks of 65536 rows (the Parquet import's batches), where Rust writes 22 chunks of 8192 rows. The column is 2.6% bigger than Rust's (63.74 MB vs 62.13 MB from vortex-jni 0.91), and a row-range or pruned read touches 8x more rows per chunk.

Fix: byte sizing and head/tail slicing for StructData, ListData and FixedSizeListData carriers, then admit them in supports.

Test first: extend RepartitionInteropIntegrationTest with list<struct<utf8>> and struct columns, comparing chunk row counts and sizes with vortex-jni.

主要語言
Java
星號
3
分支
2
平均合併
9 小時 19 分鐘
30 天內合併 PR
154

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

dfa1/vortex-java 的其他 Issue

查看 dfa1/vortex-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。