大数据平台(XSailboat)中的数据服务实践

1. 背景

在大数据平台下(大数据平台XSailboat)的数据开发和个性化应用开发的逻辑过程，通常是这样的。

即时没有使用大数据平台/数据工厂进行开发，只要有数据中台或者数据服务的概念，数据存储在关系数据库中，在以数据发布为主要功能的微服务中，就会经常需要开发REST API，通常它内部的逻辑是这样的：

1. 取得数据库连接
2. 注入参数，执行一个SQL
3. 取得SQL查询结果
4. 对结果按需处理，构造成期望的格式返回

在我们没有开发大数据平台之前，我们也在从事大数据的开发工作，那时我们的是用SpringBoot微服务做数据发布的，发现总是在不断重复上面的过程，尽快后来做了许多封装和工具类，使得过程大大简化，但是在开发过程中，总是少不了“开发->重启->测试->发布->web端开发测试->生产环境部署重启”的过程。

后来我们开始开发自己的大数据平台，借鉴阿里云数据工厂和数据服务，基于我的经验和实际的场景需求，逐步开发设计出自己的大数据平台，慢慢地摸索出自己路。

2. 我们的数据服务

我们的数据服务旨在通过可视化的界面，快速定义并发布API。如果它单纯只能使用一个SQL定义API的话，那么它的能力是相当不够的。如果能力不够，只能实现一部分场景下的API定义，又有谁愿意一会用数据服务开发API，一会又不得不在IDE里面用代码开发API吗？

2.1 数据服务的逻辑架构

所以我要求它的能力必需得足够的强，能适应绝大多说场景下的数据发布需求。为此我设计了如下的构件和逻辑：

2.2 应用参数

应用参数是工作空间内全局可见的，相对静态的，在数据服务APP启动后，工作空间环境初始化的时候固化缓存下来。

2.3 服务开发

数据服务开发工具，提供了工作空间，以隔离不同应用厂家和项目。

在一个工作空间中，API以“业务域”作为顶层分类包，其下的API，按API的路径(path)作为组织树。如下：

2.3.1 选择数据源

目前数据服务支持的数据源有支持JDBC和SQL的所有数据库。
数据源是在大数据平台中的“数据集成”模块中的“数据源管理”中定义的。每一个数据源包含开发环境配置和生产环境配置。在开发的时候使用开发环境的数据源配置，提交到生产环境时，使用生产环境的数据源配置。

2.3.2 参数定义

参数定义有点像代码开发的时候，声明变量并给变量赋值。

应用参数和和API内部的参数定义变量的值均支持Aviator表达式或接口服务调用。接口服务(REST API)可以是工作空间内的API（无认证）调用，也可以是API网关上的API（有认证）调用。

接口服务类型的参数支持设定缓存时间，以支持缓变数据避免频繁调用。这里是缓存是考虑这个服务调用的参数的，同一变量，不同调用，如果参数不同，是不会使用缓存值的。

2.3.3 SQL

SQL里面我们支持使用动态参数：

• ${参数[:aviator表达式]}，aviator表达式能使用输入参数，参数定义和应用参数等地方定义的参数。这种形式有点像SQL里面的?占位，它是会考虑参数类型的，所以对于字符串类型，不用加’'(引号)，后台的解析查询引擎会自动根据类型处理。
• ${[参数]::aviator表达式}，这种形式表达式的结果会转成String类型，原样拼接到SQL里面去。它是不会去包裹引号的，所以可以用来构建SQL段。

SQL里面的${}内定义的参数会被自动提取作为API的输入参数。

示例值，用来作为调试时用的参数，避免每次调试都得输入。默认值对于非必填参数有效，在参数没有设置时，用作缺省值。

2.3.4 后置处理

在后置处理中可以编写Aviator脚本，处理SQL查询结果。SQL查询结果用_result_obj表示。另外还有内置变量：_ds_client（本工作空间的接口的HttpClient），_gw_client（API网关的HttpClient）。这样使得有足够强大的后置处理能力。

例如，一个接口需要跨数据库实例，join两个表的结果，那么可以先定义一个接口，查询其中一个表的结果，再定义第2个接口，在变量中定义一个变量，值是调用本工作空间中的接口取得结果。用SQL查询第2个表的结果，最后在后置处理里面，用Aviator脚本综合处理两个表的查询结果返回。

我们对Aviator函数进行了扩展，有许多适合数据服务业务场景的函数可供使用。

2.4 API开发调试

这是开发环境的API调试界面，缺省使用了示例值，可以修改:

API的返回结果如果符合特定的结构，将支持解析称表格形式查看：

2.5 API 发布

开发调试好的API，点击发布，就能发布到生产环境，并把API发布到API网关。
这是API的基本信息。

在API网关上，可以找到API，并进行调试、授权等。