Pandas、Dask、Spark 和 Arrow 的高级性能表现

这项工作由 Anaconda Inc 提供支持

问题

Dask 数据框的性能与 Pandas 相比如何？Spark 数据框和 Arrow 又如何？它们之间如何比较？

我每隔几周就会收到这个问题。写这篇帖子是为了避免重复。

注意事项

这个答案可能会随着时间而改变。我写这篇文章时是 2018 年 8 月。
这个问题和答案都非常高层。更技术性的答案是可能的，但这里不包含。

答案

Pandas

如果你来自 Python 并且数据集较小，那么 Pandas 是正确的选择。它易于使用，被广泛理解，高效且维护良好。

并行计算的优势

使用 Dask 数据框或 Spark 数据框等并行数据框相比 Pandas 的性能优势（或劣势）将取决于你进行的计算类型

如果你进行小型计算，那么 Pandas 始终是正确的选择。并行化的管理成本将超过任何收益。如果你的计算耗时少于 100 毫秒（例如），则不应进行并行化。
对于过滤、清理和聚合大型数据等简单操作，你应该期望通过使用并行数据框获得线性加速。

如果你使用 20 核计算机，你可能会期望 20 倍的加速。如果你使用 1000 核集群，你可能会期望 1000 倍的加速，前提是你有一个足够大的问题可以分散到 1000 个核心上。随着规模的扩大，管理开销会增加，因此你应该期望加速效果会略有下降。
对于分布式连接等复杂操作，情况更为复杂。你可能会获得像上面那样的线性加速，或者甚至可能出现减速。在类似数据库计算和并行计算方面有经验的人可能会很好地预测哪些计算会表现良好。

然而，可能需要进行配置。人们经常发现在首次尝试并行解决方案时，它们未能达到预期。不幸的是，大多数分布式系统都需要一些配置才能达到最佳性能。

还有其他加速 Pandas 的方法

许多希望加速 Pandas 的人并不需要并行计算。通常还有其他一些技巧，例如编码文本数据、使用高效的文件格式、避免使用 groupby.apply 等，这些方法在加速 Pandas 方面比转向并行计算更有效。

比较 Apache Spark 和 Dask

假设是的，我确实需要并行计算，我应该选择 Apache Spark 还是 Dask 数据框？

这通常更多地取决于文化偏好（JVM vs Python，一体化工具 vs 与其他工具集成），而不是性能差异，但我会在这里尝试概述一些事情。

当你处理大型 SQL 风格的查询（例如 100 多行的查询），并且它们的查询优化器可以发挥作用时，Spark 数据框会好得多。
当查询超出典型数据库查询范围时，Dask 数据框会好得多。这最常发生在时间序列、随机访问和其他复杂计算中。
Spark 会更好地与 JVM 和数据工程技术集成。Spark 也会预装所有东西。Spark 是它自己的生态系统。
Dask 会更好地与 Python 代码集成。Dask 旨在与其他库和现有系统集成。如果你来自现有的基于 Pandas 的工作流程，那么迁移到 Dask 通常会容易得多。

总的来说，对于大多数操作，使用其中任何一个都可以。人们通常根据文化偏好在 Pandas/Dask 和 Spark 之间进行选择。要么他们有非常喜欢 Python 生态系统的人，要么他们有非常喜欢 Spark 生态系统的人。

数据框也只是每个项目的一小部分。Spark 和 Dask 都做了很多其他与数据框无关的事情。例如，Spark 有一个图分析库，Dask 没有。Dask 支持多维数组，Spark 不支持。Spark 通常更高层且一体化，而 Dask 则更底层，专注于与其他工具集成。

欲了解更多信息，请参阅 Dask 的“与 Spark 的比较文档” 或这篇对数据分析公司 Steppingblocks 的采访，内容关于他们为什么从 Spark 转向 Dask。

Apache Arrow

Arrow 呢？Arrow 比 Pandas 快吗？

这个问题还不太恰当……至少目前是这样。

Arrow 不是 Pandas 的替代品。今天，Arrow 对构建系统的人有用，而不是直接对像 Pandas 那样的分析师有用。Arrow 用于在不同的计算系统和文件格式之间移动数据。Arrow 今天不做计算，但常被用作其他进行计算的库的组件。例如，如果你今天使用 Pandas、Spark 或 Dask，你可能在不知不觉中使用了 Arrow。今天，Arrow 对其他库更有用，而不是对最终用户。

然而，未来这种情况可能会改变。Arrow 的开发者计划围绕 Arrow 编写计算代码，我们预期这些代码会比 Pandas 或 Spark 中的代码更快。不过这可能还需要一两年的时间。可能会有一些努力使其与 Pandas 半兼容，但这还为时过早。

博客评论由 Disqus 提供支持