11. mapreduce 的 shuffle 調(diào)優(yōu)參數(shù)

具體參考：MapReduce Shuffle性能調(diào)優(yōu)

Map 端優(yōu)化參數(shù)

Reduce 端優(yōu)化參數(shù)

12. hive 都在 mysql 中建了哪些表，分別用來干什么

詳情參考一下連接：

Hive的元數(shù)據(jù)表結(jié)構(gòu)詳解

重要的表有：

• 存儲Hive版本的元數(shù)據(jù)表（VERSION）

• Hive數(shù)據(jù)庫相關(guān)的元數(shù)據(jù)表（DBS、DATABASE_PARAMS）

• Hive 表和視圖相關(guān)的元數(shù)據(jù)表（TBLS、TABLE_PARAMS、TBL_PRIVS，這三張表通過TBL_ID關(guān)聯(lián)）

• Hive 表分區(qū)相關(guān)的元數(shù)據(jù)表（主要涉及 PARTITIONS、PARTITION_KEYS、PARTITION_KEY_VALS、PARTITION_PARAMS）

• Hive 文件存儲信息相關(guān)的元數(shù)據(jù)表（主要涉及SDS、SD_PARAMS、SERDES、SERDE_PARAMS）

13. hive 面試用神 sql，級聯(lián)求和

需求：現(xiàn)有用戶的每月消費金額情況如下,希望輸出的結(jié)果如下，請用一個 hive sql 實現(xiàn)：

要求輸出結(jié)果：

+---------+----------+--------+-------------+--+
| a.name  |  a.time  | count  | accumulate  |
+---------+----------+--------+-------------+--+
| A       | 2015-01  | 33     | 33          |
| A       | 2015-02  | 10     | 43          |
| B       | 2015-01  | 30     | 30          |
| B       | 2015-02  | 15     | 45          |
+---------+----------+--------+-------------+--+

實現(xiàn)思路：

1. 第一步，先求個用戶的月總金額

select username,month,sum(salary) as salary from t_access_times group by username,month

+-----------+----------+---------+--+
| username  |  month   | salary  |
+-----------+----------+---------+--+
| A         | 2015-01  | 33      |
| A         | 2015-02  | 10      |
| B         | 2015-01  | 30      |
| B         | 2015-02  | 15      |
+-----------+----------+---------+--+

2. 第二步，將月總金額表 自己連接 自己連接

select *
from 
(select username,month,sum(salary) as salary from t_access_times group by username,month) A 
inner join 
(select username,month,sum(salary) as salary from t_access_times group by username,month) B
on
A.username=B.username

+-------------+----------+-----------+-------------+----------+-----------+--+
| a.username  | a.month  | a.salary  | b.username  | b.month  | b.salary  |
+-------------+----------+-----------+-------------+----------+-----------+--+
| A           | 2015-01  | 33        | A           | 2015-01  | 33        |
| A           | 2015-01  | 33        | A           | 2015-02  | 10        |
| A           | 2015-02  | 10        | A           | 2015-01  | 33        |
| A           | 2015-02  | 10        | A           | 2015-02  | 10        |
| B           | 2015-01  | 30        | B           | 2015-01  | 30        |
| B           | 2015-01  | 30        | B           | 2015-02  | 15        |
| B           | 2015-02  | 15        | B           | 2015-01  | 30        |
| B           | 2015-02  | 15        | B           | 2015-02  | 15        |
+-------------+----------+-----------+-------------+----------+-----------+--+

3. 第三步，從上一步的結(jié)果中進(jìn)行分組查詢，分組的字段是 a.username a.month。求月累計值：將 b.month <= a.month 的所有 b.salary 求和即可

select A.username,A.month,max(A.salary) as salary,sum(B.salary) as accumulate
from 
(select username,month,sum(salary) as salary from t_access_times group by username,month) A 
inner join 
(select username,month,sum(salary) as salary from t_access_times group by username,month) B
on
A.username=B.username
where B.month <= A.month
group by A.username,A.month
order by A.username,A.month;


+---------+----------+--------+-------------+--+
| a.name  |  a.time  | count  | accumulate  |
+---------+----------+--------+-------------+--+
| A       | 2015-01  | 33     | 33          |
| A       | 2015-02  | 10     | 43          |
| B       | 2015-01  | 30     | 30          |
| B       | 2015-02  | 15     | 45          |
+---------+----------+--------+-------------+--+

14. sqoop 在導(dǎo)入數(shù)據(jù)到 mysql 中，如何讓數(shù)據(jù)不重復(fù)導(dǎo)入？如果存在數(shù)據(jù)問題 sqoop如何處理？

--update-key ID --update-mode allowinsert，如何數(shù)據(jù)存在就更新，不存在就插入。

15. 使用 Hive 或者自定義 MapReduce 實現(xiàn)如下邏輯：

product_no  lac_id moment start_time user_id county_id staytime city_id
13429100031 22554 8 2013-03-11 08:55:19.151754088 571 571 282 571
13429100082 22540 8 2013-03-11 08:58:20.152622488 571 571 270 571
13429100082 22691 8 2013-03-11 08:56:37.149593624 571 571 103 571
13429100087 22705 8 2013-03-11 08:56:51.139539816 571 571 220 571
13429100087 22540 8 2013-03-11 08:55:45.150276800 571 571 66 571
13429100082 22540 8 2013-03-11 08:55:38.140225200 571 571 133 571
13429100140 26642 9 2013-03-11 09:02:19.151754088 571 571 18 571
13429100082 22691 8 2013-03-11 08:57:32.151754088 571 571 287 571
13429100189 22558 8 2013-03-11 08:56:24.139539816 571 571 48 571
13429100349 22503 8 2013-03-11 08:54:30.152622440 571 571 211 571

字段解釋：

product_no：用戶手機(jī)號

lac_id：用戶所在基站

start_time：用戶在此基站的開始時間

staytime：用戶在此基站的逗留時間

需求描述：

根據(jù) lac_id 和 start_time 知道用戶當(dāng)時的位置，根據(jù) staytime 知道用戶各個基站的逗留時長。根據(jù)軌跡合并連續(xù)基站的 staytime。最終得到每一個用戶按時間排序在每一個基站駐留時長

期望輸出舉例：

13429100082 22540 8 2013-03-11 08:58:20.152622488 571 571 270 571
13429100082 22691 8 2013-03-11 08:56:37.149593624 571 571 390 571
13429100082 22540 8 2013-03-11 08:55:38.140225200 571 571 133 571
13429100087 22705 8 2013-03-11 08:56:51.139539816 571 571 220 571
13429100087 22540 8 2013-03-11 08:55:45.150276800 571 571 66 571

考慮用 mapreduce 實現(xiàn)

實現(xiàn)參考MR 基站

問題分析：針對每個product_no按照start_time進(jìn)行排序(本例降序)，如果相鄰兩項的lac_id相同，則將staytime進(jìn)行相加保存到后一項中，并將前一項移除。

自己已經(jīng)做出來了。

請隨意使用各種類型的腳本語言實現(xiàn)：批量將指定目錄下的所有文件中的 $HADOOP_HOME$替換成/home/ocetl/app/hadoop

Python（沒有驗證）

import string,os,sys dir=’/var’

files=os.listdir(dir) for f in files: tmpContents = ‘’; for s in f.readlines(): tmpContents += s.replace(“$HADOOP_HOME$”,”/home/ocetl/app/hadoop”)

f.write(tmpContents) f.close()

shell（已驗證）

#!/bin/bash
ls $1 | while read line
do
sed -i 's,\$HADOOP_HOME\$,\/home\/hadoop,g' $1$line
echo $1$line
done

16. mapreduce 的 shuffle 執(zhí)行流程

1. maptask中的 OutputCollector 收集我們的 map() 方法輸出的 kv 對，放到內(nèi)存緩沖區(qū)(環(huán)形緩沖區(qū))中(默認(rèn) 100M)

2. 當(dāng)緩沖區(qū)的存儲的數(shù)據(jù)超過了閾值（默認(rèn)80%）時，會調(diào)用 spiller 線程從內(nèi)存緩沖區(qū)溢出到本地磁盤文件，可能會溢出多個文件

3. 多個溢出文件會被合并成大的溢出文件

4. 在溢出過程中，及合并的過程中，都要調(diào)用 partitoner 進(jìn)行分區(qū)和針對 key 進(jìn)行排序（默認(rèn)是快速排序）

5. reducetask 根據(jù)自己的分區(qū)號，去各個 maptask 機(jī)器上取相應(yīng)的結(jié)果分區(qū)數(shù)據(jù)，將這些文件再進(jìn)行合并和排序（歸并排序）。

6. reducetask 合并完成后，shuffle 的過程也就結(jié)束了，后面進(jìn)入 reducetask 的邏輯運算過程。

Shuffle 中的緩沖區(qū)大小會影響到 mapreduce 程序的執(zhí)行效率，==原則上說，緩沖區(qū)越大，磁盤 io 的次數(shù)越少，執(zhí)行速度就越快==

緩沖區(qū)的大小可以通過參數(shù)調(diào)整, 參數(shù)：io.sort.mb 默認(rèn)100M

17. hdfs 的 checkpoint 過程描述

HA 模式下的元數(shù)據(jù)合并

在HA模式下checkpoint過程由StandBy NameNode來進(jìn)行，以下簡稱為SBNN，Active NameNode簡稱為ANN。

主要由4個步驟：

1. SBNN 檢查是否達(dá)到 checkpoint 條件：離上一次 checkpoint 操作是否已經(jīng)有一個小時，或者 HDFS 已經(jīng)進(jìn)行了100萬次操作。

2. SBNN 檢查達(dá)到 checkpoint 條件后，將 ANN 的最后一次操作日志讀取到本地，將磁盤中的 fsimage 文件和 edits 文件加載到內(nèi)存，合并成一份新的 fsimage 文件

3. 然后 SBNN 通過 HTTP 聯(lián)系 ANN。

4. ANN 通過 HTTP 方式從 SBNN 獲取最新的 fsimage 文件并將舊的 fsimage 文件刪除。

由于HA機(jī)制，會使得Standby NameNode和Active NameNode都擁有最新的fsimage和edits文件。

非 HA 模式的元數(shù)據(jù)合并

1. 內(nèi)存中有一份完整的元數(shù)據(jù)

2. 磁盤有一個“準(zhǔn)完整”的元數(shù)據(jù)鏡像

3. 當(dāng)客戶端對 hdfs 中的文件進(jìn)行新增或者修改操作，相應(yīng)的記錄首先被記入 edits 這種 log 日志中，當(dāng)客戶端操作成功后，相應(yīng)的元數(shù)據(jù)會更新到內(nèi)存中

4. 每隔一段時間，會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，并加載到內(nèi)存進(jìn)行merge(合并)（這個過程稱為checkpoint）

5. secondary namenode將合并好之后的新的fsimage鏡像文件回傳給namenode，namenode將舊的fsimage刪除使用新的fsimage和新的edits.inprogress文件

6. namenode 和 secondary namenode 的工作目錄存儲結(jié)構(gòu)完全相同，所以，當(dāng) namenode 故障退出需要重新恢復(fù)時，可以從 secondary namenode 的工作目錄中將 fsimage 拷貝到 namenode 的工作目錄，以恢復(fù) namenode 的元數(shù)據(jù)

這樣做的缺點就是：secondary namenode 的 fsimage 不是最新的。

什么時候進(jìn)行 checkpoint?

由兩個參數(shù)

• dfs.namenode.checkpoint.preiod (兩次checkpoint之間的時間間隔，默認(rèn)值是3600秒，即 1 小時)
• dfs.namenode.checkpoint.txns (兩次checkpoint之間最大的操作記錄，默認(rèn)值是 100萬次 )來決定。

period 參數(shù)表示，經(jīng)過 1 小時就進(jìn)行一次 checkpoint，txns 參數(shù)表示，hdfs 經(jīng)過 100 萬次操作后就要進(jìn)行 checkpoint 了。這兩個參數(shù)任意一個得到滿足，都會觸發(fā) checkpoint 過程。進(jìn)行 checkpoint 的節(jié)點每隔 dfs.namenode.checkpoint.check.period (默認(rèn)值是 60 ）秒就會去統(tǒng)計一次 hdfs 的操作次數(shù)。

18. hdfs 的讀數(shù)據(jù)流程

1. client跟namenode通信查詢元數(shù)據(jù)，找到文件塊所在的datanode服務(wù)器

2. 分別連接目標(biāo)datanode，并發(fā)讀取文件塊，并在合并讀取到的文件

3. datanode 以 packet 為單位向客戶端發(fā)送?？蛻舳私邮蘸笙却嬖诒镜鼐彺?，然后再寫入文件。

19. hdfs 的寫數(shù)據(jù)流程

1. client 跟 namenode 通信請求上傳文件，namenode 檢查目標(biāo)文件是否已存在(文件已存在則報錯不能上傳)，父目錄是否存在(目錄不存在報錯無法上傳)，以及客戶端是否有新建文件的權(quán)限。

2. namenode 返回是否可以上傳，如果可以上傳，namenode 會返回這個文件是否被分塊以及分塊的具體信息。

3. client 請求第一個 block 該傳輸?shù)侥男?datanode 服務(wù)器上

4. namenode 返回 3 個 datanode 服務(wù)器 ABC

5. client 請求 3 臺 dn 中的一臺 A 上傳數(shù)據(jù)(本質(zhì)上是一個 RPC 調(diào)用，建立 pipeline，連接離自己最近的 datanode)，A收到請求會繼續(xù)調(diào)用 B，然后 B 調(diào)用 C，將整個 pipeline 建立完成，逐級返回客戶端

6. client開始往A上傳第一個block（先從磁盤讀取數(shù)據(jù)放到一個本地內(nèi)存緩存），以packet為單位，A收到一個packet就會傳給B，B傳給C；A每傳一個packet會放入一個應(yīng)答隊列等待應(yīng)答

7. 當(dāng)一個block傳輸完成之后，client再次請求namenode上傳第二個block的服務(wù)器，以此類推。

8. 如果傳輸過程中，有某個 datanode 出現(xiàn)了故障，那么當(dāng)前的 pipeline 會被關(guān)閉，出現(xiàn)故障的 datanode 會從當(dāng)前的 pipeline 中移除，剩余的 block 會繼續(xù)剩下的 datanode 中繼續(xù)以 pipeline 的形式傳輸，同時 Namenode 會分配一個新的 datanode，保持 replicas 設(shè)定的數(shù)量。

20. Hive sql 優(yōu)化解決數(shù)據(jù)傾斜問題

Hive 中出現(xiàn)數(shù)據(jù)傾斜的情況，一般發(fā)生在 sql 中的 group by 和 join 上，且和數(shù)據(jù)邏輯綁定比較深。個人認(rèn)為解決數(shù)據(jù)傾斜問題的重點應(yīng)該放在對數(shù)據(jù)的設(shè)計和業(yè)務(wù)的理解上。

優(yōu)化方案：

1. 使用 map side join，參考 hive使用技巧（四）——巧用MapJoin解決數(shù)據(jù)傾斜問題

2. 針對 count(distinct) 操作，先轉(zhuǎn)換成 group，然后再外面加上 count

3. Hive 的萬能鑰匙：hive.groupby.skewindata=true

4. left semi join 使用，實現(xiàn) in 操作

5. 盡量盡早的過濾數(shù)據(jù)，減少每個階段的數(shù)據(jù)量，把 where 條件寫到 join 的里面，減少 join 的數(shù)據(jù)量。

6. 針對大量 key 為空的情況，將空的 key 和非空 key 做區(qū)分，空的 key 不做 join 操作。

7. 避免使用 order by，原因如下：order by 會對輸入做全局排序，因此只有一個 reducer，會導(dǎo)致當(dāng)輸入規(guī)模較大時，需要較長的計算時間。

8. 盡量避免一個 sql 包含復(fù)雜的邏輯，可以將整個步驟拆分成多個中間表來完成。

9. join 操作，數(shù)據(jù)量小的表要放在 join 的左邊

10. union all 的部分大于 2，或每個 union 的部分?jǐn)?shù)據(jù)量很大，那么應(yīng)該拆分成多個 insert into 語句。

具體參考 hive的查詢注意事項以及優(yōu)化總結(jié)

9. hbase 的 rowkey 設(shè)計原則

rowkey長度原則

==建議越短越好，不要超過16個字節(jié)==，原因如下：

1. 數(shù)據(jù)的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100字節(jié)，1000w行數(shù)據(jù)，光rowkey就要占用100*1000w=10億個字節(jié)，將近1G數(shù)據(jù)，這樣會極大影響HFile的存儲效率。
2. MemStore將緩存部分?jǐn)?shù)據(jù)到內(nèi)存，如果rowkey字段過長，內(nèi)存的有效利用率就會降低，系統(tǒng)不能緩存更多的數(shù)據(jù)，這樣會降低檢索效率。
3. 目前操作系統(tǒng)都是64位系統(tǒng)，內(nèi)存8字節(jié)對齊，控制在16個字節(jié)，8字節(jié)的整數(shù)倍利用了操作系統(tǒng)的最佳特性。

rowkey散列原則

如果rowkey按照時間戳的方式遞增，不要將時間放在二進(jìn)制碼的前面，建議將rowkey的高位作為散列字段，由程序隨機(jī)生成，低位放時間字段，這樣將提高數(shù)據(jù)均衡分布在每個RegionServer，以實現(xiàn)負(fù)載均衡的幾率。如果沒有散列字段，首字段直接是時間信息，所有的數(shù)據(jù)都會集中在一個RegionServer上，這樣在數(shù)據(jù)檢索的時候負(fù)載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率。

rowkey唯一原則

必須在設(shè)計上保證其唯一性，rowkey是按照字典順序排序存儲的，因此，設(shè)計rowkey的時候，要充分利用這個排序的特點，將經(jīng)常讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問的數(shù)據(jù)放到一塊。

10. hbase 常見的避免熱點的方法

加鹽

這里所說的加鹽不是密碼學(xué)中的加鹽，而是在rowkey的前面增加隨機(jī)數(shù)，具體就是給rowkey分配一個隨機(jī)前綴以使得它和之前的rowkey的開頭不同。分配的前綴種類數(shù)量應(yīng)該和你想使用數(shù)據(jù)分散到不同的region的數(shù)量一致。加鹽之后的rowkey就會根據(jù)隨機(jī)生成的前綴分散到各個region上，以避免熱點。

哈希

哈希會使同一行永遠(yuǎn)用一個前綴加鹽。哈希也可以使負(fù)載分散到整個集群，但是讀卻是可以預(yù)測的。使用確定的哈?？梢宰尶蛻舳酥貥?gòu)完整的rowkey，可以使用get操作準(zhǔn)確獲取某一個行數(shù)據(jù)

反轉(zhuǎn)

第三種防止熱點的方法時反轉(zhuǎn)固定長度或者數(shù)字格式的rowkey。這樣可以使得rowkey中經(jīng)常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機(jī)rowkey，但是犧牲了rowkey的有序性。

反轉(zhuǎn)rowkey的例子以手機(jī)號為rowkey，可以將手機(jī)號反轉(zhuǎn)后的字符串作為rowkey，這樣的就避免了以手機(jī)號那樣比較固定開頭導(dǎo)致熱點問題

時間戳反轉(zhuǎn)

一個常見的數(shù)據(jù)處理問題是快速獲取數(shù)據(jù)的最近版本，使用反轉(zhuǎn)的時間戳作為rowkey的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的數(shù)據(jù)。

比如需要保存一個用戶的操作記錄，按照操作時間倒序排序，在設(shè)計rowkey的時候，可以這樣設(shè)計

[userId反轉(zhuǎn)][Long.Max_Value - timestamp]，在查詢用戶的所有操作記錄數(shù)據(jù)的時候，直接指定反轉(zhuǎn)后的userId，startRow是[userId反轉(zhuǎn)][000000000000],stopRow是[userId反轉(zhuǎn)][Long.Max_Value - timestamp]

如果需要查詢某段時間的操作記錄，startRow是[user反轉(zhuǎn)][Long.Max_Value - 起始時間]，stopRow是[userId反轉(zhuǎn)][Long.Max_Value - 結(jié)束時間]

11. hbase 的列族如何設(shè)計

hbase 列族設(shè)計優(yōu)化文章

Hbase官方文檔中寫明，目前列族數(shù)量最優(yōu)不超過3個。原因如下：

每個 RegionServer 包含多個 Region，每個 Region 包含多個Store，每個 Store 包含一個 MemStore 和多個 StoreFile。

在 Hbase 的表中，每個列族對應(yīng) Region 中的一個Store，Region的大小達(dá)到閾值時會分裂，因此如果表中有多個列族，則可能出現(xiàn)以下現(xiàn)象：

1. 一個Region中有多個Store，如果每個CF的數(shù)據(jù)量分布不均勻時，比如CF1為100萬，CF2為1萬，則 Region分裂時導(dǎo)致CF2在每個Region中的數(shù)據(jù)量太少，查詢CF2時會橫跨多個Region導(dǎo)致效率降低。

2. 如果每個CF的數(shù)據(jù)分布均勻，比如CF1有50萬，CF2有50萬，CF3有50萬，則Region分裂時導(dǎo)致每個 CF 在Region的數(shù)據(jù)量偏少，查詢某個CF時會導(dǎo)致橫跨多個Region的概率增大。

3. 多個CF代表有多個Store，也就是說有多個MemStore，也就導(dǎo)致內(nèi)存的消耗量增大，使用效率下降。

4. Region 中的 緩存刷新 和 壓縮 是基本操作，即一個CF出現(xiàn)緩存刷新或壓縮操作，其它CF也會同時做一樣的操作，當(dāng)列族太多時就會導(dǎo)致IO頻繁的問題。

12. hbase 的整體架構(gòu)

hbase 架構(gòu)圖

• HMaster

HMaster用于協(xié)調(diào)多個 HRegionServer，偵測各個RegionServer之間的狀態(tài)，并平衡RegionServer之間的負(fù)載。HMaster還有一個職責(zé)就是負(fù)責(zé)分配Region給RegionServer。==如果無Master過程中，數(shù)據(jù)讀取仍照常進(jìn)行，但是，region切分、負(fù)載均衡等無法進(jìn)行==

• HRegionServer

對于一個HRegionServer而言，其包括了多個HRegion。HRegionServer的作用只是管理表格，以及實現(xiàn)讀寫操作。Client直接連接HRegionServer，并通信獲取HBase中的數(shù)據(jù)。對于Region而言，則是真實存放HBase數(shù)據(jù)的地方，也就說Region是HBase可用性和分布式的基本單位.==每個 RegionServer 包含多個 Region，每個 Region 包含多個Store，每個 Store 包含一個 MemStore 和多個 StoreFile。每個 HStore 對應(yīng) Table 中的一個 Column Familiy 的存儲。==

• Zookeeper

對于 HBase 而言，Zookeeper的作用是至關(guān)重要的。首先Zookeeper是作為HBase Master的HA解決方案。也就是說，是Zookeeper保證了至少有一個HBase Master 處于運行狀態(tài)。并且Zookeeper負(fù)責(zé)Region和Region Server的注冊。

22. mapreduce 中的 MRAppMaster 和 YarnChild 的作用分別是什么？

MRAppMaster

在YARN中，MRAppMaster負(fù)責(zé)管理MapReduce作業(yè)的生命周期，包括作業(yè)管理、資源申請與再分配、Container啟動與釋放、作業(yè)恢復(fù)等。

具體參考：YARN MapReduce MRAppMaster-剖析

YarnChild

YarnChild：運行具體的 map/reduce task。

RunJar：完成job的初始化，包括獲取jobID，將jar包上傳至hdfs等。

job啟動過程：

ResourceManager，NodeManager->RunJar->MRAppMaster->YarnChild

job退出過程：

YarnChild->MRAppMaster->RunJar