导读
本次分享主题为转转 One-Service 数据服务体系建设，主要介绍转转在建设数据服务体系过程中的三个阶段，其中将详细介绍 One-Service 统一查询服务建设思路。
主要内容包括以下几大部分：
- 转转数据服务发展历程
- One-Service 查询服务建设
- 未来规划
一、转转数据服务发展历程
在第一阶段，随着业务增长与人力资源的紧张，为了满足各个业务线的数据需求，快速的使用统计数据做数据分析，本阶段产生的数据结果大多以Excel或者数据统计到库的方式提供数据，对外提供分析或者对接应用。此阶段目标是快速产出数据结果，为业务决策提供数据支撑。
第二阶段随着业务的发展，分析数据的需求不断的增多，分析的要求也更多样化。针对不同主题下的数据，我们开发了各个主题的应用报表、多维分析报表，用来支持业务多样化的分析的诉求。虽然在一定程度上解决了业务使用数据的痛点，但是在数据查询服务上各做各的，不同的主题对应不同的查询服务后端，形成了来一个主题开发一个主题的查询服务的烟囱式开发模式。
第三阶段是统一查询服务One-Service，为了解决阶段二暴露的问题，避免重复开发降低开发工作量，打造支持各类数据存储的数据查询服务，提供统一、稳定、便捷、安全、可控的数据查询出口，我们针对不同的主题数据形成的数据集，设计和实现了一套统一的数据服务，可以完成所有主题数据服务的查询，并提供支持不同的协议以在不同的使用场景中使用。
接下来，将详细介绍统一查询服务实现的具体细节。
二、One-Service 查询服务建设
2.1 背景
在日常的数据开发过程中，我们会把数据结果存储在各类数据库中或者导入到OLAP查询引擎中供上层应用使用。对于不同的数据库和OLAP引擎上层应用都要自行构建查询服务处理各自的数据逻辑，存在大量重复的开发工作，因此为了提升数据使用效率、减少重复性开发工作、降低开发成本，我们在各类存储引擎的基础上需要开发一套统一的数据查询服务。
2.2 系统目标
目标：打造支持各类数据存储的数据查询服务，提供统一、稳定、便捷、安全、可扩展的数据查询出口。
需要支持常用的OLTP与OLAP数据存储引擎，比如MySQL、Kylin、Druid、Clickhouse、StarRocks等，所有数据出口由同一套查询服务支持，并且需要保证服务的可控、稳定、安全，对接BI需求、数据服务、数据应用工具开发等上层各类数据应用场景。
2.3 整体架构
针对之前阐述的系统背景要求与目标，我们设计了一套统一查询服务One-Service，打通了基础数据平台中的元信息，通过配置管理数据源、数据集的方式来应对不同的多样性数据需求。并且接入了权限管理平台，支持对数据集进行权限管理与配置。在服务本身设计了一些服模块功能模块，权限控制模块、查询历史记录、监控告警模块等功能来辅助完成相应的系统要求。
- 基础数据平台：根据基础数据平台维护的各类表与指标的元信息，通过配置生成不同业务的数据集；
- 管理后台：包括数据源管理、数据集管理、数据权限管理。数据集管理是把不同的数据源的数据抽象成一个数据集合，根据存储引擎的不同采用对应的组合与配置方式，比如支持SQL的存储引擎，可以通过SQL来生成对应不同业务的各类数据集，并且可以通过子查询来形成不同的数据集来多样化支持不同场景与需求，同时各类字段格式转换、特殊过滤条件处理都可以放到数据集中进行配置处理；
- 权限管理中台：通过话权限管理平台，用来对用的数据集权限进行管理，查询平台权限管理粒度为数据集；
- 查询服务：包括查询接口服务、后台管理服务、存储引擎查询器，以及其他辅助功能。针对不同的存储引擎会有与之对应的查询器进行数据查询支持。
2.4 查询引擎设计
在查询引擎方面，因为我们要支持不同的查询引擎进行查询，所以我们抽象出了一些抽象类，其中有通用统一的Map类型数据源参数、数据集参数、通用的接口调用方法等，通过继承查询器抽象类的方式实现各类存储引擎的查询器，可以方便的对查询器进行管理、扩展与功能开发。同时针对不同的查询引擎可以做定制化的查询控制与优化。查询器抽象类抽象方法大致如下：
- getSchemas 获取库信息
- getTables 获取表信息
- getDatasetDetail 查询数据集配置
- queryDimVals 查询维度信息
- queryAggData 查询数据
- viewAggDataQuery 查询生成查询sql或者执行计划信息
- getAggregateDataDownload 同步下载数据
- getDataDownloadAsync 异步下载数据接口
统一查询参数cfg设计与查询信息封装：上层应用通过数据集元信息，根据查询场景生成组装Json格式的查询参数，包括维度、过滤、聚合、指标查询信息。后端收到对应数据集与查询信息组装对应查询逻辑，然后调用查询接口对数据进行查询与结果返回。参数示例如下：
{
"rows": [
{
"columnName": "date",
"filterType": "eq",
"values": []
},
{
"columnName": "channelname",
"filterType": "eq",
"values": []
}
],
"filters": [
{
"columnName": "date",
"filterType": "=",
"values": [
"2023-05-10-00"
]
}
],
"values": [
{
"column": "active_count",
"aggType": "sum"
}
],
"pageSize": 10,
"pageNum": 1
}常用查询参数简要说明：
- rows字段为group by的维度
- filters为过滤条件，支持各类过滤条件定义表达
- values为查询指标 aggType支持：count、sum、avg、max、min、distinct、raw原始值
- orders为排序属性，columnName为列名，orderType为排序升序降序值为 ASC、DESC
- pageSize 页面行数
- pageNum 页码
前端或者后端开发，通过数据开发配置的数据集信息，可以快速的生成自己的场景查询的cfg配置，然后把请求发送到统一查询服务上，服务会根据数据集配置的数据源信息，获取到对应数据存储引擎的查询器，然后把对应的查询配置参数通过逻辑转换成对应引擎的查询逻辑，完成数据查询并组装会返回结果。
至此我们基本完成了One-Service核心功能的设计，当有新的查询引擎需要支持的时候，我们通过继承对应的抽象类，完成相应的方法即可以对该查询引擎的数据进行查询，开发工作量相对比较小，可以快速支持新引擎，截止目前我们已经完成了大多数引擎的查询支持。对于具体的复杂的应用场景，我们可以通过数据开发的结果表，配置生成不同的数据集来做二次逻辑加工，来支持多样的数据需求。同时我们开发了https、微服务两个数据查询服务版本方便于前端、后端开发人员对接数据需求。
2.5 数据安全
数据安全管控对于保护数据资产、维护数据完整性和合规性至关重要。通过数据安全管控，企业可以降低数据泄露、滥用和损坏的风险，确保数据安全。
在数据安全方面，目前控制到数据集粒度。整体上通过两种方式来管理：
- 一个种是对接了权限认证的系统，用户登录之后通过配置的用户角色与数据集对应关系来管理用户对应的数据集权限，在用户进行数据查询请求时后端服务会校验用户权限，对没有对应数据集权限的查询请求进行拦截；
- 另一种没有用户认证的情况，采用授权码的方式来控制用户数据集的访问权限，这种情况一般多用在内部的后端服务调用上，保证后端在使用查询服务的情况下依然有权限管控，不能看到权限以外的数据集信息。
同时在系统中，有对应请求的查询记录信息和监控告警模块，对于异常查询、鉴权异常、慢查询等进行相应的监控，可以通过告警或者限流的方式筛选出异常查询情况并做出相应的处理，来保证系统的稳定与数据的安全。
2.6 智能查询
在服务投入使用的过程中，我们发现很多请求其实请求的结果数据量级很小逻辑很轻，这种请求如果都发送到OLAP的引擎中进行查询，在早高峰资源占用紧张的情况下也会受到影响，影响用户查询体验。而且各种数据库或者OLAP引擎都有着各自适用的场景，目前针对大数据并没有一个完美引擎，因此在这套查询体系里为了最大化用户体验，提升查询效率，设计根据数据集优先级，以及查询条件自动选择最适合的查询引擎来进行数据查询与加载。
- 底层宽表：比如我们在Hive当中有订单主题的宽表，我们会按照业务分析场景，把宽表拆成最常用分析维度数据集，较常用维度数据集，全量数据集等数据集；
- 数据子集：根据宽表与分析场景的情况，我们会配置定义出各类数据分析子集，分析场景下的全量数据集会存储在ClickHouse当中进行最后命中查询，不同维度的子集与存储引擎可以多对一进行任意优先配置与组合；
- 优先级：根据分析场景与数据量级大小，把最常用的数据集按照引擎特性分别存储在不同的数据库或者OLAP引擎当中，根据查询性能、数据量级的不同常规优先级 MySQL（高）-> Kylin(中) -> ClickHouse(低)；
- 引擎选择器：当我们查询某一个数据集的时候，会去判断该数据集所属数据集组，在改组下有各种维度不同存储引擎下的数据集，再根据查询条件按照配置好的优先级顺序，进行匹配查询。追求最好的查询效率。
这是一种常用的处理方式，用存储空间换取查询效率与用户体验的方案，这个方案中在不同的引擎里会冗余不同维度的子数据集数据，具体的都要视查询场景与数据集特点进行拆分优化，充分利用每个引擎的特点与优势，来提供更快更稳定的查询体验。
2.7.平台建设
在系统核心功能完成之后，在易用性上我们基于该服务建设了管理功能与自助分析平台。整体如上图所示，我们可以查看自己有权限的数据集，并对数据集的数据进行自助分析，选择维度过滤，确定查询的指标与分组的维度进行自助的数据查询与分析。同时展示了对应的查询参数cfg参数与最终生成的查询SQL，方面前后端开发人员快速上手使用该查询服务，提升开发效率。
至此通过该系统基本上解决了数据查询服务统一的问题，在统一的指标管理、数据集管理的体系下，保证了数据出口逻辑的一致性。并且该系统可以支持横向扩展来适应更多的查询请求。完成支持各类数据存储的数据查询服务，提供统一、稳定、便捷、安全、可扩展的数据查询出口统一查询服务One-Service系统。
三、未来规划
- 权限管理细化：主要是要以更细的粒度管控数据权限，把数据权限控制到指标字段级别，进一步保证数据使用的安全。并且在异常请求访问拦截上增强识别能力，通过多种手段及时干预防止发生数据泄露等情况。
- 多引擎支持：目前已经支持了大部分的OLAP的存储分析引擎，后续考虑到应用场景的多样性，准备接入Redis、ElasticSearch等存储引擎，扩展服务使用场景。
- 线上服务化：目前各个查询之间没有做资源隔离，对高QPS高稳定性要求的场景不能够很好的支持，如果同时有一些大查询在处理，那么势必会对其他查询有一定的影响，所以为了满足上面的场景需要对查询资源进行隔离或者划分服务等级，来区分使用场景区别对待，使统一查询服务能够直接对线上提供有保障的查询服务。因为要对接线上的查询服务，所以对系统稳定查询稳定有了更高的要求，要对各个查询性能进行监控与有针对性的优化，从而保障服务的稳定。
- 易用性：在目前的使用过程中由于前后端都需要根据使用场景生成cfg查询参数，虽然提供了一些图形化工具来帮助快速生成，但是也有一定的沟通和理解成本，为了提升开发效率，打算支持预制查询参数组合，让前后端在使用的时候可以简单的通过设置属性值的方式来完成传参，整体上更易于理解，不用关心cfg参数具体的格式和各种拼接规则，采用常规的方式来调用查询更直接更简单的使用查询服务，提升易用性。同时完善自助分析的功能，增加更多的展示形式，优化操作逻辑，让使用数据集进行自助分析取数变的更简单更智能，提升用户体验与数据分析效率。
