从数据湖到数据仓库：云计算如何重塑大数据存储架构
近期趋势：湖仓一体加速落地
过去两年，数据湖与数据仓库的边界在云计算推动下快速模糊。云服务商陆续推出统一存储与计算框架，支持同一份数据同时运行批处理、流处理与交互式查询。开源社区中，Apache Iceberg、Delta Lake、Hudi 等表格式逐步成为云原生数据平台的标配。部分企业开始将原有Hadoop集群迁移至对象存储，并通过SQL引擎直接查询湖中数据，减少数据搬运环节。这轮趋势的核心变化是从“ETL入仓”转向“ELT在湖上完成”，即先存储原始数据，再按需定义结构。
行业背景：传统架构遭遇规模与成本瓶颈
传统数据仓库依赖本地磁盘阵列与专用硬件，扩展时需要停机或替换节点，且预留资源容易造成浪费。数据湖虽解决了存储弹性问题，但早期缺乏事务支持和一致性的索引，导致“数据沼泽”和查询性能不稳定。产业集群内不同部门常各自维护独立的数据管道，造成重复存储与口径不一的计算结果。云计算的按需付费、对象存储的无限扩展能力，以及计算与存储分离的架构，恰好提供了改写存储规则的基础：用户可将冷热数据分级存放，用低成本对象存储承载原始日志，用高性能SSD实例承载频繁访问的聚合结果。
用户关注点：治理、性能与迁移成本
- 数据治理一致性：湖仓一体是否真正做到了ACID事务？哪些场景下仍需要独立数据仓库？用户关心跨引擎的元数据统一（如字段血缘、权限继承），避免多元管理增加复杂度。
- 查询性能平衡：直接查询对象存储中的Parquet/ORC文件，延迟通常高于传统数仓。用户关注内置缓存、物化视图、分区裁剪等优化手段的成熟度。
- 迁移路径平坦度：从自建或商用数仓迁移至云原生架构，涉及数据格式转换、ETL作业改写、安全策略重配。用户希望了解分阶段迁移的方法（如先迁移冷数据，后迁移热表），以及工具链是否兼容已有SQL方言。
- 成本可见性：云存储看似便宜，但数据扫描费、API调用次数、计算启动时间都可能隐藏额外支出。用户需要经验范围参考——例如小型分析负载半年后存储费占比约20%-35%，计算费占比则随并发波动。
可能影响：数据团队角色与技术选型变化
数据工程师不再需要专职维护集群的物理硬件，但转向掌握分布式文件系统原理、云权限模型及成本优化策略。数据架构师在选型时面临更多选项：全托管云数仓、开源Lakehouse、混合模式（近实时入仓+历史数据保留在湖）。影响还体现在供应商格局上：传统MPP数据库面临云原生后发产品的直接竞争；同时，对象存储厂商通过提供原生数据目录和SQL接口，逐渐从“底层设施”进化为“数据平台”。部分中小型企业提前放弃自建，直接采用云上湖仓服务，从而缩短从数据治理到分析建模的周期。
后续观察：AI 工作负载与实时分析融合
未来几个月，预计以下方向会加速落地：
- AI 友好存储：数据湖将直接存储特征向量、模型权重与训练日志，减少数据从存储到训练集群的复制次数。
- 实时湖仓：流式写入与增量计算一体化，使分钟级延迟的报表与原始数据处于同一存储层，减少Lambda架构中的两条分离管道。
- 跨云数据编排：多云或混合云场景下，元数据目录和联邦查询能力会成为用户新的评估标准，而非单纯比较单一云的存储价格。
- 安全与合规增强：数据分类分级、动态脱敏、审计日志在湖仓体系中原生支持的程度，将直接影响金融、医疗等行业的采用意愿。
总结要点：
• 云计算推动数据湖与数据仓库走向融合，核心变化是“先存后算”及计算存储分离。
• 用户需在治理、性能、迁移成本之间权衡；经验表明成本中的计算占比随查询模式波动较大。
• 架构变化使数据团队角色转向云运维与成本优化，供应商竞争加剧。
• 后续关注AI工作负载实时化与跨云场景下的元数据统一能力。