相同的 Key 進行統(tǒng)計，統(tǒng)計方式是對 Value 求和，(_ + _)。

第 3 行代碼：將這個 RDD 保存到 HDFS。

RDD 是 Spark 的核心概念，是彈性數(shù)據(jù)集(Resilient Distributed Datasets)的縮寫。RDD 既是 Spark 面向開發(fā)者的編程模型，又是 Spark 自身架構的核心元素。

我們先來看看作為 Spark 編程模型的 RDD。我們知道，大數(shù)據(jù)計算就是在大規(guī)模的數(shù)據(jù)集上進行一系列的數(shù)據(jù)計算處理。MapReduce 針對輸入數(shù)據(jù)，將計算過程分為兩個階段，一個 Map 階段，一個 Reduce 階段，可以理解成是面向過程的大數(shù)據(jù)計算。我們在用 MapReduce 編程的時候，思考的是，如何將計算邏輯用 Map 和 Reduce 兩個階段實現(xiàn)，map 和 reduce 函數(shù)的輸入和輸出是什么，這也是我們在學習 MapReduce 編程的時候一再強調的。

而 Spark 則直接針對數(shù)據(jù)進行編程，將大規(guī)模數(shù)據(jù)集合抽象成一個 RDD 對象，然后在這個 RDD 上進行各種計算處理，得到一個新的 RDD，繼續(xù)計算處理，直到得到最后的結果數(shù)據(jù)。所以 Spark 可以理解成是面向對象的大數(shù)據(jù)計算。我們在進行 Spark 編程的時候，思考的是一個 RDD 對象需要經過什么樣的操作，轉換成另一個 RDD 對象，思考的重心和落腳點都在 RDD 上。

所以在上面 WordCount 的代碼示例里，第 2 行代碼實際上進行了 3 次 RDD 轉換，每次轉換都得到一個新的 RDD，因為新的 RDD 可以繼續(xù)調用 RDD 的轉換函數(shù)，所以連續(xù)寫成一行代碼。事實上，可以分成 3 行。

val rdd1 = textFile.flatMap(line => line.split(" "))
val rdd2 = rdd1.map(word => (word, 1))
val rdd3 = rdd2.reduceByKey(_ + _)

RDD 上定義的函數(shù)分兩種，一種是轉換(transformation)函數(shù)，這種函數(shù)的返回值還是 RDD;另一種是執(zhí)行(action)函數(shù)，這種函數(shù)不再返回 RDD。

RDD 定義了很多轉換操作函數(shù)，比如有計算map(func)、過濾filter(func)、合并數(shù)據(jù)集union(otherDataset)、根據(jù) Key 聚合reduceByKey(func, [numPartitions])、連接數(shù)據(jù)集join(otherDataset, [numPartitions])、分組groupByKey([numPartitions]) 等十幾個函數(shù)。

我們再來看看作為 Spark 架構核心元素的 RDD。跟 MapReduce 一樣，Spark 也是對大數(shù)據(jù)進行分片計算，Spark 分布式計算的數(shù)據(jù)分片、任務調度都是以 RDD 為單位展開的，每個 RDD 分片都會分配到一個執(zhí)行進程去處理。

RDD 上的轉換操作又分成兩種，一種轉換操作產生的 RDD 不會出現(xiàn)新的分片，比如 map、filter 等，也就是說一個 RDD 數(shù)據(jù)分片，經過 map 或者 filter 轉換操作后，結果還在當前分片。就像你用 map 函數(shù)對每個數(shù)據(jù)加 1，得到的還是這樣一組數(shù)據(jù)，只是值不同。實際上，Spark 并不是按照代碼寫的操作順序去生成 RDD，比如“rdd2 = rdd1.map(func)”這樣的代碼并不會在物理上生成一個新的 RDD。物理上，Spark 只有在產生新的 RDD 分片時候，才會真的生成一個 RDD，Spark 的這種特性也被稱作惰性計算。

另一種轉換操作產生的 RDD 則會產生新的分片，比如 reduceByKey，來自不同分片的相同 Key 必須聚合在一起進行操作，這樣就會產生新的 RDD 分片。實際執(zhí)行過程中，是否會產生新的 RDD 分片，并不是根據(jù)轉換函數(shù)名就能判斷出來的，具體我們下一期再討論。

總之，你需要記住，Spark 應用程序代碼中的 RDD 和 Spark 執(zhí)行過程中生成的物理 RDD 不是一一對應的，RDD 在 Spark 里面是一個非常靈活的概念，同時又非常重要，需要認真理解。

當然 Spark 也有自己的生態(tài)體系，以 Spark 為基礎，有支持 SQL 語句的 Spark SQL，有支持流計算的 Spark Streaming，有支持機器學習的 MLlib，還有支持圖計算的 GraphX。利用這些產品，Spark 技術棧支撐起大數(shù)據(jù)分析、大數(shù)據(jù)機器學習等各種大數(shù)據(jù)應用場景。

我前面提到，頂尖的產品設計大師和問題解決專家，不會去詢問人們想要什么，而是分析和觀察人們的做事方式，從而思考到更好的產品設計和問題解決方案。

但是這種技巧需要深邃的觀察力和洞察力，如果沒有深度的思考，做出的東西就會淪為異想天開和自以為是。要知道大眾提出的需求雖然也無法觸及問題的核心，但是好歹是有共識的，大家都能接受，按這種需求做出的東西雖然平庸，但是不至于令人厭惡。

而缺乏洞見的自以為是則會違反常識，讓其他人本能產生排斥感，進而產生對立情緒。這種情緒之下，設計沒有了進一步改進的基礎，最后往往成為悲劇。這兩年在所謂互聯(lián)網思維的鼓吹下，一些缺乏專業(yè)技能的人，天馬行空創(chuàng)造需求，受到質疑后公開批評用戶，也是讓人倍感驚詫。

我們在自己的工作中，作為一個不是頂尖大師的產品經理或工程師，如何做到既不自以為是，又能逐漸擺脫平庸，進而慢慢向大師的方向靠近呢?

有個技巧可以在工作中慢慢練習：不要直接提出你的問題和方案，不要直接說“你的需求是什么?”“我這里有個方案你看一下”。

直向曲中求，對于復雜的問題，越是直截了當越是得不到答案。迂回曲折地提出問題，一起思考問題背后的規(guī)律，才能逐漸發(fā)現(xiàn)問題的本質。通過這種方式，既能達成共識，不會有違常識，又可能產生洞見，使產品和方案呈現(xiàn)閃光點。

你覺得前一個版本最有意思(最有價值)的功能是什么?

你覺得我們這個版本應該優(yōu)先關注哪個方面?

你覺得為什么有些用戶在下單以后沒有支付?