spark 布隆过滤器(bloomFilter)

        数据过滤在很多场景都会应用到,特别是在大数据环境下。在数据量很大的场景实现过滤或者全局去重,需要存储的数据量和计算代价是非常庞大的。很多小伙伴第一念头肯定会想到布隆过滤器,有一定的精度损失,但是存储性能和计算性能可以达到几何级别的提升。很多第三方框架也实现了相应的功能,比如hbase框架实现的布隆过滤器性能是非常的棒,redis也可以实现相应的功能。这些需要借助于第三方框架,需要维护第三方框架。如果公司没有部署相应架构,单独为使用布隆过滤器部署一套集群,代价还是非常大的。

        我们在做流式计算时需要实现数据小时级别去重和天级别数据去重,初始功能版本使用的是基于redis实现的布隆过滤器。性能也非常的好,三个节点的redis集群(三主三从,主从交叉策略)性能可以达到每秒十几万的处理性能。在后期的使用中主要瓶颈就在redis的吞吐量的性能上。一直想在这块做一定的性能优化。

        后来,发现spark官方封装了基于DataFrame的布隆过滤器,使用起来相当方便。性能不再受制于第三方框架的吞吐量限制,依赖于spark的并行资源。可以减少架构设计的复杂度,提高可维护性。在流式计算应用中可以将布隆过滤器做成driver级别的全局变量,在batch结束更新布隆过滤器。如果考虑容错,可以将布隆过滤器数据定期持久化到磁盘(hdfs/redis)。

       直接上代码,看一下使用方法

    val bf = df.stat.bloomFilter("dd",dataLen,0.01)
    val rightNum = rdd.map(x=>(x.toInt,bf.mightContainString(x)))

        首先,在生成布隆过滤器直接调用bloomFilter(colName:String,expectedNumItems:Long,fpp:Double)就可以了,第一个参数是使用的数据列,第二个参数是数据量期望会有多少,第三个参数是损失精度。损失精度越低生成的布隆数组长度就会越长,占用的空间就会越多,计算过程就会越漫长。

        在用有些场景布隆过滤器还需要合并,官方也提供了相应的API

                mergeInPlace(BloomFilter var1):BloomFilter

        判定数据是否存在,官方一共提供了四个方法:

                mightContain(Object var1),

                mightContainString(String val1),

                mightContainLong(long var1),

                mightContainBinary(byte[] var1)

        不同的方法适用于不同的类型,bloomFilter(calname:String...)这个方法中使用列的数据类型一定要和以上四个方法对应,否则会出问题。

        官方还很贴心的提供了序列化和反序列化工具:writeTo和readFrom,可以很方便的将布隆过滤器序列化到磁盘和从磁盘加载布隆过滤器。




发布了28 篇原创文章 · 获赞 15 · 访问量 3万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览