柚子快報(bào)邀請碼778899分享：數(shù)據(jù)倉庫-數(shù)倉優(yōu)化小廠實(shí)踐

http://yzkb.51969.com/

一、背景

? ? ? ? 由于公司規(guī)模較小，大數(shù)據(jù)相關(guān)沒有實(shí)現(xiàn)平臺化，相關(guān)的架構(gòu)都是原生的Apache組件，所以集群的維護(hù)和優(yōu)化都需要人工的參與。根據(jù)自己的實(shí)踐整理一些數(shù)倉相關(guān)的優(yōu)化。

二、優(yōu)化

? ? ? ? 1、簡易架構(gòu)圖

? ? ? ? 2、ODS層優(yōu)化

? ? ? ? 2.1 分段式解析

????????隨著業(yè)務(wù)增長，數(shù)據(jù)量也不斷增加，凌晨任務(wù)經(jīng)?；€預(yù)警、破線，導(dǎo)致數(shù)據(jù)不能正常產(chǎn)出，影響運(yùn)營人員分析數(shù)據(jù)。在不增加成本的情況盡可能的優(yōu)化。

????????經(jīng)過團(tuán)隊(duì)研究，發(fā)現(xiàn) t-1 的日志解析占用非常長的時(shí)間，且集群資源空閑時(shí)間點(diǎn)比較多。

????????把日志的解析分成兩段式，當(dāng)天0點(diǎn)到22點(diǎn)數(shù)據(jù)可在22:15進(jìn)行解析，22點(diǎn)到24點(diǎn)數(shù)據(jù)在00:15解析，大大節(jié)省了時(shí)間，還充分利用了集群的資源。有效的緩解了破線問題。

? ? ? ? 2.2 小文件合并

1.原因：a.讀取的數(shù)據(jù)源文件本身就有大量的小文件

b.動態(tài)分區(qū)插入數(shù)據(jù)，每個(gè)reduce產(chǎn)生的文件個(gè)數(shù)為動態(tài)分區(qū)的個(gè)數(shù)，產(chǎn)生文件個(gè)數(shù)=reduce個(gè)數(shù)*動態(tài)分區(qū)數(shù)

c.reduce/Task個(gè)數(shù)較多（和文件數(shù)是一樣的）

2.影響：a.文件的數(shù)量決定了Mapreduce/Spark中Mapper/Task數(shù)量，小文件越多，Mapper/Task的任務(wù)越多，每個(gè)Mapper

/task都會對應(yīng)啟動一個(gè)JVM/線程來運(yùn)行，每個(gè)Task數(shù)據(jù)小，個(gè)數(shù)大，占用資源多，甚至這些任務(wù)初始化的時(shí)間

可能比執(zhí)行的時(shí)間還要多，影響性能，當(dāng)然這個(gè)問題 可以通過CombinedInputFile和開啟JVM重用來解決。

b.文件存儲在HDFS上，每個(gè)文件的元數(shù)據(jù)信息（位置、大小、分塊信息）大約占150個(gè)字節(jié)，文件的元數(shù)據(jù)信息分別存儲在

內(nèi)存和磁盤中。

3.解決方法:通過 DISTRIBUTE BY 控制文件的個(gè)數(shù)

distribute by 1

distribute by cast(rand()*10 as int)

distribute by dt

distribute by substr(udi,1,2)

? ? ? ? 2.3 提高數(shù)據(jù)壓縮比率

????????1.問題描述 ：使用 DISTRIBUTE BY INT(RAND()*300) 隨機(jī)數(shù)的方式控制了文件的個(gè)數(shù)，但是使用的SNAPPY壓縮，壓縮比原則是十倍左右，目前只能達(dá)到兩倍左右。

????????原因：每個(gè)文件里面的數(shù)據(jù)隨機(jī)，數(shù)據(jù)的相似性較小，壓縮比上不去

????????2.問題解決：DISTRIBUTE BY SUBSTR(udi,1,2) 使用文本字段進(jìn)行文件數(shù)的控制，文件個(gè)數(shù)減少了，并且文件的大小也變小了，壓縮比變大

????????說明：udi前兩個(gè)為(字母+數(shù)字),截取前兩個(gè)組合來作為文件的個(gè)數(shù)(最多36*36)

????????原理：將相似的數(shù)據(jù)放在同一個(gè)分區(qū)里，數(shù)據(jù)壓縮比增大?

? ? ? ? 2.4 分項(xiàng)目業(yè)務(wù)數(shù)據(jù)導(dǎo)入優(yōu)化

????????1.問題描述：由于項(xiàng)目數(shù)量比較多，并且會持續(xù)增加，項(xiàng)目之間的業(yè)務(wù)表相同，按照sqoop傳統(tǒng)導(dǎo)數(shù)據(jù)的腳本，會編寫很多冗余的腳本，費(fèi)時(shí)費(fèi)力，且增加新項(xiàng)目時(shí)，開發(fā)成本較高

????????2.問題解決：將不同的數(shù)據(jù)庫的配置信息(host、IP、賬號、密碼、腳本路徑) 配置到mysql表中，編寫相應(yīng)的腳本，腳本根據(jù)給定的參數(shù)去讀取相應(yīng)的配置，進(jìn)行對應(yīng)項(xiàng)目的數(shù)據(jù)導(dǎo)入。

3、DWD層優(yōu)化

? ? ? ? 3.1 縮減分區(qū)

????????1.問題描述：初始建立二級分區(qū)（項(xiàng)目+天），隨著老項(xiàng)目的數(shù)據(jù)量增加，以及新項(xiàng)目上線數(shù)據(jù)量較少， 導(dǎo)致執(zhí)行時(shí)造成數(shù)據(jù)傾斜，以及多級分區(qū)造成文件數(shù)以及分區(qū)數(shù)成倍增加，造成數(shù)據(jù)尋址時(shí)間過長。 執(zhí)行時(shí)間較短，但是刷盤的時(shí)間過長，晚上流程的時(shí)間整體拖延。

????????2.問題解決：將二級分區(qū)改為一級分區(qū)

????????3.解決方法：a.建立同樣的臨時(shí)表

????????????????????????b.將歷史數(shù)據(jù)mv導(dǎo)入到臨時(shí)表中，此時(shí)進(jìn)行核對數(shù)據(jù)量

????????????????????????c.通過命令修復(fù)臨時(shí)表的分區(qū)

????????????????????????d.將舊表刪除，建立新的分區(qū)表

????????????????????????e.將臨時(shí)表的數(shù)據(jù)導(dǎo)入到新的表中，核對數(shù)據(jù)

柚子快報(bào)邀請碼778899分享：數(shù)據(jù)倉庫-數(shù)倉優(yōu)化小廠實(shí)踐

http://yzkb.51969.com/

參考文章