面试加分秘籍:校招数据倾斜场景下的SQL优化方案

校招面试经常会问大家有没有过调优的经验,相信大家的回答基本都是往数据倾斜和小文件问题这两方面回答,对于数据倾斜相信大部分同学对热key打散或null值引发的倾斜已经非常熟悉,但这些内容面试官也是听腻了,希望大家在面试时候讲一些高大尚的案例,在描述的时候一定要有背景,有解决方案,最后结果,毕竟数据倾斜不会无故产生,一定是有业务背景的,这里给大家分享一种数据倾斜优化案例。

1.Uid和oaid之间的转化

在用增的拉新拉回业务中,经常会用到oaid来识别具体的设备是不是公司用户,所以我们需要将uid→oaid,需求目的:找到当日拉新的uid对应的oaid映射关系

代码如下:

  • 1.从id mapping表中找出uid→oaid的映射关系;

  • 2.根据最后一次活跃时间对uid→oaid映射关系去重;

  • 3.将算法提供的uid人群圈选出对应的oaid。

原来的sql

复制代码
select
  t1.user_id,
  oaid_md5
from
  (
    select
      L.uid user_id,
      md5(L.oaid) oaid_md5
    from
      (
        select
          distinct uid,
          oaid
        from
          (
            select
              uid,
              oaid,
              row_number() over (
                partition by oaid
                order by
                  cast(last_active_timestamp as bigint) desc
              ) as rn
            from
              idmapping as G
            where
              G.p_date = '20250324'
              and G.left_type = 'USER_ID'
              and G.right_type = 'OAID'
          ) tt
        where
          tt.rn = 1
      ) as L
      left join (
        select
          id
        from
          zuobishebei -- 作弊设备
        where
          p_date = '{{ds_nodash}}'
          and supplier = 'cheat'
      ) as P on (md5(L.oaid) = P.id)
    where
      P.id is null
  ) t2
  join (
    SELECT
      user_id
    FROM
      list_ground_truth
    WHERE
      p_date = '20250324'
  ) t1 on t1.user_id = t2.user_id

粗略一看,符合正常计算流程和顺序,但这段sql出现了明显的数据倾斜。

经过排查代码中有两块可能引起倾斜,一个是join,一个row number,先查询一下uid→oaid映射情况,发现部分的uid映射过10亿多的oaid,导致在去重的时候发生了数据倾斜。

解决方案

  • 1.使用过滤条件和分组操作减少数据量;

  • 2.通过调整连接顺序和提前应用过滤条件,减少了中间数据量;

  • 3.如果倾斜仍然存在,考虑对倾斜字段进行分区或使用 broadcast join 来进一步优化。

优化后:

复制代码
SELECT
  user_id,
  md5(paid) AS oaid
FROM
  (
    SELECT
      user_id,
      paid,
      ROW_NUMBER() OVER (
        PARTITION BY user_id
        ORDER BY
          CAST(last_active_timestamp AS BIGINT) DESC
      ) AS rn
    FROM
      (
        SELECT
          t1.user_id,
          t2.paid,
          t2.last_active_timestamp
        FROM
          (
            SELECT
              user_id
            FROM
              list_ground_truth
            WHERE
              p_date = '20250324'
          ) t1
          JOIN (
            SELECT
              uid,
              oaid,
              G.last_active_timestamp
            FROM
              idmappingG
            WHERE
              G.p_date = '20250324'
              AND G.left_type = 'USER_ID'
              AND G.right_type = ' OAID '
            GROUP BY
              G.left_value,
              G.right_value,
              G.last_active_timestamp
          ) t2 ON t1.user_id = t2.uid
      ) t3
  ) t1
WHERE
  rn = 1

原始脚本和优化后的脚本在逻辑上保持一致,但重点在于先jion较小的表(idmapping和 list_ground_truth),在进行row number,这样可以在join时先走map join同时减少row number执行的数据量。

相关推荐
科技小花3 小时前
数据治理平台架构演进观察:AI原生设计如何重构企业数据管理范式
数据库·重构·架构·数据治理·ai-native·ai原生
一江寒逸3 小时前
零基础从入门到精通MySQL(中篇):进阶篇——吃透多表查询、事务核心与高级特性,搞定复杂业务SQL
数据库·sql·mysql
D4c-lovetrain3 小时前
linux个人心得22 (mysql)
数据库·mysql
阿里小阿希4 小时前
CentOS7 PostgreSQL 9.2 升级到 15 完整教程
数据库·postgresql
荒川之神4 小时前
Oracle 数据仓库雪花模型设计(完整实战方案)
数据库·数据仓库·oracle
做个文艺程序员4 小时前
MySQL安全加固十大硬核操作
数据库·mysql·安全
不吃香菜学java4 小时前
Redis简单应用
数据库·spring boot·tomcat·maven
一个天蝎座 白勺 程序猿4 小时前
Apache IoTDB(15):IoTDB查询写回(INTO子句)深度解析——从语法到实战的ETL全链路指南
数据库·apache·etl·iotdb
不知名的老吴4 小时前
Redis的延迟瓶颈:TCP栈开销无法避免
数据库·redis·缓存
YOU OU4 小时前
三大范式和E-R图
数据库