3. 湖仓一体基础
在金融行业的数据架构演进中，数据湖、数据仓库与湖仓一体并非简单的名词更替，而是对“数据存哪里、怎么算、给谁用、如何治理”这四个根本问题的不同回答。理解三者的核心差异与演进逻辑，是后续搭建端到端平台的前提。
一、核心概念：三种范式的本质区别
数据仓库（Data Warehouse）的核心是“先建模、后入库”。数据在写入前必须经过ETL清洗、转换，并按星型或雪花模型组织成事实表与维度表。它提供强Schema约束、ACID事务和高度优化的SQL查询能力，适合BI报表与监管报送。代价是：非结构化数据难以进入，Schema变更成本高，历史明细常被聚合而丢失。
数据湖（Data Lake）的核心是“先存储、后定义”。原始数据以文件形式落入对象存储（如S3、HDFS、OSS），支持Parquet、ORC、JSON、CSV乃至图片、日志等任意格式。它解决了海量、多源、低成本的存储问题，但缺乏事务、Schema约束和高效索引，容易退化为“数据沼泽”。
湖仓一体（Lakehouse）的核心是“在数据湖上实现仓库级能力”。它通过开放表格式（Iceberg、Hudi、Delta Lake）在对象存储之上叠加事务、Schema演进、时间旅行、快照隔离等能力，使同一份数据既能被Spark、Flink等引擎做批流处理，又能被Trino、StarRocks等做交互式SQL分析，从而减少数据搬运与冗余副本。
二、演进历程：从分离到融合
第一阶段是仓库主导期：以Teradata、Oracle、Greenplum为代表，数据经过严格ETL后进入仓库，支撑报表与决策。第二阶段是湖仓分离期：Hadoop生态兴起后，原始数据先入湖，再抽取到仓库，形成“湖+仓”双栈，带来链路长、口径不一致、存储冗余等问题。第三阶段是湖仓一体期：以Iceberg、Hudi、Delta Lake为代表的开放表格式，在对象存储上直接提供表级事务与元数据管理，配合Spark、Flink、Trino等引擎，实现“一份数据、多种计算”。
关键判断：湖仓一体不是把仓库搬到湖上，而是让湖具备仓库的“可信”属性——事务、Schema、权限、血缘、快照。缺少这些，湖仍然只是存储池。
三、技术选型：金融场景的评估清单
金融行业选型需同时考虑监管合规、数据一致性、实时性与生态成熟度。以下清单可作为评估框架：
| 评估维度 | 数据仓库 | 数据湖 | 湖仓一体 |
|---|---|---|---|
| 事务与一致性 | 强ACID | 弱，依赖文件覆盖 | 表级ACID + 快照隔离 |
| Schema管理 | 写时约束，变更慢 | 读时解析，易失控 | Schema演进 + 版本回溯 |
| 数据类型 | 结构化为主 | 全类型 | 全类型 + 结构化治理 |
| 实时能力 | 微批/准实时 | 流式写入但难查询 | 批流一体，分钟级可见 |
| 金融适用性 | 监管报送、核心报表 | 日志、风控特征、AI样本 | 统一底座，兼顾合规与创新 |
四、金融适用性与常见误区
在银行、证券、保险场景中，湖仓一体的价值集中在三处：一是反洗钱与风控特征工程，需要同时访问交易明细、日志与外部数据；二是监管报送，要求数据可追溯、可审计、口径统一；三是实时营销与客户画像，要求批流数据在同一张表上完成关联。
误区一：认为“建了湖仓一体就不需要仓库”。实际上，面向高并发BI的集市层仍可用MPP数据库承载，湖仓一体更多承担统一存储与批流加工。
误区二：只引入Iceberg/Hudi却未建设元数据与权限体系，导致表数量膨胀、血缘断裂。
误区三：忽视小文件问题。金融高频写入场景下，需配置定时compaction与快照过期策略。
# 以Iceberg为例，金融场景常用维护参数
write.target-file-size-bytes=134217728 # 128MB，控制小文件
write.metadata.delete-after-commit.enabled=true
history.expire.max-snapshot-age-ms=604800000 # 快照保留7天
commit.retry.num-retries=4 # 冲突重试，保障并发写入复盘建议：选型时先明确“谁在什么时效下、用什么引擎、查哪类数据”，再反推表格式与计算引擎。金融项目优先验证ACID、时间旅行、权限对接与审计日志四项能力，而非只看查询性能跑分。