作为一枚混迹多年的 SQL Boy，本文想和大家聊聊我个人在 SQL优化 上的一些视角和经验。主要针对大数据计算引擎，诸如Hive、SparkSQL。
在探讨优化策略时，我通常会从以下几个层面切入：
1. 业务目标与资源投入权衡
2. 数据仓库层优化
3. 数据表设计优化
4. SQL 语句编写优化
5. 计算引擎参数调优
6. 作业拆分优化
一、业务目标与资源投入权衡
当你问一个人他当前所做的事是出于什么目的，如果他回答含糊其辞，不知所以，这是很让人尴尬的。这对于SQL编写数据输出也是一样的，作为数据分析师，首先要明确动作业务目标，而在需求澄清中，优秀的分析师往往会去琢磨业务深层次的需要（在实际工作对接中不排除会遇到含糊的业务）。
面对业务需求，数据分析师会出现如下问题：
需求澄清：这个需求业务背景是什么，具体业务术语定义澄清
深层需要：业务背后深层次的需要是什么。表面需求是钥匙孔，深层次需求才是打开机会的那把钥匙。明白了业务深层次的需要，可能就会有：业务的需求（表层）实现不了，但是能实现业务的需求（深层）。
需求价值及需求可行性分析：需求应用价值如何？有哪几种方案？方案可行性如何？然后在投入与价值评估中选择合适的方案执行。
如果需求未能澄清，分析师不明白业务背景，最典型的情况就是：数据分析师多次返工。
比如如下的案例：
某电商公司的营销部门提出需求：分析过去30天高价值用户的购买行为特征，用于设计精准促销活动。
数据分析师（DA）直接承接需求，未进行深度澄清。
初次交付：拉取了“消费金额TOP1000用户”的订单数据
业务反馈：“这些用户虽然消费高，但80%是批发商！我们要的是‘高频复购的潜力用户’，不是大客户。”
问题：未澄清“高价值用户”定义（业务实际指：复购率高、客单价中上、非企业用户）。
第二次返工：DA增加“复购次数”筛选：筛选了复购>=3次的。
业务反馈：“为什么用户数这么少？促销活动需要覆盖5万人，另外请排除使用企业优惠券的用户！”
问题：未确认数据量级、未识别“企业用户”标签规则（业务需求：个人消费者）。
第三次返工：DA补充排除企业用户，扩大时间范围至90天获取更多用户。
业务反馈：“90天前的用户可能已流失！我们要的是‘近期活跃’用户，另外请区分不同品类的购买偏好。”
问题：未明确“近期活跃”时间窗口、未确认是否需要品类维度。
当然从信息传达来说，出现了上述情况，多次返工这锅不能完全DA来背（实际工作中，普遍是业务觉得DA不专业）。好的业务，比如产品会写一手漂亮的PRD需求文档，在需求评审时会自我澄清，而DA则会以自己的理解复述业务需求以对齐。
二、数据仓库层优化
数据仓库层优化，抛开数仓分层、元数据规范等（规范减少认知成本，有助于SQL提升编写效率，比如统一词根命名，码值等）。在SQL优化主要有如下两块：
高频应用数据搭建中间表，减少数据计算。比如累全量表，粗颗粒度表诸如天、月表，有小时聚合到天，再由天表聚合到月表（在日志、订单数据中比较常见）。
维度冗余构造宽表：比如把高频分析维度字段存储到事实表里，以减少表关联（尤其维度要关联多个维表的，写起sql是真累）。
三、数据表设计优化
表层面优化通常有如下几块：
文件存储格式：比如大数据HDFS表通常以ORC存储。TextFile类型对筛选列很不友好。
分区、分桶及索引设计：这块主要是减少数据扫描，提升数据行抽取效率。
字段类型：在明确字段范围的前提下，尽可能使用存储空间较小的字段类型。比如用户性别标签可以使用boolean或者tinyint类型标记。
四、SQL 语句编写优化
SQL语句优化在大数据引擎主要围绕如下两点：
减少计算与shuffle数据量：比如mapjoin，不同join表关联顺序，groupby和join的先后顺序等（具体情况具体分析）。
负载均衡：各种倾斜处理措施，主要是针对groupby和join两种倾斜应用场景
五、计算引擎参数调优
主要有如下两类：
计算逻辑类参数：诸如合并小文件（分为job前读取和job后整合数据块）、shuffle参数、自动mapjoin参数，自动处理倾斜参数等。
资源类参数：比如hive里边的job并行数参数，SparkSQL里的cpu和内存配置。
六、作业拆分优化
作业拆分在实际生产中，主要基于如下三点：
保障作业在有限的资源及时效内完成：数据平台侧可能对单作业资源配置及运行时长有限制（超长会被系统kill掉）。
避免占用过多资源，资源负载，集群其他作业长时间等待。
提升作业时效：对于包含多段依赖不同上游的逻辑块（即子任务）的作业，若全部集中在一个作业中执行，则必须等待所有上游完成才能启动。通过将上游已就绪的逻辑块拆分为独立作业提前执行，可以在特定场景下显著缩短整体作业的完成时间。
最后再补充一点，SQL优化虽好，但需考量数据分析师的优化投入成本。对于优化预期收益远低于分析耗时的作业（例如，优化分析元数据需 >0.5 小时，而作业本身计算仅需几分钟且数据为临时采集），那么作业编辑完，直接提交即可。
