〇、先认识一下这些专业名词后文不再解释文章后面会频繁提到这些技术先统一认识一下后文就不啰嗦了名词一句话解释Flink流式计算引擎实时数仓的核心数据像流水一样进来Flink边接边算Kafka高吞吐量消息队列实时数仓里当数据管道用上下游通过它传数据PaimonApache开源的数据湖存储格式以前叫Flink Table Store支持实时Upsert和增量读取替代Kafka做中间存储Doris国产开源OLAP引擎MPP架构SQL兼容好实时导入能力强StarRocks国产开源OLAP引擎查询性能极强支持湖仓一体Doris的竞品ClickHouse俄罗斯开源的列式OLAP引擎单表查询速度极快适合日志和时序数据OLAP联机分析处理高并发秒级查询引擎Doris/StarRocks/ClickHouse都属于OLAPHBase分布式列式数据库NoSQL适合大表高并发随机读Redis内存键值数据库查询速度极快但容量受内存限制HDFSHadoop分布式文件系统大数据的底层存储CDCChange Data Capture变更数据捕获监听数据库binlog获取变更binlogMySQL的二进制日志记录了数据库所有的增删改操作Iceberg另一种开源数据湖表格式Netflix开源Hudi另一种开源数据湖表格式Uber开源和Paimon/Iceberg是同类竞品Spark大数据批处理引擎离线计算的标配也支持流处理一、先唠唠实时数仓和离线数仓到底差在哪咱先把底子打牢。离线数仓说白了就是T1批量处理——今天凌晨跑昨天的数据Hive里一顿SQL产出报表给业务看。稳是稳但延迟高你今天中午想看上午的销量门儿没有等明天吧。实时数仓不一样它主打一个**“数据刚到就能看见”。业务库插了一条订单几秒之后大屏上数字就跳了。这靠啥靠的是流式计算**——数据像水一样源源不断地流进来计算引擎主要就是Flink在一边接水一边处理而不是等水都接满了再处理。但这里有个误区要纠正很多人以为实时数仓就是把Hive换成Flink那可太天真了。实时数仓是一套完全不同的玩法从数据采集、存储、计算到服务每个环节都跟离线不一样。维度离线数仓实时数仓处理模式批量处理Batch流式处理Stream时效性T1小时级秒级~分钟级核心引擎Hive、SparkFlink、Kafka Streams存储介质HDFS、Hive表Kafka、OLAPDoris/StarRocks/ClickHouse、数据湖数据量全量历史数据增量实时数据适用场景财务报表、离线分析实时大屏、风控、推荐二、分层建模理论实时数仓和离线数仓一样吗先说结论分层概念一样但建模方法论完全不同。2.1 离线数仓的维度建模离线数仓严格遵循维度建模理论这是数据仓库领域的经典方法论核心是两条第一事实表和维度表严格分离。事实表Fact Table存业务过程的度量值比如订单金额、商品数量。特点是数据量大、列少、每行代表一个业务事件。维度表Dimension Table存描述性信息比如用户姓名、商品名称、地区名称。特点是数据量小、列多、相对稳定。第二通过join关联查询。查询时从事实表出发join多个维度表获取描述信息经典模型有星型模型事实表周围一圈维度表和雪花模型维度表进一步规范化拆分离线数仓这么做没问题——Hive擅长大表join而且查询是分钟级延迟join几次无所谓。2.2 实时数仓的宽表模型实时数仓等不了join来一条数据就要毫秒级出结果哪有时间去join三四张表所以实时数仓走的是宽表模型路线。核心思想就一句话以空间换时间把维度字段提前打平到事实表中。实时数仓的DWD层会直接产出这样一张宽表订单实时宽表 (DWD) ├─ order_id (订单ID) ├─ user_id (用户ID) ├─ user_name (用户姓名) ← 从用户维度表查来 ├─ product_id (商品ID) ├─ product_name (商品名称) ← 从商品维度表查来 ├─ category (品类) ← 从商品维度表查来 ├─ province (省份) ← 从地区维度表查来 ├─ order_amount (订单金额) ├─ event_time (下单时间)维度信息直接作为列存在宽表里了查询时根本不需要join-- 直接查宽表零joinSELECTSUM(order_amount)FROMdwd_order_wideWHEREprovince广东ANDcategory手机;2.3 两者核心区别维度离线数仓维度建模实时数仓宽表模型核心理念事实表维度表严格分离维度字段打平到事实表查询方式多表join单表查询零join存储成本低维度表复用高大量字段冗余查询延迟分钟级大表join慢亚秒级单表扫描快数据一致性维度表更新后查询自动生效宽表中维度字段需要重新回填通俗解释离线数仓像图书馆——书事实表和目录卡片维度表分开存放查的时候先翻目录再找书规范但慢。实时数仓像你的书桌——常用的书和参考资料全摊在桌面上拿起来就能看占地方但快。三、实时数仓的四种架构形态完整流程图 优缺点实时数仓从诞生到现在经历了四代架构演进。下面我把每一代的流程图、优缺点、为什么被淘汰或为什么还在用讲清楚。3.1 第一代Lambda架构2015-2019—— 新项目基本不用思想仍有价值设计思路MySQL数据同时走两条独立链路——离线Hive每天凌晨全量计算结果存Hive表准确但延迟高实时Flink/Kafka实时增量计算结果存HBase快但可能不全。服务层查询时同时查Hive和HBase合并返回。优点离线实时各管各的互不影响离线结果准实时结果快两者互补缺点❌ 两套代码Hive SQL Flink SQL改个逻辑两边一起改❌ 两套基础设施Hive集群 Flink集群运维成本高到飞起❌ 同一批数据存两份存储浪费❌ 离线结果和实时结果经常对不上业务问起来头大现状作为一种架构模式Lambda在主流互联网公司的新实时数仓项目中基本不用了。但它的核心思想——离线兜底实时互补——在金融交易对账等对准确性要求极高的场景中仍以双链路校验的形式存在。3.2 第二代Kappa架构2019-2023—— 理念影响深远纯Kappa已不多见设计思路Jay KrepsKafka作者提出干掉批处理层全部用Flink流处理搞定。MySQL数据全部进KafkaKafka长期保留全量历史数据Flink统一消费处理结果写入Doris/StarRocks供查询。需要重算时从Kafka最早的offset重新消费。优点必须有严格的前提条件数据无异常且代码一致✅ 一套代码一套系统开发和运维成本大幅降低✅ 逻辑统一不会出现离线和实时对不上的尴尬缺点❌ Kafka要保存全量历史数据存储成本极高Kafka设计为短期消息队列不适合长期存储❌ Flink重算全量历史数据性能比Spark差很多❌ Kafka里的数据不可查、不可订正、不好更新现状Kappa架构的理念“统一用流处理”深刻影响了后续架构但纯Kappa在生产中已不多见。它推动了第三代Kafka实时数仓和第四代湖仓一体的出现。3.3 第三代经典Kafka实时数仓2019-2024—— 当前生产环境使用最广泛的架构核心特点每一层Flink处理完都写回Kafka下一层Flink从Kafka消费。Kafka既是数据管道也是中间存储。每层Flink Job具体干啥ODS层Kafka TopicFlink CDC实时读取MySQL的binlog把insert/update/delete变成JSON写到Kafka数据举例{op:insert,order_id:1001,user_id:500,amount:199.0}这一层基本不做处理原样写入Flink Job #1ODS → DWD消费ODS数据清洗过滤关联维表去HBase/Redis查用户姓名、商品名称打宽处理完的宽表数据写到Kafka DWD TopicFlink Job #2DWD → DWS消费DWD宽表按5分钟/10分钟窗口做汇总聚合结果写到Kafka DWS TopicFlink Job #3DWS → ADS消费DWS汇总数据做最终加工写入Doris/StarRocks供查询优点✅ 简单直接生态成熟FlinkKafkaDoris这套组合用了5年✅ 大量生产验证文档和社区资源丰富✅ 小公司/新项目几天就能跑通缺点三大痛点❌ Kafka数据不可查——出问题只能写Flink任务消费看排查成本极高❌ Kafka数据不可订正——写错了只能重跑整个Flink Job从最早offset重新消费❌消费组互相影响——下游消费组多了Kafka集群I/O压力暴增容易卡顿当前地位重点2024年这套架构仍然是生产环境使用最广泛的实时数仓方案。原因就一个字——简单。FlinkKafkaDoris的组合生态最成熟资料最多出问题能搜到解决方案。对于大部分公司来说这套架构完全够用不需要折腾更复杂的方案。3.4 第四代湖仓一体实时数仓2023-至今—— 增长最快的趋势核心变化用Paimon表替代Kafka Topic作为中间存储。其他不变——Flink还是做实时计算Doris/StarRocks还是做查询服务。每层干啥Paimon ODS层Flink CDC实时采集MySQL变更写入Paimon表。和Kafka的区别数据可SQL直接查SELECT * FROM ods_table出了问题直接排查。Paimon DWD层Flink读取ODS表做清洗、关联维表、打宽。同一个业务过程的多张源表通过Partial Update按ID合并成一张宽表。Paimon DWS层Flink对DWD宽表做窗口聚合结果写入Paimon DWS表。OLAP层Flink将DWS汇总结果微批写入Doris/StarRocksStream Load5~10秒一个批次供业务秒级查询。优点✅ Paimon数据可SQL查询 → 出问题直接SELECT排查✅ Paimon支持Upsert → 写错了秒级订正✅ 同一张表Flink写Spark读 → 流批一体✅ HDFS存储 → 成本是Kafka的1/10✅ Partial Update拼宽表 → 比Flink Join稳定10倍缺点❌ Paimon生态还在快速发展部分高级功能文档不够完善❌ 运维复杂度略高于Kafka方案需要管理Paimon集群当前地位重点湖仓一体是2024-2025年增长最快的架构趋势阿里/字节/滴滴等大厂正在大规模迁移。但它不是来替代Kafka架构的——对于新公司和小项目Kafka架构仍然是最简单直接的选择。湖仓一体更适合中大型系统或已有Kafka架构遇到痛点的场景。3.5 四种架构对比总表维度Lambda已淘汰Kappa纯Kappa已不多见Kafka实时数仓当前主流湖仓一体增长最快中间存储Hive表 KafkaKafka长期存全量Kafka TopicPaimon表代码维护两套代码一套Flink代码一套Flink代码一套Flink代码数据排查离线可查实时不可查不可查不可查最大痛点可SQL直接查✅数据订正重跑全量重跑Flink Job几小时重跑Flink Job几小时秒级Upsert✅流批复用数据分开存Kafka离线读不了Kafka离线读不了同一张表流批✅存储成本数据存两份Kafka长期存储高Kafka保留7天就得删HDFS存储成本低✅生态成熟度成熟但复杂一般最成熟✅快速发展中上手难度高中低✅中适用场景金融对账数据量适中的流式场景新公司/新项目首选中大型系统/架构升级当前地位❌ 已淘汰理念影响深远2024生产最广泛增长最快趋势关键结论不矛盾Kafka实时数仓 当前生产环境使用最广泛的架构简单、成熟、资料多湖仓一体 增长最快的趋势架构解决Kafka痛点大厂正在迁移两者不是替代关系而是共存关系——小公司用Kafka架构够用中大型系统向湖仓一体演进四、一个关键问题Flink写入OLAP是逐条还是批量下游查询会不会锁表这是很多人包括我刚入行的时候的疑问。既然实时数仓要实时那Flink是不是每来一条数据就写一次Doris如果下游正在查询写入会不会锁表导致查询卡顿4.1 Flink写入OLAP是微批写入不是逐条Flink写入Doris/StarRocks采用的是Stream Load微批写入机制不是逐条insertFlink内部有一条数据流 数据1 → 数据2 → 数据3 → 数据4 → 数据5 → 数据6 → 数据7 → 数据8 │ │ └──────── 积攒5秒或积攒1000条 ────────────┘ │ ▼ ┌───────────────┐ │ 打一个Batch │ │ 通过HTTP发送 │ │ Stream Load │ └───────┬───────┘ ▼ Doris/StarRocksStream Load的工作方式Flink Connector内部有一个缓冲区数据来了先攒在缓冲区里触发条件满足其一积攒了5~10秒或积攒了1000~5000条或Flink做Checkpoint满足条件后将这批数据打包成一个HTTP请求通过Stream Load接口一次性写入Doris每个Batch是一个独立事务要么全部成功要么全部失败为什么不用逐条写入逐条insert网络开销太大吞吐量低得可怜逐条写入会导致Doris产生大量小版本查询性能急剧下降微批写入吞吐量可以达到每秒几十万条完全满足实时需求4.2 下游查询会锁表吗不会MVCC机制保证读写互不阻塞这是最关键的问题。答案是不会锁表写入和查询互不阻塞。Doris/StarRocks采用MVCC多版本并发控制机制Doris内部的数据版本管理 时间轴 ────t1────t2────t3────t4────t5────t6────t7──── │ │ │ │ │ │ 版本V1 [查询可见] │ │ │ 写入Batch1 └──────┘ │ 版本V2 [查询可见] │ │ 写入Batch2 └──────┘ 版本V3 [查询可见]原理每次Stream Load写入会产生一个新版本Version查询请求到达时Doris会锁定当前最新版本查询过程中看到的是这个版本的快照新的Batch写入产生新版本但正在进行的查询不受影响继续读旧版本写入完成后新的查询会自动切换到最新版本通俗比喻MVCC就像Git的版本管理。你在读代码的时候查询同事可以提交新代码写入你的代码视图不会受影响。你想看最新代码就pull一下新查询自动读最新版本。总结问题答案Flink写入是逐条还是批量微批写入Stream Load5~10秒一个批次写入时下游查询会锁表吗不会MVCC保证读写互不阻塞写入后多久能查到亚秒级Stream Load完成后立即可查写入吞吐量多大每秒几十万条取决于Batch大小和Doris集群规模五、维度表怎么处理Redis是不是落伍了实时数仓最大的坑不是计算是维度关联。Flink流里的数据只有ID需要毫秒级查到维度信息补全这个环节处理不好整个链路就崩了。5.1 三种维表方案按数据量选型方案一Broadcast Join——小维表的神器适用维表数据量在几千到几万条之间状态码映射、品类列表、配置参数。原理Flink启动时把整张维表加载到内存广播给每个TaskManager。来数据直接在本地内存查零外部网络开销。✅ 速度最快纯内存操作微秒级延迟❌ 维表大小受限于TaskManager内存❌ 维表更新需要重启Flink Job方案二Lookup Join——中等维表的通用方案适用维表数据量在几十万到几百万条之间用户信息、商品信息、门店信息。原理每来一条数据Flink实时去外部存储查一次维度信息。外部存储怎么选存储适用场景查询延迟Redis读多写少、QPS极高亚毫秒HBase数据量大、列族查询5~20msMySQL已有业务库、 QPS低5~50ms✅ 通用性强维表更新实时生效❌ 大流量下外部存储压力大❌ 外部存储挂了Flink Job会阻塞方案三Paimon维表——大维表的新方案适用维表数据量在千万到亿级之间用户全量画像、商品SKU全量表。原理维表存在Paimon数据湖中Flink通过Lookup Join查询。按bucket分区查只加载对应分区的数据。✅ 分布式抗大表重启时间从分钟级降到秒级✅ 流式更新维表变更实时生效❌ 需要部署Paimon集群5.2 Redis到底落伍了吗结论Redis没有落伍但要分场景。维表几十万条、QPS几千Redis Lookup Join依然是最简单直接的方案维表上亿条、QPS几十万Paimon维表更合适维表是配置类小表Broadcast Join连Redis都不用2024-2025年的趋势是分层选型小表Broadcast、中表Redis/HBase、大表Paimon。不是谁替代谁而是各尽其用。六、实时数仓用在哪些场景场景技术方案延迟要求实时数据大屏Flink → Doris/StarRocks → 大屏秒级实时风控Flink CEP → Redis → 风控引擎毫秒级实时推荐Flink → Redis/HBase特征库 → 推荐模型百毫秒级实时监控告警Flink聚合 → 规则引擎 → 钉钉秒级实时BI分析Flink → Doris → Superset/帆软秒级七、经典案例7.1 案例一滴滴顺风车——Kafka实时数仓架构业务背景顺风车需要实时看订单量、司机在线数、乘客等待时长。架构MySQL → Canal → Kafka(ODS) → Flink → Kafka(DWD) → Flink → Kafka(DWS) ↓ ClickHouse/Redis → 实时大屏设计要点实时4层ODS/DWD/DWS/ADS比离线少一层中间层降低延迟ODS和DWD存在Kafka里Kafka作为流式存储层维表单独存HBaseFlink通过异步IO查询汇总层容忍延迟跨天统计故意等5秒再触发保证数据到齐7.2 案例二携程商旅——湖仓一体架构业务背景覆盖机票/酒店/用车订单链条长、数据分散在近十张表。架构MySQL → Flink CDC → Paimon(ODS) → Flink → Paimon(DWD宽表) → Flink → Paimon(DWS) ↓ 业务查询/API设计决策Paimon替代Kafka——数据可SQL查调试成本低Partial Update拼宽表——多路流按订单ID自动合并批流一体——同一张Paimon表Flink实时写Spark离线读Tag机制——给Paimon表打快照Spark基于增量计算收益数据采集5小时→1.5小时延迟从小时级降到分钟级。八、选型建议你的情况推荐方案理由小公司/刚起步Flink Kafka Doris简单够用生态最成熟资料最多中等规模/有多样化需求Flink Paimon Doris湖仓一体流批一套存储排查问题方便大厂/数据量极大Flink Paimon StarRocksStarRocks性能更猛存算分离扩展性好已有Kafka实时数仓逐步迁移到Paimon先替换一层验证再逐步推广几点忠告实时数仓不是银弹业务对延迟不敏感就用离线数仓运维成本差一个数量级。层数别太多实时每多一层就多一份延迟和故障点3~4层足够了。维表是最大坑选型时按数据量分三层Broadcast/Redis/Paimon别一刀切。先跑通再优化先用FlinkKafkaDoris跑通一个实时大屏看到效果再逐步演进。九、总结实时数仓这档子事说到底就是六句话分层概念和离线一样ODS→DWD→DWS→ADS但建模方法论不同——离线用维度建模事实表维度表分离join查询实时用宽表模型维度打平以空间换时间零join。架构经历了四代演进Lambda已淘汰→ Kappa理念影响深远纯Kappa已不多见→ Kafka实时数仓当前生产最广泛→ 湖仓一体增长最快趋势。Kafka架构和湖仓一体不矛盾——Kafka架构简单成熟是当前生产使用最多的方案湖仓一体解决Kafka的痛点是大厂架构升级的方向。小公司选Kafka中大型系统向湖仓一体演进。Flink写入OLAP是微批写入Stream Load5~10秒一个批次不是逐条。OLAP采用MVCC机制读写互不阻塞不会锁表。维度表分三种方案——小表Broadcast Join、中表Redis/HBase Lookup Join、大表Paimon Lookup Join。Redis没有落伍按数据量选型各尽其用。不是每个业务都需要实时数仓但对实时大屏、风控、推荐这些场景来说它是基础设施。最后如果你正在规划实时数仓希望这篇文章能帮你理清思路。有问题欢迎在评论区交流咱们一起探讨。如果觉得有帮助点个赞再走呗~