1. 项目概述：这不是一次简单的数据搬运，而是一场风险信号的精准捕获
“关于金融风险数据的ETL到分析（下）”——这个标题里藏着三个关键动作：ETL、风险、下篇。它不是教你怎么把Excel拖进数据库，而是直指金融风控场景中最棘手的一环：如何把散落在不同系统、不同格式、不同更新节奏里的风险相关数据，清洗成可信、可比、可建模的分析底座，并最终支撑起真正能预警、能归因、能决策的风险洞察。我做过不下二十个银行、保险和持牌消金公司的风控数据项目，最常听到的抱怨不是“不会写SQL”，而是“数据对不上”“指标口径打架”“模型上线后效果断崖下跌”——这些问题90%都出在ETL这一环没做扎实。所谓“下”，意味着上篇已解决基础链路搭建与源系统探查，本篇聚焦的是真实业务中高频、高危、高价值的实战攻坚点：非结构化风险事件文本的语义解析、多源逾期数据的时间对齐与状态归因、监管报送字段的动态映射逻辑、以及如何让整个ETL流程具备可审计、可回溯、可干预的生产级健壮性。它适合三类人：正在搭建风控数据中台的工程师、需要向管理层解释“为什么模型结论和业务感知不一致”的风控分析师、以及想跳过PPT汇报、直接看懂底层数据逻辑的业务负责人。你不需要是Python专家，但得愿意拆开一个字段的生命周期，看它从信贷系统生成、经由日志埋点、被调度任务抽取、在清洗脚本中被重定义、最终出现在BI看板上的全过程。
2. 内容整体设计与思路拆解：为什么必须放弃“管道思维”，转向“风险语义流”设计
很多团队一上来就猛写Airflow DAG或Kettle作业，结果跑通了，产出的数据却没人敢用。问题出在顶层设计——把ETL当成一条单向流水线，而忽略了金融风险数据的本质是带时间戳、带因果链、带业务规则约束的语义网络。我们最终采用的方案叫“三层语义流架构”，它不是技术炫技，而是被踩坑逼出来的：
2.1 第一层：源系统语义锚定层（解决“数据从哪来、代表什么”）
- 不做盲目抽取：比如某银行核心系统有37个字段叫“status”，分布在5个表里，但含义完全不同——有的是贷款审批状态，有的是还款计划状态，有的是账户冻结状态。我们强制要求每个抽取任务必须附带一份《源字段语义说明书》，由业务方签字确认，明确字段的业务定义、有效值域、变更触发条件（如“status=4”仅在人工贷后介入后置为4）、以及与其他字段的逻辑依赖（如“overdue_days>0”必须伴随“status in (3,4,5)”）。这份说明书不是文档，而是代码注释的一部分，会自动注入到元数据管理平台。
- 处理“幽灵字段”：某些字段在数据库里存在，但业务系统从未使用（如legacy字段“credit_score_v1”），或已被弃用但未下线（如“risk_level_old”）。我们设计了一个轻量级探查脚本，在每日全量抽取前运行，统计字段值分布、空值率、与主键的关联度，自动生成“字段健康度报告”。连续7天值为空或99.9%为默认值的字段，会被标记为“待确认”，阻断其进入下游加工链路，避免污染分析口径。
2.2 第二层：风险实体统一建模层（解决“同一个客户/贷款，在不同系统里长得不一样”）
- 核心不是ID匹配，而是状态对齐：传统做法是用客户身份证号或贷款合同号做主键关联。但在实际中，A系统用“客户号+产品代码”标识一笔贷款，B系统用“放款日期+序列号”，C系统日志里只有模糊的手机号哈希。我们放弃强主键绑定，转而构建“风险实体快照”：以贷款生命周期为轴心，将所有源系统数据按时间切片（分钟级），对每个时间点，聚合该时刻所有系统对该笔贷款的状态描述（如“审批通过”“首次逾期”“催收外派”“核销”），形成一个带时间戳的JSON数组。后续分析时，不是查“当前状态”，而是查“在T时刻，各系统共识的状态是什么”，这直接解决了跨系统状态不一致的根源问题。
- 动态容忍度配置：状态对齐不是非黑即白。例如，A系统记录“逾期30天”，B系统记录“逾期28天”，C系统无记录。我们允许配置“时间容忍窗口”（如±3天）和“系统权重”（如核心系统权重0.6，外围系统0.2），用加权投票算法生成该时间点的“共识逾期天数”，而非简单取平均或最大值。这个配置项本身是可配置的，风控策略调整时，只需改参数，无需动代码。
2.3 第三层：分析就绪层（解决“分析师拿到的数据，能不能直接建模”）
- 拒绝“宽表陷阱”：很多团队热衷于拼一张包含500+字段的“风控全量宽表”，结果字段间强耦合，一个字段逻辑变更，整张表重跑。我们采用“主题域+原子指标”模式：先定义清晰的主题域（如“信用历史”“还款行为”“外部征信”“催收表现”），每个域内只提供经过严格验证的原子指标（如“近6个月月均逾期天数”“首逾后30天内还款率”“芝麻分区间分布”），所有指标独立计算、独立校验、独立版本管理。分析师需要什么，就组合什么，像搭积木一样灵活，且每个积木的“承重能力”（数据质量、更新时效）都明明白白标在旁边。
- 内置业务规则引擎：ETL过程不只做数据搬运，更承担部分业务逻辑。例如，“是否属于高风险客户”这个标签，不是分析师在BI里用一堆IF语句算，而是在ETL的最后一步，调用一个轻量级规则引擎（我们用Drools封装了200+条监管及内部风控规则），输入原子指标，输出标准化标签及触发规则路径（如“触发规则R103：近3个月查询征信次数>15次且无新增授信”）。这保证了所有下游系统看到的“高风险”定义完全一致，且可追溯。
这个三层设计，把ETL从“数据搬运工”升级为“风险语义翻译官”。它不追求技术指标的华丽（如吞吐量多少TPS），而死磕一个朴素目标：当业务方指着报表问“为什么这里显示客户A是高风险，但客户经理说他刚还完款？”时，你能30秒内定位到是哪个源系统的时间戳偏差、哪个规则引擎的阈值配置、或是哪个清洗脚本的空值填充逻辑出了问题。这才是金融级ETL的底线。
3. 核心细节解析与实操要点：那些文档里绝不会写的“脏活”和“巧活”
再好的架构，落地时全是细节决定成败。我把过去三年在多个项目中反复验证、反复优化的核心细节，浓缩成以下几条“血泪经验”，每一条都对应一个真实踩过的坑。
3.1 非结构化风险事件文本的清洗：别迷信大模型，先做“词典+规则”冷启动
风控系统里大量关键信息藏在“备注”“调查结论”“催收记录”等文本字段里。很多人第一反应是上NLP模型做实体识别。但我们发现，在金融场景下，高质量词典+确定性规则，比通用大模型更稳、更快、更可控。
构建“风险事件词典”的三原则：
- 业务驱动，非技术驱动：词典词条不是从语料库自动抽取，而是由资深风控员、贷后主管、合规律师共同梳理。例如，“失联”这个词，在催收语境下，必须同时满足“电话无法接通（含关机、空号）”+“短信未回复（超48小时）”+“地址核查失败（实地/邮寄）”才算，缺一不可。词典里存的不是“失联”二字，而是这个完整判定逻辑的伪代码。
- 动态同义词组：同一风险含义，不同系统、不同人员表述千差万别。“收入下降”可能写作“工资减少”“裁员”“公司倒闭”“经营困难”“现金流紧张”。我们维护一个“同义词组矩阵”，每个主词条（如“收入下降”）关联一组业务认可的变体，并标注每个变体的置信度（如“裁员”置信度0.95，“经营困难”置信度0.7）。清洗时，匹配到高置信度变体才触发，避免误判。
- 否定与程度修饰：这是最容易翻车的地方。“暂无还款能力”≠“无还款能力”，“疑似失联”≠“失联”。我们在词典中为每个主词条预设“否定前缀库”（如“暂无”“疑似”“可能”“未发现”）和“程度副词库”（如“严重”“轻微”“持续”“偶发”），清洗脚本必须同时扫描主词及其修饰语，组合判断。例如，匹配到“疑似失联”，则标记为“待人工复核”，不直接入库。
实操技巧：用正则表达式做“语义骨架”提取
比单纯匹配关键词更高效的是提取“语义骨架”。例如，一条催收记录：“客户张三（138****1234）于2024-03-15表示因公司裁员，预计4月底前可筹措5000元还款，但拒绝提供新工作证明。” 我们不逐字分析，而是用正则快速抓取：客户(?P<name>.*?)\((?P<phone>.*?)\).*?于(?P<date>\d{4}-\d{2}-\d{2}).*?因(?P<reason>.*?)，.*?预计(?P<repay_date>.*?)前.*?可筹措(?P<amount>[\d,]+)元.*?。这个骨架能稳定提取出姓名、电话、事件日期、原因、预期还款日、金额等结构化信息，准确率远超纯NLP。后续再用词典对reason字段做精细化分类（如“裁员”→“收入下降”→“高风险”）。这套方法在某消金公司上线后，文本结构化准确率从62%提升至94%，且耗时降低70%。
提示：不要试图用一个模型解决所有文本问题。把80%的规则明确、模式固定的文本（如催收记录、审批意见）用词典+正则搞定；把剩下的20%真正模糊、需要上下文理解的（如复杂投诉信），再交给小规模微调的专用模型。这是成本与效果的最佳平衡点。
3.2 多源逾期数据的时间对齐：时间不是标量，而是带误差的区间
逾期天数是风控最核心的指标，但不同系统计算逻辑天差地别：A系统按“还款日次日”开始计，B系统按“账单日次日”，C系统日志里只记录“发生逾期”这个事件，没有具体起始日。强行用某个系统的“逾期天数”作为唯一标准，必然导致分析失真。
我们的解决方案：逾期状态时间线（Overdue Timeline）
不存储一个数字“逾期30天”，而是存储一个时间区间[start_date, end_date]和一个状态码。start_date来自源系统最可靠的触发事件（如A系统的“还款日次日”、B系统的“账单日次日”、C系统的“日志记录时间”），end_date是该状态结束的时间（如还款成功时间、核销时间）。状态码则编码了计算依据（如A1表示“A系统按还款日计算”，B2表示“B系统按账单日计算且含宽限期”）。实操步骤：
- 源端打标：在抽取阶段，为每条逾期记录附加
source_system和calculation_rule_id（如core_v2_2023），这个ID指向元数据平台中定义的详细计算规则文档。 - 时间线融合：当同一笔贷款在多个系统都有逾期记录时，ETL不取平均值，而是合并所有时间线。例如，A系统上报
[2024-03-01, 2024-03-30]（A1），B系统上报[2024-03-05, 2024-03-25]（B2），C系统上报[2024-03-03, null]（C3，null表示持续中）。融合算法会生成一条主时间线[2024-03-01, null]，并记录各子时间线的覆盖情况（A1覆盖1-30日，B2覆盖5-25日，C3覆盖3日至今）。 - 分析层按需计算：分析师要查“截至2024-03-20的逾期天数”，系统就扫描所有时间线，找出在2024-03-20这个时间点处于“逾期”状态的所有子区间，计算其总长度（此处为20天），并返回主导状态码（A1，因覆盖时间最长）。这样，同一个查询，在不同时间点返回的结果是动态的、可解释的。
- 源端打标：在抽取阶段，为每条逾期记录附加
避坑心得：千万别在ETL里做“统一口径”的硬转换！比如把B系统的逾期天数强行减去4天（因宽限期）来匹配A系统。这等于抹杀了B系统自身的业务逻辑，一旦B系统规则调整，所有历史数据都要重算。保留原始状态，按需计算，才是可持续之道。
3.3 监管报送字段的动态映射：让ETL成为“合规翻译器”
银保监、央行的报送要求（如EAST、1104）年年更新，字段增删、口径调整、校验规则变化频繁。如果每次更新都让ETL工程师手动改SQL、改脚本，不仅效率低，还极易出错。
核心设计：报送规则即代码（Rule-as-Code）
我们把每一份监管报送规范（PDF或Excel）转化为一个结构化的YAML配置文件。例如，EAST4.0的loan_info表中，字段loan_purpose_code要求：“根据贷款合同约定用途，对照《贷款用途代码表》填写，若合同未明确，则填‘99’”。这个规则被写成：field: loan_purpose_code source_field: contract.purpose_text mapping_rules: - condition: "value in ['购房', '购车']" result: "01" - condition: "value in ['经营', '生意']" result: "02" - condition: "value == '' or value is None" result: "99" - condition: "default" result: "99" validation_rules: - type: "in_list" values: ["01", "02", "99"]实操流程：
- 配置即服务：这个YAML文件不是静态文档，而是部署在ETL调度平台上的一个“服务”。当监管新规发布，合规专员只需修改YAML，提交PR，经风控、科技双签后自动生效。
- 执行时加载：ETL任务在运行时，动态拉取最新版YAML配置，解析规则，生成对应的SQL片段或Python函数。整个过程对底层数据模型透明。
- 变更留痕：每一次YAML配置的修改，都自动记录变更人、时间、原因，并生成差异报告（如“v2.1 → v2.2：新增对‘教育’用途的映射‘03’，移除旧映射‘04’”）。这不仅是技术需求，更是审计刚需。
独家技巧：用“影子字段”做灰度验证
新规则上线前，我们不直接替换原字段。而是先生成一个“影子字段”（如loan_purpose_code_v22），与原字段loan_purpose_code并存。跑一周，对比两个字段的分布、校验通过率、与上游源字段的匹配度。只有当影子字段各项指标稳定达标，才切换主字段。这招让我们在某银行EAST4.2升级中，零故障完成切换，避免了监管检查时的尴尬。
4. 实操过程与核心环节实现：从调度到监控，一个生产级ETL的完整心跳
一个能放进生产环境的风控ETL，光有数据逻辑不够，它必须像一台精密仪器，有稳定的动力（调度）、灵敏的神经（监控）、和随时可用的维修手册（文档）。以下是我们在某头部消金公司落地的完整实操链路，所有步骤均可直接复用。
4.1 调度策略：不是“每天跑一次”，而是“按风险信号的脉搏跳动”
分层调度，按需驱动：
- 实时层（秒级）：仅处理高优先级风险事件，如“单笔交易金额>5万元且IP异常”“同一设备30分钟内登录5个不同账号”。使用Flink SQL消费Kafka风控事件流，规则引擎实时计算，结果写入Redis供前端秒级展示。不走批处理，规避延迟。
- 准实时层（15分钟）：处理核心状态变更，如“还款成功”“逾期发生”“催收外派”。源系统通过CDC（Debezium）将MySQL binlog实时同步到Kafka，Flink Job监听特定表的UPDATE/INSERT事件，触发轻量级清洗与状态更新。确保关键状态15分钟内可见。
- 批量层（T+1）：处理复杂计算与全量校验，如“客户综合风险评分”“多头借贷指数”“监管报送全量校验”。使用Airflow调度，但绝不简单设为“00:00”。我们根据源系统SLA（如核心系统凌晨2点完成日终）和下游依赖（如BI凌晨4点刷新看板），将主任务设为“02:30”，并设置3个前置检查点：① 核心系统日终完成标志文件已生成；② 上游数据质量校验（空值率<0.1%）通过；③ 前一日监管报送校验无致命错误。三个检查点全部通过，任务才启动，否则告警并暂停。
实操配置（Airflow DAG核心片段）：
# 定义检查点任务 check_core_etl_done = FileSensor( task_id='check_core_etl_done', filepath='/data/etl/core/done_{{ ds_nodash }}.flag', # 标志文件 fs_conn_id='hdfs_default', timeout=3600, # 超时1小时 poke_interval=300, # 每5分钟检查一次 ) check_data_quality = PythonOperator( task_id='check_data_quality', python_callable=validate_source_quality, op_kwargs={'date': '{{ ds }}', 'threshold': 0.001}, ) # 主ETL任务，依赖所有检查点 main_risk_etl = SparkSubmitOperator( task_id='main_risk_etl', application='/opt/spark/jars/risk-etl-main.jar', ... # 其他参数 trigger_rule='all_success', # 所有前置任务成功才触发 ) # 依赖关系 check_core_etl_done >> check_data_quality >> main_risk_etl
4.2 数据质量监控：不是“报错就停”，而是“分级告警+自动修复”
四级质量水位线：
级别 触发条件 响应动作 责任人 致命（Fatal） 关键字段（如 loan_id,overdue_days）空值率>5%；主键重复率>0.001%立即停止下游所有任务；企业微信@全体风控+科技负责人；生成根因分析报告初稿 ETL工程师+风控数据Owner 严重（Critical） 原子指标（如 m1_rate）环比波动>50%；监管字段校验失败数>1000条暂停该指标下游所有报表；邮件通知；启动30分钟应急响应会议 数据分析师+合规专员 警告（Warning） 字段值域异常（如 overdue_days出现负数）；非关键字段空值率>20%在数据质量看板标红；每日晨会通报；要求24小时内闭环 数据开发+业务方 提示（Info） 新增字段首次入库；字段分布微调（如 age平均值变化±0.5岁）记录日志，不告警；纳入周度质量趋势分析 自动化 自动修复机制（针对常见Warning）：
对于“字段值域异常”这类高频Warning，我们编写了自动修复脚本。例如，检测到overdue_days为负数，脚本会：① 查询该笔贷款的repayment_date和due_date；② 若repayment_date < due_date，则修正为0（表示提前还款）；③ 记录修复日志（原值、修正值、原因、操作人）；④ 将该记录加入“待人工复核队列”。修复不是掩盖问题，而是把人工从重复劳动中解放出来，专注分析根因。
4.3 元数据与血缘追踪：让每一行数据都有“身份证”和“家谱”
血缘图谱的最小可行实践：
不追求全链路、全自动的血缘（那需要侵入所有系统，成本极高）。我们聚焦核心风险指标，手工+半自动构建关键路径。例如，指标“M3+逾期率”：- 源头：核心系统
loan_repayment表的overdue_days字段（来源：core_db.loan_repayment.overdue_days） - 加工：ETL脚本
risk-metrics-v2.py第142行，执行WHERE overdue_days >= 90 - 存储：Hive表
risk_dwd.m3_plus_rate_daily的m3_plus_rate字段 - 消费：BI看板“贷后监控”第3个图表，SQL中
SELECT m3_plus_rate FROM risk_dwd.m3_plus_rate_daily WHERE dt='{{ds}}'
这个路径信息，不是写在Wiki里，而是作为注释嵌入到ETL脚本中，并通过一个轻量级爬虫，定期扫描所有脚本，提取
# lineage:开头的注释，自动更新到Neo4j图数据库。当业务方质疑“为什么今天M3+率突然涨了？”，我们打开血缘图谱，点击该指标，3秒内就能看到：① 昨日该指标计算脚本是否有变更（Git对比）；② 源表overdue_days字段昨日的分布是否异常（链接到数据质量看板）；③ 是否有新的贷款批量入池（链接到上游调度日志）。血缘不是技术装饰，而是业务信任的基石。- 源头：核心系统
实操工具链：
- 元数据采集：Apache Atlas（开源） + 自研插件（解析Python/SQL中的
# lineage:注释） - 血缘可视化：Neo4j Browser（开发调试） + 自研Web界面（业务方友好，支持中文搜索、一键钻取）
- 变更影响分析：当修改
risk-metrics-v2.py时，系统自动扫描所有依赖此脚本的下游报表和API，生成影响范围报告，强制要求在PR中说明。
- 元数据采集：Apache Atlas（开源） + 自研插件（解析Python/SQL中的
5. 常见问题与排查技巧实录：那些深夜救火时，真正管用的“速查口诀”
再完美的设计，也挡不住生产环境的“惊喜”。我把过去三年积累的、最常遇到的10个典型问题，整理成一张“风控ETL急救卡”，每一条都是血泪换来的直觉。
| 问题现象 | 排查口诀 | 根本原因 | 快速修复 |
|---|---|---|---|
| 问题1：BI看板上“逾期率”突降50%，但业务反馈没变化 | “查时间、查口径、查缓存” | ① BI看板查询的dt分区写错了（如dt='20240315'写成'20240314'）；② ETL脚本中overdue_days的过滤条件被误改为>=100；③ BI工具本地缓存了旧数据。 | ① 在Hive中SELECT COUNT(*) FROM risk_dwd.overdue_daily WHERE dt='20240315'；②git blame查脚本最近修改；③ BI中强制刷新缓存。 |
| 问题2：监管报送校验失败，报“字段X值非法”，但数据看起来没问题 | “看定义、看映射、看空格” | ① 监管定义中X字段要求“左对齐，不足补空格”，而源数据是右对齐；② YAML映射规则中，condition写成了== 'A '（带空格），但源数据是'A'；③ 源数据导出时，Excel自动给长数字加了科学计数法（如123456789012变成1.23457E+11）。 | ① 用hex()函数查字段十六进制值，确认空格；② 在YAML中用strip()函数清理空格；③ 源系统导出时，将数字列格式设为“文本”。 |
| 问题3：Flink实时任务CPU飙升100%，日志刷屏“Checkpoint failed” | “查状态、查背压、查GC” | ① Kafka Topic分区数增加，但Flink消费者并行度未调；② 某个Key（如customer_id）数据倾斜，90%消息集中在一个Subtask；③ JVM内存不足，频繁Full GC。 | ①flink list -r查运行任务；②flink metrics查各Subtask的numRecordsInPerSecond，找热点Key；③ 调大taskmanager.memory.process.size，加-XX:+UseG1GC。 |
| 问题4：Airflow任务显示“Success”，但下游表数据为空 | “查日志、查分区、查权限” | ① 任务日志末尾有WARN: No data to write，但返回码是0；② Hive表INSERT OVERWRITE写入了错误的分区（如PARTITION(dt='20240315')写成'20240316'）；③ Spark任务用spark.sql.adaptive.enabled=true，但Hive Metastore权限不足，无法创建临时分区。 | ① 在Airflow UI中点开任务日志，搜No data；②hive -e "SHOW PARTITIONS risk_dwd.xxx"；③ 检查Spark用户对Hive Metastore的ALL权限。 |
| 问题5：文本清洗后，“失联”标签覆盖率从80%暴跌到20% | “查词典、查修饰、查编码” | ① 新增的“失联”同义词（如“玩失踪”）未加入词典；② 源文本中“疑似失联”被规则误判为“非失联”；③ 源系统导出的CSV是GBK编码，ETL脚本用UTF-8读取，导致中文乱码，关键词匹配失败。 | ①grep -r "失联" /path/to/dict/；② 在测试脚本中，单独打印"疑似失联"的匹配结果；③file -i source.csv查编码，脚本中加encoding='gbk'。 |
问题6：多源逾期时间线融合后，某笔贷款的end_date是NULL，但实际已还款 | “查日志、查状态、查时区” | ① 还款成功的日志事件，因网络抖动未送达Kafka；② A系统上报status='REPAID'，但B系统仍上报status='OVERDUE'，融合算法因未收到B系统终止信号，不敢闭合；③ A系统服务器时区是UTC+8，B系统是UTC+0，时间戳未统一转换。 | ① 查Kafka Consumer Group Offset；② 在融合脚本中，加max_end_date_fallback参数（如if no end signal in 24h, set end_date=now()）；③ 所有源系统接入时，强制转换为UTC时间戳。 |
| 问题7：新上线的规则引擎，对同一笔贷款，不同时间点计算出不同风险标签 | “查输入、查规则、查缓存” | ① 规则引擎的输入数据（原子指标）是T+1的，但引擎被误配置为实时调用；② 规则YAML中，condition用了now()函数，导致每次计算时间不同；③ 引擎结果被Redis缓存，但缓存Key未包含as_of_date参数，导致不同时间点查到同一缓存。 | ① 检查引擎调用接口的as_of_date参数；② 规则中禁用now()，改用传入的as_of_date；③ 缓存Key改为risk_label_{loan_id}_{as_of_date}。 |
| 问题8：ETL任务运行越来越慢，从1小时变成3小时 | “查数据、查SQL、查资源” | ① 源表数据量暴增（如日志表未分区，全表扫描）；② SQL中用了SELECT *，但下游只用3个字段，网络传输浪费；③ Spark Executor内存不足，频繁Shuffle spill到磁盘。 | ①ANALYZE TABLE source_table COMPUTE STATISTICS；② 改为SELECT col1, col2, col3；③spark.sql.adaptive.enabled=true+spark.sql.adaptive.coalescePartitions.enabled=true。 |
问题9：数据质量看板显示“overdue_days空值率100%”，但源表明明有数据 | “查抽取、查映射、查类型” | ① Kafka CDC配置错误，未监听overdue_days字段的变更；② ETL脚本中，SELECT语句漏写了该字段；③ 源表该字段是VARCHAR，但脚本中CAST(... AS INT)失败，整行被丢弃。 | ①kafka-console-consumer.sh --topic core_loan --from-beginning --max-messages 10；②grep -n "overdue_days" etl_script.py；③ 在CAST前加TRY_CAST或CASE WHEN兜底。 |
| 问题10：业务方说“你们给的指标和我们自己算的差10倍”，但双方SQL一模一样 | “查粒度、查去重、查时点” | ① 业务方SQL在GROUP BY时漏了关键维度（如loan_id），导致聚合粒度错误；② 业务方用了COUNT(DISTINCT customer_id)，但ETL层是COUNT(customer_id)（含重复）；③ 业务方查的是T+0实时数据，ETL层是T+1快照数据。 | ① 让业务方提供完整SQL，用EXPLAIN看执行计划；② 统一约定：所有指标必须明确标注“去重”或“不去重”；③ 在指标定义文档中，强制注明“数据时效性：T+1”。 |
注意：这些口诀不是万能钥匙，而是帮你30秒内锁定问题方向。真正的根因，永远在现场日志、实时监控和源数据样本里。我的习惯是：遇到问题，先花5分钟看日志（不是扫，是逐行读），再花5分钟看监控曲线（不是看峰值，是看拐点），最后才动手改代码。90%的问题，答案就藏在这10分钟里。
我在实际操作中发现，最有效的“防错”不是写更多代码，而是把每一个ETL环节的“假设”都显性化、可验证。比如，脚本开头第一行，不是import pandas as pd，而是# ASSUMPTION: source_table has partition column 'dt' and is updated daily at 02:00 UTC。当这个假设在未来某一天被打破（如源系统改成每小时更新），脚本会在第一步就报错，而不是默默产出错误数据。这种把“隐性知识”变成“显性契约”的习惯，是保障金融数据生命线的最朴素，也最有力的方式。
