為什麼建議盡量在spark
中少用groupbykey,讓我們看一下使用兩種不同的方式去計算單詞的個數,第一種方式使用reducebykey
;另外一種方式使用groupbykey
,**如下:
01
#
user
:
過往記憶
02
#
date
:
2015
-
05
-
18
03
#
time
:
下午
22
:
26
06
#
過往記憶部落格,專注於hadoop、hive、spark、shark、flume的技術部落格,大量的乾貨
07
#
_
hadoop
08
09
val
words
=
array(
"one"
,
"two"
,
"two"
,
"three"
,
"three"
,
"three"
)
10
val
wordpairsrdd
=
sc.parallelize(words).map(word
=
> (word,
1
))
11
12
val
wordcountswithreduce
=
wordpairsrdd
13
.reducebykey(
_
+
_
)
14
.collect()
15
16
val
wordcountswithgroup
=
wordpairsrdd
17
.groupbykey()
18
.map(t
=
> (t.
_
1
, t.
_
2
.sum))
19
.collect()
雖然兩個函式都能得出正確的結果, 但reducebykey
函式更適合使用在大資料集上。 這是因為spark
知道它可以在每個分割槽移動資料之前將輸出資料與乙個共用的 key 結合。
借助下圖可以理解在reducebykey
裡發生了什麼。 注意在資料對被搬移前同一機器上同樣的 key 是怎樣被組合的(reducebykey
中的 lamdba 函式)。然後 lamdba 函式在每個區上被再次呼叫來將所有值 reduce成乙個最終結果。整個過程如下:
另一方面,當呼叫groupbykey
時,所有的鍵值對(key-value pair) 都會被移動。在網路上傳輸這些資料非常沒有必要。避免使用groupbykey
。
為了確定將資料對移到哪個主機,spark會對資料對的 key 呼叫乙個分割槽演算法。 當移動的資料量大於單台執行機器記憶體總量時 spark 會把資料儲存到磁碟上。 不過在儲存時每次會處理乙個 key 的資料,所以當單個 key 的鍵值對超過記憶體容量會存在記憶體溢位的異常。 這將會在之後發行的 spark 版本中更加優雅地處理,這樣的工作還可以繼續完善。 儘管如此,仍應避免將資料儲存到磁碟上,這會嚴重影響效能。
你可以想象乙個非常大的資料集,在使用 reducebykey 和 groupbykey 時他們的差別會被放大更多倍。以下函式應該優先於 groupbykey :
(1)、combinebykey
組合資料,但是組合之後的資料型別與輸入時值的型別不一樣。
(2)、foldbykey
合併每乙個 key 的所有值,在級聯函式和「零值」中使用。
MySQL中盡量少使用外來鍵的原因
mysql設定外來鍵的好處 阻止執行 從表插入新行,其外鍵值不是主表的主鍵值便阻止插入 從表修改外鍵值,新值不是主表的主鍵值便阻止修改 主表刪除行,其主鍵值在從表裡存在便阻止刪除 要想刪除,必須先刪除從表的相關行 主表修改主鍵值,舊值在從表裡存在便阻止修改 要想修改,必須先刪除從表的相關行 級聯執行...
盡量在SQL中Group
對於彙總型別的分析報表,在報表生成時往往需要進行分組聚集運算,如果在資料庫中先進行一次分組聚集,能夠大大減少取到報表伺服器的記錄數,加快取數和報表運算的速度。看如下報表 這是乙個典型的交叉分組報表,其sql有兩種寫法 第一種 select 產品,客戶,銷量 from 購買記錄表 第二種 select...
kryo在spark中的使用 (scala)
package com.shufang.spark rdd import com.esotericsoftware.kryo.kryo import org.apache.spark.rdd.rdd import org.apache.spark.serializer.kryoregistrator...