表格是存儲(chǔ)數(shù)據(jù)的最典型方式，在Python環(huán)境中沒有比Pandas更好的工具來操作數(shù)據(jù)表了。 盡管Pandas具有廣泛的能力，但它還是有局限性的。比如，如果數(shù)據(jù)集超過了內(nèi)存的大小，就必須選擇一種替代方法。 但是，如果在內(nèi)存合適的情況下放棄Pandas使用其他工具是否有意義呢？

Pandas是一種方便的表格數(shù)據(jù)處理器，提供了用于加載，處理數(shù)據(jù)集并將其導(dǎo)出為多種輸出格式的多種方法。 Pandas可以處理大量數(shù)據(jù)，但受到PC內(nèi)存的限制。 數(shù)據(jù)科學(xué)有一個(gè)黃金法則。 如果數(shù)據(jù)能夠完全載入內(nèi)存（內(nèi)存夠大），請使用Pandas。 此規(guī)則現(xiàn)在仍然有效嗎？

為了驗(yàn)證這個(gè)問題，讓我們在中等大小的數(shù)據(jù)集上探索一些替代方法，看看我們是否可以從中受益，或者咱們來確認(rèn)只使用Pandas就可以了。

您可以在GitHub上查看完整的代碼

pandas_alternatives_POC.ipynb —探索dask，spark，vaex和modin julia_POC.ipynb —探索julia和julia性能測試 Performance_test.py —運(yùn)行python性能測試控制臺(tái)運(yùn)行 Results_and_Charts.ipynb —處理性能測試日志并創(chuàng)建圖表

Pandas替代

讓我們首先探討反對替代Pandas的論點(diǎn)。

1. 他們不像Pandas那么普遍

1. 文檔，教程和社區(qū)支持較小

我們將逐一回顧幾種選擇，并比較它們的語法，計(jì)算方法和性能。 我們將看一下Dask，Vaex，PySpark，Modin（全部使用python）和Julia。 這些工具可以分為三類：

· 并行/云計(jì)算— Dask，PySpark和Modin

· 高效內(nèi)存利用— Vaex

· 不同的編程語言— Julia

數(shù)據(jù)集

對于每種工具，我們將使用Kaggle欺詐檢測數(shù)據(jù)集比較基本操作的速度。 它包含兩個(gè)文件traintransaction.csv（〜700MB）和trainidentity.csv（〜30MB），我們將對其進(jìn)行加載，合并，聚合和排序，以查看性能有多快。 我將在具有16GB RAM的4核筆記本電腦上進(jìn)行這些操作。

主要操作包括加載，合并，排序和聚合數(shù)據(jù)

Dask-并行化數(shù)據(jù)框架

Dask的主要目的是并行化任何類型的python計(jì)算-數(shù)據(jù)處理，并行消息處理或機(jī)器學(xué)習(xí)。 擴(kuò)展計(jì)算的方法是使用計(jì)算機(jī)集群的功能。 即使在單臺(tái)PC上，也可以利用多個(gè)處理核心來加快計(jì)算速度。

Dask處理數(shù)據(jù)框的模塊方式通常稱為DataFrame。 它的功能源自并行性，但是要付出一定的代價(jià)：

1. Dask API不如Pandas的API豐富

1. 結(jié)果必須物化

Dask的語法與Pandas非常相似。

如您所見，兩個(gè)庫中的許多方法完全相同。但是dask基本上缺少排序選項(xiàng)。 那是因?yàn)椴⑿信判蚝芴厥狻?Dask僅提供一種方法，即set_index。 按定義索引排序。

我們的想法是使用Dask來完成繁重的工作，然后將縮減后的更小數(shù)據(jù)集移動(dòng)到pandas上進(jìn)行最后的處理。這就引出了第二個(gè)警告。必須使用.compute()命令具體化查詢結(jié)果。

與PySpark一樣，dask不會(huì)提示您進(jìn)行任何計(jì)算。 準(zhǔn)備好所有步驟，并等待開始命令.compute（）然后開始工作。

為什么我們需要compute() 才能得到結(jié)果?

你可能會(huì)想，為什么我們不能立即得到結(jié)果，就像你在Pandas手術(shù)時(shí)那樣?原因很簡單。Dask主要用于數(shù)據(jù)大于內(nèi)存的情況下，初始操作的結(jié)果（例如，巨大內(nèi)存的負(fù)載）無法實(shí)現(xiàn)，因?yàn)槟鷽]有足夠的內(nèi)存來存儲(chǔ)。

這就是為什么要準(zhǔn)備計(jì)算步驟，然后讓集群計(jì)算，然后返回一個(gè)更小的集，只包含結(jié)果。這是目前分布式計(jì)算框架的一個(gè)通用的做法。

# 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性能

如何比較用于不同目的的兩個(gè)平臺(tái)的速度并非易事。 結(jié)果也可能因數(shù)據(jù)而有所偏差。 一種工具可以非?？焖俚睾喜⒆址?，而另一種工具可以擅長整數(shù)合并。

為了展示這些庫有多快，我選擇了5個(gè)操作，并比較了它們的速度。我重復(fù)了7次性能測試，我測量的cpu和內(nèi)存使用率從來沒有超過PC的50% (i7-5600 @ 2.60Ghz, 16GB Ram, SSD硬盤)。除了操作系統(tǒng)和性能測試之外，沒有其他進(jìn)程在運(yùn)行。

· load_transactions —讀取〜700MB CSV文件

· load_identity —讀取〜30MB CSV文件

· merge—通過字符串列判斷來將這兩個(gè)數(shù)據(jù)集合

· aggregation—將6列分組并計(jì)算總和和平均值

· sorting—對合并數(shù)據(jù)集進(jìn)行3次排序（如果庫允許）

看起來Dask可以非常快速地加載CSV文件，但是原因是Dask的延遲操作模式。 加載被推遲，直到我在聚合過程中實(shí)現(xiàn)結(jié)果為止。 這意味著Dask僅準(zhǔn)備加載和合并，但具體加載的操作是與聚合一起執(zhí)行的。

Dask對排序幾乎沒有支持。 甚至官方的指導(dǎo)都說要運(yùn)行并行計(jì)算，然后將計(jì)算出的結(jié)果（以及更小的結(jié)果）傳遞給Pandas。

即使我嘗試計(jì)算read_csv結(jié)果，Dask在我的測試數(shù)據(jù)集上也要慢30％左右。 這僅證實(shí)了最初的假設(shè)，即Dask主要在您的數(shù)據(jù)集太大而無法加載到內(nèi)存中是有用的。

PySpark

它是用于Spark（分析型大數(shù)據(jù)引擎）的python API。 Spark已經(jīng)在Hadoop平臺(tái)之上發(fā)展，并且可能是最受歡迎的云計(jì)算工具。 它是用Scala編寫的，但是pySpark API中的許多方法都可以讓您進(jìn)行計(jì)算，而不會(huì)損失python開發(fā)速度。

與Dask類似，首先定義所有操作，然后運(yùn)行.collect（）命令以實(shí)現(xiàn)結(jié)果。 除了collect以外，還有更多選項(xiàng)，您可以在spark文檔中了解它們。

PySpark語法

Spark正在使用彈性分布式數(shù)據(jù)集（RDD）進(jìn)行計(jì)算，并且操作它們的語法與Pandas非常相似。 通常存在產(chǎn)生相同或相似結(jié)果的替代方法，例如sort或orderBy方法。

首先，必須初始化Spark會(huì)話。 然后使用python API準(zhǔn)備步驟，也可以使用Spark SQL編寫SQL代碼直接操作。

如果只是為了測試，則不必安裝spark，因?yàn)镻ySpark軟件包隨附了spark實(shí)例（單機(jī)模式）。 但是要求必須在PC上安裝Java。

Spark性能

我使用了Dask部分中介紹的pySpark進(jìn)行了相同的性能測試，結(jié)果相似。

區(qū)別在于，spark讀取csv的一部分可以推斷數(shù)據(jù)的架構(gòu)。 在這種情況下，與將整個(gè)數(shù)據(jù)集加載到Pandas相比花費(fèi)了更多的時(shí)間。

Spark是利用大型集群的強(qiáng)大功能進(jìn)行海量計(jì)算的絕佳平臺(tái)，可以對龐大的數(shù)據(jù)集進(jìn)行快速的。但在相對較小的數(shù)據(jù)上使用Spark不會(huì)產(chǎn)生理想的速度提高。

Vaex

到目前為止，我們已經(jīng)看到了將工作分散在更多計(jì)算機(jī)核心之間以及群集中通常有許多計(jì)算機(jī)之間的平臺(tái)。 他們還無法擊敗Pandas而 Vaex的目標(biāo)是做到這一點(diǎn)。

作者創(chuàng)建該庫是為了使數(shù)據(jù)集的基礎(chǔ)分析更加快速。 Vaex雖然不支持Pandas的全部功能，但可以計(jì)算基本統(tǒng)計(jì)信息并快速創(chuàng)建某些圖表類型。

Vaex語法

Pandas和vaex語法之間沒有太多區(qū)別。

Vaex性能

與前兩種工具不同，Vaex的速度與Pandas非常接近，在某些地區(qū)甚至更快。

通常情況下，Pandas會(huì)很好，但也有可能你會(huì)遇到困難，這時(shí)候可以嘗試以下vaex。

Julia

Julia在數(shù)據(jù)科學(xué)界頗受歡迎。盡管尚未取得突破，但人們曾預(yù)言它會(huì)有一個(gè)輝煌的未來，并且有很多人愛上了Julia的處理方式。

與python相反，Julia是一種編譯語言。這通常會(huì)帶來更好的性能。這兩種語言都可以在jupiter notebook上運(yùn)行，這就是為什么Julia在數(shù)據(jù)科學(xué)證明方面很受歡迎。

Julia語法

Julia是專門為數(shù)學(xué)家和數(shù)據(jù)科學(xué)家開發(fā)的。盡管Julia是一種不同的語言，但它以python的方式做很多事情，它還會(huì)在合適的時(shí)候使用自己的技巧。

另一方面，在python中，有許多種類庫完成相同的功能，這對初學(xué)者非常不友好。但是Julia提供內(nèi)置的方法來完成一些基本的事情，比如讀取csv。

讓我們來比較一下pandas和julia中數(shù)據(jù)加載、合并、聚合和排序的效果。

Julia性能

要衡量Julia的速度并不是那么簡單。 首次運(yùn)行任何Julia代碼時(shí)，即時(shí)編譯器都需要將其翻譯為計(jì)算機(jī)語言，這需要一些時(shí)間。 這就是為什么任何代碼的第一次運(yùn)行都比后續(xù)運(yùn)行花費(fèi)更長的時(shí)間的原因。

在下面的圖表中，您可以看到第一次運(yùn)行的時(shí)間明顯長于其余六次測量的平均值。 我還嘗試過在單個(gè)內(nèi)核（julia）和4個(gè)處理器內(nèi)核（julia-4）上運(yùn)行Julia。

通過將環(huán)境變量JULIANUMTHREADS設(shè)置為要使用的內(nèi)核數(shù)，可以運(yùn)行具有更多內(nèi)核的julia。 從1.5開始，您可以通過julia -t n或julia --threads n啟動(dòng)julia，其中n是所需的內(nèi)核數(shù)。

使用更多核的處理通常會(huì)更快，并且julia對開箱即用的并行化有很好的支持。 您可能會(huì)擔(dān)心編譯速度，但是不需要，該代碼將被編譯一次，并且更改參數(shù)不會(huì)強(qiáng)制重新編譯。 例如在編譯CSV.read(joinpath(folder,file), DataFrame)之后，即使您更改了源文件的路徑，也將處理以下調(diào)用而不進(jìn)行編譯。 這就是為什么在load_identity步驟中看不到任何延遲的原因，因?yàn)镃SV讀取之前已經(jīng)進(jìn)行了編譯。

Modin

在結(jié)束有關(guān)Pandas替代品的討論之前，我必須提到Modin庫。 它的作者聲稱，modin利用并行性來加快80％的Pandas功能。 不幸的是，目前沒發(fā)現(xiàn)作者聲稱的速度提升。 并且有時(shí)在初始化Modin庫導(dǎo)入命令期間會(huì)中斷。 有一些情況，modin提示："not supported, defaulting to pandas"，然后該操作終崩潰了，只剩下4個(gè)python進(jìn)程，每個(gè)進(jìn)程都占用大量內(nèi)存。 使得我之后花了一些時(shí)間殺死這些進(jìn)程。

我喜歡modin背后的想法，我希望有一天能夠彌補(bǔ)這些差距，從而使modin提升為值得考慮的替代方案。

最后總結(jié)

我們已經(jīng)探索了幾種流行的Pandas替代品，以確定如果數(shù)據(jù)集足夠小，可以完全裝入內(nèi)存，那么使用其他數(shù)據(jù)是否有意義。

目前來看沒有一個(gè)并行計(jì)算平臺(tái)能在速度上超過Pandas。考慮到它們更復(fù)雜的語法、額外的安裝要求和缺乏一些數(shù)據(jù)處理能力，這些工具不能作為pandas的理想替代品。

Vaex顯示了在數(shù)據(jù)探索過程中加速某些任務(wù)的潛力。在更大的數(shù)據(jù)集中，這種好處會(huì)變得更明顯。

Julia的開發(fā)考慮到了數(shù)據(jù)科學(xué)家的需求。它可能沒有Pandas那么受歡迎，可能也沒有Pandas所能提供的所有技巧。對于某些操作，它可以提供性能提升，我必須說，有些代碼在julia中更優(yōu)雅。即使Julia沒有進(jìn)入前20名最流行的編程語言，我想它還是有前途的，如果你關(guān)注它的開發(fā)，你就不會(huì)犯錯(cuò)誤。

最后如果你想復(fù)現(xiàn)這些結(jié)果，請?jiān)诓榭催@個(gè)代碼：github/vaclavdekanovsky/data-analysis-in-examples/tree/master/DataFrames/Pandas_Alternatives

譯者注：雖然我一直覺得pandas有點(diǎn)慢，但是看了上面的評測，還是繼續(xù)用pandas吧。另外這里有個(gè)小技巧，pandas讀取csv很慢，例如我自己會(huì)經(jīng)常讀取5-10G左右的csv文件，這時(shí)在第一次讀取后使用topickle保存成pickle文件，在以后加載時(shí)用readpickle讀取pickle文件，不僅速度上會(huì)快10幾倍，文件的大小也會(huì)有2-5倍的減?。p小程度取決于你dataframe的內(nèi)容和數(shù)據(jù)類型）

最后總結(jié)還是那句話，當(dāng)數(shù)據(jù)能全部加載到內(nèi)存里面的時(shí)候，用Pandas就對了