銀行傳統(tǒng)數(shù)據(jù)倉庫向大數(shù)據(jù)平臺遷移探索

銀行傳統(tǒng)數(shù)據(jù)倉庫向大數(shù)據(jù)平臺遷移探索

【摘要】面對業(yè)務(wù)發(fā)展、數(shù)據(jù)化轉(zhuǎn)型等各方面的需求，基于傳統(tǒng)架構(gòu)的銀行數(shù)據(jù)倉庫體系面臨極大的挑戰(zhàn)。某銀行目前既有傳統(tǒng)架構(gòu)的數(shù)據(jù)倉庫，也引入了基于主流Hadoop體系的大數(shù)據(jù)平臺。為優(yōu)化數(shù)據(jù)重復(fù)加工與存儲，促進(jìn)信息管理應(yīng)用的數(shù)據(jù)融合共享，本文在采用大數(shù)據(jù)技術(shù)構(gòu)建統(tǒng)一的企業(yè)級數(shù)據(jù)管理平臺，重構(gòu)數(shù)據(jù)倉庫方面進(jìn)行了探索，以論證傳統(tǒng)數(shù)據(jù)倉庫往大數(shù)據(jù)平臺遷移的可行性，為某銀行在大數(shù)據(jù)戰(zhàn)略上的規(guī)劃提供一定的支持。探索過程涉及現(xiàn)狀調(diào)研安排、架構(gòu)設(shè)計、模型遷移與優(yōu)化、數(shù)據(jù)遷移、ETL遷移、數(shù)據(jù)訪問接口的遷移、容量規(guī)劃等多個核心環(huán)節(jié)，并依照該行的特點(diǎn)進(jìn)行了一些有意義的嘗試。

一、銀行大數(shù)據(jù)平臺建設(shè)背景在全球經(jīng)濟(jì)進(jìn)入數(shù)字化轉(zhuǎn)型時期，數(shù)字化轉(zhuǎn)型已成為傳統(tǒng)企業(yè)必須付諸行動的必選題。當(dāng)下數(shù)字化轉(zhuǎn)型已經(jīng)滲入人們?nèi)粘５囊率匙⌒?、工作生活、生產(chǎn)服務(wù)等方方面面。在消費(fèi)金融具有極大發(fā)展?jié)摿扒熬暗那闆r下，銀行進(jìn)行數(shù)字化轉(zhuǎn)型更為迫切。而面對數(shù)字化轉(zhuǎn)型的需要，銀行體系中的傳統(tǒng)數(shù)據(jù)倉庫普遍面臨極大的挑戰(zhàn)：（1）現(xiàn)有數(shù)據(jù)倉庫的數(shù)據(jù)分析模式，不能有效支撐數(shù)據(jù)快速分析和價值發(fā)現(xiàn)，需要新的交互模式發(fā)掘數(shù)據(jù)的統(tǒng)計相關(guān)性、因果關(guān)系、關(guān)聯(lián)關(guān)系等規(guī)律。（2）數(shù)據(jù)源不斷增多，訪問和數(shù)據(jù)同步變得復(fù)雜。（3）數(shù)據(jù)量增大、應(yīng)用作業(yè)不斷增加，運(yùn)行沉重緩慢。（4）難于支撐海量非結(jié)構(gòu)化數(shù)據(jù)存儲與檢索需求，如影像數(shù)據(jù)、音頻數(shù)據(jù)。我行使用傳統(tǒng)數(shù)據(jù)倉庫多年，雖然尚未完全觸碰到上述問題的極限情況，數(shù)據(jù)倉庫依然穩(wěn)定的在支撐我行業(yè)務(wù)的運(yùn)作，但隨著業(yè)務(wù)的發(fā)展，上述傳統(tǒng)數(shù)倉的困境在我行也有了一定的展現(xiàn)。為提前布局，靈活應(yīng)對，我們進(jìn)行了多種嘗試，包括繼續(xù)深挖現(xiàn)有系統(tǒng)潛力、遷移到大數(shù)據(jù)平臺等。經(jīng)過對業(yè)界和同行的調(diào)研，我們了解到，相當(dāng)部分的銀行最終選擇了將數(shù)據(jù)倉庫遷移到大數(shù)據(jù)平臺，而我行從2017年開始，已經(jīng)引入了源于Hadoop體系的科技大數(shù)據(jù)平臺，具備遷移的能力。下文是我們結(jié)合同業(yè)經(jīng)驗，在我行探索環(huán)境中實驗的，對我行數(shù)據(jù)倉庫進(jìn)行模擬遷移中所作的一些探索經(jīng)驗。二、軟件架構(gòu)選型Hadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)，Hadoop框架最核心的設(shè)計就是：HDFS和MapReduce。HDFS為海量的數(shù)據(jù)提供了存儲，而MapReduce則為海量的數(shù)據(jù)提供了計算。Hadoop是當(dāng)前世界企業(yè)管理大數(shù)據(jù)的基礎(chǔ)支撐技術(shù)。分布式文件系統(tǒng)HDFS：HDFS（HadoopDistributedFileSystem），作為GoogleFileSystem（GFS）的實現(xiàn)，是Hadoop項目的核心子項目，是分布式計算中數(shù)據(jù)存儲管理的基礎(chǔ)，是基于流數(shù)據(jù)模式訪問和處理超大文件的需求而開發(fā)的，可以運(yùn)行于廉價的商用服務(wù)器上。它所具有的高容錯、高可靠性、高可擴(kuò)展性、高獲得性、高吞吐率等特征為海量數(shù)據(jù)提供了不怕故障的存儲，為超大數(shù)據(jù)集（LargeDataSet）的應(yīng)用處理帶來了很多便利。HDFS的架構(gòu)如下圖所示：一般情況下副本系數(shù)為3，HDFS的副本放置策略是：將第一個副本放在本地節(jié)點(diǎn)，將第二個副本放在本地機(jī)架上的另一個節(jié)點(diǎn)，而第三個副本放到不同機(jī)架上的節(jié)點(diǎn)。這種方式減少了機(jī)架間的寫流量，從而提高了寫的性能。機(jī)架故障的機(jī)率遠(yuǎn)小于節(jié)點(diǎn)故障。這種方式并不影響數(shù)據(jù)可靠性和可用性的限制，并且它確實減少了讀操作的網(wǎng)絡(luò)聚合帶寬，因為文件塊僅存在兩個不同的機(jī)架，而不是三個。文件的副本不是均勻的分布在機(jī)架當(dāng)中，1/3的副本在同一個節(jié)點(diǎn)上，1/3副本在同一個機(jī)架上，另外1/3個副本均勻地分布在其他機(jī)架上。分布式計算框架MapReduce：MapReduce是面向大數(shù)據(jù)并行處理的計算模型、框架和平臺，它隱含了以下三層含義：（1）它是一個基于集群的高性能并行計算平臺（ClusterInfrastructure）。它允許用市場上普通的商用服務(wù)器構(gòu)成一個包含數(shù)十、數(shù)百至數(shù)千個節(jié)點(diǎn)的分布和并行計算集群。（2）它是一個并行計算與運(yùn)行軟件框架（SoftwareFramework）。它提供了一個龐大但設(shè)計精良的并行計算軟件框架，能自動完成計算任務(wù)的并行化處理，自動劃分計算數(shù)據(jù)和計算任務(wù)，在集群節(jié)點(diǎn)上自動分配和執(zhí)行任務(wù)以及收集計算結(jié)果，將數(shù)據(jù)分布存儲、數(shù)據(jù)通信、容錯處理等并行計算涉及到的很多系統(tǒng)底層的復(fù)雜細(xì)節(jié)交由系統(tǒng)負(fù)責(zé)處理，大大減少了軟件開發(fā)人員的負(fù)擔(dān)。（3）它是一個并行程序設(shè)計模型與方法（ProgrammingModel&Methodology）。它借助于函數(shù)式程序設(shè)計語言Lisp的設(shè)計思想，提供了一種簡便的并行程序設(shè)計方法，用Map和Reduce兩個函數(shù)編程實現(xiàn)基本的并行計算任務(wù)，提供了抽象的操作和并行編程接口，以簡單方便地完成大規(guī)模數(shù)據(jù)的編程和計算處理。三、服務(wù)器架構(gòu)選型目前市面上主流的服務(wù)器有intelX86架構(gòu)和ARM架構(gòu)。X86架構(gòu)于1978年推出的Intel8086中央處理器中首度出現(xiàn)。X86架構(gòu)（TheX86architecture）是微處理器執(zhí)行的計算機(jī)語言指令集，指一個Intel通用計算機(jī)系列的標(biāo)準(zhǔn)編號縮寫，也標(biāo)識一套通用的計算機(jī)指令集合。X86架構(gòu)的強(qiáng)大并不在于它本身，而在于圍繞著它所建立起來的：軟件生態(tài)。而X86架構(gòu)上面建立了各種各樣的基于X86指令架構(gòu)的程序，這就是它的強(qiáng)大之處。ARM架構(gòu)過去稱作進(jìn)階精簡指令集機(jī)器（AdvancedRISCMachine，更早稱作：AcornRISCMachine），是一個32位精簡指令集（RISC）處理器架構(gòu)，其廣泛地使用在許多嵌入式系統(tǒng)設(shè)計。由于節(jié)能的特點(diǎn)，ARM處理器非常適用于移動通訊領(lǐng)域，符合其主要設(shè)計目標(biāo)為低耗電的特性。在性能方面，對于大數(shù)據(jù)負(fù)載來說，英特爾?至強(qiáng)?可擴(kuò)展處理器為代表的x86處理器性能高于ARM處理器。在生態(tài)方面，大數(shù)據(jù)平臺選擇得到充分驗證和優(yōu)化的硬件平臺尤為重要，大數(shù)據(jù)工作負(fù)載在IntelX86平臺上已經(jīng)適配多年，有著很好的成熟度，也不需要企業(yè)對軟件（如移植）進(jìn)行額外投資，對于IT人員來說，也能快速掌握在IntelX86平臺上的開發(fā)運(yùn)維。例如Spark、DeepLearning、MongoDB等，英特爾?至強(qiáng)?可擴(kuò)展處理器都有經(jīng)過驗證的優(yōu)化指南。在開放性方面，采用英特爾?至強(qiáng)?可擴(kuò)展處理器為代表的x86服務(wù)器腳骨可以實現(xiàn)跨廠商解決方案的兼容性和可持續(xù)性。綜合性能、生態(tài)和開放性等方面，大數(shù)據(jù)平臺選擇采用英特爾?至強(qiáng)?可擴(kuò)展處理器為內(nèi)核的x86服務(wù)器作為計算節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)。大數(shù)據(jù)平臺很多應(yīng)用場景屬于計算密集型，在計算密集作業(yè)下CPU是系統(tǒng)運(yùn)行效率的關(guān)鍵，CPU性能提升能夠大幅度加速整體作業(yè)的運(yùn)行效率。第三代英特爾?至強(qiáng)?可擴(kuò)展處理器提供了具備多至8路的擴(kuò)展能力，每個處理器最多可達(dá)40個核心，可為大數(shù)據(jù)平臺提供進(jìn)一步突破性能瓶頸的基礎(chǔ)。四、遷移選型要求完全開源的Hadoop項目對中小銀行而言有較大的挑戰(zhàn)。首先，開源的Hadoop技術(shù)在對GB到TB級數(shù)據(jù)的處理效率較低，需要較深入的底層調(diào)優(yōu)。其次，只有對海量的數(shù)據(jù)進(jìn)行高效的分析及利用才能將大數(shù)據(jù)中存在的巨大潛在價值轉(zhuǎn)換為實際的商業(yè)價值，企業(yè)亟需完備的解決方案來加速大數(shù)據(jù)應(yīng)用的業(yè)務(wù)創(chuàng)新。最后，中小銀行因編制因素，科技人員數(shù)量有限，熟練掌握大數(shù)據(jù)技術(shù)的技術(shù)人員更是稀少，需要成熟的服務(wù)商進(jìn)行早期的引導(dǎo)和技術(shù)支持。因此，我行要從自身應(yīng)用角度出發(fā)，通過對國內(nèi)外眾多主流大數(shù)據(jù)平臺產(chǎn)品的技術(shù)能力和實現(xiàn)細(xì)節(jié)詳細(xì)了解、對比、篩選，并對候選產(chǎn)品進(jìn)行嚴(yán)格的POC測試，最終選擇更符合我行需求的大數(shù)據(jù)平臺產(chǎn)品。五、遷移策略為降低遷移風(fēng)險、縮短遷移周期、保證遷移進(jìn)度，參考同業(yè)經(jīng)驗，我們將采用了“原樣遷移、重點(diǎn)優(yōu)化”的策略模式。其中，原樣遷移策略表示：（1）參考信息架構(gòu)基本不變，保持?jǐn)?shù)據(jù)倉庫現(xiàn)有的分層架構(gòu)體系。（2）上下游接口基本不變。（3）腳本加工邏輯基本不變。重點(diǎn)優(yōu)化策略則表示：（1）基于新平臺特性進(jìn)行專項優(yōu)化。（2）在維持現(xiàn)有的E-RLDM設(shè)計模式基礎(chǔ)上，重點(diǎn)優(yōu)化基礎(chǔ)模型。（3）基于維度建模構(gòu)建銀行重要業(yè)務(wù)對象的一致性維度和匯總事實，對應(yīng)用層重點(diǎn)優(yōu)化。為貫徹遷移策略，達(dá)到良好的遷移效果，結(jié)合項目管理經(jīng)驗，我們將整個遷移過程分為：現(xiàn)狀調(diào)研、架構(gòu)設(shè)計、模型遷移、數(shù)據(jù)遷移、ETL遷移、接口遷移等多個步驟。每個步驟都是承上啟下，前后關(guān)聯(lián)。六、遷移關(guān)鍵步驟探索1.現(xiàn)狀調(diào)研了解現(xiàn)狀是整個遷移工作的基礎(chǔ)，我們要對數(shù)據(jù)倉庫現(xiàn)狀進(jìn)行詳細(xì)調(diào)研，確定大數(shù)據(jù)上的庫架構(gòu)，整理現(xiàn)有數(shù)據(jù)倉庫的數(shù)據(jù)遷移范圍，完善遷移技術(shù)需求和項目實施方案。調(diào)研內(nèi)容包括數(shù)據(jù)倉庫架構(gòu)、各數(shù)據(jù)表及數(shù)據(jù)量統(tǒng)計、各數(shù)據(jù)模型及DDL、庫表的作業(yè)運(yùn)行和依賴、庫表的下游使用情況、相關(guān)設(shè)計文檔、設(shè)計開發(fā)規(guī)范等等。為更好的做好調(diào)研工作，我們制定了如下的文檔收集指引：序號文檔分類文件收集指引文件收集目的01數(shù)據(jù)架構(gòu)類數(shù)據(jù)架構(gòu)規(guī)劃類文檔：了解行里數(shù)據(jù)架構(gòu)規(guī)劃指引大數(shù)據(jù)平臺的架構(gòu)設(shè)計和庫表規(guī)劃等。02數(shù)據(jù)架構(gòu)說明文檔：了解行里現(xiàn)有平臺的架構(gòu)設(shè)計、落地說明和功能定位等。與遷移后平臺架構(gòu)做對應(yīng)。03基礎(chǔ)模型類信息調(diào)研文檔：對現(xiàn)有平臺上的業(yè)務(wù)系統(tǒng)、信息調(diào)研分析等。支持?jǐn)?shù)據(jù)模型優(yōu)化04數(shù)據(jù)模型文件（E-R圖）：數(shù)據(jù)模型的設(shè)計、歸屬主題域等。支持?jǐn)?shù)據(jù)模型優(yōu)化05ETL開發(fā)文檔：數(shù)據(jù)模型與業(yè)務(wù)系統(tǒng)的映射。支持優(yōu)化后數(shù)據(jù)模型的開發(fā)06標(biāo)準(zhǔn)編碼維護(hù)文檔：基礎(chǔ)層代碼值支持?jǐn)?shù)據(jù)模型的編碼07匯總模型類匯總層模型：匯總層模型的設(shè)計、歸屬主題域等支持匯總層模型優(yōu)化建議08匯總層ETL腳本：匯總層模型的開發(fā)邏輯支持匯總層模型優(yōu)化建議09標(biāo)準(zhǔn)編碼維護(hù)文檔：匯總層代碼值支持匯總層代碼值的編碼10下游應(yīng)用類應(yīng)用需求文檔：下游應(yīng)用的業(yè)務(wù)需求文檔支持對下游應(yīng)用的業(yè)務(wù)邏輯理解11應(yīng)用模型設(shè)計：應(yīng)用數(shù)據(jù)模型的設(shè)計、歸屬主題域等支持應(yīng)用模型優(yōu)化12ETL開發(fā)文檔：應(yīng)用模型與業(yè)務(wù)系統(tǒng)的映射支持應(yīng)用的開發(fā)遷移13標(biāo)準(zhǔn)編碼維護(hù)文檔：應(yīng)用層代碼值支持應(yīng)用的開發(fā)遷移相關(guān)調(diào)研工作，為后續(xù)的設(shè)計、開發(fā)、測試等工作奠定堅實基礎(chǔ)，保障了生產(chǎn)數(shù)據(jù)遷移的可靠性。2.架構(gòu)設(shè)計在架構(gòu)設(shè)計方面，我們即要考慮當(dāng)前遷移的需求，也要結(jié)合行里的規(guī)劃及場景需求，通盤考慮，相關(guān)設(shè)計既要立足現(xiàn)在，更能面向未來。為了減少實時類應(yīng)用與批量類應(yīng)用之間的相互影響，保證重要系統(tǒng)性能及穩(wěn)定性，我們優(yōu)化早期單集群的架構(gòu)，將重要應(yīng)用獨(dú)立到一個集群，稱為應(yīng)用服務(wù)區(qū)；其余應(yīng)用部署到另外集群，稱為基礎(chǔ)數(shù)據(jù)區(qū)，最終邏輯架構(gòu)設(shè)計如下：對于應(yīng)用服務(wù)區(qū)，首先從技術(shù)上它只能滿足小批量數(shù)據(jù)處理，對數(shù)據(jù)的查詢及加工處理延時要求比較高，一般要求必須在1秒內(nèi)返回結(jié)果，不能接受超過2秒的延時。其次從業(yè)務(wù)的角度看在應(yīng)用服務(wù)區(qū)的應(yīng)用都是對我行比較重要的，比如我行的生產(chǎn)運(yùn)營系統(tǒng)-銀行柜面客戶歷史數(shù)據(jù)查詢系統(tǒng)，又比如我行對客系統(tǒng)進(jìn)行數(shù)據(jù)支撐-APP應(yīng)用中的客戶收益明細(xì)、實時風(fēng)險等。對于基礎(chǔ)數(shù)據(jù)區(qū)定義是大批量數(shù)據(jù)處理平臺，海量數(shù)據(jù)存儲平臺，它也可以滿足小批量數(shù)據(jù)處理的需求，不過因為存在大批量數(shù)據(jù)處理應(yīng)用資源擠壓問題，小批量數(shù)據(jù)處理可能存在性能波動的風(fēng)險，我們一般用于承載我行數(shù)據(jù)湖業(yè)務(wù)、數(shù)據(jù)倉庫業(yè)務(wù)、營銷分析、報表平臺等。采用此架構(gòu)，兩個集群穩(wěn)定運(yùn)行，實時查詢與批處理等大任務(wù)拆分開，實時查詢可穩(wěn)定對外提供服務(wù)；基礎(chǔ)數(shù)據(jù)區(qū)全天皆可運(yùn)行批處理等大作業(yè)，集群處理能力更強(qiáng)等。3.基礎(chǔ)模型層遷移及優(yōu)化在我行中，模型層模型主要以E-R(實體-屬性）構(gòu)建邏輯數(shù)據(jù)模型（LDM），來反映銀行的業(yè)務(wù)屬性及其關(guān)系，其是邏輯性的，與具體承載平臺無關(guān)。因此在實際遷移中，我們要基本保證了數(shù)據(jù)模型的不變。但在項目實施過程中，我們也要借機(jī)進(jìn)行成熟度評估，然后根據(jù)平臺特性構(gòu)建新的物理模型。我們結(jié)合實際情況整理遷移判斷邏輯如下：邏輯模型在設(shè)計過程中，為保證模型的穩(wěn)定性，往往采用泛化、子類、抽象、拉鏈等設(shè)計模式。在實際物理化時，往往都是嚴(yán)格遵守了與邏輯模型一致的1:1物理化方式，導(dǎo)致模型的性能問題。針對這些設(shè)計模式，可以采用適當(dāng)?shù)奶鼗?、上收下放、還原等優(yōu)化措施。序號優(yōu)化方式優(yōu)化策略說明01子類上收下放例如主表信息下沉，子表冗余主表屬性信息02泛化適度還原例如商戶、機(jī)構(gòu)從當(dāng)事人剝離，獨(dú)立為根節(jié)點(diǎn)03抽象按需拉橫例如:建立聯(lián)系方式的橫表04屬性按需冗余例如：當(dāng)前表冗余部分緩變歷史屬性05屬性垂直拆分例如：根據(jù)屬性相關(guān)性和變化性對超寬表進(jìn)行拆分泛化適度還原優(yōu)化示意如下：屬性按需冗余優(yōu)化示意如下：4.數(shù)據(jù)遷移在數(shù)據(jù)的遷移中，為實現(xiàn)遷移的自動化，我們需要使用服務(wù)商的數(shù)據(jù)遷移工具，相關(guān)工具要能從現(xiàn)有數(shù)據(jù)倉庫中讀取DDL信息，自動轉(zhuǎn)化為大數(shù)據(jù)平臺的DDL。相關(guān)工具轉(zhuǎn)化速度取決于大數(shù)據(jù)平臺的資源限制及網(wǎng)絡(luò)帶寬，根據(jù)同業(yè)的經(jīng)驗，理論上遷移速率可達(dá)100-250M/S甚至更高。遷移過程示意如下：5.ETL遷移針對數(shù)據(jù)倉庫的ETL工作，從技術(shù)實現(xiàn)角度進(jìn)行分析，主要包括（1）物理模型設(shè)計及DDL生成；（2）平臺間數(shù)據(jù)遷移；（3）基礎(chǔ)模型層、匯總層、應(yīng)用層等ETL開發(fā)；（4）遷移數(shù)據(jù)核對這幾個部分。其中伍立模型設(shè)計及DDL生成是最核心的部分，本次遷移中，我們實施了如下設(shè)計原則，充分保障了存量數(shù)據(jù)遷移的可靠性。各層模型平臺物理化建議：數(shù)據(jù)分層存儲設(shè)計存儲格式建議設(shè)計要點(diǎn)建議臨時區(qū)TEXT歷史區(qū)ORCTransaction分區(qū)+分桶基礎(chǔ)區(qū)ORCTransaction分區(qū)+分桶匯總區(qū)ORCTransaction分區(qū)+分桶應(yīng)用區(qū)Holodesk+ORCTransaction分區(qū)+分桶平臺模型物理化原則建議：分類原則TEXT表Text表不要用作歷史數(shù)據(jù)存儲Text原則上僅作為數(shù)據(jù)入庫緩沖層（僅存儲當(dāng)天數(shù)據(jù)）和臨時文本入庫后分析用ORC表不需要事務(wù)支持的ORC表采用ORC非事務(wù)表分區(qū)建議分區(qū)采用rangepartition建議分區(qū)字段選擇->日期字段（或地區(qū)字段）不要使用二級分區(qū)建議分區(qū)數(shù)控制在200個以下分桶單個桶的數(shù)據(jù)量大小應(yīng)小于200M（壓縮后）分桶表最小分桶數(shù)設(shè)置為3單個分區(qū)分桶數(shù)在500個以內(nèi)桶的個數(shù)為不包含31的質(zhì)數(shù)分桶字段應(yīng)選取表中的唯一值字段（如果無唯一字段，分桶字段重復(fù)率應(yīng)小于1%）Hyperbase表唯一性原則：rowkey要保證唯一性，不然在插入數(shù)據(jù)是會覆蓋之前的數(shù)據(jù)，造成數(shù)據(jù)丟失的風(fēng)險散列原則：如果Rowkey是按時間戳的方式遞增，不要將時間放在二進(jìn)制碼的前面，建議將Rowkey的高位作為散列字段，由程序循環(huán)生成，低位放時間字段，這樣將提高數(shù)據(jù)均衡分布在每個Regionserver實現(xiàn)負(fù)載均衡的幾率長度原則：建議是越短越好，不要超過16個字節(jié)ES表一個shard對應(yīng)數(shù)據(jù)不要超過20Gshard數(shù)量小于分配（頁面設(shè)置的盤符）且可用的（磁盤剩余可用空間>50G/10%）磁盤數(shù)結(jié)合以上原則，我們可以根據(jù)現(xiàn)有的ETL腳本，從腳本還原出ETL映射文檔，映射文檔對腳本中的執(zhí)行步驟，找出目標(biāo)表字段與源表、源字段的對應(yīng)關(guān)系，并分離出JOIN、WHERE、GROUPBY,ORDERBY,QUALIFY等子句，然后進(jìn)行改寫，生產(chǎn)大數(shù)據(jù)平臺的存儲過程，最終經(jīng)過核驗后落地實施。6.數(shù)據(jù)訪問接口的遷移—ODBC/JDBC大數(shù)據(jù)平臺主配置文件為Server.data，主要配置信息描述如下：連接串變?yōu)椋簀dbc:hive2://gateway地址:6666-nuser-ppasswd7.硬件配置集群27節(jié)點(diǎn)采用IntelX86架構(gòu)物理服務(wù)器進(jìn)行配置，保證各節(jié)點(diǎn)的計算性能詳細(xì)配置如下：硬件配置CPU2xIntel(R)Xeongold5115MEM256GBHDD20x2.5SAS1.2TBHDD,2x2.5SATA960GBSSD集群各節(jié)點(diǎn)磁盤配置詳情如下：8.角色規(guī)劃集群各角色均勻分布在集群節(jié)點(diǎn)，詳細(xì)規(guī)劃如下：9.容量規(guī)劃整體項目容量只要針對存量和增量兩大部分進(jìn)行，下表是我們結(jié)合一些數(shù)據(jù)，對數(shù)據(jù)倉庫遷移所需容量進(jìn)行的詳細(xì)規(guī)劃模擬計算，實際實施時需再根據(jù)情況重新計算?，F(xiàn)有數(shù)據(jù)倉庫存儲一、基礎(chǔ)指標(biāo)指標(biāo)1存量數(shù)據(jù)（T）280指標(biāo)2每天增量（T）4指標(biāo)3壓縮比4二、吞吐量指標(biāo)指標(biāo)1解壓后數(shù)據(jù)大小（T）1120大數(shù)據(jù)平臺存儲一、基礎(chǔ)指標(biāo)指標(biāo)1壓縮比3.5指標(biāo)2副本數(shù)3二、吞吐量指標(biāo)指標(biāo)1存量數(shù)據(jù)存儲（T）裸磁盤*壓縮比*0.7（可用率）960指標(biāo)2第一年空間（T）(日增量/1024)*300(工作日)1460指標(biāo)3第二年空間（T）每年數(shù)據(jù)增幅*20%1750指標(biāo)4第三年空間（T）每年數(shù)據(jù)增幅*20%2100指標(biāo)5所需要總空間（存量+三年增量數(shù)據(jù)）（T）6270指標(biāo)6所需要節(jié)點(diǎn)數(shù)量（按照目前機(jī)器配置20T*10*0.7實際存儲空間）47（3管理+44數(shù)據(jù)）七、一些有意義的嘗試機(jī)架感知調(diào)整：HDFS默認(rèn)情況下雖然有3個副本，理論上能有效的保障數(shù)據(jù)不丟失，我們?yōu)榱烁行У奶岣邤?shù)據(jù)的可用性、可靠性以及更高的網(wǎng)絡(luò)帶寬利用率，可以考慮在實施過程中啟用HDFS的機(jī)架感知。在默認(rèn)3副本的情況下，啟用機(jī)架感知，HDFS的存放策略是將一個副本存放在本地機(jī)架節(jié)點(diǎn)上，一個副本存放在同一個機(jī)架的另一個節(jié)點(diǎn)上，最后一個副本放在不同機(jī)架的節(jié)點(diǎn)上。這樣即保證了讀寫效率，又通過機(jī)架的隔離進(jìn)一步保障了數(shù)據(jù)安全性。啟用機(jī)架感知需要配置文件core-site.xml，配置項如下：<property><name></name><value>/etc/hadoop/topology.sh</value></property>value是一個shell腳本，主要的功能是輸入DataNode的IP返回對應(yīng)的機(jī)架ID。NameNode啟動時會判斷是否啟用了機(jī)架感知，若啟用則會根據(jù)配置查找配置腳本，并在收到DataNode的心跳時傳入其IP獲取機(jī)架的ID存入內(nèi)存中的一個map中。一個簡單的配置腳本示意如下：#!/bin/bashHADOOP_CONF=etc/hadoop/configwhile[$#-gt0];donodeArg=$1exec<${HADOOP_CONF}/topology.dataresult=""whilereadline;doar=($line)if["${ar[0]}"="$nodeArg"]||["${ar[1]}"="$nodeArg"];thenresult="${ar[2]}"fidoneshiftif[-z"$result"];thenecho-n"/default-rack"elseecho-n"$result"fi

done

其中topology.data的格式為：節(jié)點(diǎn)（ip或主機(jī)名）/交換機(jī)xx/機(jī)架xx，一個參考配置樣例如下：

xxx.xxx.xxx.91tbe192168147091/dc1/rack1xxx.xxx.xxx.92tbe192168147092/dc1/rack1xxx.xxx.xxx.93tbe192168147093/dc1/rack2xxx.xxx.xxx.94tbe192168147094/dc1/rack3xxx.xxx.xxx.95tbe192168147095/dc1/rack3xxx.xxx.xxx.96

tbe192168147096

/dc1/rack3修改完成后，可以使用./hadoopdfsadmin-printTopology查看機(jī)架配置信息?；厥照驹O(shè)置：為防止在線數(shù)據(jù)被誤刪，我們建議在實施時，開啟了HDFS的回收站功能，開啟后，HDFS會為每個用戶創(chuàng)建一個專屬的回收站目錄（/user/${}/.Trash），用戶刪除文件時，實際上是被移動到了回收站目錄，在緊急情況下能夠及時從回收站恢復(fù)這些數(shù)據(jù)。其主要配置示意如下：<property><name>erval</name><value>4320</value><description>Numberofminutesafterwhichthecheckpointgetsdeleted.Ifzero,thetrashfeatureisdisabled.</description></property>

<property><name>erval</name><value>15</value><description>Numberofminutesbetweentrashcheckpoints.Shouldbesmallerorequaltoerval.Everytimethecheckpointerrunsitcreatesanewcheckpointoutofcurrentandremovescheckpointscreatedmorethanervalminutesago.</description></property>其中，erval表示回收站數(shù)據(jù)保存周期，單位是分鐘，我