1 UData-解决数据应用的最初一公里

1.1 背景

在大数据的领域，咱们经验了数据产业化的历程，从各个生产零碎将数据收集起来，通过实时和离线的数据处理最终会集在一起，成为咱们的主题域数据，下一步开掘数据的价值将成为要害。

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

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

UData外围聚焦数据利用场景，从数据利用倒推买通数据接入、数据管理、数据查问等环节。各种数据利用对于数据的应用形式，大部分分为两个场景：

  1. 利用在线及时拜访数据，大多数以接口的模式，UData平台绝对应的提供了数据服务的模块；
  2. 业务人员通过在线查找本人须要的数据指标（数据指标地图），可视化的进行人工数据分析和展现，UData平台同时提供了数据分析的模块。

1.2 UData性能架构图

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

1.3 Udata的数据管理

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

1.4 Udata目前能做什么？

1.4.1 指标配置化开发治理

  1. UData数据接入能够将内部数据实时或者定时的导入平台，同时平台提供了多种数据源的联邦查问；
  2. 在线可视化的创立数据指标，并对数据指标进行打标签；
  3. 数据指标地图使业务人员不便的查找本人须要的业务指标；
  4. 数据指标的开发，治理，应用，几个阶段互相拆散，职责划分更加松耦合，业务注意力更加聚焦；

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

  1. UData从底层数据源开始至最上层封装成为数据指标对外提供数据服务；
  2. 数据指标在UData中能够像积木一样通过可视化的形式进行任意组合；
  3. UData提供了接口编排能力，能够在指标组合根底之上，实现带有业务逻辑的分支条件判断；

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

  1. UData能够重用数据视图和数据指标，创立数据集，以此为根底向上进行数据分析；
  2. 数据集的配置反对SQL模式和可视化配置模式，别离针对不同SQL程度的剖析人员；
  3. 面向数据分析利用，以利用场景为单位进行数据和计算函数的治理和组织，场景可共享；
  4. 数据在线化实时剖析，无需线上导出数据；
  5. 在线Excel操作，长久化Excel模式，数据实时刷新，Excel报表在线共享;

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

2.1 引擎架构

Udata查问引擎基于StarRocks进行了局部革新，由两局部组成FrontEnd(FE),BackEnd(BE)组成。

  • FE：负责接管和返回客户端的申请，元数据和集群的治理，查问打算的生成和优化，协调BE进行查问。
  • BE: 次要负责SR表的数据存储和查问，内部表模式连贯三方存储，并执行查问打算中的具体节点，例如scan, 投影，聚合等。

执行主流程：

  1. FE收到Sql客户端发动的查问申请，解析sql并制订查问打算；
  2. FE下发执行打算到BE, 并指定一个BE为Coordinator;
  3. 各BE依照查问打算中的PlanFragment为执行单位，接管工作，实现工作，并将后果汇聚到Coordinator节点；
  4. Coordinator的BE节点将数据返回给FE;
  5. FE向Sql客户端返回后果；

2.2 从SQL语句到执行的过程

2.2.1 过程概览

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

2.2.2 举例介绍

表构造：

desc remote\_mysql\_decimal;

SQL:

select count(`decimal`) as sum,`key` from remote_mysql_decimal where id <= 1000 group by `key` order by sum desc limit 10;

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优化执行打算，进行谓词下推，Join order 调整等。
本实例中生成的Optimizer Plan如下：

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

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

2.3 数据的输入

2.3.1 PlanFragment在BE侧的映射

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

2.3.2 执行模型

1.火山模型/迭代模型 （ Volcano Model ）

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

2.物化模式/Materialization Model

这种模型的解决形式，依然是调用自顶向下，数据从底向上，然而每一个操作Operator一次性解决所有的输出，解决实现之后，将后果一次性向上输入。
此模式对于数据量较大的OLAP不太适宜，然而比拟适宜数据量较小的OLTP零碎。

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

这种模型和火山模型十分相似，不同之处是每个Operator的next()函数，会返回一批的tuples数据，相当于是一种批处理的模型，这是一种下面两种模型的折中形式。
SR的向量化执行器次要集中在算子向量化，表达式向量化，存储向量化；充分利用SIMD指令优化，CPU Cache敌对。

3 Udata查问引擎-联邦查问的加强

3.1 Udata查问引擎倒退的三个阶段

3.1.1 社区版FE + 自研JAVA版BE

Udata查问引擎的第一阶段，是参照StarRocks的C++版本BE实现了一个JAVA版本的BE,次要实现了Udata在第一个阶段的进行联邦查问的数据服务的工作，并且在第一个版本根底上，曾经实现了聚合计算的下推，同时也通过了618的考验，在执行引擎层面积攒了大量的教训，为咱们发展引擎革新的第二阶段提供了反对；

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 侧革新优化- Optimizer Plan 的转换

执行打算优化流程

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

模式匹配和打算改写

物理打算的树状封装：

ElasticSearch:

Mysql:

查问树改写：

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

2）BE 侧革新优化

针对执行打算进行了改写之后，同样在BE侧咱们创立了对应的Node节点，实现计算下推后的执行逻辑，向下对接内部执行引擎，同时向上对接相似join的聚合节点，最终输入后果数据。

3）原生SR兼容

同时执行层面，咱们设置了灵便的开关 （ set agg\_push\_down = 0 ），能够非常容易的敞开UData优化。

3.2.4 革新功效-（ 30秒 vs 6秒 ）

在咱们的理论过程中，咱们对于计算下推，尤其是多表聚合后关联的场景进行了察看测试，计算性能随着聚合表数目的减少，会有成倍数的成果晋升。

3.3 JSF&HTTP&ClickHouse的反对 - 京东生态的对齐

3.3.1 简介

JSF是京东外部的一种RPC调用服务，很多数据分析的场景中，一些维表是在其余服务中用JSF或者Http的形式提供的，或者一些曾经计算好的数据指标须要在咱们的UData计算引擎中进行关联查问，因而咱们减少了对于JSF和Http的反对，来作为京东生态的一个补充。

JSF和HTTP查问的两个关注点是如何将查问参数进行下推和如何将返回的结构化数据映射为表中的列数据，以便在联邦查问中进行数据关联和聚合。

同时，京东外部有不少应用ClickHouse的场景，咱们也进行了查问反对，ClickHouse反对TCP协定，http协定，mysql wire协定，目前Udata查问引擎通过Mysql wire协定和ClickHouse进行表面关联。

3.3.2 次要革新点介绍

  • 在FE侧，减少了JSF，HTTP，ClickHouse三种内部表对应的元数据结构，能够长久化内部表查问须要的底层引擎的属性信息；
  • FE侧RBO革新，对于SQL语法树对应的FromClause转换为对应的逻辑打算，并进一步转换为物理打算节点；
  • BE侧减少对应的ScanNode，进行数据查问；
  • 对于JSF和HTTP，通过函数，用于从FE侧将查问参数传输到BE侧实在的查问节点，查问参数下推，同时列的过滤条件在获取数据后，在Scan节点运行时过滤；
  • 对于JSF和HTTP，建表中减少Mapping，将返回的JSON数据映射到数据列；
  • ClickHouse内部表查问节点，能够反对两种模式，一般的scan查问和计算下推的Agg查问；

3.3.3 应用形式及案例展现

1）Jsf内部表应用

Jsf建表语句 ( 表构造+拜访JSF必须的元信息 )：

Mapping ( Jsf 返回的json字串与数据表构造的映射 )：

查问Sql语句 （ 查问参数下推 和 列表达式运行时过滤 ）：

下面的sql是用来查问Jsf表面的，同样的其余聚合函数都能够用于该Jsf表查问，下面次要有以下须要进行下阐明:

  1. 列表达式过滤：（ recv_count >= 1000 ) 这种过滤条件用于Scan操作获取到数据之后，在BE节点内运行时进行再次过滤；
  2. 查问参数下推： jsfparam函数内置于Udata查问引擎，能够通过此函数，将须要带入到Jsf调用中的参数从调用端始终传递到Jsf服务中，从而缩小数据的获取；
  3. 联邦查问：Jsf表同其余表面一样能够反对联邦查问，也同样能够反对其余表面反对的聚合等查问操作；

2）Http内部表应用

Http建表语句：

Http的建表语句同下面Jsf表，只是Properties有所变动，变成了http拜访的元信息。

查问函数：

  • httpconfig : 第一个参数是数据表中的某一个列名，前面是一个map, 目前仅反对 httpmethod 示意申请的形式 get/post ;
  • httpheader : 第一个参数是数据表中的某一个列名，前面是一个map, json构造，解析后，依照key=>value 的配对，放入http申请的 header中去 ;
  • httpbody : 第一个参数是数据表中的某一个列名，前面是参数，将间接放入http的申请的body中，这里须要留神的是 http申请的形式是 application/json , 还是 x-www-form-urlencoded ，两种形式body中的写法是不一样的，x-www-form-urlencoded 写法是 key1=value&key2=value2 ;

3.4 查问代理-使Udata查问引擎在实践上具备了查问所有的可能性

UData查问引擎目前反对的联邦数据源有Es, Mysql, Ck, StarRocks, Hive, Iceberg, Hudi 等，同时对于UData目前不反对的数据源能够通过代理插件的模式进行扩大，咱们提供了Udata Proxy的设计，只有遵循Udata代理提供的接口，实现对应的逻辑，来实现其余三方数据源的读取，便能够集成到UData查问引擎中，并和其余数据源一样能够实现一般查问和联邦关联查问。

3.4.1 批处理 vs 分页流式

Udata查问引擎减少了Proxy scan 节点，Scan节点和Proxy代理之间能够通过Http和RPC两种协定进行通信；

数据从Proxy传输到Scan节点有两种形式：

  • 批处理：一次性获取proxy返回的全副数据；
  • 分页流式：适宜数据量比拟大的场景，利用scroll_id的参数，使数据能够分页微批的形式流向scan节点，须要Proxy中逻辑代码也反对滑动查问；

3.4.2 逻辑读插件热插拔

任何异构的数据源能够通过逻辑读插件的模式来反对，Proxy runtime 提供插件的执行环境，并进行并行线程的治理，逻辑读插件能够通过Proxy治理端进行上传和治理，热插拔及时失效；

作者：刘敬斌 贺思远