数据服务
在解释数据服务含义之前，我们先看下，通常数据应用在数据使用过程中出现的一些问题。
数据接入方式多样，介入效率低。
数据开发加工好数据后，通常会以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下线流程，释放对应的存储计算资源。
上图中，虚线框中的黄色部分就是数据服务需要提供的最基本功能。而这些功能中最重要的就是数据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