鎖屏面試題百日百刷，每個(gè)工作日?qǐng)?jiān)持更新面試題。請(qǐng)看到最后就能獲取你想要的,接下來的是今日的面試題：

1.解釋一下布隆過濾器原理

在日常生活中，包括在設(shè)計(jì)計(jì)算機(jī)軟件時(shí)，我們經(jīng)常要判斷一個(gè)元素是否在一個(gè)集合中。比如在字處理軟件中，需要檢查一個(gè)英語(yǔ)單詞是否拼寫正確（也就是要判斷它是否在已知的字典中）；在?FBI，一個(gè)嫌疑人的名字是否已經(jīng)在嫌疑名單上；在網(wǎng)絡(luò)爬蟲里，一個(gè)網(wǎng)址是否被訪問過等等。最直接的方法就是將集合中全部的元素存在計(jì)算機(jī)中，遇到一個(gè)新元素時(shí)，將它和集合中的元素直接比較即可。一般來講，計(jì)算機(jī)中的集合是用哈希表（hash table）來存儲(chǔ)的。它的好處是快速準(zhǔn)確，缺點(diǎn)是費(fèi)存儲(chǔ)空間。當(dāng)集合比較小時(shí)，這個(gè)問題不顯著，但是當(dāng)集合巨大時(shí)，哈希表存儲(chǔ)效率低的問題就顯現(xiàn)出來了。比如說，一個(gè)象?Yahoo,Hotmail?和?Gmai?那樣的公眾電子郵件（email）提供商，總是需要過濾來自發(fā)送垃圾郵件的人（spamer）的垃圾郵件。一個(gè)辦法就是記錄下那些發(fā)垃圾郵件的?email地址。由于那些發(fā)送者不停地在注冊(cè)新的地址，全世界少說也有幾十億個(gè)發(fā)垃圾郵件的地址，將他們都存起來則需要大量的網(wǎng)絡(luò)服務(wù)器。如果用哈希表，每存儲(chǔ)一億個(gè)?email?地址， 就需要?1.6GB?的內(nèi)存（用哈希表實(shí)現(xiàn)的具體辦法是將每一個(gè)?email?地址對(duì)應(yīng)成一個(gè)八字節(jié)的信息指紋googlechinablog.com/2006/08/blog-post.html，然后將這些信息指紋存入哈希表，由于哈希表的存儲(chǔ)效率一般只有?50%，因此一個(gè)?email?地址需要占用十六個(gè)字節(jié)。

一億個(gè)地址大約要?1.6GB， 即十六億字節(jié)的內(nèi)存）。因此存貯幾十億個(gè)郵件地址可能需要上百?GB?的內(nèi)存。除非是超級(jí)計(jì)算機(jī)，一般服務(wù)器是無(wú)法存儲(chǔ)的。

布隆過濾器只需要哈希表?1/8?到?1/4?的大小就能解決同樣的問題。

Bloom Filter是一種空間效率很高的隨機(jī)數(shù)據(jù)結(jié)構(gòu)，它利用位數(shù)組很簡(jiǎn)潔地表示一個(gè)集合，并能判斷一個(gè)元素是否屬于這個(gè)集合。Bloom Filter的這種高效是有一定代價(jià)的：在判斷一個(gè)元素是否屬于某個(gè)集合時(shí)，有可能會(huì)把不屬于這個(gè)集合的元素誤認(rèn)為屬于這個(gè)集合（false positive）。因此，Bloom Filter不適合那些“零錯(cuò)誤”的應(yīng)用場(chǎng)合。

而在能容忍低錯(cuò)誤率的應(yīng)用場(chǎng)合下，Bloom Filter通過極少的錯(cuò)誤換取了存儲(chǔ)空間的極大節(jié)省。

下面我們具體來看Bloom Filter是如何用位數(shù)組表示集合的。初始狀態(tài)時(shí)，Bloom Filter是一個(gè)包含m位的位數(shù)組，每一位都置為0。

為了表達(dá)S={x1, x2,…,xn}這樣一個(gè)n個(gè)元素的集合，Bloom Filter使用k個(gè)相互獨(dú)立的哈希函數(shù)（Hash Function），?它們分別將集合中的每個(gè)元素映射到{1,…,m}的范圍中。對(duì)任意一個(gè)元素x，第i個(gè)哈希函數(shù)映射的位置hi(x)就會(huì)被置 為1（1≤i≤k）。注意，如果一個(gè)位置多次被置為1，那么只有第一次會(huì)起作用，后面幾次將沒有任何效果。在下圖中， k=3，且有兩個(gè)哈希函數(shù)選中同一個(gè)位置（從左邊數(shù)第五位）。

在判斷y是否屬于這個(gè)集合時(shí)，我們對(duì)y應(yīng)用k次哈希函數(shù)，如果所有hi(y)的位置都是1（1≤i≤k），那么我們就認(rèn)為y是集合中的元素，否則就認(rèn)為y不是集合中的元素。下圖中y1就不是集合中的元素。y2或者屬于這個(gè)集合，或者剛好是一個(gè)false positive。

·?為了add一個(gè)元素，用k個(gè)hash function將它hash得到bloom filter中k個(gè)bit位，將這k個(gè)bit位置1。

·?為了query一個(gè)元素，即判斷它是否在集合中，用k個(gè)hash function將它hash得到k個(gè)bit位。若這k bits全為1，則此元素在集合中；若其中任一位不為1，則此元素比不在集合中（因?yàn)槿绻?，則在add時(shí)已經(jīng)把對(duì)應(yīng)的k個(gè)bits位置為1）。

·?不允許remove元素，因?yàn)槟菢拥脑挄?huì)把相應(yīng)的k個(gè)bits位置為0，而其中很有可能有其他元素對(duì)應(yīng)的位。因此remove會(huì)引入false negative，這是絕對(duì)不被允許的。

布隆過濾器決不會(huì)漏掉任何一個(gè)在黑名單中的可疑地址。但是，它有一條不足之處，也就是它有極小的可能將一個(gè)不在黑名單中的電子郵件地址判定為在黑名單中，因?yàn)橛锌赡苣硞€(gè)好的郵件地址正巧對(duì)應(yīng)個(gè)八個(gè)都被設(shè)置成一的二進(jìn)制位。好在這種可能性很小，我們把它稱為誤識(shí)概率。

布隆過濾器的好處在于快速，省空間，但是有一定的誤識(shí)別率，常見的補(bǔ)救辦法是在建立一個(gè)小的白名單，存儲(chǔ)那些可能別誤判的郵件地址。

2.如何實(shí)現(xiàn)HBase的二級(jí)索引?

方案一:?通常情況下,較原生方式,我們可以采用ES或者Solr來實(shí)現(xiàn)hbase的二級(jí)索引的操作,?當(dāng)用戶要寫入數(shù)據(jù)時(shí)候,?基于hbase的observer協(xié)處理器攔截下來,?使用es或者Solr來構(gòu)建hbase的索引數(shù)據(jù),?這樣當(dāng)查詢hbase中數(shù)據(jù)時(shí)候,?可以先去ES中查詢到對(duì)應(yīng)的數(shù)據(jù),?然后根據(jù)結(jié)果,?在從hbase中獲取最終的完整的結(jié)果

方案二:?基于Phoenix實(shí)現(xiàn), Phoenix是一款基于hbase的SQL客戶端,?可以使用SQL的方式來操作hbase,?同時(shí)為了提升整體的查詢性能, Phoenix中提供了各種索引(全局索引,?本地索引,?覆蓋索引以及函數(shù)索引),?這些索引都是基于Hbase的協(xié)處理器(主要是ObServer協(xié)處理器)而實(shí)現(xiàn)的,?二基于索引的查詢方案,?也是Phoenix實(shí)現(xiàn)hbase二級(jí)索引的方式

3.Hbase的storeFile(compact)合并機(jī)制是什么?

compact合并機(jī)制:

指的memStore中不斷進(jìn)行flush刷新操作,?就會(huì)產(chǎn)生多個(gè)storeFile的文件,?當(dāng)storeFile的文

件達(dá)到一定閾值后,?就會(huì)觸發(fā)compact的合并機(jī)制,?將多個(gè)storeFile合并為一個(gè)大的HFile文件

閾值:?達(dá)到3個(gè)及以上

整個(gè)合并過程分為兩大階段:

minor :

作用:?將多個(gè)小的storeFile合并為一個(gè)較大的Hfile操作

閾值:?達(dá)到3個(gè)及以上

注意:?此合并過程,?僅僅將多個(gè)合并為一個(gè),?對(duì)數(shù)據(jù)進(jìn)行排序操作,?如果此時(shí)數(shù)據(jù)有過期,?或者有標(biāo)記為刪除數(shù)據(jù),?此時(shí)不做任何的處理?(類似于 內(nèi)存合并中基礎(chǔ)型)

所以說,?此合并操作,?效率比較高

major:

作用:?將較大的HFile?和 之前的大的Hfile進(jìn)行合并形成一個(gè)更大的Hfile文件?(全局合并)

閾值:?默認(rèn)?7天

注意:?此合并過程,?會(huì)將那些過期的數(shù)據(jù),?或者已經(jīng)標(biāo)記刪除的數(shù)據(jù),?在這次合并中,?全部

都清除掉，由于這是一種全局合并操作,?對(duì)性能影響比較大,?在實(shí)際生產(chǎn)中,?建議 關(guān)閉掉自動(dòng)合并,?采用手動(dòng)觸發(fā)的方案

4.Hbase的flush刷新機(jī)制?

flush刷新機(jī)制(溢寫合并機(jī)制):

流程:?客戶端不斷將數(shù)據(jù)寫入到memStore內(nèi)存中,?當(dāng)內(nèi)存中數(shù)據(jù)達(dá)到一定閾值后,?需要

將數(shù)據(jù)溢寫刷新的HDFS中 形成一個(gè)storeFile文件

閾值: 128M?或者?1小時(shí) 滿足了那個(gè)都會(huì)觸發(fā)flush機(jī)制

內(nèi)部詳細(xì)流程: hbase 2.0架構(gòu) 以上流程

1)?客戶端不斷向memStore中寫入數(shù)據(jù),?當(dāng)memStore只數(shù)據(jù)達(dá)到閾值后,?就會(huì)啟動(dòng)flush操作

2)?首先hbase會(huì)先關(guān)閉掉當(dāng)前這個(gè)已經(jīng)達(dá)到閾值的內(nèi)存空間,?然后開啟一個(gè)新的memStore的空間,用于繼續(xù)寫入工作

3)?將這個(gè)達(dá)到閾值的內(nèi)存空間數(shù)據(jù)放入到 內(nèi)存隊(duì)列中,?此隊(duì)列的特性是只讀,?在hbase 2.0架構(gòu)中,?可以設(shè)置此隊(duì)列的數(shù)據(jù)盡可能晚的刷新到HDFS中,?當(dāng)這個(gè)隊(duì)列中數(shù)據(jù)達(dá)到某個(gè)閾值后(內(nèi)存不足),?這個(gè)時(shí)候觸發(fā)flush刷新操作?(隊(duì)列中可能存儲(chǔ)了多個(gè)memStore的數(shù)據(jù))

4) flush線程會(huì)將隊(duì)列中所有的數(shù)據(jù)全部讀取出來,?然后對(duì)數(shù)據(jù)進(jìn)行排序合并操作,?將合并后數(shù)據(jù)存儲(chǔ)到HDFS中,?形成一個(gè)storeFile的文件

注意:?在?hbase2.0以下的架構(gòu)中,?不存在推遲刷新功能,?同樣也不存在 合并數(shù)據(jù)的

操作當(dāng)memStore數(shù)據(jù)達(dá)到閾值后,?放入到隊(duì)列中,?專門有一個(gè)flush刷新監(jiān)控隊(duì)列,?一旦有數(shù)據(jù)直接刷新到HDFS上

注意說明:

hbase 2.0?只是提供了基于內(nèi)存的合并功能,?但是默認(rèn)情況下 不開啟的,?所以 在默認(rèn)情況

下?整個(gè)flush機(jī)制基本和2.0以下的版本是一致的,?但是一旦開啟了,?就是剛剛描述流程

合并方案:?三種基礎(chǔ)型(basic):?直接將多個(gè)memStore數(shù)據(jù)合并在一起直接刷新到HDFS上,如果數(shù)據(jù)存在過期的數(shù)據(jù),?或者是已經(jīng)標(biāo)記為刪除的數(shù)據(jù),?基礎(chǔ)型不做任何處理

饑渴型(eager):?在將多個(gè)memStore合并的過程中,?積極判斷數(shù)據(jù)是否存在過期,?或者是否已經(jīng)標(biāo)記刪除,?如果有,?直接過濾掉這些標(biāo)記刪除和過期的數(shù)據(jù)即可

適應(yīng)性(adaptive):?檢查數(shù)據(jù)是否有過期數(shù)據(jù),?如果過期數(shù)據(jù)量達(dá)到一定閾值后,?就會(huì)自動(dòng)使

用饑渴型,?否則就使用基礎(chǔ)型

5.如何解決hbase中數(shù)據(jù)熱點(diǎn)問題?

所謂數(shù)據(jù)熱點(diǎn),?指的是大量的數(shù)據(jù)寫到hbase的某一個(gè)或者某幾個(gè)region中,?導(dǎo)致其余的region沒有數(shù)據(jù),?其他region對(duì)應(yīng)regionServer的節(jié)點(diǎn)承受了大量的并發(fā)請(qǐng)求,?此時(shí)就出現(xiàn)了熱點(diǎn)問題

解決方案:?通過預(yù)分區(qū)和設(shè)計(jì)良好的rowkey來解決

1)加鹽處理(加隨機(jī)數(shù)) :?可以在rowkey前面動(dòng)態(tài)添加一些隨機(jī)數(shù),?從而保證數(shù)據(jù)可以均勻落在不同region中

n 基本保證數(shù)據(jù)落在不同region

n 將相關(guān)性比較強(qiáng)的數(shù)據(jù)分散在不同的額region中,?導(dǎo)致查詢的效率有一定降低

2)hash處理:?根據(jù)rowkey計(jì)算其hash值,?在rowkey前面hash計(jì)算值即可?(MD5 HASH)

n 讓相關(guān)性比較強(qiáng)的數(shù)據(jù)可以被放置到同一個(gè)region中

n 如果相關(guān)數(shù)據(jù)比較多,?依然會(huì)導(dǎo)致熱點(diǎn)問題

3)反轉(zhuǎn)策略:?比如說手機(jī)號(hào)反轉(zhuǎn) 或者 時(shí)間戳的反轉(zhuǎn)

n 好處:?基本保證數(shù)據(jù)落在不同region

n 弊端:?將相關(guān)性比較強(qiáng)的數(shù)據(jù)分散在不同的region中,?導(dǎo)致查詢的效率有一定降低

全部?jī)?nèi)容在[git](https://gitee.com/zjlalaforgit/interview)上,了解更多請(qǐng)點(diǎn)我頭像或到我的主頁(yè)去獲得，謝謝