Spark的实战题目——寻找5亿次访问中,访问次数最多的人
場(chǎng)景描述:這是一個(gè)Spark的實(shí)戰(zhàn)題目,也是在面試中經(jīng)常出現(xiàn)的一類題目。
問題描述
對(duì)于一個(gè)大型網(wǎng)站,用戶訪問量嘗嘗高達(dá)數(shù)十億。對(duì)于數(shù)十億是一個(gè)什么樣的概念,我們這里可以簡(jiǎn)單的計(jì)算一下。對(duì)于一個(gè)用戶,單次訪問,我們通常會(huì)記錄下哪些數(shù)據(jù)呢?
1、用戶的id
2、用戶訪問的時(shí)間
3、用戶逗留的時(shí)間
4、用戶執(zhí)行的操作
5、用戶的其余數(shù)據(jù)(比如IP等等)
我們單單從用戶id來說,比如10011802330414,這個(gè)ID,那么我們一個(gè)id差不多就是一個(gè)long類型,因?yàn)樵诖罅繑?shù)據(jù)存儲(chǔ)的時(shí)候,我們都是采用文本存儲(chǔ)。因此對(duì)于5億個(gè)用戶ID,完全存儲(chǔ)在磁盤當(dāng)中,大概是5G的大小,對(duì)于這個(gè)大小,并不能算是大數(shù)據(jù)。但是對(duì)于一個(gè)案例來說,已經(jīng)非常足夠了。
我們會(huì)產(chǎn)生一個(gè)5億條ID的數(shù)據(jù)集,我們上面說到,這個(gè)數(shù)據(jù)集大小為5G(不壓縮的情況下),因此我不會(huì)在GitHub上上傳這樣一個(gè)數(shù)據(jù)集,但是我們提供一個(gè)方法,來生成一個(gè)5億條數(shù)據(jù)。
當(dāng)然要解決這個(gè)問題,你可以依然在local模式下運(yùn)行項(xiàng)目,但是你得有足夠的磁盤空間和內(nèi)存空間,大概8G磁盤空間(因?yàn)槌藬?shù)據(jù)本身,spark運(yùn)行過程還要產(chǎn)生一些臨時(shí)數(shù)據(jù)),5G內(nèi)存(要進(jìn)行reduceByKey)。為了真正展示spark的特性,我們這個(gè)案例,將會(huì)運(yùn)行在spark集群上。
關(guān)于如何搭建集群,我準(zhǔn)備在后續(xù)的章節(jié)補(bǔ)上。但是在網(wǎng)上有大量的集群搭建教程,其中不乏一些詳細(xì)優(yōu)秀的教程。當(dāng)然,這節(jié)我們不講如何搭建集群,但是我們?nèi)匀豢梢蚤_始我們的案例。
問題分析
那么現(xiàn)在我們擁有了一個(gè)5億條數(shù)據(jù)(實(shí)際上這個(gè)數(shù)據(jù)并不以文本存儲(chǔ),而是在運(yùn)行的時(shí)候生成),從五億條數(shù)據(jù)中,找出訪問次數(shù)最多的人,這看起來并不難。但實(shí)際上我們想要通過這個(gè)案例了解spark的真正優(yōu)勢(shì)。
5億條ID數(shù)據(jù),首先可以用map將其緩存到RDD中,然后對(duì)RDD進(jìn)行reduceByKey,最后找出出現(xiàn)最多的ID。思路很簡(jiǎn)單,因此代碼量也不會(huì)很多。
實(shí)現(xiàn)
scala實(shí)現(xiàn)
首先是ID生成方法:
RandomId.class
然后是用它生成5億條數(shù)據(jù)
import org.apache.spark.{SparkConf, SparkContext}object ActiveVisitor {def main(args: Array[String]): Unit = {val conf = new SparkConf().setMaster("spark://master:7077").setAppName("ActiveVisitor")val sc = new SparkContext(conf)val list = 1 until 100000val id =new RandomId()var max = 0var maxId = 0Lval lastNum = sc.parallelize(list).flatMap(num => {var list2 = List(id.next())for (i <- 1 to 50000){list2 = id.next() :: list2}println(num +"%")list2}).map((_,1)).reduceByKey(_+_).foreach(x => {if (x._2 > max){max = x._2maxId = x._1println(x)}})} }處理5億條數(shù)據(jù)
import org.apache.spark.{SparkConf, SparkContext}object ActiveVisitor {def main(args: Array[String]): Unit = {val conf = new SparkConf().setMaster("spark://master:7077").setAppName("ActiveVisitor")val sc = new SparkContext(conf)//生成一個(gè)0-9999的列表val list = 1 until 10000val id =new RandomId()//這里記錄最大的次數(shù)var max = 0//這里記錄最大次數(shù)的IDvar maxId = 0Lval lastNum = sc.parallelize(list)//第一步生成5億條數(shù)據(jù).flatMap(num => {//遍歷list列表//總共遍歷1萬次每次生成5萬個(gè)IDvar list2 = List(id.next())for (i <- 1 to 50000){list2 = id.next() :: list2}//這里記錄當(dāng)前生成ID的百分比println(num/1000.0 +"%")//返回生成完成后的list//每次循環(huán)里面都包含5萬個(gè)IDlist2})//遍歷5億條數(shù)據(jù)//為每條數(shù)據(jù)出現(xiàn)標(biāo)記1.map((_,1))//對(duì)標(biāo)記后的數(shù)據(jù)進(jìn)行處理//得到每個(gè)ID出現(xiàn)的次數(shù),即(ID,Count).reduceByKey(_+_)//遍歷處理后的數(shù)據(jù).foreach(x => {//將最大值存儲(chǔ)在max中if (x._2 > max){max = x._2maxId = x._1//若X比之前記錄的值大,則輸出該id和次數(shù)//最后一次輸出結(jié)果,則是出現(xiàn)次數(shù)最多的的ID和以及其出現(xiàn)的次數(shù)//當(dāng)然出現(xiàn)次數(shù)最多的可能有多個(gè)ID//這里只輸出一個(gè)println(x)}})} }運(yùn)行得到結(jié)果
將其提交到spark上運(yùn)行,觀察日志
這里是輸出的部分日志,從日志中,我們顯然發(fā)現(xiàn),程序是并行的。我采用的集群由四個(gè)節(jié)點(diǎn)組成,每個(gè)節(jié)點(diǎn)提供5G的內(nèi)存空間,集群在不同節(jié)點(diǎn)中運(yùn)行,有節(jié)點(diǎn)分配到的分區(qū)是從1開始,而有節(jié)點(diǎn)則是從5000開始,因此程序并沒有按照我們所想的從1%-9999%。好在未按照順序執(zhí)行,也并不影響最終結(jié)果,畢竟最終要進(jìn)行一個(gè)reduceByKey,才是我們真正需要得到結(jié)果的地方。
再看日志另一部分:
注意到這里,spilling in-memory map of 1007.3 MB to disk,spilling操作將map中的 1007.3 MB的數(shù)據(jù)溢寫到磁盤中。這是由于spark在處理的過程中,由于數(shù)據(jù)量過于龐大,因此將多的數(shù)據(jù)溢寫到磁盤,當(dāng)再次用到時(shí),會(huì)從磁盤讀取。對(duì)于實(shí)時(shí)性操作的程序來說,多次、大量讀寫磁盤是絕對(duì)不被允許的。但是在處理大數(shù)據(jù)中,溢寫到磁盤是非常常見的操作。
事實(shí)上,在完整的日志中,我們可以看到有相當(dāng)一部分日志是在溢寫磁盤的時(shí)候生成的,大概49次(這是我操作過程中的總數(shù))
如圖:
總共出現(xiàn)49條溢寫操作的日志,每次大概是1G,這也印證了我們5億條數(shù)據(jù),占據(jù)空間5G的一個(gè)說法。事實(shí)上,我曾將這5億條數(shù)據(jù)存儲(chǔ)在磁盤中,的確其占據(jù)的空間是5G左右。
結(jié)果
最終,我們可以在日志中看到結(jié)果。
整個(gè)過程持續(xù)了將近47min,當(dāng)然在龐大的集群中,時(shí)間能夠大大縮短,要知道,我們現(xiàn)在只采用了4個(gè)節(jié)點(diǎn)。
我們看到了次數(shù)2、4、6、8居然分別出現(xiàn)了兩次,這并不奇怪,因?yàn)榧翰⑿羞\(yùn)行,異步操作,出現(xiàn)重復(fù)結(jié)果十分正常,當(dāng)然我們也可以用并發(fā)機(jī)制,去處理這個(gè)現(xiàn)象。這個(gè)在后續(xù)的案例中,我們會(huì)繼續(xù)優(yōu)化結(jié)果。
從結(jié)果上看,我們發(fā)現(xiàn)5億條數(shù)據(jù)中,出現(xiàn)最多的ID也僅僅出現(xiàn)了8次,這說明了在大量數(shù)據(jù)中,很多ID可能只出現(xiàn)了1次、2次。這也就是為什么最后我采用的是foreach方法去尋找最大值,而不采用如下的方法
import org.apache.spark.{SparkConf, SparkContext}object ActiveVisitor {def main(args: Array[String]): Unit = {val conf = new SparkConf().setMaster("spark://master:7077").setAppName("ActiveVisitor")val sc = new SparkContext(conf)//生成一個(gè)0-9999的列表val list = 1 until 10000val id =new RandomId()//這里記錄最大的次數(shù)var max = 0//這里記錄最大次數(shù)的IDvar maxId = 0Lval lastNum = sc.parallelize(list)//第一步生成5億條數(shù)據(jù).flatMap(num => {//遍歷list列表//總共遍歷1萬次每次生成5萬個(gè)IDvar list2 = List(id.next())for (i <- 1 to 50000){list2 = id.next() :: list2}//這里記錄當(dāng)前生成ID的百分比println(num/1000.0 +"%")//返回生成完成后的list//每次循環(huán)里面都包含5萬個(gè)IDlist2})//遍歷5億條數(shù)據(jù)//為每條數(shù)據(jù)出現(xiàn)標(biāo)記1.map((_,1))//對(duì)標(biāo)記后的數(shù)據(jù)進(jìn)行處理//得到每個(gè)ID出現(xiàn)的次數(shù),即(ID,Count).reduceByKey(_+_)//為數(shù)據(jù)進(jìn)行排序//倒序.sortByKey(false)//次數(shù)最多的,在第一個(gè),將其輸出println(lastNum.first())} }這個(gè)方法中,我們對(duì)reduceByKey結(jié)果進(jìn)行排序,輸出排序結(jié)果的第一個(gè),即次數(shù)最大的ID。這樣做似乎更符合我們的要求。但是實(shí)際上,為了得到同樣的結(jié)果,這樣做,會(huì)消耗更多的資源。如我們所說,很多ID啟其實(shí)只出現(xiàn)了一次,兩次,排序的過程中,仍然要對(duì)其進(jìn)行排序。要知道,由于很多ID只出現(xiàn)一次,排序的數(shù)據(jù)集大小很有可能是數(shù)億的條目。
根據(jù)我們對(duì)排序算法的了解,這樣一個(gè)龐大數(shù)據(jù)集進(jìn)行排序,勢(shì)必要耗費(fèi)大量資源。因此,我們能夠容忍輸出一些冗余信息,但不影響我們的得到正確結(jié)果。
至此,我們完成了5億數(shù)據(jù)中,找出最多出現(xiàn)次數(shù)的數(shù)據(jù)。如果感興趣,可以嘗試用這個(gè)方法解決50億條數(shù)據(jù),出現(xiàn)最多的數(shù)據(jù)條目。但是這樣做的話,你得準(zhǔn)備好50G的空間。盡管用上述的程序,屬于閱后即焚,但是50億數(shù)據(jù)仍然會(huì)耗費(fèi)大量的時(shí)間。
總結(jié)
以上是生活随笔為你收集整理的Spark的实战题目——寻找5亿次访问中,访问次数最多的人的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 你真的了解过Lucene吗?
- 下一篇: 列一下OOP规约,编程的时候共勉!别踏坑