📚 课程目录第1章流批一体概述

1. 流批一体概述：概念、为什么需要、架构对比

大家好，我是老张。做数据质量这行十几年了，今天咱们聊聊流批一体。

说实话，我第一次听到「流批一体」这个词，是在2019年的一次技术大会上。当时台下很多人跟我一样，第一反应是：这不就是Lambda架构换个马甲吗？后来踩了不少坑，才明白——嗯，还真不是一回事。

流批一体，说白了就是一套代码、一套引擎、一套元数据，同时搞定实时流处理和离线批处理。

传统做法是两套系统：

两套代码，两套运维，两套口径。你想想看，光是对齐指标定义就能让人崩溃。

流批一体的核心思想是：流就是批的无限版本，批就是流的有界快照。同一份数据，同一套逻辑，既可以在离线场景下全量重跑，也可以在实时场景下增量计算。

核心要点：流批一体不是简单的「流+批」拼凑，而是从计算引擎、存储格式、元数据管理到数据质量检测，全链路统一。

我在项目中遇到过最典型的一个场景：某电商大促期间，实时大屏显示 GMV 是 10 亿，第二天离线报表出来却是 9.2 亿。差了 8000 万！业务方直接炸了。

排查下来原因很简单：实时和离线用了两套 ETL 逻辑，对「有效订单」的定义不一致。实时为了性能砍掉了一些复杂过滤，离线则严格按照业务口径来。

这就是典型的「数据口径二义性」问题。流批一体要解决的就是这类痛点：

我的建议：如果你的团队还在用两套引擎维护同一套指标，而且每个月至少因为口径不一致出一次故障——别犹豫，流批一体是你绕不开的路。

聊架构对比之前，我先画一张图，帮大家理清这三者的关系。

上面这张图基本把三者的骨架画清楚了。下面我展开聊聊每个架构的优缺点，以及我个人的实战体会。

这是最「古老」也最「成熟」的方案。批处理层负责全量计算，流处理层负责增量计算，最后通过合并服务层把两路结果拼起来。

我曾经在一个金融项目里用过 Lambda 架构。批处理用 Hive，流处理用 Flink，合并层用自研的 Merge Service。结果呢？每次上线都要对齐两套代码的语义，光 UDF 行为不一致就修了三个月。

避坑指南：我曾经见过一个团队，Lambda 架构跑了两年，批流口径差异累计超过 200 个。最后不得不花一个季度做数据回溯——代价太大了。如果你选 Lambda，一定要在合并层做严格的数据质量校验。

Kappa 架构的思路很纯粹：所有数据都走流处理，批处理通过「重放历史数据」来实现。这样只用维护一套流引擎。

听起来很美，对吧？但我在实践中发现几个问题：

说白了，Kappa 更适合数据量可控、历史回溯频率低的场景。如果你每天要跑全量重算，Kappa 会让你很痛苦。

流批一体不是简单的架构选型，而是计算范式的升级。以 Flink 为例，它从 1.12 开始正式支持流批一体：同一套 Table API/SQL，Batch 模式和 Streaming 模式可以无缝切换。

我去年主导的一个数据质量平台，就是用 Flink 流批一体做的。核心收益有三点：

关键认知：流批一体不是银弹。如果你的业务场景实时性要求不高（分钟级即可），或者历史数据量极大（PB 级），Lambda 架构可能更务实。选型要看场景，不要追概念。

回到咱们课程的主题——质量检测体系。流批一体对数据质量意味着什么？

举个例子。我之前做实时数仓质量检测，每天凌晨要跑一个批流比对任务，把昨天的实时聚合结果和离线结果做差值分析。如果差异超过阈值就告警。这个任务本身就要维护一套复杂的比对逻辑。

用了流批一体之后，这个问题自然消失了——因为实时和离线用的是同一套聚合逻辑，结果不可能不一致。你想想看，这省了多少事？

个人经验：我建议刚开始接触流批一体的团队，先从「质量检测」这个场景切入。因为质量检测对实时性要求没那么苛刻（秒级延迟可以接受），但对口径一致性要求极高——这正是流批一体的强项。

这一章我们聊了流批一体的核心概念、为什么需要它，以及它与 Lambda、Kappa 架构的对比。说白了，流批一体不是要取代谁，而是在特定场景下提供更优的解法。

记住三个关键点：