系統(tǒng)建設目標

建設背景

監(jiān)管背景

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

?

業(yè)務背景

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

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

技術(shù)背景

面對證券業(yè)協(xié)會對數(shù)據(jù)治理的監(jiān)管要求和機構(gòu)自身對加強風險控制、提升運營能力及關鍵業(yè)務的能力的需要。證券公司在數(shù)據(jù)治理工作上也面臨著挑戰(zhàn)：內(nèi)外部數(shù)據(jù)呈爆炸式增長、新產(chǎn)品的出現(xiàn)、競爭環(huán)境和流程日益復雜、上級監(jiān)管越來越細致。

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

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

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

系統(tǒng)現(xiàn)狀

數(shù)據(jù)存儲未整合，不利于充分利用

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

數(shù)據(jù)標準不統(tǒng)一，不利于價值發(fā)現(xiàn)

證券公司現(xiàn)有系統(tǒng)之間數(shù)據(jù)的結(jié)構(gòu)和標準都不統(tǒng)一，如果借助傳統(tǒng)的方法進行數(shù)據(jù)分析，不但繁瑣復雜，而且無法滿足對業(yè)務變化的快速反應，更不能站在整個企業(yè)的角度了解企業(yè)整體情況并發(fā)現(xiàn)數(shù)據(jù)之間的聯(lián)系做出進一步的分析和預測。

數(shù)據(jù)交換不統(tǒng)一，不利于質(zhì)量控制

目前各個系統(tǒng)之間的數(shù)據(jù)交換都采用各自的采集程序，沒用統(tǒng)一的監(jiān)控、跟蹤和核對機制，很難保證數(shù)據(jù)的完整性，也不利于問題的發(fā)現(xiàn)和定位。

服務交換不統(tǒng)一，不利于服務共享

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

外部數(shù)據(jù)未接入，不利于全面分析

證券金融市場有很多的外部數(shù)據(jù)，比如征信數(shù)據(jù)、互聯(lián)網(wǎng)輿情數(shù)據(jù)、競爭公司數(shù)據(jù)等，這些數(shù)據(jù)現(xiàn)在都沒有接入到證券公司的IT系統(tǒng)中，造成很多數(shù)據(jù)分析工作不夠全面，不利于業(yè)務的全面展開。

系統(tǒng)目標

系統(tǒng)定位

搭建數(shù)據(jù)倉庫，作為數(shù)據(jù)治理工作的基礎和載體

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

整合各個應用系統(tǒng)數(shù)據(jù)，提供標準的數(shù)據(jù)接口

完成源系統(tǒng)調(diào)研，整合各個應用系統(tǒng)數(shù)據(jù)，提供標準的數(shù)據(jù)接口，形成公司唯一的、標準化的數(shù)據(jù)源，提供標準和靈活的數(shù)據(jù)交換接口，支撐各個業(yè)務系統(tǒng)的數(shù)據(jù)訪問，實現(xiàn)數(shù)據(jù)資源的共享。

優(yōu)化數(shù)據(jù)交換和IT應用系統(tǒng)架構(gòu)

建立公司的數(shù)據(jù)基礎平臺，完成公司要求的數(shù)據(jù)輸入輸出，將網(wǎng)狀的數(shù)據(jù)關系優(yōu)化為星狀。實現(xiàn)ETL過程和數(shù)據(jù)質(zhì)量的自動化管理，對ETL過程和數(shù)據(jù)質(zhì)量進行全面的監(jiān)控和管理維護。

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

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

完成前臺應用建設，為證券公司各業(yè)務部門提供數(shù)據(jù)支持

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

系統(tǒng)總體目標

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

建立符合證券公司實際需求的數(shù)據(jù)中心技術(shù)架構(gòu)。

提供符合監(jiān)管要求和證券公司業(yè)務需求的數(shù)據(jù)治理體系架構(gòu)。

建立符合證券公司實際需求的企業(yè)級數(shù)據(jù)模型。

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

完成數(shù)據(jù)標準化工作，形成公司唯一的、標準化數(shù)據(jù)源，支撐各項業(yè)務管理系統(tǒng)的數(shù)據(jù)訪問。

支撐公司各項業(yè)務數(shù)據(jù)的統(tǒng)一采集、統(tǒng)一存儲、統(tǒng)一訪問管理等功能。

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

實現(xiàn)ETL全流程調(diào)度自動化管理，對ETL 過程進行全面監(jiān)控和管理維護。

實現(xiàn)ETL過程中的數(shù)據(jù)質(zhì)量管理工作，靈活通過校驗方式和校驗規(guī)則的搭配，保證數(shù)據(jù)中心數(shù)據(jù)質(zhì)量。

建立全面和標準的數(shù)據(jù)中心指標體系，統(tǒng)一管理證券公司各類業(yè)務口徑，全面的反映證券公司各項業(yè)務的原子指標。

提供標準和靈活的數(shù)據(jù)接口，保證現(xiàn)有系統(tǒng)的數(shù)據(jù)源平滑過渡到數(shù)據(jù)中心，支持公司擬建和未來需建的各類系統(tǒng)。

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

通過對基礎數(shù)據(jù)模型的分析，形成數(shù)據(jù)集市，并展現(xiàn)公司級別的經(jīng)營狀況。

建設原則

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

自主創(chuàng)新的原則

在項目的規(guī)劃和設計過程中，將從xx的業(yè)務系統(tǒng)現(xiàn)狀和業(yè)務發(fā)展出發(fā)，同時考慮到證券公司后續(xù)業(yè)務發(fā)展的需要。在具體建設過程中，不完全使用已有第三方軟件供應商提供的數(shù)據(jù)中心產(chǎn)品。整個系統(tǒng)的設計和搭建將自主創(chuàng)新，完成整個系統(tǒng)的搭建。

合作開發(fā)的原則

數(shù)據(jù)中心項目是一個開發(fā)項目，不是一個通過產(chǎn)品安裝就能夠完成的。xx信息技術(shù)部將全程參與系統(tǒng)的設計和開發(fā)工作。

逐步推進的原則

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

項目管理的自控原則

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

標準性原則

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

術(shù)語定義

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

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

系統(tǒng)技術(shù)設計

系統(tǒng)技術(shù)架構(gòu)

系統(tǒng)總體框架

系統(tǒng)邏輯架構(gòu)

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

源業(yè)務系統(tǒng)：數(shù)據(jù)中心數(shù)據(jù)的來源，證券公司內(nèi)部各類生產(chǎn)系統(tǒng)或者互聯(lián)網(wǎng)數(shù)據(jù)。數(shù)據(jù)中心對接各個源業(yè)務系統(tǒng)進行ETL工作，將證券公司內(nèi)部的數(shù)據(jù)以及互聯(lián)網(wǎng)上獲取到的外部數(shù)據(jù)集中到數(shù)據(jù)中心，進行數(shù)據(jù)標準化和數(shù)據(jù)建模工作。

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

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

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

數(shù)據(jù)管控平臺：負責數(shù)據(jù)中心任務調(diào)度、數(shù)據(jù)質(zhì)量管理、元數(shù)據(jù)管理、數(shù)據(jù)接口管理、數(shù)據(jù)權(quán)限管理以及運維監(jiān)控功能的管理平臺。負擔整個數(shù)據(jù)中心體系中數(shù)據(jù)的管理、控制、校驗、監(jiān)控、分發(fā)工作，通常情況下會將業(yè)務展現(xiàn)平臺集成到數(shù)據(jù)管控平臺中，進行統(tǒng)一集成化管理。

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

系統(tǒng)技術(shù)架構(gòu)

??? xx數(shù)據(jù)中心項目的數(shù)據(jù)存儲和計算服務已經(jīng)采用cdh版的Hadoop大數(shù)據(jù)平臺。因此數(shù)據(jù)中心技術(shù)架構(gòu)基于Hadoop大數(shù)據(jù)平臺進行設計。

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

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

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

優(yōu)點：充分考慮到數(shù)據(jù)對接類型的全覆蓋，以避免數(shù)據(jù)分析軟件或者下游系統(tǒng)無法對接Hadoop數(shù)據(jù)接口的風險。

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

系統(tǒng)性能

根據(jù)目前現(xiàn)狀，在充分考慮公司未來 3-5 年的業(yè)務發(fā)展需要，總體達到性能指標如下：

系統(tǒng)性能指標列表

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

容錯機制

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

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

?

數(shù)據(jù)采集工具在處理的每一個環(huán)節(jié)都有完善的出錯處理，可以根據(jù)客戶的需求，設定出錯的的處理原則，例如放入臨時表，導出出錯文件，或者是發(fā)EMAIL或者是短信網(wǎng)關通知相關的人員。

安全性設計

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

網(wǎng)絡安全性

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

數(shù)據(jù)安全性

數(shù)據(jù)存放

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

數(shù)據(jù)訪問

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

操作安全性

錯誤提示

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

操作人性化

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

配置管理

系統(tǒng)有詳細的配置清單。

容錯機制

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

WEB安全性

證書安全

系統(tǒng)WEB中間件支持加載證書，支持HTTPS協(xié)議。

用戶口令保護

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

權(quán)限控制

業(yè)務展現(xiàn)平臺、數(shù)據(jù)管控平臺的權(quán)限控制基于角色與組織架構(gòu)來控制。結(jié)合BI系統(tǒng)可以將權(quán)限控制對應的字段。相關授權(quán)與重要功能的讀寫留痕，并有專門功能提供查詢。

可靠性設計

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

數(shù)據(jù)基礎平臺

?

?

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

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

下圖為通過ETL建立數(shù)據(jù)倉庫的整體過程：

ETL主要完成以下內(nèi)容：

從各類同構(gòu)或異構(gòu)生產(chǎn)庫系統(tǒng)抽取、轉(zhuǎn)換、加載數(shù)據(jù)到大數(shù)據(jù)平臺的ODS數(shù)據(jù)層。

根據(jù)xx需求按照一定主題建立的數(shù)據(jù)模型，抽取、轉(zhuǎn)換、加載ODS數(shù)據(jù)到大數(shù)據(jù)平臺的企業(yè)級數(shù)據(jù)倉庫層即EDW層。

根據(jù)數(shù)據(jù)中心模型設計規(guī)范與xx的數(shù)據(jù)需求建立完整的數(shù)據(jù)中心指標體系。

根據(jù)xx業(yè)務條線或者部門級的需求按照數(shù)據(jù)中心既定的數(shù)據(jù)標準和規(guī)范加載轉(zhuǎn)換EDW數(shù)據(jù)和指標庫數(shù)據(jù)到各類數(shù)據(jù)集市。

數(shù)據(jù)源

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

從系統(tǒng)類別的角度看，數(shù)據(jù)中心數(shù)據(jù)源采集對接經(jīng)驗如下：

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

從xx現(xiàn)有應用系統(tǒng)的角度看，數(shù)據(jù)中心數(shù)據(jù)源采集對接經(jīng)驗如下：

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

?

數(shù)據(jù)組織結(jié)構(gòu)

數(shù)據(jù)組織目標

數(shù)據(jù)組織是由業(yè)務系統(tǒng)數(shù)據(jù)分析和數(shù)據(jù)中心需求分析相結(jié)合后，產(chǎn)生的為之后的數(shù)據(jù)層次提供分類的綜合依據(jù)，具體表現(xiàn)為為ODS層次提供分類的參考和為EDW層的主題提供主題雛形。同時數(shù)據(jù)組織也是數(shù)據(jù)中心設計大部分表結(jié)構(gòu)所需要遵循的原則。

數(shù)據(jù)組織結(jié)構(gòu)

?

原始層數(shù)據(jù)是基本和數(shù)據(jù)源業(yè)務系統(tǒng)表結(jié)構(gòu)保持一致的信息數(shù)據(jù);ODS層數(shù)據(jù)主要將原始層進行清洗轉(zhuǎn)換之后符合數(shù)據(jù)中心標準和規(guī)范的共性標準化數(shù)據(jù)；EDW層主要保存進行主題建模之后持久化存儲的數(shù)據(jù)中心數(shù)據(jù)。

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

ODS數(shù)據(jù)庫

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

ODS數(shù)據(jù)庫設計原則：

標準化原則

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

統(tǒng)一客戶模型

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

統(tǒng)一數(shù)據(jù)字典

在標準化原則下，對外提供統(tǒng)一的數(shù)據(jù)字典。并能自動發(fā)現(xiàn)新增屬性值的現(xiàn)象，并通過預警的方式通知運維人員進行確認。

統(tǒng)一數(shù)據(jù)格式

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

EDW數(shù)據(jù)庫

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

EDW層數(shù)據(jù)支撐智能分析平臺、ACRM系統(tǒng)、數(shù)據(jù)統(tǒng)計以及固定報表數(shù)據(jù)需求。各個業(yè)務條線和部門的數(shù)據(jù)需求通過在EDW層建立數(shù)據(jù)集市來實現(xiàn)。

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

數(shù)據(jù)組織原則

時間與效率原則

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

通用性原則

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

粒度最小化原則

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

如果相關屬性需多個系統(tǒng)共用，由基礎數(shù)據(jù)加工而成，如日均資產(chǎn)、周轉(zhuǎn)率等。

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

標準化原則

對不同系統(tǒng)同含義的數(shù)據(jù)進行標準化，數(shù)據(jù)格式保持對不同交易系統(tǒng)的兼容，對外提供的必須是一致的字段名稱和字段值。比如客戶號、機構(gòu)代碼、產(chǎn)品類別等。

開放性原則

允許符合技術(shù)標準的數(shù)據(jù)及系統(tǒng)在此平臺上交換數(shù)據(jù)。

容錯性原則

在數(shù)據(jù)抽取清洗的每一個環(huán)節(jié)出現(xiàn)錯誤時都應有相應的出錯處理、恢復流程，出現(xiàn)錯誤能夠通過郵件、短信的方式通知維護人員。

準確性與完整性原則

數(shù)據(jù)中心為各個管理系統(tǒng)提供數(shù)據(jù)服務，其數(shù)據(jù)的準確性非常重要，須能夠提供業(yè)務系統(tǒng)層、原始層、ODS層的數(shù)據(jù)核對，并能夠在核對出現(xiàn)問題時自動提醒維護人員。

數(shù)據(jù)模型設計

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

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

(1)利用科學的面向?qū)ο蠓治龅姆椒?#xff0c;分析業(yè)務中的Who， What， When， Why， Where， How；這樣就產(chǎn)生了數(shù)據(jù)建模領域的基本主題框架，并且按照證券的特點轉(zhuǎn)化為當事人、產(chǎn)品、渠道等數(shù)據(jù)主題域。

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

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

FS-LDM	SDOM	xx數(shù)據(jù)中心
當事人	主體	當事人
產(chǎn)品	品種	產(chǎn)品
協(xié)議	賬戶	協(xié)議
事件	事件	事件
資產(chǎn)	資產(chǎn)	資產(chǎn)
財務	合同	財務
機構(gòu)		內(nèi)部機構(gòu)
地域		地域
營銷	營銷	營銷
渠道	渠道	渠道
	資訊	資訊
		公共

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

模型設計概述

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

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

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

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

?

通過本系統(tǒng)建設工作，形成證券自有知識產(chǎn)權(quán)的企業(yè)級數(shù)據(jù)倉庫邏輯數(shù)據(jù)模型，從而為搭建證券公司企業(yè)級數(shù)據(jù)倉庫奠定重要基礎。

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

當事人模型

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

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

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

唯一標識

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

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

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

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

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

主要內(nèi)容

當事人分類

結(jié)合證券業(yè)務系統(tǒng)現(xiàn)狀和數(shù)據(jù)基礎，當事人種類分為對機構(gòu)當事人、個人當事人、經(jīng)紀人當事人，代理人當事人，柜員當事人等

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

• 當事人名稱：當事人當前對應的名稱。
• 當事人所在內(nèi)部機構(gòu)。
• 當事人編號:統(tǒng)一生成唯一編碼
• 當事人證件號和當事人證件的有效日期等。
• 當事人證件有效開始日期
• 當事人證件有效結(jié)束日期
• 當事人類型代碼，包括個人和機構(gòu)。
• 當事人種類代碼，包括客戶，經(jīng)紀人，柜員，代理人等。

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

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

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

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

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

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

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

當事人狀態(tài)代碼：主要指當事人狀態(tài)，包括掛失等。

當事人風險

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

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

重要關系

?

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

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

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

產(chǎn)品當事人關系歷史：描述產(chǎn)品與當事人的關系，如開發(fā)、經(jīng)銷、購買等。

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

內(nèi)部機構(gòu)模型

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

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

唯一標識

內(nèi)部機構(gòu)的唯一標識以核心業(yè)務系統(tǒng)機構(gòu)管理中的機構(gòu)編碼為基礎，結(jié)合財務管理系統(tǒng)和其他業(yè)務系統(tǒng)的機構(gòu)編碼進行整合。

內(nèi)部機構(gòu)概況

?

內(nèi)部機構(gòu)：記錄各業(yè)務系統(tǒng)中所有的內(nèi)部機構(gòu)信息。

內(nèi)部機構(gòu)名稱歷史：記錄內(nèi)部機構(gòu)的名稱變化歷史。

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

?

重要關系

?

內(nèi)部機構(gòu)協(xié)議關系歷史：記錄協(xié)議與機構(gòu)的關系歷史，如協(xié)議的歸屬機構(gòu)。

內(nèi)部機構(gòu)地址歷史：記錄內(nèi)部機構(gòu)在各業(yè)務系統(tǒng)的地址信息。

內(nèi)部機構(gòu)產(chǎn)品關系歷史：記錄機構(gòu)與產(chǎn)品的關系。

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

地域模型

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

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

主要內(nèi)容

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

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

電子地址：包括當事人的eMail、網(wǎng)址、IP 地址等。

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

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

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

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

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

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

重要關系

?

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

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

產(chǎn)品模型

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

唯一標識

產(chǎn)品的唯一標識就是產(chǎn)品編號，由于XX證券源業(yè)務系統(tǒng)沒有明確的產(chǎn)品定義，所以唯一標識號會結(jié)合各個產(chǎn)品的特點來生成唯一號。

產(chǎn)品分類

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

根據(jù)產(chǎn)品類型代碼，產(chǎn)品劃分為：

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

非金融產(chǎn)品：以證券公司為服務的產(chǎn)品。

重要關系

?

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

協(xié)議模型

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

主要內(nèi)容

?

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

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

重要關系

?

事件模型

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

唯一標識

唯一標識一筆事件的字段是“事件編碼”，編碼規(guī)則是由“源業(yè)務系統(tǒng)編號＋各系統(tǒng)原唯一編號”組成，如核心交易系統(tǒng)事件編號為“0100 ＋交易日期＋地區(qū)代號＋機構(gòu)代號＋日志序號”。

主要內(nèi)容

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

?

?

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

外圍事件

?

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

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

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

重要關系

?

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

事件內(nèi)部機構(gòu)關系：一個事件會涉及很多內(nèi)部機構(gòu)的信息，比如事件的發(fā)生機構(gòu)、事件的操作柜員、事件的授權(quán)柜員等。

事件產(chǎn)品關系：記錄事件與產(chǎn)品之間的某種關系。

?

資產(chǎn)模型

唯一標識

資產(chǎn)主題不產(chǎn)生統(tǒng)一主題編號。

資產(chǎn)主題中增加其他主題編號，如當事人編號、內(nèi)部組織編號、協(xié)議編號等。

主要內(nèi)容

證券交易資產(chǎn)：包括客戶資金余額/證券余額。

?

?

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

?

?

開基資產(chǎn)：包括客戶開基持倉份額。

?

?

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

資產(chǎn)管理相關資產(chǎn)：投資業(yè)務資金賬戶余額、投資業(yè)務證券賬戶證券余額、理財產(chǎn)品客戶持倉份額。

?

清算系統(tǒng)相關信息：按照清算系統(tǒng)中科目及發(fā)生額、余額的方式存儲公司清算相關資產(chǎn)。

?

重要關系

證券交易：

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

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

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

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

融資融券：

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

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

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

資產(chǎn)管理：

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

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

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

清算系統(tǒng)：

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

其他資產(chǎn)：

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

財務模型

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

唯一標識

財務主題不產(chǎn)生統(tǒng)一主題編號。

財務主題中增加其他主題編號，如內(nèi)部組織編號等。

主要內(nèi)容

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

?

?

帳套信息：包括帳套表、合并帳套關系表、系統(tǒng)結(jié)賬表。

?

?

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

?

重要關系

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

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

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

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

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

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

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

營銷模型

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

唯一標識

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

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

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

主要內(nèi)容

?

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

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

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

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

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

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

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

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

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

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

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

?

重要關系

?

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

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

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

營銷內(nèi)部機構(gòu)關系：描述營銷涉及的內(nèi)部機構(gòu)，如發(fā)起機構(gòu)、管理機構(gòu)、目標機構(gòu)、執(zhí)行機構(gòu)等。

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

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

渠道模型

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

唯一標識

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

主要內(nèi)容

?

?

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

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

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

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

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

重要關系

?

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

內(nèi)部機構(gòu)渠道關系歷史：記錄渠道和內(nèi)部機構(gòu)的關系歷史，如渠道的歸屬機構(gòu)等。

產(chǎn)品渠道類型關系：記錄某些產(chǎn)品和某個種類渠道的關系。

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

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

數(shù)據(jù)集市

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

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

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

數(shù)據(jù)服務平臺

數(shù)據(jù)服務平臺目標

梳理復雜公司的數(shù)據(jù)流向網(wǎng)，將數(shù)據(jù)中心建設成公司企業(yè)級數(shù)據(jù)平臺，所有需要數(shù)據(jù)的管理系統(tǒng)向數(shù)據(jù)中心索取數(shù)據(jù)，數(shù)據(jù)中心負責整合管理系統(tǒng)需要的數(shù)據(jù)并提供數(shù)據(jù)接口服務，業(yè)務系統(tǒng)出現(xiàn)升級導致表結(jié)構(gòu)變更，或者出現(xiàn)大的變更時，保證數(shù)據(jù)中心對管理系統(tǒng)的表結(jié)構(gòu)不變，減少對管理系統(tǒng)的影響。

?

數(shù)據(jù)服務模式

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

管理系統(tǒng)	變動類型	備注
已上線管理系統(tǒng)	交易系統(tǒng)采集切換到數(shù)據(jù)中心采集	減少管理系統(tǒng)架構(gòu)不變和保持數(shù)據(jù)穩(wěn)定
數(shù)據(jù)中心后上線系統(tǒng)	從ODS、EDW獲取數(shù)據(jù)	后續(xù)生產(chǎn)系統(tǒng)變動對管理系統(tǒng)影響小
查詢統(tǒng)計	訪問數(shù)據(jù)中心的數(shù)據(jù)	獲取穩(wěn)定、一致數(shù)據(jù)

數(shù)據(jù)服務方式

實現(xiàn)方式主要有以下三種：

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

Web Service接入

?

Web Service是一種標準的服務調(diào)用接口，因此只要符合標準的外圍業(yè)務系統(tǒng)都可以進行接入，在這種方式下，數(shù)據(jù)訪問服務通過J2EE服務器加載數(shù)據(jù)服務應用程序來實現(xiàn)，服務的跨網(wǎng)段調(diào)用通過在網(wǎng)段之間部署Web服務器來實現(xiàn)。

服務調(diào)用所提供的服務、用戶、權(quán)限，由管理程序進行統(tǒng)一的管理。

設計要點

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

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

權(quán)限管理 針對不用的訪問用戶，提供不同的服務調(diào)用權(quán)限，用戶不能越權(quán)訪問數(shù)據(jù)。

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

主動推送

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

授權(quán)用戶直接訪問

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

數(shù)據(jù)接口服務安全性

Web Service數(shù)據(jù)訪問安全

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

用戶角色訪問安全

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

數(shù)據(jù)庫級別安全

下游系統(tǒng)對接CDH數(shù)據(jù)平臺

若下游系統(tǒng)直接對接CDH數(shù)據(jù)平臺，則引用CDH數(shù)據(jù)安全訪問機制。

下游對接Oracle數(shù)據(jù)庫

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

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

智能分析平臺

平臺結(jié)構(gòu)

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

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

平臺功能類型

報表：

?

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

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

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

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

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

BI分析：

?

?提供多方位信息視圖；

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

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

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

領導駕駛艙

為企業(yè)高層提供的“一站式”決策支持的管理信息中心系統(tǒng)；

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

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

數(shù)據(jù)挖掘

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

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

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

BI工具選擇

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

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

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

FINEREPORT

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

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

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

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

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

數(shù)據(jù)管控平臺

數(shù)據(jù)管控平臺銜接了數(shù)據(jù)基礎平臺、智能分析平臺、業(yè)務展現(xiàn)平臺內(nèi)部和相互之間的關系。提供了ETL調(diào)度與監(jiān)控、數(shù)據(jù)質(zhì)量管理、業(yè)務分析數(shù)據(jù)可視化等功能。

ETL調(diào)度與監(jiān)控

ETL調(diào)度管理目標為取代ETL工具內(nèi)部JOB調(diào)度工具，數(shù)據(jù)管控平臺的ETL調(diào)度管理可適用于任意ETL工具JOB的調(diào)度工作。

數(shù)據(jù)抽取

??? ETL調(diào)度支持的數(shù)據(jù)抽取模式如下：

靜態(tài)數(shù)據(jù)的獲取

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

通過交易日志獲取

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

通過數(shù)據(jù)庫觸發(fā)器獲取

同樣，這個選擇可以應用于全都是數(shù)據(jù)庫應用的源系統(tǒng)中。觸發(fā)器是存儲在數(shù)據(jù)庫中的特殊過程（程序），在特定的預定義事件發(fā)生的時候被觸發(fā)。可以為所有需要的事件創(chuàng)建觸發(fā)器程序。觸發(fā)器程序的輸出被寫入一個單獨的文件，可以用來為數(shù)據(jù)倉庫抽取數(shù)據(jù)。

在源應用系統(tǒng)中獲取

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

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

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

通過文件的比較來獲取

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

各種方式優(yōu)劣勢比對：

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

?

任務分組

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

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

任務調(diào)度

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

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

事件觸發(fā)器：用某個事件來觸發(fā)任務的執(zhí)行，如上游系統(tǒng)初始化完成、前置任務執(zhí)行完成等

組合觸發(fā)器：時間觸發(fā)器和事件觸發(fā)器有效結(jié)合來設置觸發(fā)

手動觸發(fā)：在需要時或者出現(xiàn)異常時，可以手工進行干預

調(diào)度監(jiān)控

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

在調(diào)度出現(xiàn)異常時，支持手動發(fā)起失敗的任務?？梢詮氖」?jié)點發(fā)起，也可從頭發(fā)起。

監(jiān)控方式

數(shù)據(jù)中心建設中，對系統(tǒng)的運行監(jiān)控要實現(xiàn)監(jiān)控的多樣化，其中除了包括主動狀態(tài)查詢，也包括被動的監(jiān)控狀態(tài)接收。

統(tǒng)一監(jiān)控：提供統(tǒng)一監(jiān)控場所，集成現(xiàn)有的所有監(jiān)控信息

可手工觸發(fā)監(jiān)控：對監(jiān)控出現(xiàn)的結(jié)果，如果存在異常，那么在查明異常原因的情況下，能夠手工對監(jiān)控結(jié)果進行處理，例如重新出發(fā)監(jiān)控內(nèi)容，反饋回新的狀態(tài)。

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

數(shù)據(jù)質(zhì)量管理：數(shù)據(jù)質(zhì)量檢測規(guī)則、數(shù)據(jù)質(zhì)量檢測、數(shù)據(jù)質(zhì)量檢測報告。

監(jiān)控點

實時采集是否成功；

日終采集是否成功；

歷史采集是否成功；

層與層之間的清洗監(jiān)控；

數(shù)據(jù)的正確性及準確性監(jiān)控。

ETL工具運行狀況；

采集主機的運行狀況；

數(shù)據(jù)中心主機運行狀況。

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

警告：當功能監(jiān)控發(fā)現(xiàn)系統(tǒng)執(zhí)行出現(xiàn)異常時，通過郵件、短線發(fā)送預警信息給管理員。

監(jiān)控實現(xiàn)

狀態(tài)表

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

元數(shù)據(jù)管理

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

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

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

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

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

提交與審批管理：設定相應的審批控制流程，加強對元數(shù)據(jù)的管理，保證元數(shù)據(jù)平臺的準確性、時效性和穩(wěn)定性。對于涉及上下游應用調(diào)用的借口、文件等元數(shù)據(jù)，應將下游應用納入審批流程，確?？梢约皶r評估和應對上游元數(shù)據(jù)變更帶來的影響；對于重要的元數(shù)據(jù)對象，設置特殊的高層及審批流程，確保系統(tǒng)核心元數(shù)據(jù)的穩(wěn)定性。此外，為確保應用系統(tǒng)正常的研發(fā)等活動不受影響，要注意審批流程的時效性設計。

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

以下是幾種常見的元數(shù)據(jù)管理方法：

表結(jié)構(gòu)：表結(jié)構(gòu)屬于技術(shù)元數(shù)據(jù)范疇，表結(jié)構(gòu)管理應該和應用系統(tǒng)的開發(fā)、測試、版本制作等研發(fā)流程緊密結(jié)合起來，包括由元數(shù)據(jù)管理系統(tǒng)的表結(jié)構(gòu)信息來驅(qū)動開發(fā)環(huán)境、測試環(huán)境中數(shù)據(jù)庫表的建立。通過這種方式可以確保元數(shù)據(jù)管理系統(tǒng)表結(jié)構(gòu)信息的準確性和及時性。

文件：文件及文件傳輸信息屬于技術(shù)元數(shù)據(jù)范疇，在開發(fā)階段就應該明確并體現(xiàn)到元數(shù)據(jù)管理系統(tǒng)中。使用方在需要使用文件時，需要使用部門在元數(shù)據(jù)管理系統(tǒng)中明確使用情況。當提供方出現(xiàn)文件結(jié)構(gòu)變化、邏輯變化、數(shù)據(jù)字典變化時，需要元數(shù)據(jù)管理系統(tǒng)通知接收方保持同步變化。生產(chǎn)環(huán)境中的數(shù)據(jù)傳輸變化系統(tǒng)也會依據(jù)元數(shù)據(jù)管理系統(tǒng)的內(nèi)容進行相關調(diào)整，確保元數(shù)據(jù)管理系統(tǒng)中的文件及文件傳輸信息的準確性和及時性。

接口：接口程序?qū)儆诮Y(jié)構(gòu)性技術(shù)元數(shù)據(jù)范疇，應用接口及接口調(diào)用關系均在元數(shù)據(jù)管理系統(tǒng)統(tǒng)一登記管理。所有接口新增或者某應用在調(diào)用一個接口（或不再調(diào)用一個接口）時，都要求于應用開發(fā)階段在元數(shù)據(jù)管理系統(tǒng)中登記。接口的修改、作廢等，由元數(shù)據(jù)管理系統(tǒng)自動通知使用接口的聯(lián)系人，從而對接口的使用方進行相應的改造。

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

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

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

元數(shù)據(jù)的收集

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

元數(shù)據(jù)的管理

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

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

提供元數(shù)據(jù)版本控制機制：必須為被管理的元數(shù)據(jù)元素設立專門的版本控制規(guī)則，特別是元數(shù)據(jù)實例必須具有版本控制功能，包括定版、版本比較、版本恢復等功能。在特定的環(huán)境中，元數(shù)據(jù)管理體系結(jié)構(gòu)需要跟蹤、控制和發(fā)布不同版本的元數(shù)據(jù)。雖然最終要由系統(tǒng)管理員或者業(yè)務人員來決定需要哪個版本的元數(shù)據(jù),但元數(shù)據(jù)管理體系結(jié)構(gòu)提供相應的機制來使具體應用能夠發(fā)現(xiàn)和請求不同版本。

元數(shù)據(jù)的分析

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

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

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

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

數(shù)據(jù)質(zhì)量管理

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

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

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

數(shù)據(jù)質(zhì)量管理目標

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

總體上來說，數(shù)據(jù)倉庫對數(shù)據(jù)質(zhì)量的要求可歸納為：

(1)數(shù)據(jù)的正確性，是指數(shù)據(jù)是否正確體現(xiàn)在可證實的數(shù)據(jù)源上；

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

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

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

(5)數(shù)據(jù)有效性，是指數(shù)據(jù)是否在企業(yè)定義的可接受的范圍之內(nèi)；

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

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

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

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

數(shù)據(jù)質(zhì)量管理技術(shù)框架

?

數(shù)據(jù)質(zhì)量管理功能描述

?

數(shù)據(jù)質(zhì)量問題分析

數(shù)據(jù)質(zhì)量問題的表現(xiàn)形式及其產(chǎn)生原因可以歸結(jié)為以下幾個方面：

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

(2)系統(tǒng)因素：某些應用程序測試不充分，不斷產(chǎn)生錯誤的操作型數(shù)據(jù)，表現(xiàn)為數(shù)據(jù)遺漏、數(shù)據(jù)錯誤、矛盾值、違背業(yè)務規(guī)則、沒有意義的默認值等。

(3)數(shù)據(jù)遷移因素：業(yè)務系統(tǒng)更新后，會增加、刪減或修改部分舊的業(yè)務規(guī)則，表現(xiàn)為在將老數(shù)據(jù)遷移進新系統(tǒng)后，可能會引入缺漏、錯誤、無法關聯(lián)等遺留問題。

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

(5)接口定義因素：有時業(yè)務系統(tǒng)之間交換數(shù)據(jù)時接口Bug也可能引入問題數(shù)據(jù)。

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

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

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

業(yè)務邏輯問題，由于數(shù)據(jù)庫設計得不夠嚴格或者謹慎造成。

數(shù)據(jù)質(zhì)量管理設計

數(shù)據(jù)模型中實體語義、屬性重定義

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

數(shù)據(jù)字典映射檢查

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

?

表結(jié)構(gòu)變更監(jiān)控

數(shù)據(jù)倉庫實施過程中依賴的源數(shù)據(jù)的表結(jié)構(gòu)可能會因業(yè)務發(fā)生變更而變更，例如字段數(shù)據(jù)類型變更，增加或者減少字段，這些變更都會導致數(shù)據(jù)ETL過程處理失敗或者出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象，因此需要建立表結(jié)構(gòu)變更監(jiān)控。

數(shù)據(jù)核對

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

不規(guī)范數(shù)據(jù)處理

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

老化數(shù)據(jù)和無效數(shù)據(jù)的處理

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

數(shù)據(jù)質(zhì)量問題解決策略

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

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

?

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

預警性校驗：對系統(tǒng)中的數(shù)據(jù)進行合理性校驗、錯誤性監(jiān)測以及帶預警值的閾值校驗。

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

一致性校驗：對于在系統(tǒng)中出現(xiàn)的指標進行前后一致性校驗和平行一致性校驗。前后一致性即根據(jù)勾稽關系或者計算公式對指標計算結(jié)果進行校驗。平行一致性校驗即在系統(tǒng)中相同口徑的指標進行校驗比對。

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

校驗結(jié)果管理：系統(tǒng)中設置的校驗規(guī)則是普適性的，然而在實際業(yè)務流程中會有一些特殊業(yè)務要求。對于此類現(xiàn)象，我們在系統(tǒng)中對校驗結(jié)果進行集中統(tǒng)一管理。支持對校驗結(jié)果進行白名單、黑名單、灰名單的屬性設計，便于系統(tǒng)使用人員靈活運用校驗規(guī)則進行數(shù)據(jù)質(zhì)量管理。

校驗權(quán)限管理：支持按照產(chǎn)品模塊進行權(quán)限管理，不同風險管理模塊的管理員只能操作對應模塊的校驗規(guī)則，避免因為業(yè)務操作原因?qū)е缕渌a(chǎn)品模塊的數(shù)據(jù)質(zhì)量問題。

?

?

權(quán)限管理

權(quán)限按照操作類型可以分為操作權(quán)限、賦予權(quán)限、審核權(quán)限；按照控制內(nèi)容可以分為菜單權(quán)限、指標權(quán)限、組織機構(gòu)權(quán)限。

操作日志管理

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

?

系統(tǒng)部署

系統(tǒng)部署方案

?

方案通過防火墻隔離，總共分層三層安全級別區(qū)，其中，最外面第一層是日常辦公網(wǎng)絡等，第二層是數(shù)據(jù)中心相關系統(tǒng)，第三層是核心業(yè)務DB，其安全級別依次升高。

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

系統(tǒng)備份及應急方案

應用服務器備份

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

災備及應急處理

利用上述方案搭建災備系統(tǒng)，在發(fā)生緊急情況導致生產(chǎn)系統(tǒng)無法啟動時，可及時開啟災備系統(tǒng)，在生產(chǎn)系統(tǒng)恢復后，再將異常期間的數(shù)據(jù)從災備系統(tǒng)中進行恢復即可。

系統(tǒng)應用設計

系統(tǒng)整合

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

應用級別整合

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

所有的原有系統(tǒng)中的部分功能或者報表整體不再使用，遷移到新系統(tǒng)。新系統(tǒng)需要采集、轉(zhuǎn)換數(shù)據(jù)，然后開發(fā)相應的功能及報表。

優(yōu)點:

統(tǒng)一的權(quán)限、數(shù)據(jù)口徑、統(tǒng)一的展示頁面，可減輕原有系統(tǒng)壓力。

統(tǒng)一訪問整合

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

優(yōu)點：

統(tǒng)一訪問頁面，單一登錄，可以使用所有應用。

數(shù)據(jù)服務整合

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

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

優(yōu)點:

改善公司現(xiàn)有數(shù)據(jù)流，減少數(shù)據(jù)流圖的復雜性。

減輕被索取數(shù)據(jù)多的OLTP系統(tǒng)的壓力。

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

技術(shù)實現(xiàn)

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

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

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

證券公司指標庫

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

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

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

指標覆蓋風險：市場風險、信用風險、操作風險、流動性風險、壓力測試、風險調(diào)整后收益、業(yè)績表現(xiàn)、等各類指標。

指標覆蓋類型：包括監(jiān)管指標、效益指標、規(guī)模指標、財務指標、市場指標、客戶指標等。

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

領導者駕駛艙

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

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

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

風險管理駕駛艙概述

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

風險管理駕駛艙展示

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

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

?

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

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

硬件以及第三方軟件

系統(tǒng)硬件平臺

xx的大數(shù)據(jù)平臺已經(jīng)采用cdh版的Hadoop集群作為數(shù)據(jù)倉庫中心庫。考慮到實際業(yè)務情況以及數(shù)據(jù)對接的需求，搭建關系型數(shù)據(jù)庫作為數(shù)據(jù)服務和對接的緩沖庫，因此建議選擇以下硬件平臺。

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

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

第三方軟件

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

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

?

項目計劃與實施

項目總體計劃

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

?

項目溝通計劃

項目開發(fā)實施期間，由項目經(jīng)理負責整個項目的管理與協(xié)調(diào)，由項目經(jīng)理協(xié)調(diào)安排人員與客戶方進行項目相關的溝通，協(xié)調(diào)項目組成員進行問題的解決，并負責對溝通問題的追蹤，確保最短時間內(nèi)解決問題。

項目資源計劃

項目組織結(jié)構(gòu)

?

項目組成員

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

數(shù)據(jù)交換層設計

設計數(shù)據(jù)采集平臺

ETL設計調(diào)度模型

ETL整體框架設置

設計數(shù)據(jù)服務平臺

數(shù)據(jù)推送設計

實時數(shù)據(jù)推送設計

WebService接口設計

設計數(shù)據(jù)展現(xiàn)平臺

領導者駕駛艙功能展現(xiàn)設計

設計運行監(jiān)控平臺

ETL運行監(jiān)控及運行報告

ETL調(diào)度

駕駛艙運行監(jiān)控及運行報告

數(shù)據(jù)質(zhì)量檢查

數(shù)據(jù)標準化工作

字段命名、字段類型

統(tǒng)一數(shù)據(jù)字典

統(tǒng)一代碼規(guī)范

系統(tǒng)開發(fā)與實施

1.???? 數(shù)據(jù)基礎平臺開發(fā)

a) ETL架構(gòu)及ETL基礎流程

b) ETL運行機制及調(diào)度機制

c) 實時數(shù)據(jù)抽取機制

d) 具體數(shù)據(jù)源數(shù)據(jù)抽取

e) 數(shù)據(jù)轉(zhuǎn)換元數(shù)據(jù)維護

f) 相應的單元測試

2. 數(shù)據(jù)服務平臺

a) 數(shù)據(jù)主動服務平臺

b) WebService平臺開發(fā)

c) 數(shù)據(jù)脫敏設計

3. 數(shù)據(jù)管控平臺

a) ETL運行監(jiān)控及運行報告

b) ETL調(diào)度

c) 領導者駕駛艙運行監(jiān)控及運行報告

d) 數(shù)據(jù)質(zhì)量檢查

4. 應用開發(fā)

a) 需求調(diào)研確認的報表開發(fā)

b) 領導者駕駛艙開發(fā)流程及權(quán)限控制體系

c) 領導者駕駛艙開發(fā)

系統(tǒng)測試與運行

系統(tǒng)測試內(nèi)容

按照調(diào)研階段確認的信用評級系統(tǒng)需求說明書中的需求依次進行測試。

系統(tǒng)測試方案

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

?

系統(tǒng)驗收

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

系統(tǒng)驗收內(nèi)容

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

系統(tǒng)驗收文檔

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

系統(tǒng)驗收流程

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

培訓計劃

培訓目的

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

培訓對象

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

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

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

培訓方式

用戶培訓主要分為三種：

● 集中培訓：

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

● 用戶要求：

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

● 專項培訓：

安排公司開發(fā)經(jīng)理對用戶系統(tǒng)維護技術(shù)人員進行專項培訓。

培訓內(nèi)容

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

項目質(zhì)量控制計劃

在整個系統(tǒng)設計和開發(fā)、實施過程中，對于每個環(huán)節(jié)都需要填寫

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

文檔及質(zhì)量標準

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

質(zhì)量控制活動

軟件產(chǎn)品質(zhì)量保證

軟件產(chǎn)品評審/同行評審，詳見軟件工作產(chǎn)品評審清單。

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

軟件過程質(zhì)量保證

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

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

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

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

?

質(zhì)量保證

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

?

變更控制計劃

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

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

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

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

根據(jù)評估結(jié)果,由xx項目經(jīng)理與金融公司項目經(jīng)理簽字決定是否執(zhí)行此變更。

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

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

項目風險管理

項目技術(shù)風險分析

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

數(shù)據(jù)風險

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

• 客戶歷史交易信息，及系統(tǒng)資料變更信息。

系統(tǒng)風險

• 系統(tǒng)處理能力
• 操作系統(tǒng)和數(shù)據(jù)庫處理能力
• 硬件平臺處理能力
• 業(yè)務整合涉及的技術(shù)細節(jié)
• 信息技術(shù)部人員應對系統(tǒng)架構(gòu)的技術(shù)業(yè)務知識儲備

設備風險

• 服務器

• 中間件

• 業(yè)務處理機

• 通訊線路

• 網(wǎng)絡設備，如路由器、交換機等
• 項目業(yè)務風險分析

• 由于業(yè)務流程變化對業(yè)務造成影響

• 對新系統(tǒng)熟悉度和理解不夠?qū)е碌腻e誤業(yè)務或錯誤業(yè)務流程
• 項目管理風險分析

• 項目管理，項目規(guī)定的執(zhí)行力度，人員的配合。

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

• 管理模式發(fā)生的變化，由此產(chǎn)生的風險

• 工程實施規(guī)范的落實。

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

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

數(shù)據(jù)風險應對

數(shù)據(jù)轉(zhuǎn)換過程由xx八步數(shù)據(jù)轉(zhuǎn)換法嚴格控制，如下圖：

?

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

系統(tǒng)風險應對

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

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

設備風險應對

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

項目業(yè)務風險應對

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

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

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

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

?

項目管理風險應對

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

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

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

?

?

交付文檔說明

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

???

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

?

售后服務

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

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

軟件開發(fā)控制流程的承諾

在整個系統(tǒng)設計和開發(fā)、實施過程中，對于每個環(huán)節(jié)都需要填寫工作計劃、需求說明、設計文檔、測試計劃、測試文檔，使每一項工作都處于受控狀態(tài)。

xx服務質(zhì)量控制體系的承諾

xx服務質(zhì)量方針

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

xx服務質(zhì)量目標

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

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

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

xx客戶服務體系和內(nèi)容的承諾

合理的服務機構(gòu)設置

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

首席客戶服務代表制

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

用戶意見的處理

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

高效流程、多層服務

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

客戶服務管理系統(tǒng)

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

7*24小時隨時待命服務

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

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

客戶服務承諾

故障類型分類

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

一級故障?? 系統(tǒng)癱瘓，用戶業(yè)務停機

二級故障?? 系統(tǒng)性能下降，嚴重影響客戶業(yè)務

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

四級故障?? 安裝、配置等技術(shù)難點，業(yè)務不受影響

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

?

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

?

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

新業(yè)務、新需求的響應

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

系統(tǒng)規(guī)劃

數(shù)據(jù)中心的整個建設是一個持續(xù)投入、不斷優(yōu)化的過程。在整個建設過程中，應根據(jù)現(xiàn)實和未來的需求分步驟來建設數(shù)據(jù)中心。建議采用“統(tǒng)籌規(guī)劃、分步實施”的策略，分步有序推進。

搭建大數(shù)據(jù)中心，完成數(shù)據(jù)倉庫建設以及駕駛艙功能開發(fā)

推進數(shù)據(jù)對接改造，完成星形數(shù)據(jù)網(wǎng)絡布局和數(shù)據(jù)挖掘開發(fā)

以數(shù)據(jù)中心為載體推進數(shù)據(jù)治理工作

xx優(yōu)勢

公司實力優(yōu)勢

xx是目前金融行業(yè)規(guī)模最大，產(chǎn)品線最全的軟件公司。

專家優(yōu)勢

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

中間件優(yōu)勢

系統(tǒng)采用xx在證券行業(yè)具有突出技術(shù)優(yōu)勢的專用金融基礎件作為數(shù)據(jù)采集和監(jiān)控的基礎平臺。平臺提供了完整的容錯機制和故障快速修復手段，從多個層面提高了系統(tǒng)的安全性、穩(wěn)定性。

業(yè)務理解優(yōu)勢

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

數(shù)據(jù)中心優(yōu)勢

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

主動預警

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

全面風險對接優(yōu)勢

xx全面風險以及內(nèi)控系統(tǒng)市占率非常高，數(shù)據(jù)中心有多年和風控相關系統(tǒng)的對接經(jīng)驗，對于風險數(shù)據(jù)集市和風險管理領導者駕駛艙的開發(fā)有成熟方案。

強大的二次開發(fā)支持

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

成功案例

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。