中文字幕在线观看,亚洲а∨天堂久久精品9966,亚洲成a人片在线观看你懂的,亚洲av成人片无码网站,亚洲国产精品无码久久久五月天

我們常常意識不到問題的存在,直到有人解決了這些問題

2019-02-27    來源:raincent

容器云強勢上線!快速搭建集群,上萬Linux鏡像隨意使用

Hadoop MapReduce 雖然已經(jīng)可以滿足大數(shù)據(jù)的應(yīng)用場景,但是其執(zhí)行速度和編程復(fù)雜度并不讓人們滿意。于是 UC Berkeley 的 AMP Lab 推出的 Spark 應(yīng)運而生,Spark 擁有更快的執(zhí)行速度和更友好的編程接口,在推出后短短兩年就迅速搶占 MapReduce 的市場份額,成為主流的大數(shù)據(jù)計算框架。

讀到這里請你先停一下,請給這段看似“沒毛病”的引子找找問題。

不知道你意識到?jīng)]有,我在這段開頭說的,“Hadoop MapReduce 雖然已經(jīng)可以滿足大數(shù)據(jù)的應(yīng)用場景,但是其執(zhí)行速度和編程復(fù)雜度并不讓人們滿意”,這句話其實是錯誤的。這樣說好像可以讓你更加清晰地看到事物發(fā)展的因果關(guān)系,同時也可以暗示別人自己有洞察事物發(fā)展規(guī)律的能力。然而,這種靠事后分析的因果規(guī)律常常是錯誤的,往往把結(jié)果當(dāng)作了原因。

事實上,在 Spark 出現(xiàn)之前,我們并沒有對 MapReduce 的執(zhí)行速度不滿,我們覺得大數(shù)據(jù)嘛、分布式計算嘛,這樣的速度也還可以啦。至于編程復(fù)雜度也是一樣,一方面 Hive、Mahout 這些工具將常用的 MapReduce 編程封裝起來了;另一方面,MapReduce 已經(jīng)將分布式編程極大地簡化了,當(dāng)時人們并沒有太多不滿。

真實的情況是,人們在 Spark 出現(xiàn)之后,才開始對 MapReduce 不滿。原來大數(shù)據(jù)計算速度可以快這么多,編程也可以更簡單。而且 Spark 支持 Yarn 和 HDFS,公司遷移到 Spark 上的成本很小,于是很快,越來越多的公司用 Spark 代替 MapReduce。也就是說,因為有了 Spark,才對 MapReduce 不滿;而不是對 MapReduce 不滿,所以誕生了 Spark。真實的因果關(guān)系是相反的。

這里有一條關(guān)于問題的定律分享給你:我們常常意識不到問題的存在,直到有人解決了這些問題。

當(dāng)你去詢問人們有什么問題需要解決,有什么需求需要被滿足的時候,他們往往自己也不知道自己想要什么,常常言不由衷。但是如果你真正解決了他們的問題,他們就會恍然大悟:啊,這才是我真正想要的,以前那些統(tǒng)統(tǒng)都是“垃圾”,我早就想要這樣的東西(功能)了。

所以頂尖的產(chǎn)品大師(問題解決專家),并不會拿著個小本本四處去做需求調(diào)研,問人們想要什么。而是在旁邊默默觀察人們是如何使用產(chǎn)品(解決問題)的,然后思考更好的產(chǎn)品體驗(解決問題的辦法)是什么。最后當(dāng)他拿出新的產(chǎn)品設(shè)計(解決方案)的時候,人們就會視他為知己:你最懂我的需求(我最懂你的設(shè)計)。

喬布斯是這樣的大師,Spark 的作者馬鐵也是這樣的專家。

說了那么多,我們回到 Spark。Spark 和 MapReduce 相比,有更快的執(zhí)行速度。下圖是 Spark 和 MapReduce 進行邏輯回歸機器學(xué)習(xí)的性能比較,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 語言沒關(guān)系,我來解釋一下上面的代碼。

第 1 行代碼:根據(jù) HDFS 路徑生成一個輸入數(shù)據(jù) RDD。

第 2 行代碼:在輸入數(shù)據(jù) RDD 上執(zhí)行 3 個操作,得到一個新的 RDD。

將輸入數(shù)據(jù)的每一行文本用空格拆分成單詞。

將每個單詞進行轉(zhuǎn)換,word => (word, 1),生成 的結(jié)構(gòu)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

 

標簽: 大數(shù)據(jù) 大數(shù)據(jù)的應(yīng)用 大數(shù)據(jù)分析 大數(shù)據(jù)應(yīng)用 大數(shù)據(jù)應(yīng)用場景 代碼 互聯(lián)網(wǎng) 開發(fā)者 數(shù)據(jù)分析

版權(quán)申明:本站文章部分自網(wǎng)絡(luò),如有侵權(quán),請聯(lián)系:west999com@outlook.com
特別注意:本站所有轉(zhuǎn)載文章言論不代表本站觀點!
本站所提供的圖片等素材,版權(quán)歸原作者所有,如需使用,請與原作者聯(lián)系。

上一篇:《流浪地球》票房:預(yù)測10億卻飚50億 ,大數(shù)據(jù)預(yù)測為什么這么難

下一篇:為什么我3歲的兒子有不良信用記錄?兒童數(shù)據(jù)泄露問題暗潮洶涌