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

オープン
#723 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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分
マージ済み PR(30日)
154

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dfa1/vortex-java のほかの issue

dfa1/vortex-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。