数据服务，数据中台的标配 or 灵魂？

01 什么是数据服务？

1.1 数据服务产生的背景

在数字经济快速发展，数字化转型成为企业重要战略的背景下，企业面临着快速增长的新需求和不断迭代的新技术，传统的架构开发周期长，运维成本高，并且业务系统之间的服务调用错综复杂，缺乏复用性，导致整个企业的IT开发和运维成本增加。为了解决这些问题，很多企业通过建设数据中台，提供标准化数据服务来提升数据开放共享能力，实现更高效、灵活和可扩展的业务系统。

1.2 数据服务的定义

业界有很多对数据服务的的定义，但是我们今天要讨论的是数据中台的数据服务，因此小编认为数据中台的“鼻祖”阿里巴巴提出的OneSercive概念更具有权威性，即由数据中台提供统一的数据接入和数据查询服务。

阿里数据中台的OneService提供了三项数据服务：

• 主题式数据服务，基于元数据和规范定义和建模，构建主题逻辑表，屏蔽复杂物理表，提供业务视角下的查询。

• 统一且多样化数据服务，一站式提供一般查询、 OLAP 分析、在线接口服务等查询和应用服务，便于数据跟踪管理。

• 跨源数据服务，统一数据接入层，屏蔽多种异构数据源的读写差异，减少数据访问和应用成本。

在网上曾看过这样一个比喻我觉得比较贴切，我们可以把数据服务想象成一个有各类型插口的电源插座，那么您的笔记本电脑只需插入三相插座接口就可以使用；您的电水壶只需插入两项插座接口就能烧水；您的台灯只需插入USB插口就能够点亮。

业界常用的数据服务包括五种类型， API、事件中心、数据库、文件、终端 & APP。但在数据中台领域，主要应用的是API，回到OneSercive的概念，我们可以理解为“数据服务一道桥，数据和应用分两边”这道桥联通了数据与应用，而这座桥存在的形式就是API。

数据服务在整个数据开发链条上处于什么位置？

数据通过数据中台的采集、汇聚、加工、处理、建模、质量管理后形成了企业的数据资产，但这并不是数据在数据中台的终点。通过接口服务化的方式将数据提供出去，让更多的部门、更多的业务应用来使用才是数据中台的核心与灵魂。

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

2.1 数据接入方式多样，接入效率低

数据中台项目会根据企业的数据类型、数据规模、使用场景等元素设计相应的存储方案：

• 小规模数据：可以用 MVSQL,Oracle 等 DB，因为部署维护方便、数据量小、查询性能强。

• 数据量大且需要多维分析的数据：可以用 GreenPlum，它在海量数据的 OLAP(在线分析处理)场景中有优异的性能表现。

• 数据量大的单Key查询：可以用 HBase。在大数据规模下，HBase 拥有不错的读写性能。

• 低时延高效率的数据：可以使用Redis或通过ES建立索引等方式来提升查询效率。

  上述每种方案的数据接入方式均不相同，每个数据应用都要根据不同的存储方案开发对应的接入代码，效率很低。

2.2 数据与接口无法复用

在数据应用的开发中，即使两个数据应用均使用了同一个表的数据，数据库也无法共享（不同应用之间共享数据库，会存在相互影响）；应用A的服务端接口也无法共享给应用B（因为接口已经根据应用A的需求高度定制）。这就导致了数据应用的开发过程中一直在不断地重复“造轮子”，浪费成本的同时，研发效率非常低。

2.3 不知道数据被哪些应用访问

虽然数据血缘建立了表与表之间的链路关系，但应用到表的链路关系是断的。当某个任务异常时，我们无法快速判断出这个任务影响了哪些数据应用。而数据中台提供的统一数据服务API，为数据应用和数据中台搭建了一座桥梁。数据API只有通过授权才能被访问，在给数据应用授权以及应用程序访问数据API的时候，可以“标签”的形式，将数据访问链路通知给元数据中心，从而打通了数据中台到数据应用的链路，形成了数据的全生命周期血缘。

2.4 底层数据变更，影响数据应用

在数据中台项目中，底层数据库的表重构是经常发生的，如果数据应用直接调用底层数据库表来访问数据，那一旦底层数据库的表发生重构或变更，可就头大了，数据应用需要修改代码并重新部署、上线。

我们举个例子：数据应用A使用了产品销售表的c字段，如果我们对产品销售表进行了重构，访问的字段需要替换成e字段，就需要数据应用A修改代码。有了数据服务，就会把数据应用和中台数据进行解耦，当中台数据表结构变更时，我们只需要修改-下数据服务上接口参数和数据字段的映射关系就可以了。不需要再修改代码，重新上线数据应用。

03 数据服务的七大核心功能

第一，接口规范化定义：对各个数据应用屏蔽了不同的中间存储，提供的是统一的API。

第二，数据网关部署：作为网关服务，数据服务必须要具备认证、授权、限流、监控四大功能，这是数据和接口复用的前提。

• 认证。为了解决接口安全的问题，数据服务首先会为每个注册的应用分配一对accesskey和secretkey，应用每次调用API接口，都必须携带。

• 授权。对于每个已发布的 API，API 负责人可以对应用进行授权，只有权限的应用才可以调用该接口。

• 限流。API 接口的负责人可以对应用进行限流（例如限制每秒QPS不超过 200），如果超过设定的阈值，就会触发熔断，限制接口的访问频率。需要注意的是，对于接口复用来说，限流功能非常必要，否则会造成不同应用之间的相互影响。

• 监控。例如，接口的 90% 的请求响应时间、接口调用次数、失败次数等相关的监控。同时，对于长时间没有调用的API ，应该予以下线。

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

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

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

第六，基于逻辑模型发布API，实现数据的复用：逻辑模型是解决数据复用的一个策略，在相同的物理模型之上，应用可以根据自己的需求，构建出不同的逻辑模型。我们可以在数据服务中定义逻辑模型，然后基于逻辑模型发布API。逻辑模型实际是多个物理表，从用户的视角，一个接口可以访问多张不同的物理表。

第七，构建数据市场（API集市），实现接口复用：为了实现接口的复用，我们需要构建API 集市，应用开发者可以直接在API集市发现已有的数据接口，直接申请该接口的 API权限，即可访问该数据，不需要重复开发。数据服务通过元数据中心，可以获得接口访问的表关联了哪些指标。使用者可以基于指标的组合，筛选接口，这样就可以根据想要的数据，查找可以提供这些数据的接口，形成闭环。

04 总结

数据服务为所有数据应用提供统一的API接口服务，包括接口规范化定义、数据网关、链路关系的维护、数据交付、多样中间存储和API接口、API测试。数据服务实现了数据中台模型和数据应用的全链路打通，解决了任务异常影响分析和数据下线影响哪些应用的难题：通过基于相同主键的物理模型构建逻辑模型，可以解决数据复用问题，提高接口模型发布效率。数据服务无疑是数据中台不可缺少的重要组成，说是数据中台的标配与灵魂也不为过。