【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014,关注中国数据库技术大会公众号）现场演讲嘉宾种磊老师分享内容整理而成。录音整理及文字编辑IT168@田晓旭@老鱼。
嘉宾介绍：
▲农银人寿IT部资深专员 种磊
种磊，经济师，农银人寿IT部资深专员、新核心数据组组长。04年进入农总行软件开发中心，有8年银行信息化经验，09年参与核心银行应用设计。14年进入农银人寿，主持数据治理与标准化及新核心模型设计工作。
正文：
我今天和大家分享一下公司新核心项目的数据架构规划和数据治理，可能大家对我们公司不太熟悉，借此机会先介绍一下我们公司。
农银人寿保险有限公司，简称农银人寿。前身是嘉禾人寿，13年年底由农行控股，至此五大国有银行都拥有了自己旗下的保险公司。
我们公司是国内机构布局最广的银行系寿险公司，拥有20多家省级分公司，300多家分支机构。14年的时候，客户数量是529万，截止到大会之前，客户数量是780万，年增长率达到21%。公司在14年成功扭亏为盈，去年保费规模达到了175亿，年复合增长率57%。所以在这两年期间，无论是在客户数量还是在保费规模，都出现了迅猛增长的态势。
下面简单介绍一下项目的背景。我们现在使用的是中科软保险核心业务系统，于07年10月份上线。这个系统比较陈旧，扩展性和稳定性都比较差，已经不能满足业务快速变化发展的需要，也不能满足快速推出新产品的需要。
在这个背景下，公司于13年立项，15年开始全面推动新核心业务系统的建设。我们为这个系统设计了全新的IT架构，包括数据架构、应用架构和技术架构。大家从这个应用架构图上可以看出来，新核心项目有众多的项目群，包括渠道接入、运营支撑、基础应用平台、数据管理、数据应用、决策分析以及项目实施，每个域里又包含多个子系统。我们的数据架构规划和数据治理标准化的实践就是在这个背景下展开的。
首先介绍一下组织结构，一个清晰的组织架构对于项目来说是十分必要的。新核心项目组，在领导小组下设执行小组，执行小组下设技术实施组，实施组下面又包含多个子项目组和职能组。
数据架构组作为职能组之一，与应用架构、技术架构是并列的。由此可见，上级领导对数据工作和数据治理是非常重视的。有一些单位不重视数据工作，也没有在项目内部设立专门的组织对企业数据进行统一规划和管理，或者是系统建设先于数据管理，等系统都做完了，才想起来做数据治理，那就太晚了，到时候就是想做也做不清晰、做不好了。数据治理工作应该是先于系统建设，至少得是并行。比如我们的新核心标准化字典，需要在业务模型或者数据模型出来之前，就为它准备好经过标准化处理的基础词汇。那么为什么还会有并行期呢?有些数据的标准和规则是在各个业务模块需求和设计的逐渐明晰过程中才能被抽取出来的，这些需要在并行期完成。
我们经常听到一些词，比如企业总体规划、战略、架构等等，它们之间到底有什么关系呢?我按照自己的理解画了一个图，企业总体规划要有企业战略和企业架构来支撑，企业战略又分为业务战略和IT战略，企业架构由业务架构和IT架构来支撑。IT架构分为应用架构、技术架构和数据架构。
我们在对整体IT架构进行设计的时候，要充分考虑到数据架构是否对当前业务进行支持。一个理想的规划顺序应该是这样的：首先应根据业务架构分析来定义数据架构，然后将数据架构结合业务功能定义应用架构，最后根据数据架构和应用架构的特点和技术要求来设计技术架构。这是数据驱动应该有的顺序。
数据架构目标主要是解决两个问题，如何使用数据和如何管理数据。实现数据标准化;减少数据冗余、提升数据质量以及系统性能;消除信息的孤岛，实现数据在系统间的广泛共享;发挥数据资产的价值，为企业带来高附加值的回报。
数据架构总体原则是在基于对老系统的发现问题、分析问题、解决问题的基础上，提出改进分析的意见，结合当前需求和业务特点以及主流技术和行业实践去设计目标架构规划。
这里有一些更细致的原则。比如数据的组织划分要灵活，要能够快速应对业务变更;数据的ETL过程、抽取、加载、数据移动要能够高效;数据架构要具有柔性扩展能力，以此来应对新业务、新技术对架构带来的冲击;提高数据项在企业范围内的全局性和一致性，只有这样才能在系统内和系统间实现数据的广泛共享;数据必须具有使用价值，必须能够满足数据消费系统的要求;数据的安全性。
数据架构的主体设计思路是从需求分析和业务特征出发去进行数据分类，划分主题域，然后采用领域驱动设计方法进行业务模型设计和数据模型设计，再结合老核心的数据治理和标准化的产物，结合数据架构设计原则以及主流技术和行业实践去设计数据架构规划。数据架构规划包括数据的分布与存储、数据的加工与流转，以及数据的管控与应用。这里提到的主题域，其实就是从较高的层次对业务数据进行的抽象和归纳。
新核心项目中使用了一些数据高效操作的方法。第一个是数据集成操作，这由我们的开发平台提供支持。大家都知道传统的ORM框架是以单个POJO实体为单位与后台数据库进行交互，而开发平台支持从多个POJO实体中抽取所需数据项形成一个业务服务对象整体BO，以BO为单位与数据库进行交互，这种方式在重复查询时极大减少了访问次数，提高了访问效率。
第二个是高速缓存，它由缓存平台来提供支持。可以使用缓存平台存放一些数据量比较小但是访问频率很高的数据，比如码表的数据、费率相关的数据以及用户机构和权限的数据。
第三个是读写分离、冷热分离。
数据量很大的话，就要考虑表分区。我们数据建模时在表中预留了“时间字段”和“管理机构”字段，等数据量增大到一定程度的时候，我们就可以按时间做范围分区，按管理机构做列表分区，或是二者结合的复合分区。数据量要是再大的话就要考虑拆库拆表。Oracle提供了数据分片技术(Data Sharding)，现在Oracle最新版的12C数据库已经能够做到从CDB$ROOT层面直接聚合查询多个PDB中同一张表的数据。
下面我通过一张图来介绍一下新核心数据架构的规划设计。大家从这张图上可以看到，我们将数据架构划分了八大区，分别是数据源区、数据集成操作区、数据交换区、数据存储区、数据准备区、数据加工区、数据管理区以及数据应用区。
数据源区中，我们有来自核心业务系统的多个系统，也有内部渠道和外部渠道多个系统以及其他来源的多个系统;
数据集成操作区由开发平台支持;
数据交换区主要由数据交换平台支持;
数据存储区的数据主要分为两类，一类是结构化数据，一类是半结构化和非结构化数据。生产库是写数据库，存储的是结构化数据，查询库是读数据库，二者同构，之间采用OGG方式实现准实时同步，读写分离减轻了业务系统压力。内容管理平台用来存储半结构化和非结构化数据。
数据准备区，我们没有设立单独的主数据库对主数据实施集中管理，而是采用分而治之的策略，由各个系统管理各自的主数据。我们设置了ODS，用来存储通过ETL从各个业务系统抽取出来的、经过清洗、过滤、标准化和轻度整合的业务数据，为数据仓库供数。
数据加工区规划了数据仓库和数据集市，数据仓库的模型参考了TeraData FS-LDM。
数据管理区规划了设计平台，它是元数据管理和数据建模的工具，主要提供业务模型管理、数据模型管理、元数据管理、数据字典管理以及码表管理的功能，是元数据管理和数据标准化的核心所在。
数据应用区包含了若干个数据消费系统，比如决策分析域的多个系统，以及一些查询类的应用，比如：即席查询、标准和复杂报表、MIS;一些分析类的应用，比如：多维OLAP分析、风控、KPI绩效;一些管理类的应用，比如：高管驾驶舱、决策支持等。
设计清晰的数据架构可以为划分应用边界、明确数据间引用关系、定义系统间集成接口提供依据。大家可能发现了这个数据架构中并不涉及大数据和机器学习的内容。因为适合公司目前新核心建设、适合现有系统数据现状的架构才是最好的。我们公司现在的数据量在未来可预见的相当长的一段时间内，距离PB级或EB级还差得远，所以我们的架构设计更偏向于传统的OLTP交易型架构，辅以ODS、数据仓库来提供基本的数据分析功能。
下面我们分别从数据源区、数据准备区、存储区、加工区、交换区来深入地介绍一下数据架构规划。
数据源分为内部数据和外部数据。内部数据来自于核心业务系统和渠道接入系统。外部数据来自于银行、保险等金融同业或者是像保监会这样的政府监管部门，未来可能还有来自第三方机构、互联网的。保险产品和服务相对于银行产品来说，是一种弱需求的产品。我们没事儿的时候，可能会用手机银行或者微信银行查查账户余额、信用卡账单和理财什么的，但谁不会没事儿把保单拿出来看看。所以说保险公司与客户的交互不像银行那么频繁，不容易获得客户行为特征的数据，这就决定了我们以后可能会从第三方机构购买数据。阿里收购投资了很多公司，其中也不乏互联网公司，比如高德导航、虾米音乐等等。收购它们并不是这些公司的品牌价值有多么大，阿里真正想要得到的是这些公司多年来积累的用户行为特征及偏好的大数据，从中汲取制作大数据生态版图和综合应用的素材。所以，如果我们以后要做大数据的话，可能也会去购买数据。
数据源应该去关注一下它的非功能属性，它会对数据存储分布的设计起到参考作用。比如是基于数据接口的交换还是基于文件服务器的交换;全量还是增量;变动频率是极少、偶尔还是固定周期，像客户机构名称这类数据是很少变动的，像地址和联系电话可能是偶尔变动的，像定期结算收费就可能是按固定周期变动的;数据格式是结构化、半结构化还是非结构化;共享程度，主要取决于业务模块对数据的需求强度，如果按标准来区分的话，主数据是跨系统、相对静态稳定的，可以高度共享，那么它的共享程度为高，相对来说分布在特定业务领域的业务数据的共享程度就是低了。
目前ODS是把从业务数据抽取过来的数据进行清洗过滤、标准化以及轻度整合后存放。我们可以把ODS分为两半，左边是元数据增量层和标准增量层，它采用的是贴源设计，与生产库基本是同构的。右边是基础数据层和共性加工层，做轻度整合和进一步整合。所以整个ODS可以整合业务数据的全貌，并提供跨系统的细节查询，比如清单查询。经过ODS清洗过滤及标准化后的数据，提升了数据质量，然后为数据仓库提供数据。
简单介绍一下内部划分的四个功能层：ODS从各个系统抽取业务数据以后，会放到元数据增量层，然后经过清洗过滤标准化以后，放到标准增量层。对数据做了轻度整合就进入到基础数据层，共性加工层就是在基础数据层的基础上又提炼出一些共性指标，对数据做了进一步整合加工，只包含汇总数据。
ECM主要是用来存放半结构化和非结构化的数据，比如语音、影像、扫描件或者PDF和Word的文本文件。它主要对这些种类的数据进行处理、存储、捕获，分为前端的信息采集平台和后端的内容管理平台。如果以后要做大数据的话，可能还需要建立非结构化数据的元数据，并且将这些非结构化数据的元数据，经过一些结构化的处理技术，比如像文本摘要、打标签等等，与结构化数据产生关联，这样才能共同发挥作用。
数据仓库的内容比较多，现在还处于规划阶段，在这里我只简单分享一下数据模型。数据模型我们打算参考 TeraData FS-LDM。TeraData是全球最大的数据分析、数据仓库以及整合营销解决方案的供应商，它能够在一个集成的模型内支持银行、保险、证券三大行业的金融模型，内含十大主题域。我们在这个基础上，根据自身的业务特点和数据分类划分了八大主题域，每个主题域下面又细分有小主题。比如说“参与方”这个大主题，下面细分有人员、客户、代理人、法人四个小主题，其中，客户小主题又包含客户的基本信息、联系信息、健康信息、财务信息、资产信息等具体内容。
这是我们在数据交换区构建的数据交换平台，因为我们现有核心系统存在着一些问题，比如说核心系统内部和各个系统之间，以及核心与外部系统之间的数据集成、数据同步、数据共享困难;系统耦合度比较高，A系统的表结构发生变化，B系统程序也得跟着改;dblink使用泛滥，性能开销大、存在数据安全隐患。
为了解决以上的问题，我们建设了数据交换平台，并规定了建设目标。第一，提供统一的数据集成规范、数据获取与分发、数据交换与共享、数据监控;第二，提高数据加工、数据流转效率，加快数据在系统内、系统间的快速移动;第三，改变传统的“多对多交换模式”，实现“一源多目标”的数据更新。
我们还有一个设想就是以“元数据”驱动DEP中的ETL过程，在ETL中嵌入数据质量检查与监控;将元数据管理应贯穿于数据流动的全过程。
数据交换平台的功能定位是让它作为数据交换枢纽，通过一定的“数据获取及分发”策略、作业调度策略，结合内置于各系统内的数据交换区，实现核心业务系统内各子系统、核心业务系统与外围各系统之间的数据交换、数据同步、数据共享，为各个OLTP和OLAP系统提供数据接口服务或数据文件交换服务。
各系统要与数据交换平台做一定的配合，也就是在系统内部设立数据交换区或文件交换区。比如在交换区内提供接口表，我能为别人提供什么样的数据?我需要消费什么样的数据。如果是文件交换服务，就需要提供符合一定数据格式的文件。
大家可能会问什么样的东西走ESB企业服务总线，什么样的东西走DEP数据交换平台?举个例子，如果想实现对等的交易，A系统的交易必须等待B系统返回结果之后，才能继续处理，像这种对实时性要求比较高的就走ESB，但是它的报文不能太大，我们规定是控制在500K之内。如果要是对实时性要求不高、可以准时传送、数据量又比较大，就走数据交换平台。
我觉得数据交换平台更像是数据服务总线，而ESB是是企业服务总线，他们一个是实现应用服务的虚拟化，一个是实现数据服务的虚拟化，一个提供的是应用服务的连通性，一个提供的是数据服务的连通性。ESB可以让处于不同设备、使用不同协议的系统连起来，而数据交换平台可以基于数据库或者基于文件服务器，通过提供数据服务使各系统连起来。
我们还提出一个设想就是要建立IP(集成平台)。ESP提供联机实时、小数据量的数据服务，DEP提供批量、大数据量、准实时的数据服务，而MP提供异步的消息服务，三位一体地构成一个集成平台来提供应用连通性服务和数据连通性服务。
下面介绍下我们的新核心项目在数据治理以及标准化过程中分阶段实施的进展。
说到数据治理，我们在14年的时候曾经请恩核公司做过技术咨询，在过程中应用了恩核提供的方法论，取得了不错的效果。我认为要做好数据治理，首先要选定一套行之有效的方法论，再建立起一套原则、处理流程和数据组织，如果再配上一个得心应手的工具，应该会达到事半功倍的效果。
为什么现在越来越多的公司都比以往更加重视数据治理工作?因为数据治理、元数据管理及其中的数据标准化是实现商业智能的重要环节，如果数据不一致、数据质量达不到要求，你是无法进行数据集成和整合的，也就无法进行数据分析和数据挖掘，更谈不上商业智能了。所以说数据治理的重要性在被逐渐提高。
数据治理的核心是元数据管理，而元数据管理的核心就是数据标准化，我们说元数据是Data about Data，它是描述数据的数据，其实元数据就是定义数据项的框架和标杆，它除了包括数据名称、数据类型等基本信息以外，还包括数据归属、取值范围、校验规则、数据来源等这些扩展信息。元数据管理的应用领域是十分广泛的，比如模型设计、数据存储和交换等。
我们现有的核心系统中存在很多数据质量问题，比如不符合业务技术规则、数据格式错误、多套重复编码等。我们现有的码表里面非常冗余，因为我们现在的系统是由外包人员来维护的，他们的流动性比较大，有些人为了图方便，可能来一个新人就订一套新的编码项。我们在梳理时候发现，仅销售渠道方式的编码方法就有6套重复的。
我们在数据治理的时候也发现了很多问题：命名规则不统一，英文、汉语拼音混在一起，有的缩写根本无法从字面去理解它的准确含义。我刚来公司的时候，JYX、HYX、XPS、SOS这些都不知道什么意思，后来是老员工告诉我，JYX是借意险、HYX是航意险、XPS是学平险、SOS我刚开始以为是救命呢，后来才知道是境外救援险;数据类型不统一，同一个字段在不同表里的数据类型、长度不一样，这会给数据交换造成很大的隐患;相似表、空字段太多，且大多都废弃不用了，现在总表是2500张，而在用的数据表只有1400多张，基本上有将近40%的表都是空置的;模型扩展性非常差，新增业务的时候通常要新增表;数据结构变更难以评估对应用造成的影响。
主数据管理这块重点需要关注：哪些系统是产生主数据的系统?哪些系统是消费主数据的系统?主数据是怎么获取、怎么分发的?
我们的主数据管理没有采用集中管理，而是由各系统分别管理。客户信息系统、统一用户管理系统，设计平台、产品工厂分别维护客户信息、用户机构权限数据、码表数据、产品套餐险种数据。拿客户信息系统来说，通过客户信息五要素：姓名、性别、出生日期、证件类型、证件号码去识别客户信息，通过覆盖、归并、整合、追加等方法生成客户的黄金记录，最后为客户分配唯一标识。
我们以客户信息系统为例讲一下主数据的清洗。因为客户信息数据是通过业务系统调用接口进入到系统中的，出于用户体检的考虑，我们可能不会对接口控制得那么严格。但是放松控制的结果会使脏数据进入系统，所以说数据质量的提升，其根本在于通过规章制度、绩效考核来规范和约束一线录单人员，在源头就将高质量的数据录入系统。
这是我们针对个人客户信息提出的一些清洗规则，这些规则基本上都是基于数据格式的清洗，而不是针对数据文本内容的清洗。因为针对数据具体内容的清洗是无能为力的，有的厂商说我可以提供中国邮政大字典，把地址进行清洗，但如果内容都是一些“的的的了了了”，根本无法清洗。所以IT技术只能作为一种辅助手段，它可以做数据质量检查、也可以给业务部门提供数据质量报告，但是没有办法从根本上解决数据质量问题，也没有办法彻底修复数据。所以，必须让数据质量与外包录入人员的绩效挂钩，才能从根本上提升数据质量。
下面我们介绍下数据标准化应用。上图是新核心单证系统业务模型，蓝色部分是业务实体类对象，黄色部分是业务操作类对象。业务实体类对象通常是指单证的定义、单证的明细、单证的轨迹等等。业务操作类对象通常是指单证的入库、发放、单证的回销、回退等等。业务操作类对象比较像Java类，有成员变量以及成员操作。怎么将业务模型转化为数据模型呢?具体的方法有两种，一种是大家比较熟悉的ER模型分析方法，它是面向结构的，优点是比较容易向底层物理模型转换，缺点是不够灵活，抽象和复用程度不够，如果你要是全用这种方法来设计数据模型，那么以后就只能新增一个业务增加一个表。第二种是对象类模型分析方法，它是面向对象的，优点是能够很好地实现抽象和复用，缺点是不好物理落地，所以要使用对象类模型分析方法将业务模型转化为数据模型，需要数据建模人员具备一定的设计经验、知识背景或者有一定的模型设计规范来指导他完成。
这是新核心渠道接入数据平台的数据模型，也是新核心数据治理与标准化产物综合性应用的体现。这个项目于去年11月份成功上线同时也获得了一些奖项，它的整体设计过程体现出了我们的领域设计思想。他的数据库符合《数据库数据规范》、模型符合《数据模型设计规范》，它的所有产物都应用了《新核心标准化字典》。这是我们进行数据治理的一个成果。
这里主要讲一个“业务数据样例”的概念。我们将业务场景与数据样本相结合，编制了业务数据样例，它关注的是实际发生了的业务活动将导致数据模型中的哪些内容发生变化。这里以“签单请求”的业务场景为例，给出了信息流数据在各个步骤中是如何通过数据模型来表达的。它可以用来指导开发人员正确理解和使用数据模型，指导测试人员编写测试用例。
接下来为大家展示一下数据标准化的其他成果。
这是老核心数据治理的产物，为了配合新核心的建设，我们对老核心的数据对象及重要资源进行了整理，上图展现的是表和字段的整理。数据表的整理有表的名称、所属模块、表的类型、活跃程度、使用场景以及表间关系。数据字段的整理有字段含义、标准化名称、数据类型、长度精度、码表取值、业务规则、技术规则以及字段来源。重点提一下字段来源，同一个字段在不同表中的来源可能是不同的，有可能是前台输入的，也有可能是后台系统插入的，还有可能是通过规则公式计算汇总得到的。
这是我们标准化的一个最重要的产物——新核心标准化字典之基础词汇，同时它还是汉译英的基准和标杆。从分词标准化实践的经验来看，最好是一个人做全程，并且要有一个好的工具来支持。分词的主观成分较大，主要取决于分词人的业务知识、工作经验、常识以及词汇量。大家可能从图上看到我们的这些产物都是在用office文档来维护的，这是因为我们的元数据管理工具(设计平台)正在根据试用意见进行改造，在正式投入使用前，我们会采用一些辅助手段，比如用eclipse编写一些小程序去检查字典的覆盖度、正确度、冗余度是否符合要求。
分词过程有一些细节需要注意，比如术语拆分的断点和粒度，在汉译英过程中英文词汇的选取、同义词的处理、词汇多对多的问题，副词、介词、数量词的提取规范及表示法，全称或缩写的选择以及缩写程度的把握，单体词或复合词的选取，名称超长后的缩短处理等等。
基础词汇字典的用途十分广泛。在对表、字段等数据对象进行标准化命名的同时，我们对新核心各子系统的名称及重要资源都进行了标准化。比如说发布在ESB上的原子服务、销管系统的岗位编码，等等所有需要标准化的地方都用到了这本字典。现在这本字典可以做到英译汉几乎一字不差。
这是对码表的整合，它也是数据标准化的一项重要内容。我们从业务角度对老核心码表进行了整合，分为公共编码和私有编码。像证件类型、婚姻状况、性别这种通用性很强的，属于公共编码;像销售渠道、保单类型、保单状态这种业务含义很强的属于私有编码。我们根据保险标准委员会制定的国家金融行业标准(保险通用业务代码集)，对老核心公共编码进行了替换和扩充。
私有编码比较特殊，每一个保险公司都有自己的私有编码。由于每个公司的发展战略和业务侧重点不同，私有编码的数量和取值范围在信息化落地时会存在较大差异。因此，我们在沿用老核心的基础上进行了整合与标准化，合并同类项，消除冗余。
这是我们从技术角度制定的码表规范，包括编码项的准入标准、命名规范、取值编码原则、码表结构、分发策略等内容。我们通过设计平台定义和维护码表，通过数据交换平台将它们分发到各个业务系统。码表规范会使显示或打印数据更加准确，新核心各子系统之间无需转码，这有助于提升系统性能，也便于开发运维人员理解。
这是数据治理与标准化的两大标志性产物，一个是数据库设计规范，一个是数据模型设计规范。数据库设计主要是用来指导运维人员在数据库搭建和参数配置的时候对数据库性能进行初步优化。数据模型设计规范用来指导建模人员将一些典型的业务场景或业务模式通过规范化的数据模型来表达，类似于JAVA的设计模式。这样我们就可以避免设计人员按照自己的设计经验或技能水平自由发挥，让他们设计出来的产物具有一定的规范性，再经过1-2次评审就可以交付项目组开发使用了。
这是主数据管理方案，主要是对主数据管理的概念、方法论、关键技术及当前主数据的主流应用进行了阐述。
我们做新系统少不了数据迁移，数据迁移必然会涉及到对老模型分析、新模型设计以及新老模型之间的映射和转码等问题，所以迁移之前要做好充分准备。迁移总体方案，从迁移准备、实施步骤、关键点控制、应急处理等几个方面进行了阐述。
从技术层面来说，数据治理可以帮助我们提升数据质量，提升数据的一致性、准确性和完整性;使数据的生命期更加清晰，能够很好地发现数据的产生、变迁;使系统运行更加平稳，一定程度上提升了系统性能。
从业务角度来说，当IT系统发展到一定阶段的时候，有效的数据治理可以使企业内的数据资源变为战略资产;减少运营成本，降低运营风险;支持业务运营和高层决策;增强应对监管部门审计性、合规性要求，最终数据价值的发挥将回馈于业务，体现为企业利润的增加。
我个人觉得数据治理不仅应该贯穿于项目的始终，更应该贯穿于整个企业生命期的始终。数据治理是一项很长远的工作，我们任重而道远。
