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测试。数据服务实现了数据中台模型和数据应用的全链路打通,解决了任务异常影响分析和数据下线影响哪些应用的难题:通过基于相同主键的物理模型构建逻辑模型,可以解决数据复用问题,提高接口模型发布效率。数据服务无疑是数据中台不可缺少的重要组成,说是数据中台的标配与灵魂也不为过。