2、金融数据湖总体架构设计：分层架构与技术选型
聊到金融数据湖，我第一个想说的就是分层。很多团队一上来就搞数据湖，结果数据往里一丢，变成了数据沼泽。嗯，这里要注意，分层不是花架子，它是整个数据体系的骨架。
2.1 为什么金融数据湖必须分层？
说白了，金融数据太敏感了。一笔交易从产生到最终报表，中间经过多少道加工？你想想看，如果所有数据都混在一起，出了问题你根本查不到源头。
我个人习惯把数据湖分成四层：ODS、DWD、DWS、ADS。每一层都有明确的职责，就像工厂里的流水线，每个工位只干一件事。
核心原则：每一层只做一件事，层与层之间通过标准接口交互。这样出了问题，你只需要查一层，而不是翻遍整个湖。
2.2 分层架构详解
ODS层（操作数据存储）
这一层是数据的入口。所有源系统的数据，原封不动地搬到这里。我在项目中遇到过，有些团队在ODS层就开始做清洗，结果源系统一改格式，整个下游全崩了。
- 数据格式：保持源系统原始格式
- 存储周期：通常保留7-30天
- 典型场景：交易流水、客户信息、风控日志
DWD层（明细数据层）
这一层开始做正经事了。数据清洗、去重、格式统一。我记得有一次做反洗钱项目，DWD层花了整整两周做数据标准化，因为不同渠道的客户姓名格式完全不一样。
- 数据格式：统一为Parquet/ORC列式存储
- 存储周期：按业务需求，通常3-6个月
- 典型场景：标准化后的交易明细、客户画像
DWS层（汇总数据层）
宽表、汇总、轻度聚合。这一层是给分析师和报表系统用的。你想想看，如果每次跑一个月度报表都要扫描几亿条明细，那得等到什么时候？
- 数据格式：宽表结构，预聚合
- 存储周期：按业务需求，通常1-2年
- 典型场景：客户月度交易汇总、产品日销售统计
ADS层（应用数据服务层）
这一层直接面向业务应用。数据已经高度定制化，可能是某个风控模型的输入，也可能是某个实时大屏的数据源。
- 数据格式：按应用需求定制
- 存储周期：按应用需求
- 典型场景：实时风控特征、个性化推荐数据
2.3 技术选型：我的实战经验
技术选型这块，我踩过不少坑。先说结论：没有银弹，只有最适合你场景的。
| 技术组件 | 适用场景 | 我的建议 |
|---|---|---|
| Hadoop HDFS | 海量数据存储，批处理 | 金融数据湖的基石，别想着绕开它 |
| Apache Spark | 大规模批处理，ETL | DWD/DWS层的首选，性能稳定 |
| Apache Flink | 实时流处理，低延迟 | ADS层实时场景，比如风控 |
| Delta Lake | 数据湖ACID事务，版本管理 | 强烈推荐，解决数据一致性问题 |
避坑指南：我曾经在一个项目中，为了追求"新技术"，用Flink做所有事情。结果批处理性能还不如Spark的一半。后来老老实实把批处理切回Spark，实时部分保留Flink，性能直接翻倍。
2.4 数据流向设计
数据怎么流？这个问题看似简单，但做不好就是灾难。我见过一个项目，数据从ODS到DWD走了三条不同的链路，结果对账永远对不平。
我的做法是：单向流动，分层加工。数据只能从上一层流到下一层，不允许跨层访问。这样出了问题，你只需要查一层。
警告：千万不要让业务系统直接访问ODS层！我曾经见过一个团队，为了"快速响应"，让报表系统直接读ODS。结果源系统一变更，报表全乱了，花了整整一周才排查出来。
2.5 核心架构图
下面这张图是我做金融数据湖项目时常用的架构。它清晰地展示了数据从采集到应用的完整路径。
2.6 数据流向的实战要点
数据流向设计，说白了就是回答三个问题：数据从哪里来？经过哪些加工？最终到哪里去？
- 采集阶段：用Flink CDC实时捕获数据库变更，或者用Sqoop/DataX做批量同步。我个人习惯，核心交易数据用CDC，历史数据用批量。
- 加工阶段：ODS到DWD用Spark做ETL，DWD到DWS用Spark SQL做聚合。实时场景下，Flink直接从ODS消费，加工后写入ADS。
- 服务阶段：ADS层的数据通过API或者消息队列对外提供服务。我曾经见过一个项目，让分析师直接查DWS层，结果一个复杂查询把整个集群拖垮了。
我的经验：数据流向设计时，一定要考虑数据回滚。金融数据不允许出错，一旦发现数据有问题，要能快速回滚到上一个版本。Delta Lake的版本管理功能在这里帮了大忙。
2.7 避坑指南：我踩过的三个坑
做金融数据湖这几年，我踩过的坑不少。挑三个最典型的说说：
- 坑一：ODS层数据保留太短。我曾经有个项目，ODS只保留7天，结果第8天发现数据有问题，想回溯都来不及。后来我建议至少保留30天。
- 坑二：DWD层数据标准化做得不够。不同系统对"客户姓名"的定义不一样，有的用"姓名"，有的用"客户名称"。如果不统一，下游分析全是坑。
- 坑三：ADS层直接暴露给业务系统。业务系统频繁查询，导致ADS层性能下降，反过来影响数据加工。后来加了缓存层，问题才解决。
好了，以上就是金融数据湖分层架构的核心内容。记住，分层不是目的，目的是让数据可管、可控、可追溯。下一章我们会聊到具体的数据建模方法，到时候再细说。