系統建設目標

建設背景

監管背景

2016年12月30日頒布的《證券公司全面風險管理規范》要求當中，首次提出“證券公司應當建立健全數據治理和質量控制機制。積累真實、準確、完整的內部和外部數據，用于風險識別、計量、評估、監測和報告”。“證券公司應將數據治理納入公司整體信息技術建設戰略規劃，制定數據標準，涵蓋數據源管理、數據庫建設、數據質量監測等環節?！?/p>

?

業務背景

中國金融行業發展迅速，隨著互聯網，軟件等行業的推陳出新，全球信息化的進程也日益加快。證券公司在金融市場上發揮著日益重要的作用，也面臨著市場、信用、操作、流動性各類風險的嚴峻挑戰，證券公司應對這些風險的能力直接影響著金融市場和金融秩序的穩定性。與此同時，數據已經成為證券公司參與競爭的重要武器。

證券公司長期積累了大量的內部及外部數據，這些數據除了支持證券公司的自營、資管等各項核心業務，加快金融產品和服務創新，還越來越多的用于風險控制、決策分析、績效考核等管理領域。如果數據錯誤、遺漏、缺乏統一標準、共享與整合程度不足，將導致問題數據如雪球般越滾越大，導致相關領域業務無法正常開展或者違反相關監管要求，導致決策出現偏差公司面臨嚴重的風險。因此，建設數據中心，提高數據治理水平是提升證券公司核心競爭力的關鍵。通過數據中心系統的建設、數據治理過程的推進，證券公司可以提高其數據質量，形成數據資產，進而提高經營管理水平和風險管理能力。

技術背景

面對證券業協會對數據治理的監管要求和機構自身對加強風險控制、提升運營能力及關鍵業務的能力的需要。證券公司在數據治理工作上也面臨著挑戰：內外部數據呈爆炸式增長、新產品的出現、競爭環境和流程日益復雜、上級監管越來越細致。

數據治理除了構建專門的數據治理組織架構和工作流程之外，同時也需要有一個更加完善的信息技術系統規劃戰略。國內券商在IT系統建設過程當中，由于各種原因，雖然IT化程度相對較高，但是各種數據都存在各自的業務系統對應的IT系統當中獨立存在，同時各個應用系統由不同的開發商開發實施，采用的數據庫、技術路線都不一樣，并不存在統一的數據標準和數據模型，孤島化存在的數據為后續的數據分析、數據挖掘、風險管理帶來了重重困難。

隨著各個業務系統之間協同工作和數據交互越來越多并且越來越復雜，這樣就造成了各個應用系統間數據關系形成了一張錯綜復雜的數據關系網，給系統的運行維護以及后續的系統建設和集成帶來了不小的困難。點對點的數據交互模式也給核心系統帶來了巨大的壓力。

為了解決上述問題，有必要建設一個向下可以彈性兼容各個不同的數據源，向上可以為各應用系統提供數據支持的數據中心。數據中心的建立不但可以規范企業數據，減少數據冗余，減輕核心交易系統壓力，增強系統的易維護性，提高系統的可擴展性，而且以數據中心為基礎和載體進行數據治理工作可以達到事半功倍的效果。

系統現狀

數據存儲未整合，不利于充分利用

證券公司在運營過程中生成了大量的數據，這些數據包括交易、清算、營銷、財務、資訊、人力資源、資產管理、自營等企業數據，雖然這些數據部分已經同步到同一服務器，但數據未進行有效整合，各系統依舊孤立。企業決策人員、統計分析人員、業務人員很難根據自己的意愿，及時地、靈活而多角度地查詢和分析數據，也不能充分利用、發掘現有數據，實現更大的效益。

數據標準不統一，不利于價值發現

證券公司現有系統之間數據的結構和標準都不統一，如果借助傳統的方法進行數據分析，不但繁瑣復雜，而且無法滿足對業務變化的快速反應，更不能站在整個企業的角度了解企業整體情況并發現數據之間的聯系做出進一步的分析和預測。

數據交換不統一，不利于質量控制

目前各個系統之間的數據交換都采用各自的采集程序，沒用統一的監控、跟蹤和核對機制，很難保證數據的完整性，也不利于問題的發現和定位。

服務交換不統一，不利于服務共享

各系統間存在功能冗余且口徑不一等問題，缺少統一的服務交換平臺，無法實現交易系統、呼叫中心、營銷管理、投顧系統、CRM等各系統的服務充分共享。

外部數據未接入，不利于全面分析

證券金融市場有很多的外部數據，比如征信數據、互聯網輿情數據、競爭公司數據等，這些數據現在都沒有接入到證券公司的IT系統中，造成很多數據分析工作不夠全面，不利于業務的全面展開。

系統目標

系統定位

搭建數據倉庫，作為數據治理工作的基礎和載體

完成公司級的數據倉庫搭建工作，成為公司級數據治理工作的載體。在數據倉庫中進行元數據管理、數據質量管理、數據標準定義、數據口徑統一管理等數據治理管控工作。

整合各個應用系統數據，提供標準的數據接口

完成源系統調研，整合各個應用系統數據，提供標準的數據接口，形成公司唯一的、標準化的數據源，提供標準和靈活的數據交換接口，支撐各個業務系統的數據訪問，實現數據資源的共享。

優化數據交換和IT應用系統架構

建立公司的數據基礎平臺，完成公司要求的數據輸入輸出，將網狀的數據關系優化為星狀。實現ETL過程和數據質量的自動化管理，對ETL過程和數據質量進行全面的監控和管理維護。

建立適用于證券公司各類業務的完整指標體系

建立適合公司實際業務運行情況的指標體系，提供現有的指標庫體系供參考，涵蓋公共指標、風控指標、財務指標、集團聯動指標、營業部/分公司等經營機構分類評價指標、自營/資管等各業務條線指標等。建立符合公司實際情況的企業級數據倉庫技術架構和數據模型，為各類統計報表、領導者駕駛艙和數據分析挖掘提供數據支持。

完成前臺應用建設，為證券公司各業務部門提供數據支持

根據證券公司各業務部門的實際業務需求完成領導者駕駛艙的開發、數據分析和數據挖掘開發、分析報表開發以及交互式報表等前臺應用開發。

系統總體目標

證券公司數據中心的總體建設目標是建立基礎數據模型、ETL調度平臺、數據中心指標體系、數據質量管理平臺、數據接口服務、領導者駕駛艙等，形成統一數據標準、確保數據采集完整、保證ETL數據質量、形成統一的數據展現。具體目標為：

建立符合證券公司實際需求的數據中心技術架構。

提供符合監管要求和證券公司業務需求的數據治理體系架構。

建立符合證券公司實際需求的企業級數據模型。

建立方便內部管理、幫助數據理解、增加分析敏捷性的公司級的覆蓋技術元數據和業務元數據的元數據管控體系。

完成數據標準化工作，形成公司唯一的、標準化數據源，支撐各項業務管理系統的數據訪問。

支撐公司各項業務數據的統一采集、統一存儲、統一訪問管理等功能。

使用專業成熟的ETL工具，進行對不同種類數據的抽取、轉換、加載等各項部署、實施，并能對啟動條件、依賴關系、狀態及錯誤日志統一管理。同時ETL工具和調度平臺能夠支持和大數據平臺進行數據交互。

實現ETL全流程調度自動化管理，對ETL 過程進行全面監控和管理維護。

實現ETL過程中的數據質量管理工作，靈活通過校驗方式和校驗規則的搭配，保證數據中心數據質量。

建立全面和標準的數據中心指標體系，統一管理證券公司各類業務口徑，全面的反映證券公司各項業務的原子指標。

提供標準和靈活的數據接口，保證現有系統的數據源平滑過渡到數據中心，支持公司擬建和未來需建的各類系統。

按需要提供各類數據的匯總，滿足數據報表和不同主題數據集市的需要。

通過對基礎數據模型的分析，形成數據集市，并展現公司級別的經營狀況。

建設原則

本項目是xx邁入大數據管理的第一步，旨在利用大數據技術搭建數據中心，對當前業務系統的數據進行采集集中、組織規劃，從而為后續的業務開展和公司管理提供數據支持。本項目在建設過程中，要遵循如下原則：

自主創新的原則

在項目的規劃和設計過程中，將從xx的業務系統現狀和業務發展出發，同時考慮到證券公司后續業務發展的需要。在具體建設過程中，不完全使用已有第三方軟件供應商提供的數據中心產品。整個系統的設計和搭建將自主創新，完成整個系統的搭建。

合作開發的原則

數據中心項目是一個開發項目，不是一個通過產品安裝就能夠完成的。xx信息技術部將全程參與系統的設計和開發工作。

逐步推進的原則

利用大數據技術和數據倉庫理論建設數據中心項目，這樣的過程是要經歷過一定的時間階段的。為此，在每一期建設過程中，我們將明確目標，實現數據中心建設的完整框架，后續的建設將逐步推進。

項目管理的自控原則

數據中心建設項目的進行過程中，xx信息技術部參與整個項目進度的控制和項目管理過程中的每個細節。供應商參與開發人員要完全受信息技術部的項目管理要求，并遵循信息技術部的相關規范。

標準性原則

在項目的各個階段，尤其是設計階段，要從整個公司級別考慮問題，制定的相應業務規則和數據字典要能夠作為公司級的數據標準。

術語定義

ETL	Extraction-Transformation-Loading，數據抽取、轉換和加載
DDL	Data Define Lanuage，數據定義語言，即數據庫的各種建庫，建表語句。
ODS	Operational Data Store，操作性數據存儲，是一個面向主題的、集成的、可變的、當前的細節數據集合，用于支持企業對于即時性的、操作性的、集成的全體信息的需求。常常被作為數據倉庫的過渡
EDW	Enterprise Data Warehouse，企業級數據倉庫，是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用于支持管理決策(Decision Making Support)。
CDM	概念數據模型（CDM），用于表示數據的邏輯特性，即只是在概念上表示數據庫中將存儲什么信息，而忽略這些信息的實現細節。同時，它也是對系統主要實體的高層次業務見解，比如識別關鍵主體領域、定義核心實體的主鍵。
LDM	邏輯數據模型（LDM），即實體關系模型，是一種描述數據的模型。它利用實體和它們之間的關系描述包含在顯示世界中的數據。這是一個比較詳細的數據業務見解，比如細化實體間關系，詳細的屬性定義（主外鍵、索引等主要屬性），添加了關聯的、特色的以及子類的實體，盡可能詳細化的范式（遵循第三范式），實體間的約束關系等。
Metadata	元數據（Metadata），指的是關于數據的數據，即對數據的描述。元數據描述了數據的結構、內容等多項內容，提供了對數據對象的描述、定位、管理、檢索、評估、選擇和交互等功能。元數據是數據對象的信息地圖，通過元數據管理，能夠準確勾勒出證券公司數據資產的整體視圖，支持科學制定信息數據管理政策，通過元數據管理，也能夠建立統一的數據表達形式、元數據標準，使數據可視化，方便數據的靈活交互和擴展。
HADOOP	Apache Hadoop是一個開源軟件庫，支持超大數據的分布式處理，此類數據集分布在數千臺使用普通硬件的計算機中。Apache Hadoop項目由Hadoop分布式文件系統、MapReduce和Hadoop Common等子項目組成。此外，還包括HBase、Hive、Pig以及其他相關技術。Hadoop非常適合處理大體量的靜態數據。

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

系統技術設計

系統技術架構

系統總體框架

系統邏輯架構

無論承載數據中心的基礎數據庫是ORACLE之類的關系型數據庫還是Hadoop之類的大數據平臺。從數據倉庫的理論出發，我們可以將數據中心以及和數據中心相關的系統從邏輯上進行劃分。大致可以分為源業務系統、數據基礎平臺、數據服務平臺、智能分析平臺、數據管控平臺、業務展現平臺這幾部分。

源業務系統：數據中心數據的來源，證券公司內部各類生產系統或者互聯網數據。數據中心對接各個源業務系統進行ETL工作，將證券公司內部的數據以及互聯網上獲取到的外部數據集中到數據中心，進行數據標準化和數據建模工作。

數據基礎平臺：負責數據中心數據標準化、模型化、持久存儲工作。從技術上分為數據存儲和數據計算兩大功能；從數據類型分為結構化和非結構化兩類數據平臺；從數據中心數據存儲的層次分為原始層、ODS層、EDW層、數據集市層四類層級。

數據服務平臺：負責數據中心所有對外數據接口的管理工作，通過數據服務平臺實現數據中心和下游應用分析系統的數據對接工作。數據服務形式一般有被動采集和主動推送兩種模式。

智能分析平臺：負責將數據中心的數據和指標進行智能分析，快速形成各類報表和圖表應用以及進行數據挖掘的工作。智能分析平臺通常會內嵌商業智能分析和數據挖掘軟件比如Cognos、mstr、FineBI、SPSS等。

數據管控平臺：負責數據中心任務調度、數據質量管理、元數據管理、數據接口管理、數據權限管理以及運維監控功能的管理平臺。負擔整個數據中心體系中數據的管理、控制、校驗、監控、分發工作，通常情況下會將業務展現平臺集成到數據管控平臺中，進行統一集成化管理。

業務展現平臺：負責將數據中心的產出物包括報表、圖表、駕駛艙、數據標簽、數據分析和挖掘的結果進行有機集合，形成針對業務人員使用的前端展現工具，通常會集成到數據管控平臺中。

系統技術架構

??? xx數據中心項目的數據存儲和計算服務已經采用cdh版的Hadoop大數據平臺。因此數據中心技術架構基于Hadoop大數據平臺進行設計。

數據存儲采用hdfs集群模式，這種數據存儲模式具有超大文件處理能力、流式數據訪問能力、橫向擴展能力、廉價的服務器需求等優點。

數據計算采用Hadoop原生的mapreduce計算、SPARK引擎計算、HIVE類 SQL 查詢語言相結合的模式來保證應對數據中心業務處理中的各類計算場景。

數據應用可以細分為數據中心自身的數據分析和對接下游系統的數據服務兩類。在數據應用方案的設計上采用關系型數據庫接口和大數據平臺數據接口相結合的方式。這種數據應用模式的優缺點如下：

優點：充分考慮到數據對接類型的全覆蓋，以避免數據分析軟件或者下游系統無法對接Hadoop數據接口的風險。

缺點：增加了數據中心的ETL工作量，同時由于多了一層關系型數據庫和大數據平臺的數據交互需要額外增加數據質量控制機制來保證數據應用的數據質量。

系統性能

根據目前現狀，在充分考慮公司未來 3-5 年的業務發展需要，總體達到性能指標如下：

系統性能指標列表

指標項	指標值
前端展現在線用戶數	不小于3000
并發用戶數	不小于300
客戶歷史數據保留期限	長期保留
日、周報表數據生成時間	小于1小時
月度報表數據生成時間	小于2小時
實時數據ETL處理時間	小于1分鐘
日終數據ETL處理時間	小于2小時
數據整合時間	小于2小時
一般查詢響應時間	小于3秒
查詢時間超過3秒的功能占比	小于5%

容錯機制

在數據抽取清洗（ETL）的每一個環節出現錯誤時都應有相應的出錯處理、恢復流程，錯誤處理應盡量通過系統自動恢復實現，需要通過人工干預處理的，出現錯誤后應能通過各種途徑通知維護人員。常見出錯處理方式：

錯誤類型	錯誤內容	處理方式
系統異常	數據庫連接失敗	自動處理，重連
	數據庫空間不足	自動提醒，手動擴展空間
	程序異常退出，如機器掉電，強制結束進程	手動處理，重啟程序，系統自動保證事務一致性
應用異常	主鍵沖突	自動手動結合，系統分析導致主鍵重復的數據，由相關人員手動排除錯誤。
	數據類型轉換失敗	手動處理，手動排除錯誤。
	字符串轉換越界	自動處理，自動截斷字符串，并記錄日志，作提示，供相關人員參考。
	數據庫死鎖	自動重試，重試后錯誤依然存在的，記錄錯誤信息，手動處理。
	由于柜臺數據結構變動引起的數據轉換不完整	手動處理，修改轉換過程。
	數據核對有差異	手動處理，檢查數據差異。

?

數據采集工具在處理的每一個環節都有完善的出錯處理，可以根據客戶的需求，設定出錯的的處理原則，例如放入臨時表，導出出錯文件，或者是發EMAIL或者是短信網關通知相關的人員。

安全性設計

系統的安全性表現在對系統網絡、數據傳輸、數據存儲、業務功能展現全過程的安全控制與管理方面。數據的傳送的安全性，通過技術平臺的數據安全機制，如自定義動態加密算法、校驗算法、用戶認證證書等，可有效地保證數據從客戶端的接收至服務端的處理全過程的安全。而從業務部分來說，系統通過對登陸用戶采用統一的用戶認證服務器進行身份的合法性驗證，通過對操作員操作身份認證與操作權限的嚴格限制，確保了業務處理在身份認證與權限上的安全控制。

網絡安全性

網絡安全技術主要解決諸如如何有效進行介入控制，以及何如保證數據傳輸的安全性的技術手段，主要包括物理安全分析技術，網絡結構安全分析技術，系統安全分析技術，管理安全分析技術，及其它的安全服務和安全機制策略。本項目可以綜合利用虛擬網技術、防火墻技術、病毒防護技術、入侵檢測技術、安全掃描技術、認證和數字簽名技術、VPN技術、應用系統的安全技術等多種技術相結合的方式來保證網絡的安全性。

數據安全性

數據存放

數據庫的安全性是指保護數據庫以防止不合法的使用所造成的數據泄露、更改或破壞。所有核心數據存放在數據庫中。具體安全措施包括：防止非授權的數據庫存取；防止非授權的對模式對象的存取；控制磁盤使用；控制系統資源使用；審計用戶動作。

數據訪問

數據抽取服務器對數據源的數據只有讀取權限，無其余任何查詢、修改、刪除數據權限。數據接口服務模塊對數據中心的數據只有讀取權限，不具有修改和刪除的權限。

操作安全性

錯誤提示

系統對錯誤都有明確的錯誤信息提示，從而大大加快了問題的解決，保證系統穩定安全的運行。

操作人性化

系統的界面設計針對用戶做了非常細致的考慮，盡量做到系統運行無人值守，系統運行發現問題能夠盡快提示給相關人員。提示友好而準確。

配置管理

系統有詳細的配置清單。

容錯機制

系統在實時數據抽取，日終文件傳輸，日終文件導入和清洗流程均有相應的容錯機制。

WEB安全性

證書安全

系統WEB中間件支持加載證書，支持HTTPS協議。

用戶口令保護

系統所有應用都受用戶口令保護，只有通過用戶口令校驗之后才能訪問，每個請求在遞交給應用服務器前，都首先判斷是否已通過用戶認證。

權限控制

業務展現平臺、數據管控平臺的權限控制基于角色與組織架構來控制。結合BI系統可以將權限控制對應的字段。相關授權與重要功能的讀寫留痕，并有專門功能提供查詢。

可靠性設計

系統具有完善的容錯功能，數據庫服務器、網絡設備、存儲設備及相關系統和軟件均有冗余設計。系統所有應用服務器提供冷備份措施，當其中一個應用服務器出現故障時快速接管。

數據基礎平臺

?

?

本次系統建設的關鍵是首先要建設一個公司級的數據中心，抽取現有各交易系統、賬戶系統、資管系統、TA系統、資訊系統、SOEM等系統的相關數據，并進行標準化和提供各業務系統二次開發標準接口。具體可以分為數據抽取清洗、數據標準化及建模、領導者駕駛艙應用、數據管控平臺4個部分。

ETL包括從業務系統抽取數據，進行整理和轉換，然后進行數據加載。在目前的環境中，可以界定為從源系統的取數據到裝載數據入核心數據庫的這段過程。下面的圖描述了ETL和相關部分的具體數據流。

下圖為通過ETL建立數據倉庫的整體過程：

ETL主要完成以下內容：

從各類同構或異構生產庫系統抽取、轉換、加載數據到大數據平臺的ODS數據層。

根據xx需求按照一定主題建立的數據模型，抽取、轉換、加載ODS數據到大數據平臺的企業級數據倉庫層即EDW層。

根據數據中心模型設計規范與xx的數據需求建立完整的數據中心指標體系。

根據xx業務條線或者部門級的需求按照數據中心既定的數據標準和規范加載轉換EDW數據和指標庫數據到各類數據集市。

數據源

xx數據中心團隊和風險管理團隊歷經多年的風險管理數據采集、數據中心系統數據采集工作，積累了非常豐富的各類證券系統數據對接經驗。

從系統類別的角度看，數據中心數據源采集對接經驗如下：

接口類別	支持接口數量	典型接口	完成狀態
集中交易	7	UF2.0/金證W版/金證U版/頂點ABoss	已投產
TA系統	6	xxTA/金證TA/xx自建TA/金證自建TA	已投產
資管系統	9	xxO32/xx資管SQL/銘創V8	已投產
資訊系統	8	Wind咨詢/Wind金融數據庫版/港澳資訊SQL版/聚源資訊	已投產
固收系統	3	海益固收/Comstar/衡泰固收Xir	已投產
賬戶系統	3	xx賬戶系統/頂點賬戶系統CIF	已投產
估值系統	5	xx估值基金版/xx估值保險版/贏時勝估值	已投產
財務系統	15	用友23/用友55/用友63/金蝶EAS/浪潮財務	已投產
融資融券系統	7	xx融資融券/金證融資融券	已投產

從xx現有應用系統的角度看，數據中心數據源采集對接經驗如下：

客戶名稱	接口名稱	完成狀態
xx	xxTA	全面風險團隊已投產
	xx自建TA	全面風險團隊已投產
	用友財務系統	全面風險團隊已投產
	集中交易系統xxUF2.0版	全面風險團隊已投產
	融資融券系統xxUF2.0版	全面風險團隊已投產
	海益固收系統	全面風險團隊已投產
	賬戶系統xxUF2.0版	全面風險團隊已投產
	轉融通系統xxUF2.0版	全面風險團隊已投產
	資管系統xxO32版	全面風險團隊已投產
	聚源資訊系統	全面風險團隊已投產
	xx估值系統	全面風險團隊已投產

?

數據組織結構

數據組織目標

數據組織是由業務系統數據分析和數據中心需求分析相結合后，產生的為之后的數據層次提供分類的綜合依據，具體表現為為ODS層次提供分類的參考和為EDW層的主題提供主題雛形。同時數據組織也是數據中心設計大部分表結構所需要遵循的原則。

數據組織結構

?

原始層數據是基本和數據源業務系統表結構保持一致的信息數據;ODS層數據主要將原始層進行清洗轉換之后符合數據中心標準和規范的共性標準化數據；EDW層主要保存進行主題建模之后持久化存儲的數據中心數據。

原始層	ODS層	EDW層
1.表結構與業務系統基本一致 2.采集表結構和用戶保持不變 3.歷史數據和日終數據需要進行T+1的采集同步。	1.存放當前和全部歷史數據。 2.本層的數據可以在必要的時候進行增、刪、改操作。 3.刷新頻率：每天	1.存放大量歷史數據。 2.一般只進行查詢操作。 3.刷新頻率：每天。

ODS數據庫

ODS數據層在數據中心數據體系中非常重要，其架構設計將會決定其以后的擴展性及對外提供數據的能力。該層次的定位為數據交換和數據倉庫的數據過渡層，對數據倉庫來說，其起數據規范化作用，即將不規范的數據及空值、不適用數據分析功能的冗余字段去除。在本項目中ODS數據層將保留全部歷史數據。

ODS數據庫設計原則：

標準化原則

對不同系統同含義的數據進行標準化，比如客戶號、機構代碼、產品類別等。在每個系統里，代表相同含義的字段名稱及字段值都不一致，甚至還存在空值。而ODS作為數據服務，對外提供的必然是一致的字段及字段值，因此在ODS需要做字段的規范化和字段值的統一。

統一客戶模型

證券公司通常會有多套客戶交易系統或者管理系統，在不同的系統里存在不同的客戶模型，在數據中心里將會統一客戶模型，以統一設計的客戶模型對外提供數據。

統一數據字典

在標準化原則下，對外提供統一的數據字典。并能自動發現新增屬性值的現象，并通過預警的方式通知運維人員進行確認。

統一數據格式

數據格式保持對不同交易系統的兼容，確保清洗、轉換過程不會引起數據失真和清洗轉換因字段值類型不匹配導致失敗，同時也有利于對外提供統一的數據服務。

EDW數據庫

EDW層依據不同的業務主題和數據模型對數據中心的數據進行數據建模工作，是數據統計、數據分析、數據挖掘和證券公司指標體系形成的基礎。EDW層要求保留全部歷史數據。

EDW層數據支撐智能分析平臺、ACRM系統、數據統計以及固定報表數據需求。各個業務條線和部門的數據需求通過在EDW層建立數據集市來實現。

EDW層數據模型參考業內普遍使用的數據倉庫模型數據規劃和組織以及證監會行業數據模型工作組的邏輯模型建設成果，另一方面也要考慮到證券公司各業務條線的業務特點和個性化數據需求進行數據主題模型的設計、擴展和補充。

數據組織原則

時間與效率原則

為了保證數據中心能夠及時為各個總部管理系統提供數據服務，必須控制數據的再加工量，日終處理(采集和加工)不能以延長時間為代價，原則上，日終處理的時間不應超過1小時。

通用性原則

由于數據中心系統是公司多個總部管理系統的數據基礎，為了保證數據中心系統的運行效率，數據中心僅對共性的數據進行加工、存儲。個性化數據由下游各業務系統在數據中心提供的數據基礎上自行再加工。

粒度最小化原則

如果多個系統都需要同一項數據，只是數據粒度不一樣;在這種情況下，數據中心按粒度最小化的原則進行數據加工。

如果相關屬性需多個系統共用，由基礎數據加工而成，如日均資產、周轉率等。

如果相關屬性供單個系統使用或涉及到手工調整，如客戶評級，建議下游系統各自計算產生，同時將有必要的指標數據回寫至數據中心，交易系統等。

標準化原則

對不同系統同含義的數據進行標準化，數據格式保持對不同交易系統的兼容，對外提供的必須是一致的字段名稱和字段值。比如客戶號、機構代碼、產品類別等。

開放性原則

允許符合技術標準的數據及系統在此平臺上交換數據。

容錯性原則

在數據抽取清洗的每一個環節出現錯誤時都應有相應的出錯處理、恢復流程，出現錯誤能夠通過郵件、短信的方式通知維護人員。

準確性與完整性原則

數據中心為各個管理系統提供數據服務，其數據的準確性非常重要，須能夠提供業務系統層、原始層、ODS層的數據核對，并能夠在核對出現問題時自動提醒維護人員。

數據模型設計

數據模型設計的原則是具備全面性和前瞻性，涵蓋了目前數據中心或者下游系統不涉及，但在后續數據分析過程中會涉及的數據模型；涵蓋短期內不會進行標準化，但將來會進行標準化的數據模型。

FS-LDM和SDOM的產生就是為了解決這個矛盾的。FS-LDM和SDOM解決這個矛盾有兩種途徑：

(1)利用科學的面向對象分析的方法，分析業務中的Who， What， When， Why， Where， How；這樣就產生了數據建模領域的基本主題框架，并且按照證券的特點轉化為當事人、產品、渠道等數據主題域。

(2)總結已經成功建設倉庫，并且可以支撐各種分析型應用建設的案例，對這些案例的模型進行借鑒。借助于這些專業的建模經驗，在已經確定的主題框架下，細化各種實體和關系的內容。通過關系實體模型的框架將通用的業務邏輯完整地反映出來。

本次數據中心建設方案綜合參照FS-LDM和SDOM這兩種數據模型設計方法論進行邏輯數據模型設計工作。下面是FS-LDM、SDOM、xx數據中心對于主題模型劃分的對照列表

FS-LDM	SDOM	xx數據中心
當事人	主體	當事人
產品	品種	產品
協議	賬戶	協議
事件	事件	事件
資產	資產	資產
財務	合同	財務
機構		內部機構
地域		地域
營銷	營銷	營銷
渠道	渠道	渠道
	資訊	資訊
		公共

其中SDOM主題劃分中的主體主題對應FS-LDM中的當事人主題和機構主題、品種主題對應FS-LDM模型中的產品主題、賬戶和合同主題綜合對應FS-LDM模型中的協議主題；對于財務、內部組織、地域等主題內容SDOM模型并未設計，而FS-LDM模型對應證券行業特有的資訊內容并未包含在內；xx數據中心在結合兩種主題模型設計思路的基礎上，形成了包含當事人、協議、產品、事件、資產、內部機構、財務、資訊、地域、營銷、渠道、公共十二大數據主題域的數據中心主題模型設計思路。

模型設計概述

企業級數據倉庫（Enterprise Data warehouse）邏輯數據模型（Logical Data Model）是一種圖形的展現方式，采用面向主題的方法有效組織來源多樣的各種業務數據，同時能全面反映證券復雜的業務規則，支持大量的分析應用。它使用統一的邏輯語言描述證券業務，是數據管理的分析工具和交流的有力手段；同時還能夠很好地保證數據的一致性，是實現業務智能（Business Intelligence）的重要基礎。

結合證券操作型業務系統的業務特性，采用面向主題的方法，按照標準范式規則進行設計，將來源于核心交易系統、法人清算系統、營銷系統、財務系統、統一賬號系統等諸多業務系統的數據有效地組織起來，為證券公司提供了中性數據平臺和單一信息視圖，并且保留全部歷史數據，能夠全面體現各種業務規則，支持將來的分析型應用。

本項目的模型客戶化重點是數據倉庫基礎邏輯數據模型，通過EDW層數據支撐智能分析平臺、ACRM系統、數據統計以及固定報表數據需求。統計類數據通過在EDW層建立數據集市來實現。

目前模型框架中包括當事人、內部機構、產品、協議、事件、地址、渠道、營銷、財務、客戶資產、資訊、公共十二大主題以及主題之間的關系，模型的概貌如下圖所示：

?

通過本系統建設工作，形成證券自有知識產權的企業級數據倉庫邏輯數據模型，從而為搭建證券公司企業級數據倉庫奠定重要基礎。

建設本系統，將有助于搭建全行統一的業務信息視圖，提供對數據的一致理解，滿足日益增長的分析型應用；將有利于證券公司對現有業務的全局認識與把握，從整體上對全行業務系統進行規劃設計，更好地實現跨部門、跨系統分析，支持業界成熟應用的實施，建設并完善符合證券公司業務實際和發展要求的全行業務分析型應用系統。

當事人模型

當事人（Party）是指證券公司所服務的和感興趣進行分析的任意對象。當事人可以是一個獨立的人，也可以是一組人組成的機構、團體等。當事人分為個人當事人、機構當事人和家庭，他們是和證券公司有業務往來或者出于市場營銷、分析管理等各種需要而希望關心和分析的個體或群體。

從數據倉庫模型角度考慮，主要包括以下幾類當事人信息：

• • 登記注冊開立賬戶的單位、個人普通客戶；
  • 有業務往來的其他金融機構（基金代理等）；

唯一標識

“當事人編號”是當事人的唯一標識字段，是全轄唯一的客戶識別號。當事人類型分為“個人當事人”和“機構當事人”兩類

兩者的當事人編號的生成規則分別如下：

• • 個人當事人：按照當事人在各系統中登記的證件類型＋證件號碼進行統一整合生成統一客戶號。
  • 當事人編號＝“統一客戶編號”。證件類型代碼以核心業務系統采用的編碼標準為基礎進行整合。

核心交易業務系統以及目前分析的其他外圍業務系統所涉及的客戶，目前均遵循上述原則產生該系統的客戶號，進行客戶的唯一性識別。對于未來新增的業務系統，若其擁有不同于該編碼方式的客戶號生成規則，但其一般均應提供對客戶的相關證件類型和證件號碼，與數據倉庫現有數據進行整合；否則需通過其他輔助信息進行客戶的唯一性識別（如通過核心交易業務系統的賬號關聯相應的客戶號）。

• 對公當事人：同個人當事人編號一樣

主要內容

當事人分類

結合證券業務系統現狀和數據基礎，當事人種類分為對機構當事人、個人當事人、經紀人當事人，代理人當事人，柜員當事人等

當事人：par_client指公司所服務的任意對象和感興趣進行分析的各種對象，通過“當事人類型代碼”分為“個人當事人”、“對公當事人”。當事人的主要數據來源為核心交易業務系統的客戶信息、和其他外圍業務系統的客戶信息等。

• 當事人名稱：當事人當前對應的名稱。
• 當事人所在內部機構。
• 當事人編號:統一生成唯一編碼
• 當事人證件號和當事人證件的有效日期等。
• 當事人證件有效開始日期
• 當事人證件有效結束日期
• 當事人類型代碼，包括個人和機構。
• 當事人種類代碼，包括客戶，經紀人，柜員，代理人等。

個人當事人：par_clientinfos主要指證券所服務的個人客戶。包含了一些常用的人口統計學信息：性別、出生日期，當事人開銷戶日期，當事人狀態代碼表，當事人權限，當事人委托方式等。

機構當事人：par_organinfo主要指證券所服務的機構客戶。包機構客戶所有基本信息。

經紀人當事人：par_broker主要指證券公司為客戶提供服務的經紀人，包括經紀人的基本信息。

代理人當事人：par_deputy主要指證券公司為客戶提供代理服務的當事人，包括代理人的基本信息。

柜臺當事人：par_operator主要指證券公司營業部的柜員為客戶提供服務的當事人，包括柜臺的基本信息。

當事人關系歷史：主要指與當事人之間的歷史關系變化，用拉鏈算法，其中當事人關聯關系代碼，包括（經紀關系，代理關系等），開始日期和結束日期。

當事人風險代碼:：主要指當事人開戶的風險規范，

當事人狀態代碼：主要指當事人狀態，包括掛失等。

當事人風險

當事人評級歷史：記錄當事人的風險評級情況，主要包括信用評級的信息。

當事人額度歷史：當事人的分類額度及額度的使用歷史。

重要關系

?

當事人協議關系歷史：記錄當事人與協議的關系歷史，目前記錄的主要是協議的持有者、擔保者、共同參貸人等關系。

事件當事人關系：記錄事件與當事人的關系，一個事件會涉及很多當事人，比如事件的發起人、事件的代理人，事件的經紀人等。

當事人地址關系歷史：記錄當事人與地址的關系，當事人的地址變更歷史等信息。一個當事人可以有多個地址；一個地址可能被多個當事人使用。

產品當事人關系歷史：描述產品與當事人的關系，如開發、經銷、購買等。

內部機構當事人關系歷史：內部機構在與當事人的關系中扮演不同的角色，如開戶機構、管理機構、分析機構等。

內部機構模型

內部機構（Internal Organization）是一個比較寬泛的概念，可以是正式機構，也可以是一些具有特定功能的團隊。本模型中內部機構是指證券公司的內部組織和業務單元，如營業部、服務部、部門、銷售團隊等。

通過該主題的建立要能夠體現不同組織機構之間的層次隸屬關系，同時還能夠適應組織機構變動的靈活性以及交叉管理的需要。此外，該主題和當事人、地區、產品、協議、事件、營銷活動等都有關聯。如對產品而言，可能有多種角色，如創建、銷售、監控等。

唯一標識

內部機構的唯一標識以核心業務系統機構管理中的機構編碼為基礎，結合財務管理系統和其他業務系統的機構編碼進行整合。

內部機構概況

?

內部機構：記錄各業務系統中所有的內部機構信息。

內部機構名稱歷史：記錄內部機構的名稱變化歷史。

內部機構級別歷史：該實體描述了機構內部的組織架構和層級。這是在機構是一個層次的組織架構體系假設前提下的。

?

重要關系

?

內部機構協議關系歷史：記錄協議與機構的關系歷史，如協議的歸屬機構。

內部機構地址歷史：記錄內部機構在各業務系統的地址信息。

內部機構產品關系歷史：記錄機構與產品的關系。

內部機構當事人關系歷史：內部機構在與當事人的關系中扮演不同的角色，如開戶機構、管理機構、分析機構等。

地域模型

地域（LOCATION）是希望觀察和分析的任何區域，既包括傳統類型的地址信息（如國家、地區、城市、區縣、街道等），又包括如電話信息、電子地址、郵箱、黃頁等信息。客戶可以用于和銀行的交互和溝通，也可以被用于某個特殊的場合（比如對帳單寄送地址等）。

“地址編號”作為一個地址信息的唯一標識。

主要內容

地址信息分為電子地址、物理地址和電話地址三個分類。此外，考慮到地理區域與以上三類地址信息的聯系和差別，綜合模型實體間的關系和總體布局，也將地理區域作為地址信息的一個分類。

地址：所有地址的超級父類實體。

電子地址：包括當事人的eMail、網址、IP 地址等。

物理地址：存放物理的門牌地址信息，如家庭地址、單位地址、暫住地址等，主要屬性包括：

• 信函地址、郵政編碼：具體的郵寄地址。
• 國家代碼：目前已有的國家地區代碼。
• 城市、區縣、城鎮、街道、住宅小區、建筑物、門牌號碼：詳細的物理地址信息。
• 郵箱號碼：郵局為該物理地址分配的一個信箱號碼。
• 國家組合代碼：為世界性的國家組合進行編碼，比如東盟、歐盟等。
• 世界區域代碼：為世界性的區域進行編碼，如亞太地區、阿拉伯地區等。

電話地址：存放電話信息。如家庭電話、手機、BP機。

地理區域：地址信息的一個子類，存放非行政區劃上的區域信息，如珠江三角洲、長江三角洲等。

• 區域名稱：定義國內的地理區域，主要指有一定影響力，有共同特征和利害關系的地理區域。
• 地理位置：描述區域的地理位置和范圍。
• 代表城市：區域的代表城市，可以是經濟中心，也可以是其他種類的中心城市。
• 經濟狀況：從經濟發展狀況角度描述區域的特征。

電話地址通訊類型關系：存放同一個電話號碼所對應的通訊類型，如電話、傳真等。

重要關系

?

產品地域關系歷史：描述產品與地址的關系，如某產品在某個地域銷售。

協議地址關系歷史：用于記錄協議與地址之間的關系，比如協議指定的對賬單寄往地址。

產品模型

證券公司產品（PRODUCT）是指為拓展市場占有率，滿足客戶更廣泛需求而制定的可營銷的交易品種集合，產品是金融機構向用戶銷售的或提供給客戶所使用的服務。產品必須是能夠面向市場、面向客戶的，并且必須要有回報發生的。

唯一標識

產品的唯一標識就是產品編號，由于XX證券源業務系統沒有明確的產品定義，所以唯一標識號會結合各個產品的特點來生成唯一號。

產品分類

產品：該獨立的實體包含證券公司可以提供以及競爭對手可以提供的任何感興趣追蹤的可以市場化的產品、產品包和服務的信息。該實體包含過去、現在和將來的市場化的產品、產品包和服務。每個市場化的產品、產品包或服務都是該實體中的一個實例。產品的范疇還包括投資工具，如股票、權證、債券、理財，融資融券、短期融資券，股指期貨和基金等證券產品。

根據產品類型代碼，產品劃分為：

金融產品：股票、權證、基金、債券、理財，融資融券，短期融資券、股指期貨等均屬于此類產品。

非金融產品：以證券公司為服務的產品。

重要關系

?

協議產品關系歷史：隨著生命周期的變化，一個協議可能會在不同的時期屬于不同的產品，這些產品在該關系中的角色也發生著變化。

協議模型

協議（AGREEMENT）是證券公司與當事人之間針對某種特定產品或服務而簽立的契約關系，它可以是多樣化的。當證券公司與客戶之間針對某種產品或服務的條款和條件達成協議時，一個協議（AGREEMENT）就會被開立，因此協議是客戶和證券公司往來的重要載體。

主要內容

?

協議實體是協議主題的核心實體，保存協議相關的屬性信息。對于協議持有人、科目代碼、協議歸屬機構、協議狀態代碼、協議狀態原因代碼這些可變信息，協議實體中只保留最新的信息，其余歷史變動信息保存在相關歷史實體中。

• 協議號成協議的唯一標識。
• 協議類型代碼：描述協議的類型。（1資金協議，2證券買賣協議，3開基協議，4融資融券協議，5理財協議，6債券買賣協議）

重要關系

?

事件模型

事件（EVENT）是一個范圍很廣的概念，它可以包含與證券公司相關的任何動作的記錄。既可以與資金相關，也可以與資金無關；既可以有客戶參與，也可以沒有客戶參與；既可以與賬戶相關，也可以與賬戶無關；可以由客戶發起，也可以由證券公司發起；總之它可以記錄的范圍非常廣泛，可以記錄各種與證券公司相關的活動的詳細情況，包括交易數據，比如網上交易，查詢流水，交易流水，資金的轉入轉出等。

唯一標識

唯一標識一筆事件的字段是“事件編碼”，編碼規則是由“源業務系統編號＋各系統原唯一編號”組成，如核心交易系統事件編號為“0100 ＋交易日期＋地區代號＋機構代號＋日志序號”。

主要內容

事件是本主題的主干實體，主要包含事件日期、事件時間、交易代碼等各種事件的共性信息。

?

?

事件分為核心事件和外圍事件兩大類，核心事件主要包括核心交易系統的交易流水信息（金融事件和非金融事件）；外圍事件則主要包括所有的外圍系統交易流水信息（營銷系統，法人清算系統，開放式基金系統，融資融券系統等）。

外圍事件

?

營銷系統事件：描述外圍系統營銷服務系統中，基本的客戶預約和客戶投訴事件信息，以后會進行擴展，將同時也記錄與營銷相關的營銷活動的事件。

• 營銷系統事件類別代碼：記錄營銷系統中事件的類別，包括投訴事件類別和預約事件類別。
• 營銷系統事件類型代碼：記錄營銷事件中事件類別一下的分類信息，比如在投書類事件中有：服務類投訴和費用類投訴等。

銀證平臺交易事件：描述外圍系統中銀證平臺的交易事件信息，目前主要有銀證通的交易事件：銀證通銀行端交易事件（委托流水和開銷戶流水）、銀證通證券端資金凍結事件（證券端發起的資金凍結流水）、銀證通交割明細（證券端每日提供的交易交割明細）；以后會增加銀證轉賬的事件。

重要關系

?

事件當事人關系歷史：一個事件會涉及很多當事人，比如事件發起當事人、事件授權當事人、事件的代理人，證券交易事件中交易雙方當事人等。

事件內部機構關系：一個事件會涉及很多內部機構的信息，比如事件的發生機構、事件的操作柜員、事件的授權柜員等。

事件產品關系：記錄事件與產品之間的某種關系。

?

資產模型

唯一標識

資產主題不產生統一主題編號。

資產主題中增加其他主題編號，如當事人編號、內部組織編號、協議編號等。

主要內容

證券交易資產：包括客戶資金余額/證券余額。

?

?

中登證券余額信息：取自中登DBF文件的股東股份余額信息。

?

?

開基資產：包括客戶開基持倉份額。

?

?

融資融券相關資產：包括客戶與公司的資金賬戶余額、客戶與公司的證券賬戶證券余額、融資融券負債和其他負債。

資產管理相關資產：投資業務資金賬戶余額、投資業務證券賬戶證券余額、理財產品客戶持倉份額。

?

清算系統相關信息：按照清算系統中科目及發生額、余額的方式存儲公司清算相關資產。

?

重要關系

證券交易：

客戶資金余額（DW_ASS_CLIENTFUND_DM）：存儲本公司柜臺交易客戶資金賬戶的資金余額信息。來源系統包括：交易系統。另外存在對應資金變動流水表和拉鏈表。

客戶證券余額（DW_ASS_CLIENTSEC_DM）：存儲本公司柜臺交易客戶證券賬戶的證券余額信息。來源系統包括：交易系統。另外存在對應證券變動流水表和拉鏈表。

客戶中登證券余額（DW_ASS_CLIENTSDCSEC_DM）：存儲從中登獲取的股東股份余額信息。來源系統包括：中登DBF文件。另外存在對應拉鏈表。

客戶基金份額（DW_ASS_CLIENTOPFUND_DM）：存儲開基代銷客戶開基賬戶的開基份額信息。來源系統包括：開基代銷系統。另外存在對應份額變動流水表和拉鏈表。

融資融券：

融資融券資金余額：包括融資融券客戶資金表(DW_ASS_CRDTCLIFUND_DM和融資融券公司資金表（ER_ASS_CRDTCOMFUND_DS）。來源系統包括：融資融券系統。另外存在對應變動流水表和拉鏈表。

融資融券證券余額余額：包括融資融券客戶證券余額表(DW_ASS_CRDTCLISEC_DM)和融資融券公司證券余額表（ER_ASS_CRDTCOMSEC_DS）。來源系統包括：融資融券系統。另外存在對應變動流水表和拉鏈表。

融資融券證券負債：包括融資融券負債（DW_ASS_CRDTDEBIT_DM）和融資融券其他負債（DW_ASS_CRDTOTHERDEBIT_DM）。來源系統包括：融資融券系統。另外存在對應變動流水表和拉鏈表。

資產管理：

投資業務資金余額（DW_ASS_INVESTFUND_DM）：存儲投資業務的資金賬戶的資金余額信息。來源系統包括：資管系統。另外存在對應拉鏈表。

投資業務證券余額（DW_ASS_INVESTSEC_DM）：存儲投資業務的證券賬戶的證券余額信息。來源系統包括：資管系統。另外存在對應拉鏈表。

理財產品持倉份額（DW_ASS_FINPROSHARE_DM）：存儲理財產品客戶理財產品賬戶的理財產品持倉信息。來源系統包括：TA系統。另外存在對應持倉變動流水表和拉鏈表。

清算系統：

清算系統資產相關：包括清算科目代碼表(DW_ASS_CLEARINGSUBJECT_DM)、清算資金余額表(DW_ASS_CLEARINGFUNDBAL_MM)、清算資金凈額表（DW_ASS_CLEARINGFUNDNET_DM）。用于獲取公司或部門級清算相關資產，如備付金余額、銀行存款等。來源系統包括：清算系統。另外科目代碼表存在對應拉鏈表，并對于科目代碼表在公共主題中相應創建科目代碼維度方便使用。

其他資產：

經紀人薪酬（DW_ASS_BROKERSALARY_MM）：存儲經紀人每月薪酬信息，包括項目代碼（ITEM_CODE）關聯經紀人收入項目表（DIM_BROKER_INCOME_ITEM）獲取薪酬項目信息。

財務模型

本主題主要包括本公司的總帳信息，是描述備付金金額、投資收益、傭金收入等證券公司核心科目帳務以及預算管理有關的內容。該主題抽象地描述了公司內部帳務的組織模式，能夠適應不同的科目組織體系以及靈活的科目公式計算。

唯一標識

財務主題不產生統一主題編號。

財務主題中增加其他主題編號，如內部組織編號等。

主要內容

DW模型中，以財務業務的通用性考慮，得到下面財務模型，以帳套、科目、輔助代碼對余額和憑證分錄做統計和計算。對于帳套、科目、輔助代碼構建相應拉鏈表

?

?

帳套信息：包括帳套表、合并帳套關系表、系統結賬表。

?

?

余額憑證分錄信息：包括財務科目、財務輔助代碼、余額表、憑證分錄表。

?

重要關系

系統結賬表（DW_CFS_SYSSETTLE_DM）：存儲每個帳套目前最大結賬月份信息。來源系統包括：財務系統。因財務結賬按月結賬故不保存相應拉鏈表。

帳套表（DW_CFS_LEDGER_DM）：存儲公司財務系統內所有帳套信息。來源系統包括：財務系統。另外存在對應拉鏈表。

合并帳套關系表（DW_CFS_COMPLEDGERREL_DM）：存儲合并帳套與獨立帳套的對應關系信息。來源系統包括：財務系統。另外存在對應拉鏈表。

財務科目表（DW_CFS_SUBJECT_DM）：存儲財務系統科目信息。來源系統包括：財務系統。另外存在對應拉鏈表。

財務輔助代碼表（DW_CFS_ASSISTCODE_DM）：存儲財務系統輔助代碼（分析代碼）信息。來源系統包括：財務系統。另外存在對應拉鏈表。

余額表（DW_CFS_BALANCE_MM）：財務系統余額信息，按月存儲。來源系統包括：財務系統。因科目余額變化頻率較大不建設對應拉鏈表。

憑證分錄表（DW_CFS_VOUCHER_DM）：財務系統憑證分錄信息，按日并存儲多日數據。來源系統包括：財務系統。因科目分錄變化頻率較大不建設對應拉鏈表。

營銷模型

一次營銷可以是機構為了獲取、保留客戶或者增強客戶關系、占有市場的一種活動，可能是一種有明確市場目標的銷售活動（如新產品推廣等），也可能僅僅是跟客戶的一種互動的交流活動（如客戶調查等）。目前源業務系統在這方面的信息比較欠缺，本主題的設計以基礎設計為主，更多的擴展和客戶化留待以后完成。

唯一標識

營銷：用營銷編號作為唯一標識。

營銷活動：用營銷活動編號作為唯一標識。

營銷事件：用事件主題中的事件編號作為唯一標識。

主要內容

?

營銷：是一些比較大的營銷策略記錄和規劃，可存放所有層次的營銷策略，主要記錄營銷的計劃收入、預計成本等。

• 營銷類型代碼：通過代碼來唯一描述營銷計劃的商業目標，如：交叉銷售、新客戶獲取、客戶保留等。
• 預計費用、預計獲利、預計聯系客戶數、預計積極反映的客戶數、預計新贏得客戶數：營銷預計的花費和效果，是預估的數據。

營銷活動：是對營銷的進一步細化，通過“營銷活動類型代碼”可區分為目標營銷和大眾營銷。

• 營銷活動實際單位成本：一個單位的實現成本，這里的單位可能是一封MAIL、一個電話、雜志上的一個廣告等。
• 營銷活動實際單位數目：此營銷活動涉及多少個單位，比如要發多少封EMAIL、要打多少個電話等。
• 營銷活動狀態代碼：1－已完成，2－待完成，3－由于某種原因而中途流產，4－暫停。

大眾/目標營銷：是營銷活動的子類，目標營銷是直接針對具備某種特征的個體進行的營銷活動；大眾營銷可以是直接面向一組人群，如電視廣告、報刊雜志廣告等類型的營銷；而大眾/目標營銷事件是營銷的真正實施過程及結果的記錄，與營銷活動相互呼應。

廣告：是針對客戶細分的市場活動信息，通常會宣傳產品或者一些特殊的項目，廣告可以在雜志、網絡或者電視媒體上等渠道上進行。

廣告安置：包含何時何地通過一個特定的渠道交付廣告的信息，隱含了廣告和渠道的關系。

營銷活動優惠項目：是客戶可利用的確定的激勵措施，通常包括適用條件和針對使用條件的獎勵；它通常是一個精心設計的實現一定目的的行銷行為，可以是營銷活動的一部分。

優惠項目：是客戶可利用的確定的激勵措施，通過優惠項目編號唯一表示一個優惠項目，與營銷活動本身建立關聯關系，體現在營銷活動優惠項目實體中。

營銷活動費用：記錄營銷活動的預算和實際開支。

• 營銷費用類型代碼：記錄營銷活動各費用類型，如：咨詢費用、電視播放費用、印刷費用、人工費用等。
• 營銷活動預算費用和實際費用：記錄具體的預算費用和實際費用。

?

重要關系

?

營銷渠道類型關系：描述任何層次營銷中涉及的渠道類型的關系實體，一個營銷/營銷活動活動可以通過多個渠道完成。

營銷地域關系歷史：描述營銷針對的目標區域組織，如銷售區域的關系實體。

營銷當事人關系：描述營銷涉及的當事人，關系類型代碼主要包括：目標客戶、執行人等。

營銷內部機構關系：描述營銷涉及的內部機構，如發起機構、管理機構、目標機構、執行機構等。

營銷協議關系：記錄一個營銷映射到多個協議，以及一個協議映射到多個營銷的關系實體。

營銷產品關系：記錄營銷與產品的關系，某個具體的營銷可能只涉及部分的產品。

渠道模型

渠道主題所描述的是當各種事件發生時，當事雙方（主要是指客戶和證券公司）進行交互和接觸的手段及方法，通過它客戶與證券進行接觸、購買產品、使用服務并交流信息。

唯一標識

渠道的唯一標識由“渠道類型編號”和“渠道編號”兩個字段組成。

主要內容

?

?

渠道類型組：渠道類型的分組是由于不同的“渠道類型分組原因代碼”所做的分類，如銷售渠道、人工渠道、電子渠道等，滿足不同業務部門管理統計的需要。

渠道統計學信息歷史：記錄渠道的各種希望關注的特征統計學信息。

渠道類型/渠道容量歷史：記錄每類渠道/每個渠道的最大工作容量信息。

• 渠道類型/渠道容量的時間周期代碼：如月、日；
• 渠道類型/渠道容量的容量值：具體記錄容量值的大小。

渠道事件：記錄渠道本身發生的一些事件信息。

重要關系

?

當事人渠道關系歷史：記錄渠道與當事人的關系歷史，同時記錄這些關系的有效時間段。

內部機構渠道關系歷史：記錄渠道和內部機構的關系歷史，如渠道的歸屬機構等。

產品渠道類型關系：記錄某些產品和某個種類渠道的關系。

渠道類型/渠道和營銷/營銷活動關系：一般情況下制定一個營銷策略時會因為渠道的成本、效果不同來指定某種渠道或渠道種類，真正開展一個營銷活動時也必然要借助某個渠道。

渠道地址關系歷史：用于記錄渠道的地址信息，如安置地址、聯系電話、前置機IP地址等，同時保存歷史。

數據集市

? 數據集市也叫數據市場，數據集市就是滿足特定的部門或者用戶的需求，按照多維的方式進行存儲，包括定義維度、需要計算的指標、維度的層次等，生成面向決策分析需求的數據立方體。簡單來說數據集市就是一個遵循數據中心規范的、可定制化的、面向應用的數據集合體。

數據集市的數據來源于數據倉庫模型層；同時數據集市是各類應用的數據源。根據應用屬性的劃分，數據集市可以分為客戶分析數據集市、運營管理數據集市、市場分析數據集市、風險管理數據等。數據集市根據業務應用的滋生而調整，當出現相對獨立的應用系統或者數據需求時，則針對該類應用建設對應的數據集市。

其中風險管理數據集市是xx數據中心系統和全面風險管理系統進行對接的專業數據集市，在風險管理數據集市中定義全面風險管理的基礎數據需求，達到全面風險數據接口規范化的目的；同時數據中心也會采集全面風險管理系統中統計的風險管理指標，納入到數據中心指標庫體系中，為風險數據分析、風險計量、風險管理領導者駕駛艙的建設打好數據基礎。

數據服務平臺

數據服務平臺目標

梳理復雜公司的數據流向網，將數據中心建設成公司企業級數據平臺，所有需要數據的管理系統向數據中心索取數據，數據中心負責整合管理系統需要的數據并提供數據接口服務，業務系統出現升級導致表結構變更，或者出現大的變更時，保證數據中心對管理系統的表結構不變，減少對管理系統的影響。

?

數據服務模式

建立業務支持、數據接口服務層，可以讓各個管理系統主動連接到數據中心來獲取需要的數據，主要適用于目前證券公司已經在使用的管理系統，例如風控、CRM系統等。為了保持數據穩定或者其管理系統架構不變，只做數據源的切換，從交易系統采集切換到數據中心采集，通過數據同步軟件同步交易系統數據原樣到數據中心（原始層）。對于在數據中心后上線的管理系統，則需要從ODS層、EDW層獲取源系統數據，從而保證在源系統變更時，不會影響從ODS層、EDW獲取數據的管理系統。

管理系統	變動類型	備注
已上線管理系統	交易系統采集切換到數據中心采集	減少管理系統架構不變和保持數據穩定
數據中心后上線系統	從ODS、EDW獲取數據	后續生產系統變動對管理系統影響小
查詢統計	訪問數據中心的數據	獲取穩定、一致數據

數據服務方式

實現方式主要有以下三種：

接口訪問方式	詳細方式	備注
WEB Service	標準通用接口，提供少量數據訪問方式	可為后續呼叫中心等提供實時少量數據訪問
主動推送	利用數據同步工具將數據推送至下游系統	下游系統對接數據中心困難、中等規模數據量
授權用戶直接訪問	數據中心開通相應的用戶和接口表，提供下游系統采集或直接訪問	適合超大歷史數據

Web Service接入

?

Web Service是一種標準的服務調用接口，因此只要符合標準的外圍業務系統都可以進行接入，在這種方式下，數據訪問服務通過J2EE服務器加載數據服務應用程序來實現，服務的跨網段調用通過在網段之間部署Web服務器來實現。

服務調用所提供的服務、用戶、權限，由管理程序進行統一的管理。

設計要點

身份認證 調用端需要通過身份認證后才能進行服務調用，身份采用用戶/密碼方式進行認證，系統需要為不同的調用端提供不用的登錄用戶。

通訊加密 所有的請求和應答都需要進行通訊加密。采用Web Service提供服務時，可通過HTTPS協議進行通訊加密，以保證數據的安全性。

權限管理 針對不用的訪問用戶，提供不同的服務調用權限，用戶不能越權訪問數據。

接口提供 將所提供的服務的輸入、輸出接口提供給調用者，使用WEB Service本身的機制將服務接口提供給調用者。

主動推送

? 在下游系統對接數據中心系統取數困難的情況下，數據中心可以利用數據同步工具將下游系統所需數據主動推送到下游系統數據庫。

授權用戶直接訪問

數據中心針對不同業務系統建立對應的對外數據服務用戶, 通過數據接口管理界面可對該用戶設置相應的數據訪問權限。同時數據接口管理提供明確的接口表說明,外部應用只要得到授權許可,就可以直接訪問該用戶下的數據,從而達到數據中心提供數據服務的目的。

數據接口服務安全性

Web Service數據訪問安全

對于小數據量的數據訪問服務，我們通過Web Service來實現，首先訪問Web Service的用戶需要通過校驗，其次，該用戶具體通過Web Service訪問的記錄需要有詳細的記錄，包括訪問時間、訪問對象和訪問記錄明晰。

用戶角色訪問安全

用戶登錄數據管控平臺，需要首先經過用戶的認證機制，通過用戶角色來分配權限，權限分成菜單功能權限和數據訪問權限。對于數據訪問權限，需要定位到營業部級別，即營業部人員只能查看自己營業部內的數據。對于具體哪個用戶訪問那些功能需要有明晰的日志記錄。

數據庫級別安全

下游系統對接CDH數據平臺

若下游系統直接對接CDH數據平臺，則引用CDH數據安全訪問機制。

下游對接Oracle數據庫

對于部分下游系統無法直接對接CDH數據平臺，數據中心將接口數據從CDH同步至Oracle數據庫，在Oracle庫上建立一個用戶DCSER來對外提供數據訪問用戶，對于數據庫用戶DCSER必須明確限定外界具體能訪問的表。

對于具體外界對象對DCSER訪問的明晰信息可以通過兩種方式實現，第一，開通數據庫審計功能，第二，定期查詢數據庫用戶執行的SESSION并記錄保存以便稽核。包括訪問的時間、機器名、IP、運行的SQL語句等，由于數據量會比較大，可以采取拉鏈的形式存儲相關審計信息。以上信息都需要在數據管控平臺中提供查詢功能。

智能分析平臺

平臺結構

智能分析平臺的優勢，是基于綜合的數據和開放的工具，能制作各類格式報表，快速大量生成，并分發到相關需要的人。

通過智能分析平臺，業務人員如同使用Office Excel 一樣，能方便的在線對數據進行分析。同時分析結果能發布到數據門戶或者嵌入其他業務系統（如CRM、呼叫中心）中，以方便一線的人員（如客服人員、投資顧問）使用。

平臺功能類型

報表：

?

提供各種廣度的報表類型 ；

在各種類型的報表輸出中提供一致信息；

可以個性化、有針對性地定制；

允許多用戶、多用戶群、以及和IT之間的協作；

可以通過email、門戶網站、MS-Office、搜索、以及移動設備等進行訪問。

BI分析：

?

?提供多方位信息視圖；

方便快捷地執行復雜的分析和情景模擬；

揭示趨勢背后的“為什么”， 了解癥狀及原因；

輕松地從信息的摘要級別提高到細節級別。

領導駕駛艙

為企業高層提供的“一站式”決策支持的管理信息中心系統；

各種常見的圖表（速度表、柱形圖、環形圖、預警雷達等）形象標示企業運行的關鍵指標（KPI），為復雜信息提供了一目了然、重點突出的視圖；

靈活配置，根據用戶習慣，選擇合適的圖形來顯示想要了解的具體指標，一個圖形可以反映多種指標，一種指標可以由多個圖形顯示的交叉實現模式，配置更加靈活。

數據挖掘

根據用戶社會屬性、交易行為和終端日志等信息而抽象出的一個標簽化的用戶模型 ；

基于logistic回歸模型，預測證券公司預流失客戶，分析其流失原因，證券公司可以及時采取相應措施，挽留客戶；

基于協同過濾模型，挖掘客戶與產品的相似度，進而對客戶開展有針對性的營銷，以滿足不同特征用戶各種的需求，提升客戶滿意度和忠誠度。

BI工具選擇

BI（Business Intelligence）即商務智能，它是一套完整的解決方案，用來將企業中現有的數據進行有效的整合，快速準確的提供報表并提出決策依據，幫助企業做出明智的業務經營決策。

外資企業中IBM公司、Oracle公司和Microsoft公司產品線覆蓋了全部BI領域，尤其是MicroStrategy獨立的BI廠商。幾款產品都有較好的性能，滿足大中小型企業的需求。

國內軟件商中帆軟采用了類EXCEL設計模式，支持多SHEET和跨SHEET計算，完美兼容EXCEL公式，用戶可以所見即所得的設計出任意復雜的表樣，對中國式復雜報表支持力度比較高。同時帆軟系列軟件推出的FINEBI工具很好的支持了國內各行業領導者駕駛開發的需求。

FINEREPORT

FineReport有著“專業、簡捷、靈活”等特點：

功能全面且專業：支持關系型數據庫、BI多維數據庫的連接取數，支持中國式復雜報表的處理，支持離線填報、多級上報、數據填報，有著安全、完善的權限控制方案等。

設計報表簡單高效，學習成本低：類Excel的界面使用戶不需任何額外學習成本，零編碼開發報表，輕松的拖拽數據，一兩分鐘內就能完成報表制作。

行業積累豐富：對各個行業都有著自己獨到的見解，提供諸如一系列或從上之下、從內到外涉及戰略、運營、組織、財務、營銷等多個主題的解決方案和實施方案。

本方案中推薦簡單報表和中國式報表采用輕量級FINEREPORT工具和FINEBI分析工具。

數據管控平臺

數據管控平臺銜接了數據基礎平臺、智能分析平臺、業務展現平臺內部和相互之間的關系。提供了ETL調度與監控、數據質量管理、業務分析數據可視化等功能。

ETL調度與監控

ETL調度管理目標為取代ETL工具內部JOB調度工具，數據管控平臺的ETL調度管理可適用于任意ETL工具JOB的調度工作。

數據抽取

??? ETL調度支持的數據抽取模式如下：

靜態數據的獲取

靜態數據是在一個給定時刻獲取的數據。就像是對相關源數據在某個特定時刻的快照。對于當前或者暫時的數據來說，這個獲取回包括所有需要的暫時數據。而且，對于周期性數據來說，這一數據獲取將包括每一個源操作型系統中可以獲得到每個時間點的每一個狀態或者事件。一般在數據倉庫的最初裝載的時候使用靜態的數據獲取。有的時候，會需要一個對于一張維度表的完全的刷新。

通過交易日志獲取

這個選擇使用了數據庫管理系統中保存的應付各種可能發生災難所備份的交易日志。對于每一個交易的增加、刷新或者對數據庫表的刪除，數據庫管理系統都需要立刻將其記錄在日志文件中。這種數據抽取技術通過讀取交易日志，選擇所有相關交易記錄。在操作型系統中沒有額外的管理費用，因為日志的記錄本來就是交易處理的一部分。

通過數據庫觸發器獲取

同樣，這個選擇可以應用于全都是數據庫應用的源系統中。觸發器是存儲在數據庫中的特殊過程（程序），在特定的預定義事件發生的時候被觸發?？梢詾樗行枰氖录摻ㄓ|發器程序。觸發器程序的輸出被寫入一個單獨的文件，可以用來為數據倉庫抽取數據。

在源應用系統中獲取

這個技術也是針對應用程序的數據獲取。換句話說，就是源應用程序用來幫助數據倉庫中的數據獲取。要對源程序進行修改，寫入所有對源文件和數據庫表的增加、刷新和刪除。然后另一個抽取程序可以使用獨立的包含源數據變化的文件。

基于日期和時間標記的獲取

每次創建或者更新源記錄的時候，都會有一個關于時間和日期的標識。時間標記提供了數據抽取中選擇記錄的基礎。在這里數據的獲取會在以后的時間中發生，而不是在每一個源記錄創建或更新的時候。

通過文件的比較來獲取

在對產品數據的變化進行每天的數據抽取工作時，你對今天的產品數據和昨天的數據進行了完全的比較，比較了記錄并發現有插入和刪除的操作。那么數據抽取就獲取了這兩個數據之間的變化。

各種方式優劣勢比對：

?	靈活性	實時性	源性能影響	應用程序修改	面向文件系統	內部開發成本
靜態數據獲取	好	低	無影響	無需修改	不能	無
交易日志獲取	不靈活	高	無影響	無需修改	不能	無
觸發器獲取	不靈活	高	無影響	無需修改	不能	無
源應用系統獲取	好	高	無影響	需修改	能	高
日期和時間標識獲取	好	中	無影響	可能需要修改	能	無
文件比較獲取	好	中	無影響	無需修改	能	無

?

任務分組

本平臺ETL調度管理對象分為任務組與簡單任務，每個簡單任務對應于ETL工具中的一個JOB。任務組由若干簡單任務組成，支持靈活的按照源系統、層級、主題來劃分任務組。

利用任務流來配置任務組和簡單任務的前后置及串行并行關系。

任務調度

本平臺支持按時間、事件、組合觸發及手動觸發

時間觸發器：支持按自然日、交易日、周、月、年來設置觸發，在每日觸發中，也可設置一定時間間隔觸發來達到準實時調度

事件觸發器：用某個事件來觸發任務的執行，如上游系統初始化完成、前置任務執行完成等

組合觸發器：時間觸發器和事件觸發器有效結合來設置觸發

手動觸發：在需要時或者出現異常時，可以手工進行干預

調度監控

本平臺支持自設維度對任務進行監控，支持實時監控、日終監控等，調度日志也會完整保留，便于后續對調度運行情況的跟蹤。同時，支持與短信平臺、郵件平臺進行對接，方便運維人員跟蹤監控。

在調度出現異常時，支持手動發起失敗的任務。可以從失敗節點發起，也可從頭發起。

監控方式

數據中心建設中，對系統的運行監控要實現監控的多樣化，其中除了包括主動狀態查詢，也包括被動的監控狀態接收。

統一監控：提供統一監控場所，集成現有的所有監控信息

可手工觸發監控：對監控出現的結果，如果存在異常，那么在查明異常原因的情況下，能夠手工對監控結果進行處理，例如重新出發監控內容，反饋回新的狀態。

警告通知方式：短信和郵件。出現異常能夠短信或者郵件提醒。主動發送給管理員。

數據質量管理：數據質量檢測規則、數據質量檢測、數據質量檢測報告。

監控點

實時采集是否成功；

日終采集是否成功；

歷史采集是否成功；

層與層之間的清洗監控；

數據的正確性及準確性監控。

ETL工具運行狀況；

采集主機的運行狀況；

數據中心主機運行狀況。

預警：運維平臺可默認或由管理員自定義系統運行的閥值，當系統性能達到設定時，通過郵件、短線發送預警信息給管理員

警告：當功能監控發現系統執行出現異常時，通過郵件、短線發送預警信息給管理員。

監控實現

狀態表

ETL工具接口。通過訪問ETL提供的SDK編程接口實現ETL調度的日志訪問和日志分析來獲取調度的情況及錯誤信息。

元數據管理

元數據管理是數據倉庫系統建設的重要環節，因為數據倉庫中存放規劃整合了證券公司集中交易、資產管理、清算、TA、CRM、財務等不同業務系統同時也要兼顧到未來新上線的業務系統。為了更好的完成數據倉庫關于數據標準建立和數據質量管控的定位，數據中心設計了一套元數據管理模塊，元數據管理模塊包括技術元數據和業務元數據的管理。通過開發元數據管理模塊可以實現對元數據的獲取、集成和訪問。元數據管理涉及到數據倉庫的數據采集、數據標準統一、邏輯模型設計、物理模型設計、數據中心日常運行維護的整個生命周期，是數據倉庫構建過程中十分重要的一環。元數據作為數據倉庫用戶的路線圖，它必須為數據倉庫的開發、管理、使用的角色提供必要的技術和業務支持。

證券公司元數據管理平臺，需要包含以下主要功能：元數據日常管理和維護、版本管理、權限管理、提交與審批管理等功能。

元數據日常管理和維護：支持開發人員通過頁面聯機、批量方式對技術元數據、業務元數據和操作元數據進行新增、修改、刪除，提供各類元數據間的調用關系管理、變更通知以及配套的審批管控流程。

版本管理：通過制定相關的應用系統開發流程規范，將元數據維護和變更管理納入應用系統開發流程，提供元數據基線管理、版本制作、版本提交等功能，并實現與相關版本發布系統或平臺的有效對接。以版本發布為基準，做好元數據的基線管理。

權限管理：信息安全是元數據管理系統的重要環節。元數據管理系統采用分類授權、分角色授權等原則，對訪問元數據管理系統進行權限控制。設置用戶權限，建立與應用系統、各類元數據的關聯關系；針對用戶權限變更，提供權限申請審批管理流程，加強事中的審核控制、事后的監督核查。

提交與審批管理：設定相應的審批控制流程，加強對元數據的管理，保證元數據平臺的準確性、時效性和穩定性。對于涉及上下游應用調用的借口、文件等元數據，應將下游應用納入審批流程，確保可以及時評估和應對上游元數據變更帶來的影響；對于重要的元數據對象，設置特殊的高層及審批流程，確保系統核心元數據的穩定性。此外，為確保應用系統正常的研發等活動不受影響，要注意審批流程的時效性設計。

信息統計分析：主要提供元數據管理系統質量評估、各類資產多維度統計和報表功能、資產變更統計及排名分析等。通過元數據管理系統提供的信息統計分析功能，能夠及時了解元數據管理系統中元數據資產整體和變更情況。

以下是幾種常見的元數據管理方法：

表結構：表結構屬于技術元數據范疇，表結構管理應該和應用系統的開發、測試、版本制作等研發流程緊密結合起來，包括由元數據管理系統的表結構信息來驅動開發環境、測試環境中數據庫表的建立。通過這種方式可以確保元數據管理系統表結構信息的準確性和及時性。

文件：文件及文件傳輸信息屬于技術元數據范疇，在開發階段就應該明確并體現到元數據管理系統中。使用方在需要使用文件時，需要使用部門在元數據管理系統中明確使用情況。當提供方出現文件結構變化、邏輯變化、數據字典變化時，需要元數據管理系統通知接收方保持同步變化。生產環境中的數據傳輸變化系統也會依據元數據管理系統的內容進行相關調整，確保元數據管理系統中的文件及文件傳輸信息的準確性和及時性。

接口：接口程序屬于結構性技術元數據范疇，應用接口及接口調用關系均在元數據管理系統統一登記管理。所有接口新增或者某應用在調用一個接口（或不再調用一個接口）時，都要求于應用開發階段在元數據管理系統中登記。接口的修改、作廢等，由元數據管理系統自動通知使用接口的聯系人，從而對接口的使用方進行相應的改造。

公共代碼：公共代碼需要通過字典描述，并且隨各應用系統的變化不斷濟寧擴充和調整，各相關應用系統需要及時了解最新情況的數據資源。公共代碼的種類眾多，各類公共代碼需要遵循相關的技術要求。元數據管理系統指定相匹配的各類管理規則，實現對公共代碼的規范、標準管理，保證公共代碼的質量。

指標：指標元數據都應該在元數據管理系統中進行統一管理。為了避免指標重復開發或者名稱相同但口徑存在差異，對于新增的指標，需要在指標加工前就明確指標元數據信息，嚴格控制重復指標新增準入。指標業務元數據由指標需求提出方明確，指標技術元數據由指標加工處理的技術部門明確并進行登記。對于存量指標，則需要定期梳理回顧，及時清退低效指標。

數據標準化建設規劃的主要目標是確保經營管理信息的完整性、有效性、一致性、規范性、開放性以及共享性，從而能夠暢通無阻地交互信息，進一步提升企業核心競爭能力，助理戰略發展目標的實現。數據標準化建設規劃需要遵循一定的原則，在進行數據標準化建設時，要重點考慮代價、效益和風險三個主要因素。

元數據的收集

? ???數據中心針對元數據的收集場景設計了元數據采集和元數據錄入映射兩種類型的入口。元數據管理模塊支持利用不同的元數據采集技術對各種來源的元數據實施采集，如：數據建模工具、源系統、ETL工具/程序、前端展現工具、文檔化的業務元數據等元數據來源。元數據管理模塊支持手動觸發或者通過觸發器發起元數據采集操作的過程。若是通過存量系統梳理功能或者需求管理功能鏈接過來的元數據導入請求，則通過平臺中的錄入和手工調整元數據映射的方式進行元數據收集。

元數據的管理

元數據管理能夠提供元數據瀏覽、檢索、維護等服務，方便系統管理員或者業務人員對所需業務、技術與操作元數據的使用。平臺的建設也必須考慮到元數據在不同應用中的表現形式可能不同。為此，有必要將元數據區分為兩個層面，即系統級元數據的物理存儲層與元數據的表現層。物理存儲層存放元數據的本體，表現層提供運用元數據的環境。

提供元數據變更通知機制：因元數據直接影響到存儲模式的結構和軟件工具的行為，所以再將一個修改過或者擴展后的元數據元素放回原有環境時，需要特別謹慎。業務人員可以向元數據管理平臺預訂通知消息，要求在元數據元素某個部分發生改動時通知它們。在一些環境下，一些重要的管理程序或過程可能會首先關閉受到元數據變化影響的、處于活動狀態的工具；然后，將修改過的元數據放入受到影響的工具中，在重新啟動工具，指示它將修改過的元數據融入到它內部的實現模型中。

提供元數據版本控制機制：必須為被管理的元數據元素設立專門的版本控制規則，特別是元數據實例必須具有版本控制功能，包括定版、版本比較、版本恢復等功能。在特定的環境中，元數據管理體系結構需要跟蹤、控制和發布不同版本的元數據。雖然最終要由系統管理員或者業務人員來決定需要哪個版本的元數據,但元數據管理體系結構提供相應的機制來使具體應用能夠發現和請求不同版本。

元數據的分析

元數據管理應提供元數據的全局影響分析、血統分析功能，能使數據倉庫開發人員積極地評估更改的影響，確定開發、實施更改所需的工作量和系統代價。

血統分析以圖形方式展示以某個元數據為終止節點，其前與其有關系的所有元數據，反應數據的來源與加工過程，使用血統分析可分析數據來源和對數據質量問題的定位。

影響分析以圖形方式展示以某個元數據為起始節點，其后與其有關系的所有元數據，反應數據的流向與加工過程。使用影響分析可分析數據流向和對數據轉換中錯誤的定位，用戶通過選定指定的元數據，分析該元數據的影響數據流圖。

重要程度分析，表元數據與其他元數據的關系的數量，例如，表與ETL程序、表與OLAP、表與指標等。該數量越高，表示這張表的重要程度越高，在修改或者刪除的時候就需要慎重考慮了。本功能用以展示元數據管理系統中所有類型為表的元數據的關聯度。用戶可以輸入查詢條件，用于查詢關聯度在一定數量之上的表。

數據質量管理

數據倉庫從運行于證券公司的集中交易、資產管理、清算、TA、CRM、財務等不同系統中抽取數據，經過各種各樣的傳輸、轉換和處理，加載到數據倉庫中以后，為各管理系統及數據挖掘提供基礎數據。

隨著用戶對數據分析需求的增長，數據倉庫中數據質量變得越來越重要。質量差的數據不僅可能對企業生產造成負面影響，而且會使用戶覺得所產生的報表不可信賴，更重要的是錯誤的數據容易誤導用戶，從而造成管理決策的失誤，此外低質量的數據會使雇員失去對企業的信心?？蛻魧﹀e誤數據將無法忍受，例如發送錯誤的成交信息、成本價或者不正確的客戶資料，會認為公司管理混亂，從而造成客戶流失。所以說數據質量是數據治理的核心功能，也是數據倉庫的生命。

在證券公司的很多系統中，數據是最重要的處理對象，也是最終呈現給系統用戶的內容。系統用戶認為系統是否發揮了應有的作用很大程度上依賴于系統提供的數據是否真實準確，高質量的數據將提升用戶對系統的信心，進而影響企業IT投資回報率。

數據質量管理目標

數據倉庫向用戶提供了集成的、一致的、綜合的、高質量的信息以支持管理決策，但是數據倉庫的數據來自各種不同的操作性數據源，并且經過了各種各樣的傳輸、轉換和處理，要確保數據倉庫的質量并非易事。數據質量是數據倉庫的生命，如果數據倉庫中的數據毫無質量可言，那么該數據倉庫就沒有任何的價值。

總體上來說，數據倉庫對數據質量的要求可歸納為：

(1)數據的正確性，是指數據是否正確體現在可證實的數據源上；

(2)數據的完整性，是指數據倉庫中數據之間的參照完整性是否存在或一致；

(3)數據一致性，是指數據倉庫中的數據是否被一致定義或理解；

(4)數據完備性，是指所需要的數據是否都存在；

(5)數據有效性，是指數據是否在企業定義的可接受的范圍之內；

(6)數據時效性，是指數據在需要的時間是否有效；

(7)數據可獲取性，是指數據是否易于獲取、易于理解和易于使用；

(8)數據的冗余性，是指數據倉庫中是否存在不必要的數據冗余；

(9)數據邏輯合理性，主要從業務邏輯的角度判斷數據是否正確。

數據質量管理技術框架

?

數據質量管理功能描述

?

數據質量問題分析

數據質量問題的表現形式及其產生原因可以歸結為以下幾個方面：

(1)冗余因素：各個應用系統自成體系，數據和程序冗余度高，數據孤島現象嚴重，表現為多義字段、主鍵重復等。

(2)系統因素：某些應用程序測試不充分，不斷產生錯誤的操作型數據，表現為數據遺漏、數據錯誤、矛盾值、違背業務規則、沒有意義的默認值等。

(3)數據遷移因素：業務系統更新后，會增加、刪減或修改部分舊的業務規則，表現為在將老數據遷移進新系統后，可能會引入缺漏、錯誤、無法關聯等遺留問題。

(4)操作因素：比如前臺數據錄入可能造成數據質量問題，有的前臺柜員為加快柜面辦理速度，對于客戶開戶時提供的家庭電話、職業、地址等信息不做檢查，這會造成操作性數據的信息缺漏、錯誤等問題。

(5)接口定義因素：有時業務系統之間交換數據時接口Bug也可能引入問題數據。

(6)其他因素：客戶通過網絡辦理業務時，基于隱私信息保護的心理，也可能僅僅填寫必需項或者隨意填寫，對企業而言有用的大量信息是空白或者不合常理，這也會造成信息缺漏或錯誤數據問題。數據質量問題存在于數據倉庫建設過程中數據流動的各個環節，基本上分為數據源、ETL過程中和數據倉庫內幾個部分。數據質量存在問題的根本原因在于數據源，可以歸為以下幾類：

數據格式問題，例如數據缺失、超出數據范圍、無效數據格式等等。

數據一致性問題，出于數據庫性能考慮，有時候可能會有意的去掉一些外間或者檢查約束。

業務邏輯問題，由于數據庫設計得不夠嚴格或者謹慎造成。

數據質量管理設計

數據模型中實體語義、屬性重定義

在數據模型上，實體語義、屬性重新定義，統一命名規則、編碼規則、數據字典，增加自定義數據類型。例如各系統對分支營業部、客戶狀態、性別的字段名和值都會不一致，而在數據倉庫模型中需要將其重新定義，并定義其屬性值。增加自定義數據類型，例如將所有的姓名字段數據類型描述為自定義類型tyName，在姓名字段數據類型發生變化時，可通過自定義類型找到所有相關的數據項，并通過變更tyName的數據類型，可以實現所有相關的過程、表結構變更。通過元數據管理中增加數據模型描述、增加數據字典描述來增強上述內容的可維護性。

數據字典映射檢查

在ETL清洗過程中，對于源系統不同的字段值，進行數據字典映射，映射成標準的字段屬性值。同時建立數據字典映射的檢查機制，來防止生產系統因業務變更而產生新的屬性值，導致數據質量降低。在檢查出新增屬性值后，通過報表形式或者預警形式告知維護人員，來維護相關信息。

?

表結構變更監控

數據倉庫實施過程中依賴的源數據的表結構可能會因業務發生變更而變更，例如字段數據類型變更，增加或者減少字段，這些變更都會導致數據ETL過程處理失敗或者出現數據不一致的現象，因此需要建立表結構變更監控。

數據核對

在清洗過程中，增加數據核對部分，主要核對重要數據表的記錄數、關鍵字段匯總值核對、明細表與匯總表相關字段進行核對，以保證重要數據在清洗過程中不會出現數據丟失或者失真時，通過預警告知運維人員進行數據處理。對于人工處理需要留有詳細的日志記錄。

不規范數據處理

對于不規范的數據(數據值為空、數據值不符合格式、精度不符合格式、不符合數據屬性值定義)，在ETL清洗過程中給數據打上錯誤標記，然后通過。首先保證這些記錄順利通過，然后記錄一些錯誤標志，并通過報表反映出來?？赏ㄟ^這些特殊處理確保了數據的完整性。數據質量應該盡量確保在ETL環節中進行，因為每一點的錯誤都會導致后續處理的無限放大，因此盡量把錯誤和數據質量問題消除在靠前的位置。

老化數據和無效數據的處理

由于ODS和數據倉庫設計的內容未經后續的業務需求驗證，包括完整性原則，粒度最小化原則導致部分數據從使用以來一直未被使用過，這類數據就是無效數據，其會占用數據倉庫的空間和降低數據倉庫的效率。這些數據需要通過無效數據判定的算法定時從數據倉庫中處理。數據管控平臺應該提供數據使用效率的監控工具，并通過報表形式將判斷為無效數據和老化數據信息提供給管理員，以便進一步優化數據庫設計。

數據質量問題解決策略

數據中心將所有數據質量校驗規則分為前校驗和后校驗兩大類。前校驗即ETL過程開始之前即對源數據或者上層數據做一次校驗，保證進入ETL流程的數據有效性。后校驗即ETL過程結束之后，根據預設的校驗規則對數據中心的數據進行勾稽關系或者業務邏輯校驗，保證數據中心計算指標的有效性，準確性。以下是數據質量管理功能中三類校驗規則：缺失性校驗、預警性校驗和一致性校驗。

缺失性校驗：對系統中應該存在卻不存在的信息進行校驗，包括表、字段、數據字典、關鍵數據記錄缺失與否的檢查校驗。

?

校驗方式	校驗規則	校驗細則	處理方式
? 前校驗	原始層關鍵表存在性校驗	?	?
	數據字典映射缺失檢核	?	?
后校驗	產品信息缺失校驗	資管產品分類缺失校驗	?
	證券基礎信息缺失校驗	債券到期日缺失校驗	?
		證券評級信息缺失校驗	?
		證券分類信息缺失校驗	?
		總股本缺失校驗	?
	財務信息缺失校驗 ?	財務科目缺失校驗	?
		財務賬套缺失校驗	?

預警性校驗：對系統中的數據進行合理性校驗、錯誤性監測以及帶預警值的閾值校驗。

校驗方式	校驗規則	校驗細則	處理方式
前校驗	原始層數據趨勢性校驗	?	?
	到期功能提醒	手工證券分類有效期到期提醒	?
		公司等級有效期到期提醒	?
		手工證券評級信息到期提醒	?
		標的證券有效期到期提醒	?
		手工指標有效期到期提醒	?
后校驗	計算結果趨勢性檢查	指標波動預警	?
		指標波動下鉆明細查詢	?
	數據預警校驗	證券價格準確性檢測	?
		證券成本準確性檢測	?
		證券分類準確性檢測	?
		融資融券排名校驗	?
		自營賬戶校驗	?
		對沖賬戶校驗	?
		報表關鍵指標閥值預警	?
		?	?
		報表明細關鍵字段準確性校驗	?

一致性校驗：對于在系統中出現的指標進行前后一致性校驗和平行一致性校驗。前后一致性即根據勾稽關系或者計算公式對指標計算結果進行校驗。平行一致性校驗即在系統中相同口徑的指標進行校驗比對。

校驗方式	校驗規則	校驗細則	處理方式
后校驗	報表指標勾稽校驗	?	?
	財務公式校驗	?	?

校驗結果管理：系統中設置的校驗規則是普適性的，然而在實際業務流程中會有一些特殊業務要求。對于此類現象，我們在系統中對校驗結果進行集中統一管理。支持對校驗結果進行白名單、黑名單、灰名單的屬性設計，便于系統使用人員靈活運用校驗規則進行數據質量管理。

校驗權限管理：支持按照產品模塊進行權限管理，不同風險管理模塊的管理員只能操作對應模塊的校驗規則，避免因為業務操作原因導致其他產品模塊的數據質量問題。

?

?

權限管理

權限按照操作類型可以分為操作權限、賦予權限、審核權限；按照控制內容可以分為菜單權限、指標權限、組織機構權限。

操作日志管理

平臺在運行過程中，會時刻記錄操作人員的詳細操作信息，包括操作人員的登錄 IP 地址、登錄MAC地址、登錄退出時間、瀏覽過的頁面、執行過的操作等，同時也提供日志查詢功能，便于后續的審計及異常的定位。

?

系統部署

系統部署方案

?

方案通過防火墻隔離，總共分層三層安全級別區，其中，最外面第一層是日常辦公網絡等，第二層是數據中心相關系統，第三層是核心業務DB，其安全級別依次升高。

由于數據應用服務器和CDH集群中間存在一定量數據的傳輸與計算，如果還是通過防火墻的傳輸勢必照成相當的壓力，所以數據應用服務器直接越過防火墻通過交換機與CDH集群連接。

系統備份及應急方案

應用服務器備份

系統將專門準備備份服務器，預先安裝各種系統軟件，作為系統各應用服務器的冷備份，當系統的其中一臺應用服務器出現問題的時候快速接管，保證系統的正常運行。

災備及應急處理

利用上述方案搭建災備系統，在發生緊急情況導致生產系統無法啟動時，可及時開啟災備系統，在生產系統恢復后，再將異常期間的數據從災備系統中進行恢復即可。

系統應用設計

系統整合

系統整合根據整合的級別不同可以分成多種類型，應用級別整合,統一訪問整合,明細數據整合，數據服務整合。其中固定報表系統、查詢系統的整合屬于應用級別和統一訪問的整合;智能分析、CRM、資訊管理系統的整合屬于明細數據整合;呼叫中心、營銷管理、專家在線系統的整合屬于數據服務整合。

應用級別整合

此類整合一般是將OLTP系統中的報表及查詢功能遷移到報表系統或者數據中心系統上，主要目的是使用一個報表系統來實現分散在各個系統中(對原系統主要功能影響不大的功能)的查詢及報表功能。

所有的原有系統中的部分功能或者報表整體不再使用，遷移到新系統。新系統需要采集、轉換數據，然后開發相應的功能及報表。

優點:

統一的權限、數據口徑、統一的展示頁面，可減輕原有系統壓力。

統一訪問整合

此類整合主要是提供統一的訪問服務，通過WEB嵌入的方式來實現，用戶可在一個系統中實現所有的查詢及報表需求。

優點：

統一訪問頁面，單一登錄，可以使用所有應用。

數據服務整合

此類整合適合于公司的大部分系統，即數據中心通過數據服務的方式(服務方式見第四章)給各個系統提供數據。

對于呼叫中心、營銷管理、專家在線系統的整合，這些系統原先都是從各種業務系統系統獲取客戶的基本信息、交易信息、服務信息、營銷信息、反饋意見、投訴信息問卷調查、回訪記錄和分級分類信息，這樣在給生產系統造成一定的壓力的同時，所獲取數據之間也很難保證整體性、規范性和一致性，所以我們需要通過數據中心規范化相關信息，統一提供給呼叫中心、營銷管理、專家在線等系統。

優點:

改善公司現有數據流，減少數據流圖的復雜性。

減輕被索取數據多的OLTP系統的壓力。

相對于“數據整合”來說，系統之間保持獨立，相互之間也不會存在資源競爭。對于不同廠商開發的軟件，也能解決數據提供的問題。

技術實現

通過專用的ETL工具按照一定的周期抽取客戶的基本信息、交易信息、服務信息、營銷信息、反饋意見、投訴信息和分級分類信息到ODS數據層，為保證數據的一致性和統一數據字典，需要對各個數據源數據進行清洗和轉換，形成統一的客戶信息業務視圖。各周邊系統切換數據源訪問ODS數據層數據。

在ODS數據層基礎上，通過ETL工具建立數據倉庫和數據集市，建立客戶交易、價值、特征、異動、KPI等相關主題的數據模型。并通過智能分析平臺和業務展現平臺加以展現。

按照一定的業務規則，對客戶進行分類評級，關鍵是要做到業務部門可以靈活設置分類規則指標。這樣就要求我們在進行客戶分類評級設計時需要考慮增加動態配置表，提供業務人員相關的配置接口來完成設置分類規則指標。

證券公司指標庫

數據中心在完成數據倉庫建設和主題模型設計之后，具備了持久化存儲和管理證券公司各類業務數據的可能性。然而對于實際數據使用人員來說，數據倉庫設計思路中分層設計以及主題劃分，數據標準和規范的定義還是顯得比較復雜。為了滿足業務人員使用數據的便利和數據集市建設過程中冗余程度的降低，需要在數據中心里構建一套適合xx業務現狀的指標體系。該指標庫應覆蓋xx內所有的行業數據指標，并且可提供其他同類企業可參考的現有指標庫體系作為參考，同時滿足數據標準體系設計規范的指標庫建設。具備直觀的、精準的、明確的指標、維度及其對應關系。具備易于使用、維護且有標準的指標規范流程。

在指標庫中，列出不同指標的定義/公式、取數來源、指標歸集維度（母子孫公司維度）及指標頻率。

指標覆蓋業務模塊：包括公共指標、風控指標、業務指標等，如下圖所示。

指標覆蓋風險：市場風險、信用風險、操作風險、流動性風險、壓力測試、風險調整后收益、業績表現、等各類指標。

指標覆蓋類型：包括監管指標、效益指標、規模指標、財務指標、市場指標、客戶指標等。

指標庫使用：系統維護了多年應用與發展中經過準確性驗證和認可的約350個標準常用指標；系統對指標進行明確分類，方便用戶使用指標庫指標做數據管理器及二次分析，以及使用指標庫指標構建限額監控內容。以下就是xx數據中心設計的一套適用于證券公司業務的數據中心指標庫結構。

領導者駕駛艙

決策分析是企業運營的關鍵，科學的決策必須建立在及時、準確、全面、有效的信息資源基礎之上。在證券公司通過數據中心建設打通了內部數據通道,完成了基礎數據的集中、整合和指標體系建設后，如何把基礎數據和業務指標轉換為準確、恰當的決策信息，并且及時，直觀的提供給決策者，消除決策信息的不對稱，是企業信息系統面臨的重大問題。面對以上問題，領導者駕駛艙應運而生。

領導者駕駛艙是基于數據中心指標體系的高層決策支持系統。通過詳盡的指標體系和生動形象的的圖形化展示，實時反映企業的運行狀態。是一個為高層管理層提供的“一站式”（One-Stop）決策支持的管理信息中心系統。

從證券公司業務屬性上來看，領導者駕駛艙可以分為經營分析和風險管理兩大方向。從這兩個方向出發，可以覆蓋公司經紀業務、信用業務、資管業務、財務狀況、人力資源狀況、全面風險等業務條線的運行狀態。在此我們以風險管理領導者駕駛艙為例，介紹xx數據中心的領導者駕駛艙功能模塊。

風險管理駕駛艙概述

全面風險領導者視圖全面展示市場、信用、操作、流動性風險，關鍵監管要求指標和業務發展趨勢。通過了解全面風控的不同指標，提供充足的資本準備應對各風險，從而滿足監管機構對公司凈資本的各項要求。流動性覆蓋率LCR和凈穩定資金率NSFR是重要流動性監管指標，通過儀表盤的形式展示其是安全、預警或者低于監管要求。管理者駕駛艙以圖形的方式，對流動性風險各類指標從監管需求，并根據《證監會公告[2016]10號》設置風險控制指標的預警標準及監管標準，結合公司的經營狀況，予以展示。公司管理層可以根據提供的圖形及數據，關注以凈資本和流動性為核心的風險控制指標，提升公司的風險管理能力。

風險管理駕駛艙展示

證監會制定的《證券公司風險控制指標計算標準規定》對風險覆蓋率、資本杠桿率、流動性覆蓋率、凈穩定資金率等重要指標給出量化指導意見，明確規定了監管標準和預警標準。

通過儀表盤的形式直觀展示公司核心風險指標情況。

?

KMV模型賦予長期、短期負債不同的權重，根據測算資產負債差值和資產標準差，得出抽象的違約距離，違約距離越大說明越安全。一旦觸及警戒線，違約概率大幅提升。KMV公司最早發現安然問題，在安然宣布1年前用模型發現異常，三大評級機構2周前才發現。

客戶可以自定義警戒線，領導者視圖中會列出觸及警戒線的交易對手名單，提供管理層參考。

硬件以及第三方軟件

系統硬件平臺

xx的大數據平臺已經采用cdh版的Hadoop集群作為數據倉庫中心庫?？紤]到實際業務情況以及數據對接的需求，搭建關系型數據庫作為數據服務和對接的緩沖庫，因此建議選擇以下硬件平臺。

項目		配置
ETL服務器&WEB應用服務器 1臺	硬件	IBM 750 2CPU/64GRAM
	操作系統	Windows 2003 Server
	軟件	KETTLE 5.1 & Jetty
BI服務器 1臺	硬件	IBM 750 2CPU/64GRAM
	操作系統	Windows 2003 Server
	軟件	FINEBI
數據服務服務器1臺	硬件	HP DL380 2CPU/8GRAM
	操作系統	Linux
	數據庫	Oracle 10G/11G
存儲	硬件	EMC CX4-480? 容量 2T

考慮到實際情況，ETL、WEB、BI、數據服務等服務器在機器硬件性能允許的情況下，可以進行服務器合并。

第三方軟件

對于第三方軟件的選取我們有兩種方案如下，鑒于價格上的優勢，我們推薦FINEBI作為本項目的BI工具。

項目	配置	作用
ETL工具	KETTLE 5.1	ETL調度工具，用KETTLE來調用Hadoop平臺的sqoop程序或者hivesql腳本
BI	FINEBI	領導者駕駛艙開發工具
數據庫	Oracle 10G/11G	數據中心平臺配置庫、數據服務緩沖庫

?

項目計劃與實施

項目總體計劃

階段		日期 （工作日）	階段目標	階段文檔	涉及雙方人員
項目準備	項目前期準備	T+(-5)-T	設備選型、設備采購、人員組織、編寫文檔規范、編寫設計規范和開發環境準備	?	雙方項目經理
需求調研	整合內容及業務口徑調研	T+1-T+10	業務需求及分析，明確要整合的業務系統內容，明確業務指標口徑	業務系統需求說明書 指標口徑說明書	需求經理，業務人員
	指標庫需求調研	T+6-T+80	指標庫需求分析	證券公司指標庫設計說明書	需求經理，業務人員
	領導駕駛艙需求調研	T+6-T+100	領導者駕駛艙需求分析	領導者駕駛艙需求說明書	需求經理，業務人員
環境搭建	環境搭建	T+1-T+20	1.數據庫安裝 2.ETL工具安裝 3.BI工具安裝 4.平臺搭建	相關安裝文檔	雙方項目組成員
數據基礎平臺	概要設計	T+11-T+20	1.確定系統架構 2.技術框架設計 3.制定數據標準 4.制定數據接口 5.制定ODS表結構 6.制定EDW表結構	概要設計說明書 詳細設計說明書 數據庫設說明書	雙方項目工程師
	數據ETL開發	T+21-T+80	使用ETL工具進行數據抽取、清洗、轉換	ETL調度及流程設計	雙方項目工程師
	ODS層開發	T+31-T+50	ODS層開發，配置相應調度	?	雙方項目工程師
	EDW層開發	T+51-T+80	EDW層開發，配置相應調度	?	雙方項目工程師
數據管控平臺	運維監控	T+21-T+80	實現ETL的監控，調度及運維報告	ETL調度說明書	雙方項目工程師
	數據質量模塊開發	T+71-T+80	實現數據核對，提升數據質量	?	雙方項目工程師
業務展現平臺	指標庫開發	T+81-T+100	指標庫開發	?	雙方項目工程師
	領導駕駛艙開發	T+90-T+130	駕駛艙開發	?	雙方項目工程師
應用系統整合	需求開發及應用服務提供	T+10－T+130	應用系統整合和數據服務開發	?	雙方項目工程師
項目實施	系統測試	T+21-T+140	1.系統數據準確性核對 2.性能測試 3.壓力測試	系統測試報告	雙方項目工程師
	項目上線試運行	T+140-T+160	1.系統上線試運行 2.解決在試運行過程中發現的問題	系統運維說明書	雙方項目組成員
	項目正式上線	T+160- T+165	1.系統上線 2.項目驗收	?	雙方項目組成員

?

項目溝通計劃

項目開發實施期間，由項目經理負責整個項目的管理與協調，由項目經理協調安排人員與客戶方進行項目相關的溝通，協調項目組成員進行問題的解決，并負責對溝通問題的追蹤，確保最短時間內解決問題。

項目資源計劃

項目組織結構

?

項目組成員

本項目項目組成員情況如下：

數據交換層設計

設計數據采集平臺

ETL設計調度模型

ETL整體框架設置

設計數據服務平臺

數據推送設計

實時數據推送設計

WebService接口設計

設計數據展現平臺

領導者駕駛艙功能展現設計

設計運行監控平臺

ETL運行監控及運行報告

ETL調度

駕駛艙運行監控及運行報告

數據質量檢查

數據標準化工作

字段命名、字段類型

統一數據字典

統一代碼規范

系統開發與實施

1.???? 數據基礎平臺開發

a) ETL架構及ETL基礎流程

b) ETL運行機制及調度機制

c) 實時數據抽取機制

d) 具體數據源數據抽取

e) 數據轉換元數據維護

f) 相應的單元測試

2. 數據服務平臺

a) 數據主動服務平臺

b) WebService平臺開發

c) 數據脫敏設計

3. 數據管控平臺

a) ETL運行監控及運行報告

b) ETL調度

c) 領導者駕駛艙運行監控及運行報告

d) 數據質量檢查

4. 應用開發

a) 需求調研確認的報表開發

b) 領導者駕駛艙開發流程及權限控制體系

c) 領導者駕駛艙開發

系統測試與運行

系統測試內容

按照調研階段確認的信用評級系統需求說明書中的需求依次進行測試。

系統測試方案

在系統上線后，項目組按招標文件及投標方說明中按模塊化具體就各項系統功能和性能的要求提交《系統測試報告》，報告經過確認后，雙方項目組根據測試報告的測試內容進行全面的性能和功能測試。

?

系統驗收

本項目進行驗收條件是系統實施完成.如果達到驗收標準，應填寫xx公司正式書面驗收報告，以確認xx公司的提交物達到要求。如不能達到驗收標準，則應建立業務流程來修改提交物。

系統驗收內容

以合同附件對驗收的要求為準。

系統驗收文檔

由xx公司提交以下文檔：《系統驗收報告》。

系統驗收流程

?提交物的驗收準備好后,通知風控項目組進行驗收.如果提交物符合要求,則對項目驗收報告簽字;如果提交物不符合要求,雙方協商如何修改,直到驗收通過。

培訓計劃

培訓目的

本次項目培訓的目的：通過一系列有計劃、有步驟的用戶培訓，要使涉及xx的管理領導、業務人員、技術人員，能理解和掌握xx數據中心系統的操作和使用。

培訓對象

實施培訓的對象可分為兩個層面：

●xx相關信息技術人員：對信息技術中心運維人員進行運維培訓，包括系統常見的問題及解決方法、系統的安裝方法、系統監控軟件的使用等。對信息技術中心研發人員進行技術架構、開發平臺的培訓，并參與部分功能的開發，從而熟悉系統技術架構和開發環境，便于以后需求的二次開發。

●xx相關業務人員：為了讓業務人員能夠了解系統，并能熟練操作用戶使用界面，對業務部門的培訓工作必須放在系統正式上線之前，可以邊進行用戶測試邊培訓，這樣可讓用戶在接受完系統的操作培訓后，能立即使用對應的子系統輔助自己的工作。

培訓方式

用戶培訓主要分為三種：

● 集中培訓：

把培訓的對象集中起來，進行有計劃的系統使用培訓。

● 用戶要求：

根據用戶對培訓的具體要求和目的，派專人作用戶培訓。地點、形式和方法可由用戶自行決定。

● 專項培訓：

安排公司開發經理對用戶系統維護技術人員進行專項培訓。

培訓內容

?培訓類型	培訓課程名稱	參加對象	主要內容
技術培訓	數據倉庫工具培訓(ETL、BI工具)	ETL開發人員、報表開發人員、系統管理員 2． 開發商項目經理/成員	1.相關工具的安裝 2.相關工具使用的培訓 3.開發規范培訓
技術培訓	數據庫優化	1.系統管理員、數據庫管理人員、數據建模人員	1.系統業務、物理模型培訓 2.數據庫架構、優化；相關系統表介紹 3.典型優化場景培訓
技術培訓	系統日常管理運行	1.系統管理員	系統日常管理流程 系統異常預警及處理流程
業務培訓	相關應用子系統使用培訓	1.相關業務部門人員	1．相應應用子系統使用培訓

項目質量控制計劃

在整個系統設計和開發、實施過程中，對于每個環節都需要填寫

工作計劃、需求說明、設計文檔、測試計劃、測試文檔，使每一項工作都處于受控狀態。確立項目實施過程中產物、最終產物的質量標注和質量控制活動中各個要素。

文檔及質量標準

所提交的文檔需按本項目相應的文檔模板編寫,也可進行合理的調整。所有提交的文檔必須符合文檔規范，且文字通順、條理清楚、無二義性。

質量控制活動

軟件產品質量保證

軟件產品評審/同行評審，詳見軟件工作產品評審清單。

軟件測試：包括單元測試（由軟件工程師負責）、集成測試、系統測試和驗收測試（由測試組負責）。

軟件過程質量保證

由專職SQA工程師負責實施SQA審計，從獨立、客觀的角度將項目工程活動過程的實況反映給項目管理組，讓項目管理組及時了解過程與規定之間存在的偏差。SQA審計活動通常分為如下三類：

SQA每周例行審計，審計內容為：本周文檔/代碼評審、個人工作周報和項目組工作周報的填寫及項目備份等的執行情況，詳見SQA周報模板。

SQA工程師參與或列席評審會議，審計內容為：本次評審的工作產品和本次評審過程。

SQA階段審計（通常在基線審計后進行），按SQA審計檢查單的內容進行逐項審計，審計內容為：上次審計到本次審計期間的軟件工作產品和軟件工程活動的過程記錄。

?

質量保證

質量審核確保項目滿足預定的質量目標。項目經理會主持正式的質量審核以確保建立的質量控制流程被執行并且結果與項目質量目標相吻合。

?

變更控制計劃

對于變更，通過如下流程進行管理和控制：

變更由雙方項目組成員提出

xx項目經理與金融公司項目經理共同確認此變更請求是否為變更。

若是變更，提交總體技術組或相關人員評估此變更，同時交變更管理員登記此變更。

根據評估結果,由xx項目經理與金融公司項目經理簽字決定是否執行此變更。

若此變更決定被執行，項目組即可按照推薦方案上的內容制訂相應的變更實施計劃，進行有關的變更操作，并詳細記錄狀態。

由技術組或相關人員評估此變更執行結果。如果達到要求，則完成變更。若未達到，則直到達到要求為止。變更的執行結果交變更管理員歸檔。

項目風險管理

項目技術風險分析

? ????風險評估旨在描述如何通過風險控制保證系統建設中的業務連續性，本項目涉及的主要風險描述如下：

數據風險

• 客戶資料、資金等信息的安全保障。

• 客戶歷史交易信息，及系統資料變更信息。

系統風險

• 系統處理能力
• 操作系統和數據庫處理能力
• 硬件平臺處理能力
• 業務整合涉及的技術細節
• 信息技術部人員應對系統架構的技術業務知識儲備

設備風險

• 服務器

• 中間件

• 業務處理機

• 通訊線路

• 網絡設備，如路由器、交換機等
• 項目業務風險分析

• 由于業務流程變化對業務造成影響

• 對新系統熟悉度和理解不夠導致的錯誤業務或錯誤業務流程
• 項目管理風險分析

• 項目管理，項目規定的執行力度，人員的配合。

• 機房管理，責任是否明確，人員的積極性、主動性等

• 管理模式發生的變化，由此產生的風險

• 工程實施規范的落實。

• 工程實施人員的誤操作。

• 工程實施過程中不可預見或未能預見的問題
• 項目技術風險應對

數據風險應對

數據轉換過程由xx八步數據轉換法嚴格控制，如下圖：

?

數據遷移核對指通過后臺腳本和前臺客戶端查詢進行數據一致性、完整性和正確性的檢查，保證遷移數據的正確。其中后臺腳本核對由數據遷移人員和機房管理員通過編寫的腳本在后臺對客戶資金、賬戶、交易流水等數據進行核對；前臺業務核對是由系統管理員、業務人員通過應用系統查詢并核對上述數據。

系統風險應對

為全面保障系統交易和數據安全，中心機房建設的同時同步建設高級別災備機房。建立完善的應急預案，并進行有組織有計劃的應急演練。

小機+ORACLE平臺實施方面，xx有專門的ORACLE實施專家11名，均為經過ORACLE官方認證的OCP，同時具備55家ORACLE版系統的建設和切換經驗。

設備風險應對

服務器、中間件、轉換機等交易關鍵節點設備在部署時均已考慮成組冗余部署，單臺設備故障均不會對業務連續性造成影響。

項目業務風險應對

相關業務部門人員全面參與項目建設、為系統業務功能和業務流程的建設提供指導。

對客戶技術和業務人員的培訓貫穿于整個項目實施進行過程中。

• 集中培訓：將主要業務和技術人員集中或通過視頻進行統一培訓。
• 安裝培訓：由xx工程實施人員在工程實施期間，系統安裝過程中或安裝完畢后，對用戶技術和業務人員的操作培訓；
• 項目組人員培訓：對所有參與工程實施及程序部署的項目組成員進行規范性培訓，確保工程實施的規范性和一致性。
• 加強客戶宣傳工作，提供優秀的系統幫助文檔，指導用戶正確操作。

另外貴方可根據需要參與由xx服務總部定期在杭州xx培訓中心舉辦的系統運維、Oracle、Hadoop等培訓。

?

項目管理風險應對

引入嚴格的項目管理，雙方成立公司級的項目小組；引入嚴格的質量控制，確保程序的穩定性和實施的規范性。項目雙方要明確責任，升級過程中各相關部門要有足夠的重視程度和合作深度。

項目小組成立后，需要通過相關約定和制度加強項目組各成員的配合程度，調動所有人員參與的積極主動性，明確每人的職責。雙方責任如下表所示。?

xx公司項目組
NO	主要職責及關注問題	備注
1)	協助項目整體規劃（配合客戶項目組）	?
2)	配合完成項目實施規范	?
3)	系統的安裝、調試、穩定運行	?
4)	提供交易接口，以供第三方廠商及時準備；	?
5)	技術和業務人員的操作培訓；	?
6)	工程文檔的移交；	?
7)	xx內部資源的協調；	?
8）	協助建立系統的運維體系和管理規范	?

?

?

交付文檔說明

所提交的文檔需按本項目相應的文檔模板編寫,也可進行合理的調整。所有提交的文檔必須符合文檔規范，且文字通順、條理清楚、無二義性。主要交付物如下：

???

編號	文檔名稱	質量標準
1	項目計劃書	本項目所需的子計劃已全部完成 各子計劃內容完整，合理，可行 計劃中定義的組織結構合理，其中的角色及責任明確 計劃中的管理流程合理，高效 時間表及任務的安排合理高效
2	需求分析說明書	用戶界面風格布局已與用戶確認 報表中的元素及布局已與用戶確認 用戶界面與報表中的元素的屬性已與用戶確認 所有的功能的設計是合理的且便于計算機的實現 界面輸入的所有的元素應被合理的處理 所有的輸出結果是符合業務邏輯的 若業務邏輯需要優化，優化后的業務邏輯是合理的高效的 整個系統是自成體系的，完整的 與其他系統的接口已定義明確 為將來業務的發展留有余地 審核中發現的問題已修正，好的建議已納入
3	系統設計說明書	數據庫的設計符合數據庫設計理論和應用開發經驗 命名規范明確，合理，易于管理 提示信息的處理規范明確、合理、易于管理維護 程序模塊設計合理高效，符合結構化設計理論 需求分析中的所有的功能都有相應的程序處理 所有的子程序都是合理的且被多次調用，相似的子程序應被合并 程序的返回信息已被統一規范 數據流程圖能清晰表達設計思路
4	集成測試計劃	集成測試計劃已完成 集成測試的方法，模塊集成的順序合理，有效，易行 集成測試的流程合理，高效，易操作 案例的編碼方法易于管理追蹤 已定義了切實可行的，合理的配置管理方法
5	集成測試案例	案例已覆蓋到所有需要集成的功能 所有的集成測試案例已按案例模板中的項目完成 案例已按相關性進行分類
6	系統測試計劃	系統測試計劃已完成 系統測試的方法合理，有效，易行 系統測試的流程合理，高效，易操作 已對整個項目組按業務和技術做了合理有效的安排 案例的編碼方法易于管理追蹤 已定義了切實可行的，合理的配置管理方法
7	系統測試案例	案例已覆蓋到本系統所有的功能 案例包含功能測試案例和按業務流程的綜合測試案例 功能測試案例能覆蓋本功能的各種業務分支 所有的打印輸出和業務報表應被覆蓋 所有的集成測試案例已按案例模板中的項目完成 案例已按相關性進行分類
8	用戶手冊	按用戶手冊模板完成 使用方法已被清晰描述

?

售后服務

xx公司承諾嚴格遵循高速度響應和二十四小時不間斷的服務體系。xx追求創新技術和實有功能的完美結合，強調客戶的成功就是我們的成功！ xx公司是行業內第一家通過ISO9001、CMMI4認證的企業，我們已經建立了一套成熟的軟件過程控制管理辦法，從軟件的設計、編碼、測試、安裝、服務等都有一套符合國際標準的流程管理體系，并通過象NOKIA、NEC等國際企業的認可。同時，xx真正把服務作為一項系統工程進行建設，建立完整的質量保證體系，使產品和服務都處于嚴格的受控狀態。

我們通過自身的嚴格控制，為貴公司制訂切實可靠的技術支持和服務保障。

軟件開發控制流程的承諾

在整個系統設計和開發、實施過程中，對于每個環節都需要填寫工作計劃、需求說明、設計文檔、測試計劃、測試文檔，使每一項工作都處于受控狀態。

xx服務質量控制體系的承諾

xx服務質量方針

為中國證券、金融、期貨等行業提供安全、實用、規范、配套、開放的軟件產品和集成工程；向每一家xx用戶提供專業、及時、長期、發展、多樣的服務。

xx服務質量目標

精心設計、細心編程、嚴格測試，xx產品無過失；

周密設計、互相配合、認真安裝，xx工程無返工；

健全體系、規范管理、耐心負責，xx服務無投訴。

xx客戶服務體系和內容的承諾

合理的服務機構設置

客戶服務中心總部設在公司總部杭州，下轄29個地區客戶分中心。能夠保證貴公司得到第一時間的現場服務。xx的服務強調高效應、快速的服務。

首席客戶服務代表制

xx公司將會指定一名資深的工程師作為貴公司的首席客戶服務代表，作為貴公司的維護專員，及時解決軟件使用中碰到的問題。首席客戶服務代表每月至少兩次與信息技術部總經理或指定的技術專員作溝通，了解xx產品的使用情況，主動介紹xx在產品、技術、服務等上的最新進展。

用戶意見的處理

貴公司對于此系統的任何需求，都可以通過項目經理或者首席客戶代表和我們進行聯系，我們會在36小時內作出合格的回復；針對回復單里所作的承諾，實行登記管理。用戶個性化需求經產品組程序修改后，由測試室嚴格測試，再發放給客戶，并收集用戶反饋。

高效流程、多層服務

對于重要的業務均確定了辦事流程，對客戶意見及處理等都制訂了工作流程，使所有的服務處于受控狀態。技術服務分兩個層次，一線工程支持和二線工程支持?？偛坎糠止こ處熀腿珖貐^客戶分中心的網絡工程師提供客戶一線技術支持，二線工程師由總部資深工程師組成。

客戶服務管理系統

我們把服務管理、資料管理、產品管理、合同管理等相關工作聯結起來，實現了公司局域網上的電子化作業，有利于建立高效的管理監督控制體系。它最大的作用是相當于設立了用戶軟件系統的“病例卡”，能方便地查閱每一用戶的產品信息和歷史問題。從而讓xx用戶享受到更好的個性化服務、繼承性服務。

7*24小時隨時待命服務

xx的服務能夠真正做到了有保障的7*24小時熱線維護：

公司配置：22條中繼線維護；27線維護分機；8條modem專線；16只專用維護手機；全公司所有人員的手機24小時開通，以備萬一。

客戶服務承諾

故障類型分類

根據我們多年的經驗，我們將用戶故障類型分為四個級別。

一級故障?? 系統癱瘓，用戶業務停機

二級故障?? 系統性能下降，嚴重影響客戶業務

三級故障?? 個別設備故障，只影響局部，不影響全局業務

四級故障?? 安裝、配置等技術難點，業務不受影響

根據對故障級別的定義，我們的一線工程師、二線工程師將在嚴格規定的時限內，對客戶進行響應和故障處理。

?

故障級別	? 電話響應	一線支持時限	二線支持時限
1	? < 0.5小時	?	?< 4小時
2	< 0.5小時	? < 4小時	?< 1天
3	< 0.5小時	? < 4小時	< 1 天
4	< 0.5小時	< 2天	?< 2天

?

xx公司承諾在本項目保修期內(本項目的免費服務期為一年）為用戶提供7X24小時的支持，響應時間不多于0.5小時。如果用戶允許，xx公司提供遠程電子支持手段（ECS），通過遠程登錄完成故障排除。同時，由于xx在各地客戶中心都駐有多名工程師，可為客戶提供及時周到的服務，xx工程師可在1小時之內趕赴現場解決問題。

新業務、新需求的響應

對金融公司在有新業務開展過程中相關風險監控內容的需求，xx提供專門客服代表負責接收金融公司的需求提交，并承諾2天內就需求的技術實現、時間期限等給出明確回復。

系統規劃

數據中心的整個建設是一個持續投入、不斷優化的過程。在整個建設過程中，應根據現實和未來的需求分步驟來建設數據中心。建議采用“統籌規劃、分步實施”的策略，分步有序推進。

搭建大數據中心，完成數據倉庫建設以及駕駛艙功能開發

推進數據對接改造，完成星形數據網絡布局和數據挖掘開發

以數據中心為載體推進數據治理工作

xx優勢

公司實力優勢

xx是目前金融行業規模最大，產品線最全的軟件公司。

專家優勢

xx公司長期致力于金融行業產品研發、政策研究，擁有一大批行業業務專家，也是證監會風控系統標準制定、現場評審等的專家小組成員單位，直接參與標準的制定和評審，對證券公司合規和風險管理有深刻的理解。

中間件優勢

系統采用xx在證券行業具有突出技術優勢的專用金融基礎件作為數據采集和監控的基礎平臺。平臺提供了完整的容錯機制和故障快速修復手段，從多個層面提高了系統的安全性、穩定性。

業務理解優勢

xx公司在大金融行業產品線全面，產品涵蓋了證券、基金和金融公司的各個業務應用領域，能獨立提供全面的整體解決方案。

數據中心優勢

xx證券公司數據中心系統支持證券公司現有各個數據源系統的接口，數據采集性能和穩定性高；系統支持客戶容量為1000萬，能做到TB級別數據處理，已有500萬級客戶的成功案例；完善的元數據管理、數據質量管理與完備的容錯數據處理能力；數據服務接口完美支持證券公司風控系統、營銷管理平臺等系統的數據需求；擁有成熟的數據中心模型體系，數據中心指標體系，支持各業務部門的數據查詢分析需求；擁有豐富的大數據處理經驗，有完善的大數據級數據中心建設方案；利用成熟的數據挖掘工具與數據挖掘算法，從海量數據中準確找到數據趨勢與數據價值。

主動預警

系統支持靈活多樣的預警方式，支持監控結果和待處理任務的主動推送。在出現預警信息和待處理任務時，系統可支持界面、郵件、短信等多種預警方式，大大提升了監控效率。

全面風險對接優勢

xx全面風險以及內控系統市占率非常高，數據中心有多年和風控相關系統的對接經驗，對于風險數據集市和風險管理領導者駕駛艙的開發有成熟方案。

強大的二次開發支持

客戶的IT技術人員可以自行增加表和存儲過程，并對系統參數表進行相應的配置，來達到增加新的業務功能。

成功案例

總結

以上是生活随笔為你收集整理的XX数据中心技术方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。