（二）数据服务难道就是对外提供个API吗？

大数据真有意思 2020-08-26

943

点击关注上方“知了小巷”，

设为“置顶或星标”，第一时间送达干货。

前文回顾：

交付速度和质量问题解决了，⽼板说还得“省”

在《（一）数据服务到底解决了什么问题？》中，了解到为什么必须要有数据服务，可以看到，数据服务在数据建设中发挥着重要的作⽤。有的⼈可能会好奇了，数据服务到底⻓什么样⼦呢？是不是只对外提供⼀个API？真的有这么简单吗？

</> 数据服务应该具备的⼋⼤功能

数据服务应该具备⼋个功能，只有具备这些功能，才能解决《（一）数据服务到底解决了什么问题？》中提到的问题。⽐如，数据接⼊⽅式多样，接⼊效率低；数据和接⼝没办法共享；不知道数据被哪些应⽤访问……

下面是一个⼩故事。

比如去菜⻦驿站取快递？假设有⼀个很⼤的菜⻦驿站，⾥⾯有很多组货架，每个货架前都有⼀些⼯作

⼈员帮助我们取快递，同时也有很多队伍排队。

取快递，要先约定好接⼝（⽐如统⼀使⽤收货码来取货）。然后，为了保证不同队伍都能取到快递，我们要对每个队伍做⼀些限流（⽐如⼀个队伍⼀次只能取⼀个⼈）。在你取⾛快递时，驿站会记录是谁取⾛了哪个快递，⽅便后续追查。

这段时间，菜⻦驿站服务开始升级，不仅可以取快递，还提供快递送货上⻔的服务。除此之外，不同种类的快递对应的货架也变得不同，⽐如⽣鲜⻝品，货架是冷藏冰箱，⽂件、信封，货架就是⽂件柜。

对于取快递的⼈来说，如果他买了⽣鲜，⼜买了信封，那他要排好⼏个队伍，肯定不⽅便。所以，⼀般来讲，取快递的⼈最好只在⼀个队伍排队，⽽驿站⼯作⼈员帮他⼀次把多个货架的快递都取过来。

可驿站的货架实在是太多了，为了⽅便每个取快递的⼩伙伴都能快速找到每个货架以及队伍，驿站提供了⼀个导览。与此同时，为了不让⼯作⼈员出错，驿站的⼯作⼈员必须经过严格的测试，才能上岗。

讲完这个故事之后，我们接着回到数据服务的这⼋⼤功能上来。在取快递的这个例⼦中，可以把数据服务看成是⼀个菜⻦驿站，⼯作⼈员看成是API解耦库，货架可以看作是中间存储，快递则可以认为是数据。

那么对应到⼋个功能，就是：

接⼝规范化定义，可以看成是取快递约定的收货码，基于统⼀的收货码取⾛快递；

数据⽹关，可以看成是我们对每个货架前的队伍进⾏限流，确保每个队伍都能取⾛快递；

链路关系的维护，可以看作是驿站会记录谁取⾛了什么快递；

数据交付，可以看作驿站同时提供取快递和送货上⻔服务；

提供多样中间存储，可以看成有不同类型的货架；

逻辑模型，可以看成是⼀个⼯作⼈员，可以取多个货架的快递；

API接⼝，可以看作是驿站的不同货架的不同队伍导览；

API测试，可以看作是驿站⼯作⼈员上岗前的测试。

下面是数据服务这⼋个功能具体包含什么内容。

</> 第⼀个是接⼝规范化定义

接⼝规范化定义就是取快递时约定的取件码。数据服务，对各个数据应⽤屏蔽了不同的中间存储，提供的是统⼀的API。

在上图中，我们可以在数据服务上，定义每个API接⼝的输⼊和输出参数。

</> 第⼆，数据⽹关

作为⽹关服务，数据服务必须要具备认证、权限、限流、监控四⼤功能，这是数据和接⼝复⽤的前提。这就跟我们在菜⻦驿站前取快递，要对每个队伍的⼈进⾏认证、限流⼀个道理。

⾸先是认证，为了解决接⼝安全的问题，数据服务⾸先会为每个注册的应⽤分配⼀对accesskey和secretkey，应⽤每次调⽤API 接⼝，都必须携带acesskey和secretkey。

除此之外，对于每个已发布的API，API 负责⼈可以对应⽤进⾏授权，只有有权限的应⽤才可以调⽤该接⼝。同时，API接⼝的负责⼈可以对应⽤进⾏限流（例如限制每秒QPS不超过200），如果超过设定的阈值，就会触发熔断，限制接⼝的访问频率。

需要注意的是，对于接⼝复⽤来说，限流功能⾮常必要，否则会造成不同应⽤之间的相互影响。

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

</> 第三，全链路打通

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

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

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

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

需要特别提到的是，⼀个数据应⽤往往涉及很多⻚⾯，如果我们在影响分析时，只分析到应⽤，可能粒度还是太粗了，需要到更细级别的⻚⾯的粒度，⽐如⼀个任务异常，不光要知道是哪个数据产品，还必须得知道是哪个数据产品的哪个⻚⾯。此时，我们在接⼝授权时，可以标注⻚⾯名称。

</> 第四，推和拉的数据交付⽅式

一般数据服务，都是以API接⼝的形式对外提供服务，但是业务实际场景中，光API还不够的。把API⽅式称为拉的⽅式，⽽实际业务中同样还需要推的场景。

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

</> 第五，利⽤中间存储，加速数据查询

数据中台中数据以Hive表的形式存在，基于Hive或者是Spark计算引擎，并不能满⾜数据产品低延迟，⾼并发的访问要求，所以，⼀般做法是将数据从Hive表导出到⼀个中间存储，由中间存储提供实时查询的能⼒。数据服务需要根据应⽤场景⽀持多种中间存储，这里列举了⼀些常⽤的中间存储以及这些存储适⽤的场景，希望能根据实际场景选择适合的中间存储。

</> 第六，逻辑模型，实现数据的复⽤

在前⾯取快递的场景中，每⼀个货架⼀拨⼯作⼈员，其实对取快递的⼈并不友好，所以最好的就是⼀个⼈帮我们把所有的快递都取了。这就有点⼉类似数据服务中逻辑模型的概念了。我们可以在数据服务中定义逻辑模型，然后基于逻辑模型发布API，逻辑模型的背后实际是多个物理表，从⽤⼾的视⻆，⼀个接⼝就可以访问多张不同的物理表了。

逻辑模型可以类⽐为数据库中视图的概念，相⽐于物理模型，逻辑模型只定义了表和字段的映射关系，数据是在查询时动态计算的。逻辑模型可以看作是相同主键的物理模型组成的⼤宽表。逻辑模型的存在，解决了数据复⽤的问题，相同的物理模型之上，应⽤可以根据⾃⼰的需求，构建出不同的逻辑模型，每个应⽤看到不同的列。

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

</> 第七，构建API 集市，实现接⼝复⽤

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

需要特别指出的是，数据服务通过元数据中⼼，可以获得接⼝访问的表关联了哪些指标。使⽤者可以基于指标的组合，筛选接⼝，这样就可以根据想要的数据，查找可以提供这些数据的接⼝，形成了⼀个闭环。

数据服务应该如何实现呢？数据服务的架构设计。

</> 数据服务系统架构设计

主要采⽤云原⽣、逻辑模型和数据⾃动导出三个关键设计，关于这部分内容，在实际⼯作中可以借鉴这样的⽅式完成数据服务的设计，或者在选择商业化产品时，作为架构选型⽅⾯的参考。

云原⽣

云原⽣的核⼼优势在于每个服务⾄少有两个副本，实现了服务的⾼可⽤，同时根据访问量⼤⼩，服务的副本数量可以动态调整，基于服务发现，可以实现对客⼾端透明的弹性伸缩。服务之间基于容器实现了资源隔离，避免了服务之间的相互影响。这些特性⾮常适⽤于提供⾼并发、低延迟，在线数据查询的数据服务。

上图是数据服务的部署架构，在这个图中，每个已经发布上线的API接⼝都对应了⼀个Kubernates的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。

基于云原⽣的设计，解决了数据服务不同接⼝之间资源隔离的问题，同时可以基于请求量实现动态的⽔平扩展。同时借助Envoy实现了限流、熔断的功能。