架构设计基础

一、架构图

二、系统背景

业务发展迅速，积累了大量的数据资产，大数据团队承担数据串联、沉淀，反哺和赋能业务的重要职责。大数据团队协同各部门打造了玩个大狗魔方、大狗宝盒数据产品，提供data-center应用发力数据中台，统一数据关键路径，尽最大程度解决部门间信息屏障问题。但是数据中台的加速输出没有为内部系统建设带来过多收益，反而产生了多个业务应用，造成了数据服务复用率低的难题。

数据服务建设面临挑战颇多，如存储系统多样，数据处理量大，数据需求粒度不定等重重问题，为了实现数据收口、快速响应，提高数据体验，通用数据中台应运而生。

三、系统原则

为了支持更多类型的业务，减少系统的耦合，便于发现和追踪问题，节省人力成本，方便迭代，需要设计比较好的架构，系统架构具备以下原则：

1. 通用性：该架构具备包容的能力，业务上的任何产品都可以用这一套架构来涵盖和实现。
2. 模块化：模块化的目的在于将一个业务按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容，模块之间通过一致性的协议调用。将一个大的系统模块化之后，每个模块都可以被高度复用。
3. 组件化：组件化就是基于可重用的目的，将一个大的软件系统拆分成多个独立的组件，主要目的就是减少耦合。一个独立的组件可以是一个软件包、web服务、web资源或者是封装了一些函数的模块
4. 一致性：指模块的数据输入输出采用统一的数据交互协议，做到整个系统一致。

四、系统要求

数据服务满足应用的概念，支持在数据服务上开发应用和接口，数据服务需要满足微服务设计、支持异构存储组件特性。

微服务设计特性。微服务设计具有低耦合、高内聚的特点，需要大量基础组件的支持如日志、缓存、链路追踪，以及服务的注册与发现。

异构存储组件特性。大的数据中台支持多样的存储组件，关系型/KV型，单机/分布式，磁盘/内存，行式/列式/多模式等，以独立或组合的形式适配不同的应用场景。每个存储组件的连接池管理、使用规范、性能优化各不相同。

开发编译部署特性。数据服务以降本增效为目的，提供快速的数据响应，传统的应用开发编译和部署模式存在固有的生命周期，数据服务需要更快。

1.存储系统支持。数据服务需要支持多种类型的存储系统，关系型、k-v，行式、列式，sql、query dsl、api查询语言，文件系统等多种形式。

2.自助取数。简单的模板化，负责的定制化。针对简单的查询需求，可以通过模板化配置快速分装数据接口，负责的需要能够支持编程介入。

3.系统安全。需要有完备的稳定性方案，防止某些大数据量，长耗时请求干趴整个系统。尤其注意把存储系统打崩或者带宽打满这种事。

4.数据血缘。大数据平台的建设是涉及到各个业务团队，业务系统是相互独立的系统，数据是统一的，很多数据的相互协同是通过大数据实现闭环的，业务追求闭环，数据也在追求闭环，因此就需要追溯数据的来源和去向。当数据从数据服务分发出去后通过其他形式重新回来的过程中，不能丢失这种血缘关系。

5.资产保护。数据是种具有重要价值的资产，要严格保护珍贵资产不被盗取。申请数据需要经过审批流程才能获取到一个数据接口。

6.开发支持。为了实现方便的自助取数，需要有系统级的数据资产，元数据，数据血缘等子系统支持的开发系统，用于开发、调试数据接口。

7.发布系统。数据服务的数据接口要摒弃掉以往应用编译启动的流程，公司发布系统不再满足数据服务数据接口的发布需求，灰度发布。

8.监控告警。监控告警是系统稳定性运行的前提，及时告知开发系统问题。

五、模块简介

存储层

多种多样的存储系统。redis，mysql，elasticsearch，odps等等。

值得一提的是trino（它还有个名字是presto，关于它为什么改名了，以及为什么出现个trino就是个瓜了）。presto分布式SQL查询引擎， 一个纯粹的计算引擎，并不存储数据，通过Connector获取第三方存储服务的数据，也被称作prestodb。它具有异构数据源功能，支持多种数据源，如Hive、Kafka、MySQL、Ealsticsearch、Redis、Iceberg、Kubu、Druid、Cassandra等，也可自己实现Connector。支持通过JDBC/ODBC连接，提供了ANSI SQL语法支持，支持窗口函数，join，聚合，复杂查询等。

执行层

sql即接口，这也是数据服务的核心所在。

所谓的模板化开发即提供包含占位符的query（sql，query dsl等），参数映射关系和结果映射关系实现数据接口。

系统监控

为数据服务全栈提供监控告警支持

支持系统

元数据，数据资产，数据血缘三兄弟既支持开发系统又与数据服务打通，数据服务的后台，运维系统如发布系统，权限支持，用于外界查询接口详情的在线文档。

六、提问

1. 数据服务如何提供接口？ 
   1. 方案之一。http://dubbo.apache.org/zh/docs/v2.7/user/examples/generic-reference/
2. 接口有鉴权吗？ 
   1. 每个接口都会有鉴权，以及用于追踪每个接口数据流向的功能。
3. 接口升级有兼容吗？删减参数和结果字段，接口逻辑调整等造成不兼容
   1. 增加版本号功能。dubbo本身提供了version属性来控制接口的升级，解决多版本并存的问题，但是需要消费者与提供者一起合作，可以yy的是gateway的时候通过路由和版本等功能进行接口升级。
4. 服务市场。数据服务有那些应用场景？ 
   1. magician，boss-board数据产品，data-center数据服务，报表数据源
5. 成本管理？ 
   1. 数据服务使用情况，接口的使用情况（业务数量，请求数量，业务重要性）
6. 业务价值思考？ 
   1. 降本增效。降本：改变业务流程，节省了多少资源（时间，人力，金钱。。。），增效：效率增效，时间增效
7. 资源隔离？ 
   1. 单个接口不会耗尽整个“系统”的资源，如线程、network、存储资源。考虑增加sql耗时统计自动增加熔断机制，后期考虑sql执行计划。
8. 数据？服务？ 
   1. 数据：功能核心以数据查询下载即取数方向走，接口只是一种简单形式。核心功能以支持多样数据源查询功能为主
   2. 服务：做好在线服务功能，因为接口的开发形式在改变，在微服务架构中的接口文档，服务发现，限流熔断监控告警，路由，发布等功能存在兼容问题，后期以解决这些问题为主