数据服务化——打通企业数据应用的最后一公里

转载本文需注明出处：微信公众号EAWorld，违者必究。

引言：

大量企业积累了海量数据，形成了丰富的数据资产金矿，在有价值的数据和数据产生价值之间仍然存在最后一公里的跨越；同时面对全球化的API经济的冲击，服务化已经成为各行各业的趋势诉求，如何将企业大量的数据资产金矿通过服务化的形式进行规整、盘活，已经成为关系企业长远发展的关键。

本文结合企业数据服务化落地实际案例，分享如何打造闭环的企业数据服务共享平台，进而让有价值的数据产生数据价值，打通数据应用的最后一公里。

目录：

1、“服务化”已成为数字经济时代的主旋律

2、如何实现面向服务共享的大数据应用平台

3、面向服务共享大数据应用平台核心架构

我们都知道人工智能目前非常的火热，问大家一个问题，人工智能的三要素是什么？是算力、算法、数据！正是由于这三者都具备了，人工智能在最近几年开始有了突破性的发展。

“数据”作为三要素之一，同样也是本文的主题。我今天为大家分享的题目是：“数据服务化-打通数据应用的最后一公里”，我们一起聊聊如何通过服务化的方式来体现数据的价值。

我们都知道，随着数字化的转型，多数企业积累了海量数据，形成了丰富的数据资产金矿，但在有价值的数据和数据产生价值之间仍然存在最后一公里的跨越；每次谈到最后一公里，我就想起了断头路，打通非常难，通常要涉及多个部门的密切配合才能搞定；但是断头路一旦打通，带来的效果还是非常明显的。

1. “服务化”已成为数字经济时代的主旋律

同时面对全球化的API经济的冲击，服务化已经成为各行各业的趋势诉求，如何将企业大量的数据资产金矿通过服务化的形式进行规整、盘活，已经成为关系企业长远发展的关键。

“服务化”已成为数字经济时代的主旋律，接下来我们先看一组数据：

总量上来看，近年来中国数字经济规模保持快速增长，占GDP比重持续上升。

2018年我国数字经济总量达到31.3万亿元，占GDP比重超过三分之一；2018年数字经济发展对GDP增长的贡献率达到68%，有超过三分之二的增长来自于数据经济；超越部分发达国家水平，成为带动我国国民经济发展的核心关键力量。

据预测，到2019年我国数字经济总体规模或将接近36万亿元。

按照这个趋势，我们也可以预见，未来可能只有一种主题经济，那就是数字化经济。

数字化经济下，企业业务形态有哪些变化？企业应用有哪些特征那？

首先在业务形态来看，一方面企业从专业经营走向混业经营，比如银行不再仅仅是一家专业金融公司（举例：建行从金融到住房、法律、宗教等）;另一方面，从个体走向生态，商业模式发生着变化。比如通过京东、蚂蚁金服也可以享受更多的服务。

企业生意模式也发生重大改变，“我们看到最大变革是，基于场景的快速的业务创新，business moment，这既是一个变革，也是一个非常大的挑战。”

为了适应商业的变化，基于场景的快速创新，业务的这种变化需要相应的IT能力去支撑。

因此，企业交付的IT应用有很大变化，一是应用交付速度加快，其次是企业应用粒度变小而散，三是企业应用的API化。通过开放API，去对接生态，融入更大的生态圈。

接下来我们看一则Google收购的案例：

2016下半年，谷歌的一笔重量级收购吸引了大众的眼球，斥资6.5亿美元收购API管理公司APIGee。

这是一家成立于2004年，总部位于美国圣何塞的公司；主要业务是为企业提供API产品和技术，帮助他们开发基于API的应用程序。

这一收购也使得谷歌2018、2019年连续两年获得Gartner，API全生命周期管理领域领导者厂商地位。

Apigee公司的核心业务是帮助企业把其服务API化（在今天的数字世界里，API 是大多数活动的基本组成部分）。

将合作伙伴的应用、客户的应用、生态上下游的、甚至包括IOT进行连接；通过API打造业务生态的例子，已经随处可见，微信APP，支付宝，通过聚合多达上百种的服务，已经成为事实上的流量入口；未来，你的衣服、汽车、食物都可以有API，进行API化。

Gartner已经将API定义为构建数字化平台的最佳实践；就像人工智能三要素一样，API化的本质是需要数据的支撑，我们需要回归关注数据，回归数据应用价值本身。

但在传统信息系统架构模式下，因为各种原因，我们建设了一个个“孤岛”式应用；为了解决这些孤岛问题，企业又花费大量的时间和成本去修改、或者新开发、或者做集成；企业投入过多的精力专注于ETL、ESB、Hadoop等各种技术，这样一来企业最大的损失是时间机会成本；结果是我们最有用的数据并没有发挥核心资产的作用。

回归到数据本身，我们更应该关注，我们有哪些核心资产？这些资产在哪里？别人需要什么资产？如何提供出去？

事实上，目前我们接触的很多企业数据的现状和应用的现状并不乐观，存在很多的不足，这些不足，不是简单的说企业做的不好，这些不足都是由于发展导致的或者业务复杂导致的。

有些企业，并不知道自己的核心数据资产有哪些？在哪里？有些企业，有核心数据资产，但是质量非常一般？有些企业，有一些高质量的数据，但是如何开发？现在业务和技术的协作也非常弱；另外，对于当前现状，业务更多的在讨论如何进行海量数据的存储、计算等等，而鲜有考虑怎么去建立数据应用的体系。

因此，我们讲，数据时代，我们需要新一代的数据应用平台，需要面向数据服务共享的数据应用平台。那什么是面向服务共享的数据应用平台？

企业数据的处理应由离散工具向数据服务转型；清晰的回答，企业有哪些数据资产，能对外提供哪些数字资产，如何对外提供，如何消费，如何保证数据资产的监控域安全？

数据服务共享平台定位于：企业数据资源“纵向贯通”、“横向互联”的共享通道，使其成为企业、组织、部门的数据工厂。

用于解决数据的服务资产化，数据的服务开发，数据的服务消费等系列问题。

不仅仅成为数据工厂，同时希望这样一个平台定位于一个数据的运营中心，成为企业的心脏。

在业务模式上，期望通过自助的方式来实现数据业务，打破原来业务-技术-业务的模式；实现数据更大的开放度。

提供四个统一：统一数据服务目录（数据资产可视化）、统一数据共享通道（数据共享的高速公路）、统一数据交换标准、统一数据运行监控与安全。

通过数据服务平台，降低业务对技术依赖，充分发挥业务创新潜能，打造企业级的数据资产的运营能力。

2.如何实现面向服务共享的大数据应用平台

如何实现面向服务共享的大数据应用平台？

先给大家分享我们服务的两个数据服务共享平台案例，一个是政务领域，一个是保险领域。

我们先看政务领域的例子，这个与大家的日常生活相对比较紧密：

目前各地方政府都在大力推进“一网通办”，一网受理，只跑一次，一次办成；需要打通各部委之间的数据，让数据多跑路让群众少跑腿。

场景1：一寸、两寸、45cm×45cm、蓝底、白底、红底……不同证件、申请表格，照片规格五花八门，每次照一张？想想都头大。

只要在政府部门拍过照片，就可以按需得到多种尺寸、背景的标准照片。

市民到政府办事有280+个事项需要提供个人照片，将其在政府留存的照片数据归集到他的个人档案中，再办事情就可以直接调用。

看是一个非常简单的功能，在政务领域打通需要涉及几十个系统交互才可以。

场景2：想开饭店？要办理营业执照、食品经营许可、消防检查、酒类零售、环评备案……跑五六个部门，提交31份材料，接受3个部门的现场核查。跑6次办事窗口，核查要3次，等审批要58天。

现在所需材料只要12份，减少61.3%，核查只要1次，审批时间缩短82.8%，10天，只跑一次窗口，就回家等好消息吧。

原来：每个政务部门都有自己的信息系统，如果不打通，就使得企业向A部门提交的材料，到B部门要再提交一次。公民的户籍、教育、就业、医疗、婚姻等基本信息，也处在分散的状态，给群众办事带来麻烦。

现在：正是由于打通了政府的各个部门的数据、外部的政务数据以及来自社会的非政务数据，形成政务领域的四大库：人口库、法人库、空间地理库、电子证照库。

才能做到让数据多跑路让群众少跑腿，为自然人、法人、企业提供透明优质的公共服务。

因此，我们在政务数据服务应用平台中，探索建立了以目录为核心的数据资源管理新模式。

数据不等同于数据资产，数据资产是唯一的能为业务产生价值的数据，需要让所有的人都知道数据资产目录在哪里。不能因为数据安全，就不让大家知道企业有什么数据。没有共享和开放，数据没有办法流动起来，没有流动的话数据的价值产生的速度就会非常慢。

对于同一堆数据，不同业务部门所关注的数据指标可能完全不同，按照分类、主题、应用等多个维度对数据目录进行分类管理、识别、定位和共享。

通过政务信息资源目录帮助大数据中心建立跨委办局全市统一的数据资源管理体系，与国家级以及区县级数据资源平台对接。

既然提到了数据安全，我们必须要面对与解决。

在政务领域，不同的数据归属不同的部门管理，对于数据的获取需要审批和授权。

基于此，我们提出了“三清单”为抓手，建立需求清单、责任清单、负面清单进行管理与维护。使得数据在安全的前提下让数据流动起来，只有流动的数据才会产生价值，创造效益。

以三清单为抓手进行数据价值融合；通过一套完整的线下线上流程，将数据安全的开放出来。

• 需求清单：根据业务应用场景，由需求方提出需求清单，描述需要获取的业务数据
• 责任清单：根据需求清单定义的数据，定位分别由哪些部门管理，然后委派给不同的责任部门提供需求清单需要的数据，由不同的部委对提供的数据进行责任管理
• 负面清单：根据数据的部门来源，及法律法规，对无法提供的数据进行管理；避免出现泄密等情况

对于被三清单审批过的数据资源目录，可以安全的发布到共享交换平台；最终实现了数据协同、自助数据、数据服务化、数据工作台的能力。

这是保险业的一个情况，保险业，应该说属于轻资产的行业，他们面临的问题主要来自于自身发展导致的：

根据保险行业发展趋势，目前保险交易已经呈现高频化、碎片化、场景化等特点，对系统的处理能力、容量、业务连续性、需求响应速度、运维响应速度提出了更高的要求。

但在保险行业，往往一个险种就是一个分子公司，分子公司会独立的建立自己的客户，自己的渠道以及所有围绕服务的资源，大家可以看这个胶片，左边的业务应用（渠道），明显各自是独立的，各自有自己的官网、app等等。

独立发展到今天，他们碰到的问题是，共享与融合发展的问题，例如：某客是产险的客户，他可能也会是健康险的客户，或者过3年后他就是健康险的客户，但独立经营的现状是没法很好的是做这方面的融合的。造成非常差的客户体验。

因此我们帮助企业的第一步工作就是理解客户，可以看到针对不同的险种、不同的分/子公司都有个人的、家庭的、团体的客户等等，对他们的所有关联信息（包括基本信息、保单信息、投保信息、理赔信息）搞清楚，最后建立基于集团级别的客户标准模型，并做渠道上的整合。

为集团的多端系统提供统一的客户数据供数，优化客户数据供给；为服务、行销、决策、风控提供依据。

那么，在建立一个标准的、实时共享的保险业大数据平台时，它的逻辑也非常简单。对它来讲，需要了解自身到底有多少资产，要能条目化、目录化；可以通过平台做自助式开发；针对这些服务怎么运营和监控；以及服务消费。其实这四方面一点也不复杂，复杂的是自己的业务本身。

针对上面两个案例的分享，我们总结一下，为了提升数据的业务价值，我们需要：

• 数据目录化：核心是数据的资产化，通过将源数据、前置区、共享区的数据通过，Metadata api抽取，形成数据目录，挖掘有价值的数据形成资产
• 目录服务化：形成Data api，将前置区、共享区的数据，通过数据服务装配/开发，形成具体的服务，可以是实时数据服务、批量数据服务
• 服务开放化：形成Service API，通过数据服务申请、审批，数据服务运维监控，将数据服务的能力开放给业务部门，合作patener等

整个服务化的流程相对比较清晰，主要分为数据服务提供者，数据服务消费者：

• 数据服务提供者：完成数据接入，服务管理，消费方管理、运行监控能力
• 数据服务消费者：通过服务申请来完成对服务的消费使用；并提供权限范围内的数据浏览与查看

数据目录化主要由两部分组成：

• 元数据自动采集：基于元数据驱动支持在数据源、前置区、共享区、消费方四个区域配置数据库资源，实现数据库资源自动采集、预览，为后续数据服务化与数据共享打下基础。
• 数据分类管理：将数据资产按照分类、主题、应用等多个层次对数据进行分类管理、识别、定位和共享。

通过元数据驱动来实现数据目录化，最终实现了让用数据的人知道可以提供什么数据。

目录服务化：最核心的是支持将数据一键/便携化发布为API服务，降低服务的开发成本；支持结构化数据、非结构化数据、文件数据的共享发布；支持单表、结果集等形式的实时接口服务发布；支持批量数据发布；支持发布订阅等多种模式。

关于服务化的形式，有些人认为只有封装成API才算是，我觉得不是，因为数据跟功能不同，其分析的灵活性和数据维度的无限性决定了你不可能封装出所有的数据服务，因此这里的服务应该是广义的服务，只要我提供的数据能够被共享使用，在前端被业务人员或者其他机器快速方便的使用或调用，这就是数据的服务化。

服务开放化完成统一运营企业数据的顶层设计，包括：

• 统一的数据共享通道：建立公司统一的纵向数据共享通道，提供跨系统、跨单位、跨区域的数据集成、交换、分发、共享机制。
• 统一的数据交换标准：定义统一的交换标准和规范，并在实施过程中，积累更多符合自身发展的、可复制的最佳实践。
• 统一调度管理：提供灵活的、多角度的模型作业调度机制，减轻运维管理工作量，实现运维自动化。
• 统一的数据运行监控和安全保障体系：提供数据服务发布、访问授权和运行监控的统一管理；从技术和管理两方面提供事前预防、事中控制和事后追溯能力。

最终帮助企业实现了数据资产的全景视角，并实现了全数据链路的跟踪；可以从多视角，比如，数据来源，资源分布，资源使用等维度来查看；对发布共享的数据资产，可以进行适当的排名，进而激励更多的数据产生价值。

借助于血缘分析、影响分析等来实现自助式数据问题跟踪：

• 消费方在应用过程中，发现数据问题
• 消费方通过平台对实体进行血缘分析，发现与其相关的上游数据
• 通过血缘分析定位可能的问题路径，分析并解决相关数据问题

3.面向服务共享大数据应用平台核心架构

整个平台的架构相对比较清晰，包括数据服务目录、数据服务开发、数据服务调度、数据服务共享与发布、数据服务的治理。

整个平台的应用架构，从数据的维度来切分：

• 资源层：平台需要处理和对接的各种数据资源，可以来自关系数据库，HBASE、Hive、Solar、文件等；
• 开发层：元数据的采集及数据的采集、处理、开发等；
• 数据管理层：是平台的核心，实现资产目录的管理、数据服务的发布、数据质量的稽核能力；
• 进而支持数据的应用层，各种维度的数据应用：数据接口应用、数据分析应用、业务分析应用、数据加工应用、数据预测应用等。

最后给大家分享平台建设的4个重点：

1）建立端到端的服务开发；

2）实现API的服务化；

3）全方位，事前、事中、事后的数据质量体系；

4）寻求云原生的支持。

整个平台需要考虑从消费方到提供方整个闭环的管理机制；建立从需求、设计、开发、发布的闭环管理。

服务的发布一定要支持到服务的API化，技术实现可以采用微服务架构的形式，对外提供标准化的Restful风格服务，便于生态的打通。

建立事前、事中、事后完整的数据质量检核体系，把控数据工厂的数据质量；也可以定期的进行数据的专项治理工作，提升平台的整体质量；建议从数据的开发期就关注质量，尽量避免边污染边治理的模式；比如：

• 事前：主外键、时间戳字段、数据类型……
• 事中：非空、重复记录……
• 事后：及时性、一致性……

最后，需要考虑云原生的基础设施支撑。基础设施采用容器、容器编排工具；服务开发的技术架构建议采用微服务（Spring Cloud）、Mesh；工程效率采用DevOps，实现数据类应用的自动化CI、CD能力，以及环境类的自动准备。

4.总结

总结今天的分享，主要包括三点：

1）“服务化”已成为数字经济时代的主旋律；

2）通过“数据目录化、目录服务化、服务开放化”，来打造数据资产的服务化能力；

3）建立闭环的一体化服务共享的大数据平台；

最终打通断头路，让有价值的数据发挥数据的价值。

精选提问：

问1：服务化，有一个粗细的考量，如何规则API，怎么进行API（服务）治理，普元有什么经验可分享？

答：API服务治理要从管理体系、平台工具、组织保障三个维度去考量。其中管理体系中要建立包括：管理流程、设计规范、部署规范、生命周期等内容的服务治理方案与服务的度量与评价体系；平台工具中包括普元提供的标准产品：服务治理平台、服务发布平台以及服务监控平台；组织保障需要结合组织情况以及应用项目明确治理小组，定义服务提供者与服务消费者等。普元在政府、电信、金融有较多的服务治理项目案例，可浏览官网（www.primeton.com）相关资料。

问2：数据质量检验体系搭建有什么好的经验？从哪些维度判断数据质量？

答：数据质量和数据资产、数据标准是密切相关的，其中数据资产为质量提供了检核对象、以及问题分析定位能力；标准则为数据质量规则定义提供了依据。通过数据资产管理、数据服务、数据治理三方面能力，能够很好的解决数据共享用过程中出现的难题。我们一般会在数据集成点检查数据质量问题，例如：数据一致性、及时性、非标数据、空值、数据不完整等等。

问3：还是olap的应用吧？oltp的数据应该还在原来的应用吧。oltp是建议功能与数据分离呢？还是...？

答：数据服务平台建设的目的可以打通OLAP和OLTP，既可以为上层分析型应用提供数据支撑，也可以为下游应用系统提供数据服务。OLTP不建议功能和数据分离，建议可以参考微服务应用开发架构建设OLTP应用。

关于作者：刘相，普元软件产品部副总兼SOA&云计算产品线总经理。十年IT行业经验，专注于企业软件平台，在SOA、分布式计算、企业架构设计等领域。先后主导公司EOS7、Portal、云PAAS平台、云流程平台、BPM等系列产品的开发和设计工作。著有国内首本解析SpringBatch的中文原创图书《SpringBatch批处理框架》。