数据融合之数据治理

在《从单体集成到平台融合》一文中我们提到了数据融合。数据融合的需求来自于应用融合，应用融合的支撑在于平台，应用融合的方式之一是微服务架构，微服务设计的关键在于数据，数据的质量保证是良好的数据治理。所以说到底数据融合关注的依然是数据治理。但数据融合的数据治理就不像单体系统的数据治理，也不是单体集成的数据治理，而是企业内全局数据的数据治理。
我们说过，人才和数据是企业的核心资产。没有数据，就像无米下锅，没有高质量的数据，就像大米中有很多沙子，虽然能填饱肚子，但吃起来的味道绝不是你希望的那样。为实现良好的数据质量保证，数据治理是不得不考虑的课题。

一、 数据融合

微服务虽然彼此独立，但每个微服务也只是棋盘中的棋子，各有各的角色和职责，都需要在棋手的控制之下。数据就是棋手心中的战略，每个棋子前进后退纵横捭阖的步伐。东一块西一堆的数据，就无法构建整个棋局。所以，数据要集成、要融合、要在控制之下。
单体系统之间的数据不一致、数据冗余、数据缺失等往往是通过数据集成方式解决，比如传统的数据仓库，或者现在有个挺热的概念数据湖。但数据仓库、数据湖等有点后知后觉，数据集成天生就有缺陷，难以实现数据的实时处理。数据湖方法更有点眉毛胡子一把抓，仅仅从数据入手而不考虑业务应用和平台架构等，很可能成为数据沼泽。技术的发展带来新的方法和思想，也创新新的方法和思想。微服务意在重构，通过服务重构来支撑业务流程的优化和敏捷，同时微服务重构也是数据重构的过程，微服务重构的基础是数据的重构。这正好是一个数据融合的契机。
数据融合是在企业内根据数据治理质量、标准、安全等的要求实现数据的统一管控，以期实现企业内唯一可信的数据来源。

二、 数据价值

数据的价值在于怎么去使用它，不是怎么去存储它。存储起来不使用的数据永远没有价值。因此我们认为不管数据仓库、数据湖、大数据平台或其他数据平台，其建设目的应该是提供高质量、高价值的数据。这些高质量、高价值的数据是应用于业务，实现利润。这些数据需要在业务应用之间流转，以及用于快速的创新和构建新的业务应用，支持新的业务需求。
并不是所有的数据都有同样的价值，所以数据要进行分层，分主次，我们提出用主数据思想来设计微服务应用，就是基于数据的不同价值、不同层次，和业务应用流程进行关联、融合，更方便的抓住主要的内容，实现最大数据价值。

三、 数据治理思想

数据治理不在于是否有数据治理平台，而在于是否有数据治理思想。有数据治理思想的人，即便没有数据治理平台，也可以在数据产生流转的过程中实现数据治理；没有数据治理思想的人，即便给他再好的数据治理平台、再好的数据治理工具，也做不好数据治理。胸中有丘壑，笔下自华章。无论数据仓库、大数据平台或者数据湖，都离不开数据治理。
数据治理是通过相应的标准、规范、流程和方法等，确保数据统一管理、高效运行，并在数据使用过程中充分发挥数据价值的过程。我们说了数据治理的目的是实现唯一可信数据来源。所有的标准、规范、流程、方法等都应该围绕这一目的来实现。

四、 数据治理的内容

数据治理的内容很多，不同企业关注的数据价值不同，侧重可能也会不同。有侧重数据标准的，有侧重元数据管理的，或者关注数据安全的等等。但我们认为数据治理最重要的是关注数据价值，深刻理解数据治理思想和目的，工具、平台、组件仅是辅助，可以帮助我们快速实现数据治理。
我们认为数据治理内容可以关注这些方面：数据采集、数据架构、数据标准、数据质量、数据安全、元数据、主数据等，而主数据是重点。

（一） 数据采集、生成
我们强调关注数据的来源和数据的生成。我们建议在数据的起点就考虑数据治理，以始为终，保障数据流转过程中的数据质量。

（二） 数据标准
数据标准定义并不容易，这是数据治理面临的第一个难点。很多公司数据标准的定义都是在数据中心，但我们认为这并不一定是合理的。数据中心不一定对业务了解，或者受限于职责范围，只是在数据层面的一些处理。数据标准的定义应该来自于业务数据的梳理和优化。这也是我们认为微服务构建过程中考虑重构数据、在数据融合的过程中实现数据治理的原因之一。
数据标准也不是一成不变的。不合理的数据标准就是阻碍，因此在业务过程中要适时评估数据标准，对于不合适的标准要及时更新。

（三） 数据架构
数据架构我们认为是企业内数据之间的关系。先摒除一切管理流程思维，仅仅考虑业务数据之间的关系，定义出数据层次、主数据、数据架构。然后再考虑流程和管理及相关数据。

（四） 数据安全
安全永远是重中之重！数据的访问和使用可能需要考虑数据的安全开放级别，哪些数据可以开放到什么程度、范围，在数据的访问使用过程中需要进行安全管控和验证。

数据安全分级 数据的安全分级可以根据业务需要进行划分，比如绝密、机密、密级或普通等。比如涉及某项关键业务的数据或关键客户的数据可能是机密级的，只有获得授权的人才能访问。而大部分客户的电话、身份证号可能是密级的；而经过脱敏的数据就是普通级数据。安全级别也会随着时间的变化而降低，可以称为数据安全降级或数据解密。

存储 不同级别的数据存储要求可能是不一样的。但从微服务架构的角度来说，数据根据业务微服务和业务应用来分开存放，可能是不同的库、不同的存储介质，通过服务接口对外提供数据服务。

备份 历史数据和用于统计分析的数据需要备份到数仓，或者大数据平台或者其他数据存储。数据可能会持续的备份，这些数据会根据算法和规则持续的运算，持续更新数据中台服务的数据，在其他应用需要这些中台服务的数据时，可以实时获取，而不是在使用数据时启动查询、运算，可以极大的降低延迟。这个过程需要满足数据安全的要求。

数据安全审计 数据的生成、流转、使用过程是否符合数据安全要求，可能需要一些管理审计工作。可以通过数据流程详细日志来生成数据安全审计报告。

（五） 数据使用
数据的价值在于怎么去使用它。用好数据是很重要的。数据不能不用，也不能滥用，既要考虑数据安全问题，保护客户隐私，也要考虑发挥数据的最大价值，使产生的利润最大化。

数据安全传输 数据不能只存储不用，要使用就涉及数据的传输。让数据流转起来才能发挥数据的价值。但数据传输过程往往也是最容易放松安全防护的，数据往往在传输的过程中被窃取。因此数据的安全传输保障机制需要考虑，比如敏感数据加密传输、数字签名等。

数据脱敏 一些敏感的数据需要经过数据脱敏处理才能在一些场景中使用。比如客户的姓名、身份证号、电话号码、联系地址等，涉及客户的隐私，不能随意公开。在使用这些数据之前，需要做一些处理。比如根据规则数据做一些转换，或者直接通过数据脱敏平台或服务实现数据脱敏。对于相同的字段，脱敏规则可能需要保持一致，以避免在做数据关联时关联规则失效。

（六） 数据质量
数据高质量是我们追求的目标，也是做数据治理的目的，以确保数据的真实性、准确性、连续性、完整性和及时性等。不管有多少应用、多少系统，不管数据存储在哪里，也不管是集中存储或者分开存储，最终我们希望达到数据的唯一可信来源。数据不一致是目前很严重的问题，经常从不同口径统计的数据不一致，难以给客户解释。因此需要考虑实现数据的唯一可信来源。比如客户的数据可以从客户中心对所有用到客户数据的业务提供，订单数据从订单中心对所有相关业务应用开放，而数据字典等基础数据则更需要由统一的数据字典服务提供，不会导致不同的系统或应用数据不一致。令出一门，方能有令而行，令行禁止。至于说数据源（令）有错，那超出了本文讨论的范围。

（七） 元数据管理
元数据不是数据治理的核心，数据标准有了，数据有了，数据定义有了，元数据可以自动生成并管理起来。大多数时候也就是用于查询验证。不需要花太多精力。元数据管理不是重点。

（八） 主数据
在定义数据架构是，主数据是重点，是企业的高价值数据。通常在各个应用间流转，是全局数据。比如客户、账户、产品等。我们认为重要的是要有主数据的思想，分清主次，而不要眉毛胡子一把抓。主数据模型通常可以参考通用数据模型。

五、 数据治理原则

原则通常也是相对的，不同的场景可能要求不一样，不过通常需要考虑易用性、全覆盖、有侧重、持续性、有效性、分步实施等。
易用性要考虑数据治理方法简单好用、易理解。
全覆盖要考虑数据治理应该覆盖数据的全生命周期，覆盖业务经营、风险管理和内部控制流程中的全部数据，覆盖内部数据和外部数据，覆盖监管数据，覆盖所有分支机构和附属机构等。
有侧重则要求数据有分类、有分级，业务数据是关键数据，管理流程数据相对次要，
持续性要考虑到数据治理是一个长期的过程，很可能是一个默默无闻的岗位，要考虑长效机制和激励措施。
有效性要求数据治理应当推动数据真实准确客观反映实际业务数据情况，并有效应用于经营管理。
分步实施则考虑分解数据治理过程和难度，逐步实现数据治理能力。

六、 数据治理步骤

我们谈数据融合之数据治理，融合是需要一点点渗透的，而微服务的设计实现也不是一蹴而就的，所以我们认为可以先实现局部数据治理，关注数据在数据采集、数据生成等节点的标准化、安全和数据质量等。大部分企业其实都有一些数据治理的标准、规范、工具或平台，可以基于这些标准、规范、工具或平台做相应的调整实现局部数据治理。而后逐步推广，考虑全局数据治理。当然这是一个持续的过程，也可能需要不断的调整，比如客户的数据，或模型，随着融合的系统越来越多，模型或数据可能需要调整以适应更通用的需求。

七、 数据中台

居安思危，思则有备，有备无患。我们做数据治理并不是为了数据治理，而是为了更快的构建数据中台服务能力，更好的支持业务创新，让数据持续的流转起来，促进数据价值更大实现。

来源：技术思维创新

作者：汪照辉、王作敬