意見，我厭倦了關於Python已死的文章

> Photo by Josh Hild from Pexels

全面披露-我目前是一名Python工程師，因此您可以認為我有偏見。但是我想揭露一些對Python的批評，並反思對於使用Python進行資料工程，資料科學和分析的日常工作，速度問題是否有效。

Python太慢了嗎？

我認為，此類問題應基於特定的上下文或用例提出。與C之類的編譯語言相比，Python的數字運算速度慢嗎？是的。這個事實已經存在多年了，這就是為什麼速度如此重要的Python庫（例如numpy）在後臺充分利用C的原因。

但是對於所有用例來說，Python是否比其他（難於學習和使用）語言慢很多？如果檢視許多為解決特定問題而最佳化的Python庫的效能基準，它們與編譯語言相比表現良好。例如，看一下FastAPI效能基準測試-顯然，Go作為一種編譯語言比Python快得多。儘管如此，FastAPI還是擊敗了Go的一些用於構建REST API的庫：

> Web Framework Benchmarks — image by the author

旁註：上面的列表不包括具有更高效能的C ++和Java Web框架。

類似地，當將Dask（用Python編寫）與Spark（用Scala編寫）比較用於資料密集型神經成像管道[2]時，作者得出以下結論：

總體而言，我們的結果表明，發動機之間的效能沒有實質性差異。

我們應該問自己的問題是我們真正需要多少速度。如果您執行每天僅觸發一次的ETL作業，則可能需要20秒鐘還是200秒鐘都不在乎。然後，您可能希望使程式碼易於理解，打包和維護，特別是考慮到與昂貴的工程時間相比，計算資源變得越來越負擔得起。

程式碼速度與實用性

從務實的角度來看，在選擇用於日常工作的程式語言時，我們需要回答許多不同的問題。

可以使用這種語言可靠地解決多個業務問題嗎？

如果您只關心速度，那就不要使用Python。對於各種用例，都有更快的替代方法。Python的主要優點在於其可讀性，易用性以及可以解決的許多問題。Python可以用作將無數不同的系統，服務和用例聯絡在一起的膠水。

能找到足夠的懂這種語言的員工嗎？

由於Python非常易於學習和使用，因此Python使用者數量不斷增長。以前曾在Excel中處理數字的業務使用者現在可以快速學習在Pandas中進行編碼，從而學會自給自足，而無需始終依賴IT資源。同時，這消除了IT和分析部門的負擔。它還可以縮短實現價值的時間。

如今，與那些能夠使用Java或Scala做到這一點的資料工程師相比，更加容易瞭解Python並且可以使用該語言維護Spark資料處理應用程式的人更加容易。許多組織只是因為找到"講"該語言的員工的機會較高，而逐漸在許多用例上轉向使用Python。

相比之下，我知道迫切需要Java或C＃開發人員來維護其現有應用程式的公司，但是這些語言很困難（需要花費數年時間才能熟練使用），並且對於新程式設計師來說似乎沒有吸引力，他們可能會在利用更簡單的語言（例如，Go或Python。

來自不同領域的專家之間的協同作用

如果您的公司使用Python，則業務使用者，資料分析師，資料科學家，資料工程師，資料工程師，後端和Web開發人員，DevOps工程師甚至系統管理員都很有可能使用相同的語言。這可以在專案中產生協同作用，使來自不同領域的人們可以一起工作並利用相同的工具。

> Photo by Startup Stock Photos from Pexels

資料處理的真正瓶頸是什麼？

根據我自己的工作，我通常遇到的瓶頸不是語言本身，而是外部資源。更具體地說，讓我們看幾個例子。

寫入關係資料庫

在以ETL方式處理資料時，我們需要最終將此資料載入到某個集中位置。儘管我們可以利用Python中的多執行緒功能（透過使用更多執行緒）將資料更快地寫入某些關係資料庫中，但並行寫入次數的增加可能會最大化該資料庫的CPU容量。

實際上，當我使用多執行緒來加快對AWS上RDS Aurora資料庫的寫入速度時，這發生在我身上。然後，我注意到writer節點的CPU使用率上升到如此之高，以至於我不得不使用更少的執行緒來故意降低程式碼速度，以確保不會破壞資料庫例項。

這意味著Python具有並行化和加速許多操作的機制，但是關係資料庫（受CPU核心數量的限制）具有其侷限性，僅透過使用更快的程式語言就不可能解決它。

呼叫外部API

使用外部REST API（您可能希望從中提取資料以滿足資料分析需求）是另一個例子，其中語言本身似乎並不是瓶頸。儘管我們可以利用並行性來加快資料提取的速度，但這可能是徒勞的，因為許多外部API限制了我們可以在特定時間段內發出的請求數量。因此，您可能經常會發現自己故意降低了指令碼執行速度，以確保不超出API的請求限制：

time.sleep(10)

處理大資料

根據我處理海量資料集的經驗，無論使用哪種語言，都無法將真正的"大資料"載入到膝上型電腦的記憶體中。對於此類用例，您可能需要利用Dask，Spark，Ray等分散式處理框架。使用單個伺服器例項或行動式計算機時，可以處理的資料量受到限制。

如果您想將實際的資料處理工作轉移到一組計算節點上，甚至可能利用GPU例項來進一步加快計算速度，那麼Python恰好具有一個龐大的框架生態系統，可簡化此任務：

· 您是否想利用GPU加快資料科學的計算速度？使用Pytorch，Tensorflow，Ray或Rapids（即使使用SQL — BlazingSQL）

· 您是否想加快處理大資料的Python程式碼的速度？使用Spark（或Databricks），Dask或Prefect（可在後臺將Dask抽象化）

· 您是否想加快資料處理以進行分析？使用快速專用的記憶體中柱狀資料庫，僅透過使用SQL查詢即可確保高速處理。

而且，如果您需要協調和監視在計算節點叢集上發生的資料處理，則有幾種用Python編寫的工作流管理平臺，這些平臺可以加快開發並改善資料管道的維護，例如Apache Airflow，Prefect或Dagster。如果您想進一步瞭解這些內容，請檢視我以前的文章。

順便提一句，我可以想象有些抱怨Python的人沒有充分利用它的能力，或者可能沒有為眼前的問題使用適當的資料結構。

總而言之，如果您需要快速處理大量資料，則可能需要更多的計算資源而不是更快的程式語言，並且Python庫使您可以輕鬆地在數百個節點之間分配工作。

參考文獻：

[1] TechEmpower：Web框架基準。資源

[2]" Dask和Apache Spark在資料密集型神經成像管道上的效能比較" – MathieuDugré，ValérieHayot-Sasson，Tristan Glatard。連結到arxiv