做数据仓库项目的时候最绕不开的一个环节就是 ETL也就是数据抽取、转换、加载的过程。不管你是用 SQL Server、MySQL、Oracle还是国产的达梦数据库只要你想把业务库的数据搬进数据仓库或者把数仓里的明细数据整理成可用的分析模型ETL 就是那条必经之路。这篇文章记录的是我在一个以 SQL 为主要工具的数据仓库项目中对 ETL 过程的完整拆解和实操总结包含分层设计思路、增量抽取方案、清洗去重的具体写法以及我在调度、性能优化和问题排查上踩过的坑适合正在做数据仓库相关工作、或者准备接手 ETL 任务的同学参考。我最早接触 ETL 的时候也以为这活儿必须得上 Informatica、Kettle 之类的专业工具甚至有人一上来就推 Flink、Spark。但实际做过几个项目之后我的体会是在很多中小型数仓场景里SQL 本身就已经能覆盖 ETL 的绝大部分需求而且维护成本更低、排查问题更直观。这篇文章会把我实际项目里的完整思路、SQL 写法和遇到的问题都摊开来讲希望能帮你少走点弯路。1. 项目背景与整体设计思路1.1 为什么选择用 SQL 来完成 ETL在聊具体实现之前先讲讲我为什么会选择用 SQL 来承担这个数据仓库项目的 ETL 工作。当时项目的数据量级不算特别大日增数据在百万行左右历史数据也就几千万行业务库主要是 MySQL和 SQL Server数仓这边用的是支持标准 SQL 的列式存储数据库。在这个量级下引入一整套大数据计算引擎反而有点杀鸡用牛刀而 SQL 方案的几个优势让我决定把它作为主力方案。第一SQL 的学习门槛低。团队里不管是后端开发还是数据分析师基本都会写 SQL。用 SQL 做 ETL大家上手快写出来的逻辑也能互相 review不像专业 ETL 工具那样有自己的图形化配置和脚本语言外人看半天看不懂。第二SQL 天然贴近数据逻辑。ETL 的核心是数据转换而数据转换在 SQL 里就是 SELECT、JOIN、GROUP BY、CASE WHEN 这些操作表达起来特别直接。你不需要把数据从数据库里捞出来放到内存里再写 Java 或 Python 处理直接在数据库里就能完成。第三排错方便。数据出了问题SQL 任务可以直接一段一段跑中间结果也能临时落表查看问题定位非常快。相比之下用专业工具搭出来的 ETL 流程数据异常时经常要一层层点开节点看日志效率低很多。当然SQL ETL 也有它的短板比如不适合非常复杂的业务逻辑和机器学习类转换跨数据库类型的数据迁移也需要额外处理。但就我们这个项目的场景来说SQL 方案是最合适的选择。注意SQL ETL 适合数据量可控、转换逻辑以关系运算为主、团队 SQL 能力较强的场景。如果数据量达到 TB 级以上或者需要实时处理那再考虑升级到分布式计算引擎比较合适。1.2 数据仓库分层设计中 ETL 的定位数据仓库建设的第一步往往不是写 ETL而是设计分层。我见过不少项目上来就直接从业务库抽数据到报表表结果后面需求一变动整套流程推倒重来。在这个项目里我们采用的是经典的四层架构ODS、DWD、DWS、ADS。ODS 层贴源层和业务库的表结构基本一致主要做增量或全量抽取保留原始数据。DWD 层明细层对 ODS 层的数据做清洗、去重、维度退化、格式规范化形成干净的明细数据。DWS 层汇总层按业务主题做轻度汇总比如用户维度的当日订单数、金额等。ADS 层应用层面向具体报表或业务需求数据高度聚合。ETL 在每一层之间都承担着不同的任务。ODS 到 DWD 是整个流程里最重的一段因为几乎所有清洗和转换都发生在这里DWD 到 DWS 主要是聚合运算DWS 到 ADS 相对简单一般就是按报表需求取数。把 ETL 放在分层架构里通盘考虑是我在实际项目中踩过坑之后才深刻体会到的。刚开始做第一个版本时我跳过了 DWD 层直接从 ODS 聚合到 ADS结果业务方说“订单金额的计算口径要改”我不得不把已经算好的所有报表都重新刷一遍那感觉相当酸爽。后来规规矩矩做了分层每一层各司其职改动某一层的逻辑时其他层基本不受影响整个 ETL 流程的可维护性一下子提升了不少。2. ETL 核心概念拆解与实现方案2.1 抽取Extract全量抽取与增量抽取的选择ETL 的第一步是抽取也就是把源系统的数据拿过来。这里第一个要决策的问题就是全量抽取还是增量抽取。全量抽取最简单直接SELECT * FROM source_table然后覆盖写入目标表就行。这种方式适合数据量小、变化不频繁的维表比如省份表、产品分类表。但如果是每天几百万行增长的订单表全量抽取显然不现实既有存储开销也会让 ETL 任务越跑越慢。所以对于大表一定要做增量抽取。增量抽取的常见策略有三种时间戳增量、主键增量和日志增量。时间戳增量源表里有一个 update_time 或 create_time 字段每次抽取时取上次抽取的最大时间戳作为边界拉取新增或修改的数据。这是最常用的方式实现也最直接。需要注意的一点是如果源表有数据被物理删除时间戳方式是感知不到的需要额外处理。主键增量主要针对只增不改的表比如日志表、流水表。每次抽取记录当前最大主键下一次只拉主键更大的数据。这种方式简单高效但前提是源表确实没有更新操作。日志增量基于 binlog 这类日志解析变更能够捕捉到删除和更新但需要额外组件配合一般在大数据量、实时性要求高的场景下才会用到。在这个项目里我们的订单表采用的是基于 update_time 的时间戳增量同时配合一个删除标记位业务系统不做物理删除只更新逻辑删除标记这样 T1 的 ETL 任务通过时间戳就能完整同步新增、更新、删除三类变化逻辑清晰不丢数。2.2 转换Transform清洗、去重、格式化是核心中的核心抽取做完之后就是转换这也是整个 ETL 过程中最花时间、最考验 SQL 功底的部分。转换的动作五花八门但归纳起来主要就是三类清洗、去重和格式化。清洗的核心是处理脏数据常见的脏数据包括空值、异常值、不合法的枚举值等。比如订单金额字段出现了负数或者 NULL就需要用 CASE WHEN 或者 COALESCE 将这些值处理成合理的兜底值或者打上异常标记放入异常表。去重是整个 ETL 里我最想强调的一环。业务库的表通常有主键约束但到了数仓环境由于多源合并、重跑任务等原因很容易出现重复数据。如果不做去重后面的聚合结果全是错的。在 SQL 里做去重最常用的是ROW_NUMBER()窗口函数按业务主键分区、按更新时间倒序排序然后取排名为 1 的记录。格式化则是把数据的口径统一比如日期从字符串变成标准日期格式、金额统一保留两位小数、手机号统一为 11 位并去掉空格等。这些规则看似琐碎但如果不在 DWD 层处理好后面每一层用到的时候都要重复处理那是巨大的浪费。回到我们刚才提的热搜词里反复出现的“sql语句去重”、“sql去除空值”其实就是 ETL 转换环节最基础、最高频的两个操作。我见过不少面试者能把窗口函数背得很熟但实际写出来的去重 SQL 却连分区键的定义都不清晰这种情况下到数仓里跑出来的数据基本不敢用。2.3 加载Load分区写入与断点续跑转换完的数据最终要加载到目标表里。这一步看起来就是一个 INSERT但里面也有不少讲究。第一个讲究是分区策略。数仓里的表一般都会按日期做分区每天一个分区这样查询时只要扫对应分区的数据效率和维护性都很好。加载数据时我们用的写法通常是INSERT OVERWRITE TABLE ... PARTITION(dt2024-06-01)或者先用临时表算好结果再原子性地交换分区。第二个讲究是加载的幂等性。ETL 任务有时候会因为源数据质量、网络抖动等原因失败重跑的时候必须保证结果和第一次跑完全一样。如果加载时没有清理掉上次残留的数据很可能造成重复计数的惨案。所以我们在加载前都会先做一个 DELETE 或者 TRUNCATE 分区的操作保证任务的幂等性。第三个讲究是临时表的使用。复杂的 ETL 任务如果一步到位SQL 会变得特别长中间任何一步出错都难以排查。我习惯把转换过程拆分到多张临时表里比如第一步先清洗第二步再去重第三步做维度关联最后再插入目标表。虽然多写了几条 SQL但每一步都能单独验证结果实际问题中这种做法省下的排错时间远超多花的开发时间。注意加载阶段的幂等性设计非常关键。ETL 任务重跑是常态如果没有幂等保障一次失败重跑就可能把整张表的数据搞乱而且这种问题往往要在下游报表数字对不上时才能暴露出来代价很高。3. 基于 SQL 的 ETL 实操过程3.1 用 SQL 实现数据清洗的核心写法讲完了设计思路接下来直接上实操。我说一下项目里最常用的几个 SQL 清洗写法这些语句在我的 ETL 脚本里出现频率极高。首先是空值处理。对于不允许为空的字段我会用 COALESCE 或者 CASE WHEN 来兜底SELECT order_id, COALESCE(user_id, UNKNOWN) AS user_id, COALESCE(amount, 0) AS amount, COALESCE(pay_time, create_time) AS pay_time, CASE WHEN status IS NULL OR status NOT IN (PAID, UNPAID, REFUNDED) THEN UNKNOWN ELSE status END AS status FROM ods_order;其次是格式化处理。比如把日期时间字段统一为yyyy-MM-dd HH:mm:ss格式、把金额统一为 decimal(10,2)SELECT order_id, DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s) AS create_time, CAST(ROUND(amount, 2) AS DECIMAL(10,2)) AS amount, REGEXP_REPLACE(phone, [^0-9], ) AS phone FROM ods_order;这里的 REGEXP_REPLACE 在 MySQL 8.0 和 SQL Server 2022 里都可以用老版本的话需要改用 REPLACE 函数嵌套处理。最后是异常数据标记。对于一个 ETL 任务来说与其让异常数据直接报错中断不如把它标记出来放进异常表让任务继续跑同时触发告警人工处理。我们常用的写法是这样的INSERT INTO dwd_order_exception SELECT order_id, amount_invalid AS exception_type, amount AS exception_value, CURRENT_TIMESTAMP AS occur_time FROM ods_order WHERE amount 0 OR amount IS NULL;异常表里能看出哪条数据有问题、什么类型的问题后续不管是补数还是修正口径都有据可查。3.2 增量抽取的 SQL 实现思路接下来看增量抽取的 SQL 怎么落地。我们项目里最典型的一个场景是每天凌晨同步前一天的业务订单数据源表有主键 order_id有更新时间字段 update_time有逻辑删除标记 is_deleted。我们的增量抽取脚本大概长这样-- Step 1: 找到上一次抽取的最大 update_time -- 这个值可以存到调度表的 meta 字段里也可以直接查目标表 SELECT MAX(update_time) INTO last_max_update_time FROM dwd_order WHERE dt ( SELECT MAX(dt) FROM dwd_order ); -- Step 2: 拉取增量数据到临时表 CREATE TEMPORARY TABLE tmp_order_inc AS SELECT * FROM ods_order WHERE update_time last_max_update_time; -- Step 3: 对增量数据做清洗转换 INSERT INTO dwd_order ( order_id, user_id, amount, status, create_time, update_time, dt ) SELECT order_id, COALESCE(user_id, UNKNOWN), amount, status, DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s), update_time, 2024-06-01 FROM tmp_order_inc WHERE update_time last_max_update_time;这里有一个非常容易踩的坑如果源表数据量很大直接在UPDATE_TIME字段上写UPDATE_TIME ...但源库该字段没有索引那全表扫描的性能会是灾难级的。我们当时在 MySQL 源库的订单表上给 update_time 建了索引增量抽取速度从最初的几分钟降到了十几秒效果立竿见影。另一个增量抽取的常见问题是边界重复。如果抽取任务的执行时间和源库写入时间非常接近可能会出现“上一次没抽到、下一次又因为边界条件漏掉”的情况。所以我在设计时故意让时间边界留出一点余量比如取上次最大 update_time 往前推 5 分钟作为本次起点这样能有效避免边界数据丢失代价只是多抽几条数据使用幂等写入处理掉即可。3.3 层间流转的完整落地示例上面讲了单个步骤现在我把 ODS 到 DWD 的完整流转过程串起来给大家一个可以直接参考的模板。假设我们的订单业务有三张表订单主表 ods_order、订单明细表 ods_order_item、商品表 ods_product。目标是把这三张表整合成一张宽表 dwd_order_detail提供给下游做分析使用。整个 DWD 构建流程分四步。第一步清洗订单主表数据DROP TABLE IF EXISTS tmp_order_clean; CREATE TABLE tmp_order_clean AS SELECT order_id, COALESCE(user_id, UNKNOWN) AS user_id, COALESCE(amount, 0) AS amount, status, DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s) AS create_time, update_time FROM ods_order WHERE dt 2024-06-01;第二步清洗订单明细表DROP TABLE IF EXISTS tmp_order_item_clean; CREATE TABLE tmp_order_item_clean AS SELECT order_id, order_item_id, product_id, quantity, COALESCE(price, 0) AS price FROM ods_order_item WHERE dt 2024-06-01;第三步清洗商品表DROP TABLE IF EXISTS tmp_product_clean; CREATE TABLE tmp_product_clean AS SELECT product_id, COALESCE(product_name, UNKNOWN) AS product_name, category_id FROM ods_product WHERE dt 2024-06-01;第四步关联生成宽表同时用窗口函数去重DROP TABLE IF EXISTS tmp_order_detail_rank; CREATE TABLE tmp_order_detail_rank AS SELECT oc.order_id, oc.user_id, oic.product_id, pc.product_name, pc.category_id, oic.quantity, oic.price, oc.amount, oc.status, oc.create_time, ROW_NUMBER() OVER ( PARTITION BY oc.order_id, oic.order_item_id ORDER BY oc.update_time DESC ) AS rn FROM tmp_order_clean oc LEFT JOIN tmp_order_item_clean oic ON oc.order_id oic.order_id LEFT JOIN tmp_product_clean pc ON oic.product_id pc.product_id; -- 最终写入 DWD 表 INSERT OVERWRITE TABLE dwd_order_detail PARTITION(dt 2024-06-01) SELECT order_id, user_id, product_id, product_name, category_id, quantity, price, amount, status, create_time FROM tmp_order_detail_rank WHERE rn 1;这段流程的价值在于每一步都是可验证的清洗后的临时表可以对账源表行数关联后的结果可以抽样检查关联率去重后的数据可以检查唯一键。ETL 任务跑完不光是完成了还要能解释清楚“为什么这个数字是这么多”临时表就是连接源数据与最终结果的证据链。3.4 日期分区与调度依赖设计层间流转做完了还有一个基础设施层面的问题要解决任务调度与依赖。我们的 ETL 任务是 T1 模式每天凌晨跑调度工具用的 DolphinScheduler。DolphinScheduler 支持 SQL 任务类型我们可以直接把上面的 SQL 脚本配置成工作流节点并设置任务之间的依赖关系。这里我重点说几个调度依赖的经验。第一ODS 层抽取任务必须在源系统备份任务完成之后再启动。我们当时遇到过源库凌晨做逻辑备份占用了大量 IOETL 任务同时跑导致源库查询特别慢的情况。后来在调度里给 ODS 同步任务加了一个上游等待节点错峰执行问题就解决了。第二DWD 层任务和 DWS 层任务之间必须有明确的依赖关系不能简单用时间来判断。我们刚开始用固定时间触发比如 DWD 每天 3 点跑、DWS 每天 4 点跑但一旦某个 DWD 任务因为数据量异常跑慢了DWS 就会基于不完整的数据计算出错误结果。后来改用 DolphinScheduler 的任务依赖机制DWS 节点显式依赖 DWD 节点执行成功后才触发再没出过这类问题。第三调度系统要支持失败重跑和补数。数据仓库里不同步的数据很常见补数功能必不可少。DolphinScheduler 里每个任务节点都可以单独重跑重跑时我们只要把 SQL 里的分区参数改成需要补的日期就行。这里有一个技巧调度参数尽量用变量传日期比如 dt 参数从调度系统传入SQL 写WHERE dt ${dt}这样同一个脚本既能跑当天任务也能补历史数据不用复制一堆重复脚本。4. 工具选型解析与性能调优4.1 工具选型从纯 SQL 脚本到可视化调度聊完实操我们来说说工具选型。虽然我前面说 SQL 能搞定 ETL 的大部分工作但在实际项目里完全裸写脚本手动跑是不现实的总得有调度、监控、告警这些基础设施。这里给大家分享我当时做工具选型时的对比和取舍。方案优点缺点适用场景纯 SQL 脚本 crontab部署简单、无额外组件无依赖管理、无告警、补数困难极小型项目临时用SQL 脚本 DolphinScheduler可视化 DAG、任务依赖清晰、支持告警和补数需要额外部署一套调度平台大多数离线数仓场景专业 ETL 工具如 Kettle、DataX图形化配置、组件丰富、支持异构数据源学习成本高、排错不够直观、对复杂 SQL 支持弱非技术团队操作、跨异构系统抽取大数据计算引擎如 Spark、Flink处理能力强、支持实时运维成本高、开发周期长超大体积数据量、实时数仓这个表格里的方案我基本都用过最终在这个项目里选择了 DolphinScheduler理由很简单它既有可视化的工作流编排又完全支持 SQL 任务和参数化配置跟我们的 SQL ETL 方案配合得非常顺。而且 DolphinScheduler 是有开源社区在维护的文档也相对完善团队上手成本不算高。4.2 慢 SQL 优化让 ETL 任务跑得更快在 ETL 过程里性能问题主要集中在转换环节也就是 SQL 跑得慢。我总结了几条最实用的 SQL 优化经验都是在这个项目里验证过的。第一合理使用索引。增量抽取的场景我在前面已经提过给源表的 update_time 加索引能带来几十倍的性能提升。同理在关联操作中JOIN 字段如果能有索引关联速度会有质的飞跃。这里有个前提数仓表一般是列式存储本身查询性能就比较好但如果用的是行式存储的数据库索引策略就要认真设计。第二避免在 WHERE 条件中对字段做函数操作。比如WHERE DATE_FORMAT(update_time, %Y-%m-%d) 2024-06-01这种写法会导致索引失效应该改成WHERE update_time 2024-06-01 00:00:00 AND update_time 2024-06-02 00:00:00。我在维护别的同事的 ETL 脚本时经常看到这类低级错误改完之后查询时间能减少一半以上。第三减少不必要的数据扫描。ETL 任务尽量在源头就过滤到只保留需要的字段和行不要一开始就 SELECT * 全量捞出来再在下一层过滤。列式存储数据库还好一点行式存储数据库这么干基本就等着任务超时吧。另外能分区裁剪的情况一定要分区裁剪比如查某一天的数据就直接指定分区条件不要全表扫。第四合理使用临时表代替嵌套子查询。有些复杂的 ETL 逻辑会写成五层嵌套子查询数据库优化器不一定能优化到最佳执行计划。把中间结果落临时表每层都物化反而能让每一步的执行计划更清晰性能也更稳定。这在业务逻辑复杂、多表关联的情况下尤其管用。4.3 慢 SQL 的排查方法与常见问题速查聊到慢 SQL我把实际项目中最常用的一套排查方法分享给大家。当某个 ETL 任务跑得特别慢时我一般按下面的顺序处理。先看执行计划。MySQL 用 EXPLAINSQL Server 里就是显示执行计划Oracle 是 EXPLAIN PLAN FOR。重点看 type 列是不是 ALL全表扫描key 列有没有用上索引还有 rows 估算的和实际是否差很多。执行计划一眼就能看出问题在哪。再看数据量分布。有时候 SQL 本身没问题但源表的某几个值占比极高比如订单表里有一个测试账号占了 80% 的数据关联时就会产生严重的数据倾斜导致任务卡死。这种情况一般需要单独处理这些热点值把它们拆出去单独计算最后再合并结果。然后看锁等待。ETL 任务跑得慢不一定是 CPU 不够很可能是卡在锁等待上。尤其是多任务并发写同一张表时锁竞争会非常严重。可以查一下数据库当前的锁等待情况看是不是有任务持锁不释放。我当时遇到过源库的备份任务长时间锁表我的 ETL 任务一直等待后来把调度时间错开了才解决。最后看资源。如果 SQL 已经优化得差不多了但还是慢那就要考虑是不是数据库服务器的内存、磁盘 IO 不够用了。这时候最简单的办法是看数据库的监控面板确认是 CPU 瓶颈、内存瓶颈还是磁盘瓶颈再做针对性的扩容或参数调整。4.4 常见问题与排查技巧实录最后分享几个在 ETL 项目里比较有代表性的问题和排查过程这些问题在新手阶段特别容易碰到。第一个问题是数据重复。现象是某张报表的数据比业务系统里统计出来的多了不少但对账发现 DWD 层的明细数据就有重复。我们排查后发现原因是源系统在一天内对同一条订单做了多次更新而增量抽取按 update_time 把多次更新都拉进来了。当时的修复方案就是在 DWD 层用 ROW_NUMBER() 窗口函数按订单号分区、按 update_time 倒序去重保留最新的一条记录。从那以后我们在 DWD 层对所有明细表都建立了唯一性校验脚本每天定时跑一旦发现重复数据立刻告警。第二个问题是下游报表数据和源系统对不上。这个问题的排查思路是从 ADS 一层层往下钻先看 ADS 的取数逻辑再看 DWS 的汇总口径再看 DWD 的明细数据最终定位到问题出在 DWD 层关联商品表时部分商品因为分类信息缺失而被过滤掉了。根因是商品表有 2000 多条过期数据没有同步到数仓。解决方法是把内连接改成了左连接同时把缺失维度信息的数据单独标记出来避免静默丢数据。第三个问题是调度依赖导致的脏数据。有一阵子我们每天早上的报表数据偶尔会不准排查了半天发现是 DWS 层任务偶尔会先于 DWD 层任务跑完。虽然调度平台显示 DWD 任务执行成功了但那个成功其实是调度平台层面的成功DWD 任务对应的 SQL 内部有一个隐式提交没有生效数据还没完全可见。后来调整了调度依赖同时把 DWD 和 DWS 改为依赖血缘关系而不是简单的执行成功标志这个问题才彻底解决。这也是为什么我一直强调调度依赖不能只看“跑没跑完”还要看“数据就绪没有”。第四个问题是数据库死锁。有一次 ETL 重跑任务时两个任务同时尝试更新同一张表的同一个分区数据库直接报死锁错误重跑了好几次都失败。排查下来发现是两张表之间存在互相更新的操作形成了环路等待。解决办法是制定了统一的锁顺序规范保证所有任务访问同一批表时的加锁顺序一致同时把大事务拆成小事务降低锁持有时间。这里多说一句死锁这个问题在 ETL 场景里其实并不罕见尤其是多个任务并发跑、操作同一批资源的时候最好在调度层就避免并发冲突比在数据库层面解决锁问题要省事得多。注意尽量在调度层规避并发写同一张表的情况。数仓里的 ETL 任务大部分是批量操作完全没必要搞高并发串行执行不仅能避免死锁还能让每批 IO 更稳定整个链路跑下来更省心。5. 关于 SQL 安全与性能的额外思考5.1 SQL 注入风险在 ETL 场景中的体现聊 ETL 过程的时候大部分人关注的是数据处理逻辑本身但我必须提醒一句只要你的 ETL 脚本里有动态拼接 SQL 的场景SQL 注入的风险就存在。我们项目早期就遇到过一个问题业务方配置的过滤条件直接拼到了 ETL 的查询 SQL 里结果某个配置值里带了一个单引号直接把整段 SQL 搞报错了。更严重的是如果配置值是恶意构造的甚至可能通过这种方式读取到数仓里其他表的数据。所以我的建议是ETL 脚本里尽量不要使用动态拼接 SQL所有过滤条件、表名都通过参数化方式传入如果实在需要动态表名也要建一个白名单机制只允许预先定义好的表名其他一概拒绝。ETL 任务虽然是内部系统但你的数据资产就是公司的核心资产这一块的安全意识必须到位。5.2 慢 SQL 优化与性能调优技巧慢 SQL 优化是我在上面已经详细讲过的内容但这里我还是想再强调一个核心思路ETL 任务里的慢 SQL 优化和在线业务系统的慢 SQL 优化目标是不一样的。在线业务追求的是单条查询的响应速度而 ETL 追求的是吞吐量和稳定性。所以 ETL SQL 优化时重点不是减少单条 SQL 的运行时间而是让整个任务链路在有限资源下稳定、可预期地完成。实际操作中我会用两个指标来衡量 ETL 任务是否健康一是任务运行时长二是任务消耗的资源量。如果一个任务从 30 分钟降到 15 分钟但资源消耗翻了一倍对整体调度链路来说不一定是优化反而可能拖慢其他任务。在资源有限的情况下让每个任务尽量使用稳定的资源跑完比追求单个任务最快更重要。这也是为什么我会在调度配置里给每个 ETL 任务设置资源上限和超时时间避免某个任务异常消耗资源导致整个集群雪崩。5.3 ETL 脚本里的日期与时间函数使用在 ETL 脚本里日期时间处理是最容易出错也最需要统一的地方。我遇到过的问题五花八门有日期格式不统一导致分区错乱、有时区问题导致数据差 8 个小时、有把字符串当日期比较导致结果完全错误。后来我们定了一套团队规范这里也分享给大家。第一数仓内所有时间字段统一存储为yyyy-MM-dd HH:mm:ss格式所有分区字段统一使用yyyy-MM-dd。第二涉及业务时间的过滤统一用当天 00:00:00 到第二天 00:00:00 的左闭右开区间避免 BETWEEN 这种左右都闭合的写法漏数据或重复计数据。第三在 SQL 里对日期做加减时不同数据库的写法不一样MySQL 用 DATE_ADD、DATE_SUBSQL Server 用 DATEADD迁移脚本时一定要改对我见过好几次因为 DATEADD 参数顺序写反导致算错日期的低级错误。提示在做跨数据库的 ETL 脚本迁移时时间函数几乎必改。建议提前整理一张常用时间函数的对照表团队共享能省掉很多低级错误。6. 写在最后的一些心得这个数据仓库 ETL 项目做下来我最大的感受是不要迷信工具也不要低估 SQL 的能力。对于大多数中小规模的数据场景SQL 配合一个可靠的调度平台完全能撑起一条稳定的 ETL 数据链路。重点在于设计好分层、控制好每个环节的幂等性和可追溯性并且在日常开发中持续积累排查问题的经验。要说还有什么让我特别受益的习惯那就是在每个 ETL 任务开发完成后我一定会手动模拟一次失败和重跑验证任务的幂等性。很多脏数据问题其实都是重跑造成的如果从一开始就养成这个习惯后面会省掉大量和业务方对数的精力。另外就是调度时间的错峰设计这个看起来不起眼但做到了能明显降低整个集群的压力让所有任务跑得更稳定。如果你正在准备开始自己的数据仓库 ETL 项目我建议别急着上大而全的框架先把分层和 SQL 逻辑理清楚跑通一条链路再说。我踩过的这些坑你大概率也会遇到希望这篇文章能帮你提前绕开。
