大數據面試常見問題解答

    大數據（big data），一般來說是指無法在可承受的時間范圍內用常規軟件工具進行捕捉、管理和處理的數據集合。本文匯總了大數據面試中常見的問題及解答方案，供大家參考：

1、Spark能否取代Hadoop？

答： Hadoop包含了Common,HDFS,YARN及MapReduce，Spark從來沒說要取代Hadoop，最多也就是取代掉MapReduce。事實上現在Hadoop已經發展成為一個生態系統，并且Hadoop生態系統也接受更多優秀的框架進來，如Spark (Spark可以和HDFS無縫結合，并且可以很好的跑在YARN上).。 另一方面，Spark除了跟Hadoop生態結合外，也得到了其它一些框架的支持如ElasticSearch及Cassandra等等。 所以Hadoop生態并不是使用Spark的先決條件，盡管Spark非常好的融入了Hadoop生態。

2、談談Flink，跟Spark比較下？

答： 首先作為Spark在國內的布道者，我必須承認，我非常早的就關注了Flink : ) 目前Flink在歐洲的知名度還是可以的。 Flink跟Spark一樣，都是希望做一體化的計算引擎(批處理，流處理，機器學習，圖計算等)，并且他們都能很好的融入Hadoop生態(如跟HDFS無縫結合，及支持YARN作為調度框架等)。 咋一看兩者略相似，但其實他們走的路子還是不太一樣的，在Spark推出之際，就強調了“內存計算”，而Flink走的其實是類似MPP的路子。另一方面，Flink宣稱能真正意義上做到實時計算，而Spark只能做micro batch。不過Flink支持的增量迭代還是挺有意思的，它能在迭代過程中只去處理那些變化的數據，事實上迭代到后面的時候，Flink只需要處理一小部分子集而已。不過以上都不是我最初關注Flink的原因，我當初關注Flink的原因是它對內存管理方面有著獨到之處。 Flink一開始就決定自己做內存管理，它把heap分為三個部分: Network buffers, Memory Manager pool及Remaing heap，具體不展開了，有興趣的可以字節去查看下相關資料。當然Spark也使出了殺手锏: project tungsten , 俗稱鎢絲計劃，除了做自己的內存管理，也會做其它非常強悍的優化。這些優化將在1.4, 1.5, 1.6三個版本中體現。 哦，最后提一下，Spark只支持DAG，而Flink是支持cyclic的。 這個話題就先到這，后期很可能會來篇專門的文章。

3、談談你對HBase及Cassandra的看法？

答：首先，一些國內的工程師對Cassandra有著莫名其妙的誤解，以為當年Facebook“拋棄”它，它就不行了，對此只能先呵呵。 我個人其實用HBase比較多，但是過去的一段時間，并沒有用HBase(最多也就一年多前作為OpenTSDB的后端跑了下)。 HBase和Cassandra在很多地方還是很相似的。一、都是面向列的存儲；二、都會先寫到Log中，然后進入內存中的存儲結構, 最后刷盤，甚至所用數據結構都差不多：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原生不支持二級索引，Cassandra支持；HBase老早就有coprocessor，Cassandra木有......不一一列了吧。 最大不同點還是HBase本質上還是一個中心化的組織(peer-to-peer)，而Cassandra是去中心化的，我可能會更偏向后者。 目前很難說孰優孰劣，你的選型你做主 : )

4、分布式消息隊列在流處理系統中是十分重要的，你選擇的消息隊列是哪個？能否簡述下原因？

答：毫無疑問 Kafka! 最多前面加個Flume。 任何選型的原因，都源自你的需求是什么。 Fast,Scalable,Durable是我的需求，Kafka完美滿足。稍微講些細節，好多想必大家也都知道。 Kafka將數據寫到磁盤，實際上都會寫到OS的page cache里， 而讀的時候又用sendfile非常高效的將數據傳輸到NIC。Kafka的擴展性也非常好，只要增加broker即可。Kafka的邏輯也非常清晰，可以將不同業務邏輯的數據寫進不同到topic，而topic又可以切分成若干個partition來并行處理，并且Kafka0.9后，zk只需要被broker所使用，consumer并不再需要使用zk來記錄offset，大大降低zk的壓力，同時也從側面降低了scale的壓力。Kafka也有比較友好的刪除策略。可以直接按照max age或者max size自動刪除，也可以按照key進行compact，基本上都能滿足需求。另一方面，Kafka的社區非常活躍，并且現在幾乎所有流行的(流式)計算框架都支持Kafka，如Spark Streaming，Storm等。對了，有個叫camus的工具定期可以將Kafka里的數據搬到HDFS上，已經推薦一些小伙伴用過。 還是那句話，看需求，且能hold住。

5、 你對Tachyon的看法如何？

答：我是非常早就試用了Tachyon，注意，是試用！ 現在已經有商業公司TachyonNexus為其保駕護航了。哦，對了，先說明下，Tachyon是用Java寫的，并不是用Scala寫的。我本人對Tachyon的前景非常看好，說了半天好像還沒說Tachyon是個什么玩意兒。Tachyon是分布式內存文件系統，隨著內存越來越廉價，只要Tachyon本身質量過硬，顯然不愁用戶。稍微簡單談下Tachyon的原理及特點吧，作為基于內存的文件系統，那顯然要非常激進的使用內存了，那這時候就會有人擔心了，node掛了內存里數據丟失怎么辦，這個其實不用擔心，在Tachyon下面一般還會有一層underlying filesystem，大多數情況下是HDFS，當然也支持其它一些文件系統, Tachyon定期會把數據checkpoint到underlying filesystem里。事實上Tachyon也有Journal(p_w_picpath + edit)的概念，非常有意思的是，Tachyon把Spark里lineage的理念搬了過來，依靠lineage做文件恢復。前面說到，現在出來一個framework，不跟Hadoop生態結合是很難混的，所以Tachyon也非常友好的實現了HDFS的接口，因此MapReduce及Spark，包括Flink都可以在幾乎不改動代碼的情況下使用Tachyon。Tachyon另一個出色的點是支持table，用戶可以把查詢密度高的column放進Tachyon，以此提高查詢效率。再補充幾個Tachyon可以解決的case：Spark的不同job間共享數據；不同框架間共享數據；避免Spark由于blockmanager掛掉后cache全丟失；解決內存重復使用的問題，等。 這個問題就此打住，不展開了。(以上內容轉載自：ChinaScala)

6、有10個文件，每個文件1G，每個文件的每一行存放的都是用戶的query，每個文件的query都可能重復。要求你按照query的頻度排序。

　　方案1： 

　　1）順序讀取10個文件，按照hash(query)%10的結果將query寫入到另外10個文件（記為 ）中。這樣新生成的文件每個的大小大約也1G（假設hash函數是隨機的）。 

　  2）找一臺內存在2G左右的機器，依次對 用hash_map(query, query_count)來統計每個query出現的次數。利用快速/堆/歸并排序按照出現次數進行排序。將排序好的query和對應的query_cout輸出到文件中。這樣得到了10個排好序的文件（記為 ）。 

　　3）對 這10個文件進行歸并排序（內排序與外排序相結合）。

　　方案2： 

　　一般query的總量是有限的，只是重復的次數比較多而已，可能對于所有的query，一次性就可以加入到內存了。這樣，我們就可以采用trie樹/hash_map等直接來統計每個query出現的次數，然后按出現次數做快速/堆/歸并排序就可以了。 

　　方案3： 

　　與方案1類似，但在做完hash，分成多個文件后，可以交給多個文件來處理，采用分布式的架構來處理（比如MapReduce），最后再進行合并。 

7、 有一個1G大小的一個文件，里面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M。返回頻數最高的100個詞。 

　　方案：順序讀文件中，對于每個詞x，取 ，然后按照該值存到5000個小文件（記為 ）中。這樣每個文件大概是200k左右。如果其中的有的文件超過了1M大小，還可以按照類似的方法繼續往下分，知道分解得到的小文件的大小都不超過1M。對每個小文件，統計每個文件中出現的詞以及相應的頻率（可以采用trie樹/hash_map等），并取出出現頻率最大的100個詞（可以用含100個結點的最小堆），并把100詞及相應的頻率存入文件，這樣又得到了5000個文件。下一步就是把這5000個文件進行歸并（類似與歸并排序）的過程了。 

8、海量日志數據，提取出某日訪問百度次數最多的那個IP。 

　　方案：首先是這一天，并且是訪問百度的日志中的IP取出來，逐個寫入到一個大文件中。注意到IP是32位的，最多有 個IP。同樣可以采用映射的方法，比如模1000，把整個大文件映射為1000個小文件，再找出每個小文中出現頻率最大的IP（可以采用hash_map進行頻率統計，然后再找出頻率最大的幾個）及相應的頻率。然后再在這1000個最大的IP中，找出那個頻率最大的IP，即為所求。 

9、在2.5億個整數中找出不重復的整數，內存不足以容納這2.5億個整數。 

　　方案1：采用2-Bitmap（每個數分配2bit，00表示不存在，01表示出現一次，10表示多次，11無意義）進行，共需內存 內存，還可以接受。然后掃描這2.5億個整數，查看Bitmap中相對應位，如果是00變01，01變10，10保持不變。所描完事后，查看bitmap，把對應位是01的整數輸出即可。 

　　方案2：也可采用上題類似的方法，進行劃分小文件的方法。然后在小文件中找出不重復的整數，并排序。然后再進行歸并，注意去除重復的元素。

10、怎么在海量數據中找出重復次數最多的一個？ 

　　方案：先做hash，然后求模映射為小文件，求出每個小文件中重復次數最多的一個，并記錄重復次數。然后找出上一步求出的數據中重復次數最多的一個就是所求（具體參考前面的題）。