|苏宁6亿会员是如何做到快速精确分析的？( 四 )

线上新买家空调则是拿 {A} 和 {A ， C} 做 rb_andnot_cardinality 后的集合为空集，数量为 0 。
不足与挑战
基于 PostgreSQL+Citus 的 RoaringBitmap 技术方案， bitmap 集合之间的位运算性能表现的较为卓越，但在很多业务场景需要高基数的 bitmap 集合进行位运算。
基于 Citus 我们分析发现，在位运算的时候 CPU 利用率处于低位，后期我们也针对基于 Citus 做了优化。
如 bitmap 下压到 Work 运算降低 CN 运算量，创建 cube 降低基数，在一定的程度了提高了效率，然在 Ctius 下的 CPU 始终没有得到充分利用。
ClickHouse 的并发 MPP+SMP 这种执行方式可以很充分地利用机器的集成资源，但当时看了 ClickHouse 还没有提供 bitmap 相关的接口，不能直接加以应用，如何将 RoaringBitmap 融合到 ClickHouse 是一个挑战。
RoaringBitmap 与 ClickHouse 的整合
在计算引擎中 ClickHouse 算是后起之秀，是一个列导向数据库，原生的向量化执行引擎，其存储是采用 Wired Tiger 的 LSM 引擎。
目前苏宁的大数据已将 ClickHouse 引入并改造，开发了相关的 RoaringBitmap 接口，用来支撑业务交互式查询。
基于 ClickHouse 的 RoaringBitmap 方案计算过程大幅简化，查询时候的 IO、CPU、MEM、网络资源都显著降低，并且不随着数据规模而现行增加。
基于 ClickHouse 我们开发了 RoaringBitmap 相关的接口，其支持的 Function 函数有：

bitmapBuild
bitmapToArray
bitmapMax
bitmapMin
bitmapAnd
bitmapOr
bitmapXor
bitmapAndnot
bitmapCardinality
bitmapAndCardinality
bitmapOrCardinality
bitmapAndnotCardinality 等

它们用于支撑各种场景的运算，其相关的接口开发还在不断的完善中。
未来展望
为了将基于 ClickHouse 的 RoaringBitmap 方案推广到公司的更多业务和场景中，我们在做不断优化和完善。
目前正着手于以下的尝试：

ClickHouse 目前不支持 64 位的 bitmap ，正在尝试按 hash 值进行分区，每个分区单独计算，可轻易将分区进行横向叠加支持到 long 长度。
全局字典表在高基数下构建成本较大，占用较多资源也耗时较大，后续可根据业务场景将数据字典表最大程度复用，同时考虑在无需跨 segment 聚合时候，适用这个列的 segment 字典替代。
全链路监控的完善，可根据 query_id 进行各个环节的耗时分析，便于优化和问题的定位。

作者：范东
简介：苏宁科技集团大数据中心架构师，在 OLAP、OLTP 领域有着深刻的技术积累。目前主要负责数据中台和数据工具平台的架构及性能调优工作，在数据中台、数据集成开发工具、数据资产、数据质量和数据治理等方面拥有丰富的实战经验。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】