如果你今天正在使用 Dask 解决有趣的问题，我们非常乐意邀请你分享你的故事。听取像你这样的经验用户的分享，可以帮助新用户快速识别 Dask 及周边生态系统中可能对他们有价值的部分。
如何分享你的故事
我们欢迎任何形式的故事。然而，如果你需要一些指导，我们建议遵循以下规范。我们在下面提供了如何分解故事的建议，包括每组说明旁边的两个完全虚构的故事。
你是谁？
请包含你的姓名、你参与的项目以及你在该项目中的角色。一些例子
欢迎提供链接。
你试图解决什么问题？
在此处包含你正在尝试解决的问题的背景和详细信息。此处非常欢迎详细信息。你可能是在写给本领域的人，所以请随意使用技术术语。你不一定需要在这里提及 Dask；请专注于你的问题。
示例：XYZ 汽车公司
XYZ 汽车公司生产数千种汽车零部件，每种零部件产量达数百万。许多这些零部件会每秒生成关于其运行状况的遥测数据。我们随时间处理这些信息，以了解零部件何时可能发生故障，以及何种活动可能导致故障。这有助于我们采取多种方式应对
我们提醒司机应尽快维修他们的车辆，从而减少在路上发生严重问题的几率
我们告知汽车维修技师问题所在，从而降低诊断成本
我们将这些发现反馈到设计过程中，帮助我们的工程师开发可靠的产品。
然而，分析数十亿个时间序列很困难，特别是当这些时间序列来自数千种不同类型的设备时。这既是一个“大数据”问题，也是一个“异构数据”问题。我们雇佣了一个数据科学家团队来分析这些数据。我们使用 Pandas、Scikit-Learn、statsmodels 以及 lifelines 进行生存分析，同时使用一些内部库。特别是我们发现，随着业务增长，扩展生存分析变得困难。
示例：太阳天文学家
我的研究分析来自高分辨率太阳天文学数据的相关信息，这些信息可能预示着太阳耀斑活动或与太阳黑子相关。这既有助于我们对磁流体动力学 (MHD) 基础科学的理解，也提高了地球卫星群在危险太阳风暴事件中的耐用性。
实际上，这意味着我们构建算法来分析实时高分辨率太阳图像流，以预测未来活动。我们进行图像分割以查找测试数据点，并对图像进行空间和时间上的离散小波变换，为下游机器学习算法创建特征。
我们的数据量很大。单张图像可达数百兆字节，我们拥有多年的数据。这意味着数据量达到数百太字节。
Dask 如何提供帮助
描述 Dask 如何帮助解决这个问题。同样，欢迎详细信息。新读者可能不知道诸如“我们使用 client.scatter”这样的具体 API，但很可能能理解文档标题中使用的术语，例如“我们同时使用了 dask dataframe 和 futures 接口”。
我们也鼓励你提及你对 Dask 的使用随时间推移如何变化。最初是什么吸引你使用这个项目？你现在使用它还是因为同样的原因吗？或者你的看法或需求已经改变了？
示例：XYZ 汽车公司
Dask 通过并行化我们的内部时间序列库来帮助我们解决问题。我们处于一种奇怪的境地，我们拥有“大数据”，但数据种类非常不同，因此像时间序列数据库、Apache Spark 或 Dask Dataframe 这样的标准项目并不是很适合。然而，我们发现我们可以直接使用 Pandas/Scikit-Learn/Lifelines 代码以及 Dask delayed 轻松并行化我们现有的解决方案。代码仍然和我们之前差不多（这是好的，我们在这方面投入了很多），但现在它可以在更大的数据集上很好地运行，并利用我们所有的核心。
因此，我们的大型分析工作站迅速变得非常受欢迎，我们不得不购置更多设备，但人们似乎都很高兴。我们研究了用于集群计算的分布式调度器，它很有趣，但我们还没有找到足够的业务需求。
示例：太阳天文学家
我们使用 Dask Arrays 利用 Numpy API 处理大型图像栈。我和我的大多数同事都熟悉 Numpy，因此使用 Dask Array 进行并行化的学习曲线非常容易。我们有两种常见的工作负载
最后，当我们尝试新的数据集时，我们也会使用 Dask 数组。现在，在我们笔记本电脑上随意摸索时，它是我们首选的解决方案。
我们也在开始使用 Dask 的 futures 接口，同时我们正在为实时分析和警报开发一个实时处理系统原型，但这只是一个独立的项目。
最初，大部分工作是在我的笔记本电脑上使用本地调度器开始的。然而，随着我们开始处理一些更复杂的工作负载，我们发现 Dask 不再能够在低内存环境中完成所有工作。因此，我们现在在集群上使用 dask.distributed 处理 10+TB 的图像栈。我们考虑过扩展更大规模，但目前还没有资源分配。
使用 Dask 解决你的问题的一些痛点
Dask 存在一些问题，并且它并非总是适用于所有问题的正确解决方案。你遇到了哪些你认为本领域的其他人应该提前了解的问题？
示例：XYZ 汽车公司
当我们开始使用并行化时，我们发现代码库的很大一部分无法很好地并行化。我们使用了大量的字符串比较，这与 GIL 不兼容。我们转而使用 Dask 的多进程调度器，但通信成本太高了。最终，我们通过使用 Pandas categoricals 解决了这个问题，这很好地解决了问题，但每个进程最多只能利用大约 16 个核心。
我们在诊断方面也遇到了一些问题。本地调度器上的诊断信息不如分布式调度器上的好。两者都有权衡。
示例：太阳天文学家
让新用户熟悉惰性求值花了一些时间。
当我们刚开始时，使用 dask array 重叠计算的开销非常高。尽管如此，在最新版本中似乎已经基本修复了这个问题。不过，随着我们继续扩展到更大的数据集，我们感觉总会遇到新的开销类型。这可以克服，而且情况正在好转很多，但如果你想处理 100TB 的数据，预计需要进行一些调优。幸运的是，代码库都是 Python，所以我们能够改进并向上游发送补丁。
使用分布式调度器时，我们遇到了 HPC 集群的问题，它对 workers 内存耗尽非常挑剔。花了一些时间才配置正确，以便 workers 在集群发现它们之前自行关闭。
你在使用 Dask 时用到的其他技术
这可能包括你与 Dask 一起用于分析或数据存储的其他库。你用于部署或捕获日志的集群技术等。任何你认为与你相似的人可能想了解的信息。
示例：XYZ 汽车公司
我们主要使用 Pandas、Scikit-Learn 和 Lifelines 进行计算。我们获取 CSV 格式的数据并使用 Arrow 转换为 Parquet。我们使用通用的 PyData 技术栈进行绘图等操作。