Databend 源码性能调优实践-实践篇 1

在这里主要向大家做一个 Databend 性能调优相关的分享,共会分为三次向大家介绍,如下所示:

1、基础篇:代码调优的前置知识(mp.weixin.qq.com/s/WTCL6w9ur… ) 2、实践篇1:Databend 源码性能调优实践 3、实践篇2:Databend 的 Group By 聚合查询为什么跑的这么快?

Databend 是基于 Rust 语言开发面向云原生设计的数据仓库。Rust 是近几年比较火的系统编程语言,它具有零额外开销的抽象成本,并且有贴近 C++ 的运行性能。

但这并不意味着使用 Rust 实现的代码一定比使用 Python 实现的开发要快,在没有理解本质的情况下,Rust 依然能写出低效率的代码,这其实取决于编程人员的水平,只是 Rust 让我们更容易写出高效的代码。

下面将根据多个例子,来讲讲编程中常见的一些优化点,这些优化点多以 Rust 实现为例,但其原理可以运用在其他语言中。

本系列课程的视频回放,可以点击 www.bilibili.com/video/BV1zM… 查看。

inline vs no inline

在 Rust 中,有三个 hint 去做代码的内联,如下所示:

#[inline],
#[inline(never)],
#[inline(always)]
复制代码

在写代码时,我们也尽量告诉编译器我们所期望采用的方式。

内联有以下优点:

a.内联作为一种优化转换,它可以取代对函数的调用,节省代码的开销。

缺点

a. 代码二进制体积变大,使得编译时间更糟。

b. 泛型函数可能会导致内联代码膨胀.

注:

a.对于私有函数可能不需要内联,因为 LLVM 具有启发式内联。

b.私有函数具有隐式内联。

Case 1

下图所示代码展示了两段函数 default_crc32() 和 inlined_crc32(),这两段代码所实现的功能为做一个 crc32 的哈希,在 default_crc32() 是直接调用一个 crc32 fast 的哈希库,算出哈希值后,对数组进行一次遍历,得到其加总的结果;而在 inlined_crc32() 中,在 new() 函数、update() 函数加入了 inline。他们的运行时间如下:

default_crc32 time: [16.184 ms 16.196 ms 16.209 ms]

inlined_crc32 time: [1.6317 ms 1.6353 ms 1.6396 ms]
复制代码

从数据中,我们可以明显的看出使用内联后性能有接近 10 倍的改善。 file

Case 2

在前面一个例子中,大家可以感受到内联对代码性能带来的提升。而不恰当的使用,同时也会让性能更差。但内联不是银弹,下面这段代码是使用了 inline(never)这段代码。当我们不使用这个 hint 时候,我们的整个函数会被编译器优化成 inline 的,进一步会导致 aggregate 里面的子函数就不会被 inline 了,但我们的程序执行耗时大多在子函数中,因为子函数中使用了 loop 循环执行 CPU 密集型操作。所以我们需要显式地告诉编译器不要 inline 外层函数,来达到 10% 左右的性能提升。 file

No extra allocation/copy

在写代码时候,可能会存在着一些额外的分配及拷贝。我们可以通过对其进行优化,也能提升我们代码的性能。

Case 3

select sum(number) from numbers_mt(10000000000)
复制代码

再来看第三个例子,这个例子源于 Databend 开发初期,当我们生成 numbers 表时求一个到10000000000的加总值。在这个代码中通过生成一个 Vec 的数组,我们将其转换成 Arrow 格式时,我们调用了 UInt64 Array::from() 这个函数,虽然我们将 data move 进去了,但这个函数内部还是调用了内存拷贝,通过 perf 工具可以看到 SQL 执行的开销多在内存拷贝中。

我们优化的方式是去掉多余的内存拷贝,使用了 unsafe 去生成 Arrydata,然后生成 Arrow 格式的 Array,最后让整体性能提升了 2-3 倍。

file file

Case 4.1

cast(number as Varchar) 这个例子是将一个 NumberArray 转换成 StringArray。在左边的代码中,逻辑是遍历 NumberArray 将每行的数值转换为字符串,然后返回一个迭代器,迭代器再去生成StringArray。但这段代码产生了非常多的额外开销,由于他遍历到每一个元素时,都会产生一个局部的 Vec,这里的 Vec 是非常离散的,并且使用一次后就会被丢弃,在这里就会产生大量的小内存分配和回收,进而导致性能变差。

在第一个版本的优化中,我们在生成了一个局部的 buffer,在数值转为 string 的过程中,我们把序列化写入到这个 buffer 中,再通过 builder 去把数据 push 进 arrow 的内存格式中。这使得其性能提升至两倍,但这个 case 并没有被优化到极致。 file file

Case 4.2

经过 Case 4.1 的优化,我们继续对其优化。因为在上述 Case 中我们用到了一个 buffer,但其实我们可以直接移除 buffer。这里我们用一个闭包函数,在数值转 String 的过程中,直接往 arrow 的内存模型中进行写入,无需额外的内存分配和拷贝,对比前一个版本,可以再提升两倍左右的性能。 file file file

Case 5

Databend 在开发的过程中,也会有一些些早期的代码写的不够好,比如我们在收集内存分配的时候,我们个 MemoryTracker 变量存储在 thread_local 中,去获取 runtime_tracker 的时候,左边的代码多了一个 Arc 的 clone,右边的代码是返回的引用,虽然clone 本身开销并不是很大,但是在 SQL 执行过程中,我们会临时地去分配很多小的内存,所以每一次分配的都会去调用这个 get 方法,就会大大降低其性能。 file

另外,我们还做了一次优化是,并不是每次内存分配都会去实时反馈到全局统计变量中,因为多线程去更新全局变量需要同步操作,所以我们这里做了统计值的线程内部缓冲更新,避免小内存分配统计影响性能。 file

Less extra function call

Case 6

下面的例子是 Arrow 中的一个排序函数,例如在 SQL:

复制代码

排序的列是 a,但其余的列也要跟着 a 的顺序走,arrow 的执行流程是先将索引按照 a 进行排序,下面的例子就是索引排序的过程,排序我们需要按照 a 列在不同 index 中的值进行比较,然后根据结果决定是否交换 index。

左边的实现是闭包捕获了array,但我们根据 index 那对应的值需要调用 array.values().as_slice().get_unchecked(), 这里有 3 次函数调用,如果 array 的长度很长,这个调用开销的放大是非常可观的。我们的优化过程也非常简单,我们把 values 先引用到一个变量中,之后闭包就会直接去捕获 values。这个优化大约可以达到 25% 的性能提升。 file file

Less branch prediction miss

大家应该都熟悉分支预测可以利用 CPU 乱序执行来提升性能。但是分支预测失败了,返回会大大影响性能性能 。请大家来看以下的几个例子。

Case 7

下面的例子是在一个循环中,每次循环都会调用 unwrap 函数,这个 unwrap 函数在 Rust 其实就是一次 if else 封装,因此这里会有分支预测的开销。分支预测通常来说是有缓存的,但在这个函数中,分支预测的缓存似乎工作的不太友好。

对他优化的方式是迭代器生成封装到一个方法中,从而去除多余的分支预测。 file file

Case 8

复制代码

这个例子是 abs 函数的实现。在这里我们是去对 int8 这个函数进行一次遍历并求绝对值,map 判断了 null 的情况,如果原始值是 null,结果依然需要为 null。Arrow 的内存模型是有两个 array 的,它的第一个 array 是一个 int8 的数组,第二个 array 是一个 bitmap。我们的优化方式是先忽略 null,直接遍历 int8 数组,进行 abs 的 transform,然后将输入的 bitmap 进行 clone 给结果数组,从而去除了分支预测。由于类似函数会很多,所以我们封装了多个 apply 函数进行数组到数组的转换。 file

Case 9

这里来自 ClickHouse 的一个例子。

SQL:

复制代码

这个 SQL 通常会有 2 个分支预测,一个判断 number > 3,第二个判断 number 是否有 null 值。在向量化 sum 中,我们用一些位操作来优化分支开销。 file

SIMD SIMD 指的是单指令多数据执行。接下来我们会讲到两个关于 simd 的例子。

Case 10:simd sum

在我们的列数据库中,非常常用的就是向量化执行。首先,我们先来看第一段代码,做的是对 double 数组的一次求和。理想化的情况的是,我们的 CPU 执行的如果最佳流水线,ADD 执行的次数是 N 次。

现代的 CPU 中通常有一些特殊的优化指令集,比如 SSE,AVX,通过这些指令对数据进行批量的求和,这样可以让整体性能提升至 4 倍左右。 file file file

AVXAdd 的函数实现看起来比较丑陋,通常来说我们不需要显示的使用 AVXAdd,因为现代的编译器已经足够智能优化上面的代码成 AVXAdd 方式执行了,比如 GCC 的自动向量化。

Case 11: null sum in arrow2

求和运算中,我们通常要忽略 null 值,这样可能会破坏自动向量化的优化,因为 null 值是 runtime 才能感知的。Rust有一些向量化的 crate 非常有用,比如说 Arrow2 中使用了packed_simd2, Rust 也即将迎来标准的 simd 库。下面的例子是对含有 null 值得数组求和向量化代码。 file

整体的原理是将数据按 chunk 分桶在一个 simd 位宽中,然后运用向量化的 select 将非 null 的值抽出到一个新的 selected 中求和。

自动向量化

通常来说,我们不会主动编写向量化的代码,而是让循环中的逻辑尽量简单 (不引入分支),编译器往往能给我们优化出高效的代码,比如在 not nullable 的 array 中进行求和,自动向量化的代码反而比手动向量化的代码更加高效。 file file

通过以上的 11 个例子,希望你已经对代码调优有了更深入的了解,在下一次的分享中我们将介绍 Databend 的 group by 查询为什么能跑的这么快。

想要了解更多资讯,欢迎关注公众号:Databend

如果想了解更多,可以关注公众号: Databend

猜你喜欢

转载自juejin.im/post/7049972932788879373