探寻数据服务的本质：API之外的可能性

数据服务在数据建设中发挥着重要的作用。数据服务到底啥样？是不是只对外提供一个API？这么简单？

而我希望你能在学完这部分内容之后，真正掌握数据服务的产品功能设计和系统架构设计。因为这会对你设计一个数据服务，或者选择一个商业化产品，有很大的帮助。

1 数据服务应该具备的八大功能

数据服务至少具备八个功能，才能解决上文提到问题。如数据接入方式多样，接入效率低；数据和接口没办法共享；不知道数据被哪些应用访问……

假设很大菜鸟驿站，有很多组货架，每个货架前都有工作人员帮我们取快递，同时很多队伍排队。

取快递，先约定好接口（如统一使用取货码）。然后，为保证不同队伍都能取到快递，对每个队伍限流（如一个队伍一次只能取一个人）。你取走快递时，驿站机器扫描记录取走了哪个快递，方便追查。

这段时间，菜鸟驿站服务升级，不仅可取快递，还提供快递送货上门。不同种类的快递对应的货架也变得不同，如生鲜食品，货架是冷藏冰箱，文件、信封，货架就是文件柜。

对取快递的人，如他买生鲜，又买信封，他要排好几个队伍，不方便。一般取快递的人最好只在一个队伍排队，而驿站工作人员帮他一次把多个货架的快递取过来。

可驿站货架实在太多，为方便每个取快递的都能快速找到每个货架及队伍，驿站提供一个导览。为了不让工作人员出错，驿站工作人员须经过严格测试，才能上岗。

回到数据服务八大功能。取快递例子中，你可将：

数据服务看作菜鸟驿站
工作人员看成是API解耦库
货架看作中间存储
快递认为是数据

对应八个功能：

接口规范化定义，取快递约定的收货码，基于统一的收货码取快递
数据网关，可看成是我们对每个货架前的队伍限流，确保每个队伍都能取走快递
链路关系的维护，可以看作是驿站会记录谁取走了什么快递
数据交付，可以看作驿站同时提供取快递和送货上门服务
提供多样中间存储，可以看成有不同类型的货架
逻辑模型，可以看成是一个工作人员，可以取多个货架的快递
API接口，可以看作是驿站的不同货架的不同队伍导览
API测试，可以看作是驿站工作人员上岗前的测试

通过这个故事，你是不是已经对数据服务的八个功能有一个形象的感知了？接下来，我们来看看数据服务这八个功能具体包含什么内容。

1.1 接口规范化定义

接口规范化定义就是取快递时我们约定的取件码。数据服务对各数据应用屏蔽不同的中间存储，提供统一API。

数据服务界面示意图：

上图可在数据服务上，定义每个API接口的输入和输出参数。

1.2 数据网关

作为网关服务，数据服务必须要具备认证、权限、限流、监控四大功能，这是数据和接口复用的前提。这和我们在菜鸟驿站前取快递，要对每个队伍的人认证、限流一个道理。

认证

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

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

API接口负责人可对应用进行限流（如限制每秒QPS不超过200），超过触发熔断

对接口复用，限流功能很必要，否则会造成不同应用之间的相互影响。

应用对接口授权示意图

当然，数据服务还要提供接口相关的监控，比如接口的90%的请求响应时间、接口调用次数、失败次数等相关的监控，另外，对于长时间没有调用的API ，应该予以下线。这样做的好处是防止没用的接口额外占用资源。

1.3 全链路打通

数据服务还须负责维护数据模型到数据应用的链路关系。

上图经营分析是数据应用，甄美丽是数据应用的开发，当她想访问数据服务中的某接口获取表A、B的数据时，她要向接口发布者马帅申请授予权限。然后经营分析就可通过接口获取到数据。

数据服务会把经营分析和表A、B的访问关系，推送给数据中台的元数据中心。接着元数据中心表A、B及A和B的上游所有的表（图中D、E）上，就有经营分析数据应用的标签。

当表D的产出任务异常，马帅可通过元数据中心，快速判断该任务影响经营分析数据产品的数据产出。同时，当马帅帅想要下线表D时，也可通过这张表是否有标签，快速判断这表下游是否还有应用访问。当取消API 接口授权时，元数据中心同时清理表的相关标签。

一个数据应用涉及很多页面，影响分析时，只分析到应用粒度还是太粗，要到更细级别的页面粒度，如一个任务异常，不光要知道哪个数据产品，还得知道是哪个页面。在接口授权时，可标注页面名称。

1.4 推和拉的数据交付方式

你听到的数据服务都以API接口形式对外提供服务，但业务实际场景中，光API还不够。API称为拉方式，而实际业务中同样还需要推。

比如在实时直播场景中，商家需要第一时间获得关于活动的销售数据，此时就需要数据服务具备推的能力，我把它称为数据的送货上门服务。数据服务将数据实时写入到一个Kafka中，然后应用通过订阅Kafka的Topic，可以获得实时数据的推送。

1.5 利用中间存储，加速数据查询

数据中台中数据以Hive表形式存在，基于Hive或Spark计算引擎，并不能满足数据产品低延迟，高并发访问要求，

一般做法是将数据从Hive表导到一个中间存储，由中间存储提供实时查询能力。数据服务需根据应用场景支持多种中间存储，列举一些常用中间存储及场景

1.6 逻辑模型，实现数据的复用

每个货架一拨工作人员，对取快递的人不友好，最好一个人帮我们把所有快递取了。类似数据服务中逻辑模型。

可在数据服务中定义逻辑模型，然后基于逻辑模型发布API，逻辑模型背后是多个物理表，用户视角一个接口就可访问多张不同物理表。

逻辑模型可类比为数据库视图，相比物理模型，逻辑模型只定表和字段的映射，数据在查询时动态计算。逻辑模型可看作相同主键的物理模型组成的大宽表。逻辑模型解决数据复用问题，相同物理模型之上，应用可根据自己需求，构建不同逻辑模型，每个应用看到不同列。

在上面这个例子中，有三个物理模型，但是主键都是商品ID，针对商品运营系统和店铺参谋，我们可以构建两个不同的逻辑模型，分别从不同的视角看数据，逻辑模型并不实际存在，而是在查询的时候，根据逻辑模型映射的物理模型字段，动态的地将请求拆分给多个物理模型，然后对多个查询结果进行聚合，得到逻辑模型查询的结果。

1.7 构建API 集市，实现接口复用

为了实现接口的复用，我们需要构建API的集市，应用开发者可以直接在API 集市发现已有的数据接口，直接申请该接口的API 权限，即可访问该数据，不需要重复开发。

数据服务通过元数据中心，可获得接口访问的表关联了哪些指标。使用者可基于指标组合，筛选接口，根据想要数据，查找可以提供这些数据的接口，形成闭环。

数据服务应该如何实现？

2 数据服务系统架构设计

实现数据服务时，主要采用云原生、逻辑模型和数据自动导出：

可借鉴我的方式完成数据服务的设计
或选择商业化产品时，架构选型参考

2.1 云原生

核心优势在每个服务至少有两个副本，实现服务高可用，同时根据访问量大小，服务副本数量可动态调整，基于服务发现，可实现对客户端透明弹性伸缩。服务间基于容器实现资源隔离，避免相互影响。这些特性适用高并发、低延迟，在线数据查询的数据服务。

数据服务的部署架构，每个已发布上线的API接口都对应一个k8s的Service，每个Service有多个副本的Pod组成，每个API 接口访问后端存储引擎的代码运行在Pod对应容器，随API接口调用量变化，Pod可动态创建销毁。

Envoy是服务网关，可将Http请求负载均衡到Service的多Pod。Ingress Controller 可查看 Kubernates中每个Service的Pod 变化，动态将Pod IP写回Envoy，实现动态服务发现。前端APP，Web或业务系统Server端，通过4层负载均衡LB接入Envoy。

云原生设计解决了: