近两个月转到了计算引擎领域, 为公司开发兼容PG的新的向量化计算引擎, 所以一直处于高强度的学习以及开发过程,也没有来得及做一些总结.
之前的背景都是存储, 包括NoSQL存储(Rocksdb/FoundationDB)以及做了一年半的数据库内核存储(PostgreSQL), 这个过程对于存储相关的知识也有了较为系统的积累并且对相关的工业界产品也有了一些全新的理解.
公司内部转到计算引擎的背景还是起源于 解决PostgreSQL JIT 内存上涨问题以及 修复 GreenPlum JIT bug时的一些计算相关的探索, 发现计算领域更为抽象, 要解决的问题也更为有趣且通用. 而且公司内部也提供了这样兴趣驱动的机会,所以毅然投入到了数据库领域中又一个新的领域 查询执行(计算引擎). 当然, 查询优化则更为抽象、更独立. 按照个人的规划, 在当下的计算引擎的项目未完全落地前并不会考虑新的方向了.
目前公司做的产品方向也是跟随主流的数据库发展方向: 分析型数据库. 当然查询执行器也是需要支持分析型的计算引擎. 这个过程的本质是在列存储的存储格式上尽可能高效得完成数据分析, AP场景对数据的操作更多得是 AGG(聚合操作: sum/count/avg等等). 这样的一个计算引擎涉及到的技术栈主要包括:
最主要的是如果要在一个成熟的TP系统支持一个AP的计算引擎, 意味着这个全新的 AP 引擎需要兼容所有的TP语法,这个工作量以及工业细节可就多了,当然这个过程也会非常得有趣.
本文将以 PostgreSQL 执行器中的 HashJoin 实现 以及 Arrow Acero执行器的HashJoin 实现为基础做一个 Pull 和 Push 两种执行器的差异分享.
Arrow 的作者Wes McKinney 对计算领域可以说是有前瞻性的眼光, 在pandas 作为开源型公益项目成为数据分析领域的明珠之后为了解决pandas 遇到的一些问题而和 parquet 相关的创始人一起开发了新的项目 Arrow, 而Arrow不仅完美得解决了 pandas遇到的所有的问题之后还有余力即将成为计算平台的标准. 按照目前Arrow 在计算领域的发展趋势, Wes 相信 "Future is arrow-native"的. Wes 作为Pandas/Arrow/Ibis 的创始人, 分享了很多对计算领域的深刻见解, 后续有机会会统一分享一下.
本文涉及到的相关源代码是:
PostgreSQL –REL_12_STABLE
, Arrow –apache-arrow-12.0.1
HashJoin 是 数据库执行引擎中 除了 AGG 算子之外最为通用的Join算子中的一种,其主要的应用场景是数据集较小等值链接.连接操作也是关系代数中的基本操作, 能够对两个数据集合按照连接类型(left outer/right outer/full outer/ innner/ semi/anti等)输出新的数据集合.
比如: select a,b from t1,t2 where t1.a=t2.b;
当然对于如上 query, 如果数据集较小且有序则planner可能会生成 merge-join的plan,因为 HashJoin 需要建hash表做hash探查, 而hash表是内存访问效率较高的一种场景,所以其最优的应用场景应该是无序数据集较小的情况.
PG 是成熟的工业级 TP数据库, 其hashjoin 的实现也会考虑 spill的情况(数据集远超内存时的需要考虑对hashjoin 过程中的临时数据落盘的操作), PG的 hashjoin实现采用的 Hybrid HashJoin.
PG 的执行器架构是标准的火山模型(pull), 数据流的驱动方式是自顶向下的.
图中的motion节点是greenplum 做mpp分布式执行引擎时为了做数据传递而创建的一个新的节点.
最上层的节点是 hashjoin, 其要获取数据,则会调用 getnext函数从下游节点拉数据, 下游节点的Hash节点或者motion节点则会继续调用自己的下游节点拉取数据,最后直到Scan节点 通过tableam 读取实际的heap表数据返回给上游.
整个 pull 模型采用的是 once-a-tuple, 每次上游节点调用getnext时仅会返回一个tuple.
这个模型的优势:
当然也有很多不足:
这一些不足则可以被 Push 模型的执行器解决, 但push模型也会缺乏 Pull 模型具有的优势.
PG 的 HashJoin 是基于以上 Push 模型实现, 采用的是Hybrid HashJoin(考虑spill的情况下 只需要一次对外表的扫描). 基本流程如下:
对于小表 R(被选择为inner table 构建hash表) 和大表 S (被选择为 outter table做hash 探查), 整个HashJoin的执行流程分为如 数据集的划分 以及 数据集的分批处理 两个阶段.
数据集的划分 流程如下:
主要做了两件事情
数据集的分批处理 流程是分批处理除了 R1,S1之外的其他被spill 的表数据:
PG 的执行器对 PlanState 计划树的初始化、执行、终止 分别采用的是 ExecInitNode
, ExecProcNode
以及 ExecEndNode
. 这三个入口会根据算子节点的类型分别调用对应算子的操作函数, 比如算子类型是 T_HashJoin
, 则会调用 ExecInitHashJoin
,ExecHashJoin
,ExecEndHashJoin
.
ExecInitHashJoin
被用于初始化一些数据结构, 比如 joinqual 表达式列表/targetlist 列表/hashqual 列表; 还有保存输出tuple 以及 nulltuple 的数据结构.ExecHashJoin
维护了六种状态的状态机用来实现 hybrid hashjoin.ExecEndHashJoin
释放hash表 以及 清理临时的 BufFiles.我们重点关注的是 ExecHashJoin
, 这是 hashjoin 算法实现 数据集的划分 以及 数据集的分批处理 两个阶段的主要逻辑.
详细介绍具体的两个阶段实现之前需要对 join 这个关系代数操作的一些类型有一些基本的理解, 才能理解HashJoin中一些 代码的具体作用对象.
如下两个表:
test=# select * from a;
c1 | c2
----+----
1 | 2
9 | 8
6 | 5
4 | 7
(4 rows)
test=# select * from b;
c1 | c2
----+----
2 | 1
8 | 9
7 | 4
6 | 5
1 | 9
(5 rows)
下文提到的左右表可以理解为
inner table
和outer table
, PG 实际执行之前通过 planner 会将 构建hash表代价较小的表设置为inner table
并对应 righttree,outer table
设置为outer table
并对应 lefttree.
test=# select * from a inner join b on a.c1=b.c2;
c1 | c2 | c1 | c2
----+----+----+----
1 | 2 | 2 | 1
9 | 8 | 1 | 9
9 | 8 | 8 | 9
4 | 7 | 7 | 4
(4 rows)
test=# select * from a left outer join b on a.c1=b.c2;
c1 | c2 | c1 | c2
----+----+----+----
1 | 2 | 2 | 1
9 | 8 | 1 | 9
9 | 8 | 8 | 9
6 | 5 | |
4 | 7 | 7 | 4
(5 rows)
test=# select * from a right outer join b on a.c1=b.c2;
c1 | c2 | c1 | c2
----+----+----+----
1 | 2 | 2 | 1
9 | 8 | 8 | 9
4 | 7 | 7 | 4
| | 6 | 5
9 | 8 | 1 | 9
(5 rows)
test=# select * from a full outer join b on a.c1=b.c2;
c1 | c2 | c1 | c2
----+----+----+----
1 | 2 | 2 | 1
9 | 8 | 1 | 9
9 | 8 | 8 | 9
6 | 5 | |
4 | 7 | 7 | 4
| | 6 | 5
(6 rows)
test=# select * from a where exists (select 1 from b where a.c1=b.c2);
c1 | c2
----+----
1 | 2
9 | 8
4 | 7
(3 rows)
test=# select * from a where not exists (select 1 from b where b.c2=a.c1);
c1 | c2
----+----
6 | 5
(1 row)
PG 其实还有一些执行器内部使用的连接类型,JOIN_UNIQUE_OUTER
和 JOIN_UNIQUE_INNER
用于约束连接之后输出的结果需要unique.
在了解了基本的连接类型之后, 我们接下来看看代码细节.
划分阶段主要涉及到的状态有下面几个:
1.HJ_BUILD_HASHTABLE
这个是处理 划分阶段中的 inner table R 的划分,保存 R 表的第一个batch构建的 hash表到内存中, R表的其他batch 则会被写入到内存中.
主要涉及到的函数是 ExecHashTableCreate
创建hash表初始数据结构 以及 MultiExecHash
调度getnext 处理innertable的数据, 并进行hash表数据的插入以及超限之后的spill.
PG 在hash表这里采用了比较标准 线性hash的实现, 并没有采用 dynamic_hash, 原因是 执行器的算子的内存大小其实是需要被控制的, 也就是构建hash表消耗的内存在初始化hash表的时候基本就知道了(work_mem
相关的guc), 这样就能根据已知的内存大小预分批好足量的bucket, 并没有动态扩容的需求, 性能其实也就用标准的hash表实现就好了.
ExecHashTableCreate
中, 通过 ExecChooseHashTableSize
根据用户配置的 work_mem
计算 inner table构建hash表时需要分配的buckets 的个数以及 最后整个inner table需要被拆分成多少个 batch(或者说 BufFiles).
tupsize = HJTUPLE_OVERHEAD +
MAXALIGN(SizeofMinimalTupleHeader) +
MAXALIGN(tupwidth);
// 内表总共需要的内存大小
inner_rel_bytes = ntuples * tupsize;
// 当前算子允许分配的最大的内存
hash_table_bytes = work_mem * 1024L;
默认配置的 work_mem 是1024, 也就是1M, 也就约束了当前 HashJoin 内存hash表的大小是1M.
buckets 以及 dbbatch 的大小其实也比较简单, buckets个数的量级是 hash_table_bytes / tupsize
, 只是 pg用了很多逻辑用来约束这个数值,不想太大,也不想太小; 同理 dbbatch
大小量级也是 inner_rel_bytes/hash_table_bytes
.
还有一个需要关注的逻辑就是 在ExecHashTableCreate
中也会通过 get_op_hash_functions
函数设置 inner-table和outer-table的 hash函数, 如果左右表的hash-cond 返回值类型一样, 则会用相同的hash函数, 否则会根据各自的hash-key的类型选择对应的hash函数.
接下来就是通过 MultiExecHash
--> MultiExecPrivateHash
进行 inner table 数据插入 hashtable 的逻辑了, 其中需要关注的逻辑有两个方面:
SkewBucket 用于优化数据偏斜的场景, 如果 hashkey数据 经过 distinct 之后仅剩下极少的几个,这样的tuple PG中称其为MCV (most common value), 这种情况则说明这个 hashkey有大量的重复数据,这个时候如果还是用原本的逻辑则会有部分bucket的数据集极多.且因为 会有spill的情况, 这样针对这种skew-bucket会需要大量的io操作. 所以 PG 为这一些hashkey 分配了单独的 bucket 并保证这一些buckets 一定是处于第一个batch, 这样就只会被扫描一次而不用反复得从磁盘加载. 这个过程是在前面构建hash表的时候保证的, 后续在 MultiExecPrivateHash
插入时如果 tuple 经过 hash 拿到的bucket属于 skew-bucket,则会将这个 tuple 插入其中并通过 链表连接起来.
// 获取skew bucket
int
ExecHashGetSkewBucket(HashJoinTable hashtable, uint32 hashvalue)
{
...
bucket = hashvalue & (hashtable->skewBucketLen - 1);
while (hashtable->skewBucket[bucket] != NULL &&
hashtable->skewBucket[bucket]->hashvalue != hashvalue)
bucket = (bucket + 1) & (hashtable->skewBucketLen - 1);
if (hashtable->skewBucket[bucket] != NULL)
return bucket;
...
}
// 将 读取到的 tuple数据 存储到 bucketNumber 对应的skewbucket中
static void
ExecHashSkewTableInsert(HashJoinTable hashtable,
TupleTableSlot *slot,
uint32 hashvalue,
int bucketNumber)
{
...
hashTuple = (HashJoinTuple) MemoryContextAlloc(hashtable->batchCxt,
hashTupleSize);
hashTuple->hashvalue = hashvalue;
memcpy(HJTUPLE_MINTUPLE(hashTuple), tuple, tuple->t_len);
HeapTupleHeaderClearMatch(HJTUPLE_MINTUPLE(hashTuple));
// 插入链表中
hashTuple->next.unshared = hashtable->skewBucket[bucketNumber]->tuples;
hashtable->skewBucket[bucketNumber]->tuples = hashTuple;
Assert(hashTuple != hashTuple->next.unshared);
...
}
对于非skewbucket, 则通过 ExecHashTableInsert
--> ExecHashGetBucketAndBatch
hashvalue 获取到对应的 bucketno和batchno
*bucketno = hashvalue & (nbuckets - 1);
*batchno = pg_rotate_right32(hashvalue,
hashtable->log2_nbuckets) & (nbatch - 1);
如果拿到的 batchno 和 当前hash表正在操作的 batch相同 batchno == hashtable->curbatch
, 则将 tuple 插入到当前bucket管理的tuple链表头部, 并处理当前batch 内存超限的情况.
插入逻辑如下:
hashTuple->hashvalue = hashvalue;
memcpy(HJTUPLE_MINTUPLE(hashTuple), tuple, tuple->t_len);
hashTuple->next.unshared = hashtable->buckets.unshared[bucketno];
hashtable->buckets.unshared[bucketno] = hashTuple;
处理内存超限的逻辑如下:
pg_rotate_right32(hashvalue,hashtable->log2_nbuckets) & (nbatch - 1);
, 则重新计算的batch编号只有两种可能,要么是i ,要么是 i + nbatch/2ExecHashJoinSaveTuple
写入到文件, 并维护在内存中的bucket的链表的完整性.如果 ExecHashTableInsert
拿到的 batchno 不是 hashtable->curbatch
,则直接通过 ExecHashJoinSaveTuple
写tuple 到磁盘对应的 BufFile, 等待分批处理的时候从磁盘load.
回到 HJ_BUILD_HASHTABLE
状态, 后续还有 parallel的处理(PG 进程架构加速算子性能,允许开启多个进程并发执行)并不属于主体逻辑, 本文不会做过多的介绍.
接下来会进入到 第二个状态 HJ_NEED_NEW_OUTER
.
2.HJ_NEED_NEW_OUTER
这个状态是划分阶段的第二个主体逻辑, 即使用相同的hash 函数 处理 outer table S的划分.
拿到一个outer table的tuple:
a. 如果这个tuple为空, 且是right-join (如果是 right-join, 则会在ExecInitHashjoin
时初始化 (hjstate)->hj_NullOuterTupleSlot), 则进入 HJ_FILL_INNER_TUPLES
状态,开始填充所有的左表的数据.
b. 如果这个tuple为空 但不是right-join,说明当前batch数据处理完了,进入 HJ_NEED_NEW_BATCH
状态读取下一个batch 对应的 BufFile.
c. tuple不为空,则获取其所属的bucket 以及 batchno, 如果bucket是 skewbucket或者batch 属于当前batch,则进入 HJ_SCAN_BUCKET
状态进行probe.
d. 如果不属于当前batch, 则将当前 tuple 写入到对应的batch文件.
3. HJ_SCAN_BUCKET
这个状态是处理 outer table 的 probe tuple, 用这个tuple 通过 ExecScanHashBucket
探查 inner table内存中的hash表, 如果探查失败,则转到 HJ_FILL_OUTER_TUPLE
状态,填充所有的右表的数据.
如果探查成功, 则进行 filter 和 project 处理, 进行过滤和投影操作, 这个后面会细说.
4. HJ_FILL_OUTER_TUPLE
处理 tuple probe失败的情况, 如果是LEFT-JOIN,则输出 inner-table 和 null的连接结果.
node->hj_JoinState = HJ_NEED_NEW_OUTER; // 拿下一个outer tuple
if (!node->hj_MatchedOuter &&
HJ_FILL_OUTER(node))
{
...
econtext->ecxt_innertuple = node->hj_NullInnerTupleSlot;
if (otherqual == NULL || ExecQual(otherqual, econtext))
return ExecProject(node->js.ps.ps_ProjInfo);
...
}
5. HJ_FILL_INNER_TUPLES
处理 RIGHT-JOIN的情况, 即输出所有还没有匹配过的内表的 Tuple, 如果处理完了所有的内表数据,进入下一个阶段 分批处理阶段: HJ_NEED_NEW_BATCH
.
分批处理阶段 主要处理 Ri 和 Si (i>=2) 的BufFile数据, R1和S1 在划分阶段的五个状态中已经处理完并输出了, 需要加载下一批batch数据到内存, 对于 R表来说就是加载下一个batch对应的BufFile tuple 数据到内存并构建hash表, S表则是读取下一个 BufFile的tuple 尝试进行probe.
主要涉及到的状态:
1. HJ_NEED_NEW_BATCH
处理下一个batch.
// 从R 表的 BufFile文件中读取tuple 并构建内存hash表.
innerFile = hashtable->innerBatchFile[curbatch];
while ((slot = ExecHashJoinGetSavedTuple(hjstate,
innerFile,
&hashvalue,
hjstate->hj_HashTupleSlot)))
{
/*
* NOTE: some tuples may be sent to future batches. Also, it is
* possible for hashtable->nbatch to be increased here!
*/
ExecHashTableInsert(hashtable, slot, hashvalue);
}
之后的状态就回到之前划分阶段的 2,3,4,5 状态的处理过程了.
2. HJ_NEED_NEW_OUTER
读取outer table的tuple
3. HJ_SCAN_BUCKET
尝试进行probe.
4. HJ_FILL_OUTER_TUPLE
处理 LEFT-JOIN的情况
5. HJ_FILL_INNER_TUPLES
处理 RIGHT-JOIN 的情况
JOIN-INNER 核心是仅输出所有匹配的左右表元组
所以状态机的流转比较简单, 划分阶段和分批处理阶段没有额外处理 OUTER/INNER 输出的状态.
JOIN-LEFT 核心是输出所有的外表的元组, 对于内表不匹配的元组则输出null. 有一个细节是说如果一个外表tuple 在 HJ_SCAN_BUCKET
阶段和内表的hash表 probe成功并输出之后 下一次还会再进入这个状态, 继续 probe相同内表bucket的下一个tuple 直到 probe 失败并处理下一个 外表tuple. 即 outer join 在内表有多个相同hash-value的元组的时候允许输出多行.
JOIN-RIGHT 核心是输出所有的内表的元组, 对于外表不匹配的元组则输出null. 同上在 HJ_SCAN_BUCKET
成功输出 之后下次继续进入这个状态probe.
JOIN-SEMI 半连接, 核心是在找到内表和外表匹配的tuple之后 仅输出外表的tuple. 且 输出结果是 unique的, 即不允许像 OUTER join 可以同一个tuple probe 多次内表.
JOIN-ANTI 反连接, 核心是在 内外表匹配 且 符合 ExecQual(join-filter)条件时 不输出, 仅输出不配的tuple, 同样 该连接条件的输出结果是 unique的.
理清楚 PG HashJoin 对于不同join 类型的处理细节之后,整个 HashJoin 的核心逻辑就算是结束了. 不过最终结果的输出从之前的代码来看, 必须要经过 ExecQual
以及 ExecProject
两个函数.
这两个函数做的事情分别是处理 joinqual
以及 targetlist
, 也就是 过滤 和 投影.
如下query的执行计划:
test=# explain verbose select a.c1,b.c2 from a,b where a.c1=b.c2 and a.c1 > 2 * b.c1;
QUERY PLAN
------------------------------------------------------------------------
Hash Join (cost=60.85..1120.62 rows=8513 width=8)
Output: a.c1, b.c2
Hash Cond: (a.c1 = b.c2)
Join Filter: (a.c1 > (2 * b.c1))
-> Seq Scan on public.a (cost=0.00..32.60 rows=2260 width=4)
Output: a.c1, a.c2
-> Hash (cost=32.60..32.60 rows=2260 width=8)
Output: b.c2, b.c1
-> Seq Scan on public.b (cost=0.00..32.60 rows=2260 width=8)
Output: b.c2, b.c1
(10 rows)
其中能够看到 HashJoin 节点之下有 Output、Hash Cond 以及 Join Filter.
node->js.ps.qual
链表中, HashCond 也可以是表达式.node->js.joinqual
.对于 output 的 targetlist 的初始化是通过 ExecInitHashJoin
--> ExecAssignProjectionInfo
--> ExecBuildProjectionInfo
--> ExecBuildProjectionInfoExt
, 走PG 的表达式初始化逻辑, 这块后面会统一介绍. 需要注意的是 output 对于当前节点来说 相当于输出了新的tuple, 其结果的TupleDesc 是保存在 planstate->ps_ResultTupleDesc
, 如果我们想知道当前算子输出的tuple是什么样子的(schema, nattrs等信息), 都可以从这个 TupleDesc中提取, 这个信息对于我们想要将 PG 算子向量化来说极为重要, 一旦处理不对结果就有问题.
joinqual 以及 qual的初始化同样是在 ExecInitHashJoin
--> ExecInitQual
完成, 也是走表达式初始化系统, 后续统一介绍.
因为 HashCond 已经融入到了 build hash表以及probe阶段(内表和外表都会选择 hash-cond 中自己的列作为hashkey) , 所以仅需额外处理 join-filter 和 project, 这两个操作的执行顺序是先 filter, 在project, 因为filter能提前做一个过滤, 就能避免部分逻辑再走 project了, 在 pull模型下, 某一些超级query的 project 表达式可能会非常长, 提前filter能避免极多的不必要逻辑. project 则是必须要走的逻辑.
PG 本身也有属于自己的 ProjectSet
算子, 专门做 Project, 不过在 Join或者 Agg 这样的算子中都用的是 ExecProject
, 单独用算子来做这一些投影操作其实有点重, 多了不少初始化以及调度的逻辑. 所以 ProjectSet
这样专门用于 array_agg
以及 literal
的特殊语法才会使用.
到此 整个PG 的执行器架构 以及 HashJoin 算子介绍完了, 比较简单, 但是细节很多 且 需要考虑 spill 以及 支持各种 Join 类型.
接下来看看 Arrow Acero 执行引擎的整体调度框架以及 HashJoin 算子的实现, 因为其是标准的 Push模型, 且完全向量化了, 所以能看到很多相比于 Pull 模型非常有趣的差异.
Acero 是 Arrow C++库中的一个向量化计算引擎, 可以像其他计算引擎一样被用于分析流式的数据. Acero 也可以算是 对Arrow 的核心设计 内存格式 计算层面的应用,包括 type-system, RecordBatch, compute, ipc … 在 Acero 中能够看到如何优雅得使用 Arrow 的核心设计.
借用官方的一张图来看看 Acero 和其他组件之间的关系.
本节只会粗略介绍一下 Acero, 毕竟Arrow是 Wes 大佬的设计, 且本就是抽象度足够高的计算领域, 有太多优雅的东西可以学习(借鉴–抄:));
对于 如下这样的基于 Push 模型的plan:
画的是数据流的方式, 从Scan节点开始, 其本身是没有上游节点的,因为Scan节点就是数据的最上游的生产者, 生产出来的数据以 RecordBatch的方式 Push到下游接受数据的节点(比如 hashjoin), HashJoin有上游节点也有下游节点, 同样做一些处理 将数据 以 RecordBatch 的方式push到下游的 filter/project节点. 对于 Push 模型的向量化节点来说, 数据的流式处理能够充分利用 cpu 缓存以及 simd 指令集, 并且极大得减少了函数调用的开销(batch 处理). 不过问题也很明显, 没有办法灵活得控制输入的数据量和数据规模, 一旦push模型的 plan 调度起来, 当前节点是没有办法终止数据的输入的, 数据输入和输出的规模都不好控制, 毕竟数据输入是从上游节点强制push下来的, 不是像pull 一样上游节点问你要数据.
如下案例, 是一个非常简单的 acero hashjoin的调度:
// 生成数据
ARROW_ASSIGN_OR_RAISE(auto input, MakeGroupableBatches());
// 定义 LeftScan 节点
ac::Declaration left{"source", ac::SourceNodeOptions{input.schema, input.gen()}};
// 定义 RightScan节点
ac::Declaration right{"source", ac::SourceNodeOptions{input.schema, input.gen()}};
// HashJoin 采用 inner类型, 且 cp::literal(true) 表示使用 swisstable 做hash表
ac::HashJoinNodeOptions join_opts{
ac::JoinType::INNER,
/*left_keys=*/{"str"},
/*right_keys=*/{"str"}, cp::literal(true), "l_", "r_"};
// 定义 hashjoin 的节点, 并指定左右子节点
ac::Declaration hashjoin{
"hashjoin", {std::move(left), std::move(right)}, std::move(join_opts)};
// 调度hashjoin 的执行
return ExecutePlanAndCollectAsTable(std::move(hashjoin));
如上案例 主要是通过 Declaration
声明节点, Declaration
能够比较友好得组织管理 ExecNode
, 并且能够快速将管理的 ExecNode
算子通过 AddToPlan
添加到执行计划 之中.
如上案例中添加好的 hashjoin 以及被作为hashjoin Declaration 初始化参数的左右子节点都会在 DeclarationToTableImpl
中按照添加顺序完成初始化并添加到 ExecPlan中进行 StartProducing
的异步调度.
接下来看看 HashJoin 实际是如何被 Acero 调度起来的:
本图额外补充了 HashJoin 经常用到的 JoinFilter 以及 Project 算子:
初始化. Arrow 对于输入的plan 进行 toposort 之后会形成如上红色箭头的 初始化 顺序.
Arrow的 hashjoin 分为 probe 以及 build端, build 部分是用hash-join 的 inputs_[1] 即 right-input 内表 节点生成的RecordBatch数据在 内存中构建 hash表; Probe 则是hash-join 的 inputs_[0] left-intput 节点进行hash表的探查.
数据流 则是在初始化过程中 从 source-node 即上图中生成数据的两个scan节点开始, 这一些节点调度自己的 StartProducing 进行数据的读取(读取parquet文件) 形成record-batc 作为输入 传给 下游节点(hash-join)的 inputReceived 进行对应的处理. 处理完成通过 inputFinished 标识当前节点处理完毕.
因为 Arrow 有自己的 pipeline 调度, 所以 inputReceived 和 InputFinished 每一个节点都会有, 每次数据上游节点push 的batch数据都可以 以pipeline方式在整个plan之间传递, 直到 最上游的节点调度 InputFinished 才标识数据处理完毕, 并调用下游节点的 InputFinished.
Arrow 拥有自己的 Filter-node 和 Project node, 所以可以有专门的节点来做投影和过滤. 因为有pipeline 的存在, 数据流按照 batch 通过这一些节点的时候并不会对性能有多少影响.
需要注意的是 Acero 的调度框架为了达成高效的 PipeLine 处理模式, 让整个执行计划上的所有算子每次接受到的 ExecBatch 都可以被当前算子启动的一个task异步处理. 当然 pipeline的复杂度主要是在正确性上, 因为有一些 batch 的处理是一定要求第 X 个要在 X-1 个之后处理,但是这样的异步调度可能出现第 X 个batch 在 第 X-1 个batch之前被处理完. 这就会有问题. 整个 pipeline 全链路异步 以及 正确性如何保证是 Acero 调度体系的核心, 这个就复杂多了.
提一嘴 HashJoin 的Schema, 本质上使用 Acero 的hashjoin时并不会有额外需要 Filter以及Project 节点的需求, 因为 HashJoinSchema
这个数据结构已经做了相关的管理, Filter 本质是过滤输出的行, 而 Project 则是过滤输出的列. 用户在构造 HashJoin 的 Declaration的时候指定了相关的 Filter, 制定了 Output的schema, 比如:
HashJoinNodeOptions(
JoinType join_type, std::vector<FieldRef> left_keys,
std::vector<FieldRef> right_keys, std::vector<FieldRef> left_output,
std::vector<FieldRef> right_output, Expression filter = literal(true),
std::string output_suffix_for_left = default_output_suffix_for_left,
std::string output_suffix_for_right = default_output_suffix_for_right,
bool disable_bloom_filter = false)
: join_type(join_type),
left_keys(std::move(left_keys)),
right_keys(std::move(right_keys)),
output_all(false),
left_output(std::move(left_output)),
right_output(std::move(right_output)),
output_suffix_for_left(std::move(output_suffix_for_left)),
output_suffix_for_right(std::move(output_suffix_for_right)),
filter(std::move(filter)),
disable_bloom_filter(disable_bloom_filter) {
this->key_cmp.resize(this->left_keys.size());
for (size_t i = 0; i < this->left_keys.size(); ++i) {
this->key_cmp[i] = JoinKeyCmp::EQ;
}
}
构建 HashJoinNodeOptions 的时候也可以指定输出的左右 fields, 以及Expression filter
, 然后在 HashJoinNode::Make
即初始化 HashJoinNode 的时候会利用这一些 right_output 以及 left_output 来构造 output_schema, 从而也就有了用户指定的输出列.
当然,在 HashJoinSchema
中有更加优雅的管理 schema 的方式, 除了保证输入、输出、filter等操作的正确性, 还需要能够有高性能, 尤其是大宽表场景中快速获取对应的列schema信息就尤为重要.
上面只是基本的调度流程, Acero hashjoin 的详细实现本文暂时不会展开, 因为还有 和simd深度结合的 超高性能的 swisstable 还在学习中, 等后续有时间了和 hashjoin 以及 pipeline 一起介绍.
本文只是通过 PG 和 Arrow 这两个各自在数据以及计算领域如日中天的系统 介绍一下 Pull 和 Push 模型的工作形态. 因为前者服务于 TP 系统, 后者服务于 AP 系统, 所以没有可比性. 但是 HashJoin的基本实现还是比较接近, build hash表之后probe, 只是两者在性能上的考虑因为面对的应用场景不同,有比较大的差异: