導讀

      本方案以某金融企業大資料平臺建設方案為例，面對企業內部的資料現狀提出合理化建議，基於商業版Hadoop資料平臺搭建資料倉儲系統，實現資料資產的充分利用，結合當時現狀推薦國產自主研發商業版Hadoop平臺TDH做為基礎平臺，以下為方案概述。

01 

背景目標

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

1.1 背景

1.1.1 資料基礎

      隨著公司業務的發展，公司建設的IT系統數量逐漸增多，各系統交易資料快速增長，系統間資料互動也不斷增加，同時絕大部分資料分散在各自系統中，形成資料孤島，不便於整體統計分析。

      為了整合公司各系統資料，搭建一個資料精確、效能高效、方便分析的資料倉儲系統。透過該系統可對上游系統的各類資料按照主題模型、應用集市進行彙總，為下游IT系統輸出標準化、模型化的資料，以滿足各系統資料需求，緩解各系統互動壓力，同時利用資料倉儲高效的資料處理能力，縮短報表生成時間，提高資料統計效率，快速滿足公司各部門資料包表需求。面對這一系列的挑戰，我們認為整合內外部資料在公司的利用問題是提升公司業務能力的首要需求。

1.1.2 痛點及需提升的能力

       資料增長迅速，如果加上非結構化資料，未來幾年的資料儲存將猛增，如何對這些海量歷史資料資產進行有效的儲存、管理、整合，並在此基礎上進行快速共享、計算、分析，最終達到對業務的有效指導是本系統的建設關鍵。在大資料應用平臺專案基礎軟體及服務建設過程中，主要會面臨以下挑戰：

1. 擴充套件性：當資料量達到一定限度之後，無論是資料儲存、分析、查詢，都會受到極大的限制，系統的橫向擴充套件性的能力將是系統建設的重要考量之一。

2. 價格: 系統的橫向擴充套件，必然會帶來軟體、硬體成本的增加，以及後期升級、維護、擴充套件的成本的投入也是系統擴充套件面臨的挑戰。

3. 效能：資料動輒TB、甚至PB，面對如此海量的資料，若要進行高效的計算、分析，為業務提供有效的指導，必須要滿足業務允許的時間要求。

1.1.3 大資料趨勢

      隨著移動網際網路、雲端計算、物聯網和大資料技術的廣泛應用，現代社會已經邁入全新的大資料時代。掌握大資料資產，進行智慧化決策，已成為企業勝出的關鍵。

      越來越多的企業開始重視大資料戰略佈局，重新定義自己的核心競爭力，從資料中揭示規律，瞭解過去、知悉現在、洞察未來，資料驅動企業執行與決策的科學性，構建智慧企業，打造核心競爭力。

      資料的爆炸式增長以及價值的擴大化，將對企業未來的發展產生深遠的影響，資料將成為企業的核心資產。如何應對大資料，挖掘大資料的價值，讓大資料為企業的發展保駕護航，將是未來資訊科技發展道路上關注的重點。

圖1 建設背景

1.2 目標

       透過搭建基於商業版Hadoop大資料平臺的資料倉儲系統，實現對我司資料資產的充分利用。整合企業各業務系統中的資料，為企業提供統一的高質量的業務資料檢視，進一步滿足提升企業的經營管理分析和決策的需要。

圖2 建設目標

02 

  建設方案  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。從設計稿出發，提升頁面搭建效率，亟需解決的核心問題有：

2.1 總體架構

      

圖3 總體架構圖

      總體架構是從資料層次劃分、資料分佈、資料流轉、資料儲存等多個角度對企業資料架構進行規劃的合稱。涵蓋了從匯入源資料，經過集中整合的資料加工和儲存，最後透過資料展示層呈現給終端使用者的全過程。

從總體邏輯架構中可以看出，資料架構包括內容如下：

1. 資料來源層

      源資料層是指資料倉儲系統的資料來源，為資料倉儲提供資料。資料倉儲的資料主要來自業務系統、三方系統以及部分管理系統。源資料層包含傳統的結構化與非結構化資料來源，對於消費金融的資料倉儲系統，作為資料來源的系統將包括核心信貸、財務、人力資源、移動營銷、三方資料平臺等。

2. 儲存與管理層

       資料儲存與管理層是資料架構的核心，採用Hadoop平臺+FS-LDM方式構建，集中存放企業的各類資料，並提供資料支援服務。資料儲存按照用途和業務目標，分為資料獲取、資料整合與資料加工、資料服務訪問等。

【資料倉儲金融行業邏輯資料模型FS-LDM說明參考：

FS-LDM說明-參考1

https://blog.csdn.net/BabyFish13/article/details/123702243?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165579505616782246470236%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=165579505616782246470236&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-1-123702243-null-null.142^v19^rank_v32,157^v15^new_3&utm_term=FS-LDM&spm=1018.2226.3001.4187

FS-LDM說明-參考2

https://blog.csdn.net/weixin_44441757/article/details/117962689?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165579505616781667894094%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=165579505616781667894094&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v32_ecpm-21-117962689-null-null.142^v19^rank_v32,157^v15^new_3&utm_term=FS-LDM&spm=1018.2226.3001.4187

3. 資料應用層

      專題分析、報表分析等所使用的資料，將已經統計彙總好資料對外發布，支援應用的查詢與專題分析。透過介面的方式直接查詢資料或共享層即可得到想要的資料。

4. 資料展示層

      資料準備好後，透過門戶應用提供給使用者，讓資料最大化地發揮價值。應用產品可考慮使用帆軟報表工具、iRecharts、Cognos等進行資料分析展示。

5. 終端使用者層

       按照使用者使用的方式和特點，將使用者分為不同層級，如：領導層、業務操作人員、決策人員、知識工作者/業務分析人員，管理員等等，用於區分資料許可權隔離，保證資料安全。

2.2 產品推薦(TDH)

       

2.2.1 產品優勢

       大資料平臺Transwarp Data Hub基於Spark&Hadoop2.7.2，擁有眾多自主研發的核心技術，無論相比較於開源的Hadoop平臺，還是國內、國外的商業廠商大資料軟體，都具備較大的技術優勢。

2.2.2 技術優勢

      Transwarp Data Hub（簡稱TDH）是國內首個全面支援Spark的Hadoop發行版，也是國內落地案例最多的商業版本，它是國內外領先的高效能平臺，比開源Hadoop2版本快10x~100x倍。TDH應用範圍覆蓋各種規模和不同資料量的企業，透過記憶體計算、高效索引、執行最佳化和高度容錯的技術，使得一個平臺能夠處理10GB到100PB的資料，並且在每個數量級上，都能比現有技術提供更快的效能；企業客戶不再需要混合架構，TDH可以伴隨企業客戶的資料增長，動態不停機擴容，避免MPP或混合架構資料遷移的棘手問題。

       Transwarp的大資料綜合平臺（Transwarp Data Hub, 簡稱TDH）包含四個組成部分: Transwarp Hadoop基礎平臺，Transwarp Inceptor分散式記憶體分析引擎，Transwarp Hyperbase分散式實時線上資料處理引擎和Transwarp Stream流處理引擎。大資料平臺專案基礎軟體及服務資料處理平臺需要Transwarp Hadoop基礎平臺，Transwarp Inceptor分散式記憶體分析引擎，Transwarp Hyperbase分散式實時線上資料處理引擎，Transwarp Stream流處理引擎四個產品元件。

圖4 TDH技術架構圖

• 完整的SQL支援

      透過TPC-DS99個標準測試集，99%的SQL 2003支援，唯一支援PL/SQL的引擎（98%），唯一支援ACID分散式事務的SQL引擎；定位資料倉儲和資料集市市場，可用於補充或替代Oracle、DB2等分析用資料庫。（*注：當時現狀）

• 高效記憶體/SSD計算

      支援SSD的基於Hadoop的高效計算引擎，可比硬碟快一個數量級；可用於建立各種資料集市，對接多種主流報表工具，支援高併發查詢。

• 完整的分散式機器學習演算法庫

      支援（超過50餘種）的分散式統計演算法和機器學習演算法，同時整合超過5000個R語言演算法包。適合金融業風險控制、反欺詐、文字分析、精準營銷等應用。

2.3 模型設計

想大做小，逐漸豐富

1. 本期建設，可以只實現十大主題域中的幾個或某些主題域的關鍵實體，在後續階段慢慢豐富需要的主題域實體。

2. 根據調研及在金融行業的實施經驗，本期實現當事人、產品、協議、事件等關鍵主題，在逐漸假設次要主題，如地址、營銷等。

基礎模型保持穩定

1. 結合FS-LDM模型在金融行業有大量實施案例，事實證明FS-LDM模型適應各種型別的金融企業，支援全面的金融業務。

2. 雖然每家金融公司的後設資料和業務差異較大，但均能使用同樣的FS-LDM架構。

2.3.1 方法步驟

圖5 模型設計方法步驟

模型設計方法透過如下6個步驟進行說明：

1. 前期準備：此工作將基於資料來源範圍中界定的資料來源，全面分析評估公司的客戶資訊現狀、資料現狀、資料質量狀況，確定資料整合的優先順序，以支援企業級資料倉儲建設長遠目標。收集原系統需求文件，操作左手、表結構說明書、程式碼值、樣本資料、相關指令碼等。

2. 交流研討：確定客戶化策略，明確LDM客戶阿虎的工作方式和工作目標，確定工作模板。

3. 資訊調研：包括資料表分類、欄位級資訊整理、問題追蹤記錄、調研訪談會議紀要、ID調研報告。其中資料表分類、欄位級資訊整理、問題追蹤記錄是資訊調研最重要的產出物，是後續邏輯模型設計、資料對映的基礎，也是後續資料倉儲維護、應用集市開發所需的重要文件。

4. 統一業務定義：確定概念模型的主題域及其內容，包括主題域的公共碼鍵、主題域之間的聯絡以及充分代表主題的屬性組。制定模型命名規範根據經驗提供模型命名規範的初稿，雙方討論確定邏輯建模過程中使用的通用命名規範，制定規範文件，確定客戶化範圍。

5. 客戶化FS-LDM：概念模型、邏輯模型設計將基行業完整的金融業邏輯資料模型LDM產品，結合資料來源分析的結果進行客戶化，形成邏輯資料模型（LDM），能夠滿足未來基於資料倉儲的各項分析型業務應用的需要。

6. 模型驗證：包括資料模型、應用模型的驗證，及資料合理性及資料規範性的驗證。

2.3.2 設計規範

       設計規範包括模型命名規範，資料型別定義規範，佈局規範，註釋規範。

1. 命名規範：包括對邏輯資料模型的命名規範和物理模型的命名規範

✔ 採用統一的中英文詞庫來維護命名

✔ 邏輯資料模型中實體和屬性中文命名不超過30個漢字

✔ 物理資料模型表名和欄位名不超過30個英文字元

2. 資料型別定義規範：倉庫中的欄位長度儘量滿足相應源系統欄位中最大長度的要求，對常用資料型別分檔次進行預定義。

3. 佈局規範：選用ERwin作為模型的設計工具，對主題命名方式、子主題設計方式進行規範，佈局上，對實體進行佈局屬性進行有序排列，選用特殊顏色對不同主題熟悉進行有效區分，為使用帶來便捷。

4. 註釋規範：對實體/表進行註釋規範說明，對屬性/欄位進行註釋規範說明，對指令碼註釋進行規範，杜絕無註釋情況發生。

2.3.3 設計原則

圖6 模型設計原則

數倉分層設計採用三層架構，基礎層、彙總層、集市層，設計原則如下：

基礎層：

•中性的，共享的：不針對某個特別的應用而設計

•靈活的，可擴充套件的：能以第三正規化存放最詳盡的業務資料

•穩定的，經得起考驗的：能夠在很長時間內保持穩定性

•規範的，易懂的：使用規範的業務語言進行模型設計

彙總層：

•層次分明：設計分層次，邏輯上分為預處理層和輕度彙總層

•應用驅動：可以借鑑行業經驗，但自身需求是根本

•提煉共性：彙總層需提煉出不同應用的公共指標

•迭代開發：彙總層建設是一個迴圈往復的過程，不可能一步到位

集市層：

•支援星型建模：集市層未來支援星型建模

•業務驅動：需要針對每個特定業務定製建立集市層模型

•兼顧效率與資料粒度的需要：在模型設計時需要在二者中取得平衡

2.3.4 主題劃分及主題關係

採用分類設計的策略

1. 重點設計主題（客戶、協議、事件、資產、財務）

特點：是模型中的重點主題，且在源系統中有豐富的資料來源和參照。

目標：儘量保持完整性、豐富性。

策略：按照FS-LDM的框架進行設計，同時補充銀行的個性資料元素。

2. 自主設計主題（營銷活動、渠道、機構、產品）

特點：非核心主題，基本沒有或者僅有非常少的資料來源和參照。

目標：保證模型架構的完整性和擴充性。

策略：按照FS-LDM進行設計，將來根據實際情況調整。

3. 簡化設計主題（地域）

特點：模型的重要參考主題，一般情況下源系統有資料，但定義和使用方法與FS-LDM不匹配。

目標：暫不進行唯一地址識別，但要完整保留此類資訊。

策略：暫作為PARTY等的屬性資訊進行設計。

下圖為劃分的主題說明及物理模型字首說明：

圖7 主題劃分及物理模型對應圖

圖8 主題物理模型關係圖

03 

  實施計劃 

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。從設計稿出發，提升頁面搭建效率，亟需解決的核心問題有：    

3.1 實施關鍵點

一個成功的資料類專案需要具備以下4個關鍵要素：

1. 專業的實施與服務團隊。

2. 先進成熟的實施方法。

3. 統一規範的資料模型。

4. 最為重要的是經過驗證的成功案例。

圖9 實施關鍵點圖

3.2 軟硬體配置建議

       基於客戶業務系統現狀及對系統資料量計算評估，推薦以下軟硬體配置資訊供客戶進行選擇。可在合理的範圍內進行利舊取捨，以做到資源的合理利用。

下表為軟體資訊列表：

表1 軟體配置資訊表

下表為硬體件資訊列表：

表2 硬體配置資訊表

3.3 文件產出

   

      一個完整的專案交付，需定製好專案實施範圍清單，包括專案管理在內的業務設計、技術設計及系統開發測試，到最終上線及知識交接轉移，同時也需要交付相關使用說明書等。

下表為專案實施範圍清單及專案交付清單列表：

   表3 專案實施範圍列表 （左）  

  表4 專案交付清單表 （右） 

3.4 計劃排期

      本專案基於客戶甲方要求分為8個階段和40個工作內容，對專案整體排期進行分步驟實施推進。在專案經理的管控下對工作進行詳細拆分，在不同的階段輸出相關文件，保證專案順利實施。 

圖10 專案管理階段圖

04 

  總結   

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

      建立企業大資料平臺，實現資料資源（結構化、半結構化和非結構化資料）的歸集、整理、加工和分析，並利用大資料相關技術及資料分析挖掘方法，建立資料應用模型，為企業提供決策支援、產品創新、交叉營銷、流程最佳化、服務支撐以及風險管控等服務，有效地挖掘資料的價值，實現資料資源的“共享、共用、共贏”。