3. 风险暴露数据采集：数据源类型与ETL流程
风险暴露评估的准确性高度依赖数据采集的广度、深度与时效性。本章聚焦于三类核心数据源——内部交易数据、外部市场数据、舆情数据——以及从原始数据到可用特征的标准ETL流程。理解数据源特性与采集方法，是构建可靠A/B测试风险监控体系的第一步。
3.1 数据源类型与特征对比
不同数据源在结构、时效、可信度与覆盖范围上存在显著差异。下表从风险暴露评估视角对三类数据源进行对比：
| 数据源类型 | 典型内容 | 结构特征 | 更新频率 | 主要风险维度 |
|---|---|---|---|---|
| 内部交易数据 | 订单簿、成交记录、持仓、保证金、风控限额 | 高度结构化，关系型数据库为主 | 实时/准实时（毫秒~秒级） | 市场风险、信用风险、流动性风险 |
| 外部市场数据 | 行情快照、指数、利率、波动率曲面、衍生品定价因子 | 半结构化，时间序列为主 | 实时/批量（秒级~日频） | 市场风险、基差风险、波动率风险 |
| 舆情数据 | 新闻、社交媒体、监管公告、研报、评级 | 非结构化，文本/图像为主 | 批量/流式（分钟级~小时级） | 声誉风险、事件风险、政策风险 |
实践要点：在A/B测试的风险暴露评估中，内部交易数据是“金标准”，外部市场数据提供基准参照，舆情数据则用于捕捉尾部事件与非线性冲击。三者缺一不可，但优先级与延迟容忍度不同。
3.2 数据采集方法与技术选型
针对不同数据源的结构与时效要求，采集方法需差异化设计：
3.2.1 内部交易数据采集
- 数据库直连（JDBC/ODBC）：从交易系统、风控系统的关系型数据库（如Oracle、PostgreSQL）中拉取订单、成交、持仓等结构化数据。适用于批量离线分析。
- 消息队列订阅（Kafka/RabbitMQ）：对接交易系统的实时事件流，订阅成交、撤单、保证金变动等Topic，实现毫秒级采集。适用于实时风险监控。
- API网关调用（REST/gRPC）：通过内部微服务接口获取聚合后的风险敞口、盈亏等指标。适用于按需查询与仪表盘刷新。
3.2.2 外部市场数据采集
- 金融数据供应商API（Bloomberg/Reuters/万得）：通过专有协议或REST API获取行情、指数、利率曲线等。需处理数据授权、频率限制与断线重连。
- 交易所行情网关（FIX/ITCH）：直接接入交易所的行情数据流，获取Level 2/Level 3订单簿快照与增量。适用于高频风险计量。
- 文件传输（SFTP/FTPS）：接收日终清算文件、指数成分股调整、公司行动等批量数据。适用于日频风险归因与回测。
3.2.3 舆情数据采集
- 网络爬虫（Scrapy/Playwright）：定向抓取新闻网站、监管机构官网、社交媒体API的公开文本。需遵守robots.txt与法律合规要求。
- NLP预处理管道：对原始文本进行分词、实体识别、情感打分，转化为结构化风险信号（如负面情绪指数、监管关键词命中数）。
- 第三方舆情服务（Dataminr/RavenPack）：通过API订阅已标注的事件流，降低自建爬虫的维护成本与合规风险。
选型建议：对于A/B测试实验组与对照组，应确保数据采集延迟与精度一致，避免因数据源差异引入系统性偏差。建议内部交易数据使用消息队列实时采集，外部市场数据使用API+缓存策略，舆情数据使用流式NLP管道。
3.3 ETL流程：从原始数据到风险特征
ETL（Extract, Transform, Load）是将异构数据源统一为风险暴露评估可用特征的核心环节。下图展示了面向风险暴露评估的ETL架构：
3.3.1 ETL各阶段详解
- Extract（抽取）：根据数据源类型选择对应采集方法，将原始数据拉取到临时存储区（如HDFS、S3、Kafka Topic）。关键考量：抽取频率、增量/全量策略、断点续传。
- Transform（转换）：
- 清洗：去除重复记录、过滤异常值（如价格负值、成交量突增100倍）、处理缺失值（前向填充、插值或标记）。
- 标准化：统一时间戳时区（如全部转为UTC）、货币单位（如统一为USD）、证券标识（如统一为ISIN）。
- 特征工程：计算风险因子（如Delta、Gamma、Vega）、聚合统计（如日频VaR、最大回撤）、舆情情感得分（如-1到1的负面情绪指数）。
- Load（加载）：将转换后的特征写入目标存储。实时场景加载到Redis/ClickHouse用于在线风险监控；离线场景加载到Parquet/ORC文件或数据仓库用于A/B测试后验分析。
常见陷阱：
- 时间不同步：内部交易数据使用交易所时间戳，外部数据使用数据商时间戳，舆情数据使用发布时间戳。未对齐会导致风险暴露计算偏差。
- 幸存者偏差：仅采集存续标的的数据，忽略已退市或违约标的，会低估尾部风险。
- 数据延迟不一致：A/B测试中实验组使用实时数据、对照组使用T+1数据，会引入不可忽略的度量偏差。
3.4 数据质量监控与治理
数据采集与ETL流程必须配套持续的质量监控机制，确保风险暴露评估的输入可信：
| 质量维度 | 监控指标 | 告警阈值示例 | 修复策略 |
|---|---|---|---|
| 完整性 | 字段缺失率、记录到达延迟 | 缺失率 > 5% 或延迟 > 30秒 | 补采、插值、标记为不可用 |
| 准确性 | 数值范围校验、业务规则校验（如买卖价差非负） | 单日异常记录 > 10条 | 回滚至上一版本、人工核查 |
| 一致性 | 跨数据源交叉验证（如内部持仓 vs 外部估值） | 偏差 > 1% 且持续 > 5分钟 | 触发数据对账流程 |
| 时效性 | 端到端延迟（采集→加载完成） | 实时管道延迟 > 1秒 | 扩容消费者、优化SQL |
工程实践：建议在ETL管道的每个阶段（抽取、清洗、转换、加载）都埋入质量监控点，使用Prometheus+Grafana或ELK Stack进行可视化告警。对于A/B测试场景，还需在实验开始前对实验组与对照组的数据质量做一致性检验（如KS检验、均值差异检验）。