概述

SQL，全称Structured Query Language，是当今使用最广泛的数据查询语言。最初的设计仅仅是适用于RDBMS，可是随着数据底层存储结构设计的大爆发，越来越多的数据存储引擎支持SQL查询。甚至于支持SQL查询几乎可以定义为这个数据存储引擎能否广泛应用于生产环境的一种标准，最典型的案例就是Hive。Elasticsearch和Druid虽然原生不支持，但从官网发布的消息来看，SQL支持正在计划中。

只可惜ANSI针对SQL仅仅是提供了一种标准，数据存储引擎均在此基础上做了不同的发展演化。发展至今，不同引擎的SQL差异化愈发明显，数据分析人员必须学习使用不同的SQL语言来适应不同的数据存储生产环境，这本身就违背了SQL设计的初衷。另一方面来说，不同数据存储引擎间因数据结构的差异，不能将数据放在一起进行计算探索，这也极大的限制了数据分析人员的分析成果可能性。

于是，Quicksql（简称QSQL）诞生啦！

日益复杂的场景让业务加工数据效率低下

360 内部有很多业务线，除了大家平时熟知的 PC 安全卫士、360 浏览器、360 搜索以及移动端的手机卫士等应用软件之外，还有很多其他领域的业务产品。下图为整个公司从资产角度呈现出的业务线概况。

从图中可以看到，公司内业务方向主要分为搜索、安全、视频信息流、游戏、金融和 IoT 六个领域，以这些领域为核心由向外衍生出诸多产品，这些产品每日新增打点数据 300T+，换算后有接近 100 亿 + 条记录，覆盖用户数达到 10 亿 +。由于业务对数据的使用场景在时延和量级上有不同的需求，所以数据往往分散存储在诸多存储介质上，在进行数据产出时需要抽取合并不同介质的数据，以公司内部场景为例。

某业务线要处理一定周期内各渠道活跃、下载数据的指标，由于渠道信息数据量较小，且往往会涉及频繁增删改，这部分数据通常存放于 MySQL 中，而用户的活跃下载数据实时打点写入，最终会落地 HDFS，一旦两部分数据需要关联分析时流程通常很冗长，对于业务人员而言处理难度较高。此外，在用户画像的场景下，由于行为数据和属性数据处于异构数据源，业务人员也会面临类似的问题，导致处理数据的效能低下。

使用统一的抽象屏蔽底层计算存储细节

针对业务痛点进行深入分析后，数据分析人员的技能树通常向两个方向发展，一类是技术型，Spark、Flink 信手拈来，Python、R 语言一日千行，他们对业务和数据的理解可能不深入，但他们一定懂得怎样快速清洗加工数据；另一类是业务型，线性回归、残差网络各类算法应用自如，方差期望、概率分布准确求解，他们对技术栈的了解可能不完备，但他们可以从海量数据中抓出关键的信息打动老板。

然而，日趋复杂的数据分析场景逐步提升了处理数据的难度，如果底层数据处理平台无法跟随场景进行演进，业务会陷入数据加工细节，导致产品迭代速度变缓，最终湮没在互联网快速迭代的大潮中。

因此，我们考虑对外提供统一的查询范式，屏蔽底层数据源和操作细节，让业务人员摆脱加工数据的技术束缚，不论是对成本控制还是效率提升都是一本万利的事情。

二次解析衔接所有数据源和引擎

对于统一查询的场景，我们参考了业界已有的引擎，调研发现：受限于当下计算体系结构，每一种引擎都存在优劣势。面临选择的场景，我们考虑使用动态调度的思想，使用 Apache Calcite 作为上层解析器，通过多一次解析搞清楚用户的查询意图，再向对应引擎解释路由，让合适的引擎做合适的事儿。

QuickSQL 对外提供统一标准的 SQL，针对联合查询进行了逻辑树级别优化，与引擎完全解耦合，可在运行时动态选取引擎执行。业务通过统一的 SQL 门面，能够处理各类复杂的数据加工场景。其基础架构如下：

QuickSQL 对外提供多种接口，用户可以直接通过 CLI 进行分析，也可以在平台中通过其他接口进行远程调用。

整体架构包含三层：解析层，解释层和运行时层。

解析层主要通过与元数据库交互进行语句解析和校验，结合独立的权限系统，可以在校验时进行表和字段级别的权限判断。解析生成的逻辑计划会经历联邦查询优化和逻辑树切分。切分后的逻辑子树由解释层进行方言解释和语句路由。对于特定源的查询直接由 JDBC 完成，混查场景则借助 Spark 或 Flink 作为分布式计算中间引擎进行数据周转处理。运行时层提供了下推语句的预聚合及抽取计算。

以上图中混查场景为例，语句包含两张同库 Hive 表，一份 Elasticsearch 的 index。

经过词法语法分析后，生成右图虚线连接的原始逻辑计划树，在联邦查询优化场景下，针对这棵不寻常的逻辑树进行分析优化，采用后序遍历的方式，根据定义好的切点类型在指定位置进行切分。

切点的类型包含：1. 跨数据源，跨库的关联或子查询；2. 数据源不支持的操作和函数。

切分后再向切点处补足相对应节点使各逻辑计划整体完整, 经过切分后的逻辑计划会成为计划森林，包含一个父计划和多个子计划，针对每个逻辑计划再向相应数据源的方言进行转换，由中间计算引擎的临时表查询能力进行数据汇总和再加工。

应用统一查询门面构建交互式查询引擎

QNote 是数据中心基于统一 SQL 查询引擎开发的交互式分析平台，主要面向数据分析、产品、运营和开发人员，通过统一的 SQL 语法对各类数据源包括 Hive、MySQL、Elasticsearch 等进行查询，基于底层查询引擎 QuickSQL，用户还可以进行跨源、跨库关联查询，甚至可以二次导入 CSV 文本与其他数据源进一步关联分析，能够覆盖绝大多数查询分析场景。

QNote 的业务架构图如上，主要包含三层：查询服务层，混合计算层，运行时层。

查询服务层主要提供用户侧与查询交互相关的功能，包括查询管理、监控大盘、编辑器、订阅服务及例行化调度等。

混合计算层主要分为两部分，一部分为执行器代理，主要对查询服务提供 SDK，帮助外部服务理解 SQL，并进行初步校验。另一部分为执行器，主要针对用户大批量的查询进行资源调度，统一解析，和状态同步等。两部分由中间消息队列作衔接，达成负载均衡和双向解耦。

运行时层包含所有接入联邦查询的数据源，各数据源提供语句的下推执行和结果抽取。

技术架构

查询服务，消息队列和执行器代理三部分共同支撑整个交互式查询平台，查询服务与执行器的交互间接通过向队列投掷 SUBMIT，CANCEL 消息来完成，由执行器代理拉取消息并调度资源进行处理，结果集回写公共存储。

此外，双端都会注册至 Eureka，由 Eureka 对多实例进行心跳检测。该架构基本解决了之前遇到的问题，达成服务与计算分离，查询全并行，资源充分利用等目的。

实际场景中的统一查询性能怎样？

上面四张图展示了 QuickSQL 统一查询的性能比较，由于 QuickSQL 会牺牲一次解析的时间辅助查询，所以在 MySQL 和 Elasticsearch 的查询中会慢 0.5 s，在 Hive 查询中由于底层使用了 Spark-Hive 作引擎，因此性能会稍优于 Hive 原生查询。

最后一张图展示了在混查场景下的性能比较，可以看到在处理 MySQL 和 Elasticsearch 的关联查询时，由于数据源自身具备索引，QuickSQL 能够充分利用数据源本身的能力实现下推执行，性能会远远优于 Hive 数据源与其他数据源在同等规模数据下关联的性能。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~