UData查询引擎优化如何让一条SQL [复制链接]

1UData-解决数据使用的最后一公里

1.1背景

在大数据的范畴，我们经历了数据产业化的历程，从各个生产系统将数据收集起来，经过实时和离线的数据处理最终汇集在一起，成为我们的主题域数据，下一步挖掘数据的价值将成为关键。

数据应用直接体现数据的价值，数据应用多种多样，它们使用数据的方式也各不相同，UData作为数据资产和数据应用之间的桥梁，它的第一目标是解决所谓的数据使用的最后一公里问题。

UData平台以数据指标为基本的管理单位，通过四个阶段对于数据使用提供支持，一体化整合数据链路的整个生命周期，接数据、管数据、找数据、用数据。

UData核心聚焦数据应用场景，从数据应用倒推打通数据接入、数据管理、数据查询等环节。各种数据应用对于数据的使用方式，大部分分为两个场景：

应用在线及时访问数据，大多数以接口的形式，UData平台相对应的提供了数据服务的模块；

业务人员通过在线查找自己需要的数据指标（数据指标地图），可视化的进行人工数据分析和展示，UData平台同时提供了数据分析的模块。

1.2UData功能架构图

上图，UData功能架构自底部向上，包含了数据流转使用的整个过程，平台内的功能模块从数据使用的流程角度，完整的涵盖了数据使用最后一公里的整个生命周期。

1.3Udata的数据管理

UData对于数据的使用，从物理和逻辑两个层面进行了划分，并且对于多个租户同样进行了资源和计算的隔离。

1.4Udata目前能做什么？

1.4.1指标配置化开发管理

UData数据接入可以将外部数据实时或者定时的导入平台，同时平台提供了多种数据源的联邦查询；

在线可视化的创建数据指标，并对数据指标进行打标签；

数据指标地图使业务人员方便的查找自己需要的业务指标；

数据指标的开发，管理，使用，几个阶段相互分离，职责划分更加松耦合，业务注意力更加聚焦；

1.4.2指标积木式编排和接口服务

UData从底层数据源开始至最上层封装成为数据指标对外提供数据服务；

数据指标在UData中可以像积木一样通过可视化的方式进行任意组合；

UData提供了接口编排能力，可以在指标组合基础之上，实现带有业务逻辑的分支条件判断；

1.4.3指标及明细交互式关联分析和协同分享

UData可以重用数据视图和数据指标，创建数据集，以此为基础向上进行数据分析；

数据集的配置支持SQL模式和可视化配置模式，分别针对不同SQL水平的分析人员；

面向数据分析应用，以应用场景为单位进行数据和计算函数的管理和组织，场景可共享；

数据在线化实时分析，无需线上导出数据；

在线Excel操作，持久化Excel模式，数据实时刷新，Excel报表在线共享;

2Udata-查询引擎执行介绍-一条SQL的旅行

2.1引擎架构

Udata查询引擎基于StarRocks进行了部分改造，由两部分组成FrontEnd(FE),BackEnd(BE)组成。

FE：负责接收和返回客户端的请求，元数据和集群的管理，查询计划的生成和优化，协调BE进行查询。

BE:主要负责SR表的数据存储和查询，外部表形式连接三方存储，并执行查询计划中的具体节点，例如scan,投影，聚合等。

执行主流程：

FE收到Sql客户端发起的查询请求，解析sql并制定查询计划；

FE下发执行计划到BE,并指定一个BE为Coordinator;

各BE按照查询计划中的PlanFragment为执行单位，接收工作，完成工作，并将结果汇聚到Coordinator节点；

Coordinator的BE节点将数据返回给FE;

FE向Sql客户端返回结果；

2.2从SQL语句到执行的过程

2.2.1过程概览

用户通过Mysql客户端工具或者JDBC等方式，将需要执行的SQL语句进行输入，输入后的SQL语句经过语法解析，Binder,Transformer,Optimizer等过程，从基础的sql语句，经过语法树，Relation，逻辑计划，分布式物理计划等过程，最终在FE端通过Coordinator发送到BE侧进行执行，并后续收集BE返回的数据，返回给调用客户端。

2.2.2举例介绍

表结构：

descremote_mysql_decimal;

SQL/p>

selectcount(`decimal`)assum,`key`fromremote_mysql_decimalwhereid=groupby`key`orderbysumdesclimit10;

2.2.3执行过程详解

1.解析SQL语句

在这一步骤中，SQL语句会进行语法检查，不符合规范的语句返回错误，之后经过语法解析，会生成一个抽象语法树，上面实例中的SQL语句（语句中有聚合，排序，谓词条件，limit等元素）生成的语法树结构如下：

2.绑定数据表元数据信息-生成Relation

生成语法树之后，只是单纯的SQL语法信息，在SR中FE有一个重要的作用，就是保存数据表的元数据信息（库名，表名，列名，数据类型，对应的外表）等。在这一步骤中，会将抽象语法树和FE中的元数据信息（Catalog）进行关联，丰富SQL相关的信息，将抽象语法树生成Relation这种数据结构。

3.Transformer-基于RBO,进行Rewrite生成逻辑执行计划

从Relation到逻辑计划，只是基于一些SQL改写规则，将树中的一些节点转变会逻辑计划节点。

如：

FromClause会转换为逻辑计划中的LogicalScanOperator这种扫表操作；

WhereClause会转换成逻辑计划中的LOGICAL_FILTER，指导后续进行进行条件过滤；

OrderByElements会转换成逻辑计划的LOGICAL_TOPN，指导后续进行排序和limit;

SelectList会转换为逻辑计划的LogicalProjectOperator，指导后续进行投影操作，减少网络数据传输;

本实例中的SQL会生成如下的逻辑计划：

4.Optimizer-基于CBO优化

在这一步骤中，会根据上一步生成的逻辑计划，同时结合FE中保存的元数据信息，基于CBO优化执行计划，进行谓词下推，Joinorder调整等。本实例中生成的OptimizerPlan如下：

5.分布式物理计划的生成-BE执行的并行单位（PlanFragment）

BE是分布式的，查询实际执行的时候，会将计划分配给具体的BE。BE之间，BE和FE之间通过RPC通信传输数据，BE执行的最小并行单位是Fragment,在这一步骤中会生成分布式的物理计划。本实例SQL生成的分布式物理计划如下：

2.3数据的输出

2.3.1PlanFragment在BE侧的映射

物理执行计划切分成PlanFragment之后，会发送到BE侧执行，BE会根据Fragment中的树形结构，生成对应的Node，完成各自的算子逻辑，算子之间通过不停的调用下层算子的get_next()函数，将数据用chunk的形式进行组织并流动起来，chunk的数据结构是一种列式的批结构，非常有利于向量化的执行。

2.3.2执行模型

1.火山模型/迭代模型（VolcanoModel）

在这种模型中，每一种操作会抽象成一个Operator,在执行侧作为一个操作数，从顶到下调用next()接口，数据从底部的scan节点向上传输，但是每次只传输计算一条数据，也叫做（Tuple-at-a-time）,是一种拉取执行模式。优点：每个Operator可以单独实现逻辑，比较单间，灵活。缺点：每次传输计算一条数据，导致next()函数调用次数过多，cpu效率低。

2.物化模式/MaterializationModel

这种模型的处理方式，仍然是调用自顶向下，数据从底向上，但是每一个操作Operator一次性处理所有的输入，处理完成之后，将结果一次性向上输出。此模式对于数据量较大的OLAP不太适合，但是比较适合数据量较小的OLTP系统。

3.向量化模式/批处理模型（Vectorized/BatchModel）

这种模型和火山模型非常类似，不同之处是每个Operator的next()函数，会返回一批的tuples数据，相当于是一种批处理的模型，这是一种上面两种模型的折中方式。SR的向量化执行器主要集中在算子向量化，表达式向量化，存储向量化；充分利用SIMD指令优化，CPUCache友好。

3Udata查询引擎-联邦查询的增强

3.1Udata查询引擎发展的三个阶段

3.1.1社区版FE+自研JAVA版BE

Udata查询引擎的第一阶段，是参照StarRocks的C++版本BE实现了一个JAVA版本的BE,主要完成了Udata在第一个阶段的进行联邦查询的数据服务的任务，并且在第一个版本基础上，已经实现了聚合计算的下推，同时也经过了的考验，在执行引擎层面积累了大量的经验，为我们开展引擎改造的第二阶段提供了支持；

3.1.2原生StarRocks+Udata改进

鉴于StarRocks表的优异性能，我们将查询引擎切换回原生的SR,同时将之前的积累的优化经验，在原生SR上进行了实现，包括聚合查询和Sort排序的下推，额外支持了外表数据源CK,Jsf,Http，进行了查询函数format等的丰富。

3.1.3未来探索方向

在下一个阶段，Udata查询引擎将会在SR的基础之上，密切地配合社区，引入新版本的功能，同时进行数据湖的使用探索和高性能的点查实践，以及跨SR集群的联邦查询等。

3.2计算下推-极限压榨底层引擎的计算能力

3.2.1优化背景

StarRocks在联邦查询方面针对MySQL,ElasticSearch已经有了非常快的性能，StarRocks在联邦查询方面的设计思想是针对不同的查询外部数据源，设计不同的Scan节点，并且尽可能的将谓词下推到Scan节点，在Scan节点查询到数据之后，上层会共用Project节点，Agg节点，TopN等这些节点的算子，基本的查询架构类似下图。

这种设计使StarRocks有非常好的扩展性，可以很容易的扩展到新一种的数据源，也正是这种高度可扩展的设计使我们有机会在联邦查询的细节层面，做进一步的优化，比如将一些算子的计算也尽可能的推到外部表引擎，可以节省一部分网络传输的时间，同时最大程度的压榨底层引擎原生计算能力，通过我们的测试这种计算下推也达到了数倍于原来的性能。

3.2.2优化范围

在优化之前我们针对底层引擎和算子的特征做了调研，优化的范围包括如下：

针对ES引擎，进行了聚合算子的下推，但是某些特殊算子排除，不支持sum(distinct),avg(distinct)算子下推；

针对MySQL引擎和ClickHouse，进行了聚合算子，TopN算子的下推；

针对新增加的Jsf和Http，进行了查询参数下推，运行时列过滤；

3.2.3整体优化思路

目前整体的优化思路，主要分为两个部分，FE侧的改造和BE侧的扩充，同时对于原生StarRocks计算方式保持兼容，可以轻易的切换回原来的计算模式。

1）FE侧改造优化-OptimizerPlan的转换

执行计划优化流程

目前Udata查询引擎对执行计划进行优化的节点是在原来的Optimizer之后，我们从Scan节点开始对于执行计划，进行了模式匹配，命中模式之后，进行对应的计算下推和投影的合并，同时过滤底层引擎不支持的特殊算子（如ES的sum(distinct)），最终将转变后的物理计划发送给BE侧进行执行。

模式匹配和计划改写

物理计划的树状封装：

ElasticSearch/p>

Mysql/p>

查询树改写：

最终，AggScanOperator会转变为AggNode,发送到BE进行执行。

2）BE侧改造优化

针对执行计划进行了改写之后，同样在BE侧我们创建了对应的Node节点，完成计算下推后的执行逻辑，向下对接外部执行引擎，同时向上对接类似join的聚合节点，最终输出结果数据。

3）原生SR兼容

同时执行层面，我们设置了灵活的开关（setagg_push_down=0），可以非常容易的关闭UData优化。

3.2.4改造成效-（30秒vs6秒）

在我们的实际过程中，我们对于计算下推，尤其是多表聚合后关联的场景进行了观察测试，计算性能随着聚合表数目的增加，会有成倍数的效果提升。

3.3JSFHTTPClickHouse的支持-京东生态的对齐

3.3.1简介

JSF是京东内部的一种RPC调用服务，很多数据分析的场景中，一些维表是在其他服务中用JSF或者Http的方式提供的，或者一些已经计算好的数据指标需要在我们的UData计算引擎中进行关联查询，因此我们增加了对于JSF和Http的支持，来作为京东生态的一个补充。

JSF和HTTP查询的两个