`max_shard_size` in `datasets.push_to_hub()` breaks with large files
COLLABORATOR
Hi! 

This behavior stems from the fact that we don't always embed image bytes in the underlying arrow table, which can lead to bad size estimation (we use the first 1000 table rows to [estimate](https://github.com/huggingface/datasets/blob/9a7272cd4222383a5b932b0083a4cc173fda44e8/src/datasets/arrow_dataset.py#L4627) the external file size). We plan to address this in the next major release by always embedding external bytes. In the meantime, you can either shuffle the dataset with `.shuffle().flatten_indices()` to make the estimation more precise or embed the bytes in the table like so:
```python
from datasets.table import embed_table_storage
format = ds.format
ds = ds.with_format("arrow")
ds = ds.map(embed_table_storage, batched=True)
ds = ds.with_format(**format)
...
ds.push_to_hub(...)
```
2022-12-23T15:03:41Z
https://github.com/huggingface/datasets/issues/5386#issuecomment-1364025121
https://api.github.com/repos/huggingface/datasets/issues/5386
IC_kwDODunzps5RTV8h
https://api.github.com/repos/huggingface/datasets/issues/comments/1364025121/reactions
2022-12-23T15:03:41Z
https://api.github.com/repos/huggingface/datasets/issues/comments/1364025121
https://avatars.githubusercontent.com/u/47462742?v=4
https://api.github.com/users/mariosasko/events{/privacy}
https://api.github.com/users/mariosasko/followers
https://api.github.com/users/mariosasko/following{/other_user}
https://api.github.com/users/mariosasko/gists{/gist_id}
https://github.com/mariosasko
mariosasko
MDQ6VXNlcjQ3NDYyNzQy
https://api.github.com/users/mariosasko/orgs
https://api.github.com/users/mariosasko/received_events
https://api.github.com/users/mariosasko/repos
https://api.github.com/users/mariosasko/starred{/owner}{/repo}
https://api.github.com/users/mariosasko/subscriptions
User
https://api.github.com/users/mariosasko
public
NONE
Embedding the bytes worked like charm. Thanks @mariosasko!
2022-12-26T23:45:51Z
https://github.com/huggingface/datasets/issues/5386#issuecomment-1365510245
https://api.github.com/repos/huggingface/datasets/issues/5386
IC_kwDODunzps5RZAhl
https://api.github.com/repos/huggingface/datasets/issues/comments/1365510245/reactions
2022-12-26T23:45:51Z
https://api.github.com/repos/huggingface/datasets/issues/comments/1365510245
https://avatars.githubusercontent.com/u/1086393?v=4
https://api.github.com/users/salieri/events{/privacy}
https://api.github.com/users/salieri/followers
https://api.github.com/users/salieri/following{/other_user}
https://api.github.com/users/salieri/gists{/gist_id}
https://github.com/salieri
salieri
MDQ6VXNlcjEwODYzOTM=
https://api.github.com/users/salieri/orgs
https://api.github.com/users/salieri/received_events
https://api.github.com/users/salieri/repos
https://api.github.com/users/salieri/starred{/owner}{/repo}
https://api.github.com/users/salieri/subscriptions
User
https://api.github.com/users/salieri
public
### Describe the bug

`max_shard_size` parameter for `datasets.push_to_hub()` works unreliably with large files, generating shard files that are way past the specified limit.

In my private dataset, which contains unprocessed images of all sizes (up to `~100MB` per file), I've encountered cases where `max_shard_size='100MB'` results in shard files that are `>2GB` in size. Setting `max_shard_size` to another value, such as `1GB` or `500MB` does not fix this problem.

**The real problem is this:** When the shard file size grows too big, the entire dataset breaks because of #4721 and ultimately https://issues.apache.org/jira/browse/ARROW-5030. Since `max_shard_size` does not let one accurately control the size of the shard files, it becomes very easy to build a large dataset without any warnings that it will be broken -- even when you think you are mitigating this problem by setting `max_shard_size`.

```
  File " /path/to/sd-test-suite-v1/venv/lib/site-packages/datasets/builder.py", line 1763, in _prepare_split_single
    for _, table in generator:
  File " /path/to/sd-test-suite-v1/venv/lib/site-packages/datasets/packaged_modules/parquet/parquet.py", line 69, in _generate_tables
    for batch_idx, record_batch in enumerate(
  File "pyarrow/_parquet.pyx", line 1323, in iter_batches
  File "pyarrow/error.pxi", line 121, in pyarrow.lib.check_status
pyarrow.lib.ArrowNotImplementedError: Nested data conversions not implemented for chunked array outputs
```

### Steps to reproduce the bug

1. Clone [example repo](https://github.com/salieri/hf-dataset-shard-size-bug)
2. Follow steps in [README.md](https://github.com/salieri/hf-dataset-shard-size-bug/blob/main/README.md)
3. After uploading the dataset, you will see that the shard file size varies between `30MB` and `200MB` -- way beyond the `max_shard_size='75MB'` limit (example: `train-00003-of-00131...` is `155MB` in [here](https://huggingface.co/datasets/slri/shard-size-test/tree/main/data))

(Note that this example repo does not generate shard files that are so large that they would trigger #4721)

### Expected behavior

The shard file size should remain below or equal to `max_shard_size`.

### Environment info

- `datasets` version: 2.8.0
- Platform: Linux-5.10.157-139.675.amzn2.aarch64-aarch64-with-glibc2.17
- Python version: 3.7.15
- PyArrow version: 10.0.1
- Pandas version: 1.3.5