数据服务

  在解释数据服务含义之前,我们先看下,通常数据应用在数据使用过程中出现的一些问题。

  数据接入方式多样,介入效率低。
  数据开发加工好数据后,通常会以Hive表的方式保存到hdfs上。前端应用如果想使用这些数据的话,为了保证查询性能,需要将数据导入到一个中间存储上。根据数据的使用方式和数据规模,有如下存储方案:

  • 数据规模小于500w,可以使用mysql,Oracle,sqlServer等DB。
  • 数据规模大,且存在多维查询场景。可以使用StarRocks。
  • 点查场景,数据量小可以使用redis,数据量大,采用HBase。

  因为不同的中间存储,涉及的访问 API 也不一样,所以对数据应用开发来说,每个数据应用都要根据不同的中间存储,开发对应的代码,如果涉及多个中间存储,还需要开发多套代码,数据接入效率很低。

  数据复用困难
  完了满足A应用,数据开发生成了一张数据表tableA,包含订单量数据。B应用也有一个数据需求,需要订单量和点击量数据。因为tableA中不包含点击数据,数据开发不得不重新开发一份同时包含订单量和点击量的数据。

  底层数据变更,影响数据应用
  应用前期因为数据量不大,把数据存在了redis中。随着业务的发展,redis已经不能满足存储需求,需要把数据迁移到Hbase中,而与之带来就是应用段需要修改取数代码。还有就是为了特定的业务场景,底层数据字段发生变更,前端应用也不得不做出响应代码调整。

  无法知道数据被哪些应用调用
  数据开发了生产了很多数据,但随着业务的调整,有些数据会慢慢的被弃用,被弃用的数据是应该进行下线的,同时释放相应的存储和计算资源,但是数据开发根本不知道,数据被哪些应用使用,也就无法下线数据。


  对于这些问题,我们可以通过数据服务来解决。那数据服务是什么?数据服务简单来说是一套数据请求API,数据应用通过api获取相应的数据。对于之上的四个问题,数据服务是如何解决的呢?

  数据应用通过API来获取数据,数据API介于底层数据和数据应用之间。数据的存储方式对于用户来说就是透明的,用户自然不需要根据不同的存储方案开发对应的代码。

  数据难复用最根本的问题在于,我们在构建数据模型无法将所有的应用场景都考虑全。为了满足应用需求,不得不重复造数据。例如下图:应用C需要同时使用数据A和数据B,因为数据A和数据B在不同的物理表中,或者这两份数据采用的存储方案不同。数据应用没办法使用这两份数据,不得不对合并数据A和数据B,得到满足需求的数据C。
在这里插入图片描述
数据服务解决思路如下:
在这里插入图片描述
最本质的区别就是不会构建“数据C”,数据服务将请求拆分成两个查数请求,分别从“数据A”和“数据B”中获得数据,并按照规则进行组装,最后返回,具体怎么实现的后续会讲解。

  底层数据变更,影响上层应用这个问题中,底层数据变更主要有两个方面:存储变更、元数据变更。存储由Reids->Hbase,因为数据服务通过api的方式暴露给用户,这种变更是不会影响数据应用的。元数据变更倒是对上层应用影响很大。在数据服务api并不会把底层存储的字段名直接返回给用户使用,而是会维护映射关系,这样的话,底层元数据变更,我们只需要修改映射关系,上层应用就不会受到影响。

  数据调用无法被追踪?最根本的原因是数据调用时没有记录数据使用记录。通过数据服务,可以对每一次请求进行鉴权,并记录请求信息。这样的话,数据出了问题可以立马获得受影响的数据应用,同样通过请求记录,我们能够很快知道数据是否被使用,对于没有使用、低价值的数据,就可以推动下线。
在这里插入图片描述


  数据服务只是一套API集合么?我们从数据应用接入的整个流程来看下,到底经历了哪些步骤,对应这些关键节点,我们都需要做些什么?

  如下图所示,一个数据应用想要一份数据,首先可以到数据API集市去检索,看看是否有现成的API能够满足需求,如果API集市中已经存在能够满足需求的API,数据应用需求方只需要使用认证凭证发起API请求权限申请(提供QPS,需求场景),并且数据API的提供者完成授权,这样数据应用就完成了数据对接。如果数据应用没有认证凭证,则需要申请认证凭证。

  如果数据API集市没有满足数据应用API,则需要把数据使用需求提交到数据产品。数据产品根据现有的数据仓库,查找是否有满足数据需求的表。如果有,数据产品根据数据规模和已知的应用场景,在数据服务平台快速定义数据API,完成接口的测试、上线,并交付给数据需求方。如果数仓中没有满足需求的表,数据产品会将该需求转换成一个数仓需求,完成数仓建设后,数据产品再定义数据API,最后交付给数据需求方。

  数据API上线后,数据服务还需要提供API的监控报警功能,实时监控API的调用情况,对于QPS暴增的情况要及时通知到应用方,对于数据API长时间没有调用,产品就需要启动API下线流程,释放对应的存储计算资源。
![(https://img-blog.csdnimg.cn/5b890d7d0de2475db0b0cc4ef35d93e8.png)
  上图中,虚线框中的黄色部分就是数据服务需要提供的最基本功能。而这些功能中最重要的就是数据API定义。数据API将数据应用和底层数据进行解耦,进而通过逻辑模型完成数据的复用。接下来我们将重点介绍下数据API的实现思路,先看API定义设计图:
在这里插入图片描述
  API定义包含四部分:api地址定义和数据源选择、输入参数设置、返回值设置以及DSL规则输入。

  api地址定义和数据源选择。
  “api地址定义”只要保证输入的地址是全局唯一就行,没有特别的命名规则。“数据源的选择”这部分要求数据产品选择api绑定的数据源。数据源可以有多个,也可以是不同类别。这里有一个强制约束:如果选择了多个数据源,所有数据源中必须包含相同定义的字段,这些字段名字可以不一样,但是代表的含义以及口径必须是一致的,而这些字段就是多数据源关联的主键。例如:一个api包含了两个数据源:A、B。A表中有orderid,B表中有order_id,A.orderid和B.order_id代表一个含义。

  为什么要如此设计?主要有两个原因,第一个:一个API如果绑定了多个数据源,数据服务在获取数据时必然存在JOIN操作,这种基于明细层的join查询,性能肯定不会太好。我们希望api在获取数据时,可以将查询拆分成两个查询,这两个查询分别去A,B表获得数据,然后再通过关联主键将数据合并。第二个原因就是,API绑定的多个数据源可能是不同类型,本身也没办法进行JOIN操作。

  输入参数
  每个输入参数都需要绑定数据表的具体字段,数据服务在接受请求时,会将输入参数转化成对应表字段,后续即便底层数据表字段变更,数据应用也无需修改请求。数据产品只需要将最新的字段映射关系维护到数据服务。

  返回值
这里只需要设置需要返回的字段,字段名可以随便定义,DSL中的返回值需要和此处设置的字段名绑定。

  DSL规则
  DSL是api定义最核心的部分。DSL的作用就是通过特定的语义规则,描述取数逻辑,数据服务通过DSL规则,翻译成取数代码,以此达到API快速上线的目的。这样设计主要考虑点:

  • 数据服务的取数基本上是根据某些条件从底层物理表获取数据,通常不会有复杂计算逻辑,用DSL可以很容易描述取数逻辑。
  • 同样因为取数逻辑比较简单,意味着同一类型数据源的取数代码,基本上只是字段和表名不同。所以完全可以把取数的代码进行封装,抽象出取数公共层,避免代码重复开发。同时也可以避免代码上线对其他API造成影响。
  • 通过DSL规则描述取数逻辑,本质上就是在物理模型之上构建逻辑模型,逻辑模型的存在,解决了数据复用的问题,相同的物理模型之上,应用可以根据自己的需求,构建出不同的逻辑模型,每个应用看到不同的列。

最后介绍下,数据应用通过数据服务获取数据的底层实现,看下图。
在这里插入图片描述
  “数据应用C”通过接口获取数据,数据服务接收到请求后,会找到api对应的DSL。数据服务根据DSL描述的逻辑模型,将查询请求拆解成不同的执行计划,并分解成具体的执行SQL,数据服务根据SQL去对应的物理表中,获取数据,最后将获得的数据根据主键进行合并返回给数据应用。

  在数据服务的这个应用场景,DSL完全可以使用SQL语法。为了让计算结果和API定义的返回值对应上,我们添加了Return 关键字去映射SQL中的字段。

  举个例子:数据需求方希望通过uid和day获得用户在某一天的订单累计金额和点击数。其中订单数据位于mysql表orders.orders中,点击数据位于starrocks表content.actions表中,DSL规则可以如下定义(仅供参考,并非真实环境)

Query:  
Select uid,sum(money) from orders.orders where uid=#{user_id} and day=#{date} group by uid  
Return uid,moneys; 
Query:  
Select uid,sum(clicks) from content.actions where user_id=#{user_id} and day=#{date} group by uid  
Return uid,clicks;

  数据服务会根据DSL规则,拆解成两个物理执行计划:从orders.orders中获得用户成交金额数据、从content.actions中获得点击数据。根据Return后的字段以及API定义的关联键,将两份结果数据合并,返回给用户。其中DSL解析过程是比较耗时的,通常会把取数逻辑缓存起来,当API取数逻辑发生变更时,实时刷新缓存。


  本文所介绍的数据服务建设思路只是数据服务平台其中的一小部分。数据服务完善程度直接影响了数据对业务赋能的效率,作为数据中台的最后一公里,数据服务值得数据产品和中台架构师投入更多的精力。END

  • 2
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值