比Pandas 更好的替代？PySpark,Julia等对比

2021-01-28 12:08:17 表格是存储数据的最典型形式，在Python环境中没有比Pandas更好的工具来操作数据表了。 虽然Pandas具备宽泛的才干，但它还是有局限性的。比如，假设数据集超越了内存的大小，就必定选用一种替代方法。

表格是存储数据的最典型形式，在Python环境中没有比Pandas更好的工具来操作数据表了。 虽然Pandas具备宽泛的才干，但它还是有局限性的。比如，假设数据集超越了内存的大小，就必定选用一种替代方法。 然而，假设在内存适合的状况下丢弃Pandas经常使用其他工具能否无心义呢？

Pandas是一种繁难的表格数据处置器，提供了用于加载，处置数据集并将其导出为多种输入格局的多种方法。 Pandas可以处置少量数据，但遭到PC内存的限度。 数据迷信有一个黄金规律。 假设数据能够齐全载入内存（内存够大），请经常使用Pandas。 此规定如今依然有效吗？

为了验证这个疑问，让我们在中等大小的数据集上探求一些替代方法，看看我们能否可以从中受益，或许我们来确认只经常使用Pandas就可以了。

您可以在GitHub上检查完整的代码

pandas_alternatives_POC.ipynb —探求dask，spark，vaex和modin julia_POC.ipynb —探求julia和julia性能测试 Performance_test.py —运转python性能测试控制台运转 Results_and_Charts.ipynb —处置性能测试日志并创立图表

Pandas替代

让我们首先讨论反对替代Pandas的论点。

1. 他们不像Pandas那么普遍

1. 文档，教程和社区支持较小

我们将逐个回忆几种选用，并比拟它们的语法，计算方法和性能。 我们将看一下Dask，Vaex，PySpark，Modin（所有经常使用python）和Julia。 这些工具可以分为三类：

· 并行/云计算— Dask，PySpark和Modin

· 高效内存应用— Vaex

· 不同的编程言语— Julia

数据集

关于每种工具，我们将经常使用Kaggle欺诈检测数据集比拟基本操作的速度。 它蕴含两个文件train transaction.csv（〜700MB）和train identity.csv（〜30MB），我们将对其启动加载，兼并，聚合和排序，以检查性能有多快。 我将在具备16GB RAM的4核笔记本电脑上启动这些操作。

重要操作包括加载，兼并，排序和聚合数据

Dask-并行化数据框架

Dask的重要目的是并行化任何类型的python计算-数据处置，并行信息处置或机器学习。 裁减计算的方法是经常使用计算机集群的配置。 即使在单台PC上，也可以应用多个处置外围来放慢计算速度。

Dask处置数据框的模块形式通常称为DataFrame。 它的配置源自并行性，然而要付出必定的代价：

1. Dask API不如Pandas的API丰盛

1. 结果必定物化

Dask的语法与Pandas十分相似。

如您所见，两个库中的许多方法齐全相反。然而dask基本上缺少排序选项。 那是由于并行排序很不凡。 Dask仅提供一种方法，即set_index。 按定义索引排序。

我们的想法是经常使用Dask来成功惨重的上班，而后将缩减后的更小数据集移动到pandas上启动最后的处置。这就引出了第二个正告。必定经常使用.compute()命令详细化查问结果。

与PySpark一样，dask不会揭示您启动任何计算。 预备好一切步骤，并期待开局命令.compute（）而后开局上班。

为什么我们须要compute() 才干获取结果?

你或许会想，为什么我们不能立刻获取结果，就像你在Pandas手术时那样?要素很繁难。Dask重要用于数据大于内存的状况下，初始操作的结果（例如，渺小内存的负载）不可成功，由于您没有足够的内存来存储。

这就是为什么要预备计算步骤，而后让集群计算，而后前往一个更小的集，只蕴含结果。这是目前散布式计算框架的一个通用的做法。

# the dask code goes for example like this: df = dd.read_csv(path) d2 = dd.read_csv(path2) re = df.merge(d2, on="col") re = re.groupby(cols).agg(params).compute()

Dask性能

如何比拟用于不同目的的两个平台的速度并非易事。 结果也或许因数据而有所偏向。 一种工具可以十分极速地兼并字符串列，而另一种工具可以善于整数兼并。

为了展现这些库有多快，我选用了5个操作，并比拟了它们的速度。我重复了7次性能测试，我测量的cpu和内存经常使用率素来没有超越PC的50% (i7-5600 @ 2.60Ghz, 16GB Ram, SSD硬盘)。除了操作系统和性能测试之外，没有其他进程在运转。

· load_transactions —读取〜700MB CSV文件

· load_identity —读取〜30MB CSV文件

· merge—经过字符串列判别来将这两个数据汇合

· aggregation—将6列分组并计算总和友好均值

· sorting—对兼并数据集启动3次排序（假设库准许）

看起来Dask可以十分极速地加载CSV文件，然而要素是Dask的提前操作形式。 加载被推延，直到我在聚合环节中成功结果为止。 这象征着Dask仅预备加载和兼并，但详细加载的操作是与聚合一同口头的。

Dask对排序简直没有支持。 甚至官网的指点都说要运转并行计算，而后将计算出的结果（以及更小的结果）传递给Pandas。

即使我尝试计算read_csv结果，Dask在我的测试数据集上也要慢30％左右。 这仅证明了最后的假定，即Dask重要在您的数据集太大而不可加载到内存中是有用的。

它是用于Spark（剖析型大数据引擎）的python API。 Spark曾经在Hadoop平台之上开展，并且或许是最受欢迎的云计算工具。 它是用Scala编写的，然而pySpark API中的许多方法都可以让您启动计算，而不会损失python开发速度。

与Dask相似，首先定义一切操作，而后运转.collect（）命令以成功结果。 除了collect以外，还有更多选项，您可以在spark文档中了解它们。

PySpark语法

Spark正在经常使用弹性散布式数据集（RDD）启动计算，并且操作它们的语法与Pandas十分相似。 通常存在发生相反或相似结果的替代方法，例如sort或orderBy方法。

首先，必定初始化Spark会话。 而后经常使用python API预备步骤，也可以经常使用Spark SQL编写SQL代码间接操作。

假设只是为了测试，则不用装置spark，由于PySpark软件包随附了spark实例（单机形式）。 然而要求必定在PC上装置Java。

Spark性能

我经常使用了Dask局部中引见的pySpark启动了相反的性能测试，结果相似。

区别在于，spark读取csv的一局部可以推断数据的架构。 在这种状况下，与将整个数据集加载到Pandas相比破费了更多的时期。

Spark是应用大型集群的弱小配置启动海量计算的绝佳平台，可以对庞大的数据集启动极速的。但在相对较小的数据上经常使用Spark不会发生理想的速度提高。

到目前为止，我们曾经看到了将上班扩散在更多计算机外围之间以及群集中通常有许多计算机之间的平台。 他们还不可击败Pandas而 Vaex的指标是做到这一点。

作者创立该库是为了使数据集的基础剖析愈加极速。 Vaex虽然不支持Pandas的所有配置，但可以计算基本统计信息并极速创立某些图表类型。

Vaex语法

Pandas和vaex语法之间没有太多区别。

Vaex性能

与前两种工具不同，Vaex的速度与Pandas十分凑近，在某些地域甚至更快。

通常状况下，Pandas会很好，但也有或许你会遇到艰巨，这时刻可以尝试以下vaex。

Julia在数据迷信界颇受欢迎。虽然尚未取得打破，但人们曾预言它会有一个辉煌的未来，并且有很多人爱上了Julia的处置形式。

与python相反，Julia是一种编译言语。这通常会带来更好的性能。这两种言语都可以在jupiter notebook上运转，这就是为什么Julia在数据迷信证明方面很受欢迎。

Julia语法

Julia是专门为数学家和数据迷信家开发的。虽然Julia是一种不同的言语，但它以python的形式做很多事件，它还会在适合的时刻经常使用自己的技巧。

另一方面，在python中，有许多种类库成功相反的配置，这对初学者十分不友好。然而Julia提供内置的方法来成功一些基本的事件，比如读取csv。

让我们来比拟一下pandas和julia中数据加载、兼并、聚合和排序的成果。

Julia性能

要权衡Julia的速度并不是那么繁难。 初次运转任何Julia代码时，即时编译器都须要将其翻译为计算机言语，这须要一些时期。 这就是为什么任何代码的第一次性运转都比后续运转破费更长的时期的要素。

在上方的图表中，您可以看到第一次性运转的时期显著善于其他六次测量的平均值。 我还尝试过在单个内核（julia）和4个处置器内核（julia-4）上运转Julia。

经过将环境变量JULIATHREADS设置为要经常使用的内核数，可以运转具备更多内核的julia。 从1.5开局，您可以经过julia -t n或julia --threads n启动julia，其中n是所需的内核数。

经常使用更多核的处置通常会更快，并且julia对开箱即用的并行化有很好的支持。 您或许会担忧编译速度，然而不须要，该代码将被编译一次性，并且更改参数不会强迫从新编译。 例如在编译CSV.read(joinpath(folder,file),>

在完结无关Pandas替代品的讨论之前，我必定提到Modin库。 它的作者宣称，modin应用并行性来放慢80％的Pandas配置。 可怜的是，目前没发现作者宣称的速度优化。 并且有时在初始化Modin库导入命令时期会终止。 有一些状况，modin揭示："not supported, defaulting to pandas"，而后该操作终解体了，只剩下4个python进程，每个进程都占用少量内存。 使得我之后花了一些时期杀死这些进程。

我青睐modin面前的想法，我宿愿有一天能够补偿这些差距，从而使modin优化为值得思考的替代打算。

最后总结

我们曾经探求了几种盛行的Pandas替代品，以确定假设数据集足够小，可以齐全装入内存，那么经常使用其他数据能否无心义。

目前来看没有一个并行计算平台能在速度上超越Pandas。思考到它们更复杂的语法、额外的装置要求和不足一些数据处置才干，这些工具不能作为pandas的理想替代品。

Vaex显示了在数据探求环节中减速某些义务的后劲。在更大的数据集中，这种好处会变得更显著。

Julia的开发思考到了数据迷信家的需求。它或许没有Pandas那么受欢迎，或许也没有Pandas所能提供的一切技巧。关于某些操作，它可以提供性能优化，我必定说，有些代码在julia中更优雅。即使Julia没有进入前20名最盛行的编程言语，我想它还是有出路的，假设你关注它的开发，你就不会犯失误。

最后假设你想复现这些结果，请在检查这个代码：github/vaclavdekanovsky/data-analysis-in-examples/tree/master/DataFrames/Pandas_Alternatives

译者注：虽然我不时觉得pandas有点慢，然而看了上方的评测，还是继续用pandas吧。另外这里有个小技巧，pandas读取csv很慢，例如我自己会经常读取5-10G左右的csv文件，这时在第一次性读取后经常使用to pickle保留成pickle文件，在加载时用read pickle读取pickle文件，不只速度上会快10几倍，文件的大小也会有2-5倍的减小（减小水平取决于你dataframe的内容和数据类型）

最后总结还是那句话，当数据能所有加载到内存外面的时刻，用Pandas就对了