51CTO|苏宁6亿会员是如何做到快速精确分析的？图片来自Pexels

文章图片
图片来自Pexels
【51CTO.com原创稿件】随着苏宁业务的高速发展，大数据平台对海量的业务数据分析越来越具有挑战，尤其是在精确去重、复杂JOIN场景下，如用户画像、UV、新老买家、留存、流失用户等。
苏宁大数据平台目前OLAP分析的总体架构是将时序化的数据采用Druid+ClickHouse、非时序化采用PostGreSQL、固化场景采用Hbase+phoenix、明细数据采用Elasticsearch分析。
基于Druid我们有HyperLogLog非精确去重算法，具有非常优异的空间复杂度O(mlog2log2N) ，空间的占用随着基数的增长变化不大，但统计存在一定的偏差。
基于其他引擎我们常用的精确去重算法一般是GROUPBY后countdistinct操作， GROUPBY会带来大量的shuffle操作，占用大量的磁盘和IO ，其性能较为低下。
下面将为大家揭开苏宁如何整合RoaringBitmap进行高效精确去重架构方案的神秘面纱。
RoaringBitmap在苏宁的应用实践
为何选择RoaringBitmap
首先简单为大家介绍下RoaringBitmap ， 32位的RoaringBitmap的是由高16位的Key和低16位的Value组成， Key和Value通过下标一一对应。
Key数组保持有序存储在roaring_array_t中，方便二分查找。低16位的Value存储在Container中， Container共有三种。
RoaringBitmap对创建何种Container有自己的优化策略，在默认创建或元素个数小于4096的时候创建的是ArrayContainer 。
它是动态扩容的数组，适合存放稀疏数据，超过最大容量4096时，会自动转换为BitmapContainer 。
当元素超过4096时ArrayContainer的大小占用是会线性增长，但是BitmapContainer的内存空间并不会增长，始终还是占用8K 。
还有一种是RunContainer ，只有在调用runOptimize()方法才会触发，会和ArrayContainer、BitmapContainer比较空间占用大小，然后选择是否转换。
RunContainer占用的存储大小看数据的连续性，上下限范围[4Bytes ， 128KB] 。
近年来，大数据技术得到了快速的发展，各种开源技术给大数据开发人员带来了很大的便利，在众多的技术中之所以选择RoaringBitmap ，是因为它的存储空间低和运算效率高。
RoaringBitmap的存储是通过bit来标识状态，经过压缩后存储，据估算苏宁6亿会员如果是常规的数组来存储占用空间约为2.2G ，而RoaringBitmap存储仅需要66MB ，大大降低的存储的空间，降低企业的成本。
RoaringBitmap是通过位运算(如AND、OR、ANDNOT等)进行的，在计算能力上也相当惊人。
我们在基于PostGresql+Citus做过与countdistinct的对比测试，发现RoaringBitmap的统计耗时是countdistinct的近1/50 。
原生的RoaringBitmap只存储整形数据， 32位的RoaringBitmap最大的数据存储量是2147483647 。
对于会员之类的可以采用，像订单、流量这样的数据量可以采用64位的RoaringBitmap ，在性能上32位的效率在同等条件下要优于64位。
苏宁拥有海量的业务数据，每天都有大量的离线和实时计算任务，采用RoaringBitmap技术不仅大大节约了存储的成本，计算的效率也得到了显著的改善。
应用场景
①会员相关指标计算
RoaringBitmap在会员相关指标的分析中有着许多重要的应用场景，比如会员的新、老买家、留存、复购、活跃这些指标均要用到精确去重的统计方式。
苏宁目前有6亿会员，像新、老买家这样的指标计算都是拿当前的买家与全量的历史买家进行比对，如何快速的精确的分析出计算结果，在没有引入RoaringBitmap之前是一个较大的挑战。
②精确营销
给目标用户群推送优惠的商品提高公司的销售额已经是电商公司采用普遍的精准营销手段。