巴塞尔协议
巴塞尔协议是全球银行业最重要的监管基准，由 巴塞尔银行监管委员会在国际清算银行的框架下制定。它之所以是行业基石，是因为它为银行抵御风险设定了一个共同语言和最低安全标准，确保银行持有足够的资本来应对潜在的倒闭风险。
为了帮助你快速建立一个框架性认知，我把巴塞尔协议的三个主要版本及其对银行系统的核心意义整理如下：
📜 巴塞尔协议演进概览
| 协议版本 | 核心重点 | 关键定义与指标 | 历史意义 |
|---|---|---|---|
| 巴塞尔协议 I （1988年） | 统一资本标准 | 资本充足率：资本 / 风险加权资产 最低要求：8%（核心资本至少4%） 资本划分：核心资本（一级）和附属资本（二级） | 首次为全球银行提供了统一的资本衡量标准，确保银行资产的风险越大，所需持有的资本就越多。 |
| 巴塞尔协议 II （2004年） | 三大支柱框架 | 支柱 1: 最低资本要求（操作风险被纳入） 支柱 2: 监管审查（强化外部监督） 支柱 3: 市场约束（要求银行披露风险信息） | 构建了一个更全面的风险管理体系，不再仅限于计算资本，而是将监督检查和市场约束也作为风险控制的核心手段。 |
| 巴塞尔协议 III （2010年起） | 抵御金融危机 | 更高质量资本：核心一级资本充足率升至 4.5%，一级资本充足率升至 6% 新设缓冲资本：资本留存缓冲（2.5%）和逆周期缓冲资本（0-2.5%） 引入新指标：杠杆率（3%）、流动性覆盖率（LCR）和净稳定资金比率（NSFR） | 显著提高了银行抵御风险的能力，旨在防止2008年全球金融危机重演，通过提高资本质量和引入流动性监管，确保银行即使在压力时期也有足够的"弹药"应对。 |
从2023年1月1日起，中国也已开始实施《商业银行资本管理办法》，被业内称为"中国版巴塞尔协议III"，这标志着最新的国际监管标准已在国内全面落地。
🧐 对于数据开发：你需要关注什么？
了解了背景，在工作中你可能更多会接触到这三个核心概念：
-
资本充足率：这是整个协议的量化核心。你会经常处理用于计算这个比率的数据——分子是银行持有的合格资本，分母是风险加权资产（RWA）。
-
风险加权资产（RWA）：数据开发的关键任务之一，就是根据监管规则，准确计算不同资产（贷款、债券、同业拆借等）的风险权重，从而汇总出RWA。这是巴塞尔协议I奠定的核心方法论。
-
三大支柱：这会直接反映在数据需求上。
-
支柱一（最低资本）：影响贷款、金融投资等几乎所有业务线的数据资本计量。
-
支柱二（监管审查）：通常对应银行内部资本充足评估过程的数据支持，需要强大的压力测试和风险预测模型。
-
支柱三（市场约束）：要求银行对外披露详细的资本和风险信息，这往往需要从数据仓库加工出符合监管格式的报表。
-
银行监管报送板块及内容和作用
银行监管报送是指银行按照监管部门要求，定期或不定期向其报送各类业务数据和报表的过程。
这项工作本质上是银行向监管部门"汇报经营情况"，是监管机构了解银行风险状况、实施有效监管的基础。
一、监管机构与主要报送板块
银行需向三大监管机构报送数据：
| 监管机构 | 主要报送板块 |
|---|---|
| 国家金融监督管理总局（原银保监会） | 1104非现场监管报表、EAST系统、客户风险系统、大额风险暴露系统、一表通等 |
| 中国人民银行 | 金融大集中系统、利率报备监测、金融基础数据报送、存款保险、支付统计（PISA）、信贷标准化等 |
| 国家外汇管理局 | 国际收支申报、外汇账户、结售汇、对外资产负债等 |
在众多报送板块中，1104非现场监管报表和EAST系统是最核心的两大体系：
-
1104报表：侧重宏观层面的汇总统计，反映银行整体经营和风险状况，包括资本充足率、资产质量、盈利性等核心指标
-
EAST系统：要求报送全量业务明细数据，支持监管机构从底层账户、交易出发进行穿透式监管
1104这个名称直接来源于其启动日期——2003年11月4日。
具体来说，2003年11月4日，原中国银监会（现国家金融监督管理总局）召开主席办公会议，正式启动“银行业金融机构监管信息系统建设工程”。这个项目被命名为“1104工程”，名称就是取自会议召开的日期。
简单的时间线如下：
2003年11月4日：银监会启动“1104工程”，这就是1104名称的由来
2006年3月起：报表体系开始分阶段试运行
2007年元月：系统正式投产
尽管名称源于启动日期，但“1104工程”后来逐渐扩展为一整套完整的非现场监管报表体系。
我们今天所说的“1104报表”实际上是对这一整套监管报送体系的统称，所有银行都需要按照1104工程的规范向监管部门报送各类数据。
二、核心报送内容详解
以2026年最新监管制度调整为例，可以看出监管关注的重点：
| 报送板块 | 典型报表/模块 | 核心报送内容 | 监管目的 |
|---|---|---|---|
| 1104报表 | G01_Ⅵ托管业务情况表 | 托管资产规模、资金流向、流动性状况 | 监测托管业务风险传导，防范挤兑风险 |
| G11资产质量分类表 | 贷款五级分类、行业分布 | 监控银行资产质量变化 | |
| G12贷款质量迁徙表 | 贷款向下迁徙、不良处置情况 | 追踪风险演变轨迹 | |
| S71普惠金融表 | 小微贷款、涉农贷款、退役军人创业贷 | 评估政策支持领域信贷投放 | |
| 大集中系统 | A1411资产负债统计表 | 存贷款结构、同业业务、向央行借款 | 掌握银行资产负债全貌 |
| G04利润表及附注 | 利息收入、手续费收入、纳税金额 | 评估银行盈利能力和税负 | |
| EAST | 标准化明细数据 | 客户信息、账户流水、交易对手、信贷合同 | 支持穿透式监管和风险排查 |
| 一表通 | 报送区+可信区 | 整合EAST、1104、客户风险数据，统一标准 | 实现"一次报送、多方共享"，减轻银行负担 |
监管要求持续升级：以1104报表为例，2026年修订涉及新增1张表、修订13张表、调整6份填报说明，共新增指标43项、调整46项、删除4项。
三、监管报送的三大作用
1. 对监管机构：实施非现场监管
监管机构通过分析银行报送的数据，可以不亲临现场就能判断银行的经营状况和风险水平，实现"早识别、早预警、早处置"。
例如，通过托管业务表监测大规模资金异动，通过贷款迁徙表追踪不良贷款演变。
2. 对银行自身：倒逼数据治理
监管报送倒逼银行建立统一的数据标准、提升数据质量。
许多银行以此为契机建设监管数据集市，统一基础数据来源，解决不同系统间的数据不一致问题。这正是你作为大数据开发可以重点关注的方向——如何让数据"同根同源"、可追溯、可检核。
3. 促进穿透式监管落地
传统监管依赖机构汇总报送，无法看到底层细节。"一表通"等新机制要求银行建立可信区，存储标准化明细数据，支持监管机构从账户、交易层面逐层穿透，真正实现风险的可视可控。
与你未来工作的关联：监管报送是银行大数据团队的核心战场之一。
你需要理解每张报表背后的业务含义，熟悉从源系统到数据集市再到报送文件的完整数据加工链路，并能通过数据检核发现质量问题。
这既是合规要求，也是你快速理解银行整体业务的最佳切入点。
EAST 是什么
EAST全称“检查分析系统”（Examination and Analysis System Technology），是国家金融监督管理总局（原银保监会）开发的监管数据标准化报送系统。
简单理解：EAST是监管部门要求银行（以及保险、信托等金融机构）把所有核心业务数据（明细级别的）按统一格式定期报送上去的一套标准体系。
一、为什么要有 EAST？
传统的监管报送方式（如1104报表）是汇总表格式的——银行上报的是“全行贷款总额XX亿”、“不良率XX%”这种汇总数据。
这种方式的缺陷是：监管只能看到结果，看不到过程。如果银行造假，很难发现。
EAST的思路完全不同：不报汇总结果，报原始明细。监管收到数据后，自己建模、自己分析，可以做到：
| 能力 | 说明 |
|---|---|
| 精确制导 | 不依赖银行提供的“结论”，直接从底层数据筛查违规线索 |
| 穿透追踪 | 看到一笔资金从哪来、到哪去，全链条可追溯 |
| 跨行关联 | 把不同银行的客户资金流、信息流链接在一起，发现隐蔽问题 |
业内有个形象的比喻：EAST是监管的“精确制导导弹”，坐在家里就能定位问题，指哪打哪。
二、EAST的两端：银行端 vs 监管端
| 角色 | 做什么 | 核心难点 |
|---|---|---|
| 银行端 | 从核心、信贷、理财等系统抽取业务数据，按EAST标准格式加工后报送 | 数据量大（单次报送可能上亿条）、口径复杂、跨系统整合困难 |
| 监管端 | 接收各银行报送的数据，建立原始数据库，监管人员建模分析，筛查违规疑点 | 数据质量校验、跨行关联分析 |
三、EAST的数据范围（以EAST5.0为例）
EAST5.0（2022年发布）覆盖11个主题域、70张报表、1838个数据项。
主要主题包括：
| 主题域 | 核心数据表 |
|---|---|
| 公共信息 | 机构信息、员工信息、交易对手信息 |
| 客户信息 | 对公客户、个人客户、集团客户、关联方 |
| 会计记账信息 | 总账科目、分户账流水 |
| 各项贷款 | 信贷借据、信贷合同、票据贴现、票据转贴现 |
| 表内外担保 | 保函、信用证、担保合同 |
| 信贷管理信息 | 抵质押物、贷后检查、五级分类、展期、垫款 |
| 资金交易信息 | 同业业务、债券投资 |
| 理财业务 | 理财产品销售、客户持仓 |
四、EAST的版本演进
| 版本 | 发布时间 | 核心变化 |
|---|---|---|
| EAST1.0 | 2012年 | 试点推广 |
| EAST4.0 | 2019年 | 扩大采集范围，首次出现批量罚单 |
| EAST5.0 | 2022年 | 当前主流版本：精简冗余报表、细化业务场景、新增集团客户/关联方检测、强化交叉校验 |
五、为什么银行特别重视EAST？
因为监管真的会罚款，而且罚得很重。
-
2022年：21家全国性银行因EAST数据质量问题被罚，合计8760万元，政策行、国有行、股份行“全军覆没”
-
2020年：8家银行首批EAST罚单，合计1770万元
-
2023年：宁波鄞州农商行因EAST数据与1104数据不一致等问题被罚90万元
更关键的是，2021年《商业银行监管评级办法》将“数据治理”首次纳入评价体系，占5%的权重。数据质量差直接影响监管评级，进而影响银行能开展的业务范围。
六、EAST与1104的区别（重要！）
| 对比项 | EAST | 1104报表 |
|---|---|---|
| 报送形式 | 明细数据（每一笔贷款、每一笔交易） | 汇总数据（总贷款余额、平均利率） |
| 数据量级 | 亿级行数 | 几千个指标 |
| 监管用途 | 穿透式检查、疑点筛查、现场检查线索 | 日常监测、风险指标跟踪 |
| 银行端压力 | 极大（需整合多源系统、保证明细准确） | 相对较小 |
| 交叉校验 | EAST数据与1104数据必须一致，否则被罚 | — |
七、对你作为大数据开发的意义
EAST是银行大数据团队最重要的监管报送任务之一，你将接触的典型工作包括：
-
数据抽取与加工：从核心、信贷、理财等源系统提取数据，按EAST标准转换成70张报送表
-
数据质量校验：开发检核规则，确保EAST数据与1104、客户风险系统数据交叉一致
-
性能优化：EAST数据量极大（单次报送可能数亿条），需要优化ETL任务（例如某保险公司的EAST数据加工仅需20分钟）
-
版本升级：监管每2-3年更新规范，需要配合改造报送逻辑
一句话总结：EAST是理解银行数据治理、监管合规、大数据平台架构的最佳切入点。
如果你能在入职前理解EAST的70张表覆盖了哪些业务，你就已经对银行的数据全貌有了系统性的认知。
EAST 的70张表覆盖了哪些业务
EAST 5.0 的 70 张表覆盖了银行业务的11 个主题域，基本可以理解为：只要银行做的业务，EAST 几乎都要报。
下面是这 11 个主题域及其核心业务覆盖范围的详细拆解：
EAST 5.0 的 11 个主题域与业务覆盖范围
| 序号 | 主题域 | 核心业务覆盖 | 主要数据表（举例） | 监管关注点 |
|---|---|---|---|---|
| 001 | 公共信息 | 机构、员工、股东等基础信息 | 机构信息表、员工表、股东及关联方信息表 | 了解银行自身架构，排查关联交易、内部人违规持股等 |
| 002 | 客户信息 | 对公/个人客户基本信息及财务状况 | 对公客户信息表、个人客户信息表、对公客户财务信息表、集团客户表 | 识别集团客户和关联方，通过财务数据判断还款能力 |
| 003 | 卡片信息 | 借记卡、信用卡卡片及收单业务 | 卡片信息表、收单商户信息表 | 监测伪卡欺诈风险，收单业务合规性 |
| 004 | 会计记账信息 | 银行最核心的账务流水 | 个人/对公存款分户账及明细记录、内部科目对照表 | 核对每一笔资金流向，是EAST与其他监管报表交叉校验的基础 |
| 005 | 各项贷款 | 银行最核心的信贷资产 | 信贷合同表、信贷借据表、票据贴现/转贴现表、互联网贷款相关表、垫款登记表 | 穿透看贷款真实投向（行业/地区），严防资金违规流入股市楼市 |
| 006 | 表内外担保信息 | 押品管理与担保合同 | 表内外业务担保合同表、抵质押物信息表 | 评估担保是否充足，押品价值是否虚高 |
| 007 | 信贷管理信息 | 贷后管理全流程 | 贷后检查表、五级分类认定表、资产转让表 | 监控贷款质量迁徙，严查虚假出表 |
| 008 | 信用卡业务 | 信用卡交易与分期 | 信用卡账户表、交易流水表、分期业务表 | 监测信用卡资金流向（如套现、违规投资） |
| 009 | 表外授信业务 | 票据承兑、信用证、保函 | 票据出票信息表、保函与信用证表、委托贷款表、交易背景信息表 | 核查贸易背景真实性，保证金来源是否合规 |
| 010 | 资金交易信息 | 金融市场业务（自营投资、衍生品） | 金融工具信息表、自营资金交易信息表、即期及衍生品交易信息表 | 穿透看底层资产，严防违规投向房地产或资金空转 |
| 011 | 理财业务 | 银行理财销售与投资 | 理财产品信息表、客户理财产品持有信息表、理财投资明细表 | 打破刚兑后是否风险隔离，销售是否合规 |
两大关键监管逻辑
了解表的结构只是第一步，理解监管为什么让银行报这些数据才是重点。
有以下两个核心逻辑：
-
消灭“抽屉协议”，实现穿透式监管
以前银行通过层层嵌套理财产品来规避监管。现在 EAST 5.0 要求 “看穿底层” 。-
例如，通过 “金融工具信息表” 和 “自营资金交易信息表” 的关联，监管可以清楚看到银行的自营资金是否通过购买资管产品，最终流向了被限制的房地产领域。
-
-
交叉校验，堵住“数据造假”
监管不再只看银行报送的汇总数据。EAST 5.0 专门设计了 “联动检核” 规则，将 EAST 的明细数据与 1104 报表、客户风险系统的数据进行强制比对。-
典型场景：假如你在 EAST 中填报某笔贷款投向是“小微企业”，但该企业在“对公客户财务信息表”中资产规模巨大，属于“大型企业”，就会触发“报表不一致”的警报，银行需要解释原因。
-
总结：70张表的核心价值
对于你作为大数据开发的工作，可以将这 70 张表理解为一份覆盖银行全业务线的“数据字典”。
-
对监管：EAST 是银行在监管面前 “脱掉衣服” 的过程，所有业务细节都暴露在聚光灯下。
-
对银行：满足 EAST 报送要求已成为最耗费大数据平台算力的任务之一，特别是 005（各项贷款） 和 010（资金交易） 这两个主题域，单次报送的数据量常常达到亿级。你的工作将直接关系到银行能否按时、准确地完成报送。
银行监管报送频率
银行监管报送的频率取决于报送系统的类型和监管要求，从日报到年报都有，且呈现频率加快的趋势。
最新的"一表通"系统已将部分数据报送频率提升至每日。
一、主要监管报送系统的报送频率
| 报送系统/类型 | 报送频率 | 具体时点要求 | 关键说明 |
|---|---|---|---|
| EAST系统 | 月度 | 月后10-15个工作日内 | 当月月初报上月全量明细数据，有缓冲期 |
| 1104报表 | 月度、季度为主 | 月后6日或13日（不同报表不同） | 部分报表月报，部分季报，部分年报 |
| 一表通 | 每日（日更） | 实时/每日 | 最新监管趋势，2025年起全面推广，实现"准实时"监控 |
| 大额交易报告 | 5个工作日内 | 交易发生后5个工作日内 | 反洗钱要求，人民银行管理 |
| 可疑交易报告 | 不超过5个工作日 | 确认为可疑交易后 | 反洗钱要求 |
| 重大事项报告 | 2小时/24小时 | 挤兑等紧急事件2小时内；部分事件24小时内 | 突发事件应急报送 |
| 存款/现金头寸 | 五日报/日报 | 央行要求的头寸监测 | 反映银行流动性状况 |
| 常规统计调查 | 月报、季报、年报 | 按固定周期 | 基础性统计 |
二、频率变化趋势：从"事后"到"实时"
传统的监管报送以EAST为例，是月度报送：当月月初报上月的数据，中间有半个月的缓冲期。即便数据有问题，银行还有时间慢慢修正。
但金融市场变化速度极快，"可能上午刚放出一笔贷款，下午市场就变天了；一笔异常交易几分钟内就能完成资金周转"（来源）。靠月度报表，等监管看到数据时，风险可能已经"发酵"了。
"一表通"的推出改变了这一格局——它直接把报送节奏拉到"日更"，每天都把最新数据报上去，几乎与业务实时同步。这相当于让监管有了"实时监控"的能力：谁贷了款、资金往哪流、风险指标有没有超标，每天都能呈现在监管眼前。
三、按紧急程度分类
| 报送类型 | 代表系统 | 频率 | 技术压力 |
|---|---|---|---|
| 高频/实时型 | 一表通（日更）、重大事项（2小时） | 日/小时级 | 极高，需自动化流水线 |
| 常规月度型 | EAST、1104月报 | 月度 | 高，需批量ETL |
| 定期汇总型 | 1104季报、年报 | 季度/年度 | 中等 |
| 事件触发型 | 可疑交易报告、重大事项 | 发生后规定时限内 | 需建立预警机制 |
四、对不同报表/银行的时间节点差异
1. 不同报表的月度报送时间不同
以1104报表为例，2026年制度要求：
-
部分报表：月后6日内完成报送
-
部分报表：月后13日内完成（如政策性银行的特定报表）
2. 不同规模银行的实施时间不同
"一表通"采用分阶段推进策略：
-
资产规模150亿元及以上的银行机构：需在2026年12月底前完成报送
-
其他银行机构：需在2027年12月底前全面达标
五、与大数据开发工作的关联
作为大数据开发人员，你需要关注：
| 关注点 | 说明 |
|---|---|
| ETL稳定性 | 每日/月度报送要求ETL任务必须稳定、可重复、有监控告警 |
| 性能优化 | EAST等月度报送单次数亿条数据，需要优化大批量处理性能 |
| 数据质量校验 | 日更模式下没有"事后补救"的时间窗口，源端数据质量至关重要 |
| 实时技术栈 | "一表通"推动银行从T+1批处理向准实时流处理演进 |
一句话总结：银行监管报送频率正从传统的月度为主（1104、EAST），向每日实时（一表通）和事件触发即时报送（反洗钱、重大事项）两个方向演进，对数据开发的技术要求越来越高。
一表通是什么？
一表通是国家金融监督管理总局（原银保监会）推行的一套全新监管数据报送体系，是银行业监管报送的“集大成者”和“终极方案”。
它要求在银行端建设“监管数据可信区”（一个独立的监管数据存储区域），实现“T+1”日报送（即次日报送当日数据），取代传统的EAST、1104、客户风险等多套报送体系，目标是实现真正的“穿透式监管”。
一、为什么要推一表通？——解决三大痛点
传统监管报送存在三大顽疾：
| 痛点 | 传统模式的问题 | 一表通的解决方式 |
|---|---|---|
| 标准不统一 | 1104、EAST、客户风险等9套体系各自为政，银行需重复报送、口径不一致 | 整合成统一标准，实现“一次报送、多方共享” |
| 时效性差 | EAST等是月度报送（本月报上月数据），风险发现滞后 | T+1日报送，监管几乎实时掌握银行状况 |
| 无法穿透 | 传统报表是汇总数据，看不到底层明细，容易造假 | 要求明细级数据+层层穿透，支持逐层追溯 |
二、一表通的两大核心组成部分
根据2025年5月国家金融监督管理总局发布的《关于做好银行机构监管报表“一表通”工作的通知》（金发〔2025〕20号），一表通正式从试点进入全面推广阶段。其架构包含两大核心：
| 组成部分 | 功能 | 关键特征 |
|---|---|---|
| 报送区 | 银行加工生成监管数据的系统，是报送的“生产车间” | 整合多源数据、质量校验、生成标准化报表 |
| 可信区 | 银行端独立建设的监管数据存储区，与监管端协同构成分布式大数据集群 | 存储标准化明细数据，支持监管远程访问和穿透查询，数据不离行但监管可查 |
可信区的设计亮点：数据存储在银行内部（安全性高），但监管可以像访问自己的数据库一样直接查询分析（穿透性强），避免了大量数据传输的安全风险。
三、一表通的覆盖范围有多广？
根据2026年公开信息，一表通已覆盖：
| 维度 | 数据 |
|---|---|
| 报表数量 | 约90张（整合了9套旧体系） |
| 数据字段 | 2224个业务字段 |
| 覆盖主题 | 10大主题域：产品类、协议类、交易类、状态类、资源类等 |
| 报送频率 | T+1日报送（每日更新） |
以资金业务为例，一表通债券投资相关的字段多达182个，而原EAST系统仅86个，覆盖面大幅提升。
四、一表通与现有系统的关系
一表通不是简单新增一套报表，而是逐步替代现有体系：
| 现有系统 | 与一表通的关系 |
|---|---|
| EAST | 逐步被替代。数据质量核验达标后，银行可停报EAST |
| 1104报表 | 大幅“瘦身”，部分报表被一表通吸收 |
| 客户风险系统 | 逐步被替代 |
过渡期的技术要求：一表通数据必须与原EAST、1104数据核对一致，通过监管的数据质量核验后，才能正式切换。
五、对银行大数据开发的挑战
一表通对技术的要求远高于传统报送：
| 挑战 | 说明 |
|---|---|
| 报送频率剧增 | 从月度到每日，ETL任务必须稳定、自动化 |
| 数据量巨大 | 90张表、2224个字段、日更，对存储和计算都是考验 |
| 穿透要求高 | 投资业务需层层穿透到底层资产（私募基金、资管产品等），数据获取困难 |
| 数据质量严苛 | 必须与EAST、1104等存量体系保持一致，差异需逐项排查 |
| 系统架构新 | 需建设可信区，涉及网络设计、数据库选型、API服务等 |
六、推进时间表
| 时间节点 | 要求 | 来源 |
|---|---|---|
| 2025年5月 | 金发〔2025〕20号文发布，一表通进入全面推广阶段 | |
| 2026年12月底 | 资产规模150亿元及以上的银行需完成报送 | 上一轮回答 |
| 2027年12月底 | 其他银行机构需全面达标 | 上一轮回答 |
一句话总结：一表通是监管报送的“终极形态”——日报送、全覆盖、可穿透，是银行大数据团队当前最重要的系统建设项目之一，其技术难度和工作量远超传统的EAST和1104报送。
现金头寸 & 头寸监测 是什么？
头寸是银行业术语，源自民国时期钱庄的“存洋”制度，后演变为对资金头寸的俗称，简单说就是：银行手头可动用的资金金额。
现金头寸特指银行以现金形式持有的、可随时动用的资金。头寸监测则是银行对自身及各网点资金余缺进行持续跟踪、预测和调度的管理活动。
一、拆解概念
| 术语 | 通俗定义 | 包含哪些内容 |
|---|---|---|
| 头寸 | 银行能用的钱 | 库存现金、准备金、超额备付金、同业拆借额度等 |
| 现金头寸 | 银行最灵活的那部分钱 | 主要=超额存款准备金（存在央行、随时能用）+库存现金（网点金库里的钱） |
| 头寸监测 | 每天盯着钱够不够用 | 今日进多少、出多少、缺多少，提前安排借或存 |
核心区分：
-
银行的大部分资产（如贷款）是“死钱”——放出去了，到期才能收回
-
头寸是“活钱”——今天、现在就能用的钱
-
头寸监测就是管理这把“活钱”，确保不枯竭（没钱兑付）、不冗余（闲置浪费）
二、为什么银行要死盯“头寸”？
银行业务的本质是期限错配：存款可能明天就被取走，但贷款放出去是三年期。如果某天取款的人特别多，银行头寸不够，就会发生挤兑风险——这是银行最致命的危机。
头寸监测的核心目的：
| 目的 | 说明 |
|---|---|
| 保支付 | 确保每天有足够的钱应对客户取款、结算、还款等支付需求 |
| 达标监管 | 满足央行存款准备金率要求（法定准备），头寸中的“超额准备”就是缓冲垫 |
| 降成本 | 钱闲置在账上不产生收益，但要付存款利息；多头寸就亏钱 |
| 赚收益 | 头寸富余时，去同业拆借市场借给别人赚利息（隔夜拆借利率） |
| 防风险 | 避免因临时资金缺口被动高息借钱，甚至违约 |
一句话：头寸管好了，银行赚钱又安全；头寸管砸了，银行可能一夜崩盘。
三、头寸监测看哪些指标？
| 指标 | 含义 | 监管/管理要求 |
|---|---|---|
| 超额存款准备金 | 存放在央行、超出法定要求的部分，是银行最核心的“活钱” | 通常保持一定“安全垫”，用于日间支付 |
| 库存现金 | 网点金库里的现钞 | 满足日常取款需求，过多有安保成本 |
| 备付金率 | (超额准备+库存现金) / 存款总额 | 反映银行即时支付能力，监管有关注 |
| 流动性覆盖率(LCR) | 优质流动性资产 / 未来30日净现金流出 | 国际监管标准，必须≥100% |
| 净稳定资金比率(NSFR) | 可用稳定资金 / 所需稳定资金 | 长期抗风险能力，必须≥100% |
| 存贷比 | 贷款总额 / 存款总额 | 老指标，过高意味着头寸紧张 |
银行内部会设定更细的监控指标，如：分时段头寸预测（早中晚各时点的资金余缺）、最大连续净流出天数等。
四、实际工作场景
场景1：日初匡算
每天早上，资金交易员打开系统，看到：
-
今日到期存款：50亿（要付出去）
-
今日收回贷款：30亿（收回来）
-
法定准备金需缴：20亿
-
昨日留存头寸：10亿
匡算：10 + 30 - 50 - 20 = -30亿
→ 今天缺30亿，得赶紧去同业拆借市场借钱（或动用央行常备借贷便利SLF）。
场景2：日间调度
中午，某大客户突然要汇走5亿，头寸告急。资金交易员立刻：
-
看其他网点有没有富余头寸，内部调拨（利率内部定价）
-
实在不够，在银行间市场拆借一笔隔夜资金
-
下班前，确保在央行的准备金账户不透支（透支会被罚）
场景3：日终平账
下午4点，所有支付关门。资金交易员确认：
-
今日实际头寸与预测偏差多少
-
有没有不必要的闲置资金（多的话去拆借市场借出）
-
生成头寸日报，上报行领导
五、头寸监测系统的数据来源
作为大数据开发，你会涉及这些数据：
| 数据来源系统 | 关键数据 | 用途 |
|---|---|---|
| 核心系统 | 各网点存款余额、贷款收回、大额支付流水 | 实时头寸计算 |
| 资金交易系统 | 同业拆借、债券回购、发行存单 | 主动融资/投资 |
| 央行系统 | 准备金账户余额、SLF操作 | 法定要求+最后求助 |
| 大额支付系统 | 实时逐笔支付指令（单笔超一定金额） | 大额资金流出预警 |
| 流动性管理系统 | LCR、NSFR等指标 | 监管合规监测 |
六、与监管报送的联系
头寸监测与监管报送的关系非常紧密：
| 报送系统 | 关联点 |
|---|---|
| 1104报表 | 流动性风险相关报表（如G21、G22、G25）需要填报备付金率、LCR等头寸相关指标 |
| 一表通 | 要求T+1日报送，其中流动性相关数据直接反映银行每日头寸状况 |
| 央行存款准备金报表 | 每日/五日报送，核心就是头寸管理的结果 |
| 重大事项报告 | 头寸出现严重短缺（如无法满足支付）需2小时内上报监管 |
一句话总结：现金头寸是银行的“生命线”，头寸监测就是每天“管好这条线”——确保不缺钱（防挤兑）、不浪费（提效益）、合规达标（防处罚）。
作为大数据开发，你会参与头寸预测模型、实时头寸计算ETL、流动性风险指标加工等工作，是银行核心数据能力的体现。
源系统（交易系统）OLTP，其中OLTP是什么，还有OLAP是什么
简单来说：OLTP 是银行的生产交易系统（核心系统），负责处理每一笔具体的业务；OLAP 是分析报表系统（数据仓库），负责基于大量历史数据进行查询和分析。
在银行的实际工作中，您接触到的核心系统、信贷系统都属于 OLTP 系统，而监管报送、管理会计、风险报表则基于 OLAP 系统构建。
以下为您详细拆解这两个概念：
1. OLTP (联机事务处理)
-
英文全称：On-Line Transaction Processing
-
银行俗称：生产系统 或 交易系统。
-
核心特征：
-
高并发：每天要处理几千万笔交易（如双11秒杀般的存取款、转账）。
-
低延迟：您去ATM取钱，点完确认3秒钟钱必须出来，不能等。
-
数据一致性：转1000块，对方账户必须增加1000，自己账户减少1000，绝不允许丢单。
-
操作粒度：处理单笔或少量数据。
-
-
数据特点：细节数据，反应当前状态。比如查询"我卡里现在还剩多少钱？"。
2. OLAP (联机分析处理)
-
英文全称：On-Line Analytical Processing
-
银行俗称：分析系统 或 数据仓库。
-
核心特征：
-
大数据量：可能要扫描过去10年的所有交易记录（几十亿条数据）。
-
复杂计算：做汇总、求平均、计算同比环比。
-
时效性要求相对较低：跑一个季度报表可能需要几分钟甚至几小时，不需要秒级响应。
-
操作粒度：处理大批量历史数据。
-
-
数据特点：汇总/历史数据，反应趋势变化。比如查询"过去三年，杭州地区25岁到30岁人群的存款总额变化趋势"。
结合银行场景的直观对比（以"贷款"为例）
| 维度 | OLTP (交易系统) | OLAP (分析系统) |
|---|---|---|
| 典型系统 | 核心系统、信贷系统 | 数仓、监管报送系统 |
| 典型动作 | 贷款发放：点击按钮，生成借据，账户余额减少。 | 贷款分析：统计上个月一共放了多少亿贷款，分行业统计。 |
| 数据量级 | 查询一笔交易，涉及几百个字节。 | 全表扫描几亿条记录，计算汇总值。 |
| 关注点 | 张三今天有没有还钱？（针对个体） | 所有30岁以下的群体坏账率是多少？（针对全局） |
| 数据库类型 | 一般用 MySQL、Oracle、DB2 (强调锁机制、事务回滚) | 一般用 Hadoop、Hive、Greenplum (强调列存储、分布式计算) |
| 数据模型 | 实体-关系模型 (ER模型)，3NF范式，减少数据冗余（存一次，到处用）。 | 星型模型、雪花模型，存在适度冗余，方便快速统计。 |
| 对您工作的意义 | 这是数据源头。ETL工作就是从这些系统抽取数据。 | 这是数据终点。监管报表、风控模型最终都在这里跑。 |
为什么您需要区分这两个概念？
-
理解压力来源：您在银行做大数据，白天 OLTP 系统繁忙，您不能随便跑大查询去锁表（会影响柜员办业务）。通常夜间是 ETL 抽取数据的高峰期。
-
理解数据延迟：您在数仓里查到的数据，通常是昨天的（T+1）。因为需要等 OLTP 系统日终结算完成后，才能把数据抽走。
-
技术选型：如果要优化监管报送的速度，那是 OLAP 的活儿（写SQL优化、建分区、用Hive）；如果要优化转账速度，那是 OLTP 的活儿（换更好的硬件、优化索引）。
可以说总账系统是核心系统吗
不准确。严格来说，总账系统不能等同于核心系统；但两者关系极为密切，可以说总账系统是核心系统的重要组成部分之一。
在现代银行的IT架构中，普遍采用的是 "瘦核心、大外围" 的设计理念。
核心系统主要负责交易处理，而总账系统则专注于会计核算，两者各司其职。
一、两者的核心区别
| 维度 | 核心系统 (Core Banking System) | 总账系统 (General Ledger System) |
|---|---|---|
| 系统定位 | 银行IT架构的心脏和大脑 | 后台会计核算与管理中心 |
| 主要职责 | 处理实时交易：存、贷、汇、开户、转账等 | 处理事后核算：记账、算账、报账、出报表 |
| 服务对象 | 银行客户（柜员、网银、ATM直接调用） | 银行内部财务人员、管理层、监管机构 |
| 数据时效 | 实时（毫秒级响应，交易完成即更新余额） | 准实时或T+1（日终跑批完成后更新总账） |
| 核心机制 | 交易与核算一体化（传统）→ 交易与核算分离（现代） | 接收流水，生成凭证，汇总科目余额 |
| 通俗比喻 | 银行的前台收银台（客户存钱取钱的地方） | 银行的后台会计部（月底汇总做账出报表的地方） |
二、两者的包含关系
有搜索结果表明，总账系统是核心业务系统的主要模块之一。
例如，核心业务系统的功能模块通常包括：
-
业务处理（存放汇）
-
客户信息管理（CIF）
-
账务处理（总账系统）
-
卡系统管理
-
产品工厂
因此，在传统架构中，总账功能是内置在核心系统中的。这也解释了为什么很多人会认为"总账系统就是核心系统"。
三、现代架构：交易与核算分离
然而，随着银行业务的复杂化和新会计准则的实施，"交易与核算分离"成为主流趋势。
核心逻辑：
-
核心系统：只负责"把账算对"（记录借贷双方的金额变动）
-
总账系统：独立出来，负责"把账记好"（按新会计准则生成报表、支持多维度分析）
为什么要分离？
| 原因 | 说明 |
|---|---|
| 给核心减负 | 核心系统每天要处理海量交易，如果还要做复杂的会计核算（如计提减值、递延税），会影响交易速度 |
| 满足监管要求 | EAST、一表通要求报送明细数据，独立的总账系统能更好地支持穿透式查询 |
| 精细化核算 | 总账系统可以从科目级延伸到账户级，支持按产品、客户、部门等多维度分析 |
| 快速响应新准则 | 会计准则和税法经常变，独立的总账系统可以单独升级，不需要改造核心系统 |
四、实际工作中的理解
作为大数据开发人员，你在数据开发任务中会这样区分：
| 场景 | 去哪里取数据 |
|---|---|
| 查询客户账户余额、交易流水（实时） | 核心系统 |
| 统计全行某日的资产总额、净利润 | 总账系统或数据仓库 |
| 生成资产负债表、利润表 | 总账系统 |
| EAST报送的会计记账信息表 | 总账系统或数据仓库 |
五、一句话总结
总账系统是核心系统在"会计核算"这个专业领域的延伸和深化。你可以把核心系统理解为一个既有前台又有后台的小公司，而把总账系统理解为那个被独立出去、专门做账的会计部门。 两者紧密协作，但职责边界清晰。
清分日
"清分日"这个词在银行的资金清算和现金管理这两个场景下，代表的含义完全不同，但都指向一个核心："算清楚、分明白"的日子。
在支付清算环节，"清分"是一个每天都会发生的标准化技术流程；
在现金管理环节，它则可能指代具体的结算截止日（如每月20号）。
1. 支付清算场景：日结发生的日子（最常指代）
在跨行转账、刷卡消费等业务中，"清分日"特指银行间清算系统完成数据整理、轧差计算的那一天。
-
技术定义：清分是清算的数据准备阶段。简单说，就是把当天所有银行之间的交易（比如A行客户刷了B行的卡）收集起来，按"你欠我、我欠你"进行汇总和轧差，算出最终谁该给谁多少钱。
-
发生频率：每个工作日（T日）都会进行。
-
实际业务举例：
-
T日（交易日）：你在商场用招行卡刷了1000元，这台POS机属于工行。交易瞬间完成。
-
T日（清分日/夜）：当天晚上，银联或网联系统开始"记账"。它把所有类似的跨行交易数据整理出来，算出"工行应该给招行多少钱"。
-
T+1日（结算日）：第二天，资金真正划拨，钱到账。
-
2. 现金管理场景：结息/还款日
在存款、贷款或理财业务中，"清分日"往往与利息计算或资金划拨的截止日期挂钩。
-
业务定义：指银行进行存款结息、贷款扣息或理财资金归集的特定日期。
-
常见日期：据网络查询，可能是每月的20号或25号左右。
-
实际业务举例：银行约定每月20号为"贷款清分日"，那么系统会在这一天统一从你的账户里扣除当月应还的房贷利息。
⚠️ 重要辨析：清分 vs 结算
如果你想在银行工作，这两个词是必考的基础概念，千万不能混用：
| 维度 | 清分 (Clearing) | 结算 (Settlement) |
|---|---|---|
| 核心比喻 | 算账（计算谁欠谁多少钱） | 付款（真正把钱划走） |
| 发生时间 | 交易发生后，结算之前 | 清分完成之后 |
| 资金状态 | 资金在途，尚未实际转移 | 资金所有权完成转移，钱到账了 |
| 数据表现 | 生成清算明细和应收应付净额 | 扣减一方准备金，增加另一方准备金 |
总结
如果在正式工作或面试中遇到这个词：
-
优先按照支付清算的语境理解，它指的就是交易发生后的那个"算账日"（通常是T+0或T+1）。
-
记得向对方确认是算账日（清分）还是到账日（结算），这在排查资金问题时极其关键。
数据仓库分层都有哪些
在银行的数据仓库（OLAP系统）建设中，为了应对海量数据和复杂的业务需求（如监管报送、风险计量、管理会计），通常不会只建一个库，而是按照数据处理流程划分为多个逻辑层次。
这种分层架构的核心目的是解耦和复用：下层为上层提供数据服务，每一层承担不同的职责，避免数据杂乱无章。
以下是银行业最通用的四层或五层数据架构（从原始数据到业务应用）：
1. ODS 层（操作数据存储层）
-
俗称：贴源层、裸数据层。
-
作用：作为数据仓库的缓冲区。它几乎不对数据做任何业务逻辑加工，直接存储从核心系统、信贷系统等OLTP源系统抽取来的数据。
-
存储内容：与源系统表结构几乎一模一样的原始数据。例如：核心系统的交易流水表、借据表原样存储一份。
-
对于数据开发的意义：当源系统数据因bug被修改或误删时，ODS层可用于数据回溯。这里是ETL（数据抽取转换加载）任务的第一站。
2. DWD 层（数据明细层）
-
俗称：清洗层、细节层。
-
作用：对ODS层数据进行清洗、标准化、去脏数据。解决源系统数据不一致、字段缺失、编码转换等问题。
-
存储内容：
-
清洗：剔除金额为空的记录。
-
标准化：将不同系统表示“男” (M/1/男) 统一成标准代码。
-
轻度粒化：保留最细粒度的数据（每一笔流水）。
-
-
对于数据开发的意义：是数据分析师最常使用的明细数据源，数据质量有保障。
3. DWS 层（数据汇总层/服务层）
-
俗称：宽表层、轻度汇总层。
-
作用：提前聚合。因为银行数据量巨大，每次查询都扫描DWD层的几十亿笔流水会非常慢。DWS层按主题（如客户、账户、机构、产品）或时间（如日、周、月）预先计算好统计值。
-
存储内容：宽表（将多张关联表合并成一张大表）。例如：客户日汇总表（包含该客户当天总存入、总支出、交易笔数）。
-
对于数据开发的意义：性能优化的关键。监管报表大多在此层生成，从跑几小时提速到几分钟。
4. DM 层（数据集市层）
-
俗称：业务专用层。
-
作用：这是面向具体业务部门或具体应用的个性化数据组装层。不同部门对数据的口径和需求不同，DM层按需进行数据组装。
-
存储内容：
-
信贷集市：包含授信额度、五级分类、逾期天数等。
-
监管集市：按1104报表、EAST报送接口要求组装的数据。
-
营销集市：包含客户的画像标签、资产流失预警等。
-
-
对于数据开发的意义：数据安全与隔离。信贷部不能随意看到监管报送数据，通过物理或逻辑上的集市层实现权限隔离。
5. ST 层 / APP 层（临时层/应用层）
-
俗称：接口层、前端层。
-
作用：STM 是临时表区，用于存放复杂计算过程中的中间结果；APP 是应用层，是报表系统、可视化大屏直接读取的最终结果表。
-
存储内容：极度的业务汇总数据。例如：一张包含“当日全行资产总额”的单行表。
数据流向示意图
text
源系统 (OLTP) 数据仓库 (OLAP) 业务应用
+-------------+ +----------------------------------------------+
| 核心系统 | | ODS层 DWD层 DWS层 DM/APP层 |
| (交易流水) | ----> | 原样拷贝 --> 清洗去脏 --> 按日汇总 --> 监管报表 |
+-------------+ | (贴源) (明细) (轻度汇总) (业务集市) |
| 信贷系统 | | |
| (借据表) | ----> | 保留历史 --> 关联合同 --> 统计余额 --> 风险大屏 |
+-------------+ +----------------------------------------------+
总结：为什么要分这么多层？
-
空间换时间：提前算好DWS层的汇总数据，避免每次查报表都重新扫描全量明细。
-
过程清晰：如果监管报表数据错了，可以从APP层 -> DWS层 -> DWD层 -> ODS层逐层回溯排查是哪里算错了，而不是在黑盒里抓瞎。
-
屏蔽变更：如果核心系统改造、表结构改变，只需修改ODS到DWD的映射，上层的报表逻辑（DM/APP层）可以完全不用动。
-
复用性：DWD层的“清洗后交易流水”可以被信贷集市、监管集市、风险集市共用，避免重复清洗开发。
对于刚入行的你：在银行里，通常DWD层和DWS层由数据平台团队统一维护，而DM层（数据集市）往往由具体业务条线的开发团队（比如你所在的监管报送项目组）负责建设。
ODS，DWD，DWS，DM，ST 等都是什么的缩写 还有 ETL
这些缩写涵盖了银行数据仓库建设的核心逻辑。
你可以把数据仓库想象成一个高度自动化的工厂，源数据是原材料，经过不同车间加工，最终变成供业务使用的产品。
数据仓库分层架构（从上到下）
| 缩写 | 英文全称 | 中文含义 | 通俗理解 | 主要作用 |
|---|---|---|---|---|
| ODS | Operational Data Store | 操作数据存储 | 贴源层：工厂的原材料仓库。数据几乎原封不动地从业务系统同步过来，保留了最原始的细节。 | 缓冲隔离，减轻源系统压力；作为数据追溯、重跑的“历史快照”基地。 |
| DWD | Data Warehouse Detail | 数据仓库明细层 | 清洗层：工厂的清洗加工车间。对ODS数据进行去脏、转换、标准化。 | 提供高质量、统一的明细数据，是后续所有分析的基础。 |
| DWS | Data Warehouse Service | 数据仓库服务层 | 汇总层：工厂的预包装车间。按主题（如“客户日活跃”）提前聚合计算，形成“宽表”。 | 性能优化，避免每次查询都重新计算海量明细数据。 |
| DM | Data Mart | 数据集市 | 业务集市：面向具体部门的成品定制车间（如风控集市、财务集市）。 | 按业务需求进行个性化加工，实现权限与资源隔离。 |
| ST | (暂无统一全称) | 临时表/中间表层 | 工作台：存放复杂计算过程中的临时结果。 | 辅助开发，将复杂逻辑拆解为多个简单步骤。 |
ETL：贯穿全程的物流系统
| 缩写 | 英文全称 | 中文含义 | 通俗理解 | 主要作用 |
|---|---|---|---|---|
| ETL | Extract， Transform， Load | 数据抽取、转换、加载 | 工厂的自动化物流与加工线。 • Extract（抽取）：从原材料库取货。 • Transform（转换）：清洗、加工、转换。 • Load（加载）：将成品送到指定货架。 | 实现数据从源系统 -> ODS -> DWD -> DWS -> DM 的流动与加工。 |
一个实际例子：统计“昨天招行卡消费总金额”
为了更好地理解这个流程，我们以一个具体的数据分析需求为例：
-
ODS（贴源层）：从核心系统复制原始交易表
trade_table，包含100亿条记录。数据中可能存在异常，如金额为负。 -
ETL（加工过程）：
-
Extract：从ODS层读取昨日交易数据。 -
Transform：过滤掉金额为负的数据，将交易类型的代码（如'01'）转换为文字（如'消费'）。 -
Load：将清洗后的数据写入DWD层明细表。
-
-
DWD（明细层）：存储清洗后的
dwd_trade_di表，同样是百亿级，但数据质量高。 -
DWS（汇总层）：按“日+客户+银行”分组，计算每日消费总额，生成
dws_customer_bank_trade_1d表。 -
DM（数据集市层）：风控部门在DM层创建
dm_risk_high_trade_d表，筛选出单日消费超过5万元的客户。 -
分析师最终查询：直接从
DWS或DM层获取结果，查询时间从几小时缩短到几秒。
💡 总结：分层的价值
-
空间换时间：提前计算好DWS层的汇总结果，用存储空间换取后续查询的极速响应。
-
过程清晰可追溯：数据流向层层递进。报表数据出问题，可以沿着
DM -> DWS -> DWD -> ODS的路径反向排查，快速定位是因为原始数据出错，还是清洗规则不当。 -
屏蔽底层变更：核心系统表结构改动，只需调整
ODS -> DWD的ETL逻辑，上层报表完全不受影响。 -
复用与解耦：DWD层的清洗明细数据可以被DWS层、多个DM层（信贷集市、监管集市）复用，避免重复开发，也实现了数据权限的隔离。
宽表是什么
宽表是数据仓库中一种非常实用的技术手段，它的核心思想是把很多相关的信息提前拼在一张表里，以“空间换时间”，让数据分析查询变得更快、更简单。
📊 一图看懂：窄表 vs 宽表
为了帮你建立直观印象，我们以一个非常简单的“用户订单”场景为例：
| 对比维度 | 窄表 (明细表) | 宽表 (大宽表) |
|---|---|---|
| 设计理念 | OLTP型：减少冗余，确保数据一致性 | OLAP型：增加冗余，提升查询性能 |
| 存储格式 | 多为行式存储（如MySQL） | 多为列式存储（如HBase、ClickHouse） |
| 数据关系 | 严格遵循范式，通过ID关联多张表 | 非规范化，大量字段平铺在一张表 |
| 举例 | 订单表存user_id，用户表存user_name查订单+用户名需要两表关联 | 订单表里直接存user_id和user_name查订单+用户名单表查询即可 |
| 适用场景 | 业务系统（OLTP），如银行核心交易 | 分析系统（OLAP），如监管报表、BI大屏 |
| 查询性能 | 关联表多，性能较慢 | 无需关联，查询极快 |
| 存储成本 | 较低（数据不重复） | 较高（数据大量冗余） |
🏦 银行的宽表长什么样？
在银行，宽表是数据分析的基石。一个典型的客户日汇总宽表可能会像这样设计，把所有相关信息都“拍平”在一行里：
| 客户ID | 客户姓名 | 客户年龄 | 昨日总资产 | 昨日总负债 | 昨日理财余额 | 近7日交易笔数 | 近30日交易金额 | 是否高净值客户 |
|---|---|---|---|---|---|---|---|---|
| 1001 | 张三 | 35 | 520,000 | 120,000 | 300,000 | 23 | 85,000 | 是 |
| 1002 | 李四 | 28 | 8,000 | 15,000 | 0 | 5 | 2,000 | 否 |
数据来源说明：这张宽表中的每一列数据，都是ETL任务从DWD层的多个明细表里，通过聚合、计算、关联生成的。比如，“昨日总资产”是通过汇总存款、理财、基金等多个账户的余额计算得出的。
这样做的好处是，当业务人员想分析“年龄大于30岁的高净值客户”时，直接在这一张表上做筛选和聚合就行了，完全不需要去写复杂的SQL关联10多张表。
🎯 总结：宽表的价值与局限
-
核心价值：性能优化。在数据仓库中，“大表扫描”往往比“多表关联”要快得多。同时，它也简化了使用，业务分析师无需理解底层复杂的数据关系，查一张表就能获取所有需要的信息。
-
主要局限：存储成本高，数据更新不灵活（如果要修改某个客户的姓名，所有关联的行都需要更新，容易出错），并且维护代价大（底层源数据变动时，ETL逻辑可能需要大规模修改）。
因此，你会看到银行的DWS层、DM层（数据集市）基本都是宽表，而ODS、DWD层则更多是保持原子信息的窄表。这就是“逐层加工”的典型思路。
数据清洗是什么意思
数据清洗，在银行数据开发中俗称 ETL 的核心环节。
简单来说，数据清洗就是把从各业务系统（OLTP）拿来的“脏数据”变成符合标准的“干净数据”的过程。脏数据就像是源系统产生的含有错误、格式不统一、重复或空值的原始材料，而清洗就是为了确保这些数据能被准确用于分析或上报。
银行的数据来自核心、信贷、信用卡等多个系统，每个系统的标准不同，难免会产生脏数据。
主要需要清洗以下几类问题：
| 脏数据类型 | 具体表现举例 | 清洗动作 |
|---|---|---|
| 格式不一致 | 核心系统性别存 M/F，信贷系统存 1/0 | 统一转换：全部转为男/女 |
| 缺失值 | 借据表里行业分类字段是空的 | 填充/剔除：用默认值填充，或直接剔除无效数据 |
| 重复数据 | 同一笔交易因系统重发被记录了两次 | 去重：保留一条有效记录 |
| 逻辑错误 | 一条交易流水的交易时间是未来日期 | 过滤/修正：直接过滤，或按业务逻辑推算修正 |
| 违反业务规则 | 贷款已结清，但仍有还款记录 | 校验拦截：标记为异常数据，退回源系统排查 |
具体例子：银行“贷款放款”的清洗逻辑
假设源系统（OLTP）传来两条流水，数据清洗的任务就是要识别并处理其中不规范的记录。
-
原始数据（脏）：
-
Row 1:
金额：空，利率：null，放款日期：2024-02-30 -
Row 2:
金额：100万，利率：3.45，放款日期：2024-03-01
-
-
清洗过程：
-
格式检查：
金额字段不能空 → Row 1 自动剔除，不进入数仓。 -
逻辑检查：
放款日期不能无效 → Row 1 的日期错误，同样剔除。 -
数据转换：
利率在源系统存为3.45，但数仓要求存0.0345→ 自动除以100。
-
-
清洗结果（净）：
-
只有 Row 2 的
金额：100万，利率：0.0345，放款日期：2024-03-01成功进入数仓DWD层。
-
为什么银行特别重视数据清洗？
这与你之前了解的监管报送和OLAP分析息息相关，数据清洗在其中扮演着至关重要的角色：
-
为了监管合规：你之前了解的EAST系统（即“检查分析系统”，一种监管数据报送系统）要求数据必须精准。如果没清洗干净，把性别填错或金额留空，银行会被监管通报批评甚至罚款。
-
为了风控准确：风控模型需要用干净的数据来判断坏账率。如果用脏数据训练模型，后果会非常严重——模型会认为“所有没填性别的客户都信誉良好”，导致大量的信贷风险误判。
-
为了报表不打架：如果不对性别、行业等代码进行统一清洗和转换，信贷部统计的“男性客户”和风控部统计的“男性客户”人数可能会不一样，导致管理层无法决策。
简单来说，数据清洗决定了银行数据分析的底线——如果进数仓的数据是错的，那么后面所有OLAP分析报表、监管报送出来的结果也一定是错的。这是一切数据分析工作的基础。
借据表
借据表是银行信贷核心系统中最基础、最重要的数据表之一。
它记录了每一笔贷款发放后的详细借据信息，可以理解为银行与客户之间每一笔具体借款的“电子欠条”或“法律凭证”。
它与贷款合同的关系是：一份贷款合同可以对应多笔借据。
例如，一家企业获批了一笔1000万的授信合同，在实际用款时可以分多次提款，每次提款都会生成一张独立的借据。每张借据都有自己独立的借据号、金额、利率和还款计划。
一、借据表的核心字段（常见）
| 字段分类 | 具体字段 | 说明 |
|---|---|---|
| 借据标识 | 借据号、合同号 | 借据号是借据表的主键，唯一标识一笔具体放款；合同号关联到授信合同 |
| 借款人信息 | 客户号、客户名称、证件类型、证件号码 | 关联到客户信息表，识别这笔钱借给了谁 |
| 借据基础信息 | 借据金额、已用金额、余额、币种 | 借据金额是初始放款金额；余额是当前尚未偿还的本金 |
| 利率信息 | 基准利率、利率浮动比例、执行利率、结息方式 | 决定每期还多少利息；结息方式包括按月结息、按季结息、到期还本付息等 |
| 时间信息 | 放款日期、到期日期、结清日期 | 放款日期是资金实际划拨日；到期日期是借据应还清日；结清日期是实际还清日（未结清则为空） |
| 五级分类 | 五级分类、分类调整日期 | 正常、关注、次级、可疑、损失；按月或按季更新 |
| 状态信息 | 借据状态 | 正常、逾期、核销、结清等 |
| 还款方式 | 还款方式 | 等额本息、等额本金、先息后本、一次性还本付息等 |
二、借据表在数据流转中的位置
借据表是连接信贷合同与还款流水的核心桥梁：
贷款合同（1） ──────→ 借据表（N） ──────→ 还款流水表（N）
│ │ │
│ 授信额度 │ 每笔放款明细 │ 每期还款记录
│ 合同期限 │ 执行利率 │ 还款本金
│ 担保方式 │ 放款日期 │ 还款利息
└─────────────┘ └──────────────┘ └──────────────┘
典型数据链路：
-
合同签订后：客户提款 → 核心系统生成一张借据（借据表新增一条记录）
-
放款记账：会计上借记“贷款”科目，贷记“存款”科目
-
还款时：每还一笔钱 → 还款流水表增加N条记录，同时借据表的
余额字段减少 -
借据结清：当
余额=0时，借据状态更新为“结清”，结清日期填入当天
三、借据表在大数据开发中的应用场景
| 场景 | 说明 | 关键字段 |
|---|---|---|
| 监管报送 | EAST系统需要报送“信贷借据表”，一表通需要日报送借据明细 | 借据号、余额、五级分类、逾期天数 |
| 贷后监控 | 每日跑批，识别新增逾期、关注类下迁等风险信号 | 借据状态、五级分类、余额 |
| 利息计提 | 按日或按月计算应计利息，生成会计凭证 | 执行利率、余额、结息方式 |
| 风险加权资产(RWA)计算 | 巴塞尔协议要求根据贷款风险权重计算资本占用 | 五级分类、借据金额、担保方式 |
| 客户级汇总 | 将同一客户下所有借据的余额、逾期状态汇总，形成客户级风险视图 | 客户号、余额、借据状态 |
| 不良资产处置 | 核销、打包转让时，借据明细是基础数据源 | 五级分类、余额、借据状态 |
四、借据表与相关表的关系总结
| 表名 | 关系 | 说明 |
|---|---|---|
| 贷款合同表 | 一对多 | 一份合同可多次提款，每次提款一张借据 |
| 客户信息表 | 多对一 | 一张借据对应一个借款人（对公或个人）
从借据的角度看，多张借据可以指向同一个客户。每一张借据都有且只有一个借款人。 |
| 还款计划表 | 一对多 | 等额本息/等额本金等固定还款方式会生成还款计划表
一张借据对应多个还款计划 等额本息或等额本金还款方式下，银行会预先算好未来每一期要还多少钱，每一期就是一条计划记录。 |
| 还款流水表 | 一对多 | 每还一次款，记录一条流水，同时扣减借据余额。
有时候客户会提前还款、多还、少还，实际还款不一定完全按计划来。 一张借据可以有多次还款记录；每条流水只属于一张借据。 |
| 担保关系表 | 多对多 | 一张借据可关联多个担保人/抵质押物
一笔贷款（一张借据）可以有多个担保人/多个抵押物；同时，一个担保人可以同时为多笔贷款担保。 |
客户信息表
│
│ 一对多（一个客户多张借据）
▼
┌─────────────────┐
│ 借据表 │ ← 中心表
│ (每笔放款) │
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
还款计划表 还款流水表 担保关系表
(一对多) (一对多) (多对多)
事前规划的 事后实际发生的 ┌─────────┼─────────┐
每期应还 每次还款 ▼ ▼ ▼
保证人A 保证人B 抵押物C
五、一句话总结
借据表是银行信贷业务的“原子级”记录——每一笔钱放出去，就生成一张借据；每一笔钱还回来，就更新一次借据余额。 借据结清了，这张借据的使命才结束。
| 表关系 | 通俗理解 |
|---|---|
| 客户信息表 ← 借据表（多对一） | 一个人可以借多笔钱，但一笔钱只能是一个人来借 |
| 借据表 ← 还款计划表（一对多） | 一笔贷款，提前规划好未来12期要还多少（12条计划） |
| 借据表 ← 还款流水表（一对多） | 一笔贷款，可以分很多次实际还款（每次一条流水） |
| 借据表 ↔ 担保关系表（多对多） | 一笔贷款可以有多个担保人，一个担保人也可以为多笔贷款担保 |
在数据开发中，借据表是监管报送、风险计量、贷后管理三大场景的核心数据源，理解借据表的结构和流转逻辑，是理解银行信贷数据体系的关键入口之一。
客户和账户 一对多
账户和合同 一一对应
合同和借据 一对多
账户和借据 一对多
这个理解非常到位，精准地抓住了银行信贷数据模型中最核心的几个实体关系。你总结的这四条，是搭建银行数据仓库、理解业务流转的基石。
为了帮你巩固，我把这个逻辑链条再完整地梳理一遍，并补充一些你可能还没注意到的细节：
1. 客户和账户：一对多
-
含义：一个客户（个人或企业）可以在银行开立多个账户（如储蓄卡、信用卡、定期存单）。
-
关键点：这是银行“以客户为中心”的数据模型的起点。在CRM或数据仓库中，我们通常会将一个客户名下的所有账户进行归集（即
客户ID -> 账户ID的关系）。
2. 账户和合同：一一对应
-
含义：一个账户（如贷款账户）对应一份具有法律效力的借款合同。
-
细节：这里的“一一对应”指的是 “贷款账户” 。当一个客户申请一笔贷款并获批后，银行会为这笔贷款建立一个专门的贷款账户，并同时签订一份合同。合同规定了总金额、总期限、利率、还款方式等。账户则用于记录这笔贷款的余额变动和交易流水。
3. 合同和借据：一对多
-
含义：一份贷款合同可以分多次发放（提款），每次发放生成一张独立的借据。
-
常见场景：企业获得的循环授信额度或可分批提款的固定资产贷款。例如，一家制造企业获批一份5000万元的授信合同，它可以根据原料采购和工程进度，分三次提款：第一次2000万，第二次2000万，第三次1000万。每次提款都会生成一张独立的电子借据。
4. 账户和借据：一对多
-
含义：一个贷款账户下，可以挂载多张借据。
-
模型解释：这是上面“合同-借据”关系在数据层面的具体实现。
-
合同是法律层面的约定（签了字）。
-
贷款账户是会计和技术层面的记账主体（开了户）。
-
借据是资金划拨的具体凭证（放了款）。
-
流程：签订合同（建立关系） -> 同时创建贷款账户（用于记账） -> 每次提款生成一张借据，并增加贷款账户的余额。
-
还钱时：系统需要决定，你这次还的款，是冲抵哪一张借据的本金？还款流水会精确关联到具体的
借据号。
-
💡 这对你作为大数据开发意味着什么？
在实际工作中，当你要加工数据、编写SQL时，这个模型是核心依据：
-
想查“某企业总贷款余额”：
sql
-- 正确路径：客户 -> 账户 -> 借据 SELECT SUM(j.je) FROM 客户表 k JOIN 贷款账户表 a ON k.kh_id = a.kh_id JOIN 借据表 j ON a.zh_id = j.zh_id -- 账户和借据一对多 WHERE j.zhuangtai = '正常';
-
想查“某合同下的放款明细”：
sql
-- 正确路径：合同 -> 借据 SELECT * FROM 借据表 WHERE ht_id = 'HT2023001'; -- 一份合同对应多张借据
-
特别注意：在银行的OLTP（交易）核心系统中，贷款账户是连接客户（Customer）和借据（Voucher）的中间层。而在OLAP（分析）的数据仓库中，为了便于分析，常常会把这三张表的相关字段拉通，提前加工成一张 “借据级大宽表” ，包含客户信息、账户信息、合同信息，供分析师直接使用。
扫一扫
177
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
