HeartSaVioR commented on code in PR #52391:
URL: https://github.com/apache/spark/pull/52391#discussion_r2396428578
##########
python/pyspark/sql/pandas/serializers.py:
##########
@@ -1630,8 +1633,23 @@ def row_stream():
yield (batch_key, row)
for batch_key, group_rows in groupby(row_stream(), key=lambda x:
x[0]):
- df = pd.DataFrame([row for _, row in group_rows])
- yield (batch_key, df)
+ rows = []
+ accumulate_size = 0
+ for _, row in group_rows:
+ rows.append(row)
+ # Short circuit batch size calculation if the batch size is
+ # unlimited as computing batch size is computationally
expensive.
+ if self.arrow_max_bytes_per_batch != 2**31 - 1:
Review Comment:
Actually, if we were able to break a large data for a grouping key into
multiple Arrow RecordBatches, each Arrow RecordBatch can be converted into
Pandas DataFrame and they can be connected with iterator/generator which won't
require to materialize multiple Arrow RecordBatches at once. That's how we do
with applyInPandasWithState.
I can think of a couple cases which this logic would help:
1. Very few data are bounded in a single grouping key but split to two Arrow
RecordBatches
This case we will be able to provide one Pandas DataFrame instead of two.
2. Converting Arrow RecordBatch to Pandas DataFrame could trigger whole
different memory usage
I don't have an evidence and it's just a random thought of justification of
the change - the size of data in the Arrow RecordBatch for a grouping key could
be different from the result of conversion on Pandas DataFrame.
If, the size of Arrow RecordBatch would be very similar with conversion to
Pandas DataFrame, maybe taking the route of applyInPandasWithState would be
still OK. Though I'm fine with the argument if this logic is simpler than
applyInPandasWithState, assuming sys.getsizeof is accurate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
