spark 3.3+ 之BloomFilter Runtime Filter

问题:

小表left join超大表,耗时要超1.5h,而且发生了FetchException导致任务多次重试之后挂掉的情况:

解决方案:

ai了一番之后,给出了一个靠谱的解决方案:Runtime BloomFilter:

复制代码
修改前:
...
from table_small_xxx
LEFT JOIN (
            select user_id
            from table_xxx
            where dt='${etl_date}'
    ) t3 ON (t1.user_id=t3.user_id)
    
修改后:

SET spark.sql.runtimeFilter.bloomFilter.enabled=true;    --  总开关。是否启用 Runtime BloomFilter
SET spark.sql.runtimeFilter.bloomFilter.applicationSideScanSizeThreshold=10GB;    -- application side (大表) 必须 ≥ 这个阈值, 才考虑加 BF
SET spark.sql.runtimeFilter.bloomFilter.creationSideThreshold=1GB;    -- creation side (小表) 必须 ≤ 这个阈值, 才会去构建 BF,避免bf太大
SET spark.sql.runtimeFilter.semiJoinReduction.enabled=true;    -- 另一种运行时过滤策略,适合build side很小无须使用bloomfliter直接用类似in的查询方式(其实也可以不加)

...
from table_small_xxx
LEFT JOIN (
    SELECT t.user_id
    FROM table_xxx t
    LEFT SEMI JOIN (
        SELECT DISTINCT user_id
        FROM table_small_xxx
        WHERE dt='${etl_date}'
      ) s ON (t.user_id = s.user_id)
      WHERE t.dt='${etl_date}'
) t3 ON (t1.user_id=t3.user_id)

原理介绍:

a left join b 时,a是小表,b是超大表。 那么就先对a中的join条件构造bloomfilter,broadcast到各个executor上,把超大表中的数据先剔除掉,这样就不会shuffle大量数据了。

复制代码
                   ┌────────────────────────────┐
                   │  Build Side (小的一边)       │
                   │  (creation side)            │
                   │  e.g. song_base_info 750万  │
                   └────────────┬────────────────┘
                                │ 1. 扫一遍, 把 join key 全部塞进 BF
                                ▼
                   ┌────────────────────────────┐
                   │     BloomFilter 数据结构     │
                   │  几 MB ~ 几十 MB 的 bitmap  │
                   └────────────┬────────────────┘
                                │ 2. 通过 Broadcast 分发到 tag 表 scan task
                                ▼
                   ┌────────────────────────────┐
                   │  Application Side (大的一边)│
                   │  e.g. tag 表 8862 亿行      │
                   │                             │
                   │  for each row in tag:        │
                   │    if BF.mightContain(key):  │
                   │      emit row  ← 1% 通过     │
                   │    else:                     │
                   │      skip      ← 99% 丢弃    │
                   └────────────┬────────────────┘
                                │ 3. 输出筛选后的小数据集
                                ▼
                       进入正常的 Join 阶段
相关推荐
四季豆338 小时前
工业大数据不只是“大”,更是制造业突围的“导航仪”
大数据
newsxun8 小时前
光智融合,空间新生|Jupiter SR 亮相光博会CIOE 2026
大数据·人工智能
大树888 小时前
液冷系统的真正瓶颈,藏在那层不到1毫米的材料里
大数据·运维·服务器·人工智能·ai
Vicky_time9 小时前
2026美国海外仓TOP5技术评测:FBA中转海外仓系统对接与操作方案
大数据·系统架构
北京晶数信息科技9 小时前
加油机数据采集设备加油机数据采集器加油机智能采集器液位仪数据采集设备原厂成品油流通数智化综合监管平台技术原理与落地应用解决方案
大数据·人工智能·物联网·需求分析
凌风的跨境分享9 小时前
Temu店群运维提效:定时策略自动化任务全场景实操指南
大数据·运维·前端·人工智能·架构·自动化
Elastic 中国社区官方博客9 小时前
Elasticsearch 向量数据库:几分钟内完成部署,以经济高效的方式扩展至数千亿规模
大数据·运维·数据库·elasticsearch·搜索引擎·ai·全文检索
A hao9 小时前
LED视频处理器中帧率与刷新率的区别
大数据·图像处理·人工智能·音视频
AgentMaster9 小时前
数据治理工具选型指南:一套可复用的四阶段决策框架
大数据·数据结构·人工智能·算法
数融智域9 小时前
2026年获客智能体排行榜top前五
大数据·人工智能