银行业务 | Tetuka的个人笔记

1. 银行主要的经营业务有哪些? 源系统有哪些?

主要经营业务：存款业务、贷款业务、中间业务、网银业务、银行卡业务、支付结算业务等。

源系统：CBS（核心业务系统）、NIB（新中间业务系统）、CLM（信贷系统）、EBS（网银系统）、FLM（农贷系统）、IBS（老中间业务系统）、SEP（二代支付系统）、CFE（老卡前置系统）、ATP（新卡前置系统）、NFT（银联系统）

2. 说明哈尔滨银行项目的硬件配置

生产硬件配置：

系统	服务器	型号	配置	数量
数据平台	数据库服务器	IBM P720	4C/32GB/2300GB硬盘/2个双口千兆以太网卡/2HBA卡	2台
数据平台	应用服务器	HP DL380	4C/128GB/2600G硬盘/2块双口千兆网卡/2HBA卡	2台

开发、测试硬件配置：

系统	服务器	型号	配置	数量
数据平台	数据库服务器	虚拟机	2C/8GB/300GB硬盘	2台
数据平台	应用服务器	虚拟机	2C/8GB/300GB硬盘	2台

3. 介绍哈尔滨银行项目各个项目阶段以及项目周期内主要工作

项目准备阶段：预计 2014 年 8 月 21 日至 2014 年 8 月 31 日。主要工作包括完成项目启动，明确项目目标、范围和各方职责，搭建项目团队，准备项目所需的办公环境、设备和资料等，为后续阶段的工作奠定基础。
需求分析阶段：预计 2014 年 8 月 25 日至 2014 年 11 月 14 日。乙方对甲方各个业务部门的需求进行评估、调研，编写需求分析文档；甲方将需求分析结果发回需求提出方进行签字确认，确保需求的准确性和完整性。
设计阶段：预计 2014 年 10 月 8 日至 2014 年 11 月 30 日。乙方根据需求分析结果进行架构设计、模块划分、数据探查、模型设计等工作，编写架构设计说明书、ETL 概要设计、前端概要设计等文档；甲方对概要设计进行评审并反馈意见。
开发阶段：预计 2014 年 10 月 27 日至 2015 年 1 月 11 日。乙方参照详细设计进行程序开发，包括 ETL 程序、报表程序等，并编写相关的配置文件；甲方对源代码进行评审。
测试阶段：预计 2015 年 1 月 5 日至 2015 年 3 月 8 日。乙方进行单元测试并编写单元测试文档，之后进行集成测试，确保系统各部分能协同工作；甲方提前至少 2 周申请测试数据，参与集成测试，对测试结果进行确认。
上线阶段：预计 2015 年 3 月 9 日至 2015 年 3 月 20 日。甲方保证生产设备到位，协调运维中心确保上线顺利进行；乙方按照上线步骤进行上线，提交上线部署方案和上线报告。
第一阶段现场维护阶段：预计 2015 年 3 月 23 日至 2015 年 4 月 30 日。乙方提供 2 人共计 1.5 人月现场维护，解决系统上线后出现的问题，保障系统稳定运行。
第二阶段：预计 2015 年 6 月 1 日至 2015 年 8 月 31 日。接入新信贷系统数据（不超过 130 张表），对整体架构模型进行扩展，修改汇总层、报表层程序，改造 63 张第一阶段信贷类报表，开发针对新信贷系统的数据反抽和分发程序，最终实现村行老数据平台下线。
第二阶段维护阶段：预计 2015 年 9 月 1 日至 2015 年 9 月 30 日。乙方提供 2 人共计 1.5 人月现场维护，确保第二阶段上线后系统的稳定运行。

4. 在需求调研阶段主要的工作内容有哪些，调研流程是什么

主要工作内容
- 乙方对甲方各个业务部门提出的需求进行评估，判断需求的合理性、可行性以及与项目目标的契合度。
- 乙方深入业务部门进行调研，了解业务流程、数据流向、报表需求等详细信息，收集相关资料。
- 乙方根据调研结果编写需求分析说明书，明确需求的具体内容、范围和业务规则等。
- 乙方整理源系统表清单，明确需要接入的数据来源和具体表结构。
- 乙方编写建表和配置文件的初步方案。
调研流程
- 甲方业务部门提出需求，传递给乙方。
- 乙方对需求进行初步筛选和评估，确定调研的重点和范围。
- 乙方组织与业务部门的沟通会议，通过访谈、问卷等方式进行详细调研。
- 乙方根据调研信息整理形成需求分析文档初稿。
- 乙方将需求分析结果反馈给甲方，甲方将其发回需求提出方进行签字确认。
- 若有修改意见，乙方根据意见进行调整完善，直至需求得到最终确认。

5. 数据缓冲层的作用,增量剥离操作的流程

数据缓冲层的作用：文档中未明确提及数据缓冲层，结合常见数据平台设计，数据缓冲层通常用于临时存储从源系统采集的原始数据，作为数据进入后续处理环节（如 ODS 层）前的过渡区域，可对数据进行初步的校验和整理，减轻后续处理层的压力，保证数据处理的稳定性和效率。
增量剥离操作的流程：根据对村行现有数据的分析，由于大部分数据无法提供每日增量，所以将源系统全量数据与 ODS 全量数据进行比对，找出源系统中发生变化和新产生的数据，作为当日增量数据。

6. 实施工作主要内容有哪些

数据源接入：第一阶段接入核心、老信贷、农贷等多个系统的多张表数据；第二阶段接入新信贷系统不超过 130 张表数据。
架构与模型设计：设计缓冲层、贴源层、基础层、汇总层、报表层的整体架构和数据模型，实现增量剥离、数据采集加载、历史拉链、按主题汇总等功能。
平台工具搭建：搭建调度平台（USE）、分发平台（FEX）、报表平台（RIDP）和报表工具（MSTR）的环境，包括资料库配置、开发和测试环境准备等。
程序开发：开发 ETL 程序用于数据的抽取、转换、加载和反抽；开发报表程序满足各业务部门的报表需求；开发数据分发程序为下游系统提供数据。
测试工作：进行单元测试、集成测试，确保程序功能正确、系统运行稳定，甲方参与测试并确认结果。
上线部署：制定上线部署方案，完成系统的上线工作，确保新系统顺利投入使用。
报表开发与改造：第一阶段开发 143 张报表，第二阶段改造 63 张第一阶段信贷类报表。
数据服务提供：实现数据反抽和分发，为下游系统提供每天增量数据。
老平台下线：在第二阶段完成村行老数据平台的下线工作，由新数据平台全面替代。

10. 简单描述哈尔滨银行业务源系统抽取流程

村镇银行各业务系统的数据，通过文本文件的形式采集到数据平台。ETL1 阶段读取源系统数据文件，对数据进行加工（包括数据采集，对部分数据质量有问题的数据进行处理；以及增量剥离，找出当日增量数据），然后将加工后的数据加载到 ODS 数据库。

11. 说明哈尔滨银行项目数仓分层以及各层功能,该项目主题有哪些?

数仓分层及各层功能：数据平台共由 SDM、ODM、FDM、MDM 四个层次组成。
- ODM（操作型数据存储）：贴近业务源系统，用于支持村行执行层的业务人员对业务数据的 T+1 的明细查询需求。
- SDM、FDM、MDM：实现对全行数据最快 T+1 的整合、数据历史的保留、以及按报表需求的汇总，用于支持村行管理层、决策层各位领导的日常综合运营分析、战略决策分析。其中，FDM、MDM 中客户、产品以及账户等数据信息永久保留且保留历史信息，交易类数据和汇总类数据保留 7 年。
项目主题：包括客户分析、渠道分析、存款分析、贷款分析、产品分析、绩效分析等。

12. 哈尔滨银行项目抽取报表数量,数据量大小,数据存储周期

抽取报表数量：共有201张报表需求，项目前期阶段实现前143张报表需求，待信贷系统上线后对后面的58张报表进行开发改造
数据量大小：本项目中，数据平台每月增量数据大约在 10G 左右。数据库表空间规划 200GB，数据文件存储空间规划 100GB，合计 300GB。
数据存储周期：
- ODM 中：源系统数据文件保留 7 天；客户、产品以及账户等数据信息保留最新数据信息，不保留历史；交易类数据保留 13 个月，13 个月前数据做归档，归档数据保留 1 年。
- FDM、MDM 中：客户、产品以及账户等数据信息永久保留，保留历史信息；交易类数据和汇总类数据保留 7 年，7 年以前数据做归档，归档数据保留 3 年。
- 数据分发平台中：反抽出的增量数据保留 7 天，7 天前数据进行归档，30 天前数据做物理删除。

13. 索引在什么情况下会失效?如何确认慢sql所在位置,以及定位后如何优化?

索引失效的情况
- 使用OR连接包含非索引列的条件，如WHERE idx_col1 = 1 OR col2 = 2（col2无索引）。
- 对索引列进行函数操作，例如WHERE SUBSTR(idx_col, 1, 2) = 'AB'。
- 使用不等于（!=、<>）、NOT IN、IS NOT NULL等操作符，如WHERE idx_col != 10。
- 索引列参与计算，如WHERE idx_col + 1 = 10。
- 字符串不加引号导致隐式转换，如WHERE idx_str_col = 123（实际应为字符串'123'）。
- LIKE以通配符开头，如WHERE idx_col LIKE '%abc'。
- 组合索引不满足最左匹配原则，如组合索引(a,b,c)，查询条件仅用b=1。
确认慢 SQL 位置的方法
- 数据库自带工具：如 MySQL 的slow_query_log（慢查询日志），可配置记录执行时间超过阈值的 SQL；Oracle 的AWR（自动工作负载仓库）报告、ASH（活动会话历史）报告，能定位消耗资源多的 SQL。
- 监控工具：如Percona Monitoring and Management（PMM）、Datadog等，可实时监控 SQL 执行耗时。
- 执行计划分析：通过EXPLAIN（MySQL）或EXPLAIN PLAN（Oracle）查看 SQL 执行计划，判断是否使用索引、是否全表扫描等。
慢 SQL 优化举例
- 场景：查询 “年龄大于 30 的用户姓名”，表user有索引idx_age，但 SQL 为SELECT name FROM user WHERE age + 1 > 31，此时索引idx_age失效，执行全表扫描。
- 优化：修改 SQL 为SELECT name FROM user WHERE age > 30，使索引idx_age生效，减少扫描行数。

14. 异常压制在什么情况下使用?游标在什么情况下使用?举实际代码案例

异常压制的使用场景：当某个异常发生时，不希望程序中断，且该异常对整体流程影响较小，可压制异常并记录日志以便后续分析。例如，在批量处理数据时，个别记录格式错误，可跳过错误记录继续处理其他数据。
游标使用场景：需要逐行处理查询结果集时使用，适用于结果集较小、需复杂逻辑处理单行数据的情况。例如，遍历查询出的订单记录，逐行计算订单金额并更新到另一张表。

代码案例

异常压制（Python）

import logging

data_list = ["123", "45a", "789"]  # 包含异常数据"45a"
result = []
for data in data_list:
    try:
        num = int(data)
        result.append(num)
    except ValueError as e:
        # 压制异常，记录日志后继续处理
        logging.warning(f"数据'{data}'转换失败：{e}")
        continue
print("处理后结果：", result)  # 输出：处理后结果： [123, 789]

游标（MySQL 存储过程）

DELIMITER //
CREATE PROCEDURE UpdateOrderAmount()
BEGIN
    DECLARE order_id INT;
    DECLARE total_amount DECIMAL(10,2);
    DECLARE done INT DEFAULT 0;
    -- 声明游标
    DECLARE order_cursor CURSOR FOR 
        SELECT id, quantity * price FROM order_item;
    -- 处理游标结束
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
    
    OPEN order_cursor;
    -- 遍历游标
    read_loop: LOOP
        FETCH order_cursor INTO order_id, total_amount;
        IF done THEN
            LEAVE read_loop;
        END IF;
        -- 逐行更新订单总金额
        UPDATE order SET total = total_amount WHERE id = order_id;
    END LOOP;
    CLOSE order_cursor;
END //
DELIMITER ;

15. 如何处理不同类型的重复数据?各种类型数据缺失如何处理?

重复数据处理
- 完全重复数据（所有字段均相同）：直接删除重复记录，保留一条。例如，表student中存在两条完全相同的记录，可执行DELETE t1 FROM student t1 JOIN student t2 ON t1.id > t2.id AND t1.name = t2.name AND t1.age = t2.age（假设id为唯一标识）。
- 部分字段重复（关键信息重复，其他字段不同）：根据业务规则合并。例如，用户表中同一手机号对应多条记录，可合并为一条，取最新的注册时间和状态。
- 逻辑重复（因数据标准不统一导致的重复）：先标准化数据，再去重。例如，“北京” 和 “北京市” 视为重复，先统一为 “北京市”，再删除重复项。
数据缺失处理
- 数值型缺失
  - 均值 / 中位数填充：适用于近似正态分布的数据，如用 “用户平均年龄” 填充缺失的年龄值。
  - 众数填充：适用于有明显集中趋势的数据，如用 “最常见的职业” 填充缺失的职业值。
  - 插值法：如时间序列数据，用前后时间点的数值插值填充缺失值。
- 分类型缺失
  - 众数填充：用出现频率最高的类别填充，如用 “汉族” 填充缺失的民族值。
  - 特殊值填充：用 “未知”“N/A” 等标识缺失，适用于无法确定合理值的场景。
  - 基于业务规则填充：如 “性别” 缺失，可根据 “名字” 中的常见性别特征推测（如 “张伟” 推测为男性）。
- 文本型缺失：根据上下文填充，或用 “无内容” 标识；若为重要信息（如地址），可联系数据提供方补充。
- 时间型缺失：用默认时间（如 “1970-01-01”）填充，或根据相关事件时间推导（如订单创建时间缺失，用支付时间减合理间隔填充）。

16. 简述拉链表的存储过程流程

从源系统获取增量数据或全量数据。
将源数据与拉链表中当前有效的数据进行比对，识别出新增、修改和删除的数据。
对于修改的数据，将拉链表中对应记录的结束时间更新为当前日期的前一天，标记其失效。
将新增的数据和修改后的数据作为新记录插入到拉链表中，设置其开始时间为当前日期，结束时间为一个默认的最大日期（如 9999-12-31），表示当前有效。
对于删除的数据，将拉链表中对应记录的结束时间更新为当前日期的前一天，标记其失效。
记录拉链表的更新日志，包括操作时间、操作类型、影响记录数等信息，以便后续追溯和监控。