本文系统梳理了银行数据指标体系和业务系统架构。
银行指标采用三级划分体系：一级指标（战略层）如经营效益、风险防控；二级指标（战术层）如盈利能力、资产质量；三级指标（执行层）如不良贷款率、拨备覆盖率等具体计算公式。
数据流转遵循基础层（源数据）-模型汇总层（主题宽表）-指标应用层（KPI）的加工路径，通过表内测试、表间测试和总分测试确保数据质量。
核心业务系统包括处理基础交易的核心系统、管理贷款全周期的信贷系统、记录信用卡交易的信用卡系统等，各系统数据最终汇聚至数据仓库支撑监管报送和经营分析。
信用卡业务流程涵盖申请、审批、消费、还款、分期等环节，涉及信用额度、账单日、免息期等核心概念。
可视化工具如帆软基于长亮科技构建的数据中台，为业务决策提供数据支持。
银行指标三级划分
银行指标的三级划分是一个从宏观战略到具体业务口径的逐层拆解体系。
简单来说，从"银行赚不赚钱"这种抽象问题，下钻到"营业收入具体是多少"这个可量化数值的过程中，指标被清晰地分为了三个层级。
这套体系是银行数据仓库建设、管理驾驶舱和监管报送的核心骨架。
我们可以通过下面的结构来理解：
一级指标：战略方向
一级指标位于金字塔顶端，是银行最高决策层（董事会）和外部监管机构最关心的宏观战略目标。它回答的是"银行整体经营得好不好"这个核心问题。
根据财政部发布的《商业银行绩效评价办法》，商业银行的绩效评价体系由 "服务国家发展目标和实体经济"、"发展质量"、"风险防控"、"经营效益" 这四类一级指标构成，每类权重均为25%。在银保监会的《商业银行监管评级办法》中，一级指标则更侧重于风险，包括资本充足、资产质量、公司治理与管理质量、流动性风险等九大要素。
这些一级指标直接决定了银行的监管评级、高管薪酬以及市场形象。
二级指标：业务维度
为了支撑一级指标，我们需要将其拆解为二级指标。二级指标将宏观战略细化为具体的业务关注领域，回答"我们要从哪几个方面去达成目标"这个问题。
例如，为了实现"风险防控"（一级指标）的目标，需要从管理情况、信用风险、流动性状况、杠杆化程度 等多个业务维度来进行评价。同样，"经营效益"可以被拆解为盈利能力、经营增长 等二级维度。
二级指标为银行的不同业务部门（如风控部、计财部、公司部）设定了清晰的考核方向。
三级指标：具体口径
三级指标是可量化、可计算的最小数据单元，它直接对应数据库中的某个字段或通过特定公式计算出的数值，回答"具体怎么算"这个问题。这是作为大数据开发人员最需要关注、也最直接打交道的层面。
以下是一些常见三级指标的实例：
| 所属二级指标 | 三级指标名称 | 指标计算口径/业务含义 |
|---|---|---|
| 盈利能力 | 净资产收益率 (ROE) | 净利润 / 平均净资产，衡量股东资金的使用效率 |
| 资产质量 | 不良贷款率 | (次级类贷款+可疑类贷款+损失类贷款) / 各项贷款余额，衡量信贷资产安全状况 |
| 资产质量 | 拨备覆盖率 | 贷款损失准备金 / 不良贷款余额，衡量银行抵御预期损失的能力 |
| 流动性风险 | 流动性比例 | 流动性资产 / 流动性负债，衡量短期偿债能力 |
| 小微金融 | 普惠型小微企业贷款"两增" | 指普惠型小微企业贷款增速不低于各项贷款增速、有贷款余额的户数不低于年初水平 |
| 数字化成效 | 个人财富管理线上化率 | 通过线上渠道购买理财、基金的客户数 / 总客户数 |
指标之间的关系：从原子到派生
在银行的数据中台实践中，还会基于三级指标进一步做技术抽象，分为原子指标 和派生指标。
-
原子指标：指不可再拆解的业务度量，如"贷款金额"。
-
派生指标 ：在原子指标基础上，加上业务限定 和统计周期后生成。
- 例如，"最近一个季度"、"对公业务"、"人民币贷款"、"平均余额" 就构成了一个典型的派生指标。
总结
银行指标的三级划分，本质是一个 "目标-维度-度量" 的映射过程：
-
一级指标 (战略层)：定方向（如：提升盈利水平）。
-
二级指标 (战术层)：定维度（如：关注净资产收益率和成本收入比）。
-
三级指标 (执行层) ：定口径 （如：ROE = 净利润 ÷ 平均净资产 × 100%）。
理解这个层级关系后，当你接到"做一张银行经营分析报表"的需求时，就不会迷茫了：你能清晰地知道，报表的每一个数字都来自一个定义精确的三级指标，而这个指标最终服务于哪一项银行战略。
基础指标、派生指标、衍生指标
这个分类不仅清晰，而且直接对应了银行数据仓库中指标建设的核心逻辑。
你提到的基础指标、派生指标、衍生指标 ，正是从原子数据 一步步加工成业务决策信息的标准路径。
我们结合你给出的精彩例子，把这个逻辑彻底夯实：
1. 基础指标：不可再分的"原子"
-
定义 ：最细粒度的事实度量，通常直接从借据、交易等明细表中通过简单汇总得到，不掺杂复杂计算。
-
你的例子："根据借据明细表，计算每个分行下的每个客户的贷款余额"。
-
本质 ：这是一个 "客户-分行" 粒度的、时点的贷款余额快照。它是后续所有分析的基础砖石。
-
数据特征 ：结果集的行数依然很大（等于
有贷款余额的客户数 × 涉及的分行数）。
-
2. 派生指标：基础指标的" GROUP BY "
-
定义 ：在基础指标之上，改变统计粒度或统计周期（如从"客户级"上卷到"分行级"，或从"时点"改为"日均"），不创造新的业务含义。
-
你的例子："把每个分行下每个客户的贷款余额，去汇总计算每个分行的贷款余额"。
-
本质 ：这是一个 "分行" 粒度的、时点的贷款余额汇总。
-
加工逻辑 ：
派生指标 = SUM(基础指标) GROUP BY 分行。计算过程清晰、无歧义。 -
数据特征 ：结果集的行数大幅减少（等于
分行数）。
-
3. 衍生指标：多个基础指标的"综合运算"
-
定义 ：两个及以上 基础或派生指标，通过加减乘除、比值、比例 等复杂逻辑计算得出，创造新的业务含义（如效率、占比、风险）。
-
你的例子："贷款客户逾期率 = 逾期客户数 / 贷款总客户数"。
-
本质 ：这是一个衡量资产质量的风险指标。
-
加工逻辑：
-
基础指标A= 逾期客户数（通常需先定义"逾期"标准，如>90天）。 -
基础指标B= 总贷款客户数。 -
衍生指标=A / B × 100%。
-
-
数据特征 ：结果是一个单一数值（或按某些维度拆解后的少量数值）。
-
归纳对比表
为了让你更清晰地看到三者的区别，我整理了一个对比表格：
| 维度 | 基础指标 | 派生指标 | 衍生指标 |
|---|---|---|---|
| 核心操作 | 明细数据的汇总 (SUM, COUNT) | 改变粒度的再聚合 (GROUP BY) | 不同指标间的计算 (+, -, *, /) |
| 业务含义 | 业务的原始度量 | 业务在不同视角/层级的度量 | 业务的效率、质量、比率 |
| 你的例子 | 每个分行-每个客户的贷款余额 | 每个分行的贷款总余额 | 贷款客户逾期率 |
| 能否直接用于决策？ | 很少能，数据太细 | 可以，如"看各分行规模" | 经常用于核心决策和考核 |
| 常见别名 | 原子指标、事实指标 | 统计指标、聚合指标 | 计算指标、复合指标、KPI |
在数仓中的层次对应
在银行的实际数据开发中，这三个指标通常对应着不同的数仓层次：
-
基础指标 主要在 DWD明细层 或DWS轻度汇总层（按客户、产品等维度汇总）进行计算和存储。
-
派生指标 通常在 DWS重度汇总层 或DM数据集市层，按照业务部门（如分行、总行）要求的维度进行上卷生成。
-
衍生指标 绝大多数在 DM层（数据集市） 或 APP应用层 进行最终计算，直接供报表或驾驶舱使用。
你的理解非常精准，这个分类是银行数据工作的底层逻辑之一。掌握它，你就能看懂任何一张报表背后的加工路径了。
技术架构分层：基础层 、模型汇总层、指标应用层
银行数据仓库从明细数据 到业务指标的标准加工路径。
架构逻辑图
一、 基础层
-
表名：借据表
-
数据粒度：每一笔贷款（一张借据为一条记录）
-
核心字段举例：
-
借据号、客户号、企业名称
-
贷款余额、发放金额、发放日期、到期日期
-
五级风险分类（正常、关注、次级、可疑、损失）
-
企业规模（大型、中型、小型、微型）
-
所属行业（如：C制造业、J金融业、K房地产业等）
-
贷款利率、担保方式等
-
这是最细粒度的原始数据，也是所有上层指标的唯一权威来源。
二、 模型汇总层
该层通过聚合基础层数据，构建面向特定分析主题的业务宽表，以解决"查询慢、逻辑复杂"的问题。
1. 贷款企业规模五级风险统计表
-
业务目标：监控特定客户群体在不同风险分类下的贷款余额分布。
-
数据粒度 ：按 "企业规模 + 五级风险分类" 一行。
-
表结构示例：
| 企业规模 | 五级风险分类 | 贷款余额（万元） | 客户数 |
|---|---|---|---|
| 大型企业 | 正常类 | 500，000 | 120 |
| 大型企业 | 关注类 | 20，000 | 8 |
| 中型企业 | 次级类 | 5,000 | 15 |
| 小微企业 | 损失类 | 200 | 30 |
2. 贷款行业统计报表
-
业务目标：分析全行贷款在不同行业的集中度及资产质量。
-
数据粒度 ：按 "行业" 一行。
-
表结构示例：
| 行业代码 | 行业名称 | 贷款余额（万元） | 不良贷款余额（万元） | 不良率 |
|---|---|---|---|---|
| K | 房地产业 | 8，000,000 | 80,000 | 1.00% |
| C | 制造业 | 5,000,000 | 125,000 | 2.50% |
实际生产中，这两个表只是众多汇总表的示例。
模型汇总层通常会包含客户主题、机构主题、产品主题、日期主题等多个维度的宽表，以及大量常用的统计结果表。
三、 指标应用层
这是最终呈现在报表或驾驶舱上的核心指标（KPI）。
指标应用层的表通常极度聚合，甚至可能是一行一个指标。
指标应用层设计示例
| 指标名称 | 计算逻辑/公式 | 数据来源 | 业务含义 |
|---|---|---|---|
| 不良贷款率 | (次级+可疑+损失贷款余额) / 贷款总额 | 贷款企业规模五级风险统计表 |
衡量银行信贷资产质量 |
| 大型企业不良率 | 大型企业中(次级+可疑+损失余额) / 大型企业总余额 | 贷款企业规模五级风险统计表 |
衡量大型客户群体风险 |
| 行业集中度 (CR5) | 贷款余额前5大行业的余额之和 / 贷款总额 | 贷款行业统计报表 |
衡量贷款分散化程度 |
| 单一客户集中度 | MAX(单户贷款余额) / (核心一级资本+附属资本) | 借据表 + 资本数据 |
监管红线：一般不得超过10% |
| 拨备覆盖率 | 贷款损失准备金 / (次级+可疑+损失贷款余额) | 借据表 + 准备金表 |
衡量银行抵御预期损失的能力 |
| 房地产行业不良率 | 房地产业(次级+可疑+损失余额) / 房地产业总余额 | 贷款行业统计报表 |
特定行业风险监控 |
💡 总结
-
基础层 ：确保 "不丢、不错" 。作为数据开发的你，需要保证从源系统抽取到基础层的数据是准确、完整的。
-
模型汇总层 ：实现 "易用、高效" 。这是数据开发的核心工作之一，需要充分理解业务需求，设计出高复用、高性能的汇总表。
-
指标应用层 ：达成 "准确、权威" 。确保最终提供给业务人员的每个指标，口径清晰、出处唯一，并且能逐级追溯到基础层的原始数据。
数据库 数据仓库
什么是数据仓库？
一句话概括 ：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的 数据集合，专门用于支持管理决策。
比喻：业务数据库是"收发货仓库"（记录每一笔流水），数据仓库就是"中央配送中心"（对所有数据进行清洗、归类、整合，形成统一视图，供分析决策使用）。
数据仓库的概念最早由"数据仓库之父"比尔·恩门（Bill Inmon）提出，他定义了数据仓库的四大核心特征（也称为"四大特点"）。
数据仓库的四个核心特点
| 特点 | 你的理解 | 补充说明 |
|---|---|---|
| ① 面向主题 | 按主题分类（如客户、交易、产品） | 不同于业务数据库按"业务功能"（如订单表、库存表、用户表）组织。主题是分析维度，比如想知道"过去三年客户流失情况"，围绕"客户"主题整合行为、交易、服务记录 |
| ② 集成性 | 从多个数据源采集、统一 | 不同系统数据格式、单位、命名可能不同（如A系统"性别0/1"，B系统"性别M/F"）。数据仓库会清洗、转换、去重、统一编码后才加载 |
| ③ 非易失性 | 数据加载后不修改 | 业务数据库支持增、删、改、查 （CRUD），数据仓库一般只做批量插入或覆盖，不逐行更新删除。因此历史数据稳定、可靠 |
| ④ 随时间变化 | 保存大量历史数据 | 业务数据库通常只保留最新状态 （如当前余额）。数据仓库会保留每一天/月的快照，支持趋势分析、同比环比、生命周期追溯 |
✅ 数据仓库也是用数据库技术存储 （如Oracle、PostgreSQL、Hive、ClickHouse等），但它的数据组织方式和用途与普通业务数据库完全不同。
数据仓库 vs 业务数据库 ------ 最核心区别
| 对比维度 | 业务数据库（OLTP） | 数据仓库（OLAP） |
|---|---|---|
| 中文全称 | 联机事务处理 | 联机分析处理 |
| 主要用途 | 支持日常业务操作（下单、支付、改密码） | 支持分析决策（报表、大屏、数据挖掘） |
| 操作类型 | 大量增、删、改、查（高频小事务） | 批量查询、聚合分析（低频大查询） |
| 数据特点 | 最新状态，通常只保留几天/几个月 | 历史全量，可能保存数年 |
| 数据模型 | 高度规范化（三范式），减少冗余 | 维度建模（星型/雪花型），适当冗余 |
| 响应速度 | 毫秒级（影响用户体验） | 秒/分钟级（可接受等待） |
| 典型用户 | 业务人员、客户 | 数据分析师、管理层 |
举个具体例子：
-
业务数据库 ：你在电商App点"立即购买"→ 数据库马上在订单表插入一条记录，扣减库存。这是OLTP。
-
数据仓库 ：公司做年度经营分析，想知道"华东区25-30岁女性用户最喜欢买什么品类商品"→ 数据仓库扫描过去3年数亿订单，按维度聚合返回结果。这是OLAP。
一个帮助你记忆的"生活化比喻"
| 角色 | 对应场景 |
|---|---|
| 业务数据库 | 你的记账本（今天买菜花50、加油花300... 只记录当前余额） |
| 数据仓库 | 你家里的档案室（保存过去5年每一笔收支单据、分类整理成月报、年报、品类分析表，帮你规划下一年预算） |
现代技术趋势
现在很多企业不一定先建"大而全"的传统数仓（如Teradata），而是采用数据湖 + 湖仓一体 架构。但从概念上讲，数据仓库的核心思想------为分析而生、集成、稳定、随时间变化------依然适用。
如果你之后想深入了解，我可以帮你讲：
-
数据仓库的常见分层架构（ODS → DWD → DWS → ADS）
-
维度建模和事实表、维度表（Kimball经典方法）
-
数仓 vs 数据湖 vs 湖仓一体
数据流程
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 企业数据架构全景图 │
└─────────────────────────────────────────────────────────────────────────────────────┘
┌──────────────────┐ ┌──────────────────────────────────────────────────────┐ ┌─────────────────────────┐ ┌────────────────────┐
│ 源系统层(OLTP) │ │ 数据仓库层(OLAP) │ │ 数据集市层(OLAP) │ │ 应用层(展示) │
│ 业务交易系统 │ │ 数仓 │ │ 按主题组织 │ │ 可视化/分析 │
├──────────────────┤ ├──────────────────────────────────────────────────────┤ ├─────────────────────────┤ ├────────────────────┤
│ │ │ │ │ │ │ │
│ • 核心系统 │────→│ ┌────────────────────────────────────────────┐ │ │ • 监管集市 │────→│ • 监管报送 │
│ • 信贷管理系统 │ 采集│ │ ODS层（贴源层） │ │ 采集│ - 1104报表 │ │ • 贷款风控大屏 │
│ • ECIF客户系统 │ │ │ • ODS_CUST • ODS_LOAN • ODS_TRANS │ │────→│ - 金融基础数据 │ │ • 绩效平台 │
│ • 贷记卡系统 │ │ └─────────────────┬──────────────────────────┘ │ │ • 风控集市 │ │ • 贷款数字地图 │
│ • 理财系统 │ │ │ ETL │ │ - 贷前/贷中/贷后指标 │────→│ • 自助分析报表 │
│ • 国际结算系统 │ │ ↓ │ │ • 资产集市 │ │ • 移动端驾驶舱 │
│ • 票据系统 │ │ ┌────────────────────────────────────────────┐ │ │ - 资产质量分析 │ │ │
│ • 其他业务系统 │ │ │ DWD层（明细层） │ │ │ • 营销集市 │────→│ │
│ │ │ │ • DWD_CUST（客户统一视图） │ │ │ - 客户画像标签 │ │ │
│ │ │ │ • DWD_存款账户交易明细 │ │ │ • 绩效集市 │ │ │
│ │ │ │ • DWD_贷款账户交易明细 │ │ │ - KPI考核报表 │ │ │
│ │ │ │ • DWD_理财产品交易明细 │ │ └───────────┬─────────────┘ └────────────────────┘
│ │ │ └─────────────────┬──────────────────────────┘ │ │
│ │ │ │ ETL │ │ 采集/API
│ │ │ ↓ │ ↓
│ │ │ ┌────────────────────────────────────────────┐ │ ┌─────────────────────────┐
│ │ │ │ DWS层（汇总层） │ │ │ 数据服务层 │
│ │ │ │ • DWS_贷款汇总表（按日/月/机构） │ │ │ （可选中间层） │
│ │ │ │ • DWS_存款交易统计表 │ │ ├─────────────────────────┤
│ │ │ │ • DWS_客户资产汇总表 │ │ │ • 数据API网关 │
│ │ │ └─────────────────┬──────────────────────────┘ │ │ • 统一查询接口 │
│ │ │ │ ETL │ │ • 实时数据推送 │
│ │ │ ↓ │ └─────────────────────────┘
│ │ │ ┌────────────────────────────────────────────┐ │ ↑
│ │ │ │ ADS层（应用层） │ │ │ 采集
│ │ │ │ • ADS_贷款明细宽表（含客户/产品维度） │ │ │
│ │ │ │ • ADS_风险监测指标表 │ └────────────────────┘
│ │ │ │ • ADS_监管报送数据表 │
│ │ │ └────────────────────────────────────────────┘ │
│ │ │ │
│ │ │ ◇ 元数据管理：数据血缘、数据字典、调度任务 │
│ │ │ ◇ 数据质量监控：完整性、准确性、一致性检查 │
│ │ └──────────────────────────────────────────────────────┘
│ │
└──────────────────┘
数据流向说明：
───→ 采集：ETL/ELT批量抽取 或 实时同步（Canal/Debezium）
~~~~→ 可选路径：部分应用直连ADS层一、整体架构解读
你的流程图展示了一个经典的分层数仓架构，核心流转路径是：
OLTP源系统 → 数据仓库(ODS→DWD→DWS→ADS) → 数据集市 → 应用端
这条路径解决了数据仓库的核心目标：将分散、杂乱、面向事务的业务数据，加工成统一、干净、面向分析的主题数据，最终服务于业务决策。
二、各层核心作用与流转细节
1. 源系统（OLTP）
-
作用：生产原始数据，支撑日常交易。
-
常见系统：核心、信贷、ECIF、贷记卡、理财、国际结算等。这些系统之间往往相互独立，数据标准不一。
2. 数据仓库（OLAP分析系统）
这是你图中的核心部分，也是整个流程的加工厂，通常分为四层：
| 层级 | 全称 | 核心作用 | 你图上的例子 | 关键特征 |
|---|---|---|---|---|
| ODS层 | 操作数据存储层 | 原样接入源系统数据，作为缓冲 | ODS_CUST |
保持源系统结构，是数据进入数仓的第一站 |
| DWD层 | 明细数据层 | 对ODS数据进行清洗、标准化、维度退化，形成最细粒度的事实明细 | DWD_CUST DWD_存款账户交易明细表 |
核心加工区：解决数据质量、统一编码、关联字典表 |
| DWS层 | 汇总数据层 | 按业务主题（如客户、产品、机构）进行轻度聚合，提升查询性能 | DWS_贷款汇总表 DWS_存款账户交易统计表 |
面向分析主题，粒度为日/月/年汇总 |
| ADS层 | 应用数据服务层 | 为具体应用需求定制数据产出，结果往往是宽表或接口 | ADS_贷款明细表 |
高度定制，直接对接下游数据集市或报表 |
流转逻辑 ：数据从ODS原样接入 → 在DWD层清洗打磨 → 在DWS层聚合汇总 → 在ADS层按应用场景打包输出。层层依赖，逐级加工。
3. 数据集市（OLAP分析系统）
-
作用 ：按业务部门或分析主题（监管、风控、资产、营销、绩效）进行数据再组织。数据集市通常是数仓ADS层的逻辑子集或物理视图。
-
你图中的例子：
-
监管集市→ 产出给监管报送 -
风控集市→ 产出给贷款风控 -
资产集市→ 产出给绩效平台 -
营销集市→ 产出给贷款数字地图
-
4. 应用端（可视化数据/OLAP）
-
作用：将数据以图表、报表、大屏等形式呈现给最终用户。
-
工具：帆软FineReport/FineBI、Tableau、Power BI等。它们直接连接数据集市或数仓ADS层。
三、你图中隐藏的两个重要流转路径
-
数据采集（ETL/ELT） ：你用箭头标注的"采集"，背后是复杂的ETL（抽取-转换-加载）或ELT过程。从源到ODS 通常是原样抽取；从ODS到DWD 是最复杂的转换清洗；从DWD到DWS/ADS是聚合计算。
-
应用回馈与数据治理 ：理想情况下，当应用端发现数据问题（如监管报送数据不准），可以反过来推动源系统修改或数仓加工逻辑修正，形成数据治理闭环。
四、关于你图中细节的补充/对齐点
| 你的写法 | 精确理解/建议补充 |
|---|---|
ODS_CUST |
客户主题的贴源层，基本保持与ECIF等源系统一致 |
DWD_CUST |
客户明细层 ，已经是清洗、整合后的统一客户视图（例如：将ECIF、核心、贷记卡的客户信息合并成一个） |
ADS_贷款明细表 |
此处"贷款明细"可能是面向某个具体应用（如风险明细查询）的轻度汇总或宽表，与DWD层的贷款明细粒度可能不同 |
| 数据集市与数仓的关系 | 通常数据集市可以直接基于数仓ADS层创建（逻辑集市），也可以物理独立（用于不同部门隔离） |
五、一个典型的数据流转示例
场景：一份"贷款风控报表"要展示"过去30天，每个客户经理名下的贷款逾期率"。
流转路径如下：
-
源系统 ：从核心系统抽取贷款合同表，从信贷系统抽取还款计划表，从ECIF抽取客户经理关系表 → ODS层
-
DWD层 ：清洗垃圾数据，统一日期格式、机构编码，关联三张表生成贷款逾期事实明细表
-
DWS层 ：按客户经理+日期，汇总每日逾期金额、贷款余额 → 贷款风控日汇总表
-
ADS层 ：根据风控报表需求，将DWS数据拼装成逾期风险宽表（含客户经理姓名、机构层级、逾期率预计算字段）
-
风控集市：将ADS层数据进一步按风控主题组织
-
应用端：帆软报表连接风控集市，拖拽生成逾期率趋势图、排名表
六、总结与下一步建议
你的图已经非常完整，核心要点都抓住了。如果想进一步完善，可以考虑：
-
增加元数据管理：在数仓旁标注"数据字典"、"血缘关系"、"调度任务"等组件
-
标注ETL工具：如Kettle、DataStage、DolphinScheduler
-
增加数据治理组件：数据质量管理、主数据管理
模型测试 报表测试：表内测试 、表间测试、总分测试
模型测试与报表测试是银行数据开发中保障数据质量的核心环节。
针对你提到的几个测试类型，以下是详细解释：
一、模型测试
模型测试 指的是对数据模型（如数仓分层模型、数据集市模型、风控模型）的逻辑正确性进行验证。
| 测试类型 | 测试内容 | 示例 |
|---|---|---|
| 模型结构测试 | 检查表的字段定义、数据类型、主外键约束是否符合设计文档 | DWD层贷款借据表的loan_amount字段应为decimal(18,2)，不能是varchar |
| 模型映射测试 | 验证源系统字段到目标模型字段的映射关系是否正确 | 源系统gender字段（M/F）映射到DWS层应为sex（男/女） |
| 模型逻辑测试 | 验证模型中的计算逻辑、派生字段是否正确 | 逾期天数 = 当前日期 - 应还款日期，需验证公式是否正确执行 |
| 模型性能测试 | 验证模型在大数据量下的查询响应时间、ETL执行时长 | 月结跑批是否能在4小时内完成 |
二、报表测试
报表测试 指的是对最终生成的业务报表或监管报表的数据准确性进行验证。
报表测试通常分为三个层次：表内测试、表间测试、总分测试。
1. 表内测试
定义 ：验证同一张报表内部，各字段之间的逻辑关系是否正确。
| 测试内容 | 说明 | 典型校验规则 |
|---|---|---|
| 横向合计 | 行内各列之和是否等于合计列 | 期末余额 = 期初余额 + 本期增加 - 本期减少 |
| 纵向合计 | 各行之和是否等于总计行 | 各分行贷款余额之和 = 全行合计 |
| 单个字段合理性 | 字段值是否在预期范围内 | 不良率应介于0%~100%之间 |
| 字段间勾稽关系 | 相关字段的逻辑一致性 | 利润表中的净利润 = 资产负债表中的未分配利润变动额 |
示例（EAST报表表内测试）：
text
校验规则：贷款金额 = 本金 + 利息
如果某条记录的 贷款金额 ≠ 本金 + 利息（允许误差范围内），则报错2. 表间测试
定义 ：验证不同报表之间，相同或相关数据项是否一致。
| 测试内容 | 说明 | 典型校验规则 |
|---|---|---|
| 跨报表一致性 | 同一业务实体在不同报表中的数据应一致 | EAST某贷款余额 = 1104报表对应贷款余额 |
| 跨系统一致性 | 不同系统来源的数据应一致 | 核心系统存款余额 = 总账系统存款科目余额 |
| 上下游一致性 | 数仓上下游表数据应一致 | DWS层客户日汇总表 = SUM(DWD层明细流水) |
| 监管口径一致性 | 同一业务在不同监管报表中应匹配 | EAST报送的贷款五级分类与客户风险系统一致 |
示例（一表通与EAST表间测试）：
text
校验规则：一表通客户信息表与EAST客户信息表记录数应一致
一表通客户数 = EAST客户数（允许差异阈值内）3. 总分测试
定义 ：验证汇总数据 与明细数据之间的总-分关系是否正确。
| 测试内容 | 说明 | 典型校验规则 |
|---|---|---|
| 总账←明细一致性 | 总账科目余额 = 对应明细账户余额之和 | 总账系统：1002银行存款科目余额 = 所有银行存款账户余额之和 |
| 汇总表←明细表一致性 | DWS层汇总值 = SUM(DWD层明细) | 客户日汇总表.当日总存款 = SUM(交易流水表.存款金额) |
| 报表合计←明细一致性 | 报表合计金额 = 明细清单金额之和 | 1104贷款总额 = 贷款明细清单.贷款金额总和 |
| 层级总分 | 上级机构数据 = 下级机构数据之和 | 省分行存款余额 = SUM(各市分行存款余额) |
示例（核心-总账总分测试）：
text
校验规则：核心系统日终存款余额总和 = 总账系统"吸收存款"科目余额
核心系统：所有个人/对公活期+定期账户余额 = 1000亿
总账系统：2001吸收存款科目余额 = 1000亿
→ 校验通过
如果不相等，需排查：是核心系统日切时间点问题？还是总账漏记了某笔流水？三、测试层次关系图
┌─────────────────────────────────────────────────────────────┐
│ 报表测试 │
├─────────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 表内测试 │ │ 表间测试 │ │ 总分测试 │ │
│ │ (单表逻辑) │ │ (跨表一致) │ │ (总-分核对) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 检查A表内部 检查A表=B表 检查总账=Σ明细 │
│ 借贷是否平衡 相关字段是否一致 汇总表=Σ流水 │
└─────────────────────────────────────────────────────────────┘四、实际工作中的应用场景
| 测试类型 | 适用场景 | 谁主要做 |
|---|---|---|
| 模型测试 | 数仓模型上线/变更、风控模型迭代 | 数据开发 + 数据测试 |
| 表内测试 | 单张报表开发完成、ETL任务上线前 | 数据测试 + 业务人员 |
| 表间测试 | 监管报送（EAST vs 1104一致性校验） | 监管报送团队 + 数据测试 |
| 总分测试 | 日终跑批核对、总账日结、月结 | 财务人员 + 数据测试 |
五、一句话总结
-
模型测试：验证"模型设计对了没"（结构、映射、逻辑、性能）
-
表内测试：验证"单张表自己没算错"（横行、竖行、合计）
-
表间测试：验证"多张表之间没打架"（跨表一致、跨系统一致）
-
总分测试：验证"汇总数跟明细数对得上"（总账=Σ明细、上层=Σ下层）
在银行监管报送（EAST、一表通）中，这三类测试是监管数据质量检核的核心手段，也是大数据开发人员日常工作中需要重点关注的内容。
报表可视化工具：帆软 长亮
帆软和长亮科技在报表可视化领域处于产业链上下游的协作关系 ：帆软是专业的报表与BI软件厂商，提供通用的可视化工具平台；
长亮科技则是金融行业解决方案服务商，更侧重于底层数据平台的搭建和治理，为上层可视化应用提供数据支撑。
两者的核心区别与联系如下：
| 维度 | 帆软 (Fanruan) | 长亮科技 (Sunline) |
|---|---|---|
| 核心定位 | 报表与商业智能（BI）软件厂商，以产品见长 | 金融行业IT解决方案提供商，以服务见长 |
| 主要产品 | FineReport、FineBI------以数据展示、交互分析和可视化大屏见长 | 数据资产管理平台、指标管理平台、大数据基础平台------以数据底层建设和治理为核心 |
| 擅长领域 | 复杂中国式报表、自助式数据分析、移动端/大屏可视化、数据填报 | 银行/金融核心系统、数据中台、数据湖仓建设、数据全生命周期治理（ETL、数据质量、指标统一管理） |
| 对企业的价值 | 让业务人员能直接看懂数据、自主分析，快速搭建管理驾驶舱，满足集团层面的战略、营销、财务、人力等可视化需求 | 帮企业管好数据底子，解决"数据孤岛"、口径不一致、响应速度慢等核心问题，让上层可视化有稳定、准确的数据来源 |
| 客户/案例 | 覆盖各行各业，尤其擅长制造、零售、医疗等多元领域，大型国企、民企均有广泛应用 | 深耕金融业，客户主要为银行、证券、财务公司等金融机构，如中国电财、北京某万亿级农商行 |
🤝 他们是怎么一起工作的？
在大型企业，尤其是金融机构的数字化转型项目中，常能看到两者身影，分工明确：
-
长亮科技负责"修路"：为企业搭建数据资产管理平台和数据中台。它会打通银行核心系统、信贷系统等数十个业务系统的数据，建立统一的数据标准和指标库，提供干净、可信的数据。
-
帆软负责"跑车"：基于长亮科技搭建好的数据平台，帆软的FineReport或FineBI工具可以快速连接这些数据，制作出面向最终用户的业务报表、高管驾驶舱或风险监控大屏。
简单来说，长亮科技解决了"数据从哪里来、质量好不好"的问题，而帆软解决了"数据怎么看得懂、用得快"的问题。
💡 选型建议
综合来看，你的选择取决于目前企业的核心痛点：
-
如果你的核心需求是"展示" ：需要快速制作漂亮、复杂的报表，搭建管理驾驶舱，让业务部门自己分析数据，那么帆软系列产品（FineReport/FineBI）是更直接、专业的选择。
-
如果你的核心需求是"治理" ：尤其在金融行业，面临数据标准不统一、来源复杂、质量差，导致报表没法做、不敢信，那么可能需要先引入长亮科技这样的厂商，把数据底座打好。
作业
第16题：银行的业务系统有哪些，都保存一些什么数据
银行业务系统是一个分工明确、协同运作的复杂体系。
为了更直观地理解，你可以把银行想象成一个大型商场：核心系统 是收银总台，信贷系统 是贷款柜台，信用卡系统 是会员卡管理中心，而渠道系统则是商场在各个楼层设置的收银机和自助服务终端。
以下是银行主要的业务系统及其核心数据：
一、银行核心业务系统全景
| 系统名称 | 核心功能 | 主要保存数据 | 通俗理解 |
|---|---|---|---|
| 核心系统 | 存款、取款、转账、账户管理等基础交易处理 | 客户账户余额、交易流水、存款账户信息、利率规则 | 银行的"收银总台"，记录每一笔资金进出 |
| 总账系统 | 会计核算、科目管理、报表生成 | 会计科目余额、会计凭证、资产负债表、利润表 | 银行的"会计部"，汇总所有账务 |
| 信贷管理系统 | 贷款审批、放款、贷后管理 | 贷款合同、借据信息、担保信息、还款计划、五级分类 | 银行的"贷款柜台"，管贷款的整个生命周期 |
| 信用卡系统 | 信用卡申请、审批、交易、分期、还款 | 信用卡账户、信用额度、交易流水、账单信息、分期记录 | 银行的"会员卡系统"，管信用卡业务 |
| 票据系统 | 票据承兑、贴现、转贴现 | 票据信息（票号、金额、期限）、承兑记录、贴现记录 | 银行的"票据交易所"，管票据业务 |
| 支付清算系统 | 跨行转账、资金清算 | 支付指令、清算明细、对账文件 | 银行的"快递系统"，负责资金跨行转移 |
| 渠道系统 | 网银、手机银行、ATM等客户服务渠道 | 客户操作日志、登录记录、交易流水 | 银行的"服务窗口"，客户直接接触的系统 |
二、各系统详细说明
1. 核心系统（Core Banking System）
核心定义：银行所有关键账务数据的"总账本"，是银行最核心的系统。
保存的主要数据：
-
客户信息：客户号、姓名、证件类型、证件号码、联系方式、地址等
-
账户信息：账号、账户类型（活期/定期）、开户机构、账户状态、余额
-
交易流水：每一笔存款、取款、转账的明细记录（含时间、金额、对手方）
-
利率规则：各类存款利率、计息规则
数据特征 ：要求强一致性，即扣款和入账要么同时成功，要么同时失败，绝不允许出现"钱扣了但没到账"的情况。
2. 总账系统（General Ledger System）
核心功能：银行的会计核算中心，负责汇总所有业务系统的账务数据，生成财务报表。
保存的主要数据：
-
会计科目余额：按财政部规范的一级科目（如1001现金、2001吸收存款）记录的余额
-
会计凭证：每一笔记账的借方、贷方科目及金额
-
报表数据：资产负债表、利润表、业务状况表等
3. 信贷管理系统
核心功能：管理贷款从申请到结清的全生命周期。
保存的主要数据：
-
贷款合同：合同编号、合同金额、利率、期限、担保方式、还款方式
-
借据信息：借据号、借据金额、余额、放款日期、到期日期、借据状态
-
担保信息：担保人信息、抵押物信息、质押物信息
-
还款计划表：每期应还日期、应还本金、应还利息
-
还款流水表：实际还款日期、还款金额、还款本金、还款利息
-
贷后管理：贷后检查记录、五级分类结果、风险预警信息
关系说明：一份合同 → 多张借据 → 多条还款流水（具体逻辑可回顾上一讲的表关系说明）
4. 信用卡系统
核心功能：管理信用卡从申请到还款的全流程。
保存的主要数据：
-
信用卡账户：卡号、账户状态（正常/冻结/销户）、开卡日期、有效期
-
信用额度：总额度、已用额度、可用额度、临时额度及有效期
-
交易流水：消费、取现、转账等交易的日期、金额、商户、交易类型
-
账单信息：账单日、到期还款日、本期应还总额、最低还款额
-
分期记录：分期类型（账单分期/消费分期）、分期金额、期数、手续费
-
还款记录：还款日期、还款金额、还款方式（自动还款/主动还款）
关键概念：账单日、到期还款日、最低还款额、免息还款期
5. 票据系统
核心功能：管理商业汇票的全生命周期。
保存的主要数据：
-
票据信息：票号、出票人、收款人、承兑人、票面金额、出票日期、到期日期
-
承兑记录：承兑行、承兑日期、保证金比例
-
贴现记录：贴现银行、贴现日期、贴现利率、实付金额
-
流转记录：背书转让、转贴现、再贴现的完整链路
6. 渠道系统（网银、手机银行、ATM等）
核心功能：为客户提供各类银行服务的接入渠道。
保存的主要数据：
-
用户操作日志：登录时间、操作类型、IP地址、设备信息
-
交易指令：客户发起的转账、缴费、理财购买等指令
-
渠道专属数据：如手机银行的设备绑定信息、指纹/面容识别信息
三、数据流向示意图
┌─────────────────────────────────────────────────────────────────┐
│ 业务数据流向 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 客户操作（手机银行/网银/ATM） │
│ │ │
│ ▼ │
│ 渠道系统（记录操作日志） │
│ │ │
│ ▼ │
│ 核心系统（更新账户余额、记录交易流水） ←─── 信用卡系统 │
│ │ （信用卡交易） │
│ ├──────────→ 总账系统（生成会计凭证、更新科目余额） │
│ │ │
│ └──────────→ 信贷管理系统（如果涉及贷款还款） │
│ │ │
│ └──────────→ 更新借据余额 │
│ │
│ 日终/月末 │
│ │ │
│ ▼ │
│ 数据仓库（ETL抽取各系统数据，加工监管报表） │
│ │
└─────────────────────────────────────────────────────────────────┘第17题：信用卡的业务流程大概有哪些
信用卡业务流程可以概括为**申请→审批→激活→消费→还款→（可选分期）**六个核心环节。
以下结合银行实际业务进行详细拆解：
一、信用卡业务全流程概览
二、各环节详细说明
1. 申请环节
流程：客户提交信用卡申请表，提供身份证明、收入证明、资产证明等材料。
涉及数据：客户基本信息（姓名、证件号、联系方式）、职业信息、收入情况、已有信用卡情况
系统：信用卡申请系统
2. 审批环节
流程：银行根据客户的征信报告、收入情况、已有负债等综合评估，核定信用额度。
审批要素：
-
信用记录：人行征信报告查询记录、逾期记录、贷款记录
-
还款能力：收入水平、职业稳定性、资产负债情况
-
已有额度：他行信用卡总额度、已用额度
涉及数据：征信报告信息、收入证明、资产证明、信用评级结果
产出：信用额度（银行根据客户资信情况核定的可循环使用的最高欠款限额）
系统：信用卡审批系统、征信系统
3. 制卡发卡环节
流程：审批通过后，银行制作实体卡并邮寄给客户。
涉及数据：卡号、有效期（通常3-5年）、卡片验证码（CVV/CVN2）
系统：制卡系统、物流系统
4. 激活环节
流程：客户收到卡片后，通过电话银行、手机银行、网点等渠道激活卡片，并设置查询密码和交易密码。
激活方式：
-
电话激活：拨打客服热线，按语音提示操作
-
手机银行激活：登录手机银行APP自助激活
-
网点激活：携带身份证和信用卡到柜台办理
涉及数据：卡片激活状态、查询密码、交易密码
系统：信用卡核心系统、渠道系统
5. 消费/取现环节
流程：持卡人在商户消费或ATM取现，银行记录交易信息。
关键概念：
-
交易日：持卡人实际用卡消费或取现的日期
-
银行记账日：银行将交易款项记入持卡人账户的日期
涉及数据：交易时间、交易金额、商户名称、交易类型（消费/取现）、交易渠道（POS/线上/ATM）
系统：信用卡交易系统、收单系统
6. 账单环节
流程：银行每月固定日期（账单日）汇总持卡人当期所有交易，生成账单。
关键概念：
-
账单日：银行每月对持卡人当期发生的各项交易、费用进行汇总结算，结计利息、计算应还款项的日期
-
到期还款日：持卡人应偿还全部应还款额或最低还款额的最后日期，通常为账单日后第25天
-
免息还款期：从银行记账日到到期还款日之间的周期，在此期间全额还款可免收透支利息
账单构成：
-
本期应还总额：截至账单日累计未还的交易本金、费用、利息的总和
-
最低还款额：持卡人应偿还的最低金额，通常为消费金额的10% + 取现本金 + 分期金额 + 费用利息
涉及数据：账单日、到期还款日、本期应还总额、最低还款额、交易明细清单
系统：信用卡账务系统
7. 还款环节
流程：持卡人在到期还款日前偿还欠款。
还款方式：
-
全额还款：偿还全部应还金额，享受免息期
-
最低还款：偿还最低还款额，剩余部分计收利息（通常日息万分之五）
-
自动还款：绑定本行借记卡，到期自动扣款
涉及数据：还款日期、还款金额、还款本金、还款利息、还款方式
系统：信用卡还款系统、核心系统（扣款）
8. 分期环节（可选）
流程：持卡人可将消费金额或账单金额申请分期偿还，银行收取手续费。
分期类型：
-
账单分期：对当期已出账单金额申请分期，最高不超过当期账单新增消费总额的90%
-
消费分期：对未出账单的单笔消费金额申请分期
涉及数据：分期金额、分期期数（3/6/12/24期等）、手续费率、每期应还金额
系统：信用卡分期系统
三、信用卡业务核心数据流转
┌─────────────────────────────────────────────────────────────────┐
│ 信用卡数据流转示意 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 客户刷卡消费 │
│ │ │
│ ▼ │
│ 收单系统/银联（记录交易信息） │
│ │ │
│ ▼ │
│ 信用卡核心系统（记账：增加交易流水、减少可用额度） │
│ │ │
│ ├──────────→ 信用卡账务系统（生成账单） │
│ │ │
│ └──────────→ 总账系统（生成会计凭证） │
│ │
│ 客户还款 │
│ │ │
│ ▼ │
│ 核心系统（扣款）→ 信用卡系统（更新余额、恢复额度） │
│ │
└─────────────────────────────────────────────────────────────────┘四、关键概念速查表
| 术语 | 定义 |
|---|---|
| 信用额度 | 银行根据持卡人资信情况核定的，持卡人可循环使用的最高欠款限额 |
| 账单日 | 银行每月汇总持卡人交易、计算应还款额的固定日期 |
| 到期还款日 | 持卡人应偿还欠款的最后日期，通常为账单日后第25天 |
| 免息还款期 | 从银行记账日到到期还款日之间的周期，全额还款可免息 |
| 最低还款额 | 持卡人应偿还的最低金额，通常为消费的10%+取现+分期+费用利息 |
| 违约金 | 到期还款日未还最低还款额时，需支付的费用 |
| 溢缴款 | 持卡人还款时多缴的款项或存放在信用卡账户内的款项 |