探寻数据服务的本质：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。
云原生设计解决了:
- 数据服务不同接口间资源隔离问题
- 可基于请求量实现动态水平扩展
- 借助Envoy实现限流、熔断
2.2 逻辑模型
相较物理模型，逻辑模型没有保存实际的数据，而只是包括逻辑模型和物理模型的映射，数据在每次查询时动态生成。逻辑模型的设计，解决不同接口，对同一份数据，需要只看到自己需要的数据的需求。
数据服务逻辑模型的系统设计图：
接口发布者在数据服务中选择主键相同的多张物理表构建一个逻辑模型，然后基于逻辑模型发布接口。API服务接到查询请求后，根据逻辑模型和物理模型字段的映射关系，将逻辑执行计划拆解为面向物理模型的物理执行计划，并下发多个物理模型上去执行，最后对执行的结果进行聚合，返回给客户端。
一个逻辑模型关联的物理模型可以分布在不同的查询引擎上，但这时考虑性能因素，只支持基于主键的筛选。
2.3 数据自动导出
数据服务选择的是数据中台的一张表，然后将数据导出到中间存储中，对外提供API 。那数据啥时导到中间存储？ 要等数据产出完成。
所以在用户选择一张数据中台的表，定义好表的中间存储后，数据服务会自动生成一个数据导出任务，同时建立到这个数据中台表的产出任务的依赖关系，等每次调度产出任务结束，触发数据导出服务，将数据导到中间存储，此时API接口就可查询到最新数据。
3 总结
数据服务化不是一个API接口这么简单，背后是数据标准化交付的整套流程。本文学到了数据服务的八大关键功能设计和三大系统架构设计。
- 数据服务实现了数据中台模型和数据应用的全链路打通，解决了任务异常影响分析和数据下线不知道影响哪些应用的难题
- 基于相同主键的物理模型，可以构建逻辑模型，逻辑模型解决数据复用难题，提高接口模型的发布效率
- 数据服务宜采用云原生的设计模式，可以解决服务高可用、弹性伸缩和资源隔离的问题
数据服务化对于加速数据交付流程，以及数据交付后的运维管理效率有重要作用，也是数据中台关键的组成部分。
FAQ
数据服务要想解决数据被哪些应用访问的问题，就必须确保所有数据应用都必须通过数据服务获取数据中台的数据，那问题来了，如何确保数据服务是数据中台的唯一出口？
确保数据服务是数据中台的唯一出口，可以通过以下措施来实现：
- 确定数据服务的访问权限：只有被授权的应用才能够访问数据服务，其他应用无法访问。
- 实施网络隔离：将数据服务部署在独立的网络中，通过网络隔离的方式，确保只有经过授权的应用才能够访问数据服务。
- 实施身份验证和授权：对于每个访问数据服务的应用，都需要进行身份验证和授权，确保只有经过授权的应用才能够访问数据服务。
- 实施审计和监控：对于每个访问数据服务的应用，都需要进行审计和监控，确保只有经过授权的应用才能够访问数据服务，并且能够及时发现和处理异常情况。