建站
咨詢
售后
建站咨詢
新聞中心
每個數(shù)據(jù)科學(xué)項目遲早都會面臨一個不可避免的挑戰(zhàn)：速度問題。使用更大的數(shù)據(jù)集會導(dǎo)致處理速度變慢，因此最終必須想辦法優(yōu)化算法的運行時間。正如你們大多數(shù)人已經(jīng)知道的，并行化是這種優(yōu)化的必要步驟。python 為并行化提供了兩個內(nèi)置庫：多處理和線程。在這篇文章中，我們將探討數(shù)據(jù)科學(xué)家如何在兩者之間進行選擇，以及在這樣做時應(yīng)注意哪些因素。
創(chuàng)新互聯(lián)專注于掇刀網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供掇刀營銷型網(wǎng)站建設(shè)，掇刀網(wǎng)站制作、掇刀網(wǎng)頁設(shè)計、掇刀網(wǎng)站官網(wǎng)定制、微信小程序服務(wù)，打造掇刀網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供掇刀網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
并行計算與數(shù)據(jù)科學(xué)
眾所周知，數(shù)據(jù)科學(xué)是處理大量數(shù)據(jù)并從中提取有用見解的科學(xué)。通常情況下，我們對數(shù)據(jù)執(zhí)行的操作很容易并行化，這意味著不同的處理代理可以一次對數(shù)據(jù)執(zhí)行一個操作，最后進行組合以獲得完整的結(jié)果。
為了更好地解釋并行性，讓我們拿一個真實世界的例子作為類比。假設(shè)你需要打掃你家的三個房間。你可以自己打掃，打掃完一個再打掃另一個，也可以讓你的兩個兄弟姐妹幫你打掃，每個人打掃一個房間。在后一種方法中，每個人完成整個任務(wù)的一部分，從而減少了完成任務(wù)所需的總時間。這就是實際中的并行性。
并行處理可以用 python 以兩種不同的方式實現(xiàn)：多處理和線程。
多處理與線程：理論
基本上，多處理和線程是實現(xiàn)并行計算的兩種方法，分別使用進程和線程作為處理代理。為了理解它們的工作原理，我們必須搞清楚什么是進程和線程。
進程
進程是正在執(zhí)行的計算機程序的實例。每個進程都有自己的內(nèi)存空間，用來存儲正在運行的指令，以及需要存儲和訪問才能執(zhí)行的任何數(shù)據(jù)。
線程
線程是進程的組件，可以并行運行。一個進程中可以有多個線程，它們共享相同的內(nèi)存空間，即父進程的內(nèi)存空間。這意味著要執(zhí)行的代碼以及程序中聲明的所有變量將由所有線程共享。
例如，讓我們回想一下正在你的計算機上運行的程序。你可能正在瀏覽器中閱讀本文，瀏覽器可能打開了多個選項卡。你也可以同時通過 Spotify 桌面應(yīng)用程序收聽音樂。瀏覽器和 spotify 應(yīng)用程序是不同的進程;每個進程都可以使用多個進程或線程來實現(xiàn)并行性。瀏覽器中的不同選項卡可能在不同的線程中運行。Spotify 可以在一個線程中播放音樂，在另一個線程中從 Internet 下載音樂，并使用第三個線程顯示圖形用戶界面。這稱為多線程。對多個進程進行多處理也可以做到這一點。事實上，像 chrome 和 firefox 這樣的大多數(shù)現(xiàn)代瀏覽器使用多處理，而不是多線程來處理多個選項卡。
技術(shù)細節(jié)
一個進程的所有線程都存在于同一個內(nèi)存空間中，而進程有各自的內(nèi)存空間。
與進程相比，線程更輕量級，開銷更低。生成進程比生成線程慢一點。
在線程之間共享對象更容易，因為它們共享相同的內(nèi)存空間。為了實現(xiàn)同一個進程間通信，我們必須使用某種 IPC (inter-process communication) 模型，它通常由 OS 提供。
并行計算的陷阱
將并行性引入程序并不總是一個正和博弈，也有一些陷阱需要注意。其中，最重要的是下面的這些問題。
- 競爭條件：正如我們已經(jīng)討論過的，線程有一個共享內(nèi)存空間，因此它們可以訪問共享變量。當(dāng)多個線程試圖同時更改同一個變量時，會出現(xiàn)競爭條件。線程調(diào)度程序可以在線程之間任意交換，因此我們無法知道線程嘗試更改數(shù)據(jù)的順序。這可能會導(dǎo)致兩個線程中的任何一個出現(xiàn)不正確的行為，特別是當(dāng)線程決定基于變量的值執(zhí)行某些操作時。為了防止這種情況發(fā)生，可以在修改變量的代碼段周圍放置互斥鎖，以便一次只能有一個線程寫入變量。
- 饑餓：當(dāng)一個線程在較長時間內(nèi)被拒絕訪問某個特定的資源時，就會發(fā)生饑餓，在這種情況下，整個程序的速度會減慢。這可能是由于線程調(diào)度算法設(shè)計不當(dāng)而產(chǎn)生的意外副作用。
- 死鎖：過度使用互斥鎖也有一個缺點——它會在程序中引入死鎖。死鎖是一個線程等待另一個線程釋放鎖時的狀態(tài)，但另一個線程需要一個資源來完成第一個線程保持的操作。這樣，兩個線程都會停止，程序也會停止。死鎖可以被認為是饑餓的極端情況。為了避免這種情況，我們必須小心不要引入太多相互依賴的鎖。
- 活鎖：活鎖是指線程在循環(huán)中繼續(xù)運行，但沒有任何進展。這也是由于互斥鎖設(shè)計不當(dāng)和使用不當(dāng)造成的。
python 中的多處理和線程
全局解釋器鎖
說到 python，有一些奇怪的地方需要記住。我們知道線程共享相同的內(nèi)存空間，因此必須采取特殊的預(yù)防措施，以便兩個線程不會寫入相同的內(nèi)存位置。CPython 解釋器使用名為 GIL 的機制或全局解釋器鎖來處理這個問題。
python wiki 上面的資料：
- 在 CPython 中，全局解釋器鎖(GIL)是一個互斥鎖，它保護對 python 對象的訪問過程，防止多個線程同時執(zhí)行 python 字節(jié)碼。這個鎖是必要的，這主要是因為 CPython 的內(nèi)存管理不是線程安全的。
了解 python GIL 的詳細信息，請查看 。
GIL 完成了任務(wù)，但付出了代價。它在解釋器級別上有效地序列化指令。其工作原理如下：任何線程要執(zhí)行任何函數(shù)，都必須獲取全局鎖。一次只有一個線程可以獲取該鎖，這意味著解釋器最終會以串行方式運行指令。這種設(shè)計使得內(nèi)存管理線程安全，但結(jié)果是，它根本不能利用多個 cpu 內(nèi)核。在單核 cpu 中，這不是什么大問題。但是如果你使用多核 cpu，這個全局鎖最終會成為一個瓶頸。
但是，如果你的程序在其他地方(例如在網(wǎng)絡(luò)、IO 或用戶交互中)有更嚴重的瓶頸，則此瓶頸將變得無關(guān)緊要。在這些情況下，線程是一種完全有效的并行化方法。但對于 CPU 受限的程序，線程最終會使程序變慢。讓我們通過一些示例用例來探討這個問題。
線程的使用案例
GUI 程序始終使用線程來使應(yīng)用程序響應(yīng)。例如，在文本編輯程序中，一個線程負責(zé)記錄用戶輸入，另一個線程負責(zé)顯示文本，第三個線程負責(zé)拼寫檢查，等等。在這里，程序必須等待用戶交互，這是最大的瓶頸。使用多處理不會使程序更快。
線程的另一個用例是 io 綁定或網(wǎng)絡(luò)綁定的程序，例如 web-scrapers。在這種情況下，多個線程可以同時處理多個網(wǎng)頁的刮擦。線程必須從 Internet 下載網(wǎng)頁，這將是最大的瓶頸，因此線程是一個完美的解決方案。Web 服務(wù)器是受網(wǎng)絡(luò)約束的，工作原理與此類似;有了它們，多處理就沒有線程的優(yōu)勢了。另一個相關(guān)的例子是 tensorflow，它使用線程池并行地轉(zhuǎn)換數(shù)據(jù)。
多處理的使用案例
如果程序是 CPU 密集型的，并且不需要進行任何 IO 或用戶交互，那么多處理就比線程更加突出。例如，任何一個只處理數(shù)字的程序都可以使用多處理得到極大的加速;事實上，線程可能會減慢它的速度。一個有趣的實際例子是 Pytorch Dataloader，它使用多個子進程將數(shù)據(jù)加載到 GPU 中。
python 中的并行化
python 為同名的并行化方法提供了兩個庫——多處理和線程。盡管它們之間有著根本的區(qū)別，但這兩個庫提供了非常相似的 API(從 python 3.7 開始)。讓我們來具體看看吧。
- import threading
- import random
- from functools import reduce
- def func(number):
- random_list = random.sample(range(1000000), number)
- return reduce(lambda x, y: x*y, random_list)
- number = 50000
- thread1 = threading.Thread(target=func, args=(number,))
- thread2 = threading.Thread(target=func, args=(number,))
- thread1.start()
- thread2.start()
- thread1.join()
- thread2.join()
你可以看到，我創(chuàng)建了一個函數(shù) func，它創(chuàng)建一個隨機數(shù)列表，然后按順序?qū)⑵渌性叵喑?。如果物品?shù)量足夠大，比如說 5 萬或 10 萬件，這可能是一個相當(dāng)繁重的過程。
然后，我創(chuàng)建了兩個線程來執(zhí)行同一個函數(shù)。線程對象有一個異步啟動線程的 start 方法。如果我們想等待它們終止并返回，我們必須調(diào)用 join 方法，這就是我們在上面所做的。
如你所見，在后臺將新線程轉(zhuǎn)到任務(wù)的 API 非常簡單。最棒的是，用于多處理的 API 也幾乎完全相同;讓我們來檢查一下吧。
- import multiprocessing
- import randomfrom functools
- import reduce
- def func(number):
- random_list = random.sample(range(1000000), number)
- return reduce(lambda x, y: x*y, random_list)
- number = 50000
- process1 = multiprocessing.Process(target=func, args=(number,))
- process2 = multiprocessing.Process(target=func, args=(number,))
- process1.start()
- process2.start()
- process1.join()
- process2.join()
在這里它只是交換線程。有著多處理的線程。
顯然，你可以用它做很多事情，但這不在本文的范圍內(nèi)，所以我們不在這里討論。如果你有興趣了解更多信息，請查看這里和這里的文檔：https://docs.python.org/3/library/threading.html 和 https://docs.python.org/3/library/threading.html 。
基準點
現(xiàn)在我們已經(jīng)了解了實現(xiàn)并行化的代碼是什么樣子的，讓我們回到性能問題上來。如前所述，線程不適合用于 CPU 限制的任務(wù);在這些情況下，它最終成為一個瓶頸。我們可以使用一些簡單的基準來驗證這一點。
首先，讓我們看看在我上面展示的代碼示例中，線程處理與多處理是如何比較的。請記住，此任務(wù)不涉及任何類型的 IO，因此它是純 CPU 綁定的任務(wù)。
讓我們看看一個 IO 綁定任務(wù)的類似基準。例如，以下函數(shù)：
- import requestsdef func(number):
- url = 'http://example.com/'
- for i in range(number):
- response = requests.get(url)
- with open('example.com.txt', 'w') as output:
- output.write(response.text)
這個函數(shù)只是獲取一個網(wǎng)頁并將其保存到一個本地文件中，循環(huán)多次。無用但直截了當(dāng)，因此很適合演示。讓我們看看基準是什么吧。
現(xiàn)在，從這兩張圖表中可以注意到以下幾點：
- 在這兩種情況下，單個進程的執(zhí)行時間都比單個線程長。顯然，進程比線程有更多的開銷。
- 對于受 CPU 限制的任務(wù)，多個進程的性能比多個線程要好。然而，當(dāng)我們使用 8x 并行化時，這種差異就變得不那么明顯了。由于我的筆記本電腦中的處理器是四核的，因此最多有四個進程可以有效地使用多核。所以當(dāng)我使用更多的進程時，它的伸縮性就不好。但是，它仍然比線程性能好很多，因為線程根本不能利用多個核。
- 對于 IO 綁定的任務(wù)，瓶頸不是 CPU。因此，GIL 帶來的通常限制在這里不適用，多處理也沒有優(yōu)勢。不僅如此，線程的輕量級開銷實際上使它們比多處理更快，并且線程始終優(yōu)于多處理。
差異、優(yōu)缺點
- 線程在相同的內(nèi)存空間中運行;進程有單獨的內(nèi)存。
- 從前面的觀點來看：在線程之間共享對象更容易，但與此同時，你必須采取額外的措施來實現(xiàn)對象同步，以確保兩個線程不會同時寫入同一個對象，并且不會出現(xiàn)爭用情況。
- 由于對象同步增加了編程開銷，多線程編程更容易出現(xiàn)錯誤。另一方面，多進程編程很容易實現(xiàn)。
- 與進程相比，線程的開銷更低;生成進程比線程花費更多的時間。
- 由于 python 中 GIL 的局限性，線程不能利用多個 CPU 核實現(xiàn)真正的并行。多處理沒有任何這樣的限制。
- 進程調(diào)度由操作系統(tǒng)處理，而線程調(diào)度則由 python 解釋器完成。
- 子進程是可中斷和可終止的，而子線程不是。你必須等待線程終止或加入。
從所有這些討論中，我們可以得出以下結(jié)論：
- 線程應(yīng)該用于涉及 IO 或用戶交互的程序。
- 多處理應(yīng)該用于 CPU 受限、計算密集型的程序。
從數(shù)據(jù)科學(xué)家的角度
典型的數(shù)據(jù)處理管道可分為以下步驟：
- 讀取原始數(shù)據(jù)并存儲到主存儲器或 GPU 中;
- 使用 CPU 或 GPU 進行計算;
- 將挖掘出的信息存儲在數(shù)據(jù)庫或磁盤中。
讓我們來探索如何在這些任務(wù)中引入并行性，從而加快它們的速度。
步驟 1 包括了從磁盤讀取數(shù)據(jù)，因此很明顯磁盤 IO 將成為此步驟的瓶頸。正如我們所討論的，線程是并行這種操作的最佳選擇。同樣，步驟 3 也是引入線程的理想候選步驟。
但是，步驟 2 包含涉及 CPU 或 GPU 的計算。如果是基于 CPU 的任務(wù)，那么使用線程將毫無用處;相反，我們必須進行多處理。只有這樣，我們才能利用 CPU 的多個核并實現(xiàn)并行性。如果這是一個基于 GPU 的任務(wù)，因為 GPU 已經(jīng)在硬件級別實現(xiàn)了一個大規(guī)模并行化的體系結(jié)構(gòu)，那么使用正確的接口(庫和驅(qū)動程序)與 GPU 交互應(yīng)該可以處理剩下的事情。
現(xiàn)在你可能會想，「我的數(shù)據(jù)管道看起來與此有些不同;我有一些任務(wù)并不真正適合這個通用框架。」不過，在這里你應(yīng)該考慮的因素是：
- 你的任務(wù)是否有任何形式的 IO
- IO 是否是程序的瓶頸
- 你的任務(wù)是否取決于 CPU 的大量計算
考慮到這些因素，再加上上面的要點，你應(yīng)該能夠做出決定。另外，請記住，你不必在整個程序中使用單一形式的并行，而是應(yīng)該在程序的不同部分使用不同的并行。
現(xiàn)在我們來看看數(shù)據(jù)科學(xué)家可能面臨的兩個常見場景，以及如何使用并行計算來加速它們。
場景 1：下載電子郵件
假設(shè)你想分析自己創(chuàng)業(yè)公司收件箱中的所有電子郵件，并了解其趨勢：誰是最頻繁的發(fā)件人，電子郵件中出現(xiàn)的最常見關(guān)鍵字是什么，一周中的哪一天或一天中的哪一小時收到的電子郵件最多，等等。當(dāng)然，這個項目的第一步是將電子郵件下載到你的計算機上。
首先，讓我們按順序進行，而不使用任何并行化。下面是要使用的代碼，應(yīng)該非常簡單明了。有一個下載電子郵件的功能，它以電子郵件 ID 列表作為輸入，并按順序下載它們。這個函數(shù)一次調(diào)用 100 個電子郵件的 ID 列表。
- import imaplib
- import time
- IMAP_SERVER = 'imap.gmail.com'
- USERNAME = '[email protected]'
- PASSWORD = 'password'
- def download_emails(ids):
- client = imaplib.IMAP4_SSL(IMAP_SERVER)
- client.login(USERNAME, PASSWORD)
- client.select()
- for i in ids:
- print(f'Downloading mail id: {i.decode()}')
- _, data = client.fetch(i, '(RFC822)')
- with open(f'emails/{i.decode()}.eml', 'wb') as f:
- f.write(data[0][1])
- client.close()
- print(f'Downloaded {len(ids)} mails!')
- start = time.time()
- client = imaplib.IMAP4_SSL(IMAP_SERVER)
- client.login(USERNAME, PASSWORD)
- client.select()
- _, ids = client.search(None, 'ALL')
- ids = ids[0].split()
- ids = ids[:100]
- client.close()
- download_emails(ids)
- print('Time:', time.time() - start)
所用時間：35.65300488471985 秒。
現(xiàn)在讓我們在這個任務(wù)中引入一些并行性來加快速度。在開始編寫代碼之前，我們必須在線程和多處理之間做出決定。正如你目前所了解到的，當(dāng)任務(wù)的瓶頸是 IO 時，線程是最好的選擇。這里的任務(wù)顯然屬于這一類，因為它正在通過 Internet 訪問 IMAP 服務(wù)器。所以我們要開始使用線程了。
我們將要使用的大部分代碼將與我們在順序案例中使用的代碼相同。唯一不同的是，我們將把 100 個電子郵件 ID 的列表分成 10 個較小的塊，每個塊包含 10 個 ID，然后創(chuàng)建 10 個線程，并使用每個線程的不同塊調(diào)用 download_emails 函數(shù)。我正在使用 python 標準庫中的 concurrent.futures.threadpoolexecutor 類進行線程處理。
- import imaplib
- import time
- from concurrent.futures import ThreadPoolExecutor
- IMAP_SERVER = 'imap.gmail.com'
- USERNAME = '[email protected]'
- PASSWORD = 'password'
- def download_emails(ids):
- client = imaplib.IMAP4_SSL(IMAP_SERVER)
- client.login(USERNAME, PASSWORD)
- client.select()
- for i in ids:
- print(f'Downloading mail id: {i.decode()}')
- _, data = client.fetch(i, '(RFC822)')
- with open(f'emails/{i.decode()}.eml', 'wb') as f:
- f.write(data[0][1])
- client.close()
- start = time.time()
- client = imaplib.IMAP4_SSL(IMAP_SERVER)
- client.login(USERNAME, PASSWORD)
- client.select()
- _, ids = client.search(None, 'ALL')
- ids = ids[0].split()
- ids = ids[:100]
- client.close()
- number_of_chunks = 10
- chunk_size = 10
- executor = ThreadPoolExecutor(max_workers=number_of_chunks)
- futures = []
- for i in range(number_of_chunks):
- chunk = ids[i*chunk_size:(i+1)*chunk_size]
- futures.append(executor.submit(download_emails, chunk))
- for future in concurrent.futures.as_completed(futures):
- pass
- print('Time:', time.time() - start)
所用時間：9.841094255447388 秒。
如你所見，線程大大加快了它的速度。
場景 2：使用 scikit learn 進行分類
假設(shè)你有一個分類問題，你想使用一個隨機森林分類器。由于這是一種標準的、眾所周知的機器學(xué)習(xí)算法，我們不需要重新發(fā)明輪子，而只需使用 RandomForestClassifier 即可。
以下代碼用于演示。我使用助手函數(shù) sklearn.datasets.make_classification 創(chuàng)建了一個分類數(shù)據(jù)集，然后在此基礎(chǔ)上訓(xùn)練了一個 RandomForestClassifier。另外，我正在計時代碼中完成模型擬合核心工作的部分。
- from sklearn.ensemble import RandomForestClassifier
- from sklearn import datasets
- import time
- X, y = datasets.make_classification(n_samples=10000, n_features=50, n_informative=20, n_classes=10)
- start = time.time()
- model = RandomForestClassifier(n_estimators=500)
- model.fit(X, y)
- print('Time:', time.time()-start)
任務(wù)花費時間：34.17733192443848 秒。
現(xiàn)在我們將研究如何減少該算法的運行時間。我們知道這個算法可以在一定程度上并行化，但是什么樣的并行化才是合適的呢?它沒有任何 IO 瓶頸，相反，它是一個非常 CPU 密集型的任務(wù)。所以多處理是合乎邏輯的選擇。
幸運的是，sklearn 已經(jīng)在這個算法中實現(xiàn)了多處理，我們不必從頭開始編寫它。正如你在下面的代碼中看到的，我們只需要提供一個參數(shù) n_jobs(它應(yīng)該使用的進程數(shù))來啟用多處理。
- from sklearn.ensemble import RandomForestClassifier
- from sklearn import datasets
- import time
- X, y = datasets.make_classification(n_samples=10000, n_features=50, n_informative=20, n_classes=10)
- start = time.time()
- model = RandomForestClassifier(n_estimators=500, n_jobs=4)
- model.fit(X, y)
- print('Time:', time.time()-start)
所用時間：14.576200723648071 秒。
正如預(yù)期的那樣，多處理使其速度更快。
結(jié)論
大多數(shù)(如果不是所有的)數(shù)據(jù)科學(xué)項目將會發(fā)現(xiàn)并行計算能大幅提高計算速度。事實上，許多流行的數(shù)據(jù)科學(xué)庫已經(jīng)內(nèi)置了并行性，你只需啟用它即可。因此，在嘗試自己實現(xiàn)它之前，請查看正在使用的庫的文檔，并檢查它是否支持并行性。如果沒有，本文將幫助你自己實現(xiàn)它。
本文轉(zhuǎn)自雷鋒網(wǎng)，如需轉(zhuǎn)載請至雷鋒網(wǎng)官網(wǎng)申請授權(quán)。
網(wǎng)站題目：想提高計算速度？作為數(shù)據(jù)科學(xué)家你應(yīng)該知道這些Python多線程、進程知識
轉(zhuǎn)載源于：http://m.fisionsoft.com.cn/article/djgsdpc.html
