大數(shù)據(jù)（big data），一般來說是指無法在可承受的時(shí)間范圍內(nèi)用常規(guī)軟件工具進(jìn)行捕捉、管理和處理的數(shù)據(jù)集合。本文匯總了大數(shù)據(jù)面試中常見的問題及解答方案，供大家參考：
1、Spark能否取代Hadoop？
答： Hadoop包含了Common,HDFS,YARN及MapReduce，Spark從來沒說要取代Hadoop，最多也就是取代掉MapReduce。事實(shí)上現(xiàn)在Hadoop已經(jīng)發(fā)展成為一個(gè)生態(tài)系統(tǒng)，并且Hadoop生態(tài)系統(tǒng)也接受更多優(yōu)秀的框架進(jìn)來，如Spark (Spark可以和HDFS無縫結(jié)合，并且可以很好的跑在YARN上).。 另一方面，Spark除了跟Hadoop生態(tài)結(jié)合外，也得到了其它一些框架的支持如ElasticSearch及Cassandra等等。 所以Hadoop生態(tài)并不是使用Spark的先決條件，盡管Spark非常好的融入了Hadoop生態(tài)。
2、談?wù)凢link，跟Spark比較下？
答： 首先作為Spark在國內(nèi)的布道者，我必須承認(rèn)，我非常早的就關(guān)注了Flink : ) 目前Flink在歐洲的知名度還是可以的。 Flink跟Spark一樣，都是希望做一體化的計(jì)算引擎(批處理，流處理，機(jī)器學(xué)習(xí)，圖計(jì)算等)，并且他們都能很好的融入Hadoop生態(tài)(如跟HDFS無縫結(jié)合，及支持YARN作為調(diào)度框架等)。 咋一看兩者略相似，但其實(shí)他們走的路子還是不太一樣的，在Spark推出之際，就強(qiáng)調(diào)了“內(nèi)存計(jì)算”，而Flink走的其實(shí)是類似MPP的路子。另一方面，F(xiàn)link宣稱能真正意義上做到實(shí)時(shí)計(jì)算，而Spark只能做micro batch。不過Flink支持的增量迭代還是挺有意思的，它能在迭代過程中只去處理那些變化的數(shù)據(jù)，事實(shí)上迭代到后面的時(shí)候，F(xiàn)link只需要處理一小部分子集而已。不過以上都不是我最初關(guān)注Flink的原因，我當(dāng)初關(guān)注Flink的原因是它對(duì)內(nèi)存管理方面有著獨(dú)到之處。 Flink一開始就決定自己做內(nèi)存管理，它把heap分為三個(gè)部分: Network buffers, Memory Manager pool及Remaing heap，具體不展開了，有興趣的可以字節(jié)去查看下相關(guān)資料。當(dāng)然Spark也使出了殺手锏: project tungsten , 俗稱鎢絲計(jì)劃，除了做自己的內(nèi)存管理，也會(huì)做其它非常強(qiáng)悍的優(yōu)化。這些優(yōu)化將在1.4, 1.5, 1.6三個(gè)版本中體現(xiàn)。 哦，最后提一下，Spark只支持DAG，而Flink是支持cyclic的。 這個(gè)話題就先到這，后期很可能會(huì)來篇專門的文章。
3、談?wù)勀銓?duì)HBase及Cassandra的看法？
答：首先，一些國內(nèi)的工程師對(duì)Cassandra有著莫名其妙的誤解，以為當(dāng)年Facebook“拋棄”它，它就不行了，對(duì)此只能先呵呵。 我個(gè)人其實(shí)用HBase比較多，但是過去的一段時(shí)間，并沒有用HBase(最多也就一年多前作為OpenTSDB的后端跑了下)。 HBase和Cassandra在很多地方還是很相似的。一、都是面向列的存儲(chǔ)；二、都會(huì)先寫到Log中，然后進(jìn)入內(nèi)存中的存儲(chǔ)結(jié)構(gòu), 最后刷盤，甚至所用數(shù)據(jù)結(jié)構(gòu)都差不多：LSM。簡單來講，從HBase的角度就是 Data到HLog到Memstor到StoreFile(HFile)；從Cassandra的角度就是Data到CommitLog到memtable到sstable。 三、略，太多了。 那我們還是看看不一樣的地方吧，HBase需要ZK支持，Cassandra自給自足；HBase需要有Master，Cassandra需要有seed nodes； HBase要從ZK獲取信息，Cassandra使用gossip來通信；HBase底層要有HDFS支持，Cassandra不用；HBase原生不支持二級(jí)索引，Cassandra支持；HBase老早就有coprocessor，Cassandra木有......不一一列了吧。 大不同點(diǎn)還是HBase本質(zhì)上還是一個(gè)中心化的組織(peer-to-peer)，而Cassandra是去中心化的，我可能會(huì)更偏向后者。 目前很難說孰優(yōu)孰劣，你的選型你做主 : )
4、分布式消息隊(duì)列在流處理系統(tǒng)中是十分重要的，你選擇的消息隊(duì)列是哪個(gè)？能否簡述下原因？
答：毫無疑問 Kafka! 最多前面加個(gè)Flume。 任何選型的原因，都源自你的需求是什么。 Fast,Scalable,Durable是我的需求，Kafka完美滿足。稍微講些細(xì)節(jié)，好多想必大家也都知道。 Kafka將數(shù)據(jù)寫到磁盤，實(shí)際上都會(huì)寫到OS的page cache里， 而讀的時(shí)候又用sendfile非常高效的將數(shù)據(jù)傳輸?shù)絅IC。Kafka的擴(kuò)展性也非常好，只要增加broker即可。Kafka的邏輯也非常清晰，可以將不同業(yè)務(wù)邏輯的數(shù)據(jù)寫進(jìn)不同到topic，而topic又可以切分成若干個(gè)partition來并行處理，并且Kafka0.9后，zk只需要被broker所使用，consumer并不再需要使用zk來記錄offset，大大降低zk的壓力，同時(shí)也從側(cè)面降低了scale的壓力。Kafka也有比較友好的刪除策略。可以直接按照max age或者max size自動(dòng)刪除，也可以按照key進(jìn)行compact，基本上都能滿足需求。另一方面，Kafka的社區(qū)非常活躍，并且現(xiàn)在幾乎所有流行的(流式)計(jì)算框架都支持Kafka，如Spark Streaming，Storm等。對(duì)了，有個(gè)叫camus的工具定期可以將Kafka里的數(shù)據(jù)搬到HDFS上，已經(jīng)推薦一些小伙伴用過。 還是那句話，看需求，且能hold住。
5、 你對(duì)Tachyon的看法如何？
答：我是非常早就試用了Tachyon，注意，是試用！ 現(xiàn)在已經(jīng)有商業(yè)公司TachyonNexus為其保駕護(hù)航了。哦，對(duì)了，先說明下，Tachyon是用Java寫的，并不是用Scala寫的。我本人對(duì)Tachyon的前景非?？春?，說了半天好像還沒說Tachyon是個(gè)什么玩意兒。Tachyon是分布式內(nèi)存文件系統(tǒng)，隨著內(nèi)存越來越廉價(jià)，只要Tachyon本身質(zhì)量過硬，顯然不愁用戶。稍微簡單談下Tachyon的原理及特點(diǎn)吧，作為基于內(nèi)存的文件系統(tǒng)，那顯然要非常激進(jìn)的使用內(nèi)存了，那這時(shí)候就會(huì)有人擔(dān)心了，node掛了內(nèi)存里數(shù)據(jù)丟失怎么辦，這個(gè)其實(shí)不用擔(dān)心，在Tachyon下面一般還會(huì)有一層underlying filesystem，大多數(shù)情況下是HDFS，當(dāng)然也支持其它一些文件系統(tǒng), Tachyon定期會(huì)把數(shù)據(jù)checkpoint到underlying filesystem里。事實(shí)上Tachyon也有Journal(p_w_picpath + edit)的概念，非常有意思的是，Tachyon把Spark里lineage的理念搬了過來，依靠lineage做文件恢復(fù)。前面說到，現(xiàn)在出來一個(gè)framework，不跟Hadoop生態(tài)結(jié)合是很難混的，所以Tachyon也非常友好的實(shí)現(xiàn)了HDFS的接口，因此MapReduce及Spark，包括Flink都可以在幾乎不改動(dòng)代碼的情況下使用Tachyon。Tachyon另一個(gè)出色的點(diǎn)是支持table，用戶可以把查詢密度高的column放進(jìn)Tachyon，以此提高查詢效率。再補(bǔ)充幾個(gè)Tachyon可以解決的case：Spark的不同job間共享數(shù)據(jù)；不同框架間共享數(shù)據(jù)；避免Spark由于blockmanager掛掉后cache全丟失；解決內(nèi)存重復(fù)使用的問題，等。 這個(gè)問題就此打住，不展開了。(以上內(nèi)容轉(zhuǎn)載自：ChinaScala)
6、有10個(gè)文件，每個(gè)文件1G，每個(gè)文件的每一行存放的都是用戶的query，每個(gè)文件的query都可能重復(fù)。要求你按照query的頻度排序。
方案1：
1）順序讀取10個(gè)文件，按照hash(query)%10的結(jié)果將query寫入到另外10個(gè)文件（記為 ）中。這樣新生成的文件每個(gè)的大小大約也1G（假設(shè)hash函數(shù)是隨機(jī)的）。
2）找一臺(tái)內(nèi)存在2G左右的機(jī)器，依次對(duì) 用hash_map(query, query_count)來統(tǒng)計(jì)每個(gè)query出現(xiàn)的次數(shù)。利用快速/堆/歸并排序按照出現(xiàn)次數(shù)進(jìn)行排序。將排序好的query和對(duì)應(yīng)的query_cout輸出到文件中。這樣得到了10個(gè)排好序的文件（記為 ）。
3）對(duì) 這10個(gè)文件進(jìn)行歸并排序（內(nèi)排序與外排序相結(jié)合）。
方案2：
一般query的總量是有限的，只是重復(fù)的次數(shù)比較多而已，可能對(duì)于所有的query，一次性就可以加入到內(nèi)存了。這樣，我們就可以采用trie樹/hash_map等直接來統(tǒng)計(jì)每個(gè)query出現(xiàn)的次數(shù)，然后按出現(xiàn)次數(shù)做快速/堆/歸并排序就可以了。
方案3：
與方案1類似，但在做完hash，分成多個(gè)文件后，可以交給多個(gè)文件來處理，采用分布式的架構(gòu)來處理（比如MapReduce），最后再進(jìn)行合并。
7、 有一個(gè)1G大小的一個(gè)文件，里面每一行是一個(gè)詞，詞的大小不超過16字節(jié)，內(nèi)存限制大小是1M。返回頻數(shù)最高的100個(gè)詞。
方案：順序讀文件中，對(duì)于每個(gè)詞x，取 ，然后按照該值存到5000個(gè)小文件（記為 ）中。這樣每個(gè)文件大概是200k左右。如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續(xù)往下分，知道分解得到的小文件的大小都不超過1M。對(duì)每個(gè)小文件，統(tǒng)計(jì)每個(gè)文件中出現(xiàn)的詞以及相應(yīng)的頻率（可以采用trie樹/hash_map等），并取出出現(xiàn)頻率大的100個(gè)詞（可以用含100個(gè)結(jié)點(diǎn)的最小堆），并把100詞及相應(yīng)的頻率存入文件，這樣又得到了5000個(gè)文件。下一步就是把這5000個(gè)文件進(jìn)行歸并（類似與歸并排序）的過程了。
8、海量日志數(shù)據(jù)，提取出某日訪問百度次數(shù)最多的那個(gè)IP。
方案：首先是這一天，并且是訪問百度的日志中的IP取出來，逐個(gè)寫入到一個(gè)大文件中。注意到IP是32位的，最多有 個(gè)IP。同樣可以采用映射的方法，比如模1000，把整個(gè)大文件映射為1000個(gè)小文件，再找出每個(gè)小文中出現(xiàn)頻率大的IP（可以采用hash_map進(jìn)行頻率統(tǒng)計(jì)，然后再找出頻率大的幾個(gè)）及相應(yīng)的頻率。然后再在這1000個(gè)大的IP中，找出那個(gè)頻率大的IP，即為所求。
9、在2.5億個(gè)整數(shù)中找出不重復(fù)的整數(shù)，內(nèi)存不足以容納這2.5億個(gè)整數(shù)。
方案1：采用2-Bitmap（每個(gè)數(shù)分配2bit，00表示不存在，01表示出現(xiàn)一次，10表示多次，11無意義）進(jìn)行，共需內(nèi)存 內(nèi)存，還可以接受。然后掃描這2.5億個(gè)整數(shù)，查看Bitmap中相對(duì)應(yīng)位，如果是00變01，01變10，10保持不變。所描完事后，查看bitmap，把對(duì)應(yīng)位是01的整數(shù)輸出即可。
方案2：也可采用上題類似的方法，進(jìn)行劃分小文件的方法。然后在小文件中找出不重復(fù)的整數(shù)，并排序。然后再進(jìn)行歸并，注意去除重復(fù)的元素。
10、怎么在海量數(shù)據(jù)中找出重復(fù)次數(shù)最多的一個(gè)？
方案：先做hash，然后求模映射為小文件，求出每個(gè)小文件中重復(fù)次數(shù)最多的一個(gè)，并記錄重復(fù)次數(shù)。然后找出上一步求出的數(shù)據(jù)中重復(fù)次數(shù)最多的一個(gè)就是所求（具體參考前面的題）。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
