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

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

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

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

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

Pandas替代

讓我們首先探討反對替代Pandas的論點。

1. 他們不像Pandas那么普遍

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

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

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

· 高效內存利用— Vaex

· 不同的編程語言— Julia

數(shù)據(jù)集

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

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

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

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

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

1. Dask API不如Pandas的API豐富

1. 結果必須物化

Dask的語法與Pandas非常相似。

如您所見，兩個庫中的許多方法完全相同。但是dask基本上缺少排序選項。 那是因為并行排序很特殊。 Dask僅提供一種方法，即set_index。 按定義索引排序。

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

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

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

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

這就是為什么要準備計算步驟，然后讓集群計算，然后返回一個更小的集，只包含結果。這是目前分布式計算框架的一個通用的做法。

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

如何比較用于不同目的的兩個平臺的速度并非易事。 結果也可能因數(shù)據(jù)而有所偏差。 一種工具可以非常快速地合并字符串列，而另一種工具可以擅長整數(shù)合并。

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

· load_transactions —讀取〜700MB CSV文件

· load_identity —讀取〜30MB CSV文件

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

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

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

看起來Dask可以非?？焖俚丶虞dCSV文件，但是原因是Dask的延遲操作模式。 加載被推遲，直到我在聚合過程中實現(xiàn)結果為止。 這意味著Dask僅準備加載和合并，但具體加載的操作是與聚合一起執(zhí)行的。

Dask對排序幾乎沒有支持。 甚至官方的指導都說要運行并行計算，然后將計算出的結果（以及更小的結果）傳遞給Pandas。

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

PySpark

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

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

PySpark語法

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

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

如果只是為了測試，則不必安裝spark，因為PySpark軟件包隨附了spark實例（單機模式）。 但是要求必須在PC上安裝Java。

Spark性能

我使用了Dask部分中介紹的pySpark進行了相同的性能測試，結果相似。

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

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

Vaex

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

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

Vaex語法

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

Vaex性能

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

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

Julia

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

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

Julia語法

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

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

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

Julia性能

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

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

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

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

Modin

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

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

最后總結

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

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

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

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

最后如果你想復現(xiàn)這些結果，請在查看這個代碼：github/vaclavdekanovsky/data-analysis-in-examples/tree/master/DataFrames/Pandas_Alternatives

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

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