Huawei FusionInsight LibrA (FI-MPPDB)是OLAP系统，从《openGauss数据库核心技术》这本书上的描述看LibrA就是GaussDB200，从openGauss的代码上看，openGauss的OLAP特性也是来自这个产品。

ABSTRACT

本文讲述FI-MPPDB的4个方面：

1. system availability：online expansion和online upgrade；
2. auto tuning：runtime feedback+machine learning；
3. SQL on HDFS解决方案；
4. modern computer systems：cost-based JIT；

1.INTRODUCTION

FI-MPPDB是sharenothing的MPP系统，基于Postgres-XC开发。支持行列混存，压缩，向量化等OLAP的典型技术。

2012年开始研发，2014年具备prototype。

1. V1版本：向量化和线程模型；
2. V2版本：支持列存，压缩，智能query调度，使用SCTP协议替换原来的TCP；

2016年FI-MPPDB支持SQL on Hadoop特性。类似HAWQ，FI-MPPDB直接读取HDFS和分区表这样能避免数据移动，兼容2008SQL标准，支持完整的ACID（借助本地heap表来实现）。

2017年FI-MPPDB在华为云售卖，也就是LibrA。

2. TECHNICAL DETAILS

2.1 System Overview

可以看到跨partition时通过2PC和GTM完成事务，这里有个fastpath的优化：只涉及到单个parition时无需过一次GTM。

2.1.1 Communication

为了避免连接风暴，每个节点上启动Communication Service：多个逻辑连接共享物理连接。

使用SCTP协议替代TCP：

1. message based的多地址连接协议；
2. 65535个streams共享一个SCTP连接；
3. 支持out-of-band的控制协议；

2.1.2 High Availability and Replication

为了高可用，每个DN节点都对应一个从节点， 此外，还多了一个log-only的副本：

1. 当secondary节点宕机，primary节点仍然可以继续服务，因为log-only节点仍能保证log的副本数；
2. 当secondary节点恢复后无需从primary上catchup；

2.1.3 Workload Management

1. 避免不同query竞争导致雪崩；
2. 调度：resource pools, workload groups, and a controller：所有query和resource pool关联，workload group负责管理workload并发新进来的query加入到resource pool中；如果query执行代价大于系统的剩余负载，当前query进行排队；

2.2 Online Expansion

2.2.1 Solution Overview

目标：在数据重分布过程中，原库仍然能够执行DML和查询

方法：

1. 原表进入appendonly模式；
2. 重分布过程中：append-delta数据；delete-delta数据；
3. 查询时使用上述3部分数据构造出真正可见的数据；

2.2.2 Core Algorithm

shadow表中新增隐藏列：original_tuple_key，用于删除迁移期间被删除的Tuple。

1. 原表T按照ctid分成一个个的segment，新增数据追加在T后面；
2. 对T逐个segment重分布到S中，过程中被删除的Tuple在D中，当迁移完这个segment时对D中记录的tuple进行删除，并清空D。注意：可能在复制后续segment时出现对前面segment中数据的删除；

2.3 Auto Tuning in Query Optimizer

FI-MPPDB的优化器能够：

1. 基于cost产生MPP的计划；
2. 感知向量化执行和不同底层存储的不同代价（ORC）；
3. 基于运行时反馈+machine learning适配更多优化场景（估算predicate selectivity）；

基于运行时反馈进行machine learning，这么做效果好的一个假设是OLAP的业务SQL都比较固定。

优化估算的行数和实际执行时反馈的行数收集是算子级别的：scan，join，agg。

PlanStore存储算子的反馈信息：算子类型+参数+predicate

如何使用PlanStore：

1. selectivity matching：对scan和join算子的统计数据估算；
2. similarity selectivity：对相似predicate估算
   predicate cache；
   KNN算法，K个最近邻居的平局值；

2.4 MPPDB over HDFS (aka SQLonHDFS)

2.4.1 SQLonHDFS using Foreign Data Wrapper

1. Gauss MPPDB Coordinator接收SQL；
2. Planner生成分布式计划，期间需要从HDFS的name node读取表的分布信息；
3. 分发plan fragment和task map；
4. data node从本地和HDFS远端读取；

HDFS上的优化：

1. HDFS一个目录对应一个FDW表；
2. 可以对表进行分区，一个子分区一个HDFS目录，因此可以做分区裁剪；
3. 对于ORC等格式，可以做下推；
4. 支持向量化；
5. 星型join做runtime filter优化；

2.4.2 Advanced Data Collocation and Hash Partitioning

（类似HAWQ)

1. FI-MPPDB的datanode在HDFS上的data node上，通过short-circuit直接读取HDFS数据；
2. 借助hash分区表对于co-locate的join能进一步减少网络；

每个datanode上的DB实例通过本地的表记录文件的owner和min/max元信息：block id, min/max, bitmap of deleted, block locater。

由于HDFS数据3副本存储，因此该本地的表也是3副本

2.4.3 DML support

通过block map表支持完整的ACID。

1. 写入：为了提高写入性能，小批量数据先写入本地的delta表，当积累到一定数量时再转成PAX根式写入HDFS中；
2. 删除：如果删除的数据在本地delta表中则立即删除；如果在PAX中，在block map表中的delete map做标记；
3. 定期做compaction；

2.5 Intelligent JIT Compiled Execution

3种执行模式：

1. 普通解释执行，没有JIT；
2. 有JIT，低级别优化；
3. 有JIT，O3级别优化；

JIT编译IR本身需要耗时，因此需要对JIT进行精确的cost计算，这样优化器才能决定是否对一个函数或者一段代码片段进行JIT。PostgreSQL的JIT目前还是静态的基于cost阈值来判断是否需要JIT，FI-MPPDB的处理算是一个创新性工作。

P = (T1− T2) × N − Tjit_cost

T1：没有JIT的代价；

T2：使用JIT优化后的代价；

N：数据集大小；

Tjit_cost：JIT本身消耗的代价，和待生成代码大小成正比；

如果P为正，则说明使用JIT之后仍然有收益；

3. EXPERIMENTAL RESULTS

3.1 Online Expansion

运行TPC-DS期间进行扩容

结论：

1. online expansion整体比offline方式慢，但是期间仍然能够查询和DML;
2. hash分布比随机分布快20%；

3.2 Auto Tuning in Query Optimizer

select o_orderpriority, count (∗) as ct
from lineitem, orders
where l_orderkey = o_orderkey and
l_receiptdate <op> l_commitdate + date ':?';

大多数优化器在预测predicate selectivity时采用固定的比例，比如使用1/3做为selectivity。

下图是实际的selectivity数值：

3.2.1 Hash join plan problem

对于hashjoin，选择正确的表来build hash是优化器的关键所在。

基于machine learning之所以能提升性能：不同的predicate会导致scan出来的数据有很大的差异，进而会影响join的顺序。可能很大的表在经过predicate之后scan出来的结果集很小。

3.2.2 Unnecessary data shuffle

HDFS的数据分布是按照round robin来进行的，因此，不具备co-located。数据需要shuffle：

1. 对其中一个表broadcast；
2. 两个表都hash分布；

predicate selectivity的估算影响数据shuffle的策略。

3.2.3 Insufficient hash buckets for hash aggregation

predicate selectivity的估算还会影响hashjoin时bucket的预分配。如果bucket不足时就需要重分布，2倍的性能差距。

3.2.4 Join Selectivity Experiment

前面讲述了Table scan selectivity learning的效果，此外，该方法还能用于评估join predicate selectivity。

在join时对join的条件selectivity 的估算也很重要，影响多个表的join顺序。

3.3 Cache Model-based Selectivity Estimation

结论：

1. 单个参数，评估的错误比率不超过4%；
2. 2个参数，评估的错误比率不超过6%；
3. 即使predicate cache很小，错误比率也不高；

3.4 Advanced Data Collocation Performance Improvement for SQLonHDFS

结论：在HDFS上支持hash partition之后能显著减少shuffle，TPCH测试能提升30%。

3.5 Intelligent JIT Compiled Execution

结论：

1. 基于cost的JIT能够选择出最后的优化级别；
2. TPCH整体29%的提升；

4. RELATED WORK

Online Expansion

1. Greenplum：扩容时提供queyr，但阻塞DML；
2. Amazon Redshift：老clsuter进入readonly；

Auto Tuning

SQL Server和DB2也有autotuning的功能，专注在predicate selectivity和column correlation。没有支持通用算子的selectivity，比如：join。

FI-MPPDB基于learning的方式更加简介：基于运行时真实的反馈来估算每个算子，使用predicate cache和KNN提供了similarity selectivity的估算。

SQL on HDFS

1. HAWQ：实现了直接读写HDFS和YARN的库来提高性能；
2. SQL Server PDW：支持SQL直接管理和读取Hadoop集群，同时支持索引来加速查询；
3. Spectrum：支持广泛的数据源，比如：ORC，Parquet，CSN；

Intelligent JIT Compiled Execution

1. Amazon Redshift and MemSQL：SQL转成 C/C++；
2. Cloudera Impala and Hyper：使用LLVM IR，没有精细化的代价模型；
3. Spark 2.0’s Tungsten：通过运行时字节码优化将query转成单个函数；
4. FI-MPPDB：使用LLVM，并且有精心化的代价模型；

5. FUTURE WORK AND CONCLUSION

1. 云原生：支持多种云存储，SQL on OBS/S3；
2. 智能调优：selectivity learning和parameter learning；