Repository navigation
[VL shuffle] Add VeloxSplitter to split with velox::RowVector - #1003
Conversation
|
Thanks for opening a pull request! Could you open an issue for this pull request on Github Issues? https://github.com/oap-project/gluten/issues Then could you also rename commit message and pull request title in the following format? See also: |
There was a problem hiding this comment.
Please change the remark to english
|
Can you use the benchmark https://github.com/oap-project/gluten/blob/main/cpp/core/benchmarks/ShuffleSplitBenchmark.cc to test if it works better than old shuffle? |
There was a problem hiding this comment.
Maybe you can use using namespace arrow in this .cc file
The Unit test is not completed yet, I will run |
There was a problem hiding this comment.
Will Arrow IPC writer be used in velox splitter? or probably the headers need to be minimized
There was a problem hiding this comment.
OK, I will check it, and we should minimize the header files to include
There was a problem hiding this comment.
yes, structs such as arrow::ipc::IpcPayload and arrow::ipc::IpcWriteOptions are used, so including these header files is necessary.
There was a problem hiding this comment.
I don't have much context here but my intuition is that the code can base on row vector's schema instead of Arrow schema. But current way is also OK to me as of now.
There was a problem hiding this comment.
I don't have much context here but my intuition is that the code can base on row vector's schema instead of Arrow schema. But current way is also OK to me as of now.
In my first implementation, I tried to use Row Vector‘s schema, but I found it was not a good way because too many changes are required.
I get the arrow::Schema from RowVector using the interface velox::exportToArrow provided by Velox, and then it works well with RowVector. otherwise, I will have to switch case every Velox DataType and be careful of the relations of the two type systems.
There was a problem hiding this comment.
OK. So let's just keep the current way, it's not a big deal at this time.
There was a problem hiding this comment.
Can we get arrow Schema here?
There was a problem hiding this comment.
I kept this interface here, after I add the code for JNI, I will delete it if I find that it is useless. OK?
|
@zzcclp would you help me to check the problem of CH Unit-Test for this PR |
|
There is a shuffle benchmark here: cpp/core/benchmarks/ShuffleSplitBenchmark.cc. Current the benchmark read parquet by arrow then do the slit. You may modify it as read parquet by velox, then test velox->arrow + arrow split vs. velox split to arrow. We may check the perf gain and optimize the velox split code. |
got it, I will append the benchmark |
| #endif | ||
|
|
||
| // partition number should be less than 64k | ||
| ARROW_CHECK_LE(num_partitions_, 64 * 1024); |
There was a problem hiding this comment.
why num_partitions_ can not be greater then 64K?
There was a problem hiding this comment.
Because the partition id is 16bit to save memory footprint. If your case needs more than 64K reducers, feel free to add 32bit support through template.
| // subscript: Row ID | ||
| // value: Partition ID | ||
| // TODO: rethink, is uint16_t better? | ||
| std::vector<uint32_t> row_2_partition_; // note: partition_id_ |
There was a problem hiding this comment.
why naming these fields as xxx_2_xxx ? it is not a map, why not just partitionIds ?
There was a problem hiding this comment.
Feel free to update for more reasonable names.
What changes were proposed in this pull request?
velox::RowVector. when the backend isVelox, splitting withRowVectorcan avoid transferring fromvelox::RowVectortoarrow::RowBatch, it's more efficient.using namespace arroworusing namespace facebook::veloxin header files, this usage brings mess and conflict.Unit testsoon, so filecpp/velox/tests/VeloxSplitterTest.ccis not ready now, but it will not affect others.JNI call functionsin filevelox/jni/JniWrappersoon.(Please fill in changes proposed in this fix)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)