【问渠哪得清如许-数据分析】学习笔记-上

【问渠哪得清如许】是我的一个系列，数据分析的内容，随着我的学习会陆续把我的笔记上传，如果你也正在学习相关内容，可以参考我的学习路径。

另外还有【问渠哪得清如许-产品经理】是阅读产品经理相关书籍的笔记。

【问渠哪得清如许-产品经理】阅读笔记《产品经理方法论------构建完整的产品知识体系（第2版）》上-CSDN博客

SQL学习笔记

一、图片笔记

写sql重要的是记住执行顺序，能够帮助你后面很多逻辑理解，接着同样重要的是从需求出发开始写。

我做这些笔记之前的状态是：有sql基础，上过《数据库原理》课程

我的难点在于：我能看懂别人写的，难度稍微增加自己就写不出来，因此需要继续学习。

建议先听一个十几分钟的sql迅速入门的视频，再看笔记，有疑问欢迎留言讨论~

图片笔记先是知识点回忆，接着是精选习题。

还有题没有写完，明天继续~

二、文字笔记

问题1：Map Join 和 Sort Merge Join 的区别

第一种方法：Map Join（原地干活法）

核心思想： 既然VIP名单只有10个人，我把这10个人的名单复印1万份，发给每个负责签到的工作人员。他们直接在原地就能完成核对。

具体干活流程：

复印分发（Broadcast）： 主持人把VIP名单（小表）复印了无数份，塞到每一个负责签到的**工作人员（Map节点）**手里。
原地干活（Map）：
- 工作人员A（负责1-1000号嘉宾）：手上有嘉宾名单，兜里揣着VIP名单。他一边给嘉宾签到，一边掏出VIP名单看一眼："张三？VIP名单里有他，给他一个金礼盒。李四？名单里没有，那就普通签到。"
- 工作人员B（负责1001-2000号嘉宾）：做一模一样的事情。
结果： 所有工作人员同时开工，不需要互相打电话，不需要把嘉宾名单传来传去。1万人很快就处理完了。

这就是 Map Join（也叫 Broadcast Join）：

怎么干： 小表复制到每个内存中，大表原地扫描匹配。
特点： 快！没有网络传输（Shuffle），没有数据倾斜。
代价： 小表必须足够小（能塞进内存）。

第二种方法：Sort Merge Join（分拣中心法）

核心思想： 如果VIP名单也很大（比如5000人）（此时没有足够小的小表，不适合用Map Join），没法复印给每个人。那只能把所有数据都送到"分拣中心"，统一分类处理。

具体干活流程：

第一阶段：各自整理（Sort - 排序）
- 现场工作人员（Map节点）把各自手头的嘉宾名单按姓名拼音排序。
- 另一边，负责VIP名单的工作人员也把VIP名单按姓名拼音排序。
第二阶段：送往分拣中心（Shuffle - 洗牌）
- 所有排好序的嘉宾名单数据，全部被送到中央分拣中心（Reduce节点）。
- 所有排好序的VIP名单数据，也全部被送到中央分拣中心。
第三阶段：统一配对（Merge - 合并）
- 分拣中心的工作人员拿到两堆排好序的名单（一堆嘉宾，一堆VIP）。
- 他开始像拉链一样，按顺序对齐名字：
  - 嘉宾"张三" vs VIP"张三" -> 匹配成功，发礼盒。
  - 嘉宾"李四" vs VIP"王五" -> 名字顺序不对？ VIP那边往后走走，找找有没有"李四"。
  - 这个过程就是经典的双指针归并排序。

这就是 Sort Merge Join：

怎么干： 先各自排序，然后通过网络汇总到一起，最后合并。
特点： 稳！能处理任意大小的表。
代价： 慢！有大量的网络传输（Shuffle），并且如果"张三"特别多（数据倾斜），分拣中心处理"张三"的那个人就会累死，其他人闲着。

Shuffle = 分布式计算的"搬家"过程 ------ 把分散在各处的相同 Key 数据，通过网络搬运到同一个地方。搬家次数越多、东西越重，任务就越慢！

这也是为什么 Map Join（不搬家）比 Sort Merge Join（大搬家）快得多的根本原因。

补充：双指针归并排序解释：两队人按身高排好队，两个裁判从头走到尾，身高一样的就配对，不一样的就矮的那队往前走一步继续比。全程只走一遍，O(N+M)

问题2：什么是"sql中的数据倾斜"？

解答：

在数据库原理（尤其是分布式计算框架如 Hive、Spark SQL）中，"小表关联大表造成数据倾斜" 或者"大表关联小表造成数据倾斜 "，我们可能会听到这样的表述。但其实无论你怎么写SQL，决定是否倾斜的是执行方式，不是谁关联谁的顺序，因为 实际上，在关系型数据库或 SQL 语法层面，表关联的顺序（谁 left join 谁）在优化器逻辑上通常没有区别，优化器会重写 SQL。

概念	含义	是否导致倾斜
Map Join	引擎的执行方式（小表广播）	不会
Sort Merge Join	引擎的执行方式（两边shuffle）	可能

以下是详细的解释：

场景： 优化器选择了 Sort Merge Join，但两张表的关联键（Join Key）分布不均匀。
倾斜的本质： 假设大表有 1 亿条数据，小表有 100 条数据。如果按照某个关联键（例如 city_id）进行 Join，而大表中 90% 的数据的 city_id 都等于"北京"。
结果： 在分布式计算中，数据会根据关联键的哈希值分配到不同的 Reduce 任务（或节点）上。由于"北京"这个 Key 的数据量巨大，负责处理"北京"这个 Key 的那个节点（Task）就需要处理 9000 万条数据的 Join 操作，而其他节点只需要处理 1000 万条。
现象： 整个 SQL 任务卡在 99% 进度不动，或者运行极其缓慢。这被称为 "长尾效应"，即数据倾斜。