一、项目背景与架构设计：实时数仓的“第一块砖”
大家好，我是这次课程的主讲。在正式开始之前，我想先聊聊一个很现实的问题：为什么我们要搞实时数仓？
我见过太多团队，离线数仓跑得好好的，每天凌晨出报表，业务方也习惯了。但突然有一天，运营说“我要看今天的实时GMV”，老板说“我要监控大屏的秒级波动”。这时候你才发现，离线那一套根本扛不住。嗯，这就是我们做这个项目的初衷。
1.1 实时数仓到底是什么？
说白了，实时数仓就是让数据从产生到可分析的时间窗口，从“天级”压缩到“秒级”或“分钟级”。它不是要取代离线数仓，而是补上“快”这块短板。
我个人的理解是：离线数仓解决“全”的问题，实时数仓解决“快”的问题。两者配合，才能让数据真正驱动业务决策。
核心目标：数据延迟从 T+1 降到秒级，同时保证数据的一致性和可回溯性。
1.2 项目业务背景：我们选电商还是金融？
这次课程，我选的是电商场景。为什么？
- 业务链路完整：从用户浏览、加购、下单、支付到物流，每个环节都有实时需求。
- 数据特征典型：高并发、大流量、多维度，非常适合展示实时数仓的威力。
- 避坑价值高：我在电商项目中踩过不少坑，比如双11大促时的数据洪峰、订单状态乱序等问题，这些经验我会毫无保留地分享。
当然，金融场景我也会穿插讲解。比如实时风控、交易监控等，核心思路是相通的。
1.3 技术选型：为什么是 Flink + Kafka + ClickHouse + Hudi？
这个问题，我每次被问到都会反问一句：你想想看，实时数仓最需要解决哪几个问题？
- 数据实时采集与传输——需要高吞吐、低延迟的消息队列。
- 实时计算与处理——需要支持 Exactly-Once、状态管理、事件时间语义的引擎。
- 实时存储与查询——需要支持高并发、低延迟的 OLAP 查询。
- 数据湖底座——需要支持 ACID、增量读取、数据回溯的存储层。
基于这四点，我选型如下：
| 组件 | 选型理由 | 我在项目中的体会 |
|---|---|---|
| Flink | 业界最成熟的流计算引擎，支持事件时间、状态后端、Checkpoint | 曾经用 Flink 处理过每秒 10 万+的点击流，状态管理稳如老狗 |
| Kafka | 高吞吐、可持久化、支持多消费者，是实时数仓的“数据总线” | 分区数设置不合理会导致数据倾斜，这个坑我后面会细讲 |
| ClickHouse | 列式存储、向量化执行、单表查询极快，适合实时 OLAP | 注意它的 MergeTree 引擎特性，写入合并策略调优很关键 |
| Hudi | 支持 ACID、增量查询、时间旅行，是实时数仓的“数据湖底座” | 我曾在 Hudi 上做过近实时入湖，解决了离线表与实时表的数据一致性问题 |
小提示：技术选型没有银弹。这套组合适合大多数中大型实时场景，但如果你只是小规模试用，也可以考虑简化方案，比如用 Pulsar 替代 Kafka，或用 Doris 替代 ClickHouse。
1.4 整体架构图设计
下面这张图，是我在多个项目中沉淀下来的实时数仓架构。它分为五层：数据接入层、实时计算层、实时存储层、数据服务层和数据湖底座。
这张图看起来简单，但每一层都有不少细节。我挑几个重点说说：
- 数据接入层：Kafka 是核心。我建议把不同业务的数据分到不同的 Topic，方便后续扩展。曾经有个项目把所有数据塞到一个 Topic，结果消费端压力巨大，分区数调整也很麻烦。
- 实时计算层：Flink 的 Checkpoint 间隔设置很关键。太短影响性能，太长恢复时间久。我一般设 30 秒到 1 分钟，具体看业务容忍度。
- 实时存储层：ClickHouse 适合做聚合查询，但不适合做点查。如果你需要频繁的 KV 查询，记得在前面加一层 Redis。
- 数据湖底座：Hudi 的 Copy-on-Write 和 Merge-on-Read 两种表类型，我后面会专门讲怎么选。简单说，写多读少用 MOR，读多写少用 COW。
避坑指南：我曾经在一个项目中，把 ClickHouse 当作唯一的存储层，结果业务方要求修改历史数据时，发现 ClickHouse 的更新代价极高。后来加了 Hudi 做数据湖底座，才解决了数据回溯和修正的问题。所以，实时数仓一定要有“湖”的概念，不能只靠 OLAP 引擎。
1.5 本章小结
这一章我们聊了实时数仓的概念、电商业务背景、技术选型思路，以及整体架构设计。说白了，就是给整个项目搭好了骨架。
接下来的章节，我们会一步步把每一层都落地实现。从环境搭建、数据接入，到 Flink 实时计算、ClickHouse 建模，再到 Hudi 数据湖集成，最后上线运维。每一章我都会结合真实项目中的经验和教训来讲。
嗯，准备好了吗？我们开始吧。