大数据系统如何选择 OLTP、OLAP 与湖仓

大数据架构最常见的问题不是存储空间不够，而是把不同访问模式的数据塞进同一个系统。交易写入、明细查询、聚合分析和离线归档需要不同的引擎。

四类数据访问

访问模式	典型请求	合适存储
OLTP	按主键读写订单	MySQL、PostgreSQL
OLAP	按时间和维度聚合	ClickHouse、Doris
实时流	秒级窗口指标	Kafka、Flink
低频归档	原始明细、历史快照	对象存储、数据湖

交易库追求事务和低延迟点查，分析库追求扫描和聚合吞吐。让分析 SQL 直接扫生产库，通常会与线上写入抢 CPU、IO 和锁。

湖仓的价值

数据湖把原始数据以低成本放到对象存储，湖仓再提供表格式、事务、快照和 Schema 管理。它适合保留完整历史，支持批流一体和多引擎读取。

湖仓并不意味着放弃数仓。面向报表的稳定指标仍需要清晰的维度模型和数据契约，不能让每个分析师都直接解释原始 JSON。

一条可维护的链路

业务库/日志 -> CDC/消息 -> 原始层
                         -> 清洗层 -> 明细层
                                    -> 汇总层 -> BI/API
                         -> 对象存储归档

每个节点都要记录数据时间、处理时间、来源、版本和质量状态。失败任务不能用空表覆盖成功数据，应该保留批次号并支持重跑。

选型时写清楚数字

在选引擎前记录数据量、每日增量、峰值写入、查询并发、P95 延迟、保留周期、更新方式和成本预算。没有这些数字时，所谓“更快”无法验证。

避免重复存储

原始层保留不可变数据，明细层保存标准化结果，汇总层只保留高频指标。冷热数据分层后，查询路由按时间范围和业务用途选择存储。相同数据在多个系统复制时，要明确谁是事实源，谁只是索引或缓存。

好的大数据架构是访问模式的地图，而不是产品名称的清单。先定义数据生命周期，再决定引擎和集群规模。