实时数据处理，90%的人只关心快慢。而这4种架构的取舍，才是关键

说到实时数据处理，不少人的第一反应就是：

找个最快的工具，把数据流接起来。实时嘛，不就是越快越好？

我以前也这么想。

但实际做项目就会发现，光追求快，后面麻烦不少：

• 数据不准了怎么办？
• 历史数据和实时结果对不上怎么办？
• 需求一变，重新计算会不会特别麻烦？

所以说，实时不只是个技术活，更是个架构设计题。它关乎速度，更关乎准、稳和能不能长期维护。

今天，我就结合自己的项目经验，聊聊几种常见的架构思路，实际要怎么选，怎么用。

开始前，先给大家分享一份整理好的数仓建设方案资料，里面把数仓的分层架构、建设路径和工具选型讲得挺明白。需要自取：https://s.fanruan.com/entf5

一、Lambda架构

“我们要能够实时看大盘数据，但最后出来的数字，必须一分不差，能实现吗？”

这种业务要求其实挺难的。几年前，技术工具没那么厉害。流计算工具跑得快，但容易出错，也不方便重算历史。批处理工具，像Spark，算得准、稳当，但特别慢。

那怎么办？

当时的办法是：既然一套系统搞不定，那就上两套。这就是Lambda架构的核心。

具体是这样的：

• 批处理层：用Spark这种，慢慢算全量数据，保证结果绝对正确。速度慢点没关系，关键是稳。
• 速度层：用Storm或者早期的Flink，快速处理最新的数据，先出一个大概的结果。
• 服务层：把这两层的结果合到一起，给业务用。先用快的、大概的结果；等慢的、准确的结果算好了，再替换上去。

这办法很实在。它承认了当时的工具做不到又快又准，所以干脆用两套东西来干。一个求准，一个求快。

Lambda架构的缺点

但这办法有个大问题：开发和维护成本太高了。

• 同样的计算逻辑，你要写两遍代码，用两种不同的工具；
• 你要维护两个不同的系统。
• 时间长了，两边逻辑可能还对不上。

所以，当流处理技术本身越来越强大后，大家就开始想：有没有更省事的办法？

二、Kappa架构

于是，Kappa架构被提了出来。它的想法很简单：别分什么批处理和流处理了，所有数据都当成流来处理。

具体怎么做？

你需要一个能存很久数据的消息队列，比如Kafka。所有数据，包括老的新的，都放里面。

当你要做全量计算时，就从这条“流”最早的地方开始读，重新处理一遍。虽然慢，但只用了一套逻辑。平时处理实时数据，就从最新的地方接着读。

这么做，最大的好处是什么？

就是省事：一套代码，一个框架，全搞定。

你写一个Flink任务，它既能算实时的，也能通过调个参数，去重算历史数据。没有两套代码对不上的烦恼了。

但是，这个办法对工具要求很高

你用的流计算引擎，必须非常可靠。

1. 它要能准确地记住计算中间的状态；
2. 保证数据哪怕出错重来，也只算一次；
3. 它失败了要能完美地恢复回来。

几年前，这样的工具不多，这办法用的人少。

但现在，Flink这类工具已经很成熟了，完全能做得到。所以现在很多新项目，在面对实时需求时，会优先考虑Kappa架构。

三、流批一体

Kappa 架构虽然只用了一套工具，但对开发的人来讲，写流处理的代码，和写批处理的思路，还是不一样，学起来还是有成本。

这就引出了下一个演进方向：流批一体。它比Kappa更近一步。

Kappa是用一套流引擎来处理两种场景。而流批一体，让开发者在写代码时，就感觉不到流和批的区别。

具体怎么实现？

核心在于统一的编程接口。

你把一段SQL交给Flink，它会自己去判断数据源是实时的流，还是已经存在硬盘上的文件，然后在底层用最合适的方式去执行。

好处是什么？

这对我们开发的人来说，就太方便了。不用学两套东西，用最熟悉的 SQL 就能干很多活。开发速度能快很多。

这个方向现在越来越流行了。你去看招聘，很多都要求会Flink SQL，这就是趋势。

四、湖仓一体

上面说的，都是怎么算数据。但算出来的结果，还有要用的原始数据，你放哪儿呢？

以前的做法很分散。实时结果可能放Redis，最终报表放数据仓库。数据搬来搬去，很麻烦，也容易出错。

现在大家常说的“湖仓一体”，就是想解决这个存储的问题。它希望用一个地方，存所有类型的数据。既能存原始的细节数据，也能存实时算出来的结果。

对于实时处理来说，这意味着什么？

这意味着，你的实时任务（比如Flink），算出的结果可以直接存到这个湖里。存进去之后，立刻就能被查询，也能很方便地和历史数据放在一起分析。数据不用来回拷贝了，真正实现了一份存储，多种计算。

实现湖仓一体，第一步往往是把各处的数据稳定、高效地汇集到这个统一的湖里。这也是个体力活和技术活。我自己的经验是，用对工具能事半功倍。

像我一直用的FineDataLink这个数据集成工具，就支持从各种数据库、接口、文件把数据实时或定时地同步到数据湖（比如HDFS、S3）或数据仓库中，并且能处理复杂的转换和监控，确保数据源的供给是稳定、准确的。工具链接我放在这里，可以试用看看：https://s.fanruan.com/810gr

所以，当你在设计实时架构时，眼光不能只放在计算引擎上。底层存储是不是够开放、够统一，决定了你上层建筑的稳固性和灵活性。

五、那该怎么选呢？

聊了这么多，我们来简单总结一下。这几种方法，其实是不同阶段、不同情况下的选择。

• 如果你的系统已经很老了，特别强调不能出一点错，那么现有的Lambda架构可能依然是最稳的，不要为了追新而盲目重构。
• 如果你要新做一个实时系统，特别是处理日志、监控这些，那直接用一套强大的流处理工具（比如 Flink）来做，是新项目的首选。简单，好维护。
• 如果你想提高整个团队的开发效率，让更多人能参与进来，那就多看看流批一体的工具，特别是 SQL。
• 无论选择哪种计算架构，都强烈建议你认真评估一下湖仓一体的存储方案。用一个统一的、靠谱的地方存所有数据，能帮你省掉未来很多麻烦。

说到底，选哪种方法，得看你的具体需求：业务能等多快？团队会用什么？之前有什么系统？把这些想明白，选起来就不难了。

希望今天的分享，能帮你看清楚里面的门道。少走点我们当年走过的弯路。

#数据##IT那些事#