📚 课程目录第3章数据架构核心概念

3. 数据架构核心概念

银行风险领域的数据架构选型，不能简单追随技术潮流，而要从风险管理的业务特征出发。风险数据具有强一致性、强时效性、强追溯性、强关联性四大特征：监管报送要求口径可审计，风险预警要求T+0或准实时，模型回溯要求历史数据可复现，风险传导分析要求跨业务条线关联。理解数据仓库、数据湖、数据中台、湖仓一体四种模式的本质差异，是做出正确架构决策的前提。

一、核心原理：四种架构模式的本质差异

四种模式并非简单的替代关系，而是面向不同数据形态和消费场景的架构范式。数据仓库以Schema-on-Write为核心，数据入库前必须完成建模和清洗，适合高度结构化的指标计算与监管报送；数据湖以Schema-on-Read为核心，原始数据先存储后解析，适合非结构化数据和探索式分析；数据中台本质是“数据仓库+数据湖+服务化”的组织形态，强调数据资产沉淀与API化复用；湖仓一体则通过开放表格式（如Iceberg、Hudi、Delta Lake）在数据湖上实现事务、Schema演进和性能优化，试图兼顾湖的灵活性与仓的可靠性。

二、方法流程：银行风险场景的架构匹配方法

架构选型应遵循“场景驱动、能力匹配、渐进演进”的原则。具体流程如下：

识别风险数据消费场景：将风险场景分为监管报送类、实时预警类、模型开发类、分析探索类四类，明确每类对时效、一致性、历史深度的要求。
评估数据形态与质量：结构化交易数据优先入仓，非结构化文本、影像、日志优先入湖，跨源关联数据考虑中台或湖仓。
匹配架构能力矩阵：对照下表，判断哪种架构能同时满足场景的硬性约束。
设计分层与口径：无论选择何种架构，风险指标口径必须在架构的语义层统一注册，避免“同数不同源”。
渐进式落地：先以数据仓库保障监管底线，再以数据湖承接探索需求，最终通过湖仓一体或中台实现融合。

风险场景	时效要求	数据形态	推荐架构	关键约束
监管报送（1104、EAST）	T+1	结构化	数据仓库	口径可审计、血缘完整
实时反欺诈预警	毫秒~秒级	结构化+行为流	湖仓一体/中台	低延迟、规则热更新
信用风险模型开发	T+1~T+7	结构化+外部数据	数据湖+特征平台	历史快照可复现
操作风险文本分析	T+1	非结构化	数据湖	NLP处理、存储成本
统一风险视图	T+0	跨源结构化	数据中台	实体打通、API复用

三、案例场景：某银行风险数据架构演进复盘

某全国性股份制银行在风险数据架构上经历了三个阶段。第一阶段以传统数据仓库为核心，支撑1104和EAST报送，但面对反欺诈实时预警时，仓内批处理延迟无法满足要求。第二阶段引入Hadoop数据湖，将日志、设备指纹、外部黑名单等数据入湖，反欺诈模型AUC提升明显，但湖内数据质量参差，模型特征口径与仓内指标不一致，导致同一客户在报表和预警中风险等级不同。第三阶段采用湖仓一体架构，在数据湖上引入Iceberg表格式，将仓内指标下沉为湖上事务表，同时通过数据中台统一注册风险指标口径，实现“一份口径、多处消费”。

关键经验：架构融合的价值不在于技术栈统一，而在于口径统一。湖仓一体解决了存储与计算融合，但指标语义的统一仍需依赖元数据管理和指标注册中心。

四、误区与复盘

误区一：数据湖可以替代数据仓库。数据湖缺乏事务和Schema约束，直接用于监管报送会导致口径漂移和审计困难。正确做法是湖仓分工，仓保底线，湖拓边界。

误区二：数据中台就是买一套平台。中台的核心是数据资产治理和服务化能力，而非工具堆砌。没有指标口径注册和血缘管理，中台只是另一个数据孤岛。

误区三：湖仓一体等于性能免费提升。开放表格式带来事务和Schema演进能力，但小文件合并、元数据管理、查询引擎适配仍需专门调优，否则性能可能低于传统仓。

复盘上述案例，架构选型的核心判断标准可以归纳为三条：监管报送看仓库，探索建模看湖，实时融合看湖仓，资产复用看中台。四者不是互斥选项，而是可以在同一银行内分层共存、通过统一元数据和指标口径实现逻辑一体的架构组合。

风险数据架构选型决策伪代码：
if 场景 == 监管报送 and 要求强一致:
    return 数据仓库
elif 场景 == 探索分析 and 数据形态多样:
    return 数据湖
elif 场景 == 实时预警 and 需要事务保障:
    return 湖仓一体
elif 场景 == 跨条线复用 and 需要API服务:
    return 数据中台
else:
    return 组合架构 + 统一指标注册中心

最终，银行风险数据架构的成熟度不体现在采用了哪种时髦技术，而体现在风险指标口径是否唯一、数据血缘是否完整、监管与内控能否同源。架构是容器，口径才是内容；容器可以演进，内容必须稳定。