HyperLogLog在Presto和ClickHouse中的兼容及性能差异

前言

当前HyperLogLog是一种主流的算法，用于估算海量同类型数据的不同值，因此几乎所有的计算/查询引擎都有了想关的实现，当然虽然可能其它的优化算法，但算法主体相同，然而不同引擎实现的存储过程大同小异，如果想要在不同引擎之前共享中间结果，就需要深入了解不同引擎的存储实现。

Presto是Facebook开源的，完全基于内存的并⾏计算，分布式SQL交互式查询引擎是一种Massively parallel processing (MPP)架构，多个节点管道式执⾏⽀持任意数据源（通过扩展式Connector组件），数据规模GB~PB级。

ClickHouse 是一个真正的列式数据库管理系统（DBMS)。在 ClickHouse 中，数据始终是按列存储的，包括矢量（向量或列块）执行的过程。只要有可能，操作都是基于矢量进行分派的，而不是单个的值，这被称为«矢量化查询执行»，它有利于降低实际的数据处理开销。

但碍于Presto在实际工作中会出现不稳定性的情况，便推动了Presto HLL计算的迁移，以期更加快速地响应用户的查询请求，这便是这篇博客的背景。

HLL数据共享流程

Presto/Hive上的基数预估的中间结果，实际上是一组格式化的字节数组，而ClickHouse并不支持直接加载HLL的字节数组，因此就需要扩展ClickHouse的聚合函数，即开发UDAF（自己写C++代码啦，目前CH并不是很方便地编写UDF/UDAF），完成Presto引擎上计算产生的中间结果的读取加载过程。至于CH上的内存数据存储格式，依然采用CH本身的实现，以减少工作量。

但需要注意的是，CH即使已经能够直接加载来自Presto的HLL数据，考虑到Presto和CH在计算HyperLogLog时采用的Hash逻辑不同，一个是小端一个大端，依然不能直接聚合两个引擎各自产生的中间数组，因此目前的模式是单向的，未来考虑双向聚合。

简言之，整个过程就是Presto HLL序列化 => 自定义数据格式 => 写入CH => 调用CH UDAF聚合，最终完成Presto HLL数据在CH上的聚合过程。

HLL聚合性能比较

Presto

数据总量（条）	HLL数据读取以及merge耗时（单位秒）
100000	4
200000	9
500000	23
1000000	44

ClickHouse

数据总量	HLL数据读取及Merge耗时（单位秒）
100000	5
200000	18
500000	46
1000000	91

性能差异分析

源表(viprpdm.ads_mer_high_dim_detail_df)静态统计信息：

select count(*) from test_table where dt=‘20210111’;

dt分区的数据总量N_total=2675032

select count(*) from test_table where dt=‘20210111’ and length(test_hll) <=2060;

dt分区中字节数组长度小于等于2060的总量N_2060=2670580

select count(*) from test_table where dt=‘20210111’ and length(test_hll) <= 1024;

dt分区中字节数组长度小于等于1024的总量N_1024=1112470

其中rate_1024 = N_1024 / N_total = 0.416，大约占总量的一半

由上的统计信息可以看到，源表中的HLL数据的字节数组长度，基本上所有的字段值的长度都约为4096个桶的一半，这里以Dense类型的存储格式为主说明性能差异的原因。

一般地Dense类型的数据，会使用一个与桶数相同长度的数据，来保存每一个value，举例4096个桶，就对应了4096个slot的数组，其中每个slot会存入一个6位长度的数来表示不同值。

应用程序中最本的计算单元是按字节来处理，而一个字节需要8位的比特表示，因此Presto为了更能高效地来存储和处理HyperLogLog计算的中间结果，会将桶中应该存放的6位值对齐到

4位，即VALUE_BITS >> 1，这样桶数也会降低到原来的一半BUCKET_BITS >> 1，那么在不考虑溢出的情况下，就只需要[2048 * 4 / 8 = 1024, 4096 * 6/8]范围内的存储就可以完成计算。

由于对6位的值对齐到4位，必然会出现实际值溢出问题，即某个桶的值超过了2^4，Presto内部会创建一个溢出数组，来保存溢出的值，这样依然在溢出的场景能够很好的工作，虽然这样的做法相对于直接使用一个字节来表示桶值复杂，但通常情况下溢出的现象不会很频繁，因此这种设计在更普遍的情况下会带来存储和计算的性能提升。

总结

综上，当前从Presto HLL数据到CK的中间结果的存储格式，采用一个字节来存放完整的桶值，因此抛却必要的头部信息外，需要4096*6/8=3072 bytes。

实际上CK本身在自己的HyperLogLog实现中，也是采用了6位表示的存储格式，但总的数组大小为(4096*6 + 7)/8，因此可能在大部分情况下，HLL计算性优劣如下：

中间转换格式 < CK存储格式 < Presto存储格式

因此，如果想要更好地打通ClickHouse与Presto之前的HyperLogLog数据，在应用层后续重点工作当是完善ClickHouse侧加载Presto HLL数据的过程。

参考项目地址：