為什麼建議盡量在spark
中少用groupbykey，讓我們看一下使用兩種不同的方式去計算單詞的個數，第一種方式使用reducebykey；另外一種方式使用groupbykey，**如下：
01#user:過往記憶
02#date:2015-05-18
03#time:下午22:26
06#過往記憶部落格，專注於hadoop、hive、spark、shark、flume的技術部落格，大量的乾貨
07#_hadoop
08
09valwords=array("one","two","two","three","three","three")
10valwordpairsrdd=sc.parallelize(words).map(word=> (word,1))
11
12valwordcountswithreduce=wordpairsrdd
13.reducebykey(_+_)
14.collect()
15
16valwordcountswithgroup=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...