PERF-#5740: allow read_csv, read_fwf, read_table, read_custom_text functions be executed fully asynchronous; introduce ModinDtypes

[anmyachev]

What do these changes do?

• The PR introduce new type that can be stored in dataframe._dtypes: callable() -> pandas.Series. Together with PR#5677, it makes the execution of read_csv function completely asynchronous. Unlike an index, a dtypes can be restored from internal partitions, however, if zero pickling does not work, this will lead to additional copy operations.
• As with the index cache in PR#5677, this PR offers additional functions to make working with the dtypes cache easier: has_dtypes_cache, copy_dtypes_cache.
• For backends that do not support this new behavior, it is enough to trigger the dtypes calculation in the constructor, as is done for hdk.
• First side effect of this pull request is that ._dtypes field is now always copied if possible. Same reasoning as for the index cache.
• Second side effect is if reading occurs in a context that deletes the files from which we are reading, then in some situations, given the asynchronous behavior, this will lead to the fact that by the time reading actually starts, the file may already be deleted. This, for example, affects our tests, which had to be rewritten.
• Also, one of the debatable changes in the PR is the removal of the section of code that performs astype function in the case of categorical data types. Turns out we don't have tests for that. However, the reproducer that was used for this change no longer works, and the error is not reproduced. Based on this, I decided to delete this section. Obviously, this is not a sufficient condition for deleting this section, only a necessary one. However, if we really need this code, then it is not clear why it is called only after the read functions, and not after all. As far as I understand, we are not sure that for one column we will have the same type among all partitions.

• first commit message and PR title follow format outlined here

  NOTE: If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

• passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
• passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
• signed commit with git commit -s
• Resolves PERF: make dtypes computation lazy for read_csv function #5740
• tests added and passing
• module layout described at docs/development/architecture.rst is up-to-date

[anmyachev]

This is mostly a refactoring change, but it's also safer to use since the function triggers the materialization via force_materialization.

[YarShev]

Why do we want to call copy now?

[anmyachev]

This is a mutable object, we can accidentally change for multiple dataframes when we planned to only for one.

[YarShev]

Why have we not come across the issue till this moment?

[anmyachev]

I think we've already come across this. @dchigarev Have you already fixed something like this?

[anmyachev]

For example this one. Although it was only about copying, the problem is the same.

[dchigarev]

I think we should introduce the same class wrapper around a callable as was suggested in #5677 (comment).

Operations with dtypes cache have a lot of potential to be optimized (like a delayed cast, partially known dtypes, lazy type-proxies, etc), so I think it's crucial to add a simple class-wrapper at the beginning that could then easily be extended for our future needs.

[anmyachev]

Second side effect is if reading occurs in a context that deletes the files from which we are reading, then in some situations, given the asynchronous behavior, this will lead to the fact that by the time reading actually starts, the file may already be deleted. This, for example, affects our tests, which had to be rewritten.

Should we emphasize this in docs somewhere?

I think the description of ASYNC_READ_MODE variable is enough.
Do you know the place in the documentation where the environment variables are described?

[dchigarev]

I think the description of ASYNC_READ_MODE variable is enough.
Do you know the place in the documentation where the environment variables are described?

As far as I understand they're automatically grabbed from a CSV file that is generated during the documentation build:
https://github.com/modin-project/modin/blame/master/docs/flow/modin/config.rst#L26-L28

modin/docs/conf.py

Lines 46 to 50 in 4633639

	configs_file_path = os.path.abspath(
	os.path.join(os.path.dirname(__file__), "flow/modin/configs_help.csv")
	)
	# Export configs help to create configs table in the docs/flow/modin/config.rst
	export_config_help(configs_file_path)

So no additional steps are required to add the variable to the docs.

[dchigarev]

LGTM!

The only thing that bothers me is the way we materialize in a non-async mode.

[dchigarev]

Interesting, can you please raise an issue regarding this so we can investigate this behavior further? Maybe the first call somehow caches the result and then returns it when we being called for the second time...

[YarShev]

I think the description of ASYNC_READ_MODE variable is enough.
Do you know the place in the documentation where the environment variables are described?

As far as I understand they're automatically grabbed from a CSV file that is generated during the documentation build: https://github.com/modin-project/modin/blame/master/docs/flow/modin/config.rst#L26-L28

modin/docs/conf.py

Lines 46 to 50 in 4633639

	configs_file_path = os.path.abspath(
	os.path.join(os.path.dirname(__file__), "flow/modin/configs_help.csv")
	)
	# Export configs help to create configs table in the docs/flow/modin/config.rst
	export_config_help(configs_file_path)

So no additional steps are required to add the variable to the docs.

I am still thinking of a page where we could put some notes regarding async read. Maybe here https://modin.readthedocs.io/en/stable/supported_apis/io_supported.html?

[anmyachev]

I think the description of ASYNC_READ_MODE variable is enough.
Do you know the place in the documentation where the environment variables are described?

As far as I understand they're automatically grabbed from a CSV file that is generated during the documentation build: https://github.com/modin-project/modin/blame/master/docs/flow/modin/config.rst#L26-L28

modin/docs/conf.py

Lines 46 to 50 in 4633639

	configs_file_path = os.path.abspath(
	os.path.join(os.path.dirname(__file__), "flow/modin/configs_help.csv")
	)
	# Export configs help to create configs table in the docs/flow/modin/config.rst
	export_config_help(configs_file_path)

So no additional steps are required to add the variable to the docs.

I am still thinking of a page where we could put some notes regarding async read. Maybe here https://modin.readthedocs.io/en/stable/supported_apis/io_supported.html?

Added

[YarShev]

@dchigarev, any comments?

[anmyachev]

@YarShev @dchigarev can we merge it?