2. 数据架构演进主线
数据架构的演进并不是一条“新技术替代旧技术”的直线，而是业务压力、数据规模、时效要求和组织复杂度共同作用的结果。理解这条主线，关键是看清每个阶段解决了什么痛点、付出了什么代价、在什么边界内才值得落地。下面按五个阶段梳理，并在最后给出可对照的选型判断。
一、单体数据库：事务为王，分析是副业
最早的业务系统把数据放在一个关系型数据库里，应用直接读写，报表也直接查同一套表。它的优势是强一致、事务可靠、开发简单。典型形态是 MySQL、PostgreSQL、Oracle 承载订单、用户、库存等 OLTP 业务，报表通过从库或夜间批量查询完成。
痛点出现在数据量和查询复杂度上升之后：分析型 SQL 会扫描大量行、做多表关联和聚合，直接冲击在线事务的锁与 IO；从库虽然能分担读，但复杂查询仍会拖慢复制延迟。此时常见的取舍是“读写分离 + 定时抽取”，把分析负载挪到独立库。落地边界很明确：数据量在百万级、分析时效要求为 T+1、且业务表结构相对稳定时，单体数据库加只读副本仍然是最省成本的方案。一旦出现跨系统关联、历史快照、指标口径统一等需求，就该进入下一阶段。
二、数据仓库：面向主题、集成、不可更新
数据仓库的核心思想是把分散在各业务库的数据抽取、清洗、转换后，按主题（如交易、用户、商品）重新组织，形成面向分析的统一视图。经典分层是 ODS（贴源）、DWD（明细）、DWS（汇总）、ADS（应用）。它解决了口径不一致和跨系统关联问题，代价是数据延迟高、模型变更慢。
生产落地时，ETL 调度是命脉。以每日 T+1 为例，凌晨 1:00 启动抽取，ODS 落分区，DWD 做去重与维度补全，DWS 按天/品类聚合，ADS 产出报表。若上游某张表延迟，整条链路顺延，业务早上看不到数据。因此需要设置依赖告警、断点重跑和分区补数机制。数据仓库适合稳定、批量、强口径的分析场景，但不适合秒级风控和实时推荐。
三、Lambda 与 Kappa：批流两条路线的取舍
当业务要求“实时看数”时，Lambda 架构出现了：批处理层负责全量准确结果，速度层负责增量近似结果，服务层合并两者。它的优点是兼顾准确与时效，缺点是同一套逻辑要写两遍（批和流），两套代码容易口径漂移，运维复杂度高。
Kappa 架构则主张“一切皆流”：只保留流处理一条链路，历史数据通过重放消息日志来重算。它简化了代码路径，但对消息中间件的留存能力、流处理状态管理和重放成本要求很高。实际生产中，很多团队采用折中方案：核心实时指标走流，复杂历史回溯走批，但通过统一的指标定义和同一份 SQL/DSL 尽量收敛逻辑。
下面这张图对比了五个阶段的核心结构、数据流向与主要边界，便于快速定位当前系统所处位置。
四、湖仓一体：一份存储，多种计算
湖仓一体的目标是把数据湖的开放、低成本存储与数据仓库的事务、Schema 管理能力合并。底层用对象存储（如 S3、OSS）存放 Parquet/ORC 列式文件，上层通过表格式（Iceberg、Hudi、Delta Lake）提供 ACID、快照、时间旅行和增量读。这样批处理、流处理、交互式查询可以共享同一份数据，减少搬运和冗余。
生产落地要重点处理三件事：一是小文件问题，流式写入会不断产生小文件，需要定期 compaction 合并；二是元数据服务压力，表越多、分区越细，元数据查询越容易成为瓶颈，需要合理设置分区粒度和清理过期快照；三是引擎兼容性，不同计算引擎对表格式的支持程度不同，选型时要确认读写语义一致。湖仓一体适合已经具备一定平台能力、希望降低存储冗余和批流割裂的团队。
五、数据网格：从集中平台到领域自治
数据网格不是单纯的技术栈，而是一种组织与架构范式：把数据视为产品，由最了解业务的领域团队负责生产、维护和发布，通过统一的标准（发现、契约、SLA、权限）实现跨域消费。它解决的是“集中式数据团队成为瓶颈”的组织问题，而不是单纯的性能问题。
落地数据网格的前提是平台能力已经成熟：有统一的数据目录、血缘、质量监控、权限体系和自助式发布工具。否则领域团队各自为政，反而会加剧口径分裂。因此，数据网格更适合多业务域、数据消费者众多、集中团队长期排队的大型组织。
六、如何判断当前该落在哪一阶段
选型时不要追求“最新”，而要看三个约束：数据规模与增长斜率、时效要求的硬下限、组织协同成本。若数据量在千万行以内、分析 T+1 可接受，单体库加只读副本往往最经济；若跨系统口径混乱、报表需求稳定，数据仓库分层是稳妥选择；若业务要求秒级指标且消息可重放，优先考虑 Kappa；若已有湖存储但缺乏事务和 Schema 管理，湖仓一体是自然升级；若瓶颈在组织而非技术，再考虑数据网格。
最后提醒一点：每个阶段都有其“生产落地边界”。越过边界强行使用，往往不是技术不行，而是成本、组织或运维能力不匹配。把边界写清楚，比把技术栈堆满更重要。