[GLUTEN-8453] [VL] Allow Heavy Batch to be Processed by ColumnarCachedBatchSerializer

[ArnavBalyan]

• Currently the ColumnarCachedBatchSerializer does not support Arrow Heavy Batch.
• ColumnarCachedBatchSerializer expects light batch to offload to native. (In most cases it receives an already offloaded, however fails when the input is a heavy batch).
• Added conversion to offload it if the upstream operator produced an ArrowJavaBatch.
• Also makes the check light/heavy batch public, since they can be good utility functions and don't have critical logic inside.
• Note: This is a fix which will make it work, but ideally it should work with RAS and be compatible with the transitions added, to do this we can wrap the InMemoryTableScanExec and register as a Gluten operator to elegantly offload. I'll investigate as part 2

[github-actions]

#8453

[FelixYBW]

@zhztheplayer Ok to add VeloxColumnarBatches here?

[zhztheplayer]

Yes it's normal to call the utility from Velox backend code. However it seems like discussible on whether to rely on isLightBatch / isHeavyBatch to add conditional transitions.

@ArnavBalyan Would you like to help check if we can somehow add explicit transition nodes (LoadArrowData / OffloadArrowData) into query plan instead of the PR's change? Or is the last Note. in pr description meant for something similar? Thanks!

[zhztheplayer]

Could also refer to a previous effort #7313 if needed.

[ArnavBalyan]

Thanks for the review @FelixYBW @zhztheplayer!
Yes, the note was meant for that. Ideally the transitions should have added the correct transition node before this, However the serializer is a special case since it's not an operator and does not extend the GlutenPlan, I have some ideas to explore this which may require some design changes in the serializer to make it work with transitions.

Would it be possible to merge this for now since the ColumnarRange operator depends on it and I'll work on the serializer compatibility for transitions, let me know what you think thanks!

[zhztheplayer]

However the serializer is a special case since it's not an operator and does not extend the GlutenPlan

Agreed. The code path is different. Thanks for figuring out on this.

Do you think we can add a UT for the change in this PR? If this can be considered an individual fix?

[ArnavBalyan]

Sure let me add it in the ColumnarRangeExec, since it already has the failing UT thanks!

[zhztheplayer]

Yes please feel free to move forward to the Range PR. I am also testing the relevant code and will help add a test case here.