1提高數(shù)據(jù)處理效率的迫切需要

本章包括

• 處理指數(shù)級增長的數(shù)據(jù)所面臨的挑戰(zhàn)
• 傳統(tǒng)計(jì)算架構(gòu)與最新計(jì)算架構(gòu)的比較
• Python在現(xiàn)代數(shù)據(jù)分析中的作用和不足
• 提供高效Python計(jì)算解決方案的技術(shù)

我們一直在以極快的速度從各種來源收集海量數(shù)據(jù)。無論目前是否有使用價值，這些數(shù)據(jù)都會被收集起來。無論是否有辦法對其進(jìn)行處理、存儲、訪問或?qū)W習(xí)，數(shù)據(jù)都會被收集起來。在數(shù)據(jù)科學(xué)家對其進(jìn)行分析之前，在設(shè)計(jì)師、開發(fā)人員和政策制定者利用其創(chuàng)造產(chǎn)品、服務(wù)和程序之前，軟件工程師必須找到存儲和處理這些數(shù)據(jù)的方法。現(xiàn)在，這些工程師比以往任何時候都更需要有效的方法來提高性能和優(yōu)化存儲。

在本書中，我將分享我在工作中使用的一系列性能和存儲優(yōu)化策略。簡單地增加機(jī)器數(shù)量往往既不可能，也無濟(jì)于事。因此，我在這里介紹的解決方案更多地依賴于理解和利用我們手頭的東西：編碼方法、硬件和系統(tǒng)架構(gòu)、可用軟件，當(dāng)然還有Python語言、庫和生態(tài)系統(tǒng)的細(xì)微差別。

Python已經(jīng)成為一種首選語言，可以完成或至少粘合所有與數(shù)據(jù)洪流有關(guān)的繁重工作，這也是老生常談的說法。事實(shí)上，Python在數(shù)據(jù)科學(xué)和數(shù)據(jù)工程領(lǐng)域的流行是該語言發(fā)展的主要推動力之一，根據(jù)大多數(shù)開發(fā)人員調(diào)查，Python已成為最流行的三大語言之一。在處理大數(shù)據(jù)方面，Python有其獨(dú)特的優(yōu)勢和局限性，速度不夠快肯定會帶來挑戰(zhàn)。好的一面是，正如您將看到的，有許多不同的角度、方法和變通辦法可以讓Python更高效地處理大量數(shù)據(jù)。

在找到解決方案之前，我們需要充分理解問題，而這正是我們在第一章中要做的事情。我們將花一些時間仔細(xì)研究大量數(shù)據(jù)帶來的計(jì)算挑戰(zhàn)，以確定我們所面對的問題到底是什么。接下來，我們將研究硬件、網(wǎng)絡(luò)和云架構(gòu)的作用，以了解為什么提高CPU速度等舊的解決方案不再適用。然后，我們將討論P(yáng)ython在處理大數(shù)據(jù)時面臨的特殊挑戰(zhàn)，包括Python的線程和CPython的全局解釋器鎖(GIL)。一旦我們充分理解了需要新的方法來使Python性能更佳，我將概述您將在本書中學(xué)到的解決方案。

1.1 數(shù)據(jù)洪水有多嚴(yán)重？

您可能知道摩爾定律和埃德霍姆定律這兩個計(jì)算定律，它們共同描繪了數(shù)據(jù)呈指數(shù)級增長，而計(jì)算系統(tǒng)處理這些數(shù)據(jù)的能力卻滯后的戲劇性畫面。埃德霍姆定律指出，電信領(lǐng)域的數(shù)據(jù)傳輸速率每18個月翻一番，而摩爾定律則預(yù)測，微芯片上可容納的晶體管數(shù)量每兩年翻一番。我們可以把埃德霍爾姆數(shù)據(jù)傳輸速率作為收集數(shù)據(jù)量的代表，把摩爾晶體管密度作為計(jì)算硬件速度和容量的指標(biāo)。當(dāng)我們把它們放在一起時，就會發(fā)現(xiàn)我們收集數(shù)據(jù)的速度和數(shù)量與我們處理和存儲數(shù)據(jù)的能力之間存在六個月的差距。由于指數(shù)式增長很難用語言來理解，因此我將這兩個定律對照繪制成一張圖，如圖1.1所示

摩爾定律和埃德霍爾姆定律之間的比率表明，硬件將始終落后于所產(chǎn)生的數(shù)據(jù)量。而且，隨著時間的推移，這種差距會越來越大。

這張圖描述的情況可以看作是我們需要分析的內(nèi)容（埃德霍姆定律）與我們進(jìn)行分析的能力（摩爾定律）之間的斗爭。實(shí)際上，這幅圖描繪的情況比我們的實(shí)際情況更為樂觀。我們將在第 6 章討論現(xiàn)代CPU架構(gòu)中的摩爾定律時了解其中的原因。這里我們重點(diǎn)討論數(shù)據(jù)增長，舉一個例子，互聯(lián)網(wǎng)流量是可用數(shù)據(jù)的間接衡量標(biāo)準(zhǔn)。如圖1.2所示，多年來互聯(lián)網(wǎng)流量的增長很好地遵循了埃德霍姆定律。

圖 1.2 多年來全球互聯(lián)網(wǎng)流量的增長（以每月 PB 為單位）。(資料來源：https://en.wikipedia.org/wiki/Internet_traffic）

此外，人類產(chǎn)生的 90% 的數(shù)據(jù)都發(fā)生在過去兩年（參見"大數(shù)據(jù)及其意義"，http://mng.bz/v1ya ）。至于這些新數(shù)據(jù)的質(zhì)量是否與其規(guī)模成正比，則完全是另一回事。問題是，產(chǎn)生的數(shù)據(jù)需要處理，而處理需要資源。

給軟件工程師帶來障礙的不僅僅是可用數(shù)據(jù)的數(shù)量。所有這些新數(shù)據(jù)的表現(xiàn)方式在本質(zhì)上也在發(fā)生變化。有人預(yù)測，到2025年，大約80%的數(shù)據(jù)可能是非結(jié)構(gòu)化數(shù)據(jù)（"挖掘非結(jié)構(gòu)化數(shù)據(jù)的力量"，http://mng.bz/BlP0 ）。我們將在本書稍后部分詳細(xì)介紹，但簡單地說，從計(jì)算角度來看，非結(jié)構(gòu)化數(shù)據(jù)對數(shù)據(jù)處理的要求更高。

我們?nèi)绾翁幚磉@些增長的數(shù)據(jù)？事實(shí)證明，我們大多沒有這樣做。據(jù)《衛(wèi)報》（http://mng.bz/Q8M4 ）報道，超過99%的數(shù)據(jù)從未被分析過。我們之所以無法利用如此多的數(shù)據(jù)，部分原因在于我們?nèi)狈Ψ治鲞@些數(shù)據(jù)的有效程序。

數(shù)據(jù)的增長以及隨之而來的對更多處理的需求，已發(fā)展成為有關(guān)計(jì)算的最惡毒的咒語之一： "如果你有更多的數(shù)據(jù)，只需投入更多的服務(wù)器"。出于多種原因，這往往不是一個可行或合適的解決方案。相反，當(dāng)我們需要提高現(xiàn)有系統(tǒng)的性能時，我們可以審視系統(tǒng)架構(gòu)和實(shí)施，找到可以優(yōu)化性能的地方。我已經(jīng)記不清有多少次在審查現(xiàn)有代碼時，只需注意效率問題，就能將性能提高十倍。

需要明白的是，需要分析的數(shù)據(jù)量的增加與分析數(shù)據(jù)所需的基礎(chǔ)設(shè)施的復(fù)雜性之間幾乎不是線性關(guān)系。解決這些問題需要開發(fā)人員花費(fèi)比機(jī)器更多的時間和智慧。這不僅適用于云環(huán)境，也適用于內(nèi)部集群，甚至適用于單機(jī)實(shí)施。一些使用案例將有助于說明這一點(diǎn)。例如

您的解決方案只需要一臺計(jì)算機(jī)，但突然您需要更多的機(jī)器。增加機(jī)器意味著你必須管理機(jī)器的數(shù)量，在它們之間分配工作負(fù)載，并確保數(shù)據(jù)被正確分區(qū)。您可能還需要一個文件系統(tǒng)服務(wù)器來增加機(jī)器數(shù)量。維護(hù)服務(wù)器群或云的成本要比維護(hù)單臺計(jì)算機(jī)的成本高得多。

您的解決方案在內(nèi)存中運(yùn)行良好，但隨著數(shù)據(jù)量的增加，已不再適合您的內(nèi)存。要處理存儲在磁盤中的新數(shù)據(jù)量，通常需要重新編寫代碼。當(dāng)然，代碼本身的復(fù)雜性也會增加。例如，如果主數(shù)據(jù)庫現(xiàn)在在磁盤上，您可能需要創(chuàng)建緩存策略。或者，您可能需要從多個進(jìn)程進(jìn)行并發(fā)讀取，或者更糟糕的是，并發(fā)寫入。

在使用SQL數(shù)據(jù)庫時，突然達(dá)到了服務(wù)器的最大吞吐能力。如果只是讀取能力問題，那么只需創(chuàng)建幾個讀取副本就能解決。但如果是寫入問題，該怎么辦呢？也許你會建立分片，或者決定徹底改變你的數(shù)據(jù)庫技術(shù)，轉(zhuǎn)而使用一些所謂性能更好的 NoSQL 變體？

如果您依賴的是基于供應(yīng)商專有技術(shù)的云系統(tǒng)，您可能會發(fā)現(xiàn)，無限擴(kuò)展的能力更多是營銷上的空談，而不是技術(shù)上的現(xiàn)實(shí)。在許多情況下，如果您遇到性能限制，唯一現(xiàn)實(shí)的解決方案就是改變您正在使用的技術(shù)，而這種改變需要大量的時間、金錢和人力。

我希望這些例子能夠說明，增長并不僅僅是"增加更多機(jī)器"的問題，而是需要在多個方面開展大量工作，以應(yīng)對日益增加的復(fù)雜性。即使是在單臺計(jì)算機(jī)上實(shí)施并行解決方案這樣"簡單"的事情，也會帶來并行處理的所有問題（競賽、死鎖等）。這些更高效的解決方案會對復(fù)雜性、可靠性和成本產(chǎn)生巨大影響。

最后，我們可以提出這樣的觀點(diǎn)：即使我們可以線性擴(kuò)展我們的基礎(chǔ)設(shè)施（我們確實(shí)做不到），也需要考慮倫理和生態(tài)問題：據(jù)預(yù)測，與"數(shù)據(jù)海嘯"相關(guān)的能源消耗占全球發(fā)電量的20%（"數(shù)據(jù)海嘯"，http://mng.bz/X5GE ），而且隨著硬件的更新，還存在垃圾填埋問題。

好消息是，在處理大數(shù)據(jù)時提高計(jì)算效率可以幫助我們減少計(jì)算費(fèi)用、解決方案架構(gòu)的復(fù)雜性、存儲需求、上市時間和能源消耗。有時，更高效的解決方案甚至可以將實(shí)施成本降到最低。例如，明智地使用數(shù)據(jù)結(jié)構(gòu)可以減少計(jì)算時間，而無需大量的開發(fā)成本。

另一方面，我們將研究的許多解決方案都需要開發(fā)成本，而且本身也會增加一定的復(fù)雜性。當(dāng)您查看您的數(shù)據(jù)并預(yù)測其增長時，您必須判斷在哪些方面進(jìn)行優(yōu)化，因?yàn)闆]有一目了然的方法或一刀切的解決方案。盡管如此，可能有一條規(guī)則可以適用于所有情況：如果解決方案對Netflix、谷歌、亞馬遜、蘋果或 Facebook 有利，那么它可能對你不利，當(dāng)然，除非你在這些公司中工作。

我們大多數(shù)人所看到的數(shù)據(jù)量將大大低于最大的技術(shù)公司所使用的數(shù)據(jù)量。數(shù)據(jù)量仍然會很大，數(shù)據(jù)仍然會很難獲取，但可能會低幾個數(shù)量級。在我看來，認(rèn)為適用于這些公司的技術(shù)也適用于我們其他人的觀點(diǎn)是錯誤的。一般來說，不太復(fù)雜的解決方案更適合我們大多數(shù)人。

正如你所看到的，在這個數(shù)據(jù)和算法的數(shù)量和復(fù)雜性都急劇增長的新世界里，需要更復(fù)雜的技術(shù)，以高效和節(jié)約成本的方式進(jìn)行計(jì)算和存儲。不要誤解我的意思：有時你需要擴(kuò)展你的基礎(chǔ)設(shè)施。但是，在設(shè)計(jì)和實(shí)施解決方案時，您仍然可以使用同樣的思維方式，注重效率。只是技術(shù)不同而已。

1.2 現(xiàn)代計(jì)算架構(gòu)和高性能計(jì)算

創(chuàng)建更高效的解決方案并非抽象空洞。首先，我們要考慮我們的領(lǐng)域問題，即您要解決的實(shí)際問題是什么。同樣重要的是運(yùn)行解決方案的計(jì)算架構(gòu)。計(jì)算架構(gòu)在決定最佳優(yōu)化技術(shù)方面發(fā)揮著重要作用，因此我們在設(shè)計(jì)軟件解決方案時必須將其考慮在內(nèi)。本節(jié)將介紹影響解決方案設(shè)計(jì)和實(shí)施的主要架構(gòu)問題。

1.2.1 計(jì)算機(jī)內(nèi)部的變化

計(jì)算機(jī)內(nèi)部正在發(fā)生翻天覆地的變化。首先CPU處理能力的提高主要體現(xiàn)在并行單元的數(shù)量上，而不是像過去那樣體現(xiàn)在原始速度上。計(jì)算機(jī)還可以配備圖形處理器（GPU），這種處理器最初只用于圖形處理，但現(xiàn)在也可用于通用計(jì)算。事實(shí)上，許多人工智能算法的高效實(shí)現(xiàn)都是通過GPU實(shí)現(xiàn)的。不幸的是，至少從我們的角度來看GPU的架構(gòu)與CPU完全不同：它們由數(shù)千個計(jì)算單元組成，所有單元都要進(jìn)行相同的"簡單"計(jì)算。內(nèi)存模型也完全不同。這些差異意味著，GPU的編程需要一種與 CPU 完全不同的方法。

要了解如何將GPU用于數(shù)據(jù)處理，我們需要先了解GPU的原始用途和架構(gòu)含義。顧名思義，GPU是為圖形處理而開發(fā)的。一些對計(jì)算要求最高的應(yīng)用實(shí)際上就是游戲。游戲和一般的圖形應(yīng)用都需要不斷更新屏幕上的數(shù)百萬像素。為解決這一問題而設(shè)計(jì)的硬件架構(gòu)有許多小型處理核心。GPU很容易擁有數(shù)千個內(nèi)核，而CPU通常只有不到10個。GPU內(nèi)核要簡單得多，而且每個內(nèi)核大多運(yùn)行相同的代碼。因此，它們非常適合運(yùn)行大量類似的任務(wù)，如更新像素。

鑒于GPU強(qiáng)大的處理能力，人們試圖將其用于其他任務(wù)，于是出現(xiàn)了圖形處理器通用計(jì)算（GPGPU）。由于GPU架構(gòu)的組織方式，它們大多適用于大規(guī)模并行性質(zhì)的任務(wù)。事實(shí)證明，許多現(xiàn)代人工智能算法，如基于神經(jīng)網(wǎng)絡(luò)的算法，往往是大規(guī)模并行的。因此，兩者之間存在著天然的契合點(diǎn)。

不幸的是，CPU和GPU 之間的區(qū)別不僅在于內(nèi)核數(shù)量和復(fù)雜性。GPU內(nèi)存，尤其是計(jì)算能力最強(qiáng)的 GPU，是與主內(nèi)存分離的。因此，主內(nèi)存和GPU內(nèi)存之間還存在數(shù)據(jù)傳輸問題。因此，我們在使用 GPU 時需要考慮兩個巨大的問題。

在第9章中我們會清楚地看到，使用Python對GPU進(jìn)行編程要比針對CPU的編程困難得多，也更不實(shí)用。盡管如此，Python仍然有足夠的空間來使用GPU。

與GPU的進(jìn)步相比，CPU的編程方式雖然沒有那么時髦，但也發(fā)生了巨大的變化。與GPU不同的是，我們可以在Python中輕松使用CPU的大部分變化。與過去相比，CPU性能的提升是由制造商以不同的方式實(shí)現(xiàn)的。在物理定律的驅(qū)動下，他們的解決方案是建立更多的并行處理，而不是更快的速度。摩爾定律有時被表述為速度每24個月翻一番，但實(shí)際上這并不是正確的定義：它是指晶體管密度每兩年翻一番。速度提升與晶體管密度之間的線性關(guān)系早在十多年前就已打破，此后速度基本趨于平穩(wěn)。鑒于數(shù)據(jù)隨著算法復(fù)雜度的增加而持續(xù)增長，我們正處于一種有害的境地。中央處理器制造商提出的第一類解決方案是允許更多并行性：每臺計(jì)算機(jī)擁有更多的中央處理器、每個中央處理器擁有更多的內(nèi)核，以及同時進(jìn)行多線程處理。處理器不再真正加速順序計(jì)算，而是允許更多并發(fā)執(zhí)行。這種并發(fā)執(zhí)行要求我們改變計(jì)算機(jī)編程的模式。以前，當(dāng)你更換CPU時，程序的速度會"神奇"地提高?，F(xiàn)在，速度的提高取決于程序員是否意識到底層架構(gòu)向并行編程范式的轉(zhuǎn)變。

現(xiàn)代CPU的編程方式發(fā)生了許多變化，正如你在第6章中看到的，其中一些變化非常反直覺，值得從一開始就加以關(guān)注。例如，雖然CPU的速度近年來有所下降，但CPU的速度仍然比RAM快幾個數(shù)量級。如果CPU緩存不存在，那么CPU大部分時間都會閑置，因?yàn)樗鼈兇蟛糠謺r間都在等待RAM。這意味著，有時處理壓縮數(shù)據(jù)（包括解壓縮的成本）比處理原始數(shù)據(jù)更快。為什么呢？如果可以將壓縮塊放在 CPU 緩存中，那么那些等待 RAM 訪問的空閑周期就可以用來解壓縮數(shù)據(jù)，而空余的 CPU周期則可以用于計(jì)算！類似的論點(diǎn)也適用于壓縮文件系統(tǒng)：它們有時比原始文件系統(tǒng)更快。這在Python世界中也有直接的應(yīng)用；例如，通過改變一個簡單的布爾標(biāo)志來選擇NumPy數(shù)組的內(nèi)部表示法，就可以利用緩存的局部性問題，大大加快NumPy處理速度。表1.1列出了不同類型內(nèi)存的訪問時間和大小，包括CPU緩存、RAM、本地磁盤和遠(yuǎn)程存儲。這里的關(guān)鍵不是精確數(shù)字，而是大小和訪問時間的數(shù)量級差異。

表 1.1 包括計(jì)算機(jī)外部的三級存儲。這里也發(fā)生了一些變化，我們將在下一節(jié)討論。

參考資料

• 軟件測試精品書籍文檔下載持續(xù)更新 https://github.com/china-testing/python-testing-examples 請點(diǎn)贊，謝謝！
• 本文涉及的python測試開發(fā)庫 謝謝點(diǎn)贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• Linux精品書籍下載 https://www.cnblogs.com/testing-/p/17438558.html

1.2.2 網(wǎng)絡(luò)中的變化

在高性能計(jì)算環(huán)境中，我們使用網(wǎng)絡(luò)來增加存儲，尤其是提高計(jì)算能力。雖然我們希望使用單臺計(jì)算機(jī)解決我們的問題，但有時依靠計(jì)算集群是不可避免的。優(yōu)化多臺計(jì)算機(jī)的架構(gòu)--無論是在云端還是在企業(yè)內(nèi)部--將是我們通往高性能之路的一部分。

使用多臺計(jì)算機(jī)和外部存儲會帶來與分布式計(jì)算相關(guān)的全新問題：網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)、跨機(jī)器共享數(shù)據(jù)以及管理跨網(wǎng)絡(luò)運(yùn)行的進(jìn)程。這樣的例子不勝枚舉。例如，在需要高性能和低延遲的服務(wù)上使用REST API的代價是什么？我們?nèi)绾翁幚磉h(yuǎn)程文件系統(tǒng)帶來的懲罰；我們能否減輕這些懲罰？

我們將努力優(yōu)化網(wǎng)絡(luò)堆棧的使用，為此，我們必須了解圖1.3所示的各個層面。在網(wǎng)絡(luò)之外，我們有自己的代碼和Python庫，它們會對下面的層進(jìn)行選擇。在網(wǎng)絡(luò)堆棧的頂層，數(shù)據(jù)傳輸?shù)牡湫瓦x擇是基于 JSON 有效載荷的 HTTPS。

雖然這對許多應(yīng)用程序來說是一個完全合理的選擇，但在網(wǎng)絡(luò)速度和滯后很重要的情況下，還有性能更高的替代方案。例如，二進(jìn)制有效載荷可能比JSON更有效。此外，HTTP可能會被直接的TCP套接字取代。但也有更激進(jìn)的替代方案，如替換TCP傳輸層：大多數(shù)互聯(lián)網(wǎng)應(yīng)用協(xié)議都使用TCP，但也有少數(shù)例外，如DNS和DHCP，它們都基于UDP。TCP協(xié)議具有很高的可靠性，但這種可靠性需要付出一定的性能代價。有時，UDP較小的開銷會是更有效的選擇，而額外的可靠性則沒有必要。

在傳輸協(xié)議之下，我們還有互聯(lián)網(wǎng)協(xié)議（IP）和物理基礎(chǔ)設(shè)施。在我們設(shè)計(jì)解決方案時，物理基礎(chǔ)設(shè)施可能非常重要。例如，如果我們有一個非?？煽康谋镜鼐W(wǎng)絡(luò)，那么可能丟失數(shù)據(jù)的UDP將比在不可靠的網(wǎng)絡(luò)中更有優(yōu)勢。

1.2.3 云

過去，大多數(shù)數(shù)據(jù)處理實(shí)施都是在單臺計(jì)算機(jī)或由運(yùn)行工作負(fù)載的同一機(jī)構(gòu)維護(hù)的內(nèi)部集群上進(jìn)行的。目前，所有服務(wù)器都是"虛擬"的、由外部實(shí)體維護(hù)的云基礎(chǔ)設(shè)施正變得越來越普遍。有時，就像所謂的無服務(wù)器計(jì)算一樣，我們甚至不直接與服務(wù)器打交道。

云不僅僅是增加更多的計(jì)算機(jī)或網(wǎng)絡(luò)存儲。它還涉及如何處理存儲和計(jì)算資源的一系列專有擴(kuò)展，而這些擴(kuò)展會對性能產(chǎn)生影響。此外，虛擬計(jì)算機(jī)還可能影響某些CPU優(yōu)化。例如，在裸機(jī)中，你可以設(shè)計(jì)一個考慮到緩存位置問題的解決方案，但在虛擬機(jī)中，你無法知道你的緩存是否被同時執(zhí)行的另一個虛擬機(jī)搶占。在這樣的環(huán)境中，我們該如何保持算法的效率呢？此外，云計(jì)算的成本模式完全不同，時間就是金錢，因此高效的解決方案變得更加重要。

云計(jì)算中的許多計(jì)算和存儲解決方案都是專有的，具有非常特殊的應(yīng)用程序接口和行為。使用這些專有解決方案也會對性能產(chǎn)生影響，這一點(diǎn)應(yīng)加以考慮。因此，雖然與傳統(tǒng)集群有關(guān)的大多數(shù)問題也適用于云，但有時會有一些特殊問題需要單獨(dú)處理。既然我們已經(jīng)了解了架構(gòu)的可能性和局限性，這些可能性和局限性將影響我們的應(yīng)用程序，下面我們就來談?wù)凱ython在高性能計(jì)算方面的優(yōu)缺點(diǎn)。

1.3 Python的局限性

Python廣泛應(yīng)用于現(xiàn)代數(shù)據(jù)處理應(yīng)用程序。與任何語言一樣，它既有優(yōu)點(diǎn)，也有缺點(diǎn)。使用Python有很多理由，但在這里我們更關(guān)注的是如何處理 Python 在高性能數(shù)據(jù)處理中的局限性。

讓我們不要粉飾現(xiàn)實(shí)：在處理高性能計(jì)算方面，Python的能力遠(yuǎn)遠(yuǎn)不夠。如果只考慮性能和并行性，就不會有人使用Python。Python擁有令人驚嘆的數(shù)據(jù)分析庫生態(tài)、優(yōu)秀的文檔和支持性極強(qiáng)的社區(qū)。這就是我們使用它的原因，而不是計(jì)算性能。

有一句話是這樣說的："沒有慢的語言，只有慢的語言實(shí)現(xiàn)"。我希望允許我提出不同意見。要求Python（或者JavaScript）這樣的動態(tài)高級語言的實(shí)現(xiàn)者在速度上與 C、C++、Rust或Go這樣的低級語言競爭是不公平的。

動態(tài)類型和垃圾回收等功能將在性能方面付出代價。這沒有問題：在很多情況下，程序員的時間比計(jì)算時間更寶貴。但我們也不要把頭埋在沙子里：更多的聲明性和動態(tài)語言將在計(jì)算和內(nèi)存方面付出代價。這是一種平衡。

盡管如此，這并不能成為性能不佳的語言實(shí)現(xiàn)的借口。在這方面，您可能正在使用的Python旗艦實(shí)現(xiàn)CPython的表現(xiàn)如何？要進(jìn)行全面分析并非易事，但您可以做一個簡單的練習(xí)：編寫一個矩陣乘法函數(shù)并計(jì)時。例如，用另一種Python實(shí)現(xiàn)（如PyPy）運(yùn)行它。然后將代碼轉(zhuǎn)換為 JavaScript（這是一種公平的比較，因?yàn)樵撜Z言也是動態(tài)語言；不公平的比較則是 C 語言）并再次計(jì)時。

1.3.1 全局解釋器鎖(Global Interpreter Lock)

CPython有GIL，它只允許一個線程在一個時間點(diǎn)上執(zhí)行。即使在多核處理器上，在一個時間點(diǎn)上也只能執(zhí)行一個線程。

Python的其他實(shí)現(xiàn)，如Jython和IronPython，沒有GIL，可以使用現(xiàn)代多核處理器的所有內(nèi)核。但CPython仍是所有主要庫開發(fā)的參考實(shí)現(xiàn)。此外，Jython和IronPython分別依賴于JVM和.NET。因此，CPython憑借其龐大的庫基礎(chǔ)，最終成為默認(rèn)的Python實(shí)現(xiàn)。我們將在書中簡要討論其他實(shí)現(xiàn)，其中最著名的是PyPy。

發(fā)是指一定數(shù)量的任務(wù)可以在時間上重疊，盡管它們可能不是同時運(yùn)行。例如，它們可以交錯運(yùn)行。并行是指任務(wù)同時執(zhí)行。因此，在 Python 中，并發(fā)是可能的，但并行是不可能的......。

沒有并行的并發(fā)仍然非常有用。這方面最好的例子來自JavaScript世界和Node.JS，Node.JS被廣泛用于實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)器的后臺。在許多服務(wù)器端網(wǎng)絡(luò)任務(wù)中，大部分時間實(shí)際上都在等待IO；這正是一個線程主動放棄控制權(quán)的大好時機(jī)，以便其他線程可以繼續(xù)計(jì)算?，F(xiàn)代Python 也有類似的異步設(shè)施，我們將討論它們。

但回到主要問題：GIL 會帶來嚴(yán)重的性能損失嗎？在大多數(shù)情況下，答案是令人驚訝的否定。這主要有兩個原因：

• 大多數(shù)高性能代碼，即那些緊湊的內(nèi)循環(huán)，很可能需要用我們討論過的低級語言來編寫。
• Python為低級語言提供了釋放 GIL的機(jī)制。

此外，多進(jìn)程（即同時運(yùn)行多個進(jìn)程）并不受GIL的影響。

1.4 解決方案總結(jié)

本書的主題是如何從Python中獲得高性能，只有從數(shù)據(jù)和算法需求以及計(jì)算架構(gòu)等更廣闊的角度來考慮，才能設(shè)計(jì)出高效的代碼。幫助你理解CPU設(shè)計(jì)、GPU、存儲替代方案、網(wǎng)絡(luò)協(xié)議和云架構(gòu)以及其他系統(tǒng)考慮因素（圖1.4）的影響，從而為提高Python代碼的性能做出正確的決策。無論是單臺計(jì)算機(jī)、支持GPU的計(jì)算機(jī)、集群還是云環(huán)境，本書都將幫助您評估計(jì)算架構(gòu)的優(yōu)缺點(diǎn)，并實(shí)施必要的更改以充分利用其優(yōu)勢。

本書的目標(biāo)是向您介紹一系列解決方案，并向您展示每種解決方案的最佳應(yīng)用方式和應(yīng)用場合，這樣您就可以針對特定的資源、目標(biāo)和問題選擇并實(shí)施最高效的解決方案。我們會花大量時間舉例說明，讓你親眼目睹這些方法的正反兩方面效果。我們并沒有規(guī)定必須采用所有方法，也沒有規(guī)定采用這些方法的順序。每種方法都會或多或少地提高性能和效率，同時也會有所取舍。如果你了解自己的系統(tǒng)以及改善系統(tǒng)各方面的可用策略，你就可以選擇在哪些方面花費(fèi)時間和資源。為了幫助您理解這些方法，表1.2概述了書中介紹的技術(shù)及其所針對的系統(tǒng)開發(fā)流程的組件或領(lǐng)域。

表中的內(nèi)容很多，所以讓我強(qiáng)調(diào)一下主要重點(diǎn)領(lǐng)域的實(shí)際應(yīng)用。讀完本書后，您將能夠查看本地Python代碼，并理解內(nèi)置數(shù)據(jù)結(jié)構(gòu)和算法對性能的影響。您將能夠發(fā)現(xiàn)并用更合適的解決方案替換低效的結(jié)構(gòu)：例如，在對恒定列表重復(fù)搜索時用集合替換列表，或者使用非對象數(shù)組代替對象列表以提高速度。您還可以使用性能不佳的現(xiàn)有算法，并（1）對代碼進(jìn)行剖析，找出導(dǎo)致性能問題的部分，（2）確定優(yōu)化這些代碼的最佳方法。

如前所述，本書針對廣泛使用的Python數(shù)據(jù)處理和分析庫（如pandas和NumPy），旨在改進(jìn)我們使用這些庫的方式。在計(jì)算方面，這是一個很大的材料，因此我們不會討論非常高級的庫。例如，我們不會討論如何優(yōu)化TensorFlow的使用，但會討論如何提高底層算法的效率。

關(guān)于數(shù)據(jù)存儲和轉(zhuǎn)換，您將能夠查看數(shù)據(jù)源并了解其在高效處理和存儲方面的缺點(diǎn)。然后，您將能夠?qū)?shù)據(jù)進(jìn)行轉(zhuǎn)換，使所有必要的信息仍然得到保留，但數(shù)據(jù)訪問模式將大大提高效率。最后，您還將了解到Dask，這是一個基于Python的框架，允許您開發(fā)并行解決方案，可以從單機(jī)擴(kuò)展到超大型計(jì)算機(jī)集群或云計(jì)算解決方案。文章來源地址http://www.zghlxwxcb.cn/news/detail-618542.html

到了這里，關(guān)于高效Python-1提高數(shù)據(jù)處理效率的迫切需要的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！