用故事的形式，讲一个银行柜员的一天，帮助我理解业务

已思考（用时 3 秒）

我们要求用故事形式讲银行柜员的一天，帮助理解业务。需要生动具体，涉及柜员日常操作、与客户交互、核心系统使用、交易类型等。要体现银行业务流程，比如存取款、转账、开户、销户、挂失、对公业务等。同时可以穿插柜员内部管理（日终轧账、凭证核对）。故事要真实可信，适合初学者理解银行基础业务。

故事：银行柜员小陈的一天

这个故事帮你理解：银行柜员到底在忙什么？每一笔业务背后，系统里发生了什么？

早上 8:00 到岗

小陈，25岁，在杭州某支行做现金柜员，入职刚满一年。

早上8点，她准时到网点。第一件事：签到。

她插上柜员卡，输入密码，登录核心系统。系统记录：柜员号 C10086，登录时间 08:05:23，设备号 柜面终端05。

数据视角：核心系统的柜员操作日志表会新增一条记录。

然后她和主管一起开现金尾箱——她负责的那个钱箱子。里面有多少钱，要一张一张点清楚，和系统里的“尾箱余额”对上。

今天尾箱余额是 20 万整。点完确认，签字。

数据视角：核心系统的尾箱交接表记录：柜员号、交接时间、现金金额。

上午 9:00 开始营业

卷帘门升起，第一个客户走进来。

业务一：李阿姨存定期

李阿姨，60多岁，拿着一包现金，大概8万块，说：“小陈啊，我要存个定期，三年的。”

小陈接过现金，先过点钞机，两遍，确认金额 82,000 元。

然后问李阿姨要身份证和银行卡。身份证一刷，系统自动带出客户信息：姓名、证件号、住址。

她在核心系统里操作：选择“定期存款” → 输入金额 82,000 → 选择“三年期” → 利率 2.35% → 打印凭证。

李阿姨签字。小陈把钱收进钱箱，把存单和身份证递回去。

数据视角：

  • 客户信息表（无变化，已有记录）

  • 存款账户表：新增一个定期子账户，账号 8888-...-001，余额 82,000，利率 2.35%

  • 交易流水表：新增一条，交易类型“定期存入”，金额 82,000

  • 柜员交易统计表：小陈的“存款笔数+1，存款金额+82,000”

业务二：王老板对公转账

王老板是附近一家小公司的财务，来给供应商付货款 50 万。

他递来一张转账支票和一张汇款单。收款方是上海某公司。

小陈先核验支票：印鉴（公章、财务章、法人章）对不对？她调出系统里预留的印鉴影像，一张一张比对。没问题。

然后在核心系统里录入：付款账号（王老板公司账户） → 收款户名、开户行、账号 → 金额 500,000 → 用途“货款”。

系统提示：需要主管授权。因为单笔超过 20 万。

主管过来，插卡、输密码、指纹确认。授权通过。

小陈打印回单，王老板签字，业务完成。

数据视角：

  • 交易流水表：新增一条对公转账记录，金额 50 万

  • 该公司的存款账户余额减少 50 万

  • 柜员交易统计表：转账笔数+1，转账金额+50 万

  • 授权记录表：主管授权流水

业务三：张大爷忘记密码

张大爷快 80 岁了，记性不好，银行卡密码忘了。

小陈引导他：请您输一下密码……三次错误后，系统锁定。

她对张大爷说：“大爷，密码锁了，我帮您重置。您带身份证了吗？”

张大爷递过身份证。小陈刷一下，系统显示客户信息，她核验照片和本人是否一致。

然后操作：密码重置 → 打印凭证 → 张大爷签字 → 新密码在密码键盘上输入两次。

数据视角：

  • 核心系统的客户认证表中，密码标志位更新

  • 操作日志会记录“密码重置”事件，便于审计

中午 12:00 轮班吃饭

小陈点了一下自己现金尾箱里的钱，和系统里的尾箱余额对一下——这叫“中午碰库”。

没问题，锁箱子，去吃饭。

数据视角：中午碰库记录，现金账实相符。

下午 14:00 继续营业

业务四：小刘办信用卡

小刘，26岁，程序员，想办一张信用卡。

小陈说：“我们网点不能直接办卡，但可以帮您填申请资料。”

她打开信用卡申请界面，帮小刘录入：姓名、身份证号、手机号、单位名称、年收入、学历。再让小刘授权查询征信。

提交后，系统返回“申请已受理，审批结果会短信通知”。

数据视角：

  • 信用卡申请系统新增一条申请记录

  • 征信查询系统记录一次“信用卡审批”查询，归到客户名下

业务五：赵女士取钱，卡忘带了

赵女士急急忙忙：“我卡忘带了，能取钱吗？”

小陈说：“可以的，您记得卡号吗？或者用手机银行扫码也行。”

赵女士掏出手机，打开手机银行，生成一个取款二维码。小陈的柜面扫描枪一扫，系统弹出赵女士的账户信息。

取款 5,000 元，小陈点钞、递给赵女士。

数据视角：

  • 交易流水表：取款 5,000

  • 手机银行与柜面系统联动，记录“扫码取款”事件

下午 17:00 关门，开始扎帐

卷帘门拉下。小陈一天的业务数据汇总出来了：

统计项 数量
总交易笔数 87 笔
现金收付总额 120 万元
转账金额 320 万元
信用卡申请 3 笔

她开始日终扎帐：

  1. 现金尾箱盘点：把剩余现金所有面额点一遍，和系统里的“尾箱余额”对。今天支出多，尾箱余额从早上 20 万变成 6 万，对得上。

  2. 凭证盘点：每一张存单、回单、支票，都要和系统里的流水一一核对。少一张都不行。

  3. 打印结账单：系统生成柜员日结单，小陈签字。

主管复核，没有问题，她可以下班了。

数据视角：

  • 核心系统的柜员日结表：记录小陈今天的交易汇总

  • 总账系统：当天所有业务生成的会计凭证，汇总后更新科目余额

晚上 19:00 系统跑批

小陈下班了，但银行的系统还在工作。

核心系统开始日终批量处理：

  • 计算当日所有存款利息

  • 更新账户余额

  • 生成会计流水给总账系统

  • 把当天的交易数据导出到数据仓库

数据视角：ETL 任务启动，核心系统数据被抽取到 ODS 层。

反洗钱的幕后

假设刚才王老板那笔 50 万转账，触发了反洗钱规则——比如他的公司平时月流水只有 5 万，突然转出 50 万，且收款方是异地一家“咨询公司”。

系统会自动标记为“可疑交易”，生成一个预警任务。第二天，支行的反洗钱专员会看到这个任务，决定是否上报。

数据视角：反洗钱系统扫描交易流水，匹配规则后写入可疑交易报告表。

柜员小陈的一天，对应到你的数据开发工作

业务场景 产生的数据 你平时会取哪张表
客户存款 存款账户余额变化、交易流水 存款账户表、交易流水表
客户取款 同上 同上
转账 付款方账户减少、收款方增加 对公/对私转账流水表
办卡 信用卡申请记录、征信查询记录 信用卡申请表、征信查询记录表
密码重置 认证信息变更日志 客户认证表、操作日志表
日终扎帐 柜员日结单、现金/凭证盘点 柜员日结表、尾箱交接表
反洗钱预警 可疑交易报告 可疑交易报告表

一句话总结

柜员的一天，就是核心系统里不断更新账户余额、生成交易流水、打印凭证、日终核对的过程。你作为大数据开发，拿到的数据就是从这些操作里产生的——每一笔存取款、每一次转账、每一张办卡申请，都会变成表里的一条记录。

你想听什么别的银行岗位的故事？比如客户经理怎么拉存款，或者信贷审批员怎么审贷款？

用故事的形式，讲一个银行行长的一天，帮助我理解业务

已思考（用时 2 秒）

我们需要用一个故事形式，讲述银行行长的一天，帮助理解业务。行长视角不同于柜员，涉及管理、经营指标、风险、监管、员工、客户等。要生动且包含数据、业务逻辑。

故事：支行行长老周的一天

这个故事帮你理解：银行行长不看柜员怎么点钞，他看什么？每一分钟他做的决定，背后对应什么业务和数据？

老周，48岁，杭州某股份制银行支行行长，管着80多号人，存款规模30多亿，贷款余额20多亿。他每天不是坐在办公室喝茶，而是开会、盯数据、跑客户、应付检查。

早上 7:30 看手机：经营快报

老周醒了第一件事：打开手机银行（行长版）。

屏幕上跳出几个核心指标：

指标 今日（较上日） 本月累计 年度目标
个人存款 +320万 +1.2亿 15亿
对公存款 -800万 -5000万 12亿
个人贷款 +150万 +8000万 8亿
对公贷款 +2000万（明天放） +1.5亿 10亿
不良贷款余额 1.2亿 - ≤1亿
中间业务收入 12万 320万 2000万

老周眉头一皱：对公存款今天掉了800万。肯定是哪个大户转走了钱。

他马上打电话给对公团队负责人：“老刘，XX集团那笔3000万理财到期了？我看存款掉了，赶紧去维护，别让人家把钱转走。”

数据视角：核心系统的存款账户余额日变化，会实时汇总到行长驾驶舱。大额变动触发预警。

早上 8:15 晨会：指标拆解

全体员工列队。老周站在前面，不多废话：

“同志们，本月对公存款还差5000万，个人贷款还差2000万。今天是10号，还有20天。”

他转向客户经理：

  • “小张，你那个XX科技公司的流贷什么时候放？跟紧。”

  • “王姐，XX园区那个新客户，开户了吗？今天必须开，开完马上进账。”

数据视角：客户经理的“营销通”App里，每个人的存款、贷款、中收完成进度实时排名。老周手里的报表就是汇总。

上午 9:30 见大客户：XX集团财务总监

XX集团是支行最大的对公客户，存款常年1个亿以上，贷款5000万，每年结算流水几十亿。

财务总监李总来了，坐进老周办公室。

李总：“周行长，我们总部要求降低融资成本，你们那笔流贷利率能不能从4.0降到3.7？另一家银行给的报价更低。”

老周心里快速盘算：这5000万贷款，利率降0.3%，一年少收15万利息。但如果不降，客户可能流失，连带存款、结算全跑掉。

他笑着说：“李总，我马上跟分行沟通，争取最优条件。另外我们行最近有个结构性存款，收益比普通理财高0.5%，您那笔闲置资金放进去，一年能多赚……”

最后达成：贷款利率微调，但客户多买2000万理财。

数据视角：贷款定价涉及 FTP（内部资金转移定价）、存贷利差、客户综合贡献度（存款+结算+理财）。老周最终要确保“客户不亏钱，银行不亏本”。

上午 11:00 审贷会：不良贷款处置

会议室里，信贷主管、风险经理、客户经理一起讨论一笔逾期贷款。

借款人：某小房地产公司，贷款2000万，抵押物是两块地。

逾期180天，五级分类已经“次级”（后来变成“可疑”）。借款人跑路了，抵押物的评估价只有1500万。

老周问：“法律程序走到哪了？查封没？”

风险经理：“法院已经查封，马上拍卖。但流拍风险大，底价打八折可能只有1200万。”

老周：“那就是至少亏800万。上报分行核销，同时继续追索担保人。”

数据视角：贷款五级分类、拨备覆盖率、不良率、核销额度，每个数字都直接影响支行KPI和老周的绩效。

中午 12:30 陪客户吃饭，聊发工资代发

老周中午没闲着，请一家制造业企业的老板吃饭。

企业有500个工人，每月发工资300万。老板现在用的是另一家银行代发。

老周：“王总，您把代发转到我们行来。我给您的人开卡免费，手机银行转账免手续费，还能给工人提供小额消费贷，利率优惠。”

王总犹豫。

老周再加码：“您那笔1000万贷款到期后，我帮您申请续贷，利率再优惠0.2%。”

王总动心了：“行，下个月开始逐步转。”

数据视角：代发工资是银行最稳定的低成本存款来源。一个代发客户，后续能衍生信用卡、消费贷、理财等一堆业务。客户经理的考核里，“新增代发”权重很高。

下午 14:30 监管检查：EAST数据质量

分行合规部通知：监管明天要来检查EAST数据质量。

老周赶紧召集运营主管、科技专员：“上月EAST报送的数据，客户信息表、借据表、交易流水表，都核对了吗？千万别出交叉校验错误。”

科技专员：“已经跑过检核脚本，但大额风险暴露那张表有点问题，部分客户关联方没识别全。”

老周：“今天必须改完，明天检查不能出岔子。上次隔壁支行被罚了80万，我们丢不起这人。”

数据视角：EAST报送的70多张表，任何一张表的字段错误、逻辑矛盾，都会触发监管问题单，轻则通报，重则罚款。

下午 16:00 网点巡视：柜面服务

老周去营业厅转一圈。

看到大堂经理在帮一位老人用智能柜员机。他凑过去：“老人家，办理什么业务？”

老人：“我想转5万块钱给我孙子。”

老周点点头，提醒大堂经理：“做一下风险提示，别是诈骗。”

回到办公室，他调出网点服务数据：今天平均等待时间12分钟，比上个月长了2分钟。他打电话给运营主管：“加开一个弹性窗口，排队别超过10分钟。”

数据视角：网点运营数据包括：客户等待时长、满意度、业务量、柜员差错率，全行排名，直接影响支行考核。

下午 17:30 盯数据：今日收官

老周打开电脑，看支行今日经营数据：

  • 存款：个人日增650万，对公日减300万（因为之前那笔800万今天确认是理财到期转走，但另外补了500万新资金），净增350万。

  • 贷款：个人消费贷放了80万，企业流贷放了2000万（明天到账）。

  • 中收：卖理财赚手续费15万，保险代销5万。

  • 不良：无新增逾期。

松了口气。他更新明天的晨会材料。

数据视角：每日经营快报由核心系统 + 总账系统 + 信贷系统聚合而成，ETL在日终跑批后生成。

晚上 19:00 应酬：维护关系

老周今晚约了区里的金融办主任吃饭。

席间聊到：区里要建一个产业园，需要20亿贷款。老周赶紧表态：“我们行全力支持，马上组织团队跟区里对接。”

回到家用手机发微信给公司部：“盯紧产业园项目，别让其他支行抢了。”

数据视角：政府项目贷款通常涉及银团、项目融资、长期基建贷款，对支行未来几年的对公存款、贷款、中收影响巨大。这种“储备项目”在行内系统里记为意向授信，后期逐步落地。

晚上 22:00 到家

老周洗澡时还在想：明天分行行长要来调研，汇报材料得突出普惠金融、服务小微的亮点。

他打开手机备忘录，写下三个要点：

  1. 普惠小微贷款增速 18%，高于全行平均

  2. 首贷户新增35户

  3. 线上小微贷款占比提升到40%

数据视角：这些汇报素材全部来自数据仓库中营销集市、普惠金融报表。

小陈（柜员）和老周（行长）的一天对比

维度 柜员小陈 行长老周
核心系统里 操作账户、交易流水 看汇总报表、经营快报
关心什么 每笔业务不错、账实相符 存款、贷款、中收、不良、监管合规
看的数据粒度 单笔交易、单个客户 支行级、团队级、产品级汇总
压力来源 客户满意、现金正确 KPI、监管、同业竞争
一天中接触数据次数 几百次（每笔业务） 几十次（看报表、听汇报、盯预警）
下班后 扎完帐下班 应酬、写材料、接电话

从大数据开发的角度，行长要的数据长什么样？

行长手机上的“经营快报”，本质上是数仓DWS/ADS层加工出来的：

sql

-- 简化的快报SQL示例
SELECT 
  分行号,
  存款余额_个人,
  存款余额_对公,
  贷款余额_个人,
  贷款余额_对公,
  不良贷款余额,
  中收_理财,
  中收_保险
FROM ads_branch_daily_snapshot
WHERE 统计日期 = CURDATE()

快报背后的ETL任务：

  • 日终（22:00）核心系统日切完成

  • 22:30 数据抽取到ODS

  • 23:00 DWD清洗

  • 23:30 DWS汇总（按支行+产品+日期）

  • 00:30 ADS生成快报宽表

  • 01:00 推送到行长App

这样，老周每天早上7:30睁眼，就能看到最新的经营数据。

行长的一天，就是盯指标、追客户、控风险、迎监管、带队伍。而他做的每一件事，最终都体现在数据里——存款涨了、贷款放了、不良降了、监管过了。

你作为大数据开发，写的每一行ETL代码，最终都会出现在老周的手机屏幕上，影响他的判断和决策。

还想听哪个岗位的故事？比如风险经理怎么查贷后，或者客户经理怎么跑业务？

风险经理怎么查贷后

已思考（用时 1 秒）

我们继续用故事形式，讲一个银行风险经理的贷后检查工作。帮助理解贷后环节有哪些数据、哪些表、哪些风险点。

故事：风险经理老吴的贷后检查

这个故事帮你理解：贷款放出去之后，风险经理怎么盯着借款人，防止出问题。每一笔监控背后，都有对应的数据和表。

老吴，45岁，在某银行分行风险管理部做贷后管理岗。他不管放贷款，专门负责查“钱借出去之后，企业有没有出问题”。

他手上有120笔对公贷款，总额8个亿，分布在制造业、批发零售、建筑业等行业。

早上 9:00 打开系统：跑批出来的风险预警

老吴到工位第一件事：打开贷后管理系统。

系统已经跑完夜间批量任务，生成了今天的预警清单。老吴的待办里有7条预警：

客户名称 预警类型 预警内容 风险等级
XX科技公司 资金流向异常 放款后第3天，500万转入小额贷款公司 高
XX建材厂 征信变化 企业征信显示他行贷款逾期30天 高
XX贸易公司 财务异常 纳税申报收入同比下降65% 中
XX食品厂 经营异常 工商显示企业列入经营异常名录 中
XX服装公司 抵押物变化 抵押的厂房被法院查封 高
XX工程公司 结算异常 基本户连续3个月无经营流水 中
XX汽配厂 关联风险 担保人（老板）个人征信出现逾期 中

数据视角：这些预警来自多个数据源的交叉比对——交易流水表、征信解析表、税务数据、工商数据、抵押物状态表、担保人征信表。

老吴先处理高风险的，点开第一条：XX科技公司。

第一单：资金流向异常

预警详情

XX科技公司，贷款500万，用途是“采购原材料”。

放款日是3月10日。3月13日（放款后第3天），企业账户分4笔、每笔100-150万，转给了“XX小额贷款有限公司”。还有一笔50万转给了“XX投资咨询部”。

数据视角：交易流水表里，放款日之后的交易对手字段，命中关键词“小贷”“投资咨询”。

老吴皱眉头：这明显不是买原材料，钱去了小贷公司，很可能拿去以贷养贷——借银行的钱去还其他借款。

老吴的动作

  1. 查交易对手：XX小额贷款有限公司，是本地一家民间借贷机构，不是银行名单里的正规小贷公司。老吴判定：风险极高。

  2. 联系客户经理：老吴打电话给管户的客户经理小张：“XX科技那笔贷款，资金流向查了吗？钱转到小贷公司了，你知不知道？”

小张慌了：“我…我还没查流水…”

老吴：“马上联系企业老板，问清楚钱去哪了。今天之内给我书面说明，明天我去现场检查。”

  1. 在系统里上报：老吴在贷后管理系统里，把这条预警升级为“重大风险事件”，推送给了信贷审批部和分行风险总监。

  2. 采取措施：老吴申请冻结该企业未使用的授信额度，并暂停其新的用信申请。

数据视角：预警处理过程中，系统记录每一步操作——谁处理的、什么时间、采取了什么措施。最终可能形成贷款流向预警结果表的一条记录。

第二单：征信变化 + 担保人逾期

老吴接着处理第二高风险的：XX建材厂。

预警详情

企业的征信报告显示：在他行有一笔经营贷，本金100万，已经逾期32天。同时，这笔贷款的担保人（老板个人）的征信也出现了信用卡逾期。

数据视角：征信数据表里，逾期天数>30 触发规则。同时关联担保关系表，查到担保人客户号，再去查担保人的征信，发现也有逾期。

老吴心里有数了：企业现金流已经出问题，连他行的贷款都还不上了，还本行贷款大概率也会出风险。

老吴的动作

  1. 调阅企业近期流水：他发现企业基本户最近三个月，每月进账从原来的300万降到50万左右。客户经理之前报的“经营正常”明显有问题。

  2. 电话沟通：老吴直接打电话给企业财务：“李总，我们看到你在他行的贷款逾期了，是什么情况？我们的贷款马上也要到期了，能正常还吗？”

财务支支吾吾：“最近资金有点紧，我们正在跟那家银行谈展期。你们的贷款…可能也要晚几天。”

老吴：“我们行不允许展期，到期不还就进不良。您尽快想办法。”

  1. 调整五级分类：老吴在信贷系统里，建议将这笔贷款的五级分类从“正常”调整为“关注”。

  2. 催收准备：老吴通知资产保全部，提前介入，准备催收材料。

数据视角：五级分类调整后，借据表的五级分类字段更新。这个变化会影响不良贷款余额、拨备覆盖率等监管指标，也会在EAST报送中体现。

第三单：抵押物被查封

老吴处理第三单：XX服装公司。

预警详情

这家企业贷款800万，抵押物是老板名下的一栋厂房。工商信息和司法数据里显示，该厂房被法院查封了。

数据视角：司法拍卖、查封数据来自外部接口（如企查查、法院公告），与抵质押物信息表里的押品编号比对，状态变化触发预警。

老吴的动作

  1. 核实查封原因：打电话问企业老板。老板说是因为跟供应商有合同纠纷，被起诉了，厂房被查封了。

  2. 评估抵押物价值：老吴调阅当初的评估报告，抵押物评估价1200万，抵押率66%。查封后，变现难度大增，银行作为抵押权人，虽然优先受偿，但要走法律程序，耗时很长。

  3. 要求追加担保：老吴要求企业提供新的抵押物或增加担保人。企业说没有。

  4. 上报风险：老吴判断，这笔贷款虽然没有立即逾期，但第二还款来源（抵押物）已经出问题，风险较高。他建议将五级分类调整为“次级”。

数据视角：抵质押物信息表里，押品状态字段更新为“查封”。担保关系表里，该抵押物对贷款的保护能力下降。

中午 12:00 写报告

老吴一上午处理了3个高风险预警，还有一个中风险的XX贸易公司——纳税收入下降65%，属于经营恶化。他给客户经理发了个任务：要求一周内提供企业最近一期财务报表和纳税申报表。

他打开Word，开始写贷后检查报告：

  • 检查时间：2025年5月23日

  • 检查方式：非现场监测（系统预警+数据分析）

  • 发现主要风险点：

    1. XX科技公司贷款资金违规流入小贷公司，已要求限期整改

    2. XX建材厂他行逾期+担保人逾期，建议下调五级分类至关注

    3. XX服装公司抵押物被查封，建议下调五级分类至次级并追加担保

  • 后续措施：下周现场检查、冻结额度、启动催收

数据视角：贷后检查报告会存储到贷后检查表，关联对应的合同号或客户号。

下午 14:00 现场检查

老吴下午去一家制造业企业做现场检查（每季度至少一次）。这家企业贷款2000万，目前还款正常，但属于“潜在风险客户”（行业景气度下降）。

到企业后，老吴做三件事：

1. 看生产现场

  • 车间里机器在转吗？工人多不多？（如果冷冷清清，说明停产了）

  • 今天看到机器在转，工人大概30-40人，正常。

2. 问老板

  • “最近订单怎么样？”

  • “上游原材料涨价，对我们利润有影响，但还能扛住。”

  • “他行贷款有续贷吗？”

  • “都正常续了，没问题。”

3. 对账

  • 老吴拿出企业的银行流水（他从行里打印的），跟企业的账本对一下。

  • 发现：企业报的“月销售收入500万”，但银行流水里进账只有300万。

  • 老吴问：“这个差异怎么回事？”

  • 老板解释：“有一部分走的是老板个人卡……”

  • 老吴警惕：个人卡收款，说明企业在避税，资金流不透明，风险增加了。

数据视角：现场检查后，老吴要在系统里填写贷后现场检查表，记录检查结论、发现的问题、整改要求。

下午 16:30 回到行里，写检查报告

老吴把现场检查的情况录入系统：

  • 客户名称：XX制造有限公司

  • 检查日期：2025-05-23

  • 检查人员：吴XX

  • 检查结论：生产经营基本正常，但存在通过个人卡收款现象，资金流不透明

  • 风险评级：中风险（维持）

  • 后续措施：要求企业逐步规范财务，下季度复查个人卡资金情况

下午 17:30 总结今日工作

老吴今天的贷后工作成果：

工作项 数量
处理系统预警 7条
其中高风险 3条（已上报、调整分类）
现场检查企业 1家
发现新问题 1个（个人卡收款）
撰写检查报告 2份
通知客户经理跟进 3项

他关掉电脑，心想：明天还有两家企业的现场检查要跑。

风险经理老吴的一天，对应到你的数据开发工作

老吴的工作 背后的数据表 你作为数据开发要做什么
看资金流向预警 交易流水表、放款流水表、公检法/小贷名单表 写ETL：关联流水和名单，命中则生成预警
查征信变化 征信解析表（DWD层） 清洗征信数据，标准化逾期天数、五级分类
盯抵押物状态 抵质押物信息表、外部司法接口表 每日比对押品状态变化，状态变更则触发预警
调阅企业流水 存款账户表、交易流水表（DWD层） 提供按客户、按时间段的流水查询接口
调整五级分类 借据表、贷款合同表 提供更新五级分类的接口，记录调整日志
写贷后检查报告 贷后检查表 提供报告录入和查询功能

一句话总结

风险经理老吴的工作，就是每天对着数据找问题——资金流没去该去的地方、征信变差了、抵押物被查封了、企业经营恶化了。只要数据里有异常，他就要追到底。你写的ETL、你建的预警规则、你维护的数据质量，就是他手里的“放大镜”和“照妖镜”。

你还想听哪个角色的故事？比如客户经理怎么跑业务拉存款，或者反洗钱专员怎么查可疑交易？

客户经理怎么跑业务拉存款

已思考（用时 3 秒）

我们需要设计一个故事，讲客户经理如何拉存款。故事要生动，包含具体场景、数据视角（对应什么表、什么数据）。客户经理的主要业务：对公存款、个人存款、理财产品销售、代发工资等。可以设计一个客户经理小王的典型一天或一段时期的经历。注意结合银行数据开发视角，说明产生的数据、使用的系统。长度适中。

故事：客户经理小王拉存款

这个故事帮你理解：银行的存款从哪里来？客户经理每天都在忙什么？每一笔存款背后，系统里发生了什么？

小王，28岁，某银行支行的对公客户经理。入行3年，手上管着50多个企业客户，存款任务一年1个亿。

他每天不是在客户那里，就是在去客户的路上。

背景：存款为什么重要？

银行靠贷款赚钱，但贷款的钱从哪里来？从存款来。

存款是银行的“原材料”。没有存款，银行就没钱放贷。

所以每个客户经理头上都压着存款指标。完不成，扣绩效、扣奖金、影响晋升。

小王今年的存款任务是日均存款新增8000万。他目前完成了6000万，还差2000万，时间还剩2个月。

第一幕：存量客户维护——别让存款流失

早上 9:00 打开系统，看客户资金变动

小王到工位第一件事：打开客户关系管理系统（CRM）和核心系统。

他先看今天的“大额资金变动提醒”：

客户名称 账户余额（昨日） 今日流出 今日流入 当前余额 备注
XX科技公司 800万 500万 0 300万 大额转出
XX贸易公司 200万 0 150万 350万 货款到账

小王看到XX科技公司转走了500万，心头一紧。

他马上打电话给这家公司的财务：

“李姐，我看你们账户今天转走500万，是有什么大额支付吗？我们行最近有个通知存款利率挺高的，钱放着别浪费啊。”

李姐：“哦，那是付给供应商的货款。不过下个月还有一笔800万的回款会进来，到时候找你。”

小王松了一口气：不是流失，是正常支付。但提醒自己要盯紧，别让钱被别的银行挖走。

数据视角：核心系统每天生成大额交易流水表，CRM系统会推送“大额异动”给管户客户经理。

维护存量客户的核心动作

小王每周要做的事：

  1. 看余额变化：客户存款掉了，马上问原因

  2. 送对账单：每月初把上个月的对账单发给客户（现在一般是电子版）

  3. 推产品：客户账上钱多了，推荐理财、通知存款、结构性存款（利率比活期高）

  4. 节日问候：客户老板生日、公司周年庆，发微信、送小礼物

数据视角：客户经理的每一次联系记录，都要录入CRM系统的客户联系记录表。这些记录用于考核客户经理的“客户触达率”。

第二幕：新增存款——从哪里挖？

存量维护只能保底，增量存款要靠新客户。

小王的主要目标：把其他银行的存款挖过来。

上午 10:00 拜访意向客户：XX物流公司

小王昨天约了XX物流公司的老板张总。这家公司年营收2个亿，但开户和存款都在竞争对手银行。

小王带着伴手礼和一本“银行服务方案”去了。

见面寒暄后，小王开门见山：

“张总，您的公司业务蒸蒸日上，我听说您最近准备扩大车队，需要资金支持。我们行对物流行业有专项信贷额度，利率比同业低0.5%。您要不要先把基本户开过来，感受一下我们的服务？”

张总：“利率确实有吸引力。但我现在的银行合作好几年了，换银行麻烦。”

小王：“不麻烦。我们可以帮您一站式办理开户、网银、代发工资。而且您公司500个司机，每人每月发工资，我们提供免费代发服务，还能给司机们办信用卡、消费贷，提升员工福利。”

张总有点心动：“那你们存款利率呢？我账上经常有短期闲置资金。”

小王：“我们有7天通知存款，利率1.5%，比活期高5倍。还有结构性存款，保本保最低收益，挂钩黄金汇率，收益有机会到2.8%。”

张总：“行，你先回去准备开户材料，我让财务跟你们对接。”

数据视角：客户经理在外拜访，要在手机App里记录拜访日志：客户名称、拜访时间、洽谈内容、下一步计划。银行考核客户经理的“有效拜访量”。

中午 12:30 陪客户吃饭，聊供应链金融

小王中午请XX物流公司的财务总监吃饭。席间聊到：

“王总，你们上游有100多家小供应商，他们经常缺钱吧？我们行可以做‘供应链融资’——基于你们对供应商的应付账款，给供应商发放贷款，不需要供应商额外抵押物。”

财务总监：“这个好！我们那些供应商经常来催款，要是他们能从银行拿到钱，我们账期就能拉长。”

小王：“对，而且这个业务还能帮你们公司沉淀存款——供应商的贷款回款账户开到我们行，资金流水都留在这里。”

数据视角：供应链金融业务涉及到应付账款转让登记表、保理合同表、交易流水表。核心是“核心企业信用传导”给上下游。

第三幕：代发工资——存款的压舱石

代发工资是银行最稳定的低成本存款来源。工人工资发到银行卡里，通常不会马上转走，会沉淀一段时间。

小王下午去一家制造业企业，谈代发工资业务。

这家企业有800个工人，每月发工资400万。现在用的是另一家银行代发。

小王对老板说：“王总，您把代发转到我们行来。我给您三个好处：

  1. 代发手续费全免

  2. 我们上门给工人开卡，不用工人跑网点

  3. 给工人的工资卡配一个‘薪金宝’理财，工资到账自动理财，收益比活期高，工人高兴，您也省心。”

老板：“听起来不错。但代发换银行，财务工作量不小。”

小王：“我们提供‘批量代发’系统，您财务在网银上传工资表，一键发薪。我可以安排科技人员上门培训。”

老板最终同意：下个月开始试运行。

数据视角：代发工资业务涉及代发协议表、代发工资明细表、工资卡批量开卡记录。核心系统在每月发薪日，会批量将总金额分解到每个工人的账户。

第四幕：理财产品——拉住有钱人

下午 16:00 电话营销：高净值客户

小王下午回到行里，打开CRM系统，筛选出“存款50万以上、没买过理财”的客户名单。

他一个一个打电话：

“李总您好，我是XX银行客户经理小王。看到您账上有80万活期，我们行今天新发了一期理财产品，182天，预期年化3.2%，比活期高很多。您有兴趣了解一下吗？”

大部分客户拒绝，但打到第8个，有个客户说：“3.2%有点低，别家银行有3.5%的。”

小王：“您说的是哪家？我帮您对比一下风险等级。我们这个是R2低风险，别家如果是R3，风险不一样。另外我们行现在新客理财有3.5%的，您要是没买过，可以试试。”

客户：“那行，我明天去你们网点看看。”

数据视角：理财产品销售记录在理财销售表里，包括客户号、产品代码、购买金额、销售渠道、销售人员。销售业绩计入客户经理的“中收”考核。

第五幕：月末冲刺——存款“冲时点”

每月最后一天，是银行“月末存款”考核的关键时点。

小王今天的任务：确保月末存款余额达标。

他早上先过一遍手上的客户名单：

客户 当前余额 月初承诺 缺口 对策
XX科技 300万 500万 -200万 打电话催回款
XX贸易 350万 300万 +50万 已超额
XX物流 0（未开户） 200万 -200万 今天必须开户进账

小王先打给XX科技财务：

“李姐，之前说下个月才有回款，能不能这个月月底前先到账一笔？我们月底考核，帮帮忙。”

李姐：“我帮你问一下老板……老板说可以，今天下午有一笔300万货款到账，我让他们直接打到你们行账户。”

小王：“太感谢了！改天请您吃饭。”

然后再催XX物流开户：

“张总，今天是我们行月末考核，您今天把基本户开了，先转50万进来，下个月再转剩下的150万。我帮您申请了开户绿色通道，20分钟搞定。”

张总答应了。

下午4点，XX科技300万到账。XX物流开户完成，转入50万。

小王在系统里看到：月末存款余额 = 之前的6000万 + 今天新增350万 = 6350万。还差1650万才能完成年度任务？

不，他算了算：今天只是月末时点数据，日均存款还没到8000万。但时点数据好看，考核也能加分。

数据视角：月末存款余额来自核心系统的存款账户余额表，按客户、按账户汇总。月末最后一天的余额是监管报送1104报表的必填项。

第六幕：压力与收获

小王这个月最终完成了：

指标 本月完成 年度累计 年度目标 完成率
日均存款新增 700万 6700万 8000万 83.75%
新开户数 8户 35户 40户 87.5%
理财销售 1200万 8000万 1亿 80%
代发工资新增 2家企业 8家 10家 80%

还差一点，但小王心里有数：XX物流下个月200万存款会落地，还有两个新客户在谈。年底前完成任务问题不大。

他的绩效奖金=基本工资×完成系数。如果完成100%，全年奖金能拿12万。

如果完不成，可能只能拿5-6万。

客户经理小王的一天，对应到你的数据开发工作

小王的动作 产生的数据/用的表 你作为数据开发要做什么
看客户资金变动 大额交易流水表、存款账户余额表 提供“大额异动推送”接口，定时跑批生成异动名单
记录拜访日志 客户联系记录表、拜访日志表 设计CRM系统的拜访日志录入和查询功能
谈代发工资 代发协议表、批量开卡记录 支持代发工资文件的批量导入、自动拆分到个人账户
卖理财产品 理财销售表、产品信息表 理财销售数据加工，统计客户经理中收
月末冲存款 存款账户余额表、月末快照表 月末批量生成存款余额快照，供监管报送使用
看客户存款排名 客户存款排名表、客户经理业绩表 按客户经理分组汇总存款、理财、代发等业绩指标

一句话总结

客户经理小王的工作，就是到处跑、到处谈、到处打电话，目标只有一个——把别人的钱搬到自己的银行里。你作为数据开发，给他提供的数据越准、推送越及时、报表越好用，他拉存款的效率就越高。

你写ETL加工出的存款余额日汇总表、大额异动推送表、客户经理业绩排名表，最终都会出现在小王每天打开的CRM系统里，直接影响他今天该去拜访谁、给谁打电话。

想听哪个角色？反洗钱专员、信贷审批员、还是柜员？

反洗钱专员怎么查可疑交易

已思考（用时 2 秒）

我们需要设计一个故事，讲反洗钱专员如何查可疑交易。要体现出数据的运用、流程、检测规则、上报等。结合之前提到的洗钱案例背景，可以虚构一个日常场景。主题：反洗钱专员小陈的一天。

故事：反洗钱专员小陈查可疑交易

这个故事帮你理解：银行怎么发现洗钱？反洗钱专员每天对着数据做什么？什么情况会上报人行？

小陈，32岁，某银行分行反洗钱岗。她不管存款贷款，专门盯着异常资金流动。她的工作就是：从海量交易里，把“不对劲”的揪出来。

早上 9:00 打开系统：反洗钱监测平台

小陈到工位第一件事：打开反洗钱监测系统（AML系统）。

系统昨晚跑完批量，生成了今天的可疑交易预警清单。她的待办里有23条预警，按风险等级排列：

预警ID 客户名称 预警类型 触发原因 风险等级
W001 杭州XX商贸有限公司 快进快出 资金到账后2小时内转出，不留余额 高
W002 李XX（个人） 公转私频繁 多个对公账户向其个人卡转账 高
W003 义乌XX电子商务商行 分散转入、集中转出 多人向同一账户汇款，随后大额转出 高
W004 杭州XX科技公司 交易对手异常 与高风险地区账户发生交易 中
... ... ... ... ...

小陈倒了一杯咖啡，开始逐条核查。

数据视角：AML系统的预警来自交易流水表（每日增量）与一系列规则库的碰撞。规则包括：快进快出、公转私、分散转入集中转出、夜间交易频繁、与黑名单账户交易等。

第一单：快进快出的商贸公司

预警详情

客户：杭州XX商贸有限公司
注册时间：2025年2月（3个月前）
注册资金：100万（认缴，未实缴）
经营范围：建材、五金、日用百货
账户开立：2025年3月1日

近30天交易特征：

日期 转入金额 转出金额 资金停留时间 对手方
5月1日 50万 49.8万 1.5小时 转入：深圳XX投资公司；转出：个人账户（王某）
5月3日 80万 79.5万 2小时 转入：上海XX贸易公司；转出：个人账户（李某）
5月5日 120万 119万 1小时 转入：广州XX科技公司；转出：个人账户（赵某）
... ... ... ... ...

特征：

  1. 资金快进快出：到账后不超过2小时就转走，账户余额几乎永远为0或很少

  2. 金额近似：转出比转入略少（扣除手续费），明显不是正常贸易（正常贸易会有利润留存）

  3. 对手方异常：转入方都是外地公司，转出方都是个人

  4. 公司无实际经营：没有水电费、房租、工资等经营支出记录

数据视角：这些特征来自交易流水表的交易时间、交易对手字段，对比转入时间与转出时间计算停留时长；同时关联企业水电缴费表（无记录）判断是否空壳。

小陈的核查动作

  1. 查工商信息：打开企查查，这家公司注册地址是杭州某写字楼509室。但打开地图一看，那栋写字楼根本没有509室——虚假地址。

  2. 查企业网银登录IP：调出后台日志，发现这家公司的网银登录IP地址，同时登录过另外7家公司的网银。这些公司的开户行分布在不同支行，但登录IP相同。大概率是同一伙人在操作。

  3. 查关联账户：顺着转出的个人账户（王某、李某、赵某），发现这些个人账户之间也存在资金互转，形成了一个资金闭环。

  4. 查外部信息：在公安提供的涉诈名单里，发现王某的账户曾被用于电信诈骗收款。

小陈的判断

“这是典型的‘跑分’洗钱——诈骗资金通过空壳公司‘清洗’，最终流向个人口袋。必须上报。”

她的操作

  1. 在AML系统中，把这笔预警升级为“可疑交易报告”

  2. 填写可疑交易报告表：客户信息、可疑特征、判断依据、涉及金额

  3. 提交给反洗钱主管复核

  4. 主管同意后，通过系统上报中国人民银行反洗钱监测中心

数据视角：可疑交易报告生成后，会写入可疑交易报告表，并推送到监管接口。银行必须在发现可疑交易之日起5个工作日内上报。

第二单：频繁公转私的个人账户

预警详情

客户：李XX（个人）
职业：无固定职业（系统里填的“自由职业”）
近3个月交易：

日期 交易方向 金额 对手方
5月2日 收入 20万 杭州XX科技公司
5月2日 支出 19.8万 转给“张XX”
5月5日 收入 35万 上海XX贸易公司
5月5日 支出 34.5万 转给“王XX”
5月8日 收入 50万 深圳XX投资公司
5月8日 支出 49万 转给“赵XX”

特征：

  1. 收入全部来自对公账户，支出全部转给个人

  2. 本人无固定职业，账户月流水却超过200万

  3. 资金快进快出，不留余额

数据视角：交易流水表中，账号类型（对公/对私）的差异触发“公转私频繁”规则。

小陈的核查动作

  1. 查李XX的身份信息：发现他是外省人，身份证地址是农村，手机号归属地却是深圳。可疑。

  2. 查李XX的其他账户：他在这家银行只有这一个账户，但在其他银行？小陈查不到（银行间数据不互通）。不过李XX的开户预留手机号，在反洗钱系统里关联出另外3个账户（不同银行，通过人行风险共享平台查到）。这些账户也有类似特征。

  3. 查资金来源：转钱给他的公司（杭州XX科技公司），正是小陈上一单查到的空壳公司之一。

小陈的判断

“这是典型的‘跑分’工具人——用自己的银行卡帮别人转账，赚取手续费。背后可能是网络赌博或诈骗资金。”

上报。

第三单：分散转入、集中转出的电商

预警详情

客户：义乌XX电子商务商行（个体工商户）
近7天交易：

  • 转入：200多笔，每笔几百到几千元不等，合计80万

  • 转出：1笔，79万，转给“广州XX科技有限公司”

特征：

  1. 分散转入：大量小额资金，来源分散（不同个人账户）

  2. 集中转出：累积到一定金额后，一次性转给某个对公账户

  3. 交易时间集中在深夜23:00-凌晨3:00

数据视角：交易流水表按对手方聚合，发现“收款人相同、付款人分散”的模式；交易时间字段分析发现夜间交易占比异常高。

小陈的核查动作

  1. 查商户背景：这家电商在淘宝上开店，卖的是“虚拟产品”——游戏点卡、话费充值。这类商品极易被洗钱利用（买卡、转卖、变现）。

  2. 查买家IP：调取网银/支付接口的日志，发现这些买家的IP地址来自境外（东南亚）。一个卖游戏点卡的网店，买家全是境外IP？可疑。

  3. 查资金最终流向：转出的“广州XX科技有限公司”，经查是一家空壳公司，注册地址不存在。

小陈的判断

“这是典型的‘赌资归集’——网络赌客分散充值，商户收集后统一转给庄家。”

上报。

中午 12:30 处理完预警，写分析报告

小陈一上午处理了3个高危预警，还有20个中低风险的要继续排查。

她打开可疑交易报告的草稿，汇总：

报告编号 客户 可疑类型 涉及金额 是否上报
STR20250523001 杭州XX商贸有限公司 空壳公司、快进快出、跑分 约500万 是
STR20250523002 李XX 公转私、工具人账户 约300万 是
STR20250523003 义乌XX电子商务商行 分散转入集中转出、网络赌博 约200万 是

下午她还有客户尽职调查要做——去一家触发预警的企业现场核查。

下午 14:00 现场核查：上门看企业

小陈和客户经理一起去一家触发预警的贸易公司。这家公司的预警理由是：交易对手涉及制裁名单国家。

到了公司注册地址，发现是一间居民住宅，门口没有任何公司招牌。敲门没人应。

小陈打电话给企业联系人：“您好，我们是银行工作人员，来您公司做例行回访。您在吗？”

对方支支吾吾：“我们……我们不在这办公了，搬到别的地方了。”

小陈：“新地址是哪里？我们过去。”

对方：“还没确定，过几天再联系。”

挂了电话，小陈在系统里记录：“企业地址不实，电话联系推脱，疑似空壳。”

回来后，她提交了可疑交易报告的补充说明：企业地址虚假、无法联系、交易涉及制裁名单——建议销户。

数据视角：现场核查结果录入客户尽职调查表，作为可疑交易报告的证据附件。

下午 16:30 总结今日工作

小陈今天的成果：

工作项 数量
处理AML预警 23条
其中上报可疑交易 3条
现场核查企业 1家（空壳，建议销户）
补充尽调记录 5份
冻结账户 1个（涉及电信诈骗，公安要求）

她关掉电脑，心想：明天还有一批预警等着她。

反洗钱专员小陈的一天，对应到你的数据开发工作

小陈的动作 背后的数据表 你作为数据开发要做什么
看系统生成的预警 交易流水表、规则引擎结果表 写SQL实现“快进快出”“公转私”等规则的批量计算
查企业工商信息 外部工商接口表（企查查等） 每日同步工商数据，与银行客户信息比对
查网银登录IP 网银登录日志表 关联多个账户的登录IP，找出同一IP控制的账户群
查关联账户 交易流水表（自关联） 资金链路追踪，找出多级转账后的最终收款方
查外部风险名单 人行风险共享平台接口、公安涉诈名单表 每日同步外部名单，与交易对手匹配
上报可疑交易 可疑交易报告表 提供上报接口，生成符合监管格式的数据文件
现场核查记录 客户尽职调查表 提供核查记录录入和查询功能
冻结账户 账户状态表 提供账户冻结接口，更新账户状态字段

反洗钱的核心规则（你会在ETL里实现）

规则名称 判断逻辑（简化） SQL示例
快进快出 资金停留时间 < 24小时，且金额进出近似 SELECT ... WHERE (转出时间 - 转入时间) < INTERVAL '24' HOUR AND 转出金额 >= 转入金额 * 0.99
公转私频繁 对公账户向个人账户转账，且月累计 > 50万 SELECT 付款账号, COUNT(*) FROM ... WHERE 付款账号类型='对公' AND 收款账号类型='对私' GROUP BY 付款账号 HAVING SUM(金额) > 50万
分散转入集中转出 收款人相同，付款人>10个，且转出笔数<=3笔 SELECT 收款账号, COUNT(DISTINCT 付款账号) as 付款人数, SUM(金额) as 总额 FROM ... GROUP BY 收款账号 HAVING 付款人数 > 10 AND 转出笔数 <= 3
夜间交易频繁 23:00-05:00交易笔数占比 > 80% SELECT 账号, SUM(CASE WHEN HOUR(交易时间) BETWEEN 23 OR HOUR(交易时间) < 5 THEN 1 ELSE 0 END) / COUNT(*) > 0.8
与高风险地区交易 交易对手账户开户行位于制裁/高风险国家/地区 LEFT JOIN 地区风险表 ON ... WHERE 地区风险等级='高'

一句话总结

反洗钱专员小陈的工作，就是每天在系统预警里“淘金”——把真正的可疑交易从海量数据里挑出来，写成报告上报人行。你写的每一行ETL、每一条预警规则，都在帮小陈更准、更快地抓住坏人。

而如果银行漏报、迟报，可能被罚几百万甚至几千万。这就是为什么反洗钱是银行不敢松懈的红线。

想听哪个故事？信贷审批员、资金交易员，还是合规部？

大数据开发新人实习生的一天

已思考（用时 4 秒）

我们需要设计一个故事，讲述大数据开发新人实习生的一天，帮助理解银行大数据开发岗位的工作内容、技术栈、协作方式。要贴合之前对话中提到的概念（ETL、数仓分层、SQL、监管报送等），并且体现新人的学习成长。故事要真实、有细节、有数据表操作等。

大纲：早上晨会、分配任务（修复某张表的数据质量问题或开发一个简单指标）、写SQL、跑批、遇到问题求助导师、联调测试、交付。可以包含监管报送相关。

最好与之前提到的EAST、借据表、客户画像等衔接。

输出故事。

故事：大数据开发实习生小周的一天

这个故事帮你理解：银行大数据开发新人上班到底在干什么？每天面对什么数据、写什么SQL、和谁打交道？

小周，22岁，刚入职某银行的项目组，做监管报送方向的数据开发实习生。

带他的导师叫老赵，35岁，在银行干了8年。

早上 9:00 到工位：看昨天的ETL跑了没

小周在银行科技部的工位上坐下。他负责EAST监管报送的ETL开发——具体来说，是加工EAST要求的“信贷借据表”。

他打开DataWorks（阿里云数据开发平台），先看昨天的调度任务：

任务名称 状态 运行时长 数据量
ods_credit_voucher_import ✅ 成功 12分钟 230万条
dwd_voucher_clean ✅ 成功 8分钟 228万条
dws_voucher_summary ❌ 失败 - -

有一个任务失败了：dws_voucher_summary。

小周点开报错日志，看到一行红色：

text

FAILED: SemanticException [Error 10004]: Line 2:12 Invalid table alias or column reference '五级分类'

数据视角：Hive SQL里引用了“五级分类”字段，但表里没有这个列。可能是源表改了结构，ETL脚本没同步。

小周心里一紧。这是昨天导师让他写的那个汇总任务，用来计算每个分行的五级分类贷款余额。

他赶紧去查dwd_voucher_clean表的结构，发现“五级分类”字段已经被重命名为risk_classify了——信贷系统改了字段名，但没有通知他们组。

他跑去找导师老赵。

上午 9:30 请教导师：修ETL

小周：“赵哥，昨天跑批失败了，源表把‘五级分类’字段改名了。”

老赵看了一眼报错：“嗯，信贷系统这周上线了新版本，改了字段名。你去把脚本里的字段名改成risk_classify，重新跑一遍。”

小周：“那我以后怎么提前知道源表变更？”

老赵：“问得好。我们有元数据订阅，你每天上班第一件事，去元数据管理平台看有没有字段变更通知。今天没看吧？”

小周挠头：“忘了……”

老赵：“没事，新人正常。我发你个文档，以后每天早上先看元数据变更。”

小周回到工位，打开dws_voucher_summary的SQL脚本，找到了报错的那一行：

sql

SELECT 
    机构号,
    五级分类,      -- 老字段名
    SUM(贷款余额) as 余额
FROM dwd_voucher_clean
GROUP BY 机构号, 五级分类

改成：

sql

SELECT 
    机构号,
    risk_classify as 五级分类,   -- 新字段名，统一别名保持下游不变
    SUM(贷款余额) as 余额
FROM dwd_voucher_clean
GROUP BY 机构号, risk_classify

然后手动触发任务重跑。这回成功了。

数据视角：ETL脚本里的字段映射必须与源表保持一致。银行系统经常变更，数据开发的日常工作就是“适配变更”。

上午 10:30 新需求：加工一个监管指标

老赵给小周派了个新任务：

“小周，EAST报送下个月要新增一个指标——‘逾期90天以上贷款余额’。你去写个SQL，从DWD层加工出这个指标，结果写到ADS层的一张新表里。下午下班前给我。”

小周打开了需求文档：

指标名称：逾期90天以上贷款余额
口径定义：借据表中，当前逾期天数 ≥ 90 天的未还本金之和。
逾期天数 = 当前日期 - 最近一次应还款日期（若未还清）
注意：已核销、已结清的借据不计入。

小周理了一下思路：

  1. 需要借据表（dwd_loan_voucher_di）：借据号、余额、借据状态、客户号

  2. 需要还款计划表（dwd_repay_plan_di）：借据号、应还款日期、是否已还

  3. 关联后找出每个借据最近一期未还的应还款日

  4. 用当前日期减去应还款日，得到逾期天数

  5. 过滤逾期天数≥90、余额>0、状态不是“核销/结清”的借据

  6. 汇总余额，分行级（机构号）输出

他开始写SQL：

sql

-- 第一步：找到每个借据最近一期未还的应还款日
WITH latest_unpaid AS (
    SELECT 
        a.借据号,
        MAX(b.应还款日期) as 最近应还款日
    FROM dwd_loan_voucher_di a
    LEFT JOIN dwd_repay_plan_di b 
        ON a.借据号 = b.借据号
    WHERE b.是否已还 = '未还'
      AND a.借据状态 NOT IN ('核销','结清')
    GROUP BY a.借据号
),

-- 第二步：计算逾期天数，筛选≥90天
overdue_voucher AS (
    SELECT 
        a.借据号,
        a.机构号,
        a.余额,
        DATEDIFF(CURRENT_DATE(), l.最近应还款日) as 逾期天数
    FROM dwd_loan_voucher_di a
    JOIN latest_unpaid l ON a.借据号 = l.借据号
    WHERE DATEDIFF(CURRENT_DATE(), l.最近应还款日) >= 90
      AND a.余额 > 0
)

-- 第三步：按机构汇总
INSERT OVERWRITE TABLE ads_overdue_90_balance_di
SELECT 
    机构号,
    SUM(余额) as overdue_balance
FROM overdue_voucher
GROUP BY 机构号;

写完自己测了一下：造了两条假数据，逻辑跑通了。

他跑去给老赵看SQL。

老赵看了看：“思路对。但有一个坑：如果一笔借据有多期没还，你用了MAX(应还款日)，拿到的是最近一期——但逾期天数要从最早一期没还的那天开始算。比如第一期没还日是1月1日，第二期是2月1日，用MAX只能拿到2月1日，逾期天数才XX天，但实际上应该从1月1日就开始算了。你这样会少算逾期天数。”

小周一愣：“啊？那应该用MIN？”

老赵：“对。找最早一期没还的应还款日。因为从那天起，这笔借据就已经开始逾期了。信贷系统的口径是‘首次逾期日’，不是‘最近逾期日’。改一下，用MIN。”

小周恍然大悟，赶紧改了SQL里的MAX为MIN，重新跑测试。这回逾期天数大了很多。

数据视角：业务口径是“首次逾期”，不是“最近逾期”。新人最容易犯的错就是理解偏了业务规则。所以银行大数据开发必须懂业务，不能只看数据。

中午 12:00 吃饭，和同事聊

小周和组里的几个同事去食堂吃饭。

聊到今天的任务：

小周：“今天才知道‘逾期天数’要从第一次没还的日子算起，差点写错。”

老员工老刘：“正常。我们刚来的时候也被坑过。银行的业务规则特别细，不能靠猜，必须查数据字典和业务口径文档。”

小周：“我们组有这种东西吗？”

老刘：“有啊，在SVN上，叫‘监管报送口径手册’。你找找。里面写了每个指标的计算规则、取哪个表、用哪个字段、特殊情况怎么处理。”

小周心想：下午回去一定仔细看看那个手册。

下午 14:00 联调测试：和业务人员对口径

老赵让小周把结果发给业务人员（反洗钱科的张姐）做验收。

小周把今天加工的“逾期90天以上贷款余额”按分行汇总发过去。

张姐回复：“XX分行的余额和我手工算的不一样，差了120万。”

小周心一沉，赶紧排查。

他先查了XX分行有哪些借据逾期≥90天，拉出明细：

借据号 余额 首次逾期日 逾期天数
J001 50万 2025-01-01 140天
J002 30万 2025-02-01 109天
J003 45万 2025-02-15 94天

合计：125万。和张姐说的差异在哪？

张姐说他算的是125万，小周算的是125万？不对，张姐说他手工算了125万，小周算的是多少？小周再看自己汇总结果：XX分行 = 125万。一致啊？

他再仔细看张姐的微信消息：“XX分行的余额和我手工算的不一样，差了120万”——哦，原来张姐算的是5万，小周算的是125万，差了120万。那就是他的SQL把所有逾期≥90天的借据都加进来了，张姐只计了其中一部分。为什么？

小周打电话给张姐：“张姐，您手工算的5万是哪几笔？”

张姐说：“J001这笔50万，虽然逾期140天，但企业已经和我们签了重组协议，正在走流程，不算入‘逾期90天以上’的监管指标。”

小周恍然大悟——有重组的借据要从统计里剔除。

他挂了电话，去找老赵。

老赵：“业务口径文档里写了，‘已达成重组协议且正在履行中的借据，不计入逾期指标’。你没看文档吧？”

小周惭愧地点头。

他回到工位，翻开那个500多页的EAST报送口径手册，找到了相关条款：

EAST G0106表（贷款借据明细表）逾期天数填报规则：
若借据状态为“重组中”，且重组协议正常履行，逾期天数填0，不计入逾期余额。

于是他在SQL中加了一个过滤条件：AND 借据状态 != '重组中'。

重新跑任务，结果出来了，和张姐的手工结果完全一致。

数据视角：监管报送对每个字段都有详细的口径说明。数据开发必须严格按照文档写SQL，不能自己想当然。

下午 16:30 写日报，准备下班

小周在钉钉群里发今天的日报：

text

【实习生小周日报】
2025-05-23

1. 修复`dws_voucher_summary`任务失败问题（源表字段变更，已适配）。
2. 开发新增指标“逾期90天以上贷款余额”，完成SQL编写及联调测试，口径与业务确认一致。
3. 学习EAST口径手册P120-150，了解五级分类、逾期天数计算规则。

明日计划：
1. 将今日指标加工成ADS表，并配置日调度。
2. 学习元数据平台的使用。

附：今日代码已提交到SVN，路径：/trunk/east/voucher/

老赵在群里回了个“👍”。

小周收拾东西，准备下班。

大数据开发实习生小周的一天，总结

时间段 做的事情 用到的技术/工具 产生的数据/产出
9:00-9:30 看昨日调度任务，排查失败 DataWorks、Hive 定位字段变更问题
9:30-10:30 修改ETL脚本，重跑 SQL、元数据平台 修复dws_voucher_summary任务
10:30-12:00 新需求开发：逾期90天指标 SQL、Hive、DWD/ADS层 编写ads_overdue_90_balance_di
14:00-16:00 联调测试，和业务对口径 钉钉、口径手册 修正SQL逻辑（排除重组借据）
16:00-16:30 学习文档、写日报 SVN、手册 积累业务知识

一句话总结

大数据开发实习生小周的一天，就是写SQL、修ETL、对口径、学业务。每一项任务都离不开对银行数据表、监管规则、业务逻辑的理解。新人最容易犯的错不是写错SQL，而是不理解业务口径。一旦理解清楚，代码反而是最好写的部分。

需要我再讲一个资深数据开发（老赵）的一天，或者数据测试工程师的一天吗？

资深数据开发（老赵）的一天

已思考（用时 3 秒）

我们要求用故事形式讲资深数据开发老赵的一天，帮助理解业务。需要涵盖他作为导师、解决复杂问题、设计架构、处理生产问题、与业务沟通等。内容要真实，涉及银行数据开发场景，如监管报送、ETL优化、数据质量、项目管理等。

故事：资深数据开发老赵的一天

这个故事帮你理解：干了8年银行数据开发的老手，每天在忙什么？他不只写SQL，还要设计架构、优化性能、救火、带新人、和业务吵架（划掉）沟通。

老赵，35岁，某银行项目组的技术骨干，带6个人（包括实习生小周）。他负责整个EAST监管报送和数据仓库的建设。

他不是在写代码，就是在开会，要不就是在帮人擦屁股。

早上 8:30 到工位：先看监控大屏

老赵到得比小周早。他打开DataWorks和调度监控平台，扫一眼昨晚跑批的情况：

任务域 总任务数 成功 失败 重跑中 备注
ODS抽取 45 45 0 0 正常
DWD清洗 120 118 2 2 超时
DWS汇总 80 78 2 2 数据倾斜
ADS报送 35 33 2 0 文件生成失败

老赵皱了皱眉：DWD有两个任务超时，DWS有两个数据倾斜，ADS有两个文件失败。

他点开一个DWD超时任务：是清洗信用卡交易流水的，昨天跑了2小时还没跑完（平时30分钟）。

数据视角：任务运行时长监控是ELK/DataWorks自带的。超时可能是因为源表数据量暴增或者SQL写烂了。

他查看日志，发现昨天的信用卡交易量比平时多了10倍——原来是某支付平台搞活动，交易量激增。

老赵快速决策：

  1. 让组员小刘把那个任务的并发度调高（set mapred.reduce.tasks=200）

  2. 重跑，预计15分钟能跑完

然后再看DWS数据倾斜：按客户汇总的交易表，某个大客户有几百万笔交易，导致一个reduce卡死。

老赵在群里喊了一声：“谁写的这个SQL？加个随机盐，把热点打散。参考我之前发的模板。”

新手小钱赶紧回复：“赵哥，我来改。”

数据视角：数据倾斜是Hive开发常见问题，解决方式包括加盐、两阶段聚合、改用Spark等。

上午 9:30 站会：进度同步

老赵主持了10分钟站会：

  • 小刘：信用卡交易清洗任务重跑成功，优化了参数，后续活动期间会自适应。

  • 小钱：客户汇总表数据倾斜正在改，预计上午搞定。

  • 小周（实习生）：昨天写的逾期90天指标口径调整好了，今天要加分区和调度。

  • 老赵：ADS那两个文件失败谁负责？小陈：是我这边，EAST接口规范昨天有小更新，报送字段顺序变了，我改一下shell脚本。

老赵总结：“小周上午跟小陈一起把ADS层修复了，下午我跟他讲一下我们整个调度依赖的设计。大家抓紧，月底EAST报送不能出问题。”

上午 10:30 处理生产问题：业务投诉数据对不上

合规部的张姐气冲冲地跑过来：

“老赵，你们上周报送的EAST‘贷款借据表’里，我行总的不良贷款余额和我手工台账差了2000万！监管问下来我们怎么解释？！”

老赵不慌不忙：“张姐，我们看看数据。您先告诉我是哪个时点的数据？”

张姐：“2025年4月30日。”

老赵打开数据质量平台，调出4月30日那天报送的数据校验报告：

  • 借据表不良余额汇总 = 5.2亿

  • 手工台账 = 5.0亿

  • 差异 = 2000万

他又打开一个SQL，现场查：

sql

SELECT 五级分类, SUM(余额)
FROM dws_loan_summary_di
WHERE 统计日期 = '2025-04-30'
GROUP BY 五级分类;

结果：

五级分类 余额
正常 100亿
关注 3亿
次级 2亿
可疑 2.5亿
损失 0.7亿

不良（次级+可疑+损失）= 2+2.5+0.7 = 5.2亿。系统算的是5.2亿。

老赵问张姐：“您的手工台账不良是5.0亿，是少了哪一笔？”

张姐查了一下：“XX房地产那笔5000万，我算在‘可疑’里，你们算在‘损失’里了？我看看……确实是损失，我记错了。那差异应该是1500万，不对，还差500万……”

两人核对了半天，发现张姐漏记了一笔500万的小微贷款，也是损失类。

最终对上了。张姐不好意思地笑了：“谢谢老赵，我回去改台账。以后以系统为准。”

老赵笑着说：“咱们系统数据是以业务录入为准的，万一业务录错了，系统也会错。要不我每天给您发一份‘数据与台账差异预警’，您每周对一次？”

张姐：“那太好了！”

数据视角：数据质量检核不仅仅是技术问题，更是业务和技术的协同。老赵的提议实际上是一个“数据核对自动化”的小需求。

中午 11:45 和小周1对1：讲调度依赖

老赵趁午饭前，给小周讲了整个ETL调度依赖的设计。

他在白板上画了一个图：

text

【ODS层】
信贷合同表(日增量) ──┐
借据表(日增量)   ──┼──→ 都完成
客户信息表(全量) ──┘
         ↓
【DWD层】清洗、去重、关联
dwd_loan_voucher_di (依赖ODS三个表)
         ↓
【DWS层】汇总、拉宽
dws_loan_summary_di (依赖DWD借据表)
         ↓
【ADS层】监管报送表
ads_east_g0106_voucher (依赖DWS汇总)
         ↓
【出口】生成文件、加密、报送

老赵说：“关键是依赖关系——下游必须等上游跑完才能开始。我们用的是DataWorks的依赖配置，你明天试着把逾期指标那个ADS任务的依赖配上。”

小周使劲点头。

下午 13:30 设计评审：新监管报表

下午有个设计评审会，参会的有：合规部、信贷部、科技部，以及老赵的团队。

议题：EAST新增一张表——“贷款资金流向表”，需要监控贷款发放后15日内资金是否流入小贷、房地产等敏感领域。

合规部提出口径：

  • 时间窗口：放款后15个自然日

  • 资金比例：累计流向敏感对手方金额 ≥ 放款金额的30%

  • 敏感对手方：小贷公司、担保公司、房地产开发商、公检法名单账户

信贷部补充：“要关联借据表和交易流水表。但是注意，如果企业是正常贸易，比如向房地产公司买办公楼，那是允许的。不能一刀切。”

老赵说：“好，我们设计一个‘排除清单’，对于有真实贸易背景的，比如提供购房合同、租赁合同的，不触发预警。技术上我们可以先全量监控，再由业务人员复核剔除。”

科技部问：“数据量多大？每天多少笔交易？”

老赵：“全行每天放款大约2000笔，每笔15天内的交易流水平均50条，大概10万条关联数据。Hive跑没问题，但要控制资源，放在夜间低峰期跑。”

老赵在需求文档上写下技术方案：

  • 源表：dwd_loan_voucher_di（借据）、dwd_transaction_flow_di（交易流水）

  • 外部名单：dim_sensitive_counterparty（敏感对手方维表，每日更新）

  • 加工逻辑：窗口关联，聚合计算流向金额占比

  • 输出：ads_loan_flow_monitor_di，供给反洗钱系统

评审通过，预计2周开发+测试。

下午 15:30 代码审查（Code Review）

小钱把他改完的数据倾斜代码发给老赵审查。

原SQL：

sql

SELECT 客户号, SUM(交易金额)
FROM dwd_transaction_di
GROUP BY 客户号;

小钱修改后：

sql

-- 加盐打散
SELECT 客户号, SUM(交易金额) FROM (
    SELECT 
        IF(客户号 = 'HOT_CUSTOMER_001', 
           CONCAT(客户号, '_', CAST(RAND()*100 AS INT)), 
           客户号) as salted_key,
        交易金额
    FROM dwd_transaction_di
) t
GROUP BY salted_key;

老赵说：“思路对，但是HOT_CUSTOMER_001是写死的，不通用。应该先统计每个客户交易量，动态识别热点客户，再加盐。或者更简单——用distribute by + sort by配合bucket。我给你一个模板，你明天改一版。”

老赵心里叹了口气：新人对Hive优化的理解还停留在表面，慢慢来吧。

下午 16:30 规划下月工作：数据治理

老赵和项目经理老王讨论下个月的重点工作。

老王：“监管要求我们今年必须通过数据管理能力成熟度评估（DCMM）三级。我们现在二级都没过。你得牵头搞数据治理。”

老赵列出几个痛点：

  1. 数据标准不统一：同一个“客户号”在核心系统、信贷系统、信用卡系统里，格式不一致，导致ETL要反复转换。

  2. 数据血缘不清晰：很多老任务没有文档，不知道字段从哪里来的，没人敢动。

  3. 数据质量无监控：很多表没有配置完整性、唯一性、准确性校验。

老赵提议：“建立企业级数据标准库，先把核心实体（客户、账户、产品）统一编码。然后开发数据质量检核脚本，每天自动发报告给各业务部门。最后搞一个数据血缘平台，自动解析SQL，形成可视化血缘图。”

老王：“听起来要加人。”

老赵：“至少加两个。或者我们招两个实习生。”

两人相视而笑。

下午 17:30 回复邮件、写日报

老赵回到工位，回复了几封邮件：

  • 给合规部的：EAST报送差异分析报告

  • 给数据治理委员会的：DCMM评估自查表

  • 给组里同事的：明天的任务安排

然后在群里发日报：

text

【数据开发组日报】2025-05-23

一、生产情况
- 昨日批处理：总任务280，成功276，失败4（已处理）
- 主要问题：信用卡交易量激增导致超时，已优化并发参数；数据倾斜已修复。

二、重点工作
- 小周：逾期90天指标ADS开发，已联调通过。
- 小陈：EAST接口规范变更适配，已完成。
- 老赵：新监管报表“贷款资金流向表”设计评审通过，下周启动开发。

三、明日计划
- 小钱：优化数据倾斜代码。
- 老赵：与合规部确认贷款流向表排除清单。
- 全员：学习数据治理标准V1.0。

四、风险提示
- 信贷系统下月升级，可能影响借据表字段，请提前关注元数据变更。

晚上 18:15 下班前

小周还没走，在做作业。

老赵路过：“还不走？”

小周：“赵哥，我那个逾期指标任务，调度依赖还是有点晕，能再讲一下吗？”

老赵拉过椅子，又画了一遍依赖图，解释了两个常见的依赖模式：全量表依赖日增量、多源融合依赖。

小周终于懂了。

老赵拍了拍他肩膀：“干我们这行，技术能学，业务能补，但细心和责任心是练出来的。你今天的表现不错。明天继续。”

小周笑了。

老赵收拾东西，关灯，回家。

资深数据开发老赵的一天，总结

时间段 做的事情 体现的能力/角色
8:30-9:30 监控批处理、处理超时/倾斜 生产保障、性能优化
9:30-10:00 站会、进度跟踪 项目管理、任务分配
10:30-11:30 与业务对账、解决数据质量争议 业务沟通、问题定位
11:45-12:30 给新人讲调度依赖 导师、知识传承
13:30-15:00 新需求设计评审 架构设计、跨部门协调
15:30-16:30 代码审查、技术指导 技术Leader
16:30-17:30 规划数据治理 战略规划、技术管理
17:30-18:15 回复邮件、写日报、带新人 日常管理、辅导

一句话总结

老赵的一天，不是单纯写SQL，而是救火、设计、沟通、规划、带人。他既能深入技术细节（查数据倾斜），又能站在业务角度解决问题（和合规对账），还能带领团队往前走（规划数据治理）。这就是3-5年后你想成为的样子——懂业务、懂数据、能带队的数据专家。

以上就是“银行各角色一天”系列：

  1. 柜员小陈

  2. 行长老周

  3. 风险经理老吴

  4. 客户经理小王

  5. 反洗钱专员小陈

  6. 大数据开发实习生小周

  7. 资深数据开发老赵

你想让我再补充哪个角色的故事？比如数据测试工程师、项目经理、产品经理？

数据测试工程师

已思考（用时 2 秒）

我们接下来写“数据测试工程师”的故事，延续之前讲故事的方式，帮助理解银行数据测试的工作内容。注意和之前的角色区别：测试工程师主要负责验证数据加工的正确性、质量检核、回归测试等。

故事：数据测试工程师阿芳的一天

这个故事帮你理解：数据测试工程师在银行做什么？不是点点点，而是写SQL验证数据对不对、口径准不准、报表和源数据是否一致。

阿芳，29岁，某银行项目组的数据测试工程师，负责监管报送（EAST、1104）和数仓的数据质量验证。她不会写ETL，但她会挑ETL的毛病——开发写完SQL，她来验证对不对。

带她的测试组长叫老李，39岁。和小周（开发实习生）是同一个项目组的“死对头”——一个写代码，一个找bug。

早上 9:00 到工位：看昨天的测试报告

阿芳到工位第一件事：打开测试管理平台（Jira + 自研数据校验工具），看昨天执行的自动化测试结果。

昨天的测试任务：

测试任务 涉及表/报表 测试类型 执行结果 失败用例数
EAST_G0106_借据表 ads_east_g0106_voucher 表内校验 ❌ 失败 3
1104_G01_资产负债 ads_1104_g01 表间校验 ✅ 成功 0
逾期90天指标 ads_overdue_90_balance_di 总分校验 ❌ 失败 1
贷款流向预警 ads_loan_flow_warning 逻辑验证 ⚠️ 警告 2

阿芳点开失败的任务，开始排查。

数据视角：数据测试工程师的核心工具是SQL和数据校验脚本。自动化测试框架会每日跑预设的校验规则，生成报告。

第一单：EAST借据表——表内校验失败

测试用例：EAST G0106表（贷款借据明细表）要求：借据金额 = 本金余额 + 已还本金（逻辑上，任何一笔贷款，初始放款金额应该等于已还本金加上剩余本金）。

阿芳的校验SQL：

sql

SELECT 借据号, 借据金额, 本金余额, 已还本金
FROM ads_east_g0106_voucher
WHERE ABS(借据金额 - (本金余额 + 已还本金)) > 0.01;

跑出来3条记录：

借据号 借据金额 本金余额 已还本金 差额
J12345 100万 60万 39万 1万
J12346 50万 30万 19.5万 0.5万
J12347 200万 120万 79万 1万

为什么差这么多？ 阿芳去查源系统（核心借据表）的数据。发现核心系统里，这三笔贷款的“已还本金”字段是空的，而“本金余额”正常——ETL开发在加工时，可能用了错误的关联逻辑，导致“已还本金”只取了部分还款流水。

阿芳在Jira上建了一个缺陷单：

  • 标题：EAST G0106借据表，三笔借据的“已还本金”缺失，导致等式不成立

  • 严重程度：高（监管报送数据质量要求严，等式不成立会被监管退回）

  • 指派给：小周（负责借据表ETL的开发实习生）

  • 附件：校验SQL、三笔借据明细截图

然后她发钉钉给小周：“小周，你昨天改的借据表ETL，有三笔数据‘已还本金’算错了，Jira单号889，你今天上午修一下。”

小周看到消息，无奈地回复：“收到，我看看。”

数据视角：表内校验是数据测试的基础——单张表内字段之间的业务逻辑关系必须成立。数据测试工程师需要熟悉每个监管报表的内部勾稽关系。

第二单：逾期90天指标——总分校验失败

测试用例：ADS层的ads_overdue_90_balance_di（逾期90天以上贷款余额，按分行汇总）的总和，应该等于从DWD层明细汇总的总和（总分一致性）。

阿芳的校验SQL：

sql

-- 从ADS层拿汇总结果
SELECT SUM(逾期余额) as ads_total FROM ads_overdue_90_balance_di;

-- 从DWD明细层直接计算
SELECT SUM(余额) as dwd_total
FROM dwd_loan_voucher_di
WHERE 逾期天数 >= 90 AND 借据状态 NOT IN ('核销','结清','重组中');

结果：

  • ads_total = 5.2亿

  • dwd_total = 5.0亿

  • 差异 = 2000万

阿芳找到差异的源头：ADS层多了XX分行的一笔2000万贷款，这笔贷款在DWD明细里逾期天数是85天（小于90），不应该进ADS。但ADS里却进来了。

她查了小周开发的ETL逻辑，发现小周在判断逾期天数时，用的是“最近一期未还的应还款日”（MAX），而不是“首次未还日”。这恰恰是昨天小周被老赵纠正过的那个坑——但小周改完SQL后，忘记同步到生产环境了。

阿芳在Jira上建缺陷：

  • 标题：逾期90天指标，XX分行多计2000万（逾期天数计算口径错误）

  • 严重程度：高（影响不良贷款率监管指标）

  • 指派给：小周

  • 备注：生产环境的SQL未同步修改，请紧急更新并重跑历史数据

数据视角：总分校验是数据测试的核心——汇总层的指标值必须与明细层累加一致，否则说明ETL逻辑有问题。

上午 11:00 回归测试：验证修复

小周修完两个缺陷后，阿芳做回归测试——检查修复是否有效，同时确保没有引入新问题。

她重新跑了一遍昨天的所有测试用例：

  • EAST_G0106借据表 → 成功（3条异常已消失）

  • 逾期90天指标 → 成功（ads_total = dwd_total = 5.0亿）

  • 贷款流向预警 → 还有2个警告，需要进一步分析

阿芳在Jira上更新状态：已修复，回归通过。然后发消息给老赵（开发组长）：“两个高优缺陷已修复，可以发版。”

老赵回了个“👍”。

数据视角：回归测试是确保代码修改不破坏已有功能。数据测试通常要维护一套自动化回归用例集，每次发版前全部跑一遍。

中午 12:30 吃饭，和小周聊

食堂里，阿芳和小周坐一桌。

小周：“阿芳姐，你是不是专门盯着我的代码找茬？”

阿芳笑了：“不是我盯你，是你的代码bug多。你知道为啥吗？你写完代码从来不自己测，直接提测，我不找bug谁找？”

小周：“我测了啊，我造了几条数据跑通了。”

阿芳：“造数据测试只能测通不通，测不准对不对。你得用生产数据子集做测试，还要写测试用例覆盖边界情况——比如重组中的借据、逾期天数刚好90天边缘、多期逾期但最近一期还了……这些你都没测。”

小周挠头：“好复杂……”

阿芳：“不复杂，我发你一个测试用例设计模板。写ETL之前，先想清楚：这个逻辑要覆盖哪些业务场景？边界在哪？异常数据怎么处理？想清楚了再写代码，bug少一半。”

小周：“谢谢阿芳姐！”

数据视角：数据测试不仅仅是找bug，更是一种质量内建的理念——开发应该自己先做单元测试和自测，再提交给测试工程师做集成测试。阿芳在做的是赋能开发，而不是单纯背锅。

下午 14:00 新需求：测试贷款流向预警模型

老赵上午开发完“贷款资金流向预警”模型（放款后15日内流向敏感对手方），提测了。

阿芳拿到需求文档和SQL脚本，开始设计测试用例。

业务口径：

  • 放款后15个自然日内

  • 累计流向敏感对手方金额 ≥ 放款金额 × 30%

  • 敏感对手方：小贷公司、担保公司、房地产开发商、公检法名单账户

测试策略：构造不同场景的数据，验证模型输出是否正确。

阿芳在测试数据库里造了几笔测试数据（test_loan_voucher + test_transaction_flow）：

测试场景 放款金额 流向敏感对手方金额 占比 预期结果
场景1：正常贸易 100万 0 0% 不预警
场景2：少量流向敏感方 100万 20万 20% 不预警
场景3：超过阈值 100万 40万 40% 预警
场景4：多笔累计超过阈值 100万 第一笔10万，第二笔25万 35% 预警
场景5：15天外发生 100万 第16天转出40万 40% 不预警
场景6：放款后立即全部转给小贷公司 100万 95万 95% 预警

她写了个脚本，把测试数据插入到临时表，然后运行老赵的ETL（指向测试表），再查询结果表，对比预期。

结果：

  • 场景1-5：✅ 通过

  • 场景6：❌ 失败——预警记录里没有这笔

阿芳排查：发现老赵的SQL里，敏感对手方名单表dim_sensitive_counterparty中，“小贷公司”关键词只匹配了“小额贷款公司”，而场景6里的对手方名称是“XX小额贷款有限公司”，多了一个“有限”，没匹配上。

阿芳在Jira上建缺陷：

  • 标题：贷款流向预警模型，小贷公司关键词匹配不完整（漏了“有限公司”后缀）

  • 严重程度：中（逻辑漏洞，建议优化关键词）

  • 指派给：老赵

老赵看到缺陷，回复：“感谢阿芳，我加个正则或者用模糊匹配。”

数据视角：数据测试不仅要验证“对不对”，还要验证“全不全”——边界条件、异常输入、特殊字符等都要覆盖。造数据是测试工程师的基本功。

下午 16:00 性能测试：看跑批多久能跑完

除了功能测试，阿芳还负责性能测试——确保ETL任务在规定时间内跑完。

今天她测的是“贷款流向预警”模型在全量数据上的运行时长。

她在预生产环境（数据量和生产接近）触发任务，计时：

任务 数据量 运行时长 预期时长 结论
关联借据+交易流水 5000万条 45分钟 30分钟 ❌ 超标

阿芳把结果发给老赵：“赵哥，这个任务跑了45分钟，超了15分钟。可能是两个大表join时没有用好分区裁剪，你看看SQL优化一下？”

老赵：“收到，我加个时间窗口过滤（只取最近一个月的交易流水），重跑试试。”

优化后：25分钟，通过。

数据视角：性能测试在数据领域极其重要，因为银行数据量大，一个烂SQL可能导致跑批超时，影响第二天开门营业。

下午 17:00 整理测试报告

阿芳今天的工作成果：

测试类型 用例数 发现缺陷 已修复 遗留
表内校验（EAST） 15 3（已修复） 3 0
总分校验（逾期指标） 1 1（已修复） 1 0
逻辑验证（贷款流向） 6 1（修复中） 0 1
性能测试 1 1（修复中） 0 1
回归测试 20 0 0 0

她把结果汇总到测试报告（Excel/共享文档），发给项目组：

测试结论：EAST借据表、逾期90天指标已通过测试，可上线。贷款流向预警模型存在关键词匹配不完整问题，建议修复后再次提测。

同时她在群里@老赵：“赵哥，流向预警那个缺陷你修好了告诉我，我再跑一遍全量回归。”

老赵回：“好的，明天上午给你。”

下午 17:45 写日报、准备下班

阿芳的日报：

text

【测试工程师日报】2025-05-23

一、今日完成
- EAST借据表表内校验，发现3个缺陷，已修复验证通过。
- 逾期90天指标总分校验，发现1个缺陷，已修复验证通过。
- 贷款流向预警模型逻辑测试，执行6个场景，发现1个缺陷（关键词匹配），已提单。
- 贷款流向预警模型性能测试，发现超时，已协助开发优化。

二、明日计划
- 跟踪贷款流向预警模型缺陷修复，进行回归测试。
- 编写下月EAST版本升级的测试用例（新增3张表）。

三、风险
- 信贷系统下月升级可能影响现有ETL逻辑，需要提前做全量回归测试。

数据测试工程师阿芳的一天，总结

时间段 做的事情 关键能力/工具
9:00-10:30 分析自动化测试报告，定位缺陷 校验SQL、业务口径理解
10:30-11:00 建缺陷单、与开发沟通 Jira、钉钉
11:00-12:00 回归测试、验证修复 SQL、回归用例集
12:30-13:00 与开发交流测试方法 沟通、赋能
14:00-16:00 新需求测试用例设计、造数据 边界值分析、场景构造
16:00-17:00 性能测试、协助优化 SQL分析、性能调优
17:00-17:30 整理测试报告、写日报 Excel、文档

一句话总结

数据测试工程师阿芳的工作，不是“给开发找茬”，而是为数据质量守门——确保每一张表、每一个指标、每一条预警规则，都符合业务口径和监管要求，并且在规定时间内跑完。她是数据开发的“第一道防线”，也是业务和技术的“翻译官”。

“银行各角色一天”系列现在补全了：

  • 柜员、行长、风险经理、客户经理、反洗钱专员

  • 大数据开发实习生、资深数据开发、数据测试工程师

你想听项目经理或产品经理的故事吗？或者我们回到技术话题，讲数据建模、性能调优？

继续讲故事：一表通负责人的一天

已思考（用时 7 秒）

用户想了解一表通负责人的一天。我需要基于已有的银行业务知识，结合最新的相关政策，创作一个生动的故事。为了全面获取信息，我需要同时进行多项搜索，涵盖一表通的建设进展、系统架构、数据要求、报送机制以及银行实践等方面。

搜索到 33 个网页

搜索结果显示了一些相关页面。为了全面了解一表通负责人一天的工作，我们需要同时打开这些页面。

浏览 11 个页面

【活动回顾】“筑牢数安底座，释放数据价值”2026金融业数据管理创新研讨会暨首届金融数据管理人年会成功召开

陕西省银行业协会组织开展银行机构监管报表“一表通”培训-协会要闻-协会动态-陕西省银行业协会

2026年一表通监管要求下的数据管理建设思路与策略讨论报告-刘贤荣

2026年一表通监管要求下的数据管理建设思路与策略讨论报告

方案架构_方案概述_金融-华为云

查看全部

这些资料提供了关于一表通的详细信息。我的回答将以故事的形式展现一表通负责人一天的工作。故事会涵盖从凌晨检查日报T+1数据、处理预警、晨会、与业务部门协调数据问题、与老赵讨论技术方案、复盘日报差异等环节，最后总结一表通负责人的关键能力和日常工作重点。

故事：一表通负责人老韩的一天

这个故事帮你理解：银行的一表通项目负责人每天在做什么？为什么一表通比传统的EAST、1104报送更紧急？为什么一表通会“倒逼”业务部门规范流程？

老韩，42岁，某城商行一表通项目负责人，科技部数据团队的技术骨干，兼一表通系统的“大总管”。他不只是写代码，还管系统建设、跟业务扯皮、盯数据质量、应对监管检查。在他的带动下，一表通建设不仅大幅减轻了基层负担，还推动了银行数据治理的全面改革-。

下面是他一天的真实写照。

凌晨 02:00 系统跑批（TP时刻）

虽然老韩在睡觉，但他手机监控APP的自动预警从来没关过。

银行核心系统每秒产生海量数据，一表通要求日报T+1报送，本质是倒逼银行练内功——平时数据随便记、快报送了才突击补录，在日频率采集模式下根本行不通-26。

一旦ETL任务失败，手机就会发出警报。老韩有两次半夜被叫醒的经历，一次是交易流水表迟迟没到账，另一次是信贷系统的字段突然变空，导致校验规则全部失效。他第二天还得照常上班。

数据视角：一表通报送涵盖10大主题、90张表、2224个字段，日报T+1、月报T+8报送--5。任何环节延迟都会触发预警。

早上 07:30 睁眼就看手机：日报跑通了吗

老韩醒了，第一时间打开手机上的一表通驾驶舱APP。

首要目标是确保监管能按日取数。屏幕显示：

报送批次 状态 记录数 质量校验通过率 耗时
2025-05-22日报 🟢 成功 380万条 99.7% 3h12min
2025-05-22月报（部分） 🟢 成功 120万条 99.9% 2h02min

老韩松了口气。他特别关注那0.3%的未通过数据，点进去查看详情，大多是敏感数据脱敏格式的问题，不致命，但要盯着整改。

他把日报成功率截图发到项目群：“今日日报可正常报送。”然后开始洗漱吃早饭。

数据视角：一表通系统在报送前会预生成可信区穿透层各类数据，检查数据的完整性和准确性，避免重复报送-。

上午 09:00 到工位：双区检查

老韩到办公室，首先登录一表通平台，检查报送区和可信区。

报送区是监管数据处理中心，核心功能是从核心、信贷、财务等多数据源采集数据，建立监管数据集市-30，并通过“五性校验”确保数据质量-30。

可信区是银行与监管端协同的数据存储中心，数据以分布式形态存储在银行端，降低监管端数据集中风险-30。

今天报送区的ETL日志里有一条告警：

“客户信息表与信贷合同表的‘客户号’关联失败，匹配率仅97.3%。”

老韩皱眉：剩下2.7%是数据孤岛，很可能客户在核心系统有账户，但在信贷系统里“客户号”被录错了。他给源系统负责人发了条消息：“有空帮我核对这323条客户信息差异。”

同时，他打开质量校验报告——一表通报送覆盖十个主题域、2224个字段-5。校验规则多达4367条，其中强制性校验3670条-5，任何偏差都要解释或修正。

老韩重点盯了三项核心指标：和1104历史数据比对的一致性、借款利率是否落在监管允许区间、通过X/Y/Z三种路径交叉验证是否结果一致。

数据视角：一表通要求业务账与会计账明细一致，监管数据工程涉及全行客户明细、协议明细、交易明细和账务明细采集，数据关联联络复杂-。

上午 10:00 开会：被业务部门“围攻”

周三是周例会。参会的有信贷部、个金部、计财部的业务骨干，还有项目组的同事。

信贷部朱经理一上来就吐槽：“你们一表通又退回我的数据了！说关联方担保信息不全。我不是填了吗？”

老韩打开系统，指给她看：“朱姐你看，关联担保人那张表里有12个字段，你们只填了4个。监管现在要从底层明细去看完整担保链，少填一个，整笔贷款的担保信息就识别不全。”

朱经理皱眉。一表通把银行的全流程业务数据都兜了进来，从客户开户填的第一张表，到贷款审批的每一个环节-26。因此，流程上的不足会直接导致一表通采集时出现数据缺失-26。不规范的业务操作必须以数据的形式补上，不可能让技术凭空造数据-26。

最终，双方达成共识：信贷部修订录入规范，老韩团队提供字段校验工具，从源头堵住缺失。

数据视角：监管驱动的“嵌入式监管”，要求银行将监管要求内化为日常业务规则-1。一表通的推行实现了以业务源头规范倒逼数据质量治理。

中午 12:00 食堂午餐，和技术团队交流

食堂里，老韩和骨干开发小赵边吃边聊。

小赵问：“韩哥，昨天日报跑批耗时比预期多了半小时，我查了一下，好像是大表校验那段卡住了。有没有办法优化一下？”

老韩放下筷子：“大表校验这块最怕跑死机。建议你加个动态分片——把客户信息表的2000万条记录拆成几百个小块并行跑，再智能跳过上个月没变更的数据，这样能节省35%的资源-32。”

小赵记下了。

数据视角：一表通通过三层技术架构（采集层、加工层、服务层）实现T+1报送-32，包括实时增量同步、分布式流水线加速、校验报送高速通道等技术手段-32。大银行的模式对中小银行有参考价值。

下午 14:00 双区联动：处理历史数据质量

下午，老韩和项目组的老赵开小会，讨论历史数据补录。

在一表通的旧系统切换过程中，需要将存量数据迁移到新的标准化结构里。过程中不可避免会遇到部分字段缺失、逻辑不匹配等“历史遗留问题”。

老韩说：“一表通试点时，业内有银行53%的字段无法匹配源系统-12，还有38%的指标无法追溯原始数据-20。历史数据补录占项目总预算40%-20。”

因此，他们决定分三步走：先给缺失字段设默认值，再重点补全近3年的数据，最后在源头系统增加校验规则防止新增。

老赵点头：“小周上次就是因为没看懂业务口径，才把MAX和MIN搞混。数据质量这件事得靠机制，不能靠个人。”

数据视角：一表通校验规则达4367条，其中强制性校验3670条-5。历史数据补录和源头系统校验是数据质量攻坚的关键环节。

下午 16:00 监管沟通：分析日报差异

快下班时，老韩接到监管局老师的电话。

“老韩，你们昨天日报的‘房地产贷款余额’和我们系统里其他行报送的数据对不上，差距有点大。你们核实一下口径。”

老韩赶紧调出昨天的数据，对比自家口径和监管的统计范围，发现是口径理解偏差，不是数据问题。他整理好差异说明，发给监管老师。

数据视角：一表通要求监管数据采集、审核、应用流程完全透明，报送数据需与现有1104、EAST和客户风险数据做一致性比对-。

晚上 18:30 总结：日更的威力

老韩关电脑前，回顾今天的情况。日报顺利完成，但历史数据改造迫在眉睫，业务协同是最大的挑战。一表通对银行数据治理提出多重挑战——数据质量要求高、源系统需明确监管相关字段、面临复杂校验规则与穿透式监管-4。

最让他感慨的是，以前按月报送，数据有问题还能周旋；现在日报T+1报送意味着监管能每天都看清楚银行，迫使银行前置治理，真正实现“数据即业务”-26。

他关灯，走出办公室，接到了明天讨论“月报T+8”任务的消息。

一表通负责人老韩的一天，总结

时间段 做的事情 体现的能力/角色
02:00-07:30 半夜监控跑批、清晨检查驾驶舱 运维保障、风险预警
09:00-10:00 检查报送区/可信区、分析质量报告 系统管理、数据分析
10:00-12:00 参加业务部门会议、解决协同矛盾 跨部门沟通、口径拉通
14:00-15:00 讨论历史数据补录、源头系统改造 架构规划、数据治理
16:00-17:00 与监管沟通口径差异 监管协同、问题定位
17:00-18:30 总结日报、规划月报 项目管理、标准制定

一句话总结

一表通负责人老韩的一天，就是确保监管每天都能看到银行最真实的数据——从凌晨的系统跑批、上午的跨部门“吵架”，到下午的历史数据补录，最终让监管从“按月查账本”升级为“按日看运营”。他的工作目标是把一表通从合规负担做成内部管理的价值引擎，让数据创造实际业务价值-20。

想继续听哪个角色的故事？比如数据治理专员、项目交付经理、还是监管沟通接口人？

项目交付经理

已思考（用时 2 秒）

我们要求用故事形式讲述“项目交付经理”的一天，帮助理解业务。需要结合银行数据开发/监管报送背景，体现项目交付经理的工作内容、挑战、协作等。保持之前故事系列风格，生动具体。

故事：项目交付经理老徐的一天

这个故事帮你理解：项目交付经理在银行数据项目中做什么？为什么他总在催进度、协调资源、安抚客户、化解风险？他不是写代码的人，但项目能不能按期上线，全看他。

老徐，38岁，某银行项目群的项目交付经理，管着EAST、一表通、反洗钱三个监管报送项目的交付。他手下有30多号开发、测试、运维。他不写SQL，但他得确保每个SQL在deadline前跑通。

他的口头禅是：“你们只管干，其他我来搞定。”但“其他”包括：跟行方要数据、跟监管解释延期、跟销售要预算、跟开发擦屁股。

早上 8:30 到工位：先看项目看板

老徐到办公室第一件事：打开项目管理系统（Jira + 自研看板），扫一眼三个项目的健康度：

项目 里程碑 计划完成 实际进度 偏差 风险
EAST 5.0升级 数据映射完成 5月20日 95% -2天 低
一表通（一期） 可信区部署 5月25日 80% -5天 高
反洗钱名单优化 联调测试 5月22日 100% 0 中

一表通一期滞后5天。老徐皱眉，点进去看详情：卡在“可信区网络策略申请”上——行方网络组还没审批通过，导致环境无法搭建，开发和测试全在等。

老徐立刻给行方科技部的网络主管打电话：“王老师，一表通可信区那台服务器的防火墙策略，我们上周三就提了，您看今天能批吗？再不批我们5月25号肯定交不了。”

王老师：“我手上十几个单子，你排第8。我先看看，今天下午给你答复。”

老徐挂了电话，在群里@所有人：“一表通环境还在等网络，大家先做其他模块，别闲着。”

数据视角：项目交付经理的核心工具是里程碑计划和风险日志。任何影响进度的阻塞都要第一时间升级处理。

上午 10:00 站会：三个项目轮流过

老徐主持项目站会（线上+线下）。

项目一：EAST 5.0升级

开发小周：“数据映射已经做完，还剩两个字段‘交易对手类型’和‘资金用途’口径没确认，需要业务老师定。”

老徐：“好，我约业务方下午2点开会，你带上备选方案。”

项目二：一表通（一期）

测试阿芳：“环境还没好，没法测。我们先把测试用例写完了，但执行不了。”

老徐：“环境我追，你们先把自动化脚本准备好，环境一好马上跑。”

项目三：反洗钱名单优化

开发老赵：“联调昨天完成了，今天让阿芳跑一遍回归测试，没问题明天就能上线。”

老徐：“上线窗口申请了吗？行方每周二四才给变更，明天是周三，要等下周二。我现在去申请。”

数据视角：项目交付经理要熟悉行方的变更管理流程——什么时候能上线、谁审批、需要哪些材料。错过一个窗口可能多等一周。

上午 11:00 处理紧急问题：客户投诉数据不对

合规部张姐气冲冲地走过来：“老徐！你们EAST报送的‘逾期90天以上贷款余额’怎么跟我台账差了2000万？监管都打电话问了！”

老徐心里咯噔一下——这是上个月上线的EAST 5.0新口径，要是错了就是生产事故。

他安抚张姐：“张姐别急，我马上调数据查。10分钟给您答复。”

然后他拉上老赵（开发）和阿芳（测试）开小会：“EAST逾期指标，业务说差了2000万，你们查一下原因。”

老赵：“我们用的口径是‘逾期天数≥90且未重组’，跟业务确认过的。”

阿芳：“我昨天跑过分总校验，ADS和DWD对得上啊。”

老徐让老赵把明细导出来，和张姐的台账逐笔对比。发现张姐的台账里，有一笔2000万的贷款，企业已经签了重组协议，张姐没算进去，但系统口径要求“重组中不算逾期”。张姐忘了这个规则。

老徐松了口气：“张姐，口径问题，系统是按之前确认的规则算的。要不我们开个会，把重组贷款的统计规则再明确一下？”

张姐有点不好意思：“行，是我记错了。辛苦你们。”

老徐在风险日志里记了一笔：“业务口径理解偏差导致投诉，后续加强变更通知”。

数据视角：项目交付经理要能快速组织技术排查，同时也要懂业务口径，否则无法判断是系统bug还是业务理解问题。

中午 12:30 吃饭，和销售聊项目延期

老徐和销售总监老刘一起吃饭。

老刘：“老徐，一表通一期延期5天了，行方科技总问我要进度，你怎么回？”

老徐：“不是我们开发慢，是行方网络审批卡住了。你要催也是催他们网络组。另外我们人力有点吃紧，下个月一表通二期要启动了，得加两个人。”

老刘：“行，我跟行方申请追加预算。你先保证一期别拖过6月。”

老徐点头。他明白，项目延期客户会扣钱，而且影响公司口碑。

数据视角：项目交付经理要平衡客户期望、公司利润、团队士气。延期、加人、加预算，都要跟销售协同。

下午 14:00 开业务口径会：EAST两个字段

老徐约了合规部、信贷部、风险部的业务老师，一起确认EAST那两个模糊字段。

第一个字段：“交易对手类型”

信贷部：就是“对公/对私/金融机构”三种。

合规部：监管要求细到“集团客户/关联方/普通企业”，你们得区分。

双方争了20分钟。

老徐打圆场：“要不我们折中：能关联到集团客户的就填‘集团客户’，能关联到关联方的填‘关联方’，其他的填‘普通企业’。技术上我们能实现，关联关系表我们已经有。”

业务同意。

第二个字段：“资金用途”

风险部：监管要填“流动资金/固定资产投资/并购/其他”。

信贷部：我们的系统里只有自由文本，没有分类。

老徐：“那我们先按关键词匹配自动打标，匹配不上的业务手工补录。这样行不行？”

最终达成一致。老徐把会议纪要发到群里，让开发按此实现。

数据视角：项目交付经理要能引导业务达成共识，而不是让技术和业务互怼。他是项目的“翻译官”和“润滑剂”。

下午 16:00 项目周报：向行方汇报

老徐每周三下午要给行方科技部汇报项目进展。他打开PPT，准备材料：

EAST 5.0升级：进度95%，预计5月28日上线（比原计划晚2天，因口径确认延迟）。

一表通一期：进度80%，滞后5天（因网络审批），已升级处理，预计6月2日完成。

反洗钱名单优化：进度100%，已申请下周二上线窗口。

风险与应对：

  • 网络审批风险：已与行方网络组沟通，承诺周五前解决。

  • 业务口径风险：已通过专题会解决，后续加强提前沟通。

  • 人力风险：一表通二期需增2人，已与销售沟通。

老徐在汇报时特别强调：“一表通一期虽然延期，但我们追回了部分时间，最终只晚3天，不影响二期启动。”

行方科技总点头：“可以接受，但二期不能再延期了。”

数据视角：项目交付经理的汇报要诚实但乐观——报问题也要报解决方案，让客户放心。

下午 17:30 总结今日，安排明天

老徐在项目群里发今日总结：

text

【项目交付日志】2025-05-23

一、今日关键事项
- EAST：业务口径会议达成一致，开发明早开始改。
- 一表通：网络审批跟进行方，预计周五解决。
- 反洗钱：联调完成，申请下周二上线。

二、明日计划
- 上午：跟进网络审批，准备一表通环境搭建。
- 下午：EAST字段修改完成，提交测试。
- 下班前：更新项目计划，同步行方。

三、风险提醒
- 一表通若周五网络还不批，需要行方领导介入。
- EAST上线窗口需提前申请（下周四）。

然后他关掉电脑，去接孩子放学。

项目交付经理老徐的一天，总结

时间段 做的事情 体现的能力/角色
8:30-9:00 看项目看板，识别风险 项目管理、风险识别
9:00-10:00 追网络审批，协调资源 沟通协调、问题升级
10:00-11:00 站会，过三个项目进度 多项目并行管理
11:00-12:00 处理业务投诉，快速定位 问题排查、业务理解
14:00-15:30 主持业务口径会，达成共识 需求拉通、冲突调解
16:00-17:00 准备周报，向行方汇报 向上沟通、预期管理
17:00-17:30 写日志，安排明日 执行力、闭环思维

一句话总结

项目交付经理老徐的一天，就是在客户、开发、测试、运维、销售之间来回跑——催进度、拉资源、平争议、报风险。他不是英雄，但项目能上线，他功不可没。他的价值不是写代码，而是让代码在正确的时间、正确的质量下，交付到正确的人手里。

“银行各角色一天”系列又添一员：

  • 柜员、行长、风险经理、客户经理、反洗钱专员

  • 大数据开发实习生、资深数据开发、数据测试工程师

  • 一表通负责人、项目交付经理

你想听数据治理专员、解决方案架构师，还是监管沟通接口人的故事？

讲一个央行或金融监管部门临时检查的故事，监管视角

已思考（用时 2 秒）

我们要求讲一个央行或金融监管部门临时检查的故事，监管视角。需要体现监管部门如何检查银行，检查什么内容，以及银行如何应对。故事要真实可信，有细节。可以结合之前提到的监管报送（EAST、一表通、反洗钱等）。从监管人员角度出发，描述一次突击检查。

故事：央行监管员的突袭检查

这个故事帮你理解：监管部门怎么查银行？不是看报表，而是直接查底层数据。一旦发现问题，轻则整改，重则罚款甚至停业。

老郑，45岁，中国人民银行某分行金融稳定科的副调研员。他干了20年监管，经手过大大小小几十次检查。他最擅长的不是看银行的总结报告，而是直接扎进数据里找问题。

这天早上8点半，他接到科长电话：“老郑，准备一下，今天去XX银行，临时检查。重点看房地产贷款和不良资产处置。9点半出发。”

老郑心里有数了。临时检查，就是不提前通知，杀个措手不及。

第一幕：出发前，先“云检查”

老郑没有直接去银行。他先打开EAST系统和一表通监管端，远程调出这家银行最近三个月的数据。

他主要看三样东西：

  1. 房地产贷款集中度：有没有超标？

  2. 不良贷款迁徙率：正常类有多少下迁到关注？关注有多少下迁到不良？

  3. 借据表里“五级分类”调整记录：有没有在季末突击调分类？

几分钟扫下来，他发现了三个疑点：

  • 某房地产集团的贷款余额，比上个月猛增20%，可能触碰了集中度红线

  • 有一笔5000万贷款，上个月还是“正常”，这个月突然变成“损失”——跳过“关注、次级、可疑”，直接核销？不合规

  • 该行不良贷款率连续两个季度维持在1.8%，非常平稳，但同区域其他银行都在上升——过于平滑，可能有“藏匿”不良的嫌疑

老郑把这些疑点截屏，存进检查底稿。

监管视角：EAST和一表通让监管可以“非现场”先筛查，带着问题去现场，而不是到了银行再盲目翻账。

第二幕：到银行，亮证、封账、要数据

上午10点，老郑和两位同事到了XX银行总行。

银行科技部老总迎出来：“郑老师，怎么没提前通知？我们好准备材料。”

老郑笑笑：“没事，我们就随便看看。麻烦您把上月末的贷款明细账、五级分类台账、房地产贷款清单、不良资产处置台账调出来。还有，我们可能要查一下核心系统的日志。”

这是数据现场检查的标准动作。老郑的同事打开自带的笔记本电脑，连上银行的数据查询平台（有监管专用只读账号），开始跑SQL。

老郑则找信贷部老总谈话。

第三幕：对质，查分类下调逻辑

老郑：“王总，你们行有一笔XX房地产公司的贷款，5000万，上个月还是正常，这个月直接调到损失。这中间的逻辑是什么？按监管规定，从正常到损失，必须经过‘关注、次级、可疑’逐级下调，而且每次下调都要有充分依据。你们有没有逐级审批记录？”

王总额头冒汗：“这个……可能是系统自动跑的，我们回头查一下。”

老郑：“EAST系统里能看到每一次分类调整的操作人、操作时间。你们是人工调的，还是系统自动的，我一查便知。”

下午2点，同事小张跑完数据，发现这笔贷款的分类调整确实跳过了“可疑”——从关注直接变成损失。操作人是一个客户经理，没有审批记录。

老郑在检查底稿上记下：“违规调整五级分类，规避拨备计提。拟要求整改并问责。”

第四幕：查不良资产处置，发现假出表

老郑又盯上了另一笔贷款：1.2亿，已认定为不良。银行台账显示，这笔贷款已经打包转让给了某资产管理公司，从表内移出。

老郑：“转让协议和资金流水给我看看。”

银行提供了转让协议，但资金流水显示，资产管理公司支付的对价，来自某信托计划；而该信托计划的资金，又来自该银行的理财产品。

这就形成了闭环：银行用理财资金，通过资管公司接盘自己的不良资产——本质是“假出表”，不良资产还在银行自己手里，只是账面消失了。

老郑问：“王总，这笔转让的交易结构，麻烦解释一下。理财资金接盘不良，合规吗？”

王总脸都白了：“郑老师，这是总行批准的……具体操作我不太清楚。”

老郑在底稿上又记一笔：“违规虚假出表，掩盖不良资产。”

第五幕：查数据质量，发现EAST报送造假

同事小张跑完EAST数据，又发现一个问题：银行报送的EAST“贷款行业分类”字段，与核心系统里的原始数据不一致。

小张把EAST导出文件和核心系统明细做比对，发现房地产贷款被大量归入‘制造业’、‘批发零售业’——明显是为了躲避房地产贷款集中度监管。

老郑把对比表打印出来，摆在王总面前：“王总，你们报送EAST的行业分类，怎么跟核心系统里的不一样？这是谁改的？”

王总说不出话。

老郑：“数据造假，性质很严重。我们回去要写专题报告。”

第六幕：检查结束，初步反馈

下午5点，老郑召集银行相关人员，做了个初步反馈：

“今天我们主要看了三块：五级分类调整、不良资产处置、EAST数据质量。发现了一些问题：分类调整不合规、不良资产处置存在闭环交易、EAST行业分类涉嫌造假。这些问题我们会带回分局进一步研判。请你们明天之前提供书面说明，配合后续调查。”

老郑顿了顿，补充道：“这不是最终结论，但问题确实存在。希望你们正视，不要试图掩盖。”

王总低着头签字确认。

第七幕：检查之后

两周后，老郑所在的央行分行对这家银行做出行政处罚决定：

  • 罚款420万元（EAST数据造假250万，五级分类违规100万，不良假出表70万）

  • 责令问责相关人员：信贷部老总记过，客户经理降级，数据报送员警告

  • 要求三个月内整改：重调五级分类，还原不良资产，重报EAST数据

银行发布了整改公告，股价跌了2%。

老郑则在内部总结会上说：“EAST和一表通就是我们的眼睛。银行以为改个数据神不知鬼不觉，但我们在后台看得一清二楚。数据质量，就是监管的生命线。”

监管视角的关键工具

监管工具 怎么用 能发现什么问题
EAST系统 远程查看银行明细数据，跑SQL分析 五级分类跳级、行业分类造假、关联交易
一表通 日报T+1，实时监控银行每日数据变化 存款异常波动、贷款集中度超标
现场数据检查 直接查询核心系统、比对源数据 EA区ST与核心系统不一致、数据篡改
资金穿透 追踪不良资产转让的资金来源和去向 假出表、理财资金接盘不良
日志审计 查看系统操作日志，谁在什么时候改了什么 非授权操作、数据篡改痕迹

一句话总结

监管人员老郑的一天，就是带着数据和规则，去银行“对账”——看你的五级分类有没有跳级、不良资产有没有假出表、报送数据有没有造假。EAST和一表通就是他的“千里眼”，银行在数据里做的手脚，他在后台一眼就能看穿。一旦被查出问题，轻则罚款，重则停业整顿。

你想听哪个岗位的故事？数据治理专员、解决方案架构师，还是业务需求分析师？

我的银行业务AI虚构小故事，还缺重要角色吗，对我理解银行大数据开发的业务来说

你愿意用虚构故事来理解银行大数据开发，说明你已经找到了很有效的学习方式。关于“缺不缺重要角色”，我的判断是：看你故事聚焦的业务场景，但有几个通用角色容易被忽略。

我先把你之前可能已经听过的“银行一天”系列角色列出来（这是我讲过或常见的）：

  • 业务前台：柜员、客户经理（对公/零售）、行长

  • 风险合规：风险经理、反洗钱专员、合规部、资产保全部

  • 数据科技：大数据开发实习生、资深数据开发、数据测试、一表通负责人、项目交付经理、数据治理专员（我还没详细讲）

  • 监管：央行/监管局检查人员

如果你自己写的虚构故事里只出现了“开发人员 + 业务提需求的人”，那么可能缺少以下几类对理解大数据开发很关键的角色：

1. 数据治理/元数据管理员

  • 他管什么：字段命名规范、数据字典、数据血缘、数据标准。

  • 为什么重要：你在开发中会发现“同一个‘客户号’在核心系统叫CUST_NO，在信贷系统叫KH_ID，在信用卡系统叫CARD_HOLDER_ID”。没有数据治理的人，你永远在手工对齐字段。

  • 故事中可以出现的场景：你写的ETL突然报错，因为源表字段改了但没人通知。你去问数据治理的人，他查元数据中心告诉你：“昨天核心系统变更了五级分类字段名，我们还没来得及发通知。”

2. 业务需求分析师/产品经理（BA）

  • 他做什么：把业务人员的口语（“我想看逾期的客户”）翻译成可落地的数据需求（“逾期=借据表里当前逾期天数≥1天且未结清，统计客户数”）。

  • 为什么重要：开发最怕的是业务说“我要A”，你做完后他看了说“不对，我要的是B”。BA就是中间那个“确认口径”的人。

  • 故事场景：合规部张姐说“我要逾期90天以上贷款余额”，BA跟你确认：“是按首次逾期日还是最近逾期日？包不包含重组中的借据？”——帮你避免返工。

3. 源系统负责人（核心/信贷/信用卡系统接口人）

  • 他负责什么：每个源系统（核心、信贷、信用卡）都有一个负责人，他知道自己系统的表结构、数据特点、变更计划。

  • 为什么重要：你从ODS取数，发现某张表数据对不上。最有效的方式不是自己猜，而是直接找源系统负责人：“你们系统最近是不是改了交易类型的枚举值？”

  • 故事场景：你的ETL任务突然少了一半数据，源系统负责人告诉你：“昨天我们上线了新版本，有一批交易的标志位从‘1’改成了‘2’，你没适配。”

4. 数据安全/脱敏专员

  • 他管什么：个人客户信息（姓名、身份证号、手机号）的脱敏规则；哪些字段开发能看到明文，哪些只能看密文。

  • 为什么重要：你在开发环境直接查客户真实姓名可能违规。你需要知道生产数据脱敏后才能用到开发/测试环境。

  • 故事场景：你写SQL查客户明细，数据安全专员找到你：“你怎么直接用了真实姓名字段？要用姓名_脱敏，否则违反《个人信息保护法》。”

5. 运维/调度平台管理员（不是数据开发但会影响你）

  • 他管什么：调度任务（DataWorks/Airflow）的资源配置、队列、告警。

  • 为什么重要：你的任务跑慢了、跑挂了，需要他帮你调并发、重跑历史分区、排查集群故障。

  • 故事场景：你重跑昨天失败的ETL，发现队列堵了。运维告诉你：“现在高峰时段，你的任务优先级是‘中’，等半小时。”

对你理解银行大数据开发的业务来说，缺了这些角色会怎样？

缺失的角色 你可能会遇到的困惑（故事里没体现的）
数据治理 “为什么不同系统的同一字段名字不一样？谁说了算？”
BA/产品经理 “业务说的口径改了，没人告诉我，我白做了三天。”
源系统负责人 “ODS层数据错了，我不知道该找谁修。”
数据安全专员 “我写了个报表，里面带了客户手机号，合规说不能发。”
运维 “任务跑崩了，我不知道是资源不够还是代码问题。”

建议你补充一个“数据需求沟通与确认”的场景

在你的故事里，可以加入这样一个小情节：

业务方（合规部张姐）提需求：“我要逾期客户的名单。”
BA（小王）拦住她：“姐，您说的是‘逾期1天以上’还是‘逾期90天以上’？包含已经核销的吗？是按客户维度还是按借据维度？”
张姐明确了口径。
你（开发）根据确认后的口径写SQL，一次通过。

这个场景虽然简单，但会帮你理解银行大数据开发中最耗时的不是写SQL，而是“口径对齐”。

最后回答你的问题

  • 缺吗？ 如果你的故事里只有“开发+业务提需求的人”，那确实缺了中间翻译、元数据管理、源系统协调、安全合规、运维支持这些角色。

  • 对你理解业务帮助大吗？ 这些角色背后的数据治理、口径管理、数据安全、跨系统协调，正是银行大数据开发区别于互联网公司的地方。把它们加进去，你的故事会更贴近真实工作。

没有故事大纲，就是整理了你讲的“银行的一天”系列角色。

我们确认用户所说：他整理了之前讲的“银行的一天”系列角色，想知道是否缺少重要角色。根据之前的对话，已经讲过的角色包括：柜员、行长、风险经理、客户经理、反洗钱专员、大数据开发实习生、资深数据开发、数据测试工程师、一表通负责人、项目交付经理、监管人员（央行检查）。可能还缺一些典型角色如数据治理专员、业务分析师/产品经理、源系统负责人、数据安全专员等。用户问的是“还缺重要角色吗”。需要给出建议，指出哪些角色对理解大数据开发业务很重要但尚未涵盖，并解释为什么。

这个系列目前已经覆盖了 业务前台、风险合规、数据科技、监管检查 四大类，但对于“理解银行大数据开发的业务”来说，还缺几个关键角色。

我先列一下你已有的角色清单，再补充缺失的重要角色，最后说明为什么缺了它们会限制你对业务的理解。

你已经有的角色（按我讲过的顺序）

角色 所属领域 在数据开发中的价值
柜员 业务前台 理解交易产生的源头数据
客户经理 业务前台 理解存款、贷款、代发等业务怎么来的
行长 管理层 理解银行的核心KPI（存款、贷款、中收、不良）
风险经理 风险合规 理解贷后管理、五级分类、预警规则
反洗钱专员 风险合规 理解反洗钱规则、可疑交易上报
监管检查人员 监管 理解监管怎么查数据、罚什么
大数据开发实习生 数据科技 理解新人如何写ETL、踩坑
资深数据开发 数据科技 理解架构设计、性能优化、带人
数据测试工程师 数据科技 理解数据质量校验、口径验证
一表通负责人 数据科技 理解T+1日报送、可信区、监管协同
项目交付经理 项目管理 理解进度、风险、客户预期管理

我认为还缺的重要角色（至少3个）

1. 数据治理专员/元数据管理员

为什么重要？

  • 银行数据开发最头疼的问题之一：同一个业务概念，在不同系统里字段名、含义、格式都不一样。

  • 数据治理专员就是制定“数据标准”的人——规定“客户号”全行统一叫什么、什么格式、取值范围。

  • 没有这个角色，你的故事里会缺少“为什么我的表关联不上？因为核心系统的客户号和信贷系统的客户号长度不一样”——这是一个非常真实的痛点。

可以加的故事场景：

小周（开发）写的ETL突然报错，因为源表把五级分类字段改名了。他去问数据治理专员老杨，老杨查了元数据中心：“核心系统昨天上线了新版本，字段名从五级分类改成了risk_classify，我们还没来得及发变更通知。你先按新字段名改，以后每天早上记得看元数据变更公告。”

2. 业务分析师/产品经理（BA）

为什么重要？

  • 业务人员（如合规部张姐）提的需求往往是模糊的：“我要逾期客户的名单。”

  • BA的职责是：把模糊的业务需求，翻译成明确的数据口径——逾期是指逾期1天还是90天？包含已核销的吗？按客户去重还是按借据？

  • 没有BA，你的故事里会缺少“需求澄清”这个关键环节，而实际工作中这占了大量时间。

可以加的故事场景：

张姐提需求：“我要逾期90天以上的贷款余额。” BA小王马上追问：“是按首次逾期日还是最近逾期日？重组中的借据算不算？要不要分行业？” 张姐明确了口径后，小王才把需求文档交给开发。小周照着文档写SQL，一次性通过。

3. 源系统负责人（核心/信贷/信用卡接口人）

为什么重要？

  • 银行的数据来自多个源系统（核心、信贷、信用卡、理财、总账…）。每个系统都有自己的负责人。

  • 当ODS层数据出现问题时，开发不能自己“猜”，必须找源系统负责人确认——是源系统数据错了，还是同步任务出了问题？

  • 没有这个角色，你的故事里会缺少“数据问题排查的协作链条”。

可以加的故事场景：

小周发现DWD层的交易流水表少了30%的数据，他找源系统负责人老刘。老刘说：“昨天核心系统上线了新版本，有一批交易的标志位从‘1’变成了‘2’，你们的ETL没适配，过滤掉了。” 小周修改逻辑后数据恢复正常。

可选但很有价值的角色（根据你的业务场景补充）

角色 为什么可能有用 是否必要
数据安全/脱敏专员 个人客户信息（姓名、手机号）不能随便查，需要脱敏。开发环境看不到真实数据，测试要构造脱敏数据。 如果你关注合规和数据安全，建议加
运维/调度平台管理员 ETL跑慢了、跑挂了，需要调资源配置、重跑历史分区。开发自己通常没有权限。 如果你想展现“ETL生产保障”环节，可以加
外部数据供应商接口人 银行会采购征信、工商、税务等外部数据。接口人负责对接、校验数据质量。 如果你的故事涉及风控模型依赖外部数据，建议加

结论：缺不缺？

如果你只是理解“银行大数据开发日常要跟哪些人打交道”，你已有的角色已经覆盖了70%～80%的场景，不算严重缺失。

但如果你想让故事更真实、更贴近数据开发工作中的核心痛点（口径对齐、数据治理、多源系统协调、数据质量检核），那么我建议至少补充“数据治理专员 + BA + 源系统负责人”这三个角色。它们会帮你理解为什么银行大数据开发不仅是写SQL，还要花大量时间在“沟通、确认、查源头”上。

你想让我帮你用这三个新角色，重新串一个小故事吗？比如“小周的一天（完整版）”，把数据治理、BA、源系统负责人加进去，展示一次真实的需求开发全流程？

需要

我们接受用户请求，需要基于之前已有角色和新增的角色（数据治理专员、BA、源系统负责人）重新串一个小故事，以“小周的一天（完整版）”展示真实的需求开发全流程。需要涵盖从需求提出、口径澄清、设计开发、测试验证、生产部署、数据问题排查等环节，体现多个角色之间的协作。注意符合小周实习生/新人设定的成长性。要求内容详实、生动。

小周的一天（完整版）

这个故事融合了“银行一天”系列里已有的角色，并补充了数据治理专员、业务分析师（BA）、源系统负责人三个关键角色。帮你理解：一个真实的数据开发需求，从业务提出到上线，要跟多少人打交道？

小周，22岁，某银行项目组大数据开发实习生。他入职已经三周，会写SQL，但还在学“怎么跟银行的人打交道”。

今天他接到了一个需求——来自合规部张姐的：“我要一个逾期90天以上贷款余额的报表，按分行展示，每个月更新。”

第一幕：需求来了，谁接？

早上 9:00

小周打开Jira，看到一个新任务：【EAST补充需求】逾期90天以上贷款余额统计。指派给：小周。

他还没来得及看详情，项目经理老徐就在群里@他：“小周，这个需求你负责。先去跟业务分析师（BA）小王对齐口径，别直接写代码。”

小周找到小王。

小王，28岁，BA岗，专门负责把业务需求翻译成开发能做的数据口径。他问小周：“业务提的需求你看了吗？”

小周：“看了，就一句话，‘逾期90天以上贷款余额’。”

小王笑了：“银行里‘逾期90天’至少有5种定义。你直接写SQL，合规部肯定打回来。走，我们去问张姐。”

新增角色1：业务分析师（BA）——在业务和开发之间搭桥，把模糊需求变成可落地的数据口径。

第二幕：口径确认，和业务聊

上午 9:30

小王带着小周去找合规部张姐。

小王：“张姐，您提的‘逾期90天以上贷款余额’，我们有几个细节想跟您确认一下。”

确认点1：逾期天数从哪天开始算？

  • 张姐：“从首次逾期日开始算。比如一笔借据，1月1日没还，2月1日也没还，到了4月1日，逾期天数就是90天（从1月1日算起），不是30天。”

  • 小王记下：逾期天数 = 当前日期 - 首次逾期日（最早一期未还的应还款日）。

确认点2：重组中的借据算不算？

  • 张姐：“如果借据已经签了重组协议，并且重组后正常还款，那就不算逾期。”

  • 小王记下：排除重组中且正常履约的借据。

确认点3：按客户维度还是借据维度？

  • 张姐：“按借据维度。一笔借据逾期，只计这一笔的余额。不用合并到客户级。”

  • 小王记下：粒度 = 借据级。

确认点4：已核销的借据算不算？

  • 张姐：“不算。核销的已经出表了，不计入贷款余额。”

  • 小王记下：排除核销、结清的借据。

小王把确认结果整理成口径确认单，张姐签字。然后他对小周说：“好了，按这个写SQL。表用dwd_loan_voucher_di（借据表）和dwd_repay_plan_di（还款计划表）。注意使用MIN(应还款日)找首次逾期日，之前老赵教过你。”

小周点头。他心想：如果没有小王，他直接写SQL肯定会把“首次逾期日”写成“最近逾期日”，全错。

关键产出：口径确认单。这是开发、测试、业务三方对齐的依据。

第三幕：写代码，遇到字段问题

上午 10:30

小周回到工位，打开SQL编辑器。他按照口径写了一个大概：

sql

WITH first_overdue AS (
    SELECT 借据号, MIN(应还款日) as 首次逾期日
    FROM dwd_repay_plan_di
    WHERE 是否已还 = '未还'
    GROUP BY 借据号
)
SELECT 
    v.机构号,
    SUM(v.余额) as 逾期余额
FROM dwd_loan_voucher_di v
JOIN first_overdue f ON v.借据号 = f.借据号
WHERE v.借据状态 NOT IN ('核销','结清','重组中')
  AND v.余额 > 0
  AND DATEDIFF(CURRENT_DATE(), f.首次逾期日) >= 90
GROUP BY v.机构号;

他信心满满地准备提交，但忽然发现：dwd_loan_voucher_di表里没有机构号字段，只有客户号。而客户在哪个分行，存在客户信息表里。

他需要关联客户信息表才能拿到分行。但这个表的客户号字段叫CUST_ID，而借据表里的客户号叫KH_NO——字段名不统一。

小周懵了。他想起之前听老赵提过数据治理专员，说是管字段规范的。他去找数据治理专员老杨。

新增角色2：数据治理专员——统一全行的字段命名、数据标准，解决“同一个东西在不同表里叫不同名字”的问题。

第四幕：数据治理来救场

上午 11:00

老杨，40岁，数据治理专员，办公桌上一堆数据标准和元数据文档。

小周：“杨哥，借据表里的客户号叫KH_NO，客户信息表里的客户号叫CUST_ID，我关联的时候用哪个？”

老杨打开元数据管理平台，查了一下：

  • 借据表.KH_NO = 客户号（信贷系统源字段）

  • 客户信息表.CUST_ID = 客户号（核心系统源字段）

  • 标准名称：customer_id（数仓统一命名）

老杨：“理论上，DWD层的客户号应该已经统一成customer_id了。你看看dwd_loan_voucher_di有没有一个字段叫customer_id？”

小周一看，果然有。他自己没注意。

老杨：“我们数据治理组上半年已经把核心的字段都标准化了。你以后写SQL，优先用标准化字段，不要直接引用源系统的字段名。这个文档——《企业级数据标准V2.0》——你回去看第三章。”

小周连连道谢。他改用customer_id关联，问题解决。

关键产出：数据标准文档。数据治理让开发不再被字段名混乱困扰。

第五幕：测试验证，又出幺蛾子

下午 14:00

小周写完SQL，提交到测试环境。数据测试工程师阿芳开始跑校验。

阿芳跑完总分校验（ADS汇总 vs DWD明细汇总），发现差异：ADS层按分行汇总的逾期余额是5.2亿，但从DWD明细直接聚合只有5.0亿，差了2000万。

阿芳把结果发给小周：“小周，你的SQL有问题。XX分行多算了2000万。”

小周查了半天，发现XX分行有一笔借据，逾期天数算出来是90天，但业务上这笔借据已经签了重组协议，应该在“重组中”被排除。但他的WHERE条件里只排除了借据状态=重组中，而这笔借据的状态还是正常（业务忘了改状态）。

小周去找源系统负责人老刘。

新增角色3：源系统负责人（核心/信贷系统接口人）——负责解释自己系统的数据逻辑，协助排查数据问题。

第六幕：源系统负责人排查

下午 15:00

老刘，信贷系统负责人，对信贷系统的表结构、业务规则门儿清。

小周：“刘哥，有一笔借据J12345，企业已经签了重组协议，但系统里借据状态还是‘正常’，没有改成‘重组中’。这是不是数据错了？”

老刘查了一下信贷系统的操作日志：“这笔重组的流程还没走完——审批过了，但系统里状态还没同步。我们的作业流程是：线下签完协议，业务员要在系统里手动更新状态，他们可能忘了。我通知信贷部补录一下。”

小周：“那我这个需求怎么办？没改状态之前，这笔逾期余额会多算2000万。”

老刘：“你跟BA商量一下，看能不能先用‘是否有重组协议’这个标志位来判断？我们系统里有一个reorganization_flag字段，重组的会打Y。”

小周回去找BA小王，小王又去问张姐。张姐同意：如果借据状态来不及改，先用重组标志位排除。

小周修改SQL，加了条件AND reorganization_flag != 'Y'。重新跑测试，数据对上了。

关键产出：明确了数据问题的根因（业务未同步状态），并找到临时解决方案（用重组标志位）。

第七幕：生产上线，监控

下午 16:30

小周的SQL通过测试，准备上线。项目经理老徐帮他申请了上线的变更窗口（每周二、四）。

上线前，老徐让小周在调度平台上把任务配置好：每天凌晨2点跑，依赖上游dwd_loan_voucher_di和dwd_repay_plan_di任务完成。

小周配置完，老徐审核通过。

晚上10点，小周在家收到监控告警：新任务跑失败了。他远程登录VPN查看日志，发现是上游任务的产出表还没准备好（依赖等待超时）。他调整了任务的依赖配置（增加等待时间），重新触发。凌晨1点，任务成功。

他在群里发消息：“逾期90天指标已上线，今日数据正常产出。”

小周一天的角色协作图

text

业务需求（合规部张姐）
        ↓
【BA 小王】澄清口径，输出口径确认单
        ↓
【数据治理 老杨】提供字段标准，解决命名混乱
        ↓
【开发 小周】写SQL，ETL实现
        ↓
【测试 阿芳】执行总分校验，发现差异
        ↓
【源系统负责人 老刘】排查数据问题，解释原因
        ↓
【项目经理 老徐】申请上线窗口，审核配置
        ↓
【运维/调度管理员】（暗线）保障任务跑批
        ↓
生产上线 → 监控告警 → 小周修复

总结：缺失角色对故事的影响

如果没有这个角色 故事里会缺什么 实际工作中的后果
BA 需求模糊直接开发，业务说“这不是我要的” 返工、延期、业务投诉
数据治理 字段名混乱，不知道关联哪个字段 开发效率低，SQL写错
源系统负责人 数据错了不知道找谁修 问题卡住，无法推进
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

大模型推理成本砍 90%！2026 年最实用的 7 个优化技巧

2026年大模型推理成本优化7大技巧 随着大模型规模化应用，推理成本成为企业核心痛点。本文提出7个实用优化方案： 提示词瘦身：结构化输入减少30%无效Token 动态批处理：vLLM连续批处理使GPU利用率提升至75%+ 语义缓存：向量检索拦截40%-60%重复请求 4-bit量化：显存占用降60%而精度损失<0.5% 投机采样：小模型预生成使大模型推理提速2-3倍 置信度早停：实时监控输出可缩短

avatar AtomGit开源社区

Gauge Phase Divergence: A Training-Free Geometric Fingerprint for Real-Time Contradiction Detection

Retrieval-augmented generation (RAG) systems fail to detect causal contradictions on edge devices: vector similarity ignores polarity, while NLI methods are too computationally heavy. We present Gauge

avatar AtomGit开源社区

登录鉴权-ai

登录:客户端 → 网关(白名单放行) → Auth-Service→ 校验密码 → 查角色 → 签发AccessToken+RefreshToken → Redis存RefreshToken← 返回双Token访问业务:客户端(带AccessToken) → 网关→ 清洗伪造Header→ 本地验签(双密钥fallback)→ 查jti黑名单(200ms超时,异常降级)→ 查用户级失效时间戳→ 写

avatar AtomGit开源社区