既然Python的庫能對大數據進行分析，那為何還要用Hadoop和Spark?

再者，機器學習和spark,hadoop有關係嗎？

一般 Python 的庫不是為大數據設計的。pandas 誕生於 2009 年，它把 DataFrame 的概念帶到了 Python 語言。而要說 DataFrame 的歷史，甚至可以追溯到上個世紀90年代的 S 語言，R 語言作為 S 語言的開源版本，在 2000 年發布第一個穩定版本。這些 DataFrame 是同宗同源的。

他們的 DataFrame 數據模型相同，在行和列上存在著標籤，且數據保證順序。他們都要求數據能 fit 進內存，大部分操作也並沒有考慮到多核。這主要還是時代局限，在他們誕生的年代，大數據還不是主流。

關於 MapReduce 和 Hadoop 誕生的歷史就不多說了，網上一搜很多。MapReduce 就是簡單把數據處理抽象成 map 和 reduce 兩個運算元（函數式編程的概念），map 和 reduce 數據都需要落盤。MapReduce 的好處是特別簡單，反正就兩個運算元，基本上所有操作都能用這兩個運算元組合出來，而且因為數據落盤，任何計算失敗都可以 failover 出來，因此 Hadoop 特別穩定。缺點也很容易想到，就是更高階的運算元的表達得寫大量代碼。所以 Hadoop 誕生之後，工程師特別滿足，因為很多東西都要重新實現啊。Hadoop 是 Java 寫的，因此奠定了 Java 在大數據領域的黃金地位。

那時候反正大數據基本都是日誌，大家寫一堆 mapper 邏輯來抽取日誌信息，然後在 reducer 里聚合啊等等算一些統計數據。

很快人們就發現不對，這麼搞下去藥丸，每次一個任務就要寫一大堆代碼，亟需一個更高層的語言，不用每次寫這麼多重複代碼。有一個前提，這個高層語言，底層要能用 MapReduce 實現。大家都知道了，這個語言就是 SQL，SQL 的強大在於簡單，基本上沒學過編程的人也會使。SQL 是一種 declarative 的語言，也就是說，人們只要告訴它我要算某個欄位的 AVG，咋算的我不管，那就太適合架在 Hadoop 上面作為一種更高階的語言。大家的開發效率也提高了，因為不用再寫很多重複的 Java 代碼了。聲明式語言的好處是，可以優化啊，SQL 發展了幾十年的關係代數優化也可以逐步採用。

後來隨著時間發展，人們發現 Hadoop 也太慢了，什麼東西都要落盤這怎麼吃得消。因此，spark 誕生了，spark 也受了函數式編程的影響，把 Scala 語言上的介面全部帶到 Spark 里，什麼 map、flatmap 等等。然後把運算元歸為兩類，一種要 shuffle 的（就是我這個分區的數據依賴前面所有的數據），一種不需要 shuffle 的，不需要 shuffle 的數據就可以做更多管線優化，數據在內存里流動就行了。再者，除了 Scala 和 Java，Spark 還支持了 Python、R 來編程，一下讓其他編程語言的用戶有了幸福感。

然而好景不長，這種方式雖然各種語言都能寫了，然而不同語言性能不同，雖然都寫著類似的代碼，但性能天差地別。於是怎麼辦呢？SQL 啊，再把 SQL 架上去，這次不是架在 MapReduce 上，而是架在 RDD 編程介面上，這樣 spark 帶來的性能優勢都還在。Spark 的開發者們閱歷也特豐富，R 和 pandas 的 DataFrame 看上去不錯，畢竟不是每個人都想寫 SQL 的，於是又在和 SQL 同等級別上又搞出來了 DataFrame，以及後來的 Dataset 介面，寫 DataFrame 就不是 SQL Monkey 了。（沒有冒犯的意思：））

時過境遷，屬於大數據的時代很快就被人工智慧給取代了，人工智慧時代，演算法工程師們都是寫 Python 的，Python 語言特別適合用來作為深度學習框架的前端，因為他簡單、優雅，再加上人們對人工智慧的過度吹捧，很快 Python 一躍成為最受矚目的語言。畢竟這個時候不會 Python，意味著不懂人工智慧，和文盲沒區別啊（再次沒有冒犯的意思:)），看人家潘石屹都在學 Python。

但其實傳統的大數據離人工智慧的 gap 確實比較遠，演算法工程師一個 pip install tensorflow，網上翻個經典模型就開幹了，大數據的那套環境玩不轉。

於是，我們看深度學習的前序數據處理又回到了 pandas 這套，甚至用 Python 的循環。反正是相當原始。天道好輪迴啊。

這裡觀眾可能要問，不是有 spark DataFrame 么？甚至後來磚廠還搞了個號稱完全兼容 pandas 的 Koalas，它看上去不是和 pandas 挺像么。對，看上去確實像，但是底層仍然是 spark，所以其實內在有很多不同。如果拿 pandas 這套來寫，經常會如鯁在喉。最集中的兩點是，報錯經常來個 Java 異常棧，讓人不知所云；spark 本身數據並不保證順序，所以人們做分析的時候常常得到錯誤的結果。關於這點可以看我的文章：https://zhuanlan.zhihu.com/p/135329592。

所以，到這裡回到題目，pandas 這些庫不能處理超過內存大小的數據，這就是為什麼還需要 hadoop 和 spark 的原因，因為只有人家能幹大數據的活啊。

那麼，為什麼 Python 不能處理大數據呢？數據從 Python 流到深度學習一氣呵成，不是很好么？

這就是我們做 Mars 項目的原因（抱歉啊，廣告來的太突然），保證和 pandas 兼容，但能處理大規模的數據，能用 GPU 加速數據處理，還能和 tensorflow 等深度學習框架集成。關於這點，我覺得他和天下大事，分久必合，合久必分一個理，你看人家資料庫那邊，有了轟轟烈烈的 NoSQL（Not only SQL），現在也都改叫 NewSQL 了。我覺得 Mars 也可以說是 new pandas:) pandas 很好，我們沒有必要取代他，我們要做的只是讓他能處理更多數據、能並行和分散式起來。

所以啊，使用 Mars，你可能不需要 Hadoop 和 Spark。

Mars 文檔：https://docs.pymars.org/zh_CN/latest/

Mars 開源地址：https://github.com/mars-project/mars

因為python庫並不是為分散式設計的，實際業務中數據量並不是一部高性能計算機就能handle得來的。下面聽我細細道來。

打個比喻：

有個年輕人，他參加了藍翔烹飪學校的課程，立志成為一名廚師。

畢業後，他開了一家小餐館。在他看來，他每天的任務就是早上把食材準備好，放在廚房的一個冰箱里，他開工時，按照客戶的點單，從冰箱取出相應食材進行烹飪。

這種日子也挺愜意，廚師度過了開店前六個月安穩的小日子。

有一天，顧客A對他說：你的菜很棒，我想請你為我們工廠提供工作餐，你看可以嗎？

廚師立馬就答應下來了。但是他坐下來一想，可能要準備很多食材，現在的冰箱恐怕是放不下了。

有兩個選擇：1.買多幾個冰箱 2.換更大的冰箱。

廚師選擇了1。他認為，現在有顧客在這裡大量訂餐，以後也會有顧客大量訂餐，生意一定是蒸蒸日上的。如果現在買了大冰箱，可能過兩個月，又得買更大的。

買了冰箱，食材的放置就要有一定的規划了。這樣會使得工作效率最大化。例如肉類放冰箱A，蔬菜放冰箱B，這樣就不用為了準備一個菜，要去翻來覆去的把每個冰箱找一次。

當然有了冰箱，他一個人也不夠人手來準備這麼多菜。他請了幾個夥計，一個負責做水煮魚、一個負責做沙拉。

這個餐廳倍受好評。在當地三個鎮都有訂單。為了減少來回成本，這個廚師決定在三個鎮都開分店，按照統一的標準進行管理。當某地食材不足時，可以從其他地區補充。

就這樣，這個餐廳一直擴張，這位藍翔畢業的廚師，終於在2019年最後一個月，實現了小康生活。

把上面文章用大數據的語言翻譯下：

畢業後，他開了一家小餐館。（一個數據節點，一個處理單元）

這種日子也挺愜意，廚師度過了開店前六個月安穩的小日子。（業務不多，數據量不大，一台伺服器處理得來）

有兩個選擇：1.買多幾個冰箱（買多幾個伺服器） 2.換更大的冰箱（更高性能伺服器）。

廚師選擇了1。（幾個伺服器搭建分散式數據系統，擴展業務只需添加新伺服器）

他認為，現在有顧客在這裡大量訂餐，以後也會有顧客大量訂餐，生意一定是蒸蒸日上的。如果現在買了大冰箱，可能過兩個月，又得買更大的。（擴展數據系統只需要添加）

買了冰箱，食材的放置就要有一定的規划了。這樣會使得工作效率最大化。例如肉類放冰箱A，蔬菜放冰箱B，這樣就不用為了準備一個菜，要去翻來覆去的把每個冰箱找一次。（數據的indexing）

當然有了冰箱，他一個人也不夠人手來準備這麼多菜。他請了幾個夥計(worker node)，一個負責做水煮魚(task1)，紅燒牛肉（task2）、一個負責做沙拉(task3),意麵(task4)。

這個餐廳倍受好評。在當地三個鎮的工廠都來訂餐。為了減少來回成本，這個廚師決定在三個鎮都開分店，按照統一的標準進行管理(cluster manager)。當某地食材不足時，可以從其他地區補充(data shuffle)。

就這樣，這個餐廳一直擴張，這位藍翔畢業的廚師，成為了鎮上的小康之家(建立了穩定的大數據系統），在2019年最後一個月，完全脫貧。

為了再加深理解，我在Spark結構圖上面標註了餐廳的一些「術語」。

看完這個圖，你對我們藍翔的廚師專業，啊不，你對spark還有什麼想了解的嗎。

其他答案回答的非常全面了，我想談談為什麼會產生題主的這個問題，其實就是近幾年亂七八糟的概念亂炒作，「大數據」和「機器學習（人工智慧）」首當其衝。

先來談學術界，學術界很多傳統的實證研究和統計方法加上大數據的特點和技術（就是指hadoop生態代表的一系列技術）後說自己創新了方法，也有很多根本談不上是大數據，就是數據量變多了而已，這樣水的文章不在其數。

機器學習就更泛濫了，在各個領域遍地開花地寫文章......

大數據技術和機器學習有關係嗎？

我感覺在科研屆後者不在乎前者的關係，工業界是肯定要考慮的，因為要實實在在地落地。為什麼學術界不是很在乎數據這塊呢？（這也是為什麼機器學習的學者拿著pandas和for循環就開乾的原因），首先要明確大數據和大數據技術是兩個不同的概念，前者是理論性的，類似4v理論什麼的，後者很早就出現了，源頭在「分散式數據應用」、「數據密集型應用」的解決方案上，更早更早就是谷歌的三家數據方解決的三家馬車：GFS, MR，Bigtables （這些技術上的在科研界可能就只聽個名字，沒有真正會用的。）

所以科研界用大數據方法來搞實證的，我真的懷疑是否真的進行的整套的數據流處理，分散式部署和處理，因為數據處理的是否高效對你的論文結論來看沒有必然從影響（換言之用串列或傳統的方法處理你所謂的大數據是不是不影響結論？可能我的想法略天真，也希望有從事大數據作為研究方法的朋友批評指正）.....

上述原因導致hadoop生態這些東西對使用機器學習作為研究方法的科研人員來說根本用不到。畢竟對科研來講方法創新是主要的，你的實驗歷程和實現根本看不到，你數據分散式不分布或者大數據處理與否不重要（或者說沒必要，因為數據量不夠）. 因此python針對科研的模塊，numpy，pandas自然不考慮這些。

那麼完整的落地方案必要要考慮數據密集這一重要問題，系統的可用、可靠、可維護都需要hadoop生態為代表的大數據技術的基本支持，所以工業界和學術界思考問題的側重點是不一樣的。兩者合作才是硬道理。

那麼整個流程的統一，有些回答也提供了相關方案了，總而言之，技術選型是次要的，搞清楚各個環節的職責才是首要的學習任務。

問得好。事實上，我們不僅需要基於Hadoop、Spark的大數據平台，還需要更加強大的數據中台。

不管企業還是個人，做數據分析/挖掘的目的，不外乎發現問題，總結知識，降低成本，提高效率，只有Python庫本身，並不等於可以無視性能、規模之類的挑戰，並不等於高效了。

而數據中台，更是解決成本和效率問題的「大殺器」，網易數據中台負責人郭憶的精彩分享如下：

如果我們把數據中台看作是一個汽車工廠，那大數據平台就是工廠中的設備，Hadoop 集群則是工廠運作所必須的水、電、煤。Hadoop 提供的是大數據生產所必須的計算和存儲資源，大數據平台使得數據開發人員具備了對數據的加工和處理能力，類比設備使得工人具備了對原材料的加工能力，但是大數據平台還不能提供產品，這麼多的原始數據，要按照一定的方法論，進行良好的組織，加工，才能生成最終的指標，就如只有切割機、油漆機還不能生產汽車，各個零部件要按照一定的規則，通過設備組裝在一起，才是一輛完整的汽車。