尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
Hadoop MapReduce 雖然已經可以滿足大數據的應用場景，但是其執行速度和編程複雜度並不讓人們滿意。於是 UC Berkeley 的 AMP Lab 推出的 Spark 應運而生，Spark 擁有更快的執行速度和更友好的編程接口，在推出後短短兩年就迅速搶占 MapReduce 的市場份額，成為主流的大數據計算框架。
讀到這里請你先停一下，請給這段看似「沒毛病」的引子找找問題。
不知道你意識到沒有，我在這段開頭說的，「Hadoop MapReduce 雖然已經可以滿足大數據的應用場景，但是其執行速度和編程複雜度並不讓人們滿意」，這句話其實是錯誤的。這樣說好像可以讓你更加清晰地看到事物發展的因果關係，同時也可以暗示別人自己有洞察事物發展規律的能力。然而，這種靠事後分析的因果規律常常是錯誤的，往往把結果當作了原因。
事實上，在 Spark 出現之前，我們並沒有對 MapReduce 的執行速度不滿，我們覺得大數據嘛、分布式計算嘛，這樣的速度也還可以啦。至於編程複雜度也是一樣，一方面 Hive、Mahout 這些工具將常用的 MapReduce 編程封裝起來了；另一方面，MapReduce 已經將分布式編程極大地簡化了，當時人們並沒有太多不滿。
真實的情況是，人們在 Spark 出現之後，才開始對 MapReduce 不滿。原來大數據計算速度可以快這麼多，編程也可以更簡單。而且 Spark 支持 Yarn 和 HDFS，公司遷移到 Spark 上的成本很小，於是很快，越來越多的公司用 Spark 代替 MapReduce。也就是說，因為有了 Spark，才對 MapReduce 不滿；而不是對 MapReduce 不滿，所以誕生了 Spark。真實的因果關係是相反的。
這里有一條關於問題的定律分享給你：我們常常意識不到問題的存在，直到有人解決了這些問題。
當你去詢問人們有什麼問題需要解決，有什麼需求需要被滿足的時候，他們往往自己也不知道自己想要什麼，常常言不由衷。但是如果你真正解決了他們的問題，他們就會恍然大悟：啊，這才是我真正想要的，以前那些統統都是「垃圾」，我早就想要這樣的東西（功能）了。
所以頂尖的產品大師（問題解決專家），並不會拿著個小本本四處去做需求調研，問人們想要什麼。而是在旁邊默默觀察人們是如何使用產品（解決問題）的，然後思考更好的產品體驗（解決問題的辦法）是什麼。最後當他拿出新的產品設計（解決方案）的時候，人們就會視他為知己：你最懂我的需求（我最懂你的設計）。
喬布斯是這樣的大師，Spark 的作者馬鐵也是這樣的專家。
說了那麼多，我們回到 Spark。Spark 和 MapReduce 相比，有更快的執行速度。下圖是 Spark 和 MapReduce 進行邏輯回歸機器學習的性能比較，Spark 比 MapReduce 快 100 多倍。
除了速度更快，Spark 和 MapReduce 相比，還有更簡單易用的編程模型。使用 Scala 語言在 Spark 上編寫 WordCount 程序，主要代碼只需要三行。
不熟悉 Scala 語言沒關係，我來解釋一下上面的代碼。
第 1 行代碼：根據 HDFS 路徑生成一個輸入數據 RDD。
第 2 行代碼：在輸入數據 RDD 上執行 3 個操作，得到一個新的 RDD。
第 3 行代碼：將這個 RDD 保存到 HDFS。
RDD 是 Spark 的核心概念，是彈性數據集（Resilient Distributed Datasets）的縮寫。RDD 既是 Spark 面向開發者的編程模型，又是 Spark 自身架構的核心元素。
我們先來看看作為 Spark 編程模型的 RDD。我們知道，大數據計算就是在大規模的數據集上進行一系列的數據計算處理。MapReduce 針對輸入數據，將計算過程分為兩個階段，一個 Map 階段，一個 Reduce 階段，可以理解成是面向過程的大數據計算。我們在用 MapReduce 編程的時候，思考的是，如何將計算邏輯用 Map 和 Reduce 兩個階段做到，map 和 reduce 函數的輸入和輸出是什麼，這也是我們在學習 MapReduce 編程的時候一再強調的。
而 Spark 則直接針對數據進行編程，將大規模數據集合抽象成一個 RDD 對象，然後在這個 RDD 上進行各種計算處理，得到一個新的 RDD，繼續計算處理，直到得到最後的結果數據。所以 Spark 可以理解成是面向對象的大數據計算。我們在進行 Spark 編程的時候，思考的是一個 RDD 對象需要經過什麼樣的操作，轉換成另一個 RDD 對象，思考的重心和落腳點都在 RDD 上。
所以在上面 WordCount 的代碼示例里，第 2 行代碼實際上進行了 3 次 RDD 轉換，每次轉換都得到一個新的 RDD，因為新的 RDD 可以繼續調用 RDD 的轉換函數，所以連續寫成一行代碼。事實上，可以分成 3 行。
RDD 上定義的函數分兩種，一種是轉換（transformation）函數，這種函數的返回值還是 RDD；另一種是執行（action）函數，這種函數不再返回 RDD。
RDD 定義了很多轉換操作函數，比如有計算map(func)、過濾filter(func)、合併數據集union(otherDataset)、根據 Key 聚合reduceByKey(func, [numPartitions])、連接數據集join(otherDataset, [numPartitions])、分組groupByKey([numPartitions]) 等十幾個函數。
我們再來看看作為 Spark 架構核心元素的 RDD。跟 MapReduce 一樣，Spark 也是對大數據進行分片計算，Spark 分布式計算的數據分片、任務調度都是以 RDD 為單位展開的，每個 RDD 分片都會分配到一個執行進程去處理。
RDD 上的轉換操作又分成兩種，一種轉換操作產生的 RDD 不會出現新的分片，比如 map、filter 等，也就是說一個 RDD 數據分片，經過 map 或者 filter 轉換操作後，結果還在當前分片。就像你用 map 函數對每個數據加 1，得到的還是這樣一組數據，只是值不同。實際上，Spark 並不是按照代碼寫的操作順序去生成 RDD，比如這樣的代碼並不會在物理上生成一個新的 RDD。物理上，Spark 只有在產生新的 RDD 分片時候，才會真的生成一個 RDD，Spark 的這種特性也被稱作惰性計算。
另一種轉換操作產生的 RDD 則會產生新的分片，比如，來自不同分片的相同 Key 必須聚合在一起進行操作，這樣就會產生新的 RDD 分片。實際執行過程中，是否會產生新的 RDD 分片，並不是根據轉換函數名就能判斷出來的，具體我們下一期再討論。
總之，你需要記住，Spark 應用程序代碼中的 RDD 和 Spark 執行過程中生成的物理 RDD 不是一一對應的，RDD 在 Spark 里面是一個非常靈活的概念，同時又非常重要，需要認真理解。
當然 Spark 也有自己的生態體系，以 Spark 為基礎，有支持 SQL 語句的 Spark SQL，有支持流計算的 Spark Streaming，有支持機器學習的 MLlib，還有支持圖計算的 GraphX。利用這些產品，Spark 技術棧支撐起大數據分析、大數據機器學習等各種大數據應用場景。
我前面提到，頂尖的產品設計大師和問題解決專家，不會去詢問人們想要什麼，而是分析和觀察人們的做事方式，從而思考到更好的產品設計和問題解決方案。
但是這種技巧需要深邃的觀察力和洞察力，如果沒有深度的思考，做出的東西就會淪為異想天開和自以為是。要知道大眾提出的需求雖然也無法觸及問題的核心，但是好歹是有共識的，大家都能接受，按這種需求做出的東西雖然平庸，但是不至於令人厭惡。
而缺乏洞見的自以為是則會違反常識，讓其他人本能產生排斥感，進而產生對立情緒。這種情緒之下，設計沒有了進一步改進的基礎，最後往往成為悲劇。這兩年在所謂互聯網思維的鼓吹下，一些缺乏專業技能的人，天馬行空創造需求，受到質疑後公開批評用戶，也是讓人倍感驚詫。
我們在自己的工作中，作為一個不是頂尖大師的產品經理或工程師，如何做到既不自以為是，又能逐漸擺脫平庸，進而慢慢向大師的方向靠近呢？
有個技巧可以在工作中慢慢練習：不要直接提出你的問題和方案，不要直接說「你的需求是什麼？」「我這里有個方案你看一下」。
直向曲中求，對於複雜的問題，越是直截了當越是得不到答案。迂回曲折地提出問題，一起思考問題背後的規律，才能逐漸發現問題的本質。通過這種方式，既能達成共識，不會有違常識，又可能產生洞見，使產品和方案呈現閃光點。
思考題
你在工作、生活中通過提問發現問題背後的本質、現象背後的規律的例子有哪些？或者你觀察到同事、朋友這樣的例子有哪些？
歡迎你寫下自己的思考或疑問，與我和其他同學一起討論。
—–點擊上方關注持續收聽面試乾貨
私信 「888」 索要大數據相關學習資料