有輕功：用3行代碼讓Python數據處理腳本得到4倍提速

本文首發自集智專欄

---

Python是一門很是適合處理數據和自動化完成重複性工做的編程語言，咱們在用數據訓練機器學習模型以前，一般都須要對數據進行預處理，而Python就很是適合完成這項工做，好比須要從新調整幾十萬張圖像的尺寸，用Python沒問題！你幾乎老是能找到一款能夠輕鬆完成數據處理工做的Python庫。

然而，雖然Python易於學習，使用方便，但它並不是運行速度最快的語言。默認狀況下，Python程序使用一個CPU以單個進程運行。不過若是你是在最近幾年配置的電腦，一般都是四核處理器，也就是有4個CPU。這就意味着在你苦苦等待Python腳本完成數據處理工做時，你的電腦其實有75%甚至更多的計算資源就在那閒着沒事幹！

今天我（做者Adam Geitgey——譯者注）就教你們怎樣經過並行運行Python函數，充分利用你的電腦的所有處理能力。得益於Python的 concurrent.futures 模塊，咱們只需3行代碼，就能將一個普通數據處理腳本變爲能並行處理數據的腳本，提速4倍。

普通Python處理數據方法

比方說，咱們有一個全是圖像數據的文件夾，想用Python爲每張圖像建立縮略圖。

下面是一個短暫的腳本，用Python的內置glob函數獲取文件夾中全部JPEG圖像的列表，而後用Pillow圖像處理庫爲每張圖像保存大小爲128像素的縮略圖：

import glob
import os
from PIL import Image


def make_image_thumbnail(filename):
    # 縮略圖會被命名爲"<original_filename>_thumbnail.jpg"
    base_filename, file_extension = os.path.splitext(filename)
    thumbnail_filename = f"{base_filename}_thumbnail{file_extension}"

    # 建立和保存縮略圖
    image = Image.open(filename)
    image.thumbnail(size=(128, 128))
    image.save(thumbnail_filename, "JPEG")

    return thumbnail_filename


# 循環文件夾中全部JPEG圖像，爲每張圖像建立縮略圖
for image_file in glob.glob("*.jpg"):
    thumbnail_file = make_image_thumbnail(image_file)

print(f"A thumbnail for {image_file} was saved as {thumbnail_file}")
複製代碼

這段腳本沿用了一個簡單的模式，你會在數據處理腳本中常常見到這種方法：

• 首先得到你想處理的文件（或其它數據）的列表
• 寫一個輔助函數，可以處理上述文件的單個數據
• 使用for循環調用輔助函數，處理每個單個數據，一次一個。

我們用一個包含1000張JPEG圖像的文件夾測試一下這段腳本，看看運行完要花多長時間：

$ time python3 thumbnails_1.py
A thumbnail for 1430028941_4db9dedd10.jpg was saved as 1430028941_4db9dedd10_thumbnail.jpg
[... about 1000 more lines of output ...]
real 0m8.956s
user 0m7.086s
sys 0m0.743s
複製代碼

運行程序花了8.9秒，可是電腦的真實工做強度怎樣呢？

咱們再運行一遍程序，看看程序運行時的活動監視器狀況：

電腦有75%的處理資源處於閒置狀態！這是什麼狀況？

這個問題的緣由就是個人電腦有4個CPU，但Python只使用了一個。因此程序只是卯足了勁用其中一個CPU，另外3個卻無所事事。所以我須要一種方法能將工做量分紅4個我能並行處理的單獨部分。幸運的是，Python中有個方法很容易能讓咱們作到！

試試建立多進程

下面是一種可讓咱們並行處理數據的方法：

1.將JPEG文件劃分爲4小塊。

2.運行Python解釋器的4個單獨實例。

3.讓每一個Python實例處理這4塊數據中的一塊。

4.將這4部分的處理結果合併，得到結果的最終列表。

4個Python拷貝程序在4個單獨的CPU上運行，處理的工做量應該能比一個CPU大約高出4倍，對吧？

最妙的是，Python已經替咱們作完了最麻煩的那部分工做。咱們只需告訴它想運行哪一個函數以及使用多少實例就好了，剩下的工做它會完成。整個過程咱們只須要改動3行代碼。

首先，咱們須要導入concurrent.futures庫，這個庫就內置在Python中：

import concurrent.futures
複製代碼

接着，咱們須要告訴Python啓動4個額外的Python實例。咱們經過讓Python建立一個Process Pool來完成這一步：

with concurrent.futures.ProcessPoolExecutor() as executor:
複製代碼

默認狀況下，它會爲你電腦上的每一個CPU建立一個Python進程，因此若是你有4個CPU，就會啓動4個Python進程。

最後一步是讓建立的Process Pool用這4個進程在數據列表上執行咱們的輔助函數。完成這一步，咱們要將已有的for循環：

for image_file in glob.glob("*.jpg"):
thumbnail_file = make_image_thumbnail(image_file)
複製代碼

替換爲新的調用executor.map():

image_files = glob.glob("*.jpg")
for image_file, thumbnail_file in zip(image_files, executor.map(make_image_thumbnail, image_files)):
複製代碼

該executor.map()函數調用時須要輸入輔助函數和待處理的數據列表。這個函數能幫我完成全部麻煩的工做，包括將列表分爲多個子列表、將子列表發送到每一個子進程、運行子進程以及合併結果等。幹得漂亮！

這也能爲咱們返回每一個函數調用的結果。Executor.map()函數會按照和輸入數據相同的順序返回結果。因此我用了Python的zip()函數做爲捷徑，一步獲取原始文件名和每一步中的匹配結果。

這裏是通過這三步改動後的程序代碼：

import glob
import os
from PIL import Image
import concurrent.futures


def make_image_thumbnail(filename):
    # 縮略圖會被命名爲 "<original_filename>_thumbnail.jpg"
    base_filename, file_extension = os.path.splitext(filename)
    thumbnail_filename = f"{base_filename}_thumbnail{file_extension}"

    # 建立和保存縮略圖
    image = Image.open(filename)
    image.thumbnail(size=(128, 128))
    image.save(thumbnail_filename, "JPEG")

    return thumbnail_filename


# 建立Process Pool，默認爲電腦的每一個CPU建立一個
with concurrent.futures.ProcessPoolExecutor() as executor:
    # 獲取須要處理的文件列表
    image_files = glob.glob("*.jpg")

    # 處理文件列表，但經過Process Pool劃分工做，使用所有CPU！
    for image_file, thumbnail_file in zip(image_files, executor.map(make_image_thumbnail, image_files)):
        print(f"A thumbnail for {image_file} was saved as {thumbnail_file}")
複製代碼

咱們來運行一下這段腳本，看看它是否以更快的速度完成數據處理：

$ time python3 thumbnails_2.py
A thumbnail for 1430028941_4db9dedd10.jpg was saved as 1430028941_4db9dedd10_thumbnail.jpg
[... about 1000 more lines of output ...]
real 0m2.274s
user 0m8.959s
sys 0m0.951s
複製代碼

腳本在2.2秒就處理完了數據！比原來的版本提速4倍！之因此能更快的處理數據，是由於咱們使用了4個CPU而不是1個。

可是若是你仔細看看，會發現「用戶」時間幾乎爲9秒。那爲什麼程序處理時間爲2.2秒，但不知怎麼搞得運行時間仍是9秒？這彷佛不太可能啊？

這是由於「用戶」時間是全部CPU時間的總和，咱們最終完成工做的CPU時間總和同樣，都是9秒，但咱們使用4個CPU完成的，實際處理數據時間只有2.2秒！

注意：啓用更多Python進程以及給子進程分配數據都會佔用時間，所以靠這個方法並不能保證老是能大幅提升速度。若是你要處理很是大的數據集，這裏有篇設置將數據集切分紅多少小塊的文章，能夠讀讀，會對你幫助甚大.

這種方法總能幫個人數據處理腳本提速嗎？

若是你有一列數據，而且每一個數據都能單獨處理時，使用咱們這裏所說的Process Pools是一個提速的好方法。下面是一些適合使用並行處理的例子：

• 從一系列單獨的網頁服務器日誌裏抓取統計數據。
• 從一堆XML，CSV和JSON文件中解析數據。
• 對大量圖片數據作預處理，創建機器學習數據集。

但也要記住，Process Pools並非萬能的。使用Process Pool須要在獨立的Python處理進程之間來回傳遞數據。若是你要處理的數據不能在處理過程當中被有效地傳遞，這種方法就行不通了。簡而言之，你處理的數據必須是Python知道怎麼應對的類型。

同時，也沒法按照一個預想的順序處理數據。若是你須要前一步的處理結果來進行下一步，這種方法也行不通。

那GIL的問題呢？

你可能知道Python有個叫全局解釋器鎖（Global Interpreter Lock）的東西，即GIL。這意味着即便你的程序是多線程的，每一個線程也只能執行一個Python指令。GIL確保任什麼時候候都只有一個Python線程執行。換句話說，多線程的Python代碼並不能真正地並行運行，從而沒法充分利用多核CPU。

可是Process Pool能解決這個問題！由於咱們是運行單獨的Python實例，每一個實例都有本身的GIL。這樣咱們得到是真正能並行處理的Python代碼！

不要懼怕並行處理！

有了concurrent.futures庫，Python就能讓你簡簡單單地修改一下腳本後，馬上讓你電腦上全部CPU投入到工做中。不要懼怕嘗試這種方法，一旦你掌握了，它就跟一個for循環同樣簡單，卻能讓你的數據處理腳本快到飛起。

參考資料：medium.com

---

限時折扣中： 0806期《人工智能-從零開始到精通》

（還有少許200優惠券）