本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)。

我是一名Python工程師，所以你可以認(rèn)為我有偏見。在本文中，我想澄清一些關(guān)于Python的批評(píng)，并探討在使用Python進(jìn)行數(shù)據(jù)工程、數(shù)據(jù)科學(xué)和分析學(xué)的日常工作中，我們是否有必要擔(dān)憂速度。

[[376425]]

Python速度很慢嗎?

在我看來，這類問題應(yīng)該基于特定的情境和用例提出。與編譯語言(如C語言)相比，Python處理數(shù)字的速度慢嗎?是的，慢。這是眾所周知的事實(shí)，這就是為什么Python庫在后臺(tái)控制著C語言，而在諸如numpy的Python庫中，速度起著重要作用。

但是對(duì)于所有用例來說，Python是否比其他(更難學(xué)習(xí)和使用的)語言慢得多?你若查看為解決特定問題而優(yōu)化的許多Python庫的性能基準(zhǔn)，就會(huì)發(fā)現(xiàn)它們與編譯語言相比，表現(xiàn)相當(dāng)不錯(cuò)。

例如，看看FastAPI的性能基準(zhǔn)——顯然，Go作為一種編譯語言要比Python快得多。盡管如此，F(xiàn)astAPI在構(gòu)建REST API方面還是勝過了一些Go的庫：

我們應(yīng)該捫心自問的是，我真正需要的速度是多少。如果運(yùn)行每天只觸發(fā)一次的ETL作業(yè)，你可能并不關(guān)心它需要20秒還是200秒。你可能更傾向于使代碼易于理解、封裝和維護(hù)，特別是考慮到與昂貴的工程時(shí)間相比，計(jì)算資源正變得越來越便宜。

代碼速度與實(shí)用性

[[376426]]

圖源：unsplash

從實(shí)用的角度來看，在為日常工作選擇編程語言時(shí)，我們需要回答許多不同的問題。

(1) 你能用這種語言切實(shí)解決多個(gè)業(yè)務(wù)問題嗎?

假如你只關(guān)心速度，那就別用Python了。各種用例都有更快的替代方案。Python的主要優(yōu)點(diǎn)在于它的可讀性、易用性，以及能用它解決廣泛?jiǎn)栴}。Python可以用作橋梁，將無數(shù)不同的)系統(tǒng)、服務(wù)和用例連接在一起。

(2) 你能找到足夠多的懂這門語言的員工嗎?

Python非常容易學(xué)習(xí)和使用，所以其用戶數(shù)量在不斷增長(zhǎng)。以前用Excel處理數(shù)字的商業(yè)用戶，現(xiàn)在可以很快學(xué)會(huì)用Pandas編碼，從而自給自足，無需始終依賴IT資源。同時(shí)，這消除了IT和分析部門的負(fù)擔(dān)，也縮短了實(shí)現(xiàn)價(jià)值的時(shí)間。

近些年，比起那些能用Java或Scala做同樣事情的人，你更容易找到那些了解Python并能用這種語言維護(hù)Spark數(shù)據(jù)處理應(yīng)用程序的數(shù)據(jù)工程師。許多組織在很多用例中逐漸轉(zhuǎn)向使用Python，只是因?yàn)檎业?ldquo;會(huì)說”這種語言的員工的幾率更高。

我知道一些公司非常需要Java或C#開發(fā)人員來維護(hù)他們現(xiàn)有的應(yīng)用程序，但這些語言很難(需要很多年才能掌握)，而且對(duì)于新程序員來說似乎沒有吸引力，因?yàn)樗麄兛梢杂酶?jiǎn)單的語言(如Go或Python)來獲得更多收入。

(3) 不同領(lǐng)域?qū)＜抑g的協(xié)同效應(yīng)

假如你的公司使用Python，那么商業(yè)用戶、數(shù)據(jù)分析師、數(shù)據(jù)科學(xué)家、數(shù)據(jù)工程師、后端和web開發(fā)人員、DevOps工程師，甚至系統(tǒng)管理員很可能都使用同一種語言。這會(huì)引起項(xiàng)目中的協(xié)同效應(yīng)，來自不同領(lǐng)域的人可以一起工作。

數(shù)據(jù)處理中真正的瓶頸是什么?

在我的工作中，我通常遇到的瓶頸不是語言本身，而是外部資源，來看幾個(gè)例子。

(1) 寫入關(guān)系數(shù)據(jù)庫

在以ETL方式處理數(shù)據(jù)時(shí)，最終需要將此數(shù)據(jù)加載到某個(gè)集中位置。盡管可以利用Python中的多線程功能，將數(shù)據(jù)更快地寫入某些關(guān)系數(shù)據(jù)庫中(通過使用更多線程)，但并行寫入操作次數(shù)的增加可能會(huì)使數(shù)據(jù)庫的CPU容量使用最大化。

事實(shí)上，我在AWS上使用多線程加速RDS Aurora數(shù)據(jù)庫的寫入操作的時(shí)候，這種情況就發(fā)生過一次了。我注意到寫入節(jié)點(diǎn)的CPU利用率非常高，以至于我不得不通過使用更少的線程來刻意降低代碼的速度，以確保不會(huì)破壞數(shù)據(jù)庫實(shí)例。

這意味著Python具有并行化并加快許多操作的機(jī)制，但關(guān)系數(shù)據(jù)庫(受CPU核數(shù)量的限制)有其局限性，僅通過使用更快的編程語言不太可能解決這個(gè)問題。

(2) 調(diào)用外部的API

使用外部REST API，你可能是想從中提取數(shù)據(jù)來滿足數(shù)據(jù)分析需求，這同樣證明了語言本身似乎不是瓶頸。雖然我們可以通過利用并行性來加速數(shù)據(jù)提取，但這可能是徒勞的，因?yàn)橥獠緼PI限制了我們?cè)谔囟〞r(shí)間段內(nèi)可以發(fā)出的請(qǐng)求數(shù)量。因此，你可能會(huì)刻意讓腳本變慢，來確保不超出API的請(qǐng)求限制：

time.sleep(10) 

(3) 使用大數(shù)據(jù)

從我處理大量數(shù)據(jù)集的經(jīng)驗(yàn)來看，無論使用哪種語言，都無法將真正的“大數(shù)據(jù)”加載到筆記本電腦的內(nèi)存中。對(duì)于這樣的用例，你可能需要利用分布式處理框架，如Dask、Spark、Ray等。在使用單個(gè)服務(wù)器實(shí)例或筆記本電腦時(shí)，可以處理的數(shù)據(jù)量是有限制的。

如果你想把實(shí)際的數(shù)據(jù)處理工作轉(zhuǎn)移到一個(gè)計(jì)算節(jié)點(diǎn)集群中，可能使用GPU實(shí)例來進(jìn)一步加快計(jì)算速度，Python剛好有一個(gè)龐大的框架生態(tài)系統(tǒng)，可以簡(jiǎn)化這項(xiàng)任務(wù)：

• 你想通過利用GPU來加快數(shù)據(jù)科學(xué)的計(jì)算速度嗎?使用Pytorch、Tensorflow、Ray或Rapids吧。
• 你想加快處理大數(shù)據(jù)的Python代碼的速度嗎?使用Spark(或Databricks)、Dask或Prefect吧(可在后臺(tái)將Dask抽象化)。
• 你想加快用以分析的數(shù)據(jù)處理速度嗎?使用快速專用的內(nèi)存列數(shù)據(jù)庫，通過SQL查詢確保高速處理。

如果你需要協(xié)調(diào)和監(jiān)視在計(jì)算節(jié)點(diǎn)集群上發(fā)生的數(shù)據(jù)處理，有幾個(gè)用Python編寫的工作流管理平臺(tái)，可以加快數(shù)據(jù)管道的開發(fā)和維護(hù)，例如Apache Airflow、Prefect或Dagster。

有些抱怨Python的人，其實(shí)并沒有充分利用它，或者可能沒有使用適當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)來解決眼前的問題?？偠灾?，如果你需要快速處理大量數(shù)據(jù)，那你可能需要更多的計(jì)算資源，而不是更快的編程語言，而且有一些Python庫可以輕松地將工作分布到數(shù)百個(gè)節(jié)點(diǎn)上。

圖源：Google

雖然Python比許多編譯語言慢，但它好用且非常多樣化。對(duì)許多人來說，語言的實(shí)用性勝過速度方面的考量。語言本身可能不是瓶頸，至少在數(shù)據(jù)工程中是這樣，瓶頸是外部系統(tǒng)和龐大數(shù)據(jù)量的限制，無論選擇哪種編程語言都無法在單個(gè)計(jì)算機(jī)上進(jìn)行處理。