Persist multiple Dask collections into memory This turns lazy Dask collections into Dask collections with the same metadata, but now with their results fully computed or actively computing in the background. For example a lazy dask.array built up from many lazy calls will now be a
(*args, traverse=True, optimize_graph=True, scheduler=None, **kwargs)
| 1014 | |
| 1015 | |
| 1016 | def persist(*args, traverse=True, optimize_graph=True, scheduler=None, **kwargs): |
| 1017 | """Persist multiple Dask collections into memory |
| 1018 | |
| 1019 | This turns lazy Dask collections into Dask collections with the same |
| 1020 | metadata, but now with their results fully computed or actively computing |
| 1021 | in the background. |
| 1022 | |
| 1023 | For example a lazy dask.array built up from many lazy calls will now be a |
| 1024 | dask.array of the same shape, dtype, chunks, etc., but now with all of |
| 1025 | those previously lazy tasks either computed in memory as many small :class:`numpy.array` |
| 1026 | (in the single-machine case) or asynchronously running in the |
| 1027 | background on a cluster (in the distributed case). |
| 1028 | |
| 1029 | This function operates differently if a ``dask.distributed.Client`` exists |
| 1030 | and is connected to a distributed scheduler. In this case this function |
| 1031 | will return as soon as the task graph has been submitted to the cluster, |
| 1032 | but before the computations have completed. Computations will continue |
| 1033 | asynchronously in the background. When using this function with the single |
| 1034 | machine scheduler it blocks until the computations have finished. |
| 1035 | |
| 1036 | When using Dask on a single machine you should ensure that the dataset fits |
| 1037 | entirely within memory. |
| 1038 | |
| 1039 | Examples |
| 1040 | -------- |
| 1041 | >>> df = dd.read_csv('/path/to/*.csv') # doctest: +SKIP |
| 1042 | >>> df = df[df.name == 'Alice'] # doctest: +SKIP |
| 1043 | >>> df['in-debt'] = df.balance < 0 # doctest: +SKIP |
| 1044 | >>> df = df.persist() # triggers computation # doctest: +SKIP |
| 1045 | |
| 1046 | >>> df.value().min() # future computations are now fast # doctest: +SKIP |
| 1047 | -10 |
| 1048 | >>> df.value().max() # doctest: +SKIP |
| 1049 | 100 |
| 1050 | |
| 1051 | >>> from dask import persist # use persist function on multiple collections |
| 1052 | >>> a, b = persist(a, b) # doctest: +SKIP |
| 1053 | |
| 1054 | Parameters |
| 1055 | ---------- |
| 1056 | *args: Dask collections |
| 1057 | scheduler : string, optional |
| 1058 | Which scheduler to use like "threads", "synchronous" or "processes". |
| 1059 | If not provided, the default is to check the global settings first, |
| 1060 | and then fall back to the collection defaults. |
| 1061 | traverse : bool, optional |
| 1062 | By default dask traverses builtin python collections looking for dask |
| 1063 | objects passed to ``persist``. For large collections this can be |
| 1064 | expensive. If none of the arguments contain any dask objects, set |
| 1065 | ``traverse=False`` to avoid doing this traversal. |
| 1066 | optimize_graph : bool, optional |
| 1067 | If True [default], the graph is optimized before computation. |
| 1068 | Otherwise the graph is run as is. This can be useful for debugging. |
| 1069 | **kwargs |
| 1070 | Extra keywords to forward to the scheduler function. |
| 1071 | |
| 1072 | Returns |
| 1073 | ------- |