本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014,关注中国数据库技术大会公众号）现场演讲嘉宾种磊老师分享内容整理而成。录音整理及文字编辑IT168@田晓旭@老鱼。 html

▲农银人寿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系统发展到必定阶段的时候，有效的数据治理可使企业内的数据资源变为战略资产;减小运营成本，下降运营风险;支持业务运营和高层决策;加强应对监管部门审计性、合规性要求，最终数据价值的发挥将回馈于业务，体现为企业利润的增长。

　　我我的以为数据治理不只应该贯穿于项目的始终，更应该贯穿于整个企业生命期的始终。数据治理是一项很长远的工做，咱们任重而道远。

来自 “ ITPUB博客 ” ，连接：//viewspace-2154035/，如需转载，请注明出处，不然将追究法律责任。