dask.LocalCluster参数解析

n_workers：节点数量，默认是None

threads_per_worker：节点线程数，默认是None

processes：是否开进程并发，默认是True

    dask的源码是这样的：

    然后我们看看n_wokers和threads_per_worker的处理逻辑：

    nprocesses_nthreads的源码：

    CPU_COUNT的源码：

    所以实际上你不用可以设置n_workers和threads_per_worker，它会自动利用到你所有的cpu核心线程数并且自动分配，比如六核十二线程的cpu，cpu_count = 12，它会分配成n_workers = 4 / threads_per_workers = 3。

    但你需要注意的是，这样的分配是一定不会把cpu性能跑满的，因为本质上对于12线程的cpu，如果希望它们同时并发地工作，能真正并发的最大进程数量就是12，所以只有当n_workers = 12的情况下，理论上你的cpu负载才可能达到100%。n_workers = 4 / threads_per_workers = 3本质上是4个节点使用进程，每个节点进程下开3个线程，线程之间是竞争同一个进程资源的。所以理论上假设你空闲时候的cpu占用是10%，那么你最高的cpu占用只能达到 10% + (4 / 12) = 43.3% ，你的并发也会更慢。

    所以实际上如果你希望你的cpu满载，那么n_workers = cpu_count，也就是cpu线程数，而threads_per_worker就设为1，多于1我认为是没有意义的，它们竞争的是同一个进程的资源，况且python还有GIL。以下是我的项目代码在不同n_workers和threads_per_worker下的运行速度（六核十二线程）：

    当然更少的n_workers意味着在固定内存大小的情况下，每个节点的工作内存会更大，更大的工作内存能够避免dask在工作过程中出现memory leak的warning。

memory_limit：单个节点内存限制，

    不设就自适应，默认把你剩下能用的内存平均劈给每一个节点

    None或者0就不设限，能直接给你内存挤爆

scheduler_port： 调度器的监听端口

    默认是0，就是随机选端口

    本质上它在哪个端口不重要，因为我们只和dashboard交互

silence_logs：日志等级，默认是logging.WARN

    所以当你不知道怎么debug dask报出来的各种各样的warning时，你就把它调高，看不见就等于没有

host：调度器监听的主机名，默认是localhost

    本地集群下就不用管，调度器就在本机

ip：deprecated

dashboard_address：可视化界面地址

    模式是本机下的8787端口

worker_dashboard_address：可视化界面下的worker界面的地址

    默认禁用了该功能，因为本质上主界面就可以点到worker界面

    当然一般情况下我们就看主界面就行

    worker界面会详细显示每个节点的资源状况，一般情况不看那么细

diagnostics_port：deprecated

asynchronous：是否涉及异步

    也就是当你的并发操作是异步函数的时候，需要把它设为True

    其他情况下最好保持是False

worker_class：节点类

    本质上它就是个pipe line，你可以重写里面的get_data和compute方法来实现一些管道方法，比如数据预处理、结果存储

    不过一般我们还是把逻辑写在外部，可读性会高一点

    在使用进程作为节点的情况下，重写的父类叫做Nanny，否则重写的父类叫Worker