2018最新BAT大數(shù)據(jù)面試題

1、0,那HDFS。一個線程將緩沖區(qū)的數(shù)據(jù)寫到磁盤，這個過程叫做spill 。1、kafka 的message 包括哪些信息一個Kafka的Message 由一個固定長度的 header和一個變長的消息體 body組成 header部分由一個字節(jié)的 magic（文件格式）和四個字節(jié)的CRC32（用于判斷body消息體是否正常）構(gòu)成。當magic的值為1的時候，會在magic和crc32之間多一個字節(jié)的數(shù)據(jù):attributes（保存一些相關屬性，比如是否壓縮、壓縮格式等等）；如果magic的值為么不存在attributes 屬性body是由N個字節(jié)構(gòu)成的一個消息體，包含了具體的key/value

2、消息2、怎么查看kafka的offset0.9版本以上，可以用最新的Consumer client 客戶端，有 consumer.seekToEnd（）onsumer.position（）可以用于得到當前最新的offset :3、hadoop 的 shuffle 過程一、Map 端的 shuffleMap端會處理輸入數(shù)據(jù)并產(chǎn)生中間結(jié)果，這個中間結(jié)果會寫到本地磁盤，而不是 每個Map的輸出會先寫到內(nèi)存緩沖區(qū)中，當寫入的數(shù)據(jù)達到設定的閾值時，系統(tǒng)將會啟動然后在spill寫入之前，會先進行二次排序，首先根據(jù)數(shù)據(jù)所屬的Partition 進行排序,每個partition 中的數(shù)據(jù)再按key來排序。pa

3、rtition的目是將記錄劃分到不同的Reducer上去，以期望能夠達到負載均衡，以后的Reducer就會根據(jù)partition 來讀取自己對應的數(shù) 據(jù)。接著運行combiner（如果設置了的話），combiner的本質(zhì)也是一個 Reducer，其目的是對將要寫入到磁盤上的文件先進行一次處理,這樣，寫入到磁盤的數(shù)據(jù)量就會減少。最后Map任務結(jié)束后就會被刪除）。最后，每個Map任務可能產(chǎn)生多個 spill文件，在每個 Map任務完成前，會通過多路歸并算法將這些spill文件歸并成一個文件。至此，Map的shuffle過程就結(jié)束了。二、Reduce 端的 shuffleReduce 端的 shuf

4、fle 主要包括三個階段，copy、sort(merge) 和 reduce 。首先要將Map端產(chǎn)生的輸出文件拷貝到Reduce端，但每個 Reducer如何知道自己應該處理哪些數(shù)據(jù)呢？因為 Map端進行partition 的時候，實際上就相當于指定了每個Reducer要處理的數(shù)據(jù)（partition 就對應了 Reducer），所以Reducer在拷貝數(shù)據(jù)的時候只需拷貝與自己對應的partition中的數(shù)據(jù)即可。每個Reducer會處理一個或者多個partition ,但需要先將自己對應的partition中的數(shù)據(jù)從每個Map的輸出結(jié)果中拷貝過來。接下來就是sort階段，也成為merge階段

5、，因為這個階段的主要工作是執(zhí)行了歸并排序。從Map端拷貝到Reduce端的數(shù)據(jù)都是有序的，所以很適合歸并排序。最終在Reduce端生成一個較大的文件作為Reduce的輸入。最后就是 Reduce過程了，在這個過程中產(chǎn)生了最終的輸出結(jié)果，并將其寫到HDFS上。4、spark集群運算的模式Sp ark有很多種模式，最簡單就是單機本地模式，還有單機偽分布式模式，復雜的則運行在集群中，目前能很好的運行在Yarn和Mesos中，當然 Spark還有自帶的 Standalone模式，對于大多數(shù)情況Standalone模式就足夠了，如果企業(yè)已經(jīng)有 Yarn或者MesOS環(huán)境，也是很方便部署的。Master是

6、有單點故障的;yarn負責資源管理，Sparstandalone（集群模式）：典型的Mater/slave 模式，不過也能看出Spark 支持 ZooKeeper 來實現(xiàn) HA on yarn（集群模式）：運行在yarn資源管理器框架之上，由k負責任務調(diào)度和計算on mesos（集群模式）：運行在 mesos資源管理器框架之上,由 mesos負責資源管理,Spark負責任務調(diào)度和計算on cloud（集群模式）：比如AWS的EC2，使用這個模式能很方便的訪問Amazon 的 S3;Spark支持多種分布式存儲系統(tǒng):HDFS 和 S35、HDFS讀寫數(shù)據(jù)的過程讀:1、跟name node 通信查

7、詢元數(shù)據(jù),找到文件塊所在的data node 服務器2、挑選一臺data node （就近原則，然后隨機）服務器，請求建立socket3、data node開始發(fā)送數(shù)據(jù)（從磁盤里面讀取數(shù)據(jù)放入流，以packet為單位來做校驗）4、客戶端以packet為單位接收，現(xiàn)在本地緩存，然后寫入目標文件寫:1、根name node 通信請求上傳文件，name node 檢查目標文件是否已存在，父目錄是否 存在2、name node 返回是否可以上傳clie nt請求第一個block該傳輸?shù)侥男ヾata node服務器上name node 返回 3 個 data node 服務器 ABCclient請求3臺

8、dn中的一臺A上傳數(shù)據(jù)（本質(zhì)上是一個RPC調(diào)用，建立pipeline ），A收到請求會繼續(xù)調(diào)用B，然后B調(diào)用C,將真?zhèn)€pipeline建立完成，逐級返回客戶端6、client開始往A上傳第一個block （先從磁盤讀取數(shù)據(jù)放到一個本地內(nèi)存緩存），以acket為單位，A收到一個packet就會傳給 B，B傳給C ； A每傳一個packet會放入一個應答隊列等待應答7、當一個block 傳輸完成之后，clie nt再次請求name node上傳第二個 block的服務器。6、RDD中reduceBykey 與groupByKey 哪個性能好，為什么reduceByKey : reduceByKey

9、 會在結(jié)果發(fā)送至 reducer之前會對每個 mapper在本地進行merge ，有點類似于在 Map Reduce 中的combi ner。這樣做的好處在于，在map端進行一次reduce之后，數(shù)據(jù)量會大幅度減小，從而減小傳輸，保證reduce端能夠更快的進行結(jié)果計算。groupByKey : groupByKey 會對每一個 RDD中的value值進行聚合形成一個序列（Iterator），此操作發(fā)生在reduce端，所以勢必會將所有的數(shù)據(jù)通過網(wǎng)絡進行傳輸,造成不必要的浪費。同時如果數(shù)據(jù)量十分大，可能還會造成OutOfMemoryError 。通過以上對比可以發(fā)現(xiàn)在進行大量數(shù)據(jù)的reduce

10、操作時候建議使用reduceByKey。不僅可以提高速度，還是可以防止使用grou pByKey 造成的內(nèi)存溢出問題。7、spark2.0的了解更簡單：ANSI SQL與更合理的API速度更快：用Spark作為編譯器更智能：Structured Stream ing8、rdd怎么分區(qū)寬依賴和窄依賴寬依賴：父 RDD的分區(qū)被子 RDD的多個分區(qū)使用例如 groupByKey 、reduceByKey 、sortByKey等操作會產(chǎn)生寬依賴，會產(chǎn)生shuffle窄依賴：父RDD的每個分區(qū)都只被子 RDD的一個分區(qū)使用例如map、filter、union等操作會產(chǎn)生窄依賴9、spark stream

11、ing讀取kafka 數(shù)據(jù)的兩種方式這兩種方式分別是:Receiver-base使用Kafka的高層次Consumer API 來實現(xiàn)。receiver從Kafka中獲取的數(shù)據(jù)都存儲在Sp ark Executor的內(nèi)存中，然后 Spark Streami ng啟動的job會去處理那些數(shù)據(jù)。然而,在默認的配置下，這種方式可能會因為底層的失敗而丟失數(shù)據(jù)。如果要啟用高可靠機制，讓數(shù)據(jù)零丟失，就必須啟用Sp ark Streami ng的預寫日志機制(Write Ahead Log ，WAL)。該機制會同步地將接收到的Kafka數(shù)據(jù)寫入分布式文件系統(tǒng)（比如HDFS ）上的預寫日志中。所以，即使底層節(jié)

12、點出現(xiàn)了失敗，也可以使用預寫日志中的數(shù)據(jù)進行恢復。DirectSpark1.3中引入Direct方式，用來替代掉使用Receiver接收數(shù)據(jù)，這種方式會周期性地查詢Kafka，獲得每個topic+partition的最新的offset，從而定義每個batch的offset的范圍。當處理數(shù)據(jù)的job啟動時，就會使用 Kafka的簡單consumer api來獲取Kafka 指定offset范圍的數(shù)據(jù)。10、kafka的數(shù)據(jù)存在內(nèi)存還是磁盤內(nèi)存的速度一定Kafka最核心的思想是使用磁盤，而不是使用內(nèi)存，可能所有人都會認為,比磁盤快，我也不例外。在看了 Kafka的設計思想，查閱了相應資料再加上自己

13、的測試后,發(fā)現(xiàn)磁盤的順序讀寫速度和內(nèi)存持平。而且Linux對于磁盤的讀寫優(yōu)化也比較多，包括read-ahead 和write-behind，磁盤緩存等。如果在內(nèi)存做這些操作的時候，一個是JAVA對象的內(nèi)存開銷很大， 另一個是隨著堆內(nèi) 存數(shù)據(jù)的增多，JAVA的GC時間會變得很長，使用磁盤操作有以下幾個好處: 磁盤緩存由Linux系統(tǒng)維護，減少了程序員的不少工作。磁盤順序讀寫速度超過內(nèi)存隨機讀寫。JVM的GC效率低，內(nèi)存占用大。使用磁盤可以避免這一問題。系統(tǒng)冷啟動后，磁盤緩存依然可用。11、怎么解決kafka的數(shù)據(jù)丟失P roducer 端: 宏觀上看保證數(shù)據(jù)的可靠安全性，肯定是依據(jù)分區(qū)數(shù)做好數(shù)據(jù)

14、備份，設立副本數(shù)。broker 端:broker 中，分topic設置多分區(qū)，分區(qū)自適應所在機器，為了讓各分區(qū)均勻分布在所在的區(qū)數(shù)要大于broker數(shù)。分區(qū)是kafka進行并行讀寫的單位，是提升kafka速度的關鍵。Con sumer 端consumer端丟失消息的情形比較簡單：如果在消息處理完成前就提交了offset ，那么就有可能造成數(shù)據(jù)的丟失。由于Kafka con sumer默認是自動提交位移的，所以在后臺提交位移前一定要保證消息被正常處理了，因此不建議采用很重的處理邏輯，如果處理耗時很長,則建議把邏輯放到另一個線程中去做。為了避免數(shù)據(jù)丟失，現(xiàn)給出兩點建議:en mit=false關閉

15、自動提交位移在消息被完整處理之后再手動提交位移12、fsimage 和 edit 的區(qū)別？大家都知道name node 與seco ndary name node的關系，當他們要進行數(shù)據(jù)同步時叫做checkpoint時就用到了fsimage 與edit，fsimage 是保存最新的元數(shù)據(jù)的信息，當fsimage數(shù)據(jù)到一定的大小事會去生成一個新的文件來保存元數(shù)據(jù)的信息,這個新的文件就是edit，edit會回滾最新的數(shù)據(jù)。13、列舉幾個配置文件優(yōu)化?1)Core-site.xml 文件的優(yōu)化a、erval，默認值：0;說明： 這個是開啟hdfs文件刪除自動轉(zhuǎn)移到垃圾箱的選項

16、，值為垃圾箱文件清除時間。一般開啟這個會比較好，以防錯誤刪除重要文件。單位是分鐘。b、node.handler.count，默認值：10 ;說明：hadoop 系統(tǒng)里啟動的任務線程數(shù)，這里改為40 ,同樣可以嘗試該值大小對效率的影響變化進行最合適的值的設定。c、 mapreduce.tasktracker.http.threads，默認值：40;說明：map和reduce 是通過http進行數(shù)據(jù)傳輸?shù)?，這個是設置傳輸?shù)牟⑿芯€程數(shù)。14、 data node首次加入cluster的時候，如果 log報告不兼容文件版本，那需要name node執(zhí)行格式化操作，這樣處理的原因是?1）

17、這樣處理是不合理的,因為那么name node 格式化操作，是對文件系統(tǒng)進行格式化,name node格式化時清空dfs/n ame下空兩個目錄下的所有文件，之后，會在目錄dfs. name.dir下創(chuàng)建文件。2）文本不兼容，有可能時n ame node與 data node的數(shù)據(jù)里的 n ames pacelD 、clusterlD 不一致，找到兩個ID位置，修改為一樣即可解決。15、MapReduce中排序發(fā)生在哪幾個階段？這些排序是否可以避免？為什么?1） 一個Map Reduce 作業(yè)由Map階段和Reduce階段兩部分組成，這兩階段會對數(shù)據(jù)排序，從這個意義上說，Map Reduce框

18、架本質(zhì)就是一個Distributed Sort 。2 ）在Map階段，Map Task會在本地磁盤輸出一個按照key排序（采用的是快速排序）的文件（中間可能產(chǎn)生多個文件，但最終會合并成一個），在Reduce階段，每個ReduceTask會對收到的數(shù)據(jù)排序，這樣，數(shù)據(jù)便按照Key分成了若干組，之后以組為單位交給reduce ()處理。3 ）很多人的誤解在 Map階段，如果不使用 Comb iner便不會排序，這是錯誤的， 不管 你用不用 Combiner ，Map Task 均會對產(chǎn)生的數(shù)據(jù)排序（如果沒有 Reduce Task，則不會排序，實際上 Map階段的排序就是為了減輕Reduce端排序

19、負載）。4）由于這些排序是 Map Reduce自動完成的，用戶無法控制， 因此，在hadoop 1.x 中無法避免，也不可以關閉，但hadoo p2.x 是可以關閉的。16、hadoop 的優(yōu)化?1）優(yōu)化的思路可以從配置文件和系統(tǒng)以及代碼的設計思路來優(yōu)化2）配置文件的優(yōu)化：調(diào)節(jié)適當?shù)膮?shù)，在調(diào)參數(shù)時要進行測試3）代碼的優(yōu)化：combiner的個數(shù)盡量與reduce的個數(shù)相同，數(shù)據(jù)的類型保持一致，可以減少拆包與封包的進度4）系統(tǒng)的優(yōu)化：可以設置linux系統(tǒng)打開最大的文件數(shù)預計網(wǎng)絡的帶寬MTU的配置5）為job添加一個 Combiner ，可以大大的減少 shuffer階段的maoTask拷貝

20、過來給遠程的 reduce task的數(shù)據(jù)量，一般而言 comb in er 與reduce相同。6）在開發(fā)中盡量使用stringBuffer而不是string ，string 的模式是read-oniy 的，如果對它進行修改，會產(chǎn)生臨時的對象，二stri ngBuffer是可修改的，不會產(chǎn)生臨時對象。7）修改一下配置：以下是修改map red-site.xml文件a、修改最大槽位數(shù)：槽位數(shù)是在各個tasktracker上的mapred-site.xml上設置的,默認都是2vprop erty><n ame>ma pred.tasktracker.ma p.tasks.max

21、imu m</n ame><value>2</value></prop erty>vprop erty><n ame>ma pred.tasktracker.reduce.tasks.maximu m</n ame><value>2</value></prop erty>心跳時間b、調(diào)整心跳間隔：集群規(guī)模小于300時，心跳間隔為 300毫秒map reduce.jobtracker.heartbeat.i nterval.minmap red.heartbeats.i n. sec

22、 ond集群每增加多少節(jié)點，時間增加下面的值map reduce.jobtracker.heartbeat.scali ng.factor集群每增加上面的個數(shù)，心跳增多少c、啟動帶外心跳map reduce.tasktracker.outofba nd.heartbeat默認是falsed、配置多塊磁盤map reduce .lo cal.dire、配置 RPC hander 數(shù)目map red.job.tracker.ha ndler.co unt默認是10,可以改成 50,根據(jù)機器的能力f、配置HTTP線程數(shù)目tasktracker.http.threads 默認是 40，可以改成100

23、根據(jù)機器的能力g、選擇合適的壓縮方式，以snappy 為例:vprop erty> <n ame>ma pred.co mp ress.ma p.output</n ame> <value>true</value></prop erty> vprop erty> <n ame>ma pred.ma p.outpu t.co mp ressi on. codec</name <value>org.a pache.hado op .io.co mp ress.S napp yCodec</v

24、alue></prop erty>17、設計題1）采集nginx 產(chǎn)生的日志，日志的格式為user ip time url htmlId 每天產(chǎn)生的文件的數(shù)據(jù)量上億條， 請設計方案把數(shù)據(jù)保存到 HDFS上，并提供一下實時查詢的功能 （響應時間小于3s）A、某個用戶某天訪問某個 URL的次數(shù)B、某個URL某天被訪問的總次數(shù)實時思路是：使用Logstash + Kafka + Sp ark-streami ng + Redis +報表展示平臺離線的思路是：Logstash + Kafka + Elasticsearch +Sp ark-streami ng +關系型數(shù)據(jù)庫A、B、

25、數(shù)據(jù)在進入到 Spark-streaming中進行過濾，把符合要求的數(shù)據(jù)保存到Redis中18、有10個文件，每個文件1G ,每個文件的每一行存放的都是用戶的query，每個文件的query 都可能重復。要求你按照query的頻度排序。還是典型的TOP K算法,解決方案如下:1)方案1 :順序讀取 10個文件，按照 hash（query）%10的結(jié)果將query 寫入到另外10個文件（記為）中。這樣新生成的文件每個的大小大約也1G （假設hash函數(shù)是隨機的）。找臺內(nèi)存在 2G左右的機器，依次對用hash_ma p(q uery,query_co unt)來統(tǒng)計每個query出現(xiàn)的次數(shù)。利用快

26、速/堆/歸并排序按照出現(xiàn)次數(shù)進行排序。將排序好的query和對應的query_cout 輸出到文件中。這樣得到了 10個排好序的文件（記為）。對這10個文件進行歸并排序（內(nèi)排序與外排序相結(jié)合）。2）方案2:query，般query的總量是有限的，只是重復的次數(shù)比較多而已，可能對于所有的一次性就可以加入到內(nèi)存了。這樣，我們就可以采用trie樹/hash_map等直接來統(tǒng)計每億個數(shù)，設置相應的bit位，讀入要查詢的數(shù)，查看相應bit位是否為1，為1表示存?zhèn)€query出現(xiàn)的次數(shù)，然后按出現(xiàn)次數(shù)做快速/堆/歸并排序就可以了。3）方案3:與方案1類似，但在做完 hash，分成多個文件后，可以交給多個文件

27、來處理，采用分布式的架構(gòu)來處理（比如MapReduce ），最后再進行合并。2.5億個整數(shù)。19、在2.5億個整數(shù)中找出不重復的整數(shù)，注，內(nèi)存不足以容納這1 ）方案1 :采用2-Bitmap （每個數(shù)分配 2bit，00表示不存在，01表示出現(xiàn)一次,10表示多次，11無意義）進行，共需內(nèi)存2人32 * 2 bit=1 GB 內(nèi)存，還可以接受。然后掃描這2.5億個整數(shù)，查看Bitmap 中相對應位，如果是 00變01，01變10，10保持不變。所描完事后，查看bitmap，把對應位是 01的整數(shù)輸出即可。2 ）方案2 :也可采用與第 1題類似的方法，進行劃分小文件的方法。然后在小文件中找出不重復

28、的整數(shù)，并排序。然后再進行歸并，注意去除重復的元素。20、騰訊面試題：給40億個不重復的 unsigned int的整數(shù)，沒排過序的，然后再給一個數(shù)，如何快速判斷這個數(shù)是否在那40億個數(shù)當中?1）方案1: oo，申請512M 的內(nèi)存，一個bit位代表一個 unsigned int值。讀入 40在，為0表示不存在。2）方案2 :這個問題在編程珠璣里有很好的描述，大家可以參考下面的思路，探討這里我們一下：又因為2人32 為40億多，所以給定一個數(shù)可能在，也可能不在其中;把40億個數(shù)中的每一個用32位的二進制來表示，假設這40億個數(shù)開始放在一個文件中。然后將這40億個數(shù)分成兩類：1.最咼位為0 2.

29、最咼位為1并將這兩類分別寫入到兩個文件中，其中一個文件中數(shù)的個數(shù) <=20億，而另一個>=20億（這相當于折半了）與要查找的數(shù)的最高位比較并接著進入相應的文件再查找再然后把這個文件為又分成兩類1.次最高位為0 2.次最高位為1并將這兩類分別寫入到兩個文件中，其中一個文件中數(shù)的個數(shù) <=10 億，而另一個>=10億（這相當于折半了）與要查找的數(shù)的次最高位比較并接著進入相應的文件再查找。以此類推，就可以找到了 ，而且時間復雜度為O（logn），方案2完。3）附：這里，再簡單介紹下，位圖方法:使用位圖法判斷整形數(shù)組是否存在重復，判斷集合中存在重復是常見編程任務之一，當集合中數(shù)據(jù)量比較大時我們通常希望少進行幾次掃描,max創(chuàng)建一個長度為這時雙重循環(huán)法就不可取了。位圖法比較適合于這種情況，它的做法是按照集合中最大元素max+1的新數(shù)組，然后再次掃描原數(shù)組，遇到幾就給新數(shù)組的第幾位置上1 ,如遇到5就 給新數(shù)組的第六個元素置 1 ,這樣下次再遇到 5想置位時發(fā)現(xiàn)新數(shù)組的第六個元素已經(jīng)是種給新數(shù)組初始化時置零其后1 了，這說明這次的數(shù)據(jù)肯定和以前的數(shù)據(jù)存在著重復。這置一的做法類似于位圖的處理方法故稱位圖法。它的運算次數(shù)最壞的情況為2N 。如果已知數(shù)組的最大值即能事先給新數(shù)組定長的話效率還能提高一倍。21、怎么在海量數(shù)據(jù)中找出重復次