117道有關大數據面試題的解析，但願對你有所幫助

時間 2019-11-17

標籤有關數據面試題的解析但願有所幫助欄目快樂工作简体版

原文原文鏈接

一 .簡述如何安裝配置apache 的一個開源的hadoophtml

使用root帳戶登錄

2.修改ipjava

3.修改host主機名node

4.配置ssh 免密登錄python

5.關閉防火牆mysql

6.安裝ＪＤＫlinux

7.解壓hadoop安裝包ios

8.配置hadoop的核心配置文件 hadoop-env.sh? core-site.xml? mapred-site.xml yarn-site.xml hdfs-site.xml程序員

9.配置hadoop 的環境變量web

10 .格式化hadoop namenode-format面試

啓動節點start-all.sh

二 .列出hadoop 集羣中的都分別須要啓動哪些進程它們分別是做用是什麼？

namenode :負責管理HDFS中文件的元數據，響應客戶端請求，管理datanode 上文件block的均衡，維持副本數量

secondname: 主要負責checkpoint 操做也能夠作冷備對必定範圍內數據作快照性備份

datanode : 存儲數據塊負責客戶對數據塊的io請求

jobtracker :管路任務，並將任務分配給tasktracker

tasktracker: 執行jobtrancker 分配的任務

resource manager? nodemanager journalnode? zookeeper? zkfc

三簡述mapreduce的運行原理

先將文件進行分割後，進行map操做，後面進行shuffle操做，分爲map端shuffle和reduce端shuffle，map輸出結果放在緩衝區，當緩存區到達必定閾值時，將其中數據spill（也就是溢寫）到磁盤，而後進行partition, sort, combine操做，這樣屢次spill後，磁盤上就會有多個文件，merge操做將這些文件合併成一個文件，reduce端shuffle從map節點拉取數據文件，若是在內存中放得下，就直接放在內存中，每一個map對應一塊數據，當內存佔用量達到必定程度時，啓動內存時merge，把內存中的數據輸出到磁盤的一個文件上。若是在內存中放不下的話，就直接寫到磁盤上。一個map數據對應一個文件，當文件數量達到必定閥值時，開始啓動磁盤文件merge，把這些文件合併到一個文件中。最後，把內存中的文件和磁盤上的文件進行全局merge，造成一個最終端文件，作爲reduce的輸入文件。固然merge過程當中會進行sort,combine操做。

四 hive中內部外部表的區別

內部表：數據存儲在Hive的數據倉庫目錄下，刪除表時，除了刪除元數據，還會刪除實際表文件。

外部表：數據並不存儲在Hive的數據倉庫目錄下，刪除表時，只是刪除元數據，並不刪除實際表文件。

五 mapreduce中的combiner 和partition的區別

? Combiner就是在map端先進行一次reduce操做，減小map端到reduce端的數據傳輸量，節省網絡帶寬，提升執行效率。

Partition就是將map輸出按key分區，送到不一樣的reduce上去並行執行，提升效率。

六面試問答：

一、講項目經驗：

問的很細，給紙，筆，讓畫公司hadoop的項目架構,說幾條業務數據，而後通過平臺後，出來成什麼樣子；

二、java方面：

io輸入輸出流裏有哪些經常使用的類，還有webService,線程相關的知識；

三、linux：

問到jps命令，kill命令，問awk,sed是幹什麼用的、還有hadoop的一些經常使用命令；

四、hadoop：

講hadoop1中map,shuffle,reduce的過程，其中問到了map端和reduce端溢寫的細節；

也問了一些，外部表，還有就是hive的物理模型跟傳統數據庫的不一樣。

七新手問答：

一、工資多少，工做幾年了,有java基礎嗎,大學學什麼

** 13k,作javaweb將近三年，2014年4月開始學習hadoop,如今已經工做一個多月了，有java基礎，大學是計算機系

二、flume,kafka,storm是怎麼學的，有沒有作優化

** 看官方文檔，先搭環境，而後用java寫代碼調用它們的接口，熟悉api不過，若是有視頻資源的話，仍是建議儘可能看一下

三、如今用hadoop1仍是2

**hadoop2

四、面試時說作hadoop多久了

** 我說的將近兩年，面試時必定要說有hadoop經驗

五、storm,python以前都會嗎，仍是進公司後自學的

**這些都是到公司後，自學的

六、你用的hadoop是收費的仍是免費的

**目前是用的是免費的

七、本身搭過集羣嗎，一開始壓力大嗎

**集羣是本身搭的，壓力很大，不過車到山前必有路

八、廣告做弊用mapreduce計算嗎

** 用的storm，實時處理

九、普通局域網的機子能夠搭建麼

** 能夠，當時我先在本身機器上測試，用的本身電腦上的虛擬機，後來公司買的去服務器

十、flume的知識有什麼高深的東西

**我以爲沒有什麼東西是高深，只是咱們沒有涉入，只要用的多，多測試，它只是一個軟件而已

十一、你看源碼嗎，如今？

**會看源碼，可是我以爲不要死扣在源碼，咱們主要是應用，若是本身有精力，也能夠分塊研究一下

十二、公司如今有多少臺服務器？

**有10臺，我用其中四臺作了storm,kafka,flume，另外四臺作hadoop ,hive,還有兩臺用作機器學習用

1三、沒有java能作hadoop麼

**不能吧，必需要會java

1四、面試時會不會讓默寫代碼

**沒有遇到過（不一樣的公司不同）

1五、本身學，遇到問題都本身解決嗎？

**目前遇到的問題，本身都能解決，若是不能的話，會救助同事吧

1六、大家數據庫用hbase?

**目前還沒用，如今主要用mongdb,mysql,redis（hive、hbase的公司很多）

1七、大專很差找工做嗎？

也沒有，我有個同事，也是大專，可是她找工做時說本身是本科（由於那職位要求本科），後來面試經過後，又給人事打電話說，我實際上是大專，可是爲了獲得此次面試機會，我說本身是本科。。。後來人事說這個不要緊。。。那個公司就是×××，她如今已經在那裏上班了（這個屬於特殊狀況，若是比較嚴的公司，拒絕的可能性是很是大的，除非實力強勁，大專找到工做是很正常的事情，

**這裏只是公供你們參考，但願去其糟粕，取其精華

1八、如今hadoop什麼水平了，基本的框架都會用的程度嗎？

** 是的，我如今基本框架都會用，都搭集羣環境，包括調用的api也都很熟悉

1九、hadoop方向不錯我如今15k，考慮要不要轉

**我以爲這個要看你如今的行業之後的發展，若是有瓶頸，我以爲能夠考慮轉

20、英文雜樣，能看懂官方文檔嗎？

**看文檔的問題不大，寫和說還不行，我正在作計劃，看怎麼學

2一、你對本身在it行業啥想法呢，會一直在大數據這方面嗎？

**目前個人想法是之後準備作數據挖掘，機器學習工程師

2二、python要掌握到什麼程度？

**在互聯網方面，python,shell都是少不了的工具，我以爲咱們主要精通一門，python的話，能看懂，能修改別人代碼就行。如今的話，我仍是比較推崇python，比shell強大，比java簡潔。

**2三、3周是本身單獨學，仍是工做以外學？

** 學習的過程，我通常都是晚上學，很癡迷，也多是由於想趕忙轉，脫離當前公司的苦海，哈哈

2四、人家說集羣什麼的都沒有搭建，這樣的工做你當時沒猶豫就接了嗎，這麼有自信？

**當時我也很擔憂，不過進去的時候，也有說，讓我別壓力太大，若是有問題，他們會想辦法找人幫我解決，因此我就豁出去

2五、shell掌握到什麼程度是，工做用到的難不難

**我以爲shell 的話，主要把awk,sed學好，固然基礎也要學好，好比網絡配置、基本操做

八寬表你什麼理解？

寬表指的是行少列多，若是一行數據量過大，可能形成一個HFile放不下。但寬表有行級原子性的優點。高表指的是行多列少，Hbase只能按行分片，所以高表更有優點。具體仍是要根據業務場景綜合考慮。

2）最好不要定義過多的ColumnFamily，通常來講，一張表一個ColumnFamily就好。由於Flushing和壓縮是基於Region的。當一個ColumnFamily所存儲的數據達到Flushing閥值時，該表中的其餘ColumnFamily可能沒存儲多少數據，也要跟着進行Flushing操做，這將會帶來不少沒必要要的IO消耗。ColumFamily越多，對性能的影響也就越大。此外，同一個表中不一樣的ColumnFamily存儲的數據量差異也不要太大，否則有些數據會分散在太多的Region上，會影響檢索效率。

九 Hbase rowkey設計原則

總的原則：綜合考慮業務場景，及hbase的存儲訪問特色。

幾個簡單的原則：rowkey惟一，長度一致，能短則短。

而後考慮幾個問題：

1）讀取方便？

i. 儘量的把檢索條件存儲於rowkey中。

ii. 同時訪問的數據，rowkey儘可能鏈接，便可以利用scan指定start和end rowkey直接訪問。

2）提升寫效率？

i. 評估業務場景，根據數據分佈狀況進行預分區，提升併發度。

ii. 有些狀況下，能夠加入散列值，使寫分散到各regionserver，避免單點過載。

十 . mapreduce?的?join?方法有哪些？

database.51cto.com/art/201410/…

my.oschina.net/leejun2005/…

若有兩個文件File1和File2，文件內容以下：

File1: （學生編碼，學生名字，性別）

zs 張三男

...

File2: （學生編碼，選修課程，得分）

zs c1 80

zs c2 90

...

1） reduce join

適用於兩張表都是大表

在map階段，輸出，在value中標記數據是來自File1和File2，在reduce階段，將key的value按照來源是File1仍是File2分紅兩組，作集合乘積。

缺點：

i.? map階段沒有對數據瘦身，shuffle的網絡傳輸和排序性能很低。

ii.? reduce端對2個集合作乘積計算，很耗內存，容易致使OOM。

示例：

在map階段：map函數同時讀入兩個文件File1和File2，對每一條數據打一個標籤，用來區分數據來源於File1仍是File2。鏈接字段作爲key，其餘字段及標誌作爲value。

如

在shuffle階段:? 會按key分組，鏈接字段爲key，各個map的的輸出結果造成list作爲value。

如

在reduce階段:? 對同一個key，按標誌位，將value分紅左表和右表，而後進行笛卡爾鏈接輸出。

如左表 = { "張三男" }

右表 = {? "c1 80",? "c2 90"? }

而後兩個for循環實現笛卡爾鏈接輸出：

張三男 c1 80

張三男 c2 90

2） map join

適合一張小表，一張大表。

小數據文件所有加載到內存，大數據文件做爲map的輸入文件，在內存中和小數據文件進行鏈接，按key分組輸出。減少shuffle階段的排序和網絡傳輸消耗。

示例：

假設File1爲小表，File2爲大表。

i.? 將小表文件File1放到該做業的DistributedCache中。

ii.? 在setup函數中，將File1從DistributedCache中讀入內存中，如hash map中。如：

{zs, "張三男"}

iii.? 在map函數中，掃描File2，判斷File2的key在不在hasp map中，若是在，直接輸出（

key + hash map中該key的value +? File2中其餘字段）如：

zm 張三男? c1 80

3）semi join

reduce join的一個變種。將File1中參與join的key單獨抽取出來，存入File3。經過Distributed Cache分發到相關節點，而後將其取出放到內存中，如hash set中。在map階段掃描鏈接表，將key不在set中的記錄過濾掉，將那些參與join的記錄打上標籤經過shuffle傳輸到reduce端進行操做，後面的過程和reduce join是同樣的。

4）reduce join + boomfilter

若是semi join 抽取出來的key在內存中還放不下，則考慮將key放入boomfilter。經過boomfilter過濾掉不須要參與join的記錄，將那些參與join的記錄打上標籤經過shuffle傳輸到reduce端進行操做，後面的過程和reduce join是同樣的。boomfilter是經過二進制位（0101這些）記錄數據，因此佔用空間比較小。

十一 MR數據傾斜緣由和解決方案

數據傾斜就是數據key分佈不均勻，致使分發到不一樣的reduce上，個別reduce任務特別重，致使其餘reduce都完成，而這些個別的reduce遲遲不完成的狀況。

blog.sina.com.cn/s/blog_9402…

www.cnblogs.com/datacloud/p…

緣由以下：

1） key分佈不均勻

2）業務數據自己的特徵

解決方案：

假設A、B兩張表關聯，A中存在數據傾斜的key

1）先對A表進行採樣，將形成數據傾斜的key的記錄存入一個臨時表tmp1。

2）通常狀況下，形成數據傾斜的key不會太多，因此tmp1會是一個小表。因此能夠將tmp1和B表進行map join，生成tmp2，再把tmp2分發到distribute file cache。

3）map讀入A表和B表，假如記錄來自A表，則判斷key是否在tmp2中，若是是，輸出到本地文件a，若是不是，則生成對，假如記錄來自B表，生成對，進入reduce階段。

4）將文件a和步驟3中reduce輸出文件合併起來寫到hdfs。

通俗的說法：

1）map端數據傾斜，通常是輸入文件太多且大小不一形成的，能夠考慮合併文件。

2）reduce端數據傾斜，通常是默認的分區器問題，能夠考慮自定義分區，根據數據中key特性及分佈狀況自定義分區，使之儘量均勻地分配到reduce。

3）設置Combine, 聚合精簡數據。

4 ) 兩張表join，若是形成數據傾斜的key記錄佔全量數據比例較少的話，能夠考慮將數據分爲傾斜和非傾斜部分，這樣傾斜部分會是小文件，能夠使用map join處理，非傾斜部分則能夠按正常reduce處理，最後合併起來便可。

若是使用hive統計，能夠經過如下辦法解決：

調節hive配置參數：

i. hive.map.aggr = true? --map端部分聚合至關於Combiner

ii. hive.groupby.skewindata = true? --有數據傾斜時，查詢計劃生成兩個mr job，第一個job先進行key隨機分配處理，先縮小數據量。第二個job再進行真正的group by key數理。

SQL調節

i. 大小表join

使用map join讓小表先進內存，在map端完成reduce。

ii. 大表join大表

若是是空值形成數據傾斜，那麼把空值變成一個字符串加上隨機數，把這部分傾斜的數據分發到不一樣的reduce上。

iii. count distinct 大量相同特殊值（如空值）

空值能夠不用處理，直接最後count結果加1便可。或者空值單獨拿出來處理，最後再union回去。

iv. 不一樣數據類型關聯

默認的hash操做會按其中一種類型的值進行分配，致使別一種類型所有分發到同一個reduce中。把兩個關聯的類型轉換成相同類型。

RDMS數據庫三範式

1NF：字段不可分割。? org_id只能存機構編碼，不能存機構編碼+用戶編碼

2NF：主鍵不可冗餘。? org_id+kpi_code 作爲主鍵能夠。 org_id+org_name+kpi_code作爲主鍵不妥。

3NF：非主鍵不可依賴。org_id，kpi_code，kpi_value作爲一張表能夠，org_id,? org_name, kpi_code,? kpi_value作爲一張表不妥，由於依賴到非主鍵org_name。

其實OLTP能夠徹底遵照3NF，但OLAP只要作到2NF就能夠了。

十二 hadoop?運轉的原理?

經過namenode管理文件系統的命名空間，維護文件系統樹中的全部文件和文件夾的元數據，由datanode存儲實際數據，並向namenode彙報數據存儲狀況。即經過hdfs實現數據存儲，經過mr實現數據計算處理。

十三 mapreduce?的原理?

一個根本思想就是「分而治之」，將一個大任務分解成多個小任務，map並行執行後，reduce合併結果。

十四說說mapreduce?是怎麼來運轉的?

十五 HDFS?存儲的機制?

namenode負責維護全部數據目錄及文件的元數據，datanode負責實際數據存儲。

客戶端向hfds寫數據，首先會將數據分塊，與namenode通訊，namenode告知客戶端將數據寫入datanode的地址，第一個datanode寫完後，將數據同步給第2個datanode，依次類推，直到全部備份節點寫完爲止，而後進入下一個數據塊的寫操做。

在有啓用機架感知的狀況下，存儲策略爲本地一份，同機架內其它某一節點上一份，不一樣機架的某一節點上一份。

十六 mapreduce?中?Combiner?和?Partition?的做用

Combiner就是在map端先進行一次reduce操做，減小map端到reduce端的數據傳輸量，節省網絡帶寬，提升執行效率。

Partition就是將map輸出按key分區，送到不一樣的reduce上去並行執行，提升效率。

十七 Hive?元數據保存的方法有哪些，各有什麼特色？

1）、內嵌模式：將元數據保存在本地內嵌的derby數據庫中，內嵌的derby數據庫每次只能訪問一個數據文件，也就意味着它不支持多會話鏈接。

2）. 本地模式：將元數據保存在本地獨立的數據庫中（通常是mysql），這能夠支持多會話鏈接。

3）. 遠程模式：把元數據保存在遠程獨立的mysql數據庫中，避免每一個客戶端都去安裝mysql數據庫。

十八 hadoop機架感知

blog.csdn.net/l1028386804…

topology.script.file.name

value指定一個可執行程序，一般是一個shell腳本，該腳本接受一個參數（ip），輸出一個值（機架位置）。

能夠將ip，主機名，機架位置配置在一個配置文件中。而後腳本讀取該配置文件，去解析傳入ip對應的機架位置，並輸出便可。固然也能夠用java類實現。

hdfs存儲策略是本地存儲一份，同機架內其餘節點存儲一份，不一樣機架某一節點存儲一份，當執行計算時，發現本地數據損壞，能夠從同一機架相鄰節點拿到數據，速度確定比跨機架來得快。同時，若是整個機架的網絡出現異常，也能保證能從其餘機架拿到數據。要實現這個存儲策略，就須要機架感知。

十九 hdfs?的數據壓縮算法

www.tuicool.com/articles/eI…

壓縮格式：gzip,? bzip2,? lzo

壓縮算法：deflate[d?'fle?t],? bzip2，lzo

從壓縮效果來說：bzip2 > gzip > lzo

從壓縮速度來說：lzo > gzip > bizp2

另外bizp2，lzo都支持文件分割，gzip不支持。

全部壓縮算法都是時間和空間的權衡，在選擇哪一種壓縮格式時，咱們應該根據自身的業務須要來選擇。

二十 hadoop?的調度器有哪些，工做原理？

www.mamicode.com/info-detail…

www.cnblogs.com/xing901022/…

my.oschina.net/ssrs2202/bl…}

www.tuicool.com/articles/M3…

lxw1234.com/archives/20…

FIFO調度器，只有一個隊列，按先進先出的原則爲job分配資源。

Capacity調度器，能夠設置多個隊列，併爲每一個隊列設置資源佔比，好比有三個隊列，資源佔比能夠設置爲30%，30%，40%。隊列之間支持共享資源，當某個隊列的資源不用時，能夠共享給其餘有須要的隊列。當集羣繁忙時，一旦有些任務完成釋放資源造成空閒資源，優先分配給資源利用率低的隊列，最終達到按「隊列容量」分配資源的效果。隊列裏面的Job按FIFO規則選擇優先順序。

固然，能夠設置隊列的最大資源使用量，這樣能夠保證每一個隊列都不會佔用總體集羣的資源。

Fair調度器，能夠設置多個隊列，併爲每一個隊列設置最小份額，權重等指標，好比整個集羣有100G內存，有三個隊列，最小份額分別設置爲40G,30G,20G，權重分別設置爲2，3，4（按照誰願意分享更多，誰得到更多的原則，即最小份額跟權重成反比關係）。隊列之間支持資源共享，當某個隊列的資源不用時，能夠共享給其餘有須要的隊列。當集羣繁忙時，一旦有些任務完成釋放資源造成空閒資源，優先分配給「飢餓程度」（已使用資源量跟最小份額之間的差距程度）較高的隊列，慢慢地，你們就會進入都不「飢餓」的狀態，這時按已使用資源量/權重誰小分配給誰，最終達到按最小份額和權重「公平」分配資源的效果。隊列裏面的Job可按FIFO或Fair（Fair判斷指標有：job已使用資源量與實際須要資源量的差距，提交時間）選擇優先順序。

還有Capacity和Fair調度器都支持資源搶佔。

二十一 hive?中的壓縮格式?RCFile、TextFile、SequenceFile?各有什麼區別？

blog.csdn.net/yfkiss/arti…

TextFile：Hive默認格式，不做壓縮，磁盤及網絡開銷較大。能夠結合Gzip, Bzip2使用，但使用這種方式，hive不會對數據進行切分，從而沒法對數據進行並行操做。

SequenceFile:? SequenceFile 是Hadoop API提供支持的一種二進制文件，具備使用方便，可分割，可壓縮的特色，支持三種壓縮選擇：NONE, RECORD, BLOCK。RECORD壓縮率低，通常建議使用BLOCK壓縮。

RCFILE:? RCFILE是一種行列存儲相結合的的存儲方式。首先，將數據按行分塊，保證同一個record在一個塊上，避免讀一個記錄須要讀取多個block。其次，塊數據列式存儲，有利於數據壓縮。

總結：相比TEXTFILE和SEQUENCEFILE，RCFILE因爲列式存儲方式，數據加載時性能消耗較大，可是具備較好的壓縮比和查詢響應。數據倉庫的特色是一次寫入，屢次讀取，所以，總體來看，RCFILE相比兩它兩種格式，具備較明顯的優點。

二十二 Hive中的內部表，外部表，分區表、桶表有什麼區別和做用？

內部表：數據存儲在Hive的數據倉庫目錄下，刪除表時，除了刪除元數據，還會刪除實際表文件。

外部表：數據並不存儲在Hive的數據倉庫目錄下，刪除表時，只是刪除元數據，並不刪除實際表文件。

分區表：跟RDMS的分區概念相似，將一張表的數據按照分區規則分紅多個目錄存儲。這樣能夠經過指定分區來提升查詢速度。

桶表：在表或分區的基礎上，按某一列的值將記錄進行分桶存放，即分文件存放，也就是將大表變成小表的意思，這樣，涉及到Join操做時，能夠在桶與桶間關聯便可，大大減少Join的數據量，提升執行效率。

二十三 kafka的message包括哪些信息

一個Kafka的Message由一個固定長度的header和一個變長的消息體body組成header部分由一個字節的magic(文件格式)和四個字節的CRC32(用於判斷body消息體是否正常)構成。當magic的值爲1的時候，會在magic和crc32之間多一個字節的數據：attributes(保存一些相關屬性，好比是否壓縮、壓縮格式等等)；若是magic的值爲0，那麼不存在attributes屬性

body是由N個字節構成的一個消息體，包含了具體的key/value消息

二十四怎麼查看kafka的offset

0.9版本以上，能夠用最新的Consumer client 客戶端，有consumer.seekToEnd() / consumer.position() 能夠用於獲得當前最新的offset：

二十五 hadoop的shuffle過程

Map端的shuffle

Map端會處理輸入數據併產生中間結果，這個中間結果會寫到本地磁盤，而不是HDFS。每一個Map的輸出會先寫到內存緩衝區中，當寫入的數據達到設定的閾值時，系統將會啓動一個線程將緩衝區的數據寫到磁盤，這個過程叫作spill。

在spill寫入以前，會先進行二次排序，首先根據數據所屬的partition進行排序，而後每一個partition中的數據再按key來排序。partition的目是將記錄劃分到不一樣的Reducer上去，以指望可以達到負載均衡，之後的Reducer就會根據partition來讀取本身對應的數據。接着運行combiner(若是設置了的話)，combiner的本質也是一個Reducer，其目的是對將要寫入到磁盤上的文件先進行一次處理，這樣，寫入到磁盤的數據量就會減小。最後將數據寫到本地磁盤產生spill文件(spill文件保存在{mapred.local.dir}指定的目錄中，Map任務結束後就會被刪除)。

最後，每一個Map任務可能產生多個spill文件，在每一個Map任務完成前，會經過多路歸併算法將這些spill文件歸併成一個文件。至此，Map的shuffle過程就結束了。

Reduce端的shuffle

Reduce端的shuffle主要包括三個階段，copy、sort(merge)和reduce。

首先要將Map端產生的輸出文件拷貝到Reduce端，但每一個Reducer如何知道本身應該處理哪些數據呢？由於Map端進行partition的時候，實際上就至關於指定了每一個Reducer要處理的數據(partition就對應了Reducer)，因此Reducer在拷貝數據的時候只需拷貝與本身對應的partition中的數據便可。每一個Reducer會處理一個或者多個partition，但須要先將本身對應的partition中的數據從每一個Map的輸出結果中拷貝過來。

接下來就是sort階段，也成爲merge階段，由於這個階段的主要工做是執行了歸併排序。從Map端拷貝到Reduce端的數據都是有序的，因此很適合歸併排序。最終在Reduce端生成一個較大的文件做爲Reduce的輸入。

最後就是Reduce過程了，在這個過程當中產生了最終的輸出結果，並將其寫到HDFS上。

二十六 spark集羣運算的模式

Spark 有不少種模式，最簡單就是單機本地模式，還有單機僞分佈式模式，複雜的則運行在集羣中，目前能很好的運行在 Yarn和 Mesos 中，固然 Spark 還有自帶的 Standalone 模式，對於大多數狀況 Standalone 模式就足夠了，若是企業已經有 Yarn 或者 Mesos 環境，也是很方便部署的。

standalone(集羣模式)：典型的Mater/slave模式，不過也能看出Master是有單點故障的；Spark支持ZooKeeper來實現 HA

on yarn(集羣模式)：運行在 yarn 資源管理器框架之上，由 yarn 負責資源管理，Spark 負責任務調度和計算

on mesos(集羣模式)：運行在 mesos 資源管理器框架之上，由 mesos 負責資源管理，Spark 負責任務調度和計算

on cloud(集羣模式)：好比 AWS 的 EC2，使用這個模式能很方便的訪問 Amazon的 S3;Spark 支持多種分佈式存儲系統：HDFS 和 S3

二十七 HDFS讀寫數據的過程

讀：

一、跟namenode通訊查詢元數據，找到文件塊所在的datanode服務器

二、挑選一臺datanode（就近原則，而後隨機）服務器，請求創建socket流

三、datanode開始發送數據（從磁盤裏面讀取數據放入流，以packet爲單位來作校驗）

四、客戶端以packet爲單位接收，如今本地緩存，而後寫入目標文件

寫：

一、根namenode通訊請求上傳文件，namenode檢查目標文件是否已存在，父目錄是否存在

二、namenode返回是否能夠上傳

三、client請求第一個 block該傳輸到哪些datanode服務器上

四、namenode返回3個datanode服務器ABC

五、client請求3臺dn中的一臺A上傳數據（本質上是一個RPC調用，創建pipeline），A收到請求會繼續調用B，而後B調用C，將真個pipeline創建完成，逐級返回客戶端

六、client開始往A上傳第一個block（先從磁盤讀取數據放到一個本地內存緩存），以packet爲單位，A收到一個packet就會傳給B，B傳給C；A每傳一個packet會放入一個應答隊列等待應答

七、當一個block傳輸完成以後，client再次請求namenode上傳第二個block的服務器。

二十八 RDD中reduceBykey與groupByKey哪一個性能好，爲何

reduceByKey：reduceByKey會在結果發送至reducer以前會對每一個mapper在本地進行merge，有點相似於在MapReduce中的combiner。這樣作的好處在於，在map端進行一次reduce以後，數據量會大幅度減少，從而減少傳輸，保證reduce端可以更快的進行結果計算。

groupByKey：groupByKey會對每個RDD中的value值進行聚合造成一個序列(Iterator)，此操做發生在reduce端，因此勢必會將全部的數據經過網絡進行傳輸，形成沒必要要的浪費。同時若是數據量十分大，可能還會形成OutOfMemoryError。

經過以上對比能夠發如今進行大量數據的reduce操做時候建議使用reduceByKey。不只能夠提升速度，仍是能夠防止使用groupByKey形成的內存溢出問題。

二十九 spark sql怎麼取數據的差集

好像不支持

spark2.0的瞭解

更簡單：ANSI SQL與更合理的API

速度更快：用Spark做爲編譯器

更智能：Structured Streaming

三十 rdd 怎麼分區寬依賴和窄依賴

寬依賴：父RDD的分區被子RDD的多個分區使用例如 groupByKey、reduceByKey、sortByKey等操做會產生寬依賴，會產生shuffle

窄依賴：父RDD的每一個分區都只被子RDD的一個分區使用例如map、filter、union等操做會產生窄依賴

三十一spark streaming 讀取kafka數據的兩種方式

這兩種方式分別是：

Receiver-base

使用Kafka的高層次Consumer API來實現。receiver從Kafka中獲取的數據都存儲在Spark Executor的內存中，而後Spark Streaming啓動的job會去處理那些數據。然而，在默認的配置下，這種方式可能會由於底層的失敗而丟失數據。若是要啓用高可靠機制，讓數據零丟失，就必須啓用Spark Streaming的預寫日誌機制（Write Ahead Log，WAL）。該機制會同步地將接收到的Kafka數據寫入分佈式文件系統（好比HDFS）上的預寫日誌中。因此，即便底層節點出現了失敗，也能夠使用預寫日誌中的數據進行恢復。

Direct

Spark1.3中引入Direct方式，用來替代掉使用Receiver接收數據，這種方式會週期性地查詢Kafka，得到每一個topic+partition的最新的offset，從而定義每一個batch的offset的範圍。當處理數據的job啓動時，就會使用Kafka的簡單consumer api來獲取Kafka指定offset範圍的數據。

三十二 kafka的數據存在內存仍是磁盤

Kafka最核心的思想是使用磁盤，而不是使用內存，可能全部人都會認爲，內存的速度必定比磁盤快，我也不例外。在看了Kafka的設計思想，查閱了相應資料再加上本身的測試後，發現磁盤的順序讀寫速度和內存持平。

並且Linux對於磁盤的讀寫優化也比較多，包括read-ahead和write-behind，磁盤緩存等。若是在內存作這些操做的時候，一個是JAVA對象的內存開銷很大，另外一個是隨着堆內存數據的增多，JAVA的GC時間會變得很長，使用磁盤操做有如下幾個好處：

磁盤緩存由Linux系統維護，減小了程序員的很多工做。

磁盤順序讀寫速度超過內存隨機讀寫。

JVM的GC效率低，內存佔用大。使用磁盤能夠避免這一問題。

系統冷啓動後，磁盤緩存依然可用。

三十三怎麼解決kafka的數據丟失

producer端：

宏觀上看保證數據的可靠安全性，確定是依據分區數作好數據備份，設立副本數。

broker端：

topic設置多分區，分區自適應所在機器，爲了讓各分區均勻分佈在所在的broker中，分區數要大於broker數。

分區是kafka進行並行讀寫的單位，是提高kafka速度的關鍵。

Consumer端

consumer端丟失消息的情形比較簡單：若是在消息處理完成前就提交了offset，那麼就有可能形成數據的丟失。因爲Kafka consumer默認是自動提交位移的，因此在後臺提交位移前必定要保證消息被正常處理了，所以不建議採用很重的處理邏輯，若是處理耗時很長，則建議把邏輯放到另外一個線程中去作。爲了不數據丟失，現給出兩點建議：

enable.auto.commit=false 關閉自動提交位移

在消息被完整處理以後再手動提交位移

三十四給定a、b兩個文件，各存放50億個url，每一個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url?

假如每一個url大小爲10bytes，那麼能夠估計每一個文件的大小爲50G×64=320G，遠遠大於內存限制的4G，因此不可能將其徹底加載到內存中處理，能夠採用分治的思想來解決。

Step1：遍歷文件a，對每一個url求取hash(url)%1000，而後根據所取得的值將url分別存儲到1000個小文件(記爲a0,a1,...,a999，每一個小文件約300M);

Step2:遍歷文件b，採起和a相同的方式將url分別存儲到1000個小文件(記爲b0,b1,...,b999);

巧妙之處：這樣處理後，全部可能相同的url都被保存在對應的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不對應的小文件不可能有相同的url。而後咱們只要求出這個1000對小文件中相同的url便可。

Step3：求每對小文件ai和bi中相同的url時，能夠把ai的url存儲到hash_set/hash_map中。而後遍歷bi的每一個url，看其是否在剛纔構建的hash_set中，若是是，那麼就是共同的url，存到文件裏面就能夠了。

草圖以下(左邊分解A，右邊分解B，中間求解相同url)：

三十五 .有一個1G大小的一個文件，裏面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M，要求返回頻數最高的100個詞。

Step1：順序讀文件中，對於每一個詞x，取hash(x)%5000，而後按照該值存到5000個小文件(記爲f0,f1,...,f4999)中，這樣每一個文件大概是200k左右，若是其中的有的文件超過了1M大小，還能夠按照相似的方法繼續往下分，直到分解獲得的小文件的大小都不超過1M;

Step2：對每一個小文件，統計每一個文件中出現的詞以及相應的頻率(能夠採用trie樹/hash_map等)，並取出出現頻率最大的100個詞(能夠用含100個結點的最小堆)，並把100詞及相應的頻率存入文件，這樣又獲得了5000個文件;

Step3：把這5000個文件進行歸併(相似與歸併排序);

草圖以下(分割大問題，求解小問題，歸併)：

三十六 .現有海量日誌數據保存在一個超級大的文件中，該文件沒法直接讀入內存，要求從中提取某天出訪問百度次數最多的那個IP。

Step1：從這一天的日誌數據中把訪問百度的IP取出來，逐個寫入到一個大文件中;

Step2：注意到IP是32位的，最多有2^32個IP。一樣能夠採用映射的方法，好比模1000，把整個大文件映射爲1000個小文件;

Step3：找出每一個小文中出現頻率最大的IP(能夠採用hash_map進行頻率統計，而後再找出頻率最大的幾個)及相應的頻率;

Step4：在這1000個最大的IP中，找出那個頻率最大的IP，即爲所求。

草圖以下：

三十七 LVS和HAProxy相比，它的缺點是什麼?

以前，的確是用LVS進行過MySQL集羣的負載均衡，對HAProxy也有過了解，可是將這二者放在眼前進行比較，還真沒試着瞭解過。面試中出現了這麼一題，面試官給予的答案是LVS的配置至關繁瑣，後來查找了相關資料，對這兩種負載均衡方案有了更進一步的瞭解。LVS的負載均衡性能之強悍已經達到硬件負載均衡的F5的百分之60了，而HAproxy的負載均衡和Nginx負載均衡，均爲硬件負載均衡的百分之十左右。因而可知，配置複雜，相應的效果也是顯而易見的。在查找資料的過程當中，試着將LVS的10種調度算法瞭解了一下，看似數量挺多的10種算法其實在不一樣的算法之間，有些只是有着一些細微的差異。在這10種調度算法中，靜態調度算法有四種，動態調度算法有6種。

靜態調度算法：

①RR輪詢調度算法

這種調度算法不考慮服務器的狀態，因此是無狀態的，同時也不考慮每一個服務器的性能，好比我有1-N臺服務器，來N個請求了，第一個請求給第一臺，第二個請求給第二臺，，，第N個請求給第N臺服務器，就醬紫。

②加權輪詢

這種調度算法是考慮到服務器的性能的，你能夠根據不一樣服務器的性能，加上權重進行分配相應的請求。

③基於目的地址的hash散列

這種調度算法和基於源地址的hash散列殊途同歸，都是爲了維持一個session，基於目的地址的hash散列，將記住同一請求的目的地址，將這類請求發往同一臺目的服務器。簡而言之，就是發往這個目的地址的請求都發往同一臺服務器。而基於源地址的hash散列，就是來自同一源地址的請求都發往同一臺服務器。

④基於源地址的hash散列

上述已講，再也不贅述。

動態調度

①最少鏈接調度算法

這種調度算法會記錄響應請求的服務器上所創建的鏈接數，每接收到一個請求會相應的將該服務器的所創建鏈接數加1，同時將新來的請求分配到當前鏈接數最少的那臺機器上。

②加權最少鏈接調度算法

這種調度算法在最少鏈接調度算法的基礎上考慮到服務器的性能。固然，作這樣子的考慮是有其合理性存在的，若是是同一規格的服務器，那麼創建的鏈接數越多，必然越增長其負載，那麼僅僅根據最少鏈接數的調度算法，必然能夠實現合理的負載均衡。但若是，服務器的性能不同呢?好比我有一臺服務器，最多隻能處理10個鏈接，如今創建了3個，還有一臺服務器最多能處理1000條鏈接，如今創建了5個，若是單純地按照上述的最少鏈接調度算法，妥妥的前者嘛，但前者已經創建了百分之三十的鏈接了，然後者連百分之一的鏈接尚未創建，試問，這合理嗎?顯然不合理。因此加上權重，纔算合理。相應的公式也至關簡單：active*256/weight。

③最短時間望調度算法

這種算法，是避免出現上述加權最少鏈接調度算法中的一種特殊狀況，致使即便加上權重，調度器也無差異對待了，舉個栗子：

假設有三臺服務器ABC，其當前所創建的鏈接數相應地爲1,2,3，而權重也是1,2,3。那麼若是按照加權最少鏈接調度算法的話，算出來是這樣子的：

A:1256/1=256

B:2256/2=256

C:3256/3=256

咱們會發現，即使加上權重，A、B、C，通過計算仍是同樣的，這樣子調度器會無差異的在A、B、C中任選一臺，將請求發過去。

而最短時間望將active256/weight的算法改進爲(active+1)256/weight

那麼仍是以前的例子：

A:(1+1)256/1=2/1256=2256

B:(2+1)256/2=3/2256=1.5256

C:(3+1)25六、3=4/3256≈1.3256

顯然C

④永不排隊算法

將請求發給當前鏈接數爲0的服務器上。

⑤基於局部的最少鏈接調度算法

這種調度算法應用於Cache系統，維持一個請求到一臺服務器的映射，其實咱們仔細想一想哈，以前作的一系列最少鏈接相關的調度算法。考慮到的是服務器的狀態與性能，可是一次請求並非單向的，就像有一個從未合做過的大牛，他很閒，你讓他去解決一個以前碰到過的一個問題，未必有找一個以前已經跟你合做過哪怕如今不怎麼閒的臭皮匠效果好哦~，因此基於局部的最少鏈接調度算法，維持的這種映射的做用是，若是來了一個請求，相對應的映射的那臺服務器，沒有超載，ok交給老夥伴完事吧，俺放心，若是那臺服務器不存在，或者是超載的狀態且有其餘服務器工做在一半的負載狀態，則按最少鏈接調度算法在集羣其他的服務器中找一臺將請求分配給它。

⑥基於複製的局部最少鏈接調度算法

這種調度算法一樣應用於cache系統，但它維持的不是到一臺服務器的映射而是到一組服務器的映射，當有新的請求到來，根據最小鏈接原則，從該映射的服務器組中選擇一臺服務器，若是它沒有超載則交給它去處理這個請求，若是發現它超載，則從服務器組外的集羣中，按最少鏈接原則拉一臺機器加入服務器組，而且在服務器組有一段時間未修改後，將最忙的那臺服務器從服務器組中剔除。

三十八 .Sqoop用起來感受怎樣?

說實話，Sqoop在導入數據的速度上確實十分感人，經過進一步瞭解，發現Sqoop1和Sqoop2在架構上仍是有明顯不一樣的，不管是從數據類型上仍是從安全權限，密碼暴露方面，Sqoop2都有了明顯的改進，同時同一些其餘的異構數據同步工具比較,如淘寶的DataX或者Kettle相比，Sqoop不管是從導入數據的效率上仍是從支持插件的豐富程度上，Sqoop仍是至關不錯滴!!

三十九 ZooKeeper的角色以及相應的Zookepper工做原理?

果真，人的記憶力是有衰減曲線的，當面試官拋出這個問題後，前者角色，我只答出了兩種(leader和follower)，後者原理壓根就模糊至忘記了。因此惡補了一下，涉及到Zookeeper的角色大概有以下四種：leader、learner(follower)、observer、client。其中leader主要用來決策和調度，follower和observer的區別僅僅在於後者沒有寫的職能，但都有將client請求提交給leader的職能，而observer的出現是爲了應對當投票壓力過大這種情形的，client就是用來發起請求的。而Zookeeper所用的分佈式一致性算法包括leader的選舉其實和-原始部落的得到神器爲酋長，或者得玉璽者爲皇帝相似，誰id最小，誰爲leader，會根據你所配置的相應的文件在相應的節點機下生成id，而後相應的節點會經過getchildren()這個函數獲取以前設置的節點下生成的id，誰最小，誰是leader。而且若是萬一這個leader掛掉了或者墮落了，則由次小的頂上。並且在配置相應的zookeeper文件的時候回有相似於以下字樣的信息：Server.x=AAAA:BBBB:CCCC。其中的x即爲你的節點號哈，AAAA對應你所部屬zookeeper所在的ip地址，BBBB爲接收client請求的端口，CCCC爲從新選舉leader端口。

四十 .HBase的Insert與Update的區別?

這個題目是就着最近的一次項目問的，當時實現的與hbase交互的三個方法分別爲insert、delete、update。因爲那個項目是對接的一個項目，對接的小夥伴和我協商了下，不將update合併爲insert，若是合併的話，按那個項目自己，其實經過insert執行overwrite至關於間接地Update，本質上，或者說在展示上是沒什麼區別的包括所調用的put。但那僅僅是就着那個項目的程序而言，若是基於HBaseshell層面。將同一rowkey的數據插入HBase，其實雖然展示一條，可是相應的timestamp是不同的，並且最大的版本數能夠經過配置文件進行相應地設置。

四十一請簡述大數據的結果展示方式。

1)報表形式

基於數據挖掘得出的數據報表，包括數據表格、矩陣、圖形和自定義格式的報表等，使用方便、設計靈活。

2)圖形化展示

提供曲線、餅圖、堆積圖、儀表盤、魚骨分析圖等圖形形式宏觀展示模型數據的分佈狀況，從而便於進行決策。

3)KPI展示

提供表格式績效一覽表並可自定義績效查看方式，如數據表格或走勢圖，企業管理者可根據可度量的目標快速評估進度。

4)查詢展示

按數據查詢條件和查詢內容，以數據表格來彙總查詢結果，提供明細查詢功能，並可在查詢的數據表格基礎上進行上鑽、下鑽、旋轉等操做。

四十二例舉身邊的大數據。

i.QQ，微博等社交軟件產生的數據

ii.天貓，京東等電子商務產生的數據

iii.互聯網上的各類數據

四十三簡述大數據的數據管理方式。

答：對於圖像、視頻、URL、地理位置等類型多樣的數據，難以用傳統的結構化方式描述，所以須要使用由多維表組成的面向列存儲的數據管理系統來組織和管理數據。也就是說，將數據按行排序，按列存儲，將相同字段的數據做爲一個列族來聚合存儲。不一樣的列族對應數據的不一樣屬性，這些屬性能夠根據需求動態增長，經過這樣的分佈式實時列式數據庫對數據統一進行結構化存儲和管理，避免了傳統數據存儲方式下的關聯查詢。

四十四什麼是大數據?

答：大數據是指沒法在允許的時間內用常規軟件工具對其內容進行抓取、管理和處理的數據。

四十五海量日誌數據，提取出某日訪問百度次數最多的那個IP。

首先是這一天，而且是訪問百度的日誌中的IP取出來，逐個寫入到一個大文件中。注意到IP是32位的，最多有個2^32個IP。一樣能夠採用映射的方法，好比模1000，把整個大文件映射爲1000個小文件，再找出每一個小文中出現頻率最大的IP(能夠採用hash_map進行頻率統計，而後再找出頻率最大的幾個)及相應的頻率。而後再在這1000個最大的IP中，找出那個頻率最大的IP，即爲所求。

或者以下闡述(雪域之鷹)：

算法思想：分而治之+Hash

1)IP地址最多有2^32=4G種取值狀況，因此不能徹底加載到內存中處理;

2)能夠考慮採用「分而治之」的思想，按照IP地址的Hash(IP)%1024值，把海量IP日誌分別存儲到1024個小文件中。這樣，每一個小文件最多包含4MB個IP地址;

3)對於每個小文件，能夠構建一個IP爲key，出現次數爲value的Hashmap，同時記錄當前出現次數最多的那個IP地址;

4)能夠獲得1024個小文件中的出現次數最多的IP，再依據常規的排序算法獲得整體上出現次數最多的IP;

四十六 .搜索引擎會經過日誌文件把用戶每次檢索使用的全部檢索串都記錄下來，每一個查詢串的長度爲1-255字節。

假設目前有一千萬個記錄(這些查詢串的重複度比較高，雖然總數是1千萬，但若是除去重複後，不超過3百萬個。一個查詢串的重複度越高，說明查詢它的用戶越多，也就是越熱門。)，請你統計最熱門的10個查詢串，要求使用的內存不能超過1G。

典型的TopK算法，仍是在這篇文章裏頭有所闡述，詳情請參見：11、從頭至尾完全解析Hash表算法。

文中，給出的最終算法是：

第一步、先對這批海量數據預處理，在O(N)的時間內用Hash表完成統計(以前寫成了排序，特此訂正。July、2011.04.27);

第二步、藉助堆這個數據結構，找出TopK，時間複雜度爲N‘logK。

即，藉助堆結構，咱們能夠在log量級的時間內查找和調整/移動。所以，維護一個K(該題目中是10)大小的小根堆，而後遍歷300萬的Query，分別和根元素進行對比因此，咱們最終的時間複雜度是：O(N)+N’*O(logK)，(N爲1000萬，N’爲300萬)。ok，更多，詳情，請參考原文。

或者：採用trie樹，關鍵字域存該查詢串出現的次數，沒有出現爲0。最後用10個元素的最小推來對出現頻率進行排序。

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

方案：順序讀文件中，對於每一個詞x，取hash(x)%5000，而後按照該值存到5000個小文件(記爲x0,x1,…x4999)中。這樣每一個文件大概是200k左右。

若是其中的有的文件超過了1M大小，還能夠按照相似的方法繼續往下分，直到分解獲得的小文件的大小都不超過1M。

對每一個小文件，統計每一個文件中出現的詞以及相應的頻率(能夠採用trie樹/hash_map等)，並取出出現頻率最大的100個詞(能夠用含100個結點的最小堆)，並把100個詞及相應的頻率存入文件，這樣又獲得了5000個文件。下一步就是把這5000個文件進行歸併(相似與歸併排序)的過程了。

四十八 .有10個文件，每一個文件1G，每一個文件的每一行存放的都是用戶的query，每一個文件的query均可能重複。要求你按照query的頻度排序。

仍是典型的TOPK算法，解決方案以下：

方案1：

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

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

對這10個文件進行歸併排序(內排序與外排序相結合)。

方案2：

通常query的總量是有限的，只是重複的次數比較多而已，可能對於全部的query，一次性就能夠加入到內存了。這樣，咱們就能夠採用trie樹/hash_map等直接來統計每一個query出現的次數，而後按出現次數作快速/堆/歸併排序就能夠了。

方案3：

與方案1相似，但在作完hash，分紅多個文件後，能夠交給多個文件來處理，採用分佈式的架構來處理(好比MapReduce)，最後再進行合併。

四十九 .給定a、b兩個文件，各存放50億個url，每一個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url?

方案1：能夠估計每一個文件安的大小爲5G×64=320G，遠遠大於內存限制的4G。因此不可能將其徹底加載到內存中處理。考慮採起分而治之的方法。

遍歷文件a，對每一個url求取hash(url)%1000，而後根據所取得的值將url分別存儲到1000個小文件(記爲a0,a1,…,a999)中。這樣每一個小文件的大約爲300M。

遍歷文件b，採起和a相同的方式將url分別存儲到1000小文件(記爲b0,b1,…,b999)。這樣處理後，全部可能相同的url都在對應的小文件(a0vsb0,a1vsb1,…,a999vsb999)中，不對應的小文件不可能有相同的url。而後咱們只要求出1000對小文件中相同的url便可。

求每對小文件中相同的url時，能夠把其中一個小文件的url存儲到hash_set中。而後遍歷另外一個小文件的每一個url，看其是否在剛纔構建的hash_set中，若是是，那麼就是共同的url，存到文件裏面就能夠了。

方案2：若是容許有必定的錯誤率，能夠使用Bloomfilter，4G內存大概能夠表示340億bit。將其中一個文件中的url使用Bloomfilter映射爲這340億bit，而後挨個讀取另一個文件的url，檢查是否與Bloomfilter，若是是，那麼該url應該是共同的url(注意會有必定的錯誤率)。

Bloomfilter往後會在本BLOG內詳細闡述。

五十 .在2.5億個整數中找出不重複的整數，注，內存不足以容納這2.5億個整數。

方案1：採用2-Bitmap(每一個數分配2bit，00表示不存在，01表示出現一次，10表示屢次，11無心義)進行，共需內存2^32*2bit=1GB內存，還能夠接受。而後掃描這2.5億個整數，查看Bitmap中相對應位，若是是00變01，01變10，10保持不變。所描完過後，查看bitmap，把對應位是01的整數輸出便可。

方案2：也可採用與第1題相似的方法，進行劃分小文件的方法。而後在小文件中找出不重複的整數，並排序。而後再進行歸併，注意去除重複的元素。

五十一 .騰訊面試題：給40億個不重複的unsignedint的整數，沒排過序的，而後再給一個數，如何快速判斷這個數是否在那40億個數當中?

與上第6題相似，個人第一反應時快速排序+二分查找。如下是其它更好的方法：

方案1：oo，申請512M的內存，一個bit位表明一個unsignedint值。讀入40億個數，設置相應的bit位，讀入要查詢的數，查看相應bit位是否爲1，爲1表示存在，爲0表示不存在。

dizengrong：

方案2：這個問題在《編程珠璣》裏有很好的描述，你們能夠參考下面的思路，探討一下：

又由於2^32爲40億多，因此給定一個數可能在，也可能不在其中;

這裏咱們把40億個數中的每個用32位的二進制來表示

假設這40億個數開始放在一個文件中。

而後將這40億個數分紅兩類:

1.最高位爲0

2.最高位爲1

並將這兩類分別寫入到兩個文件中，其中一個文件中數的個數<=20億，而另外一個>=20億(這至關於折半了);

與要查找的數的最高位比較並接着進入相應的文件再查找

再而後把這個文件爲又分紅兩類:

1.次最高位爲0

2.次最高位爲1

並將這兩類分別寫入到兩個文件中，其中一個文件中數的個數<=10億，而另外一個>=10億(這至關於折半了);

與要查找的數的次最高位比較並接着進入相應的文件再查找。

…….

以此類推，就能夠找到了,並且時間複雜度爲O(logn)，方案2完。

附：這裏，再簡單介紹下，位圖方法：

使用位圖法判斷整形數組是否存在重複

判斷集合中存在重複是常見編程任務之一，當集合中數據量比較大時咱們一般但願少進行幾回掃描，這時雙重循環法就不可取了。

位圖法比較適合於這種狀況，它的作法是按照集合中最大元素max建立一個長度爲max+1的新數組，而後再次掃描原數組，遇到幾就給新數組的第幾位置上1，如遇到5就給新數組的第六個元素置1，這樣下次再遇到5想置位時發現新數組的第六個元素已是1了，這說明此次的數據確定和之前的數據存在着重複。這種給新數組初始化時置零其後置一的作法相似於位圖的處理方法故稱位圖法。它的運算次數最壞的狀況爲2N。若是已知數組的最大值即能事先給新數組定長的話效率還能提升一倍。

五十二.怎麼在海量數據中找出重複次數最多的一個?

方案1：先作hash，而後求模映射爲小文件，求出每一個小文件中重複次數最多的一個，並記錄重複次數。而後找出上一步求出的數據中重複次數最多的一個就是所求(具體參考前面的題)。

五十三上千萬或上億數據(有重複)，統計其中出現次數最多的錢N個數據。

方案1：上千萬或上億的數據，如今的機器的內存應該能存下。因此考慮採用hash_map/搜索二叉樹/紅黑樹等來進行統計次數。而後就是取出前N個出現次數最多的數據了，能夠用第2題提到的堆機制完成。

五十四一個文本文件，大約有一萬行，每行一個詞，要求統計出其中最頻繁出現的前10個詞，請給出思想，給出時間複雜度分析。

方案1：這題是考慮時間效率。用trie樹統計每一個詞出現的次數，時間複雜度是O(nle)(le表示單詞的平準長度)。而後是找出出現最頻繁的前10個詞，能夠用堆來實現，前面的題中已經講到了，時間複雜度是O(nlg10)。因此總的時間複雜度，是O(nle)與O(nlg10)中較大的哪個。

五十五100w個數中找出最大的100個數。

方案1：在前面的題中，咱們已經提到了，用一個含100個元素的最小堆完成。複雜度爲O(100w*lg100)。

方案2：採用快速排序的思想，每次分割以後只考慮比軸大的一部分，知道比軸大的一部分在比100多的時候，採用傳統排序算法排序，取前100個。複雜度爲O(100w*100)。

方案3：採用局部淘汰法。選取前100個元素，並排序，記爲序列L。而後一次掃描剩餘的元素x，與排好序的100個元素中最小的元素比，若是比這個最小的要大，那麼把這個最小的元素刪除，並把x利用插入排序的思想，插入到序列L中。依次循環，知道掃描了全部的元素。複雜度爲O(100w*100)。

五十六十個海量數據處理方法大總結

ok，看了上面這麼多的面試題，是否有點頭暈。是的，須要一個總結。接下來，本文將簡單總結下一些處理海量數據問題的常見方法，而往後，本BLOG內會具體闡述這些方法。

1、Bloomfilter

適用範圍：能夠用來實現數據字典，進行數據的判重，或者集合求交集

五十七基本原理及要點：

對於原理來講很簡單，位數組+k個獨立hash函數。將hash函數對應的值的位數組置1，查找時若是發現全部hash函數對應位都是1說明存在，很明顯這個過程並不保證查找的結果是100%正確的。同時也不支持刪除一個已經插入的關鍵字，由於該關鍵字對應的位會牽動到其餘的關鍵字。因此一個簡單的改進就是countingBloomfilter，用一個counter數組代替位數組，就能夠支持刪除了。

還有一個比較重要的問題，如何根據輸入元素個數n，肯定位數組m的大小及hash函數個數。當hash函數個數k=(ln2)(m/n)時錯誤率最小。在錯誤率不大於E的狀況下，m至少要等於nlg(1/E)才能表示任意n個元素的集合。但m還應該更大些，由於還要保證bit數組裏至少一半爲0，則m應該>=nlg(1/E)*lge大概就是nlg(1/E)1.44倍(lg表示以2爲底的對數)。

舉個例子咱們假設錯誤率爲0.01，則此時m應大概是n的13倍。這樣k大概是8個。

注意這裏m與n的單位不一樣，m是bit爲單位，而n則是以元素個數爲單位(準確的說是不一樣元素的個數)。一般單個元素的長度都是有不少bit的。因此使用bloomfilter內存上一般都是節省的。

擴展：

Bloomfilter將集合中的元素映射到位數組中，用k(k爲哈希函數個數)個映射位是否全1表示元素在不在這個集合中。Countingbloomfilter(CBF)將位數組中的每一位擴展爲一個counter，從而支持了元素的刪除操做。SpectralBloomFilter(SBF)將其與集合元素的出現次數關聯。SBF採用counter中的最小值來近似表示元素的出現頻率。

問題實例：給你A,B兩個文件，各存放50億條URL，每條URL佔用64字節，內存限制是4G，讓你找出A,B文件共同的URL。若是是三個乃至n個文件呢?

根據這個問題咱們來計算下內存的佔用，4G=2^32大概是40億*8大概是340億，n=50億，若是按出錯率0.01算須要的大概是650億個bit。如今可用的是340億，相差並很少，這樣可能會使出錯率上升些。另外若是這些urlip是一一對應的，就能夠轉換成ip，則大大簡單了。

五十八 Hashing

適用範圍：快速查找，刪除的基本數據結構，一般須要總數據量能夠放入內存

基本原理及要點：

hash函數選擇，針對字符串，整數，排列，具體相應的hash方法。

碰撞處理，一種是openhashing，也稱爲拉鍊法;另外一種就是closedhashing，也稱開地址法，openedaddressing。

擴展：

d-lefthashing中的d是多個的意思，咱們先簡化這個問題，看一看2-lefthashing。2-lefthashing指的是將一個哈希表分紅長度相等的兩半，分別叫作T1和T2，給T1和T2分別配備一個哈希函數，h1和h2。在存儲一個新的key時，同時用兩個哈希函數進行計算，得出兩個地址h1[key]和h2[key]。這時須要檢查T1中的h1[key]位置和T2中的h2[key]位置，哪個位置已經存儲的(有碰撞的)key比較多，而後將新key存儲在負載少的位置。若是兩邊同樣多，好比兩個位置都爲空或者都存儲了一個key，就把新key存儲在左邊的T1子表中，2-left也由此而來。在查找一個key時，必須進行兩次hash，同時查找兩個位置。

問題實例：

1).海量日誌數據，提取出某日訪問百度次數最多的那個IP。

IP的數目仍是有限的，最多2^32個，因此能夠考慮使用hash將ip直接存入內存，而後進行統計。

五十九 bit-map

適用範圍：可進行數據的快速查找，判重，刪除，通常來講數據範圍是int的10倍如下

基本原理及要點：使用bit數組來表示某些元素是否存在，好比8位電話號碼

擴展：bloomfilter能夠看作是對bit-map的擴展

問題實例：

1)已知某個文件內包含一些電話號碼，每一個號碼爲8位數字，統計不一樣號碼的個數。

8位最多99999999，大概須要99m個bit，大概10幾m字節的內存便可。

2)2.5億個整數中找出不重複的整數的個數，內存空間不足以容納這2.5億個整數。

將bit-map擴展一下，用2bit表示一個數便可，0表示未出現，1表示出現一次，2表示出現2次及以上。或者咱們不用2bit來進行表示，咱們用兩個bit-map便可模擬實現這個2bit-map。

六十堆

適用範圍：海量數據前n大，而且n比較小，堆能夠放入內存

基本原理及要點：最大堆求前n小，最小堆求前n大。方法，好比求前n小，咱們比較當前元素與最大堆裏的最大元素，若是它小於最大元素，則應該替換那個最大元素。這樣最後獲得的n個元素就是最小的n個。適合大數據量，求前n小，n的大小比較小的狀況，這樣能夠掃描一遍便可獲得全部的前n元素，效率很高。

擴展：雙堆，一個最大堆與一個最小堆結合，能夠用來維護中位數。

問題實例：

1)100w個數中找最大的前100個數。

用一個100個元素大小的最小堆便可。

六十一雙層桶劃分—-其實本質上就是【分而治之】的思想，重在「分」的技巧上!

適用範圍：第k大，中位數，不重複或重複的數字

基本原理及要點：由於元素範圍很大，不能利用直接尋址表，因此經過屢次劃分，逐步肯定範圍，而後最後在一個能夠接受的範圍內進行。能夠經過屢次縮小，雙層只是一個例子。

擴展：

問題實例：

1).2.5億個整數中找出不重複的整數的個數，內存空間不足以容納這2.5億個整數。

有點像鴿巢原理，整數個數爲2^32,也就是，咱們能夠將這2^32個數，劃分爲2^8個區域(好比用單個文件表明一個區域)，而後將數據分離到不一樣的區域，而後不一樣的區域在利用bitmap就能夠直接解決了。也就是說只要有足夠的磁盤空間，就能夠很方便的解決。

2).5億個int找它們的中位數。

這個例子比上面那個更明顯。首先咱們將int劃分爲2^16個區域，而後讀取數據統計落到各個區域裏的數的個數，以後咱們根據統計結果就能夠判斷中位數落到那個區域，同時知道這個區域中的第幾大數恰好是中位數。而後第二次掃描咱們只統計落在這個區域中的那些數就能夠了。

實際上，若是不是int是int64，咱們能夠通過3次這樣的劃分便可下降到能夠接受的程度。便可以先將int64分紅2^24個區域，而後肯定區域的第幾大數，在將該區域分紅2^20個子區域，而後肯定是子區域的第幾大數，而後子區域裏的數的個數只有2^20，就能夠直接利用directaddrtable進行統計了。

六十二數據庫索引

適用範圍：大數據量的增刪改查

基本原理及要點：利用數據的設計實現方法，對海量數據的增刪改查進行處理。

六十三倒排索引(Invertedindex)

適用範圍：搜索引擎，關鍵字查詢

基本原理及要點：爲什麼叫倒排索引?一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。

以英文爲例，下面是要被索引的文本：

T0=「itiswhatitis」

T1=「whatisit」

T2=「itisabanana」

咱們就能獲得下面的反向文件索引：

「a」:{2}

「banana」:{2}

「is」:{0,1,2}

「it」:{0,1,2}

「what」:{0,1}

檢索的條件」what」,」is」和」it」將對應集合的交集。

正向索引開發出來用來存儲每一個文檔的單詞的列表。正向索引的查詢每每知足每一個文檔有序頻繁的全文查詢和每一個單詞在校驗文檔中的驗證這樣的查詢。在正向索引中，文檔佔據了中心的位置，每一個文檔指向了一個它所包含的索引項的序列。也就是說文檔指向了它包含的那些單詞，而反向索引則是單詞指向了包含它的文檔，很容易看到這個反向的關係。

擴展：

問題實例：文檔檢索系統，查詢那些文件包含了某單詞，好比常見的學術論文的關鍵字搜索。

六十四外排序

適用範圍：大數據的排序，去重

基本原理及要點：外排序的歸併方法，置換選擇敗者樹原理，最優歸併樹

擴展：

問題實例：

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

這個數據具備很明顯的特色，詞的大小爲16個字節，可是內存只有1m作hash有些不夠，因此能夠用來排序。內存能夠當輸入緩衝區使用。

六十五trie樹

適用範圍：數據量大，重複多，可是數據種類小能夠放入內存

基本原理及要點：實現方式，節點孩子的表示方式

擴展：壓縮實現。

問題實例：

1).有10個文件，每一個文件1G，每一個文件的每一行都存放的是用戶的query，每一個文件的query均可能重複。要你按照query的頻度排序。

2).1000萬字符串，其中有些是相同的(重複),須要把重複的所有去掉，保留沒有重複的字符串。請問怎麼設計和實現?

3).尋找熱門查詢：查詢串的重複度比較高，雖然總數是1千萬，但若是除去重複後，不超過3百萬個，每一個不超過255字節。

六十六分佈式處理mapreduce

適用範圍：數據量大，可是數據種類小能夠放入內存

基本原理及要點：將數據交給不一樣的機器去處理，數據劃分，結果歸約。

擴展：

問題實例：

1).ThecanonicalexampleapplicationofMapReduceisaprocesstocounttheappearancesof

eachdifferentwordinasetofdocuments:

2).海量數據分佈在100臺電腦中，想個辦法高效統計出這批數據的TOP10。

3).一共有N個機器，每一個機器上有N個數。每一個機器最多存O(N)個數並對它們操做。如何找到N^2個數的中數(median)?

六十七經典問題分析

上千萬or億數據(有重複)，統計其中出現次數最多的前N個數據,分兩種狀況：可一次讀入內存，不可一次讀入。

可用思路：trie樹+堆，數據庫索引，劃分子集分別統計，hash，分佈式計算，近似統計，外排序

所謂的是否能一次讀入內存，實際上應該指去除重複後的數據量。若是去重後數據能夠放入內存，咱們能夠爲數據創建字典，好比經過map，hashmap，trie，而後直接進行統計便可。固然在更新每條數據的出現次數的時候，咱們能夠利用一個堆來維護出現次數最多的前N個數據，固然這樣致使維護次數增長，不如徹底統計後在求前N大效率高。

若是數據沒法放入內存。一方面咱們能夠考慮上面的字典方法可否被改進以適應這種情形，能夠作的改變就是將字典存放到硬盤上，而不是內存，這能夠參考數據庫的存儲方法。

固然還有更好的方法，就是能夠採用分佈式計算，基本上就是map-reduce過程，首先能夠根據數據值或者把數據hash(md5)後的值，將數據按照範圍劃分到不一樣的機子，最好可讓數據劃分後能夠一次讀入內存，這樣不一樣的機子負責處理各類的數值範圍，實際上就是map。獲得結果後，各個機子只需拿出各自的出現次數最多的前N個數據，而後彙總，選出全部的數據中出現次數最多的前N個數據，這實際上就是reduce過程。

實際上可能想直接將數據均分到不一樣的機子上進行處理，這樣是沒法獲得正確的解的。由於一個數據可能被均分到不一樣的機子上，而另外一個則可能徹底彙集到一個機子上，同時還可能存在具備相同數目的數據。好比咱們要找出現次數最多的前100個，咱們將1000萬的數據分佈到10臺機器上，找到每臺出現次數最多的前100個，歸併以後這樣不能保證找到真正的第100個，由於好比出現次數最多的第100個可能有1萬個，可是它被分到了10臺機子，這樣在每臺上只有1千個，假設這些機子排名在1000個以前的那些都是單獨分佈在一臺機子上的，好比有1001個，這樣原本具備1萬個的這個就會被淘汰，即便咱們讓每臺機子選出出現次數最多的1000個再歸併，仍然會出錯，由於可能存在大量個數爲1001個的發生彙集。所以不能將數據隨便均分到不一樣機子上，而是要根據hash後的值將它們映射到不一樣的機子上處理，讓不一樣的機器處理一個數值範圍。

而外排序的方法會消耗大量的IO，效率不會很高。而上面的分佈式方法，也能夠用於單機版本，也就是將總的數據根據值的範圍，劃分紅多個不一樣的子文件，而後逐個處理。處理完畢以後再對這些單詞的及其出現頻率進行一個歸併。實際上就能夠利用一個外排序的歸併過程。

另外還能夠考慮近似計算，也就是咱們能夠經過結合天然語言屬性，只將那些真正實際中出現最多的那些詞做爲一個字典，使得這個規模能夠放入內存。

六十八使用mr，spark,sparksql編寫wordcount程序

【Spark版本】

valconf=newSparkConf().setAppName("wd").setMaster("local[1]")

valsc=newSparkContext(conf,2)

//加載

vallines=sc.textFile("tructField("name",DataTypes.StringType,true)")

valparis=lines.flatMap(line=>line.split("^A"))

valwords=paris.map((_,1))

valresult=words.reduceByKey(+).sortBy(x=>x._1,false)

//打印

result.foreach(

wds=>{

println("單詞："+wds._1+"個數："+wds._2)

}

)

sc.stop()

【sparksql版本】

valconf=newSparkConf().setAppName("sqlWd").setMaster("local[1]")

valsc=newSparkContext(conf)

valsqlContext=newSQLContext(sc)

//加載

vallines=sqlContext.textFile("E:idea15createRecommederdatawords.txt")

valwords=lines.flatMap(x=>x.split("")).map(y=>Row(y))

valstructType=StructType(Array(StructField("name",DataTypes.StringType,true)))

valdf=sqlContext.createDataFrame(rows,structType)

df.registerTempTable("t_word_count")

sqlContext.udf.register("num_word",(name:String)=>1)

sqlContext.sql("selectname,num_word(name)fromt_word_count").groupBy(df.col("name")).count().show()

sc.stop()

六十九 2hive的使用，內外部表的區別，分區做用，UDF和Hive優化

(1)hive使用：倉庫、工具

(2)hive內外部表：內部表數據永久刪除，外部表數據刪除後、其餘人依然能夠訪問

(3)分區做用：防止數據傾斜

(4)UDF函數：用戶自定義的函數(主要解決格式，計算問題)，須要繼承UDF類

java代碼實現

classTestUDFHiveextendsUDF{

publicStringevalute(Stringstr){

try{

return"hello"+str

}catch(Exceptione){

returnstr+"error"

}

(5)Hive優化：看作mapreduce處理

a排序優化：sortby效率高於orderby

b分區：使用靜態分區(statu_date="20160516",location="beijin")，每一個分區對應hdfs上的一個目錄

c減小job和task數量：使用表連接操做

d解決groupby數據傾斜問題：設置hive.groupby.skewindata=true，那麼hive會自動負載均衡

e小文件合併成大文件：錶鏈接操做

f使用UDF或UDAF函數：hive中UDTF編寫和使用(轉) - ggjucheng - 博客園

3Hbase的rk設計，Hbase優化

aowkey:hbase三維存儲中的關鍵(rowkey：行鍵，columnKey(family+quilaty)：列鍵，timestamp：時間戳)

owkey字典排序、越短越好

使用id+時間：9527+20160517使用hash散列：dsakjkdfuwdsf+9527+20160518

應用中，rowkey通常10~100bytes,8字節的整數倍，有利於提升操做系統性能

bHbase優化

分區：RegionSplit()方法NUMREGIONS=9

column不超過3個

硬盤配置，便於regionServer管理和數據備份及恢復

分配合適的內存給regionserver

其餘：

hbase查詢

(1)get

(2)scan

使用startRow和endRow限制

4Linux經常使用操做

aawk：

awk-F:BEGIN{print"nameip"}{print$1$7}END{print"結束"}/etc/passwd

last|head-5|awkBEGIN{print"nameip"}{print$1$3}END{print"結束了"}

bsed

七十 5java線程2種方式實現、設計模式、鏈表操做、排序

(1)2種線程實現

aThread類繼承

TestCLth=newTestCL()//類繼承Thread

th.start()

b實現Runnable接口

Threadth=newThread(newRunnable(){

publicvoidrun(){

//實現

}

})

th.start()

(2)設計模式，分爲4類

a建立模式：如工廠模式、單例模式

b結構模式：代理模式

c行爲模式：觀察者模式

d線程池模式

6【最熟悉的一個項目簡介、架構圖、使用的技術、你負責哪塊】

7cdh集羣監控

(1)數據庫監控(2)主機監控(3)服務監控(4)活動監控

8計算機網絡工做原理

將分散的機器經過數據通訊原理鏈接起來，實現共享!

9hadoop生態系統

hdfsmapreducehivehbasezookeeperlume

hdfs原理及各個模塊的功能mapreduce原理mapreduce優化數據傾斜

11系統維護：hadoop升級datanode節點

12【講解項目要點：數據量、多少人、分工、運行時間、項目使用機器、算法、技術】

13【學會向對方提問】

14jvm運行機制及內存原理

運行：

I加載.class文件

II管理而且分配內存

III垃圾回收

內存原理：

IJVM裝載環境和配置

II裝載JVM.dll並初始化JVM.dll

IV處理class類

15hdfs、yarn參數調優

mapreduce.job.jvm.num.tasks

默認爲1，設置爲-1，重用jvm

16Hbase、Hive、impala、zookeeper、Storm、spark原理和使用方法、使用其架構圖講解

七11、如何爲一個hadoop任務設置mappers的數量

答案：

使用job.setNumMapTask(intn)手動分割，這是不靠譜的

官方文檔：「Note:Thisisonlyahinttotheframework」說明這個方法只是提示做用，不起決定性做用

實際上要用公式計算：

Max(min.split，min(max.split，block))就設置分片的最大最下值computeSplitSize()設置

七十二有可能使hadoop任務輸出到多個目錄中麼?若是能夠，怎麼作?

答案：在1.X版本後使用MultipleOutputs.java類實現

源碼：

MultipleOutputs.addNamedOutput(conf,"text2",TextOutputFormat.class,Long.class,String.class);

MultipleOutputs.addNamedOutput(conf,"text3",TextOutputFormat.class,Long.class,String.class);

發音：Multiple['m?lt?pl]--》許多的

七十三如何爲一個hadoop任務設置要建立的reducer的數量

答案：job.setNumReduceTask(intn)

或者調整hdfs-site.xml中的mapred.tasktracker.reduce.tasks.maximum默認參數值

七十四在hadoop中定義的主要公用InputFormats中，哪個是默認值：

(A)TextInputFormat

(B)KeyValueInputFormat

(C)SequenceFileInputFormat

答案：A

七十五兩個類TextInputFormat和KeyValueTextInputFormat的區別?

答案：

?FileInputFormat的子類：

TextInputFormat(默認類型，鍵是LongWritable類型，值爲Text類型，key爲當前行在文件中的偏移量，value爲當前行自己);

?KeyValueTextInputFormat(適合文件自帶key，value的狀況，只要指定分隔符便可，比較實用，默認是分割);

源碼：

StringsepStr=job.get("mapreduce.input.keyvaluelinerecordreader.key.value.separator","");

注意：在自定義輸入格式時，繼承FileInputFormat父類

七十六在一個運行的hadoop任務中，什麼是InputSpilt?

答案：InputSplit是MapReduce對文件進行處理和運算的輸入單位，只是一個邏輯概念，每一個InputSplit並無對文件實際的切割，只是記錄了要處理的數據的位置(包括文件的path和hosts)和長度(由start和length決定)，默認狀況下與block同樣大。

拓展：須要在定義InputSplit後，展開講解mapreduce的原理

七十七 Hadoop框架中，文件拆分是怎麼被調用的?

答案：JobTracker，建立一個InputFormat的實例，調用它的getSplits()方法，把輸入目錄的文件拆分紅FileSplist做爲Mappertask的輸入，生成Mappertask加入Queue。

源碼中體現了拆分的數量

longgoalSize=totalSize/(numSplits==0?1:numSplits);

longminSize=Math.max(job.getLong(org.apache.hadoop.mapreduce.lib.input.

FileInputFormat.SPLIT_MINSIZE,1),minSplitSize);//minSplitSize默認是1

七十八分別舉例什麼狀況下使用combiner,什麼狀況下不會使用?

答案：Combiner適用於對記錄彙總的場景(如求和)，可是，求平均數的場景就不能使用Combiner了

七十9、Hadoop中job和Tasks之間的區別是什麼?

答案：

job是工做的入口，負責控制、追蹤、管理任務，也是一個進程

包含maptask和reducetask

Tasks是map和reduce裏面的步驟，主要用於完成任務，也是線程

八十 Hadoop中經過拆分任務到多個節點運行來實現並行計算，可是某些節點運行較慢會拖慢整個任務的運行，hadoop採用何種機制應對這種狀況?

答案：結果查看監控日誌，得知產生這種現象的緣由是數據傾斜問題

解決：

(1)調整拆分mapper的數量(partition數量)

(2)增長jvm

(3)適當地將reduce的數量變大

八十一流API中的什麼特性帶來能夠使mapreduce任務能夠以不一樣語言(如perlubyawk等)實現的靈活性?

答案：用可執行文件做爲Mapper和Reducer，接受的都是標準輸入，輸出的都是標準輸出

八十二參考下面的M/R系統的場景：

--HDFS塊大小爲64MB

--輸入類型爲FileInputFormat

--有3個文件的大小分別是：64k65MB127MB

Hadoop框架會把這些文件拆分爲多少塊?

答案：

64k------->一個block

65MB---->兩個文件：64MB是一個block，1MB是一個block

127MB--->兩個文件：64MB是一個block,63MB是一個block

八十三 Hadoop中的RecordReader的做用是什麼?

答案：屬於split和mapper之間的一個過程

將inputsplit輸出的行爲一個轉換記錄，成爲key-value的記錄形式提供給mapper

八十四 Map階段結束後，Hadoop框架會處理：Partitioning,shuffle和sort,在這個階段都會發生了什麼?

答案：

MR一共有四個階段，splitmapshuffreduce在執行完map以後，能夠對map的輸出結果進行分區，

分區：這塊分片肯定到哪一個reduce去計算(彙總)

排序：在每一個分區中進行排序，默認是按照字典順序。

Group：在排序以後進行分組

八十五若是沒有定義partitioner,那麼數據在被送達reducer前是如何被分區的?

答案：

Partitioner是在map函數執行context.write()時被調用。

用戶能夠經過實現自定義的?Partitioner來控制哪一個key被分配給哪一個?Reducer。

查看源碼知道：

若是沒有定義partitioner，那麼會走默認的分區Hashpartitioner

publicclassHashPartitionerextendsPartitioner{

/**Use{@linkObject#hashCode()}topartition.*/

publicintgetPartition(Kkey,Vvalue,intnumReduceTasks){

return(key.hashCode()&Integer.MAX_VALUE)%numReduceTasks;

}

八十六什麼是Combiner?

答案：這是一個hadoop優化性能的步驟，它發生在map與reduce之間

目的：解決了數據傾斜的問題，減輕網絡壓力，實際上時減小了maper的輸出

源碼信息以下：

publicvoidreduce(Textkey,Iteratorvalues,

OutputCollectoroutput,Reporterreporter)

throwsIOException{

LongWritablemaxValue=null;

while(values.hasNext()){

LongWritablevalue=values.next();

if(maxValue==null){

maxValue=value;

}elseif(value.compareTo(maxValue)>0){

maxValue=value;

}

output.collect(key,maxValue);

}

在collect實現類中，有這樣一段方法

publicsynchronizedvoidcollect(Kkey,Vvalue)

throwsIOException{

outCounter.increment(1);

writer.append(key,value);

if((outCounter.getValue()%progressBar)==0){

progressable.progress();

八十七下面哪一個程序負責HDFS數據存儲。答案C datanode

a)NameNode

b)Jobtracker

c)Datanode

d)secondaryNameNode

e)tasktracker

八十八HDfS中的block默認保存幾份?答案A默認3分

a)3份

b)2份

c)1份

d)不肯定

八十九下列哪一個程序一般與NameNode在一個節點啓動?答案D

a)SecondaryNameNode

b)DataNode

c)TaskTracker

d)Jobtracke

此題分析：

hadoop的集羣是基於master/slave模式，namenode和jobtracker屬於master，datanode和tasktracker屬於slave，master只有一個，而slave有多個SecondaryNameNode內存需求和NameNode在一個數量級上，因此一般secondary NameNode(運行在單獨的物理機器上)和NameNode運行在不一樣的機器上。

JobTracker和TaskTracker

JobTracker對應於NameNode

TaskTracker對應於DataNode

DataNode和NameNode是針對數據存放來而言的

JobTracker和TaskTracker是對於MapReduce執行而言的

mapreduce中幾個主要概念，mapreduce總體上能夠分爲這麼幾條執行線索：obclient，JobTracker與TaskTracker。

1)、JobClient會在用戶端經過JobClient類將應用已經配置參數打包成jar文件存儲到hdfs，並把路徑提交到Jobtracker,而後由JobTracker建立每個Task(即MapTask和ReduceTask)並將它們分發到各個TaskTracker服務中去執行。

2)、JobTracker是一個master服務，軟件啓動以後JobTracker接收Job，負責調度Job的每個子任務task運行於TaskTracker上，並監控它們，若是發現有失敗的task就從新運行它。通常狀況應該把JobTracker部署在單獨的機器上。

3)、TaskTracker是運行在多個節點上的slaver服務。TaskTracker主動與JobTracker通訊，接收做業，並負責直接執行每個任務。TaskTracker都須要運行在HDFS的DataNode上。

九十. Hadoop做者答案：C Doug cutting

a)Martin Fowler

b)Kent Beck

c)Doug cutting

九十一 . HDFS默認Block Size答案：B

a)32MB

b)64MB

c)128MB

(由於版本更換較快，這裏答案只供參考)

九十二.下列哪項一般是集羣的最主要瓶頸：答案：C磁盤

a)CPU

b)網絡

c)磁盤IO

d)內存

該題解析：

首先集羣的目的是爲了節省成本，用廉價的pc機，取代小型機及大型機。小型機和大型機有什麼特色?

1.cpu處理能力強

2.內存夠大

因此集羣的瓶頸不多是a和d

3.網絡是一種稀缺資源，可是並非瓶頸。

4.因爲大數據面臨海量數據，讀寫數據都須要io，而後還要冗餘數據，hadoop通常備3份數據，因此IO就會打折扣。

九十三.關於SecondaryNameNode哪項是正確的?答案C

a)它是NameNode的熱備

b)它對內存沒有要求

c)它的目的是幫助NameNode合併編輯日誌，減小NameNode啓動時間

d)SecondaryNameNode應與NameNode部署到一個節點。

多選題：

九十四下列哪項能夠做爲集羣的管理?答案：ABD

a)Puppet

b)Pdsh

c)Cloudera Manager

d)Zookeeper

九十五 .配置機架感知的下面哪項正確：答案ABC

a)若是一個機架出問題，不會影響數據讀寫

b)寫入數據的時候會寫到不一樣機架的DataNode中

c)MapReduce會根據機架獲取離本身比較近的網絡數據

九十六 Client端上傳文件的時候下列哪項正確?答案B

a)數據通過NameNode傳遞給DataNode

b)Client端將文件切分爲Block，依次上傳

c)Client只上傳數據到一臺DataNode，而後由NameNode負責Block複製工做

該題分析：

Client向NameNode發起文件寫入的請求。

NameNode根據文件大小和文件塊配置狀況，返回給Client它所管理部分DataNode的信息。

Client將文件劃分爲多個Block，根據DataNode的地址信息，按順序寫入到每個DataNode塊中。

11.下列哪一個是Hadoop運行的模式：答案ABC

a)單機版

b)僞分佈式

c)分佈式

九十七. Cloudera提供哪幾種安裝CDH的方法?答案：ABCD

a)Cloudera manager

b)Tarball

c)Yum

d)Rpm

判斷題：

九十八 Ganglia不只能夠進行監控，也能夠進行告警。(正確)

分析：此題的目的是考Ganglia的瞭解。嚴格意義上來說是正確。ganglia做爲一款最經常使用的Linux環境中的監控軟件，它擅長的的是從節點中按照用戶的需求以較低的代價採集數據。可是ganglia在預警以及發生事件後通知用戶上並不擅長。最新的ganglia已經有了部分這方面的功能。可是更擅長作警告的還有Nagios。Nagios，就是一款精於預警、通知的軟件。經過將Ganglia和Nagios組合起來，把Ganglia採集的數據做爲Nagios的數據源，而後利用Nagios來發送預警通知，能夠完美的實現一整套監控管理的系統。

九十九. Block Size是不能夠修改的。(錯誤)

分析：它是能夠被修改的Hadoop的基礎配置文件是hadoop-default.xml，默認創建一個Job的時候會創建Job的Config，Config首先讀入hadoop-default.xml的配置，而後再讀入hadoop-site.xml的配置(這個文件初始的時候配置爲空)，hadoop-site.xml中主要配置須要覆蓋的hadoop-default.xml的系統級配置。

一百. Nagios不能夠監控Hadoop集羣，由於它不提供Hadoop支持。(錯誤)

分析：Nagios是集羣監控工具，並且是雲計算三大利器之一

16.若是NameNode意外終止，SecondaryNameNode會接替它使集羣繼續工做。(錯誤)

分析：SecondaryNameNode是幫助恢復，而不是替代，如何恢復，能夠查看.

Cloudera CDH是須要付費使用的。(錯誤)

分析：第一套付費產品是Cloudera Enterpris，Cloudera Enterprise在美國加州舉行的Hadoop大會(Hadoop Summit)上公開，以若干私有管理、監控、運做工具增強Hadoop的功能。收費採起合約訂購方式，價格隨用的Hadoop叢集大小變更。

Hadoop是Java開發的，因此MapReduce只支持Java語言編寫。(錯誤)

分析：rhadoop是用R語言開發的，MapReduce是一個框架，能夠理解是一種思想，能夠使用其餘語言開發。

Hadoop支持數據的隨機讀寫。(錯)

分析：lucene是支持隨機讀寫的，而hdfs只支持隨機讀。可是HBase能夠來補救。HBase提供隨機讀寫，來解決Hadoop不能處理的問題。HBase自底層設計開始即聚焦於各類可伸縮性問題：表能夠很「高」，有數十億個數據行;也能夠很「寬」，有數百萬個列;水平分區並在上千個普通商用機節點上自動複製。表的模式是物理存儲的直接反映，使系統有可能提升高效的數據結構的序列化、存儲和檢索。