XX数据中心技术方案

系统建设目标
1. 建设背景

监管背景

2016年12月30日颁布的《证券公司全面风险管理规范》要求当中，首次提出“证券公司应当建立健全数据治理和质量控制机制。积累真实、准确、完整的内部和外部数据，用于风险识别、计量、评估、监测和报告”。“证券公司应将数据治理纳入公司整体信息技术建设战略规划，制定数据标准，涵盖数据源管理、数据库建设、数据质量监测等环节。”

业务背景

中国金融行业发展迅速，随着互联网，软件等行业的推陈出新，全球信息化的进程也日益加快。证券公司在金融市场上发挥着日益重要的作用，也面临着市场、信用、操作、流动性各类风险的严峻挑战，证券公司应对这些风险的能力直接影响着金融市场和金融秩序的稳定性。与此同时，数据已经成为证券公司参与竞争的重要武器。

证券公司长期积累了大量的内部及外部数据，这些数据除了支持证券公司的自营、资管等各项核心业务，加快金融产品和服务创新，还越来越多的用于风险控制、决策分析、绩效考核等管理领域。如果数据错误、遗漏、缺乏统一标准、共享与整合程度不足，将导致问题数据如雪球般越滚越大，导致相关领域业务无法正常开展或者违反相关监管要求，导致决策出现偏差公司面临严重的风险。因此，建设数据中心，提高数据治理水平是提升证券公司核心竞争力的关键。通过数据中心系统的建设、数据治理过程的推进，证券公司可以提高其数据质量，形成数据资产，进而提高经营管理水平和风险管理能力。

技术背景

面对证券业协会对数据治理的监管要求和机构自身对加强风险控制、提升运营能力及关键业务的能力的需要。证券公司在数据治理工作上也面临着挑战：内外部数据呈爆炸式增长、新产品的出现、竞争环境和流程日益复杂、上级监管越来越细致。

数据治理除了构建专门的数据治理组织架构和工作流程之外，同时也需要有一个更加完善的信息技术系统规划战略。国内券商在IT系统建设过程当中，由于各种原因，虽然IT化程度相对较高，但是各种数据都存在各自的业务系统对应的IT系统当中独立存在，同时各个应用系统由不同的开发商开发实施，采用的数据库、技术路线都不一样，并不存在统一的数据标准和数据模型，孤岛化存在的数据为后续的数据分析、数据挖掘、风险管理带来了重重困难。

随着各个业务系统之间协同工作和数据交互越来越多并且越来越复杂，这样就造成了各个应用系统间数据关系形成了一张错综复杂的数据关系网，给系统的运行维护以及后续的系统建设和集成带来了不小的困难。点对点的数据交互模式也给核心系统带来了巨大的压力。

为了解决上述问题，有必要建设一个向下可以弹性兼容各个不同的数据源，向上可以为各应用系统提供数据支持的数据中心。数据中心的建立不但可以规范企业数据，减少数据冗余，减轻核心交易系统压力，增强系统的易维护性，提高系统的可扩展性，而且以数据中心为基础和载体进行数据治理工作可以达到事半功倍的效果。

系统现状
1. 数据存储未整合，不利于充分利用

证券公司在运营过程中生成了大量的数据，这些数据包括交易、清算、营销、财务、资讯、人力资源、资产管理、自营等企业数据，虽然这些数据部分已经同步到同一服务器，但数据未进行有效整合，各系统依旧孤立。企业决策人员、统计分析人员、业务人员很难根据自己的意愿，及时地、灵活而多角度地查询和分析数据，也不能充分利用、发掘现有数据，实现更大的效益。

数据标准不统一，不利于价值发现

证券公司现有系统之间数据的结构和标准都不统一，如果借助传统的方法进行数据分析，不但繁琐复杂，而且无法满足对业务变化的快速反应，更不能站在整个企业的角度了解企业整体情况并发现数据之间的联系做出进一步的分析和预测。

数据交换不统一，不利于质量控制

目前各个系统之间的数据交换都采用各自的采集程序，没用统一的监控、跟踪和核对机制，很难保证数据的完整性，也不利于问题的发现和定位。

服务交换不统一，不利于服务共享

各系统间存在功能冗余且口径不一等问题，缺少统一的服务交换平台，无法实现交易系统、呼叫中心、营销管理、投顾系统、CRM等各系统的服务充分共享。

外部数据未接入，不利于全面分析

证券金融市场有很多的外部数据，比如征信数据、互联网舆情数据、竞争公司数据等，这些数据现在都没有接入到证券公司的IT系统中，造成很多数据分析工作不够全面，不利于业务的全面展开。

1. 系统目标
  1. 系统定位
搭建数据仓库，作为数据治理工作的基础和载体

完成公司级的数据仓库搭建工作，成为公司级数据治理工作的载体。在数据仓库中进行元数据管理、数据质量管理、数据标准定义、数据口径统一管理等数据治理管控工作。

整合各个应用系统数据，提供标准的数据接口

完成源系统调研，整合各个应用系统数据，提供标准的数据接口，形成公司唯一的、标准化的数据源，提供标准和灵活的数据交换接口，支撑各个业务系统的数据访问，实现数据资源的共享。

优化数据交换和IT应用系统架构

建立公司的数据基础平台，完成公司要求的数据输入输出，将网状的数据关系优化为星状。实现ETL过程和数据质量的自动化管理，对ETL过程和数据质量进行全面的监控和管理维护。

建立适用于证券公司各类业务的完整指标体系

建立适合公司实际业务运行情况的指标体系，提供现有的指标库体系供参考，涵盖公共指标、风控指标、财务指标、集团联动指标、营业部/分公司等经营机构分类评价指标、自营/资管等各业务条线指标等。建立符合公司实际情况的企业级数据仓库技术架构和数据模型，为各类统计报表、领导者驾驶舱和数据分析挖掘提供数据支持。

完成前台应用建设，为证券公司各业务部门提供数据支持

根据证券公司各业务部门的实际业务需求完成领导者驾驶舱的开发、数据分析和数据挖掘开发、分析报表开发以及交互式报表等前台应用开发。

系统总体目标

证券公司数据中心的总体建设目标是建立基础数据模型、ETL调度平台、数据中心指标体系、数据质量管理平台、数据接口服务、领导者驾驶舱等，形成统一数据标准、确保数据采集完整、保证ETL数据质量、形成统一的数据展现。具体目标为：

建立符合证券公司实际需求的数据中心技术架构。
提供符合监管要求和证券公司业务需求的数据治理体系架构。
建立符合证券公司实际需求的企业级数据模型。
建立方便内部管理、帮助数据理解、增加分析敏捷性的公司级的覆盖技术元数据和业务元数据的元数据管控体系。
完成数据标准化工作，形成公司唯一的、标准化数据源，支撑各项业务管理系统的数据访问。
支撑公司各项业务数据的统一采集、统一存储、统一访问管理等功能。
使用专业成熟的ETL工具，进行对不同种类数据的抽取、转换、加载等各项部署、实施，并能对启动条件、依赖关系、状态及错误日志统一管理。同时ETL工具和调度平台能够支持和大数据平台进行数据交互。
实现ETL全流程调度自动化管理，对ETL 过程进行全面监控和管理维护。
实现ETL过程中的数据质量管理工作，灵活通过校验方式和校验规则的搭配，保证数据中心数据质量。
建立全面和标准的数据中心指标体系，统一管理证券公司各类业务口径，全面的反映证券公司各项业务的原子指标。
提供标准和灵活的数据接口，保证现有系统的数据源平滑过渡到数据中心，支持公司拟建和未来需建的各类系统。
按需要提供各类数据的汇总，满足数据报表和不同主题数据集市的需要。
通过对基础数据模型的分析，形成数据集市，并展现公司级别的经营状况。
1. 建设原则

本项目是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非常适合处理大体量的静态数据。

系统技术设计
1. 系统技术架构
  1. 系统总体框架

系统逻辑架构

无论承载数据中心的基础数据库是ORACLE之类的关系型数据库还是Hadoop之类的大数据平台。从数据仓库的理论出发，我们可以将数据中心以及和数据中心相关的系统从逻辑上进行划分。大致可以分为源业务系统、数据基础平台、数据服务平台、智能分析平台、数据管控平台、业务展现平台这几部分。

源业务系统：数据中心数据的来源，证券公司内部各类生产系统或者互联网数据。数据中心对接各个源业务系统进行ETL工作，将证券公司内部的数据以及互联网上获取到的外部数据集中到数据中心，进行数据标准化和数据建模工作。

数据基础平台：负责数据中心数据标准化、模型化、持久存储工作。从技术上分为数据存储和数据计算两大功能；从数据类型分为结构化和非结构化两类数据平台；从数据中心数据存储的层次分为原始层、ODS层、EDW层、数据集市层四类层级。

数据服务平台：负责数据中心所有对外数据接口的管理工作，通过数据服务平台实现数据中心和下游应用分析系统的数据对接工作。数据服务形式一般有被动采集和主动推送两种模式。

智能分析平台：负责将数据中心的数据和指标进行智能分析，快速形成各类报表和图表应用以及进行数据挖掘的工作。智能分析平台通常会内嵌商业智能分析和数据挖掘软件比如Cognos、mstr、FineBI、SPSS等。

数据管控平台：负责数据中心任务调度、数据质量管理、元数据管理、数据接口管理、数据权限管理以及运维监控功能的管理平台。负担整个数据中心体系中数据的管理、控制、校验、监控、分发工作，通常情况下会将业务展现平台集成到数据管控平台中，进行统一集成化管理。

业务展现平台：负责将数据中心的产出物包括报表、图表、驾驶舱、数据标签、数据分析和挖掘的结果进行有机集合，形成针对业务人员使用的前端展现工具，通常会集成到数据管控平台中。

系统技术架构

xx数据中心项目的数据存储和计算服务已经采用cdh版的Hadoop大数据平台。因此数据中心技术架构基于Hadoop大数据平台进行设计。

数据存储采用hdfs集群模式，这种数据存储模式具有超大文件处理能力、流式数据访问能力、横向扩展能力、廉价的服务器需求等优点。

数据计算采用Hadoop原生的mapreduce计算、SPARK引擎计算、HIVE类 SQL 查询语言相结合的模式来保证应对数据中心业务处理中的各类计算场景。

数据应用可以细分为数据中心自身的数据分析和对接下游系统的数据服务两类。在数据应用方案的设计上采用关系型数据库接口和大数据平台数据接口相结合的方式。这种数据应用模式的优缺点如下：

优点：充分考虑到数据对接类型的全覆盖，以避免数据分析软件或者下游系统无法对接Hadoop数据接口的风险。
缺点：增加了数据中心的ETL工作量，同时由于多了一层关系型数据库和大数据平台的数据交互需要额外增加数据质量控制机制来保证数据应用的数据质量。
1. 系统性能

根据目前现状，在充分考虑公司未来 3-5 年的业务发展需要，总体达到性能指标如下：

系统性能指标列表

指标项	指标值
前端展现在线用户数	不小于3000
并发用户数	不小于300
客户历史数据保留期限	长期保留
日、周报表数据生成时间	小于1小时
月度报表数据生成时间	小于2小时
实时数据ETL处理时间	小于1分钟
日终数据ETL处理时间	小于2小时
数据整合时间	小于2小时
一般查询响应时间	小于3秒
查询时间超过3秒的功能占比	小于5%

容错机制

在数据抽取清洗（ETL）的每一个环节出现错误时都应有相应的出错处理、恢复流程，错误处理应尽量通过系统自动恢复实现，需要通过人工干预处理的，出现错误后应能通过各种途径通知维护人员。常见出错处理方式：

错误类型	错误内容	处理方式
系统异常	数据库连接失败	自动处理，重连
	数据库空间不足	自动提醒，手动扩展空间
	程序异常退出，如机器掉电，强制结束进程	手动处理，重启程序，系统自动保证事务一致性
应用异常	主键冲突	自动手动结合，系统分析导致主键重复的数据，由相关人员手动排除错误。
	数据类型转换失败	手动处理，手动排除错误。
	字符串转换越界	自动处理，自动截断字符串，并记录日志，作提示，供相关人员参考。
	数据库死锁	自动重试，重试后错误依然存在的，记录错误信息，手动处理。
	由于柜台数据结构变动引起的数据转换不完整	手动处理，修改转换过程。
	数据核对有差异	手动处理，检查数据差异。

数据采集工具在处理的每一个环节都有完善的出错处理，可以根据客户的需求，设定出错的的处理原则，例如放入临时表，导出出错文件，或者是发EMAIL或者是短信网关通知相关的人员。

安全性设计

系统的安全性表现在对系统网络、数据传输、数据存储、业务功能展现全过程的安全控制与管理方面。数据的传送的安全性，通过技术平台的数据安全机制，如自定义动态加密算法、校验算法、用户认证证书等，可有效地保证数据从客户端的接收至服务端的处理全过程的安全。而从业务部分来说，系统通过对登陆用户采用统一的用户认证服务器进行身份的合法性验证，通过对操作员操作身份认证与操作权限的严格限制，确保了业务处理在身份认证与权限上的安全控制。

网络安全性

网络安全技术主要解决诸如如何有效进行介入控制，以及何如保证数据传输的安全性的技术手段，主要包括物理安全分析技术，网络结构安全分析技术，系统安全分析技术，管理安全分析技术，及其它的安全服务和安全机制策略。本项目可以综合利用虚拟网技术、防火墙技术、病毒防护技术、入侵检测技术、安全扫描技术、认证和数字签名技术、VPN技术、应用系统的安全技术等多种技术相结合的方式来保证网络的安全性。

1. 数据安全性
数据存放

数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。所有核心数据存放在数据库中。具体安全措施包括：防止非授权的数据库存取；防止非授权的对模式对象的存取；控制磁盘使用；控制系统资源使用；审计用户动作。

数据访问

数据抽取服务器对数据源的数据只有读取权限，无其余任何查询、修改、删除数据权限。数据接口服务模块对数据中心的数据只有读取权限，不具有修改和删除的权限。

1. 操作安全性
错误提示

系统对错误都有明确的错误信息提示，从而大大加快了问题的解决，保证系统稳定安全的运行。

操作人性化

系统的界面设计针对用户做了非常细致的考虑，尽量做到系统运行无人值守，系统运行发现问题能够尽快提示给相关人员。提示友好而准确。

配置管理

系统有详细的配置清单。

容错机制

系统在实时数据抽取，日终文件传输，日终文件导入和清洗流程均有相应的容错机制。

1. WEB安全性
证书安全

系统WEB中间件支持加载证书，支持HTTPS协议。

用户口令保护

系统所有应用都受用户口令保护，只有通过用户口令校验之后才能访问，每个请求在递交给应用服务器前，都首先判断是否已通过用户认证。

权限控制

业务展现平台、数据管控平台的权限控制基于角色与组织架构来控制。结合BI系统可以将权限控制对应的字段。相关授权与重要功能的读写留痕，并有专门功能提供查询。

可靠性设计

系统具有完善的容错功能，数据库服务器、网络设备、存储设备及相关系统和软件均有冗余设计。系统所有应用服务器提供冷备份措施，当其中一个应用服务器出现故障时快速接管。

数据基础平台

本次系统建设的关键是首先要建设一个公司级的数据中心，抽取现有各交易系统、账户系统、资管系统、TA系统、资讯系统、SOEM等系统的相关数据，并进行标准化和提供各业务系统二次开发标准接口。具体可以分为数据抽取清洗、数据标准化及建模、领导者驾驶舱应用、数据管控平台4个部分。

ETL包括从业务系统抽取数据，进行整理和转换，然后进行数据加载。在目前的环境中，可以界定为从源系统的取数据到装载数据入核心数据库的这段过程。下面的图描述了ETL和相关部分的具体数据流。

下图为通过ETL建立数据仓库的整体过程：

ETL主要完成以下内容：

从各类同构或异构生产库系统抽取、转换、加载数据到大数据平台的ODS数据层。
根据xx需求按照一定主题建立的数据模型，抽取、转换、加载ODS数据到大数据平台的企业级数据仓库层即EDW层。
根据数据中心模型设计规范与xx的数据需求建立完整的数据中心指标体系。
根据xx业务条线或者部门级的需求按照数据中心既定的数据标准和规范加载转换EDW数据和指标库数据到各类数据集市。
1. 数据源

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估值系统	全面风险团队已投产

数据组织结构
1. 数据组织目标

数据组织是由业务系统数据分析和数据中心需求分析相结合后，产生的为之后的数据层次提供分类的综合依据，具体表现为为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. 数据组织原则
时间与效率原则

为了保证数据中心能够及时为各个总部管理系统提供数据服务，必须控制数据的再加工量，日终处理(采集和加工)不能以延长时间为代价，原则上，日终处理的时间不应超过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主要指证券公司营业部的柜员为客户提供服务的当事人，包括柜台的基本信息。
当事人关系历史：主要指与当事人之间的历史关系变化，用拉链算法，其中当事人关联关系代码，包括（经纪关系，代理关系等），开始日期和结束日期。
当事人风险代码:：主要指当事人开户的风险规范，
当事人状态代码：主要指当事人状态，包括挂失等。

当事人风险

当事人评级历史：记录当事人的风险评级情况，主要包括信用评级的信息。
当事人额度历史：当事人的分类额度及额度的使用历史。

重要关系

当事人协议关系历史：记录当事人与协议的关系历史，目前记录的主要是协议的持有者、担保者、共同参贷人等关系。
事件当事人关系：记录事件与当事人的关系，一个事件会涉及很多当事人，比如事件的发起人、事件的代理人，事件的经纪人等。
当事人地址关系历史：记录当事人与地址的关系，当事人的地址变更历史等信息。一个当事人可以有多个地址；一个地址可能被多个当事人使用。
产品当事人关系历史：描述产品与当事人的关系，如开发、经销、购买等。
内部机构当事人关系历史：内部机构在与当事人的关系中扮演不同的角色，如开户机构、管理机构、分析机构等。
1. 内部机构模型

内部机构（Internal Organization）是一个比较宽泛的概念，可以是正式机构，也可以是一些具有特定功能的团队。本模型中内部机构是指证券公司的内部组织和业务单元，如营业部、服务部、部门、销售团队等。

通过该主题的建立要能够体现不同组织机构之间的层次隶属关系，同时还能够适应组织机构变动的灵活性以及交叉管理的需要。此外，该主题和当事人、地区、产品、协议、事件、营销活动等都有关联。如对产品而言，可能有多种角色，如创建、销售、监控等。

唯一标识

内部机构的唯一标识以核心业务系统机构管理中的机构编码为基础，结合财务管理系统和其他业务系统的机构编码进行整合。

内部机构概况

内部机构：记录各业务系统中所有的内部机构信息。
内部机构名称历史：记录内部机构的名称变化历史。
内部机构级别历史：该实体描述了机构内部的组织架构和层级。这是在机构是一个层次的组织架构体系假设前提下的。

重要关系

内部机构协议关系历史：记录协议与机构的关系历史，如协议的归属机构。
内部机构地址历史：记录内部机构在各业务系统的地址信息。
内部机构产品关系历史：记录机构与产品的关系。
内部机构当事人关系历史：内部机构在与当事人的关系中扮演不同的角色，如开户机构、管理机构、分析机构等。
1. 地域模型

地域（LOCATION）是希望观察和分析的任何区域，既包括传统类型的地址信息（如国家、地区、城市、区县、街道等），又包括如电话信息、电子地址、邮箱、黄页等信息。客户可以用于和银行的交互和沟通，也可以被用于某个特殊的场合（比如对帐单寄送地址等）。

“地址编号”作为一个地址信息的唯一标识。

主要内容

地址信息分为电子地址、物理地址和电话地址三个分类。此外，考虑到地理区域与以上三类地址信息的联系和差别，综合模型实体间的关系和总体布局，也将地理区域作为地址信息的一个分类。

地址：所有地址的超级父类实体。
电子地址：包括当事人的eMail、网址、IP 地址等。
物理地址：存放物理的门牌地址信息，如家庭地址、单位地址、暂住地址等，主要属性包括：
- 信函地址、邮政编码：具体的邮寄地址。
- 国家代码：目前已有的国家地区代码。
- 城市、区县、城镇、街道、住宅小区、建筑物、门牌号码：详细的物理地址信息。
- 邮箱号码：邮局为该物理地址分配的一个信箱号码。
- 国家组合代码：为世界性的国家组合进行编码，比如东盟、欧盟等。
- 世界区域代码：为世界性的区域进行编码，如亚太地区、阿拉伯地区等。
电话地址：存放电话信息。如家庭电话、手机、BP机。
地理区域：地址信息的一个子类，存放非行政区划上的区域信息，如珠江三角洲、长江三角洲等。
- 区域名称：定义国内的地理区域，主要指有一定影响力，有共同特征和利害关系的地理区域。
- 地理位置：描述区域的地理位置和范围。
- 代表城市：区域的代表城市，可以是经济中心，也可以是其他种类的中心城市。
- 经济状况：从经济发展状况角度描述区域的特征。
电话地址通讯类型关系：存放同一个电话号码所对应的通讯类型，如电话、传真等。

重要关系

产品地域关系历史：描述产品与地址的关系，如某产品在某个地域销售。
协议地址关系历史：用于记录协议与地址之间的关系，比如协议指定的对账单寄往地址。
1. 产品模型

证券公司产品（PRODUCT）是指为拓展市场占有率，满足客户更广泛需求而制定的可营销的交易品种集合，产品是金融机构向用户销售的或提供给客户所使用的服务。产品必须是能够面向市场、面向客户的，并且必须要有回报发生的。

唯一标识

产品的唯一标识就是产品编号，由于XX证券源业务系统没有明确的产品定义，所以唯一标识号会结合各个产品的特点来生成唯一号。

产品分类

产品：该独立的实体包含证券公司可以提供以及竞争对手可以提供的任何感兴趣追踪的可以市场化的产品、产品包和服务的信息。该实体包含过去、现在和将来的市场化的产品、产品包和服务。每个市场化的产品、产品包或服务都是该实体中的一个实例。产品的范畴还包括投资工具，如股票、权证、债券、理财，融资融券、短期融资券，股指期货和基金等证券产品。

根据产品类型代码，产品划分为：

金融产品：股票、权证、基金、债券、理财，融资融券，短期融资券、股指期货等均属于此类产品。
非金融产品：以证券公司为服务的产品。

重要关系

协议产品关系历史：随着生命周期的变化，一个协议可能会在不同的时期属于不同的产品，这些产品在该关系中的角色也发生着变化。
1. 协议模型

协议（AGREEMENT）是证券公司与当事人之间针对某种特定产品或服务而签立的契约关系，它可以是多样化的。当证券公司与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议（AGREEMENT）就会被开立，因此协议是客户和证券公司往来的重要载体。

主要内容

协议实体是协议主题的核心实体，保存协议相关的属性信息。对于协议持有人、科目代码、协议归属机构、协议状态代码、协议状态原因代码这些可变信息，协议实体中只保留最新的信息，其余历史变动信息保存在相关历史实体中。
- 协议号成协议的唯一标识。
- 协议类型代码：描述协议的类型。（1资金协议，2证券买卖协议，3开基协议，4融资融券协议，5理财协议，6债券买卖协议）

重要关系

事件模型

事件（EVENT）是一个范围很广的概念，它可以包含与证券公司相关的任何动作的记录。既可以与资金相关，也可以与资金无关；既可以有客户参与，也可以没有客户参与；既可以与账户相关，也可以与账户无关；可以由客户发起，也可以由证券公司发起；总之它可以记录的范围非常广泛，可以记录各种与证券公司相关的活动的详细情况，包括交易数据，比如网上交易，查询流水，交易流水，资金的转入转出等。

唯一标识

唯一标识一笔事件的字段是“事件编码”，编码规则是由“源业务系统编号＋各系统原唯一编号”组成，如核心交易系统事件编号为“0100 ＋交易日期＋地区代号＋机构代号＋日志序号”。

主要内容

事件是本主题的主干实体，主要包含事件日期、事件时间、交易代码等各种事件的共性信息。

事件分为核心事件和外围事件两大类，核心事件主要包括核心交易系统的交易流水信息（金融事件和非金融事件）；外围事件则主要包括所有的外围系统交易流水信息（营销系统，法人清算系统，开放式基金系统，融资融券系统等）。

外围事件

营销系统事件：描述外围系统营销服务系统中，基本的客户预约和客户投诉事件信息，以后会进行扩展，将同时也记录与营销相关的营销活动的事件。
- 营销系统事件类别代码：记录营销系统中事件的类别，包括投诉事件类别和预约事件类别。
- 营销系统事件类型代码：记录营销事件中事件类别一下的分类信息，比如在投书类事件中有：服务类投诉和费用类投诉等。
银证平台交易事件：描述外围系统中银证平台的交易事件信息，目前主要有银证通的交易事件：银证通银行端交易事件（委托流水和开销户流水）、银证通证券端资金冻结事件（证券端发起的资金冻结流水）、银证通交割明细（证券端每日提供的交易交割明细）；以后会增加银证转账的事件。

重要关系

事件当事人关系历史：一个事件会涉及很多当事人，比如事件发起当事人、事件授权当事人、事件的代理人，证券交易事件中交易双方当事人等。
事件内部机构关系：一个事件会涉及很多内部机构的信息，比如事件的发生机构、事件的操作柜员、事件的授权柜员等。

事件产品关系：记录事件与产品之间的某种关系。

1. 资产模型
唯一标识

资产主题不产生统一主题编号。
资产主题中增加其他主题编号，如当事人编号、内部组织编号、协议编号等。

主要内容

证券交易资产：包括客户资金余额/证券余额。

中登证券余额信息：取自中登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－暂停。
大众/目标营销：是营销活动的子类，目标营销是直接针对具备某种特征的个体进行的营销活动；大众营销可以是直接面向一组人群，如电视广告、报刊杂志广告等类型的营销；而大众/目标营销事件是营销的真正实施过程及结果的记录，与营销活动相互呼应。
广告：是针对客户细分的市场活动信息，通常会宣传产品或者一些特殊的项目，广告可以在杂志、网络或者电视媒体上等渠道上进行。
广告安置：包含何时何地通过一个特定的渠道交付广告的信息，隐含了广告和渠道的关系。
营销活动优惠项目：是客户可利用的确定的激励措施，通常包括适用条件和针对使用条件的奖励；它通常是一个精心设计的实现一定目的的行销行为，可以是营销活动的一部分。
优惠项目：是客户可利用的确定的激励措施，通过优惠项目编号唯一表示一个优惠项目，与营销活动本身建立关联关系，体现在营销活动优惠项目实体中。
营销活动费用：记录营销活动的预算和实际开支。
- 营销费用类型代码：记录营销活动各费用类型，如：咨询费用、电视播放费用、印刷费用、人工费用等。
- 营销活动预算费用和实际费用：记录具体的预算费用和实际费用。

重要关系

营销渠道类型关系：描述任何层次营销中涉及的渠道类型的关系实体，一个营销/营销活动活动可以通过多个渠道完成。
营销地域关系历史：描述营销针对的目标区域组织，如销售区域的关系实体。
营销当事人关系：描述营销涉及的当事人，关系类型代码主要包括：目标客户、执行人等。
营销内部机构关系：描述营销涉及的内部机构，如发起机构、管理机构、目标机构、执行机构等。
营销协议关系：记录一个营销映射到多个协议，以及一个协议映射到多个营销的关系实体。
营销产品关系：记录营销与产品的关系，某个具体的营销可能只涉及部分的产品。
1. 渠道模型

渠道主题所描述的是当各种事件发生时，当事双方（主要是指客户和证券公司）进行交互和接触的手段及方法，通过它客户与证券进行接触、购买产品、使用服务并交流信息。

唯一标识

渠道的唯一标识由“渠道类型编号”和“渠道编号”两个字段组成。

主要内容

渠道类型组：渠道类型的分组是由于不同的“渠道类型分组原因代码”所做的分类，如销售渠道、人工渠道、电子渠道等，满足不同业务部门管理统计的需要。
渠道统计学信息历史：记录渠道的各种希望关注的特征统计学信息。
渠道类型/渠道容量历史：记录每类渠道/每个渠道的最大工作容量信息。
- 渠道类型/渠道容量的时间周期代码：如月、日；
- 渠道类型/渠道容量的容量值：具体记录容量值的大小。
渠道事件：记录渠道本身发生的一些事件信息。

重要关系

当事人渠道关系历史：记录渠道与当事人的关系历史，同时记录这些关系的有效时间段。
内部机构渠道关系历史：记录渠道和内部机构的关系历史，如渠道的归属机构等。
产品渠道类型关系：记录某些产品和某个种类渠道的关系。
渠道类型/渠道和营销/营销活动关系：一般情况下制定一个营销策略时会因为渠道的成本、效果不同来指定某种渠道或渠道种类，真正开展一个营销活动时也必然要借助某个渠道。

渠道地址关系历史：用于记录渠道的地址信息，如安置地址、联系电话、前置机IP地址等，同时保存历史。

数据集市

数据集市也叫数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。简单来说数据集市就是一个遵循数据中心规范的、可定制化的、面向应用的数据集合体。

数据集市的数据来源于数据仓库模型层；同时数据集市是各类应用的数据源。根据应用属性的划分，数据集市可以分为客户分析数据集市、运营管理数据集市、市场分析数据集市、风险管理数据等。数据集市根据业务应用的滋生而调整，当出现相对独立的应用系统或者数据需求时，则针对该类应用建设对应的数据集市。

其中风险管理数据集市是xx数据中心系统和全面风险管理系统进行对接的专业数据集市，在风险管理数据集市中定义全面风险管理的基础数据需求，达到全面风险数据接口规范化的目的；同时数据中心也会采集全面风险管理系统中统计的风险管理指标，纳入到数据中心指标库体系中，为风险数据分析、风险计量、风险管理领导者驾驶舱的建设打好数据基础。

数据服务平台
1. 数据服务平台目标

梳理复杂公司的数据流向网，将数据中心建设成公司企业级数据平台，所有需要数据的管理系统向数据中心索取数据，数据中心负责整合管理系统需要的数据并提供数据接口服务，业务系统出现升级导致表结构变更，或者出现大的变更时，保证数据中心对管理系统的表结构不变，减少对管理系统的影响。

数据服务模式

建立业务支持、数据接口服务层，可以让各个管理系统主动连接到数据中心来获取需要的数据，主要适用于目前证券公司已经在使用的管理系统，例如风控、CRM系统等。为了保持数据稳定或者其管理系统架构不变，只做数据源的切换，从交易系统采集切换到数据中心采集，通过数据同步软件同步交易系统数据原样到数据中心（原始层）。对于在数据中心后上线的管理系统，则需要从ODS层、EDW层获取源系统数据，从而保证在源系统变更时，不会影响从ODS层、EDW获取数据的管理系统。

管理系统	变动类型	备注
已上线管理系统	交易系统采集切换到数据中心采集	减少管理系统架构不变和保持数据稳定
数据中心后上线系统	从ODS、EDW获取数据	后续生产系统变动对管理系统影响小
查询统计	访问数据中心的数据	获取稳定、一致数据

数据服务方式

实现方式主要有以下三种：

接口访问方式	详细方式	备注
WEB Service	标准通用接口，提供少量数据访问方式	可为后续呼叫中心等提供实时少量数据访问
主动推送	利用数据同步工具将数据推送至下游系统	下游系统对接数据中心困难、中等规模数据量
授权用户直接访问	数据中心开通相应的用户和接口表，提供下游系统采集或直接访问	适合超大历史数据

Web Service接入

Web Service是一种标准的服务调用接口，因此只要符合标准的外围业务系统都可以进行接入，在这种方式下，数据访问服务通过J2EE服务器加载数据服务应用程序来实现，服务的跨网段调用通过在网段之间部署Web服务器来实现。

服务调用所提供的服务、用户、权限，由管理程序进行统一的管理。

设计要点

身份认证 调用端需要通过身份认证后才能进行服务调用，身份采用用户/密码方式进行认证，系统需要为不同的调用端提供不用的登录用户。

通讯加密 所有的请求和应答都需要进行通讯加密。采用Web Service提供服务时，可通过HTTPS协议进行通讯加密，以保证数据的安全性。

权限管理 针对不用的访问用户，提供不同的服务调用权限，用户不能越权访问数据。

接口提供 将所提供的服务的输入、输出接口提供给调用者，使用WEB Service本身的机制将服务接口提供给调用者。

主动推送

在下游系统对接数据中心系统取数困难的情况下，数据中心可以利用数据同步工具将下游系统所需数据主动推送到下游系统数据库。

授权用户直接访问

数据中心针对不同业务系统建立对应的对外数据服务用户, 通过数据接口管理界面可对该用户设置相应的数据访问权限。同时数据接口管理提供明确的接口表说明,外部应用只要得到授权许可,就可以直接访问该用户下的数据,从而达到数据中心提供数据服务的目的。

数据接口服务安全性
1. Web Service数据访问安全

对于小数据量的数据访问服务，我们通过Web Service来实现，首先访问Web Service的用户需要通过校验，其次，该用户具体通过Web Service访问的记录需要有详细的记录，包括访问时间、访问对象和访问记录明晰。

用户角色访问安全

用户登录数据管控平台，需要首先经过用户的认证机制，通过用户角色来分配权限，权限分成菜单功能权限和数据访问权限。对于数据访问权限，需要定位到营业部级别，即营业部人员只能查看自己营业部内的数据。对于具体哪个用户访问那些功能需要有明晰的日志记录。

1. 数据库级别安全
下游系统对接CDH数据平台

若下游系统直接对接CDH数据平台，则引用CDH数据安全访问机制。

下游对接Oracle数据库

对于部分下游系统无法直接对接CDH数据平台，数据中心将接口数据从CDH同步至Oracle数据库，在Oracle库上建立一个用户DCSER来对外提供数据访问用户，对于数据库用户DCSER必须明确限定外界具体能访问的表。

对于具体外界对象对DCSER访问的明晰信息可以通过两种方式实现，第一，开通数据库审计功能，第二，定期查询数据库用户执行的SESSION并记录保存以便稽核。包括访问的时间、机器名、IP、运行的SQL语句等，由于数据量会比较大，可以采取拉链的形式存储相关审计信息。以上信息都需要在数据管控平台中提供查询功能。

智能分析平台
1. 平台结构

智能分析平台的优势，是基于综合的数据和开放的工具，能制作各类格式报表，快速大量生成，并分发到相关需要的人。

通过智能分析平台，业务人员如同使用Office Excel 一样，能方便的在线对数据进行分析。同时分析结果能发布到数据门户或者嵌入其他业务系统（如CRM、呼叫中心）中，以方便一线的人员（如客服人员、投资顾问）使用。

1. 平台功能类型
报表：

提供各种广度的报表类型；
在各种类型的报表输出中提供一致信息；
可以个性化、有针对性地定制；

允许多用户、多用户群、以及和IT之间的协作；
可以通过email、门户网站、MS-Office、搜索、以及移动设备等进行访问。

BI分析：

提供多方位信息视图；
方便快捷地执行复杂的分析和情景模拟；
揭示趋势背后的“为什么”，了解症状及原因；
轻松地从信息的摘要级别提高到细节级别。

领导驾驶舱
为企业高层提供的“一站式”决策支持的管理信息中心系统；

各种常见的图表（速度表、柱形图、环形图、预警雷达等）形象标示企业运行的关键指标（KPI），为复杂信息提供了一目了然、重点突出的视图；
灵活配置，根据用户习惯，选择合适的图形来显示想要了解的具体指标，一个图形可以反映多种指标，一种指标可以由多个图形显示的交叉实现模式，配置更加灵活。

数据挖掘

根据用户社会属性、交易行为和终端日志等信息而抽象出的一个标签化的用户模型；
基于logistic回归模型，预测证券公司预流失客户，分析其流失原因，证券公司可以及时采取相应措施，挽留客户；
基于协同过滤模型，挖掘客户与产品的相似度，进而对客户开展有针对性的营销，以满足不同特征用户各种的需求，提升客户满意度和忠诚度。
1. 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、财务等不同系统中抽取数据，经过各种各样的传输、转换和处理，加载到数据仓库中以后，为各管理系统及数据挖掘提供基础数据。

随着用户对数据分析需求的增长，数据仓库中数据质量变得越来越重要。质量差的数据不仅可能对企业生产造成负面影响，而且会使用户觉得所产生的报表不可信赖，更重要的是错误的数据容易误导用户，从而造成管理决策的失误，此外低质量的数据会使雇员失去对企业的信心。客户对错误数据将无法忍受，例如发送错误的成交信息、成本价或者不正确的客户资料，会认为公司管理混乱，从而造成客户流失。所以说数据质量是数据治理的核心功能，也是数据仓库的生命。

在证券公司的很多系统中，数据是最重要的处理对象，也是最终呈现给系统用户的内容。系统用户认为系统是否发挥了应有的作用很大程度上依赖于系统提供的数据是否真实准确，高质量的数据将提升用户对系统的信心，进而影响企业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地址、登录退出时间、浏览过的页面、执行过的操作等，同时也提供日志查询功能，便于后续的审计及异常的定位。

系统部署
1. 系统部署方案

方案通过防火墙隔离，总共分层三层安全级别区，其中，最外面第一层是日常办公网络等，第二层是数据中心相关系统，第三层是核心业务DB，其安全级别依次升高。

由于数据应用服务器和CDH集群中间存在一定量数据的传输与计算，如果还是通过防火墙的传输势必照成相当的压力，所以数据应用服务器直接越过防火墙通过交换机与CDH集群连接。

系统备份及应急方案

应用服务器备份

系统将专门准备备份服务器，预先安装各种系统软件，作为系统各应用服务器的冷备份，当系统的其中一台应用服务器出现问题的时候快速接管，保证系统的正常运行。

灾备及应急处理

利用上述方案搭建灾备系统，在发生紧急情况导致生产系统无法启动时，可及时开启灾备系统，在生产系统恢复后，再将异常期间的数据从灾备系统中进行恢复即可。

系统应用设计
1. 系统整合

系统整合根据整合的级别不同可以分成多种类型，应用级别整合,统一访问整合,明细数据整合，数据服务整合。其中固定报表系统、查询系统的整合属于应用级别和统一访问的整合;智能分析、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周前才发现。

客户可以自定义警戒线，领导者视图中会列出触及警戒线的交易对手名单，提供管理层参考。

硬件以及第三方软件
1. 系统硬件平台

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	数据中心平台配置库、数据服务缓冲库

项目计划与实施
1. 项目总体计划

阶段		日期（工作日）	阶段目标	阶段文档	涉及双方人员
项目准备	项目前期准备	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.项目验收		双方项目组成员

项目沟通计划

项目开发实施期间，由项目经理负责整个项目的管理与协调，由项目经理协调安排人员与客户方进行项目相关的沟通，协调项目组成员进行问题的解决，并负责对沟通问题的追踪，确保最短时间内解决问题。

项目资源计划
1. 项目组织结构

项目组成员

本项目项目组成员情况如下：

数据交换层设计

设计数据采集平台

ETL设计调度模型
ETL整体框架设置
设计数据服务平台

数据推送设计

实时数据推送设计
WebService接口设计

设计数据展现平台

领导者驾驶舱功能展现设计

设计运行监控平台

ETL运行监控及运行报告
ETL调度
驾驶舱运行监控及运行报告

数据质量检查

数据标准化工作
字段命名、字段类型
统一数据字典
统一代码规范
1. 系统开发与实施

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) 领导者驾驶舱开发

1. 系统测试与运行
系统测试内容

按照调研阶段确认的信用评级系统需求说明书中的需求依次进行测试。

系统测试方案

在系统上线后，项目组按招标文件及投标方说明中按模块化具体就各项系统功能和性能的要求提交《系统测试报告》，报告经过确认后，双方项目组根据测试报告的测试内容进行全面的性能和功能测试。

系统验收

本项目进行验收条件是系统实施完成.如果达到验收标准，应填写xx公司正式书面验收报告，以确认xx公司的提交物达到要求。如不能达到验收标准，则应建立业务流程来修改提交物。

系统验收内容

以合同附件对验收的要求为准。

系统验收文档

由xx公司提交以下文档：《系统验收报告》。

系统验收流程

提交物的验收准备好后,通知风控项目组进行验收.如果提交物符合要求,则对项目验收报告签字;如果提交物不符合要求,双方协商如何修改,直到验收通过。

培训计划
1. 培训目的

本次项目培训的目的：通过一系列有计划、有步骤的用户培训，要使涉及xx的管理领导、业务人员、技术人员，能理解和掌握xx数据中心系统的操作和使用。

培训对象

实施培训的对象可分为两个层面：

●xx相关信息技术人员：对信息技术中心运维人员进行运维培训，包括系统常见的问题及解决方法、系统的安装方法、系统监控软件的使用等。对信息技术中心研发人员进行技术架构、开发平台的培训，并参与部分功能的开发，从而熟悉系统技术架构和开发环境，便于以后需求的二次开发。

●xx相关业务人员：为了让业务人员能够了解系统，并能熟练操作用户使用界面，对业务部门的培训工作必须放在系统正式上线之前，可以边进行用户测试边培训，这样可让用户在接受完系统的操作培训后，能立即使用对应的子系统辅助自己的工作。

培训方式

用户培训主要分为三种：

● 集中培训：

把培训的对象集中起来，进行有计划的系统使用培训。

● 用户要求：

根据用户对培训的具体要求和目的，派专人作用户培训。地点、形式和方法可由用户自行决定。

● 专项培训：

安排公司开发经理对用户系统维护技术人员进行专项培训。

培训内容

培训类型	培训课程名称	参加对象	主要内容
技术培训	数据仓库工具培训(ETL、BI工具)	ETL开发人员、报表开发人员、系统管理员 2．开发商项目经理/成员	1.相关工具的安装 2.相关工具使用的培训 3.开发规范培训
技术培训	数据库优化	1.系统管理员、数据库管理人员、数据建模人员	1.系统业务、物理模型培训 2.数据库架构、优化；相关系统表介绍 3.典型优化场景培训
技术培训	系统日常管理运行	1.系统管理员	系统日常管理流程系统异常预警及处理流程
业务培训	相关应用子系统使用培训	1.相关业务部门人员	1．相应应用子系统使用培训

项目质量控制计划

在整个系统设计和开发、实施过程中，对于每个环节都需要填写

工作计划、需求说明、设计文档、测试计划、测试文档，使每一项工作都处于受控状态。确立项目实施过程中产物、最终产物的质量标注和质量控制活动中各个要素。

文档及质量标准

所提交的文档需按本项目相应的文档模板编写,也可进行合理的调整。所有提交的文档必须符合文档规范，且文字通顺、条理清楚、无二义性。

1. 质量控制活动
软件产品质量保证

软件产品评审/同行评审，详见软件工作产品评审清单。

软件测试：包括单元测试（由软件工程师负责）、集成测试、系统测试和验收测试（由测试组负责）。

软件过程质量保证

由专职SQA工程师负责实施SQA审计，从独立、客观的角度将项目工程活动过程的实况反映给项目管理组，让项目管理组及时了解过程与规定之间存在的偏差。SQA审计活动通常分为如下三类：

SQA每周例行审计，审计内容为：本周文档/代码评审、个人工作周报和项目组工作周报的填写及项目备份等的执行情况，详见SQA周报模板。

SQA工程师参与或列席评审会议，审计内容为：本次评审的工作产品和本次评审过程。

SQA阶段审计（通常在基线审计后进行），按SQA审计检查单的内容进行逐项审计，审计内容为：上次审计到本次审计期间的软件工作产品和软件工程活动的过程记录。

质量保证

质量审核确保项目满足预定的质量目标。项目经理会主持正式的质量审核以确保建立的质量控制流程被执行并且结果与项目质量目标相吻合。

变更控制计划

对于变更，通过如下流程进行管理和控制：

变更由双方项目组成员提出
xx项目经理与金融公司项目经理共同确认此变更请求是否为变更。
若是变更，提交总体技术组或相关人员评估此变更，同时交变更管理员登记此变更。
根据评估结果,由xx项目经理与金融公司项目经理签字决定是否执行此变更。
若此变更决定被执行，项目组即可按照推荐方案上的内容制订相应的变更实施计划，进行有关的变更操作，并详细记录状态。
由技术组或相关人员评估此变更执行结果。如果达到要求，则完成变更。若未达到，则直到达到要求为止。变更的执行结果交变更管理员归档。
1. 项目风险管理
  1. 项目技术风险分析

风险评估旨在描述如何通过风险控制保证系统建设中的业务连续性，本项目涉及的主要风险描述如下：

数据风险

客户资料、资金等信息的安全保障。

客户历史交易信息，及系统资料变更信息。

系统风险

系统处理能力
操作系统和数据库处理能力
硬件平台处理能力
业务整合涉及的技术细节
信息技术部人员应对系统架构的技术业务知识储备

设备风险

服务器

中间件

业务处理机

通讯线路

网络设备，如路由器、交换机等
1. 项目业务风险分析

由于业务流程变化对业务造成影响

对新系统熟悉度和理解不够导致的错误业务或错误业务流程
1. 项目管理风险分析

项目管理，项目规定的执行力度，人员的配合。

机房管理，责任是否明确，人员的积极性、主动性等

管理模式发生的变化，由此产生的风险

工程实施规范的落实。

工程实施人员的误操作。

工程实施过程中不可预见或未能预见的问题
1. 项目技术风险应对

数据风险应对

数据转换过程由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真正把服务作为一项系统工程进行建设，建立完整的质量保证体系，使产品和服务都处于严格的受控状态。

我们通过自身的严格控制，为贵公司制订切实可靠的技术支持和服务保障。

软件开发控制流程的承诺

在整个系统设计和开发、实施过程中，对于每个环节都需要填写工作计划、需求说明、设计文档、测试计划、测试文档，使每一项工作都处于受控状态。

1. xx服务质量控制体系的承诺
xx服务质量方针

为中国证券、金融、期货等行业提供安全、实用、规范、配套、开放的软件产品和集成工程；向每一家xx用户提供专业、及时、长期、发展、多样的服务。

xx服务质量目标

精心设计、细心编程、严格测试，xx产品无过失；

周密设计、互相配合、认真安装，xx工程无返工；

健全体系、规范管理、耐心负责，xx服务无投诉。

1. xx客户服务体系和内容的承诺
合理的服务机构设置

客户服务中心总部设在公司总部杭州，下辖29个地区客户分中心。能够保证贵公司得到第一时间的现场服务。xx的服务强调高效应、快速的服务。

首席客户服务代表制

xx公司将会指定一名资深的工程师作为贵公司的首席客户服务代表，作为贵公司的维护专员，及时解决软件使用中碰到的问题。首席客户服务代表每月至少两次与信息技术部总经理或指定的技术专员作沟通，了解xx产品的使用情况，主动介绍xx在产品、技术、服务等上的最新进展。

用户意见的处理

贵公司对于此系统的任何需求，都可以通过项目经理或者首席客户代表和我们进行联系，我们会在36小时内作出合格的回复；针对回复单里所作的承诺，实行登记管理。用户个性化需求经产品组程序修改后，由测试室严格测试，再发放给客户，并收集用户反馈。

高效流程、多层服务

对于重要的业务均确定了办事流程，对客户意见及处理等都制订了工作流程，使所有的服务处于受控状态。技术服务分两个层次，一线工程支持和二线工程支持。总部部分工程师和全国地区客户分中心的网络工程师提供客户一线技术支持，二线工程师由总部资深工程师组成。

客户服务管理系统

我们把服务管理、资料管理、产品管理、合同管理等相关工作联结起来，实现了公司局域网上的电子化作业，有利于建立高效的管理监督控制体系。它最大的作用是相当于设立了用户软件系统的“病例卡”，能方便地查阅每一用户的产品信息和历史问题。从而让xx用户享受到更好的个性化服务、继承性服务。

7*24小时随时待命服务

xx的服务能够真正做到了有保障的7*24小时热线维护：

公司配置：22条中继线维护；27线维护分机；8条modem专线；16只专用维护手机；全公司所有人员的手机24小时开通，以备万一。

1. 客户服务承诺
故障类型分类

根据我们多年的经验，我们将用户故障类型分为四个级别。

一级故障系统瘫痪，用户业务停机

二级故障系统性能下降，严重影响客户业务

三级故障个别设备故障，只影响局部，不影响全局业务

四级故障安装、配置等技术难点，业务不受影响

根据对故障级别的定义，我们的一线工程师、二线工程师将在严格规定的时限内，对客户进行响应和故障处理。

故障级别	电话响应	一线支持时限	二线支持时限
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数据中心技术方案相关推荐

Google全球三大数据中心自然冷却方案剖析
Google将其数据中心技术作为一个核心竞争力,很少对外公布其技术细节,因此搜索巨人的数据中心一直是个谜.根据谷歌公布其数据中心能耗发展的图表,在图表中显示近年来谷歌在能耗控制方面有了明显的进步. 本 ...
高校云计算机中心建设方案,最新某大学云数据中心建设方案.pdf
精品文档 xxxxx大学云数据中心建设方案 2015/11 精品文档精品文档目录第1章云数据中心总体方案 3 1.1 设计原则 3 1.2 系统建设拓扑图 4 1.2.1 xxxxx大学智慧 ...
国内数据中心变革的见证者，揭秘阿里巴巴数据中心技术积淀
[编者按]在前文<做数据中心,腾讯是认真的!>中,我们向大家介绍了国内科技巨头腾讯在数据中心建设上的成果和现状.今天,我们把目光转向阿里巴巴,看看这家科技公司在数据中心建设上有哪些进展. ...
云网融合驱动数据中心技术聚变
摘要:全球网络中20,489,883个运行设备,将近人均一个申请专利,年销售额15%以上用于研发,基于雄厚的技术积累,4月17日,华三正式发布融合数据中心解决方案,为未来数据中心建设指出了一条&quo ...
不动产数据整合技术方案
目录存量数据整合 2 1.1目标与任务 2 1.1.1数据整合目标 2 1.1.2数据整合任务 2 1.2总体要求 4 1.3整合思路 5 1.4主要技术方法 9 1.4.1内业属性关联 9 1.4 ...
学校云计算机中心建设方案,智慧校园云数据中心建设方案.docx
智慧校园云数据中心建设方案目录 TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc526875262" 第1章云数据中心总体 ...
大学数字化校园云数据中心建设方案
大学数字化校园云数据中心建设方案精品方案 2016年 07月目录 1 项目背景 2 建设原则 3 方案设计 3.1 总体拓扑设计 3.2 总体方案描述 3.3 核心网络设计 3.4 数据中心计算 ...
数据中心技术发展趋势初探
作者:程艳娜本文结合数据中心高速发展的环境和数据中心建设发展需重点考虑因素阐述了数据中心数据中心的预制化､模块化､绿色化､智能化数据中心的技术发展方向｡ 1数据中心面临持续高增长的发展环境 1.1国 ...
2023年四大绿色数据中心技术趋势
随着世界变得越来越数字化,对数据中心的需求不断增长.随着这种增长,我们有责任减少这些设施对环境的影响.数据中心消耗大量能源,导致温室气体排放和地球资源紧张. 因此,人们越来越关注开发绿色数据中心技术, ...
mysql集群跨地域同步部署_跨地域冗余 - 跨数据中心部署方案 - 《TiDB v2.1 用户文档》 - 书栈网 · BookStack...
跨数据中心部署方案作为 NewSQL 数据库,TiDB 兼顾了传统关系型数据库的优秀特性以及 NoSQL 数据库可扩展性,以及跨数据中心(下文简称"中心")场景下的高可用.本文档 ...

XX数据中心技术方案

XX数据中心技术方案相关推荐

最新文章

热门文章