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

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

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

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

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ù)被誤刪，我們建議在實(shí)施時(shí)，開啟了HDFS的回收站功能，開啟后，HDFS會(huì)為每個(gè)用戶創(chuàng)建一個(gè)專屬的回收站目錄（/user/${}/.Trash），用戶刪除文件時(shí)，實(shí)際上是被移動(dòng)到了回收站目錄，在緊急情況下能夠及時(shí)從回收站恢復(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ù)保存周期，單位是分鐘，我