为什么说 数据服务是数据中台的标配？

有人认为，多维的数据分类体系已经够用了，标签就是一个“鸡肋”；也有人认为标签体系有有利于大数据的萃取和分析，提供画像能力，实现精准推荐，必须是数据中台的标配。

如果“标签体系”确有争议的话，那么今天介绍的这个功能一定没有争议，它绝对是数据中台的真正标配，它就是——数据服务。

01 什么是数据服务？

数据服务的类别相当广泛，有提供数据传输能力的叫做数据传输服务，有提供数据存储能力的叫做数据存储服务，有执行各种类型分析的叫做数据分析服务，还有提供数据安全管理的叫做数据安全服务等等。

这些都叫数据服务，但这些数据服务强调的是能力，更准确的定义是“Data as a Service——数据即服务”，但这不是我们今天要讲的数据中台的数据服务！

数据中台的数据服务到底是什么？

我的理解：不同系统之间使用服务的方式进行交互，数据服务为数据和应用之间建立了一座“沟通的桥梁”，这座桥梁的存在形式是 API。

可以把它想象成一个电源插座，例如，只需要你的吹风机有一个匹配的插头，并将其插入，电流就会流向你的吹风机，就像数据流向你的数据应用一样。

02 数据中台为什么需要数据服务？

网上的很多文章中，喜欢将数据中台用“厨师做菜”来形象比喻。厨师做菜一般有几个步骤：买菜、洗菜择菜、制定菜单、炒菜。这几个步骤在数据中台的数据加工流程中被称为：数据采集、数据清洗、数据建模、数据分析/数据应用。

图片

数据采集

跟厨师做菜一样，巧妇难为无米之炊，需要做几道好菜，首先得有原材料，那么数据采集/数据接入就是买菜的过程。

数据清洗

买回来菜需要摘洗干净，才能下锅，数据清洗就是摘菜洗菜的过程，是需要把脏数据清洗掉。

数据建模

菜摘洗好了，但炒什么菜要需要根据客人下的菜单来做。数据建模就像对为客人制定菜单一样，例如：客人喜欢什么菜？鱼香肉丝还是宫保鸡丁，口味是甜一点，辣一点还是清淡一点等问题都要描述清楚并传递给“厨师”。数据建模就是将数据消费者的需求转化为计算机能够理解的语言。

数据分析/数据应用

根据客人的“菜单”要求，炒菜装盘。

好了，看到这里有人不禁要问：说了这么多，数据服务在哪里？数据中台到底为什么需要数据服务？

在这个“厨师做菜”的过程中，有一个不能忽略的角色，不知道你有没有发现，这个角色就是“服务员”。他的任务是帮助客户点菜，并将炒好的菜端到客人的桌上。而数据中台的“服务员”就是数据服务，英文名字：OneService。

想象一下，你正坐在餐厅的一张桌子旁，那里有可供选择的菜单。但如果没有服务员，就会缺少的是将你的菜单传达给厨房并将你的食物送回餐桌的关键环节。这就是“服务员”（数据服务）的用武之地，接受数据消费者的请求，并告诉系统做什么，将做好的数据服务以 API 的方式提供给数据消费者。

另外，在整个过程中，数据服务还有一个作用，它屏蔽了底层数据的技术细节，数据消费者不需要关心“这些数据来自哪里，哪个库，哪张表，数据库类型是什么等”问题，只需要关心“这些数据能否满足我的需要”就行了。

就如同你去餐厅吃饭，不用关心菜是从哪买回来的，谁是配菜的，谁是炒菜的等这些问题一样，只需要关心这个菜合不合你的口味就行了。

03 数据服务能解决哪些问题？

在传统的数据集成方案中，往往需要将数据从一个系统导出/导入，或复制到另一个系统当中。随着企业数据应用规模的不断扩大，需要在几十个甚至上百个系统中进行数据集成，传统的数据集成方式难度越来越大，暴露的问题也越来越多。

1、数据“搬家”造成的数据不一致问题

传统数据集成需要将数据从一个系统复制到另一个系统中，过程中由于网络、接口、程序、任务以及其他的一些不确定因素都会导致数据在“搬家”的过程中“丢失”，从而造成数据不一致问题。

而通过数据中台提供的数据 API 交付数据，大部分情况下不需要数据“落地”，强调使用权而不是拥有权，这样就大大减少了数据在流向下游系统过程中造成不一致问题。

2、数据接入多样，集成效率低

数据中台会根据企业数据的类型、数据量大小、数据的应用需求等，设计相应的不同数据接入和存储方案。例如：通过 MySQL、Oracle 接入数据量相对较小的数据，通过 Greenplum 接入数据量大且需要多维分析的数据，通过 Hbase 接入大量的 keyValue 数据，以及通过 ES 建立数据索引提升数据的查询效率等等。这种情况下，如果按每种数据接入方式暴露数据的话，无疑是一个非常复杂事情。

而通过数据中台将各类型数据封装为统一的数据 API，对外提供接口，能够屏蔽数据接入多样性带来的数据集成复杂、效率低下等问题。

3、数据被哪些应用访问了无法监控

传统的数据项目中，即使用了元数据这样的工具，也无法实现数据的采集、汇总、清洗、处理、应用的全链路血缘分析。尤其是数据平台到数据应用的链路几乎全部是割裂的，数据平台通过导出/导入或数据复制的方式为数据应用提供数据，数据一旦进入到下游系统中，数据平台就无法监控其使用情况了。

而数据中台提供的统一数据服务 API，为数据应用和数据中台搭建了一座桥梁。数据 API 只有通过授权才能被访问，在给数据应用授权以及应用程序访问数据 API 的时候，可以“标签”的形式，将数据访问链路通知给元数据中心，从而打通了数据中台到数据应用的链路，形成了数据的全生命周期血缘。

4、上游数据变更，影响下游数据应用

在很多数据项目中，还有一种情况比较常见：数据应用直接调用数据平台的数据库来访问数据。这就会导致，一旦上游数据发生变更就会对下游的数据应用造成较大影响。

而数据中台提供统一的数据 API 供数据应用调用，实现了数据中台与数据应用的解耦。在数据服务内部建立与与各数据源建立映射，上游数据发生变更，只需要调整数据服务的映射即可，不会对数据应用的使用造成影响。

04 数据服务应具备哪些功能？

在数据中台架构中数据服务层位于数据中台上层，连接数据消费层，将已整合的数据以服务的形式提供给数据消费者，以获得更好的性能和体验。数据服务层具备的功能如下：

图片

跨源数据服务

数据中台接入数据的多样性，决定了数据中台的技术架构需要由多个大数据组件组成，例如：Hive、HBASE、GP、ES、Redis、MySQL、Oracle 等等，而业务上对数据的使用可能是跨多个数据库的。数据服务层提供的跨源数据服务，屏蔽了底层数据源的技术差异，可以从不同数据源提取数据，并按照业务需要进行编排，形成统一 API 进行对外共享。

主题数据服务

按照不同的业务主题，组织形成统一的数据 API。数据中台继承了数据仓库面向主题的思想，将位于不同数据中间存储的同一业务主题的数据整合到一起，屏蔽多数据源与多物理表，形成标准的数据服务供外部使用。例如：销售主题，需要将企业的批发、零售、线上、线下、代理等等各个渠道的销售数据汇集起来。

一站式查询

数据服务最终将用户访问的 API 转化为底层对各种数据源的访问，实现对数据中台数据的一站式查询，提供数据检索、联机分析、实时查询等，提升数据查询的效率。

全链路打通

数据和应用的分离会导致数据血缘无法完整追溯，数据服务不仅提供了连接数据和应用能力，还通过服务授权以及访问监控等功能，将数据 API 的访问情况实时写入元数据中心，形成完整的数据血缘。

订阅交付能力

订阅交付能力：数据 API 构建完成，并不需要数据消费者重复构建集成通道，而是通过授权“订阅”的方式，让数据消费者通过接口快速使用数据。

API 网关服务

API 网关服务使用云原生技术提供了服务 API 的统一管理和监控能力，包括：服务注册、服务自动发现、认证授权、流量控制、超时熔断、安全控制、监控分析等。

05 数据中台的数据服务该如何构建？

图片

颗粒度问题

服务拆分的越细则复用性越好，但如果只考虑服务重用，大量的细颗粒度服务将很难管理并且势必会对整体性能带来影响。服务的设计需要从业务需求、管理难以程度、性能特性等方面综合考量。

标准化问题

服务的开发采用 Restful API 技术，该技术具有结构清晰、易于理解、方便扩展等特点，且接口规范标准，不论前端应用是 java、.net、C#还是 PHP 都能够调用。就像设计一个插座，一定要具备普适性，这样不论你的吹风机插头是美标的、欧标的还是国标均的都能够适配。

DataOps

DataOps 是将 DevOps 的理念延伸到数据世界，提供了一种数据服务的持续运营方式。通过 API 网关进行服务的注册和管理，实现数据服务的动态发现、自动部署、自动化监控。根据服务的运行监控数据对数据服务的进行有效治理，包括数据服务的迭代优化、服务编排、自动测试、服务下架等。

写在最后

数据服务层（OneService）改变了传统的数据集成和交付方式，所有整合到数据中台的数据都通过数据服务提供，数据服务对外暴露的不是数据而是接口，数据消费者不用直接获取数据，而是通过接口服务获取。

数据服务不是简单的对外暴露一个 API 就行了，

从功能层面

数据服务还包括了跨数据源服务、主题数据服务、一站式查询服务、订阅式交付、全链路打通等能力；

在技术层面

数据服务采用了云原生技术，具备了服务的动态发现、自动部署、自动监控、服务治理等能力。