1. 金融数据仓库概述

大家好，我是老张。在金融数据这个领域摸爬滚打了十几年，今天咱们来聊聊数据仓库的入门话题。说实话，金融行业的数据处理，跟电商、社交那些完全不是一个量级。我刚开始接触时，也被各种奇葩需求折腾得够呛。

1.1 金融行业数据特点

金融数据有什么特别的？我总结了几点，你看看是不是这么回事：

• 数据量大——每天几亿笔交易，光日志就能撑爆硬盘
• 实时性要求高——股票行情延迟一秒，可能就是几百万的损失
• 准确性要求变态——一分钱都不能差，差了对不上账就麻烦了
• 合规性要求严格——监管机构随时可能来查，数据得能追溯
• 数据来源复杂——核心系统、风控系统、CRM、外部数据源……五花八门

嗯，这里要注意一点。金融数据还有个特点——时序性极强。每一笔交易都有精确的时间戳，而且顺序不能乱。我在项目中遇到过，因为时间戳精度不够，导致交易流水对不上，排查了整整三天。

1.2 数据仓库核心概念

数据仓库这个概念，说白了就是把分散的数据集中起来，统一管理、统一分析。我习惯把它比作一个大型图书馆——原始数据是散落的书籍，数据仓库就是那个有索引、有分类、方便查阅的图书馆。

金融数据仓库有几个核心概念，我挑重要的说：

1.2.1 主题域

主题域就是按业务划分的数据分类。比如客户主题、交易主题、产品主题、风险主题。每个主题域下，再细分不同的数据模型。我个人习惯先画业务流程图，再确定主题域，这样不容易漏掉关键数据。

1.2.2 数据分层

金融数据仓库一般分四层：

层级	名称	说明
ODS	操作数据存储	原始数据，基本不做加工
DWD	明细数据层	清洗、去重、标准化后的数据
DWS	汇总数据层	按维度汇总，比如日交易汇总
ADS	应用数据层	面向具体业务报表的数据

你想想看，如果没有分层，所有数据混在一起，查个报表得跑几个小时，谁敢用？

1.2.3 维度和度量

维度就是你看数据的角度，比如时间、地区、产品类型。度量就是你要分析的值，比如交易金额、交易笔数。这个其实很好理解——你想知道"北京地区昨天卖了多少钱"，那"北京"和"昨天"就是维度，"卖了多少钱"就是度量。

1.3 实时与批量处理对比

这个对比，我估计很多同学都听过。但真正在金融场景里用起来，差别还是挺大的。

1.3.1 批量处理

批量处理就是定时跑任务，比如每天晚上12点跑一次。优点是稳定、成本低、容易管理。缺点是延迟高——你今天看到的报表，其实是昨天的数据。

适合的场景：

• 监管报表（T+1报送）
• 月末结算
• 历史数据归档
• 风控模型训练

1.3.2 实时处理

实时处理就是数据一来就处理，延迟在秒级甚至毫秒级。优点是快，缺点是对系统要求高、成本也高。

适合的场景：

• 实时风控（比如反欺诈）
• 行情推送
• 实时大屏
• 交易监控

1.3.3 核心对比

对比维度	批量处理	实时处理
延迟	分钟~天级	秒级~毫秒级
数据量	大（TB级）	中等（GB级）
一致性	强一致性	最终一致性
成本	低	高
复杂度	低	高
典型工具	Hive、Spark SQL	Flink、Kafka Streams

为什么会这样？说白了，实时处理要保证低延迟，就不能做太复杂的计算。而批量处理可以慢慢算，所以能做更精细的数据清洗和关联。

1.4 知识体系总览

下面这张图，是我自己画的。它把金融数据仓库的核心逻辑串起来了。你看一眼，应该就能明白整个体系是怎么运转的。

这张图其实就讲了一件事——数据从哪来、怎么存、怎么算、怎么用。左边是三种处理模式，右边是数据流转路径。你仔细看看，应该能发现实时和批量在架构中的位置差异。

1.5 我的几点建议

最后，分享几个我在实际项目中的体会：

• 别一上来就搞实时——先搞清楚业务到底需要多快的数据。很多场景T+1就够了。
• 数据质量是命根子——金融数据一分钱都不能差。我见过因为数据对不上，整个团队加班一周的惨状。
• 架构要留有余地——今天做批量，明天可能就要加实时。设计时考虑好扩展性。
• 监控和告警不能少——数据链路断了，你得第一时间知道。我曾经因为没监控，数据丢了三天才发现……