1. OLAP 调度系统概述：什么是 OLAP、为什么需要调度系统、调度系统的核心价值与挑战
大家好，我是这次课程的主讲。在正式开始搭建之前，我觉得有必要先聊聊「我们到底在做什么」。
很多刚接触数据工程的同学，容易把 OLAP 和 OLTP 搞混。也有些人觉得调度不就是 crontab 吗？嗯，真没那么简单。我见过不少团队，前期图省事用 Linux 定时任务跑 SQL，结果数据对不上、任务卡死、没人知道谁该负责——最后全变成了「人工调度」。
所以这一章，我们先打好地基。
1.1 什么是 OLAP？
OLAP，全称是 Online Analytical Processing，中文叫「联机分析处理」。说白了，它就是用来做复杂查询和数据分析的那套东西。
你想想看，一个电商平台每天产生几千万条订单。运营想看「过去 30 天每个品类的销售额趋势」，或者「按省份、按年龄段、按支付方式交叉分析」。这种查询，单条 SQL 可能要扫描几十亿行数据。OLAP 就是专门干这个的。
我习惯用一个对比来帮团队理解：
| 维度 | OLTP（联机事务处理） | OLAP（联机分析处理） |
|---|---|---|
| 典型场景 | 下单、支付、修改用户信息 | 月报、趋势分析、多维钻取 |
| 数据量级 | 单次操作影响几十行 | 单次查询扫描百万到亿级行 |
| 响应要求 | 毫秒级，实时 | 秒级到分钟级，可接受延迟 |
| 数据模型 | 高度规范化（3NF） | 星型/雪花型，宽表为主 |
| 典型引擎 | MySQL, PostgreSQL, Oracle | ClickHouse, Doris, StarRocks, Druid |
我在项目中遇到过最典型的翻车案例：有人把 ClickHouse 当 MySQL 用，频繁做单行更新。结果呢？MergeTree 合并压力巨大，查询越来越慢。OLAP 引擎的设计哲学就是「一次写入，多次读取」，别拿它当 OLTP 使。
1.2 为什么需要调度系统？
好，现在你有了 OLAP 引擎，数据也导进去了。然后呢？
一个真实的数仓，通常有几十到几百个 ETL 任务。比如：
- 凌晨 2 点同步 MySQL binlog 到 Kafka
- 凌晨 3 点从 Kafka 写入 ODS 层
- 凌晨 4 点做 DWD 层的清洗和维度关联
- 凌晨 5 点跑 DWS 层的汇总宽表
- 早上 6 点把数据写入 OLAP 引擎的物化视图
这些任务之间有严格的上下游依赖。DWS 必须在 DWD 完成后才能跑。如果某个任务失败了，下游不能盲目启动，否则数据就是错的。
我曾经见过一个团队，用 Shell 脚本 + crontab 硬扛了两年。一开始只有 20 个任务，还行。后来涨到 200 个，每天凌晨都有人盯着屏幕，手动重跑失败的任务。有一次某个上游表结构变更，下游全挂了，整整三天没出报表。老板拍桌子，DBA 背锅。
所以，调度系统不是「锦上添花」，而是刚需。它要解决的核心问题就三个：
- 什么时候跑 —— 时间触发还是数据触发？
- 按什么顺序跑 —— 依赖关系怎么保证？
- 跑失败了怎么办 —— 重试、告警、补偿机制？
一句话总结：调度系统就是给数据任务装上「交通信号灯」和「交警」。没有它，早晚出事故。
1.3 调度系统的核心价值
聊完痛点，我们看看调度系统到底能带来什么好处。我把它归纳为四点：
1.3.1 自动化与可靠性
任务按 DAG（有向无环图）自动执行。失败了自动重试，重试还失败就发告警。人只需要处理异常，不用盯着屏幕。
1.3.2 可观测性
每个任务的执行时间、输入输出行数、资源消耗、日志，全都有记录。出了问题，能快速定位是哪个环节挂了。
1.3.3 资源管控
OLAP 查询很吃资源。调度系统可以控制并发数，避免凌晨 ETL 和白天报表查询抢 CPU。我见过一个客户，没做资源隔离，ETL 跑的时候直接把 BI 系统拖垮了。
1.3.4 数据一致性保障
通过事务机制或幂等设计，保证即使任务重跑，数据也不会重复或丢失。这一点在金融场景尤其重要。
一个小建议：选调度系统时，别只看功能多不多。先看它能不能跟你的 OLAP 引擎深度集成。比如是否支持 SQL 任务的原生提交、是否能把查询计划暴露出来。这些细节，后期用起来差别很大。
1.4 面临的挑战
调度系统不是银弹。我自己踩过不少坑，挑几个典型的说说：
- 任务雪崩：某个上游任务延迟了 10 分钟，下游几百个任务同时积压，资源瞬间打满。我曾经遇到过 ClickHouse 连接池被撑爆，整个集群响应超时。
- 数据漂移：上游表结构悄悄加了字段，下游的 INSERT 语句没适配，任务直接报错。调度系统检测不到这种「逻辑错误」，只能靠数据质量监控。
- 调度延迟：调度器本身也是服务。如果调度器挂了，所有任务都停摆。高可用设计是必须的。
- 依赖地狱：任务数量上千后，依赖关系变得极其复杂。改一个任务的依赖，可能影响几十个下游。没有可视化 DAG，根本理不清。
注意：调度系统只能保证「任务按顺序执行」，不能保证「数据是正确的」。数据质量需要额外的校验层。别把调度系统当成数据质量的兜底方案。
1.5 知识体系总览
下面这张图，是我对 OLAP 调度系统核心模块的拆解。后面的课程，基本就围绕这几个模块展开。
从图上你能看到，调度引擎是大脑，DAG 管理负责编排，执行引擎负责干活，监控告警负责兜底。底层还有元数据、日志、数据质量这些基础设施。每一块我都会在后面的章节里手把手带大家实现。