avoid merge errors when blocks contain different type

[982945902]

Why are these changes needed?

example:

ds = ray.data.from_pandas(pd.DataFrame({"a": [1, 2, 3], "b": ["a", "b", np.nan]}))
ds.repartition(2)

wil get # <class 'pyarrow.lib.Table'>, <class 'pandas.core.frame.DataFrame'>
because in blockaccess, fallback maybe arise， like ["a", "b", np.nan] cannot cover to arrow will raise exception cause fallback, and then return pandas

when use this code

def my_fn(batch):
    return batch
a = ds.repartition(2).map_batches(my_fn,).to_pandas()

will finally cause # <class 'pyarrow.lib.Table'>, <class 'pandas.core.frame.DataFrame'> merge in to_pandas method, it will raise exception.

In short, I solved the problem that merging two blocks of a dataset will throw an exception when there are two formats of pandas arrow in the blocks.

Related issue number

#45236

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[982945902]

@kevin85421 if you have interesting to review this pull

[kevin85421]

Hi @982945902, would you mind solving the conflict and adding some tests? Then, I can ping someone to review this PR.

[982945902]

Hi @982945902, would you mind solving the conflict and adding some tests? Then, I can ping someone to review this PR.

@kevin85421 ok

[982945902]

@kevin85421 this pull is conflict with #45294, My idea is to accommodate different types of block merges, such as #45236, in case the conversion to arrow fails