📚 课程目录第4章数据接入与处理

4. 数据接入与处理

量化风险看板的价值，不取决于图表多漂亮，而取决于底层数据是否接得全、洗得净、算得准、来得及时。数据接入与处理是风险看板的“供水系统”：上游数据源一旦断流、错位或口径不一致，下游的指标、阈值和告警都会失真。本节围绕风险数据源、采集方式、清洗标准化、实时与批量架构、数据质量监控五个环节，建立一条可落地的数据链路。

一、核心原理：风险数据源类型与采集方式

风险数据源通常分为四类：交易与业务系统数据（订单、支付、清算、持仓）、市场与行情数据（价格、利率、汇率、波动率）、客户与外部数据（征信、工商、舆情、黑名单）、日志与行为数据（登录、操作、风控规则命中记录）。不同数据源的时效性、结构化程度和更新频率差异很大，采集方式必须与之匹配。

数据库直连/CDC：适合交易库、客户库，通过 Binlog 或 WAL 捕获变更，延迟低、对源库压力可控。
API 拉取：适合行情、征信、外部评分，需处理限流、重试与鉴权。
消息队列订阅：适合日志、行为事件，Kafka/Pulsar 提供高吞吐与削峰能力。
文件批量导入：适合日终对账、监管报表，通常按 T+1 调度。

采集设计的第一原则是“先定口径，再定通道”。同一风险指标若来自多个系统，必须明确主数据源与优先级，避免同一指标在不同看板上出现两个值。

二、方法流程：清洗、标准化与实时/批量架构

原始数据进入平台后，需要经过清洗、标准化、关联、聚合四步。清洗解决缺失值、重复值、异常值与格式错误；标准化统一币种、单位、时间戳、编码与业务口径；关联将交易、客户、市场数据拼接为风险宽表；聚合则按机构、产品、客户、行业等维度生成指标。

-- 标准化示例：统一币种与时间口径
SELECT
  trade_id,
  CAST(amount AS DECIMAL(18,2)) * fx_rate AS amount_cny,
  TO_TIMESTAMP(trade_time, 'yyyy-MM-dd HH:mm:ss') AS trade_ts,
  UPPER(TRIM(counterparty_code)) AS counterparty_code
FROM raw_trade
WHERE trade_time IS NOT NULL
  AND amount > 0;

架构上，实时与批量并非二选一，而是Lambda 与 Kappa 的取舍。实时链路负责告警、限额监控、异常交易拦截，要求秒级延迟；批量链路负责日终估值、监管报送、历史回溯，要求口径稳定与可重算。常见做法是：实时层用 Flink/Spark Streaming 做窗口聚合，批量层用 Spark/Hive 做全量重算，两者通过统一指标服务对外提供一致口径。

三、案例/场景：从原始交易到风险告警

某券商需要监控“单一客户集中度超限”。原始数据来自交易库、客户主数据和行情库。处理流程如下：

CDC 捕获交易变更，写入 Kafka 主题 trade-change。
Flink 消费后按客户 ID 做 5 分钟滚动窗口，计算持仓市值与总资产占比。
与客户主数据关联，补齐行业、评级、风险等级。
结果写入指标服务，若占比超过 25% 则触发告警，并推送至看板与工单系统。
日终 Spark 任务重算全量集中度，与实时结果比对，差异超过 0.5% 则进入数据质量工单。

实时链路解决“快”，批量链路解决“准”，两者必须通过统一指标口径和差异对账机制绑定，否则看板会出现“实时值”和“日终值”打架。

四、数据质量监控与常见误区

数据质量监控应覆盖完整性、准确性、一致性、及时性、唯一性五个维度。建议在接入层、清洗层、指标层分别埋点，形成质量清单。

维度	监控项	典型阈值/动作
完整性	关键字段空值率	空值率 > 1% 告警
准确性	金额为负、汇率越界	异常记录进入隔离表
一致性	实时与批量差异	差异 > 0.5% 生成工单
及时性	数据到达延迟	延迟 > 5 分钟降级告警
唯一性	主键重复	重复即阻断入库

常见误区有三：一是只监控“任务是否成功”，不监控“数据是否合理”；二是实时与批量各算各的，没有对账；三是清洗规则写死在代码里，口径变更时无法追溯。复盘时应把质量规则配置化，并保留每次口径变更的版本记录。

数据接入与处理不是一次性工程，而是持续运营。只有把数据源、采集、清洗、架构与质量监控串成闭环，风险看板上的每一个数字才具备可解释、可追溯、可告警的可信度。