很多人学数据架构，容易陷入一个误区：
把架构演进理解成“新技术淘汰旧技术”。
传统数仓之后有 Lambda，Lambda 之后有 Kappa，再后来又出现湖仓一体、Data Mesh，于是很容易得出一个结论：
越新的架构越先进。
但真正做过企业数据项目就会发现，架构选型从来不是版本升级。
一家每天做一次财务结算的企业，没有必要把所有链路都改造成实时流计算；一家每秒产生大量订单和设备事件的平台，也很难继续依靠每天凌晨跑一次 ETL。
所以判断一种数据架构，真正应该问的不是：
“现在最流行什么？”
而是：
数据从哪里来？多久要到？怎样加工？谁负责？最终给谁使用？
下面就从实际架构设计的角度，把目前最常见的5种数据架构一次拆清楚。
传统数仓最经典的一条链路，大多数人都见过：
表面上看，它只是把数据一层层加工。
但传统数仓真正解决的问题其实是：
企业到底应该相信哪一份数据？
例如销售系统里有订单金额，ERP里有出库金额，财务系统里又有确认收入。
这三个数字可能都没错，因为它们分别描述的是不同业务阶段。
问题在于，如果没有统一的数据模型：
-
销售部门可能按照订单金额统计收入；
-
供应链按照出库金额统计；
-
财务按照会计确认规则统计。
最后到了经营会上，同一个“销售收入”可能出现三套数字。
所以数仓分层真正做的，是把企业业务事实逐渐沉淀下来。
-
ODS 尽量保留源系统原始数据；
-
DWD 统一订单、客户、商品、组织等基础业务对象；
-
DWS 沉淀公共指标和统计逻辑；
-
ADS 再服务于经营、财务、供应链等具体分析场景。
可以把它理解成：
越接近底层，越强调事实稳定；越接近上层，越强调业务应用。
这也是为什么传统数仓发展了这么多年，今天仍然大量存在。
不过真正让数仓项目变复杂的，往往不是建几张宽表，而是前面的数据接入。
一家中大型企业可能同时存在 ERP、CRM、MES、WMS、财务系统、数据库、API、文件等几十种数据来源。
如果每条链路都靠脚本单独维护，数据源一变、字段一改、任务时间一调整，就要不断修改代码。
所以很多项目会把数据接入和任务调度单独抽成平台能力。
例如使用 FineDataLink 5.0 承接不同业务系统的数据同步，把全量初始化、后续增量同步、清洗转换以及上下游任务依赖统一组织起来。这样做数仓分层时，架构师关注的重点才能真正回到：
数据应该怎样建模、哪些逻辑应该沉淀到公共层，而不是每天处理“这张表今天为什么没同步过来”。
传统数仓的问题也很明确：
它天然更擅长确定时间窗口内的批量计算。
如果企业只要求每天早上看到昨天的数据，这套架构非常稳定。
但当业务开始要求：
-
订单发生以后几秒钟就要看到；
-
设备异常一分钟内必须告警；
-
险交易不能等到第二天再判断。
数据问题就从“批量处理”变成了“持续处理”。
Lambda 架构出现的背景，本质上是一个矛盾：
批处理算得准，但慢；实时处理来得快，但复杂。
于是 Lambda 选择了一个看起来有些“奢侈”的方案：
两套都保留。
同一份业务数据，同时进入两条链路。
第一条是批处理链路。
它保存完整历史数据，周期性重新计算，追求最终结果的完整和准确。
第二条是实时链路。
它只处理最近产生的数据，让业务能够尽快看到最新变化。
最终查询的时候，再把：
历史批处理结果 + 最新实时结果组合起来。
例如金融风控。
一笔交易刚发生时，系统必须在几秒钟内判断有没有异常。
这显然不能等晚上跑批。
于是实时链路先快速给出结果。
但到了第二天，企业可能还要利用完整交易记录重新计算风险指标，对上一天结果做统一校准。
所以 Lambda 真正解决的是：
既要“现在能看到”，又要“最后算得准”。
但它最大的代价也非常明显：
同一套业务逻辑可能需要维护两遍。
假设“高风险客户”的规则从：
过去30天异常交易超过3次
改成：
过去30天异常交易超过3次，并且累计金额超过10万元。
-
那么批处理逻辑需要修改；
-
实时计算逻辑也需要同步修改；
-
两边还必须保证完全一致。
否则就可能出现：
实时看板显示100个高风险客户；
第二天离线重算却只有93个。
这就是 Lambda 最容易被低估的成本：
不是服务器成本，而是双链路带来的开发、测试和口径维护成本。
因此真正选 Lambda 时，不能只问：
“业务要不要实时？”
还应该继续问：
是否既需要实时结果，又必须保留一套独立的完整重算能力？
如果答案不是肯定的，两套链路带来的复杂度可能反而超过收益。
Kappa 可以理解为对 Lambda 的一次简化。
既然流计算能力越来越成熟，那么能不能不再维护两套业务逻辑？
Kappa 的答案是：
可以。
它把数据统一理解为一系列持续发生的事件。
-
订单创建是一条事件；
-
订单支付是一条事件；
-
退款是一条事件；
-
库存从100变成98，也是一次事件。
这些事件不断进入消息系统，再由流处理引擎持续处理，最终更新业务结果。
所以典型链路会更接近：
业务事件 → 消息系统 → 流处理 → 实时存储/分析系统。
但很多人理解 Kappa 时，只记住两个字：
实时。
实际上，Kappa 真正的关键能力是：
Replay——重放。
假设昨天的 GMV 计算规则写错了。
传统批处理很好解决：
把昨天数据重新读一遍，再算一次。
实时系统怎么办？
如果历史事件还完整保存在消息系统中，就可以从过去某个时间点重新消费这些事件，用新的规则重新生成结果。
所以 Kappa 能不能真正成立，关键要看四件事：
-
事件有没有完整保存；
-
顺序是否可靠；
-
重复事件怎样保证幂等；
-
历史数据能不能重新消费。
这也是为什么实时架构从来不是装一个 Kafka、再加一个 Flink 就结束了。
例如数据库里的订单、库存、客户状态发生变化时，实时架构首先要解决的，其实是：
怎样把这些变化持续、稳定地捕获下来。
如果每个业务系统都单独开发一套实时采集程序，随着数据源增加，后面的连接维护、异常恢复和字段变更都会越来越重。
实际项目里，通常会把这部分能力集中起来管理。
像 FineDataLink 5.0，可以利用 CDC 获取数据库中的增量变化，也可以接入 Kafka、MQTT 等实时数据，再根据业务需要完成字段处理、转换和下游分发。
但链路接通只是第一步。
真正进入生产以后，更值得关注的是：
数据有没有积压、任务中断后从哪里继续、重复数据怎么处理、异常数据怎么隔离、上下游数量能不能对得上。
因为实时系统最危险的情况往往不是任务直接报错。
而是：
任务看起来一直在运行，但数据已经悄悄少了一部分。
所以成熟的实时架构，最终看的不是“实时任务数量”，而是：
延迟、完整性、一致性、可恢复性和可观测性。
传统数仓在结构化数据时代很好用。
但随着企业数据类型越来越复杂，新问题开始出现。
日志、JSON、图片、IoT数据、模型训练数据不断增加。
这些数据如果全部按照传统数仓方式：
先设计Schema，再建表，再加工入库，
成本会越来越高。
于是企业开始建设数据湖。
数据湖的核心思路是：
先把数据存下来，再决定未来怎么使用。
-
结构化数据可以放；
-
半结构化数据可以放；
-
非结构化数据也可以放。
这解决了“什么数据都能存”的问题，但很快又产生了另外一类问题：
-
数据越来越多，却不知道哪些能用；
-
一份数据出现多个版本；
-
Schema变化没人管理；
-
数据质量也很难保证。
最终 Data Lake 很容易变成：
Data Swamp——数据沼泽。
湖仓一体真正想做的，就是同时获得两类能力：
一方面保留数据湖开放、低成本、能够承载多类型数据的特点；
另一方面补上数据仓库的：
事务能力、元数据管理、Schema管理、数据质量和分析能力。
于是 BI、数据科学、机器学习、实时分析，可以尽可能围绕同一套数据底座工作。
但湖仓项目还有一个非常现实的问题：
底层架构统一了，上游数据入口却未必统一。
例如底层已经建设统一湖仓，上游却仍然是：
-
ERP团队写一套同步脚本；
-
MES团队写一套接口；
-
CRM又自己维护一套ETL。
最终只是把过去的数据烟囱，搬到了湖仓入口。
所以湖仓建设前面通常还需要一个稳定的数据汇聚层。
在这类项目里，FineDataLink 5.0 更适合放在“数据怎么进入湖仓”这一层理解：不同业务系统的数据先统一接入，根据业务特点决定采用周期同步还是实时同步，再进行必要的清洗和转换后送到下游。
这样架构设计的问题就会从：
“这个系统怎么接？”
逐渐转向更重要的：
-
哪些数据需要全量初始化？
-
哪些字段只做增量变化？
-
哪些数据必须实时进入？
-
数据异常以后怎么补？
而真正成熟的湖仓一体，还必须继续解决：
小文件、分区、元数据、数据质量、权限、血缘、冷热数据以及计算成本。
否则只是换了一个更大的地方堆数据。
Data Mesh 和前面几种架构最大的不同，是它首先不是讨论：
数据存在数据库还是对象存储；
使用批计算还是流计算。
它首先讨论的是：
企业的数据到底应该由谁负责？
传统企业常见的模式是建立一个中央数据团队。
-
销售要指标，找数据团队；
-
供应链要建表，找数据团队；
-
财务要改口径，还是找数据团队。
企业规模小时，这种模式没有太大问题。
但随着业务越来越复杂，中央数据团队会逐渐变成巨大的排队中心。
更麻烦的是：
真正理解业务的人，没有数据建设责任；
真正建设数据的人，又未必真正理解业务。
Data Mesh 因此提出一个核心思想：
Domain Ownership——领域负责。
-
交易域负责订单；
-
供应链域负责库存；
-
客户域负责客户；
-
财务域负责收入、成本和资金。
而且每个业务域不只是把数据库表暴露出来，而是要把重要数据建设成：
Data Product——数据产品。
一份真正可以被其他团队长期使用的数据产品，至少应该明确：
-
数据代表什么；
-
指标口径是什么；
-
多久更新；
-
质量标准是什么；
-
谁负责；
-
发生异常找谁。
但 Data Mesh 并不是：
每个部门自己建设一套数据平台。
如果财务一套平台、销售一套平台、供应链再建一套平台，最后只是重新制造数据孤岛。
所以 Data Mesh 还需要一个公共的平台能力层。
数据接入、任务开发、调度、权限、监控等共性能力可以统一建设，各个业务域再负责自己领域的数据逻辑和数据质量。
如果企业已经把 FineDataLink 5.0 作为统一的数据集成与任务运行平台，也可以从这个角度理解它的位置：
公共平台负责提供连接、同步和任务运行能力，业务域则围绕自己负责的数据建设具体链路。
这样一来，需要集中的是技术能力；
需要下放的是数据责任。
也就是：
平台集中，责任分散。
这才真正接近 Data Mesh 想解决的问题。
所以 Data Mesh 最难落地的，往往不是技术。
而是企业能不能真正回答：
一份数据出了质量问题，到底谁负责？
如果所有问题最后仍然只能说：
“找数据部。”
那么再漂亮的 Data Mesh 架构图也没有太大意义。
理解完前面五种架构，会发现它们并不是简单的升级关系。
真正做选型时，可以重点看五个维度。
1.看数据时效
如果小时级、T+1已经能满足经营分析，传统数仓通常足够。
如果订单、风控、设备等场景要求秒级响应，就需要考虑实时架构。
2.看数据类型
主要处理结构化经营数据，数仓依然非常成熟。
如果日志、IoT、文件、AI训练数据越来越多，湖仓的价值会逐渐提升。
3.看重算需求
既要求实时，又必须保留独立批处理进行完整校正，可以考虑 Lambda。
如果业务天然事件化，并且历史事件具备完整重放能力，可以进一步考虑 Kappa。
4.看组织规模
Data Mesh 往往不是因为数据量太大才出现。
更常见的原因是：
业务域越来越多，中央数据团队已经无法理解并交付所有数据需求。
5.看复杂度是否值得
这是架构选型最容易被忽视的一点。
实时系统、湖仓平台、流处理、领域自治都会带来：
-
更多组件；
-
更多运维；
-
更多人才要求；
-
更高治理成本。
所以架构师最终一定要算一笔账：
为了把数据延迟从1小时降低到1分钟，业务到底获得了什么？
如果只是让大屏刷新得更快，却没有任何经营动作因此发生改变，那么这套技术复杂度就值得重新评估。
真正成熟的数据架构，往往从来不是五选一。
一家大型企业完全可能同时存在：
-
底层采用湖仓一体；
-
订单和设备数据使用 Kappa 做实时处理；
-
财务和经营分析继续采用传统数仓分层；
-
少数关键业务保留 Lambda 的批流双链路；
-
组织层面再逐渐按照 Data Mesh 划分数据责任。
因为架构最终服务的不是技术统一，而是业务问题。
真正的数据架构师，也不是背熟五张标准架构图。
而是在面对一个业务需求时，能够继续追问：
-
数据从哪里产生？
-
允许多大延迟？
-
结果错了能不能重算？
-
任务失败以后怎么恢复？
-
谁对这份数据负责？
-
为了满足这些要求，企业愿意付出多少成本和复杂度？
能回答这些问题以后，你会发现：
架构图只是最终结果，架构取舍才是数据架构师真正的价值。
