我們並沒有覺得MapReduce速度慢,直到Spark出現
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 和 MapReduce 相比,有更快的執行速度。下圖是 Spark 和 MapReduce 進行邏輯迴歸機器學習的效能比較,Spark 比 MapReduce 快 100 多倍。
除了速度更快,Spark 和 MapReduce 相比,還有更簡單易用的程式設計模型。使用 Scala 語言在 Spark 上編寫 WordCount 程式,主要程式碼只需要三行。
val textFile = sc.textFile("hdfs://...")val counts = textFile.flatMap(line => line.split(" ")) .map(word => (word, 1)) .reduceByKey(_ + _)counts.saveAsTextFile("hdfs://...")
不熟悉 Scala 語言沒關係,我來解釋一下上面的程式碼。
第 1 行程式碼:根據 HDFS 路徑生成一個輸入資料 RDD。
第 2 行程式碼:在輸入資料 RDD 上執行 3 個操作,得到一個新的 RDD。
將輸入資料的每一行文字用空格拆分成單詞。
將每個單詞進行轉換,
word => (word, 1)
,生成 <Key, Value> 的結構。相同的 Key 進行統計,統計方式是對 Value 求和,
(_ + _)
。
第 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 行。
val rdd1 = textFile.flatMap(line => line.split(" "))val rdd2 = rdd1.map(word => (word, 1))val rdd3 = rdd2.reduceByKey(_ + _)
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,比如rdd2 = rdd1.map(func)
這樣的程式碼並不會在物理上生成一個新的 RDD。物理上,Spark 只有在產生新的 RDD 分片時候,才會真的生成一個 RDD,Spark 的這種特性也被稱作惰性計算。
另一種轉換操作產生的 RDD 則會產生新的分片,比如reduceByKey
,來自不同分片的相同 Key 必須聚合在一起進行操作,這樣就會產生新的 RDD 分片。實際執行過程中,是否會產生新的 RDD 分片,並不是根據轉換函式名就能判斷出來的,具體我們下一期再討論。
總之,你需要記住,Spark 應用程式程式碼中的 RDD 和 Spark 執行過程中生成的物理 RDD 不是一一對應的,RDD 在 Spark 裡面是一個非常靈活的概念,同時又非常重要,需要認真理解。
當然 Spark 也有自己的生態體系,以 Spark 為基礎,有支援 SQL 語句的 Spark SQL,有支援流計算的 Spark Streaming,有支援機器學習的 MLlib,還有支援圖計算的 GraphX。利用這些產品,Spark 技術棧支撐起大資料分析、大資料機器學習等各種大資料應用場景。
前面提到,頂尖的產品設計大師和問題解決專家,不會去詢問人們想要什麼,而是分析和觀察人們的做事方式,從而思考到更好的產品設計和問題解決方案。
但是這種技巧需要深邃的觀察力和洞察力,如果沒有深度的思考,做出的東西就會淪為異想天開和自以為是。要知道大眾提出的需求雖然也無法觸及問題的核心,但是好歹是有共識的,大家都能接受,按這種需求做出的東西雖然平庸,但是不至於令人厭惡。
而缺乏洞見的自以為是則會違反常識,讓其他人本能產生排斥感,進而產生對立情緒。這種情緒之下,設計沒有了進一步改進的基礎,最後往往成為悲劇。這兩年在所謂網際網路思維的鼓吹下,一些缺乏專業技能的人,天馬行空創造需求,受到質疑後公開批評使用者,也是讓人倍感驚詫。
我們在自己的工作中,作為一個不是頂尖大師的產品經理或工程師,如何做到既不自以為是,又能逐漸擺脫平庸,進而慢慢向大師的方向靠近呢?
有個技巧可以在工作中慢慢練習:不要直接提出你的問題和方案,不要直接說“你的需求是什麼?”“我這裡有個方案你看一下”。
直向曲中求,對於複雜的問題,越是直截了當越是得不到答案。迂迴曲折地提出問題,一起思考問題背後的規律,才能逐漸發現問題的本質。通過這種方式,既能達成共識,不會有違常識,又可能產生洞見,使產品和方案呈現閃光點。
大資料交流群:714526711,更多大資料資料諮詢私信群主,有更多大資料知識等你
【想知道更多大資料好文,關注作者】
相關文章
- Linux之父:我就是覺得蘋果太沒意思!Linux蘋果
- 我覺得eventbus最難實現
- Javascript之其實我覺得原型鏈沒有難的那麼誇張!JavaScript原型
- Nir Eyal:健身應用大部分都沒用 並且讓我們變得更胖
- 我們現在沒有討論的但有必要討論的模式模式
- 微信:我們沒有單獨出會員,只是和QQ SVIP繫結
- AbortSignal:以前我沒得選,現在我想中止promisePromise
- 抱歉,我覺得程式設計師副業賺錢並不靠譜程式設計師
- 覺得itpub的PK沒意思的來看看SAP總裁們的PK
- try/catch/finally:“前端的好厚米,我覺得你們不夠了解我呀~”前端
- 《仁王2》沒有簡單模式,但會讓玩家覺得更公平模式
- 5人開發獨立遊戲賣出680萬:我們想讓玩家覺得“發行商賣虧了”遊戲
- 談談Hadoop MapReduce和Spark MR實現HadoopSpark
- 你覺得大模型時代該出現什麼?大模型
- Windows 的這款工具,有時讓我覺得 Mac 不是很香WindowsMac
- Masonry實現原理並沒有那麼可怕
- 在大資料時代,我們真的沒有隱私嗎?大資料
- hive on spark執行速度慢HiveSpark
- 有沒有覺得前兩天的網慢了?“512k”事件惹的禍事件
- 如何實現報表視覺化,有沒有工具推薦視覺化
- 為什麼我們說區塊鏈沒有那麼容易?區塊鏈
- 請教資料庫高手(我們這沒有SQL版阿)資料庫SQL
- Spark與Hadoop MapReduce相比,有哪些優點你知道嗎?SparkHadoop
- 研究發現意識並沒有思想強大
- 剛實習使用Thinkphp如何和大佬交流讓他們覺得我不是菜雞?PHP
- 編譯器入門:沒有siri的那些年,我們如何實現人機對話?編譯
- 我只是來寫字的,並沒有什麼技術可言
- 有沒有一段程式碼,讓你覺得人類的智慧也可以璀璨無比?
- 最近幾個典型 Elasticsearch 線上易出錯難排查問題彙集,我們們得避免!Elasticsearch
- React Hooks 可以為我們帶來什麼,及為什麼我覺得React才是前端的未來ReactHook前端
- 我覺得你可能真的還不會JavaJava
- 分析:Google讓我們變得更愚蠢嗎Go
- 《絕地求生》開發商談Epic:我們之間沒有敵意
- Spark入門(二)--如何用Idea執行我們的Spark專案SparkIdea
- Mapper 介面並沒有實現類,它是如何工作的?APP
- 996我沒覺得有啥毛病啊996
- 你覺得我的這段Java程式碼還有優化的空間嗎?Java優化
- 我還沒搞懂 JS 中 this 指向及繼承,直到有人向我這樣解釋它JS繼承