4. 舆情数据采集
金融舆情风险告警的上游是数据。采集环节决定了后续分类、评分与告警的“原料质量”。本节围绕多源采集、爬虫与API、清洗去重、存储方案四个环节展开，目标是让学员能独立设计一条可运行、可扩展、可审计的金融舆情数据管道。
一、核心原理：多源采集的“三源四层”模型
金融舆情的数据源可归纳为三类：公开媒体源（财经门户、新闻网站、监管公告）、社交与社区源（微博、股吧、雪球、微信公众号）、专业数据源（交易所公告、Wind/同花顺接口、企业预警通）。采集架构通常分为四层：接入层负责协议适配，解析层负责结构化抽取，治理层负责清洗去重，存储层负责持久化与检索。
关键原则：采集不是“抓得越多越好”，而是“抓得准、抓得稳、抓得合规”。金融领域尤其要关注信源权威性、时效性与版权边界。
二、方法流程：爬虫与API的协同采集
实际项目中，爬虫与API并非二选一，而是互补。API适合结构化、授权明确、频率可控的数据；爬虫适合无API或API受限的网页数据。推荐流程如下：
- 源清单管理：为每个源登记名称、类型、URL、频率、字段、合规状态。
- 调度与限速：使用Scrapy-Redis或Airflow调度，设置并发与延迟，避免封禁。
- 增量抓取：基于时间戳、ID或游标，只抓新增内容。
- 解析与落库：统一输出JSON，写入消息队列缓冲。
- 监控告警：对失败率、延迟、字段缺失率设置阈值。
# 示例：基于 requests + BeautifulSoup 的财经新闻增量采集
import requests, hashlib, time
from bs4 import BeautifulSoup
HEADERS = {"User-Agent": "Mozilla/5.0 (compatible; FinSentimentBot/1.0)"}
BASE = "https://example-finance.com/news?page="
def fetch_page(page):
resp = requests.get(BASE + str(page), headers=HEADERS, timeout=10)
resp.raise_for_status()
soup = BeautifulSoup(resp.text, "html.parser")
items = []
for node in soup.select(".news-item"):
title = node.select_one(".title").get_text(strip=True)
url = node.select_one("a")["href"]
pub_time = node.select_one(".time").get_text(strip=True)
uid = hashlib.md5((title + url).encode("utf-8")).hexdigest()
items.append({"uid": uid, "title": title, "url": url, "pub_time": pub_time})
return items
for p in range(1, 4):
for item in fetch_page(p):
print(item)
time.sleep(2) # 限速，尊重目标站点
API采集示例：交易所公告接口通常返回JSON，可直接映射字段。务必保存原始响应，便于回溯与审计。
三、数据清洗、去重与存储方案
清洗的目标是让每条记录具备可分析性。常见操作包括：去除HTML标签与广告、统一时间格式、补全缺失字段、过滤非金融相关噪声。去重分为精确去重（URL或内容哈希）与近似去重（SimHash/MinHash），后者用于识别转载与洗稿。
| 环节 | 常用方法 | 金融场景要点 |
|---|---|---|
| 清洗 | 正则、HTML解析、时间标准化 | 保留股票代码、公司全称、监管文号 |
| 精确去重 | MD5/SHA1 内容哈希 | 同一公告多站转载只留一条 |
| 近似去重 | SimHash + 汉明距离 | 识别标题微改的重复舆情 |
| 存储 | MySQL + ES + MongoDB | 结构化字段入MySQL，全文检索入ES |
# 示例：SimHash 近似去重（simhash 库）
from simhash import Simhash
def is_near_duplicate(text_a, text_b, threshold=3):
ha = Simhash(text_a)
hb = Simhash(text_b)
return ha.distance(hb) <= threshold
print(is_near_duplicate("某银行被罚200万", "某银行遭罚200万元")) # True
存储方案建议采用“冷热分层”：热数据（近7天）放Elasticsearch供实时检索与告警；温数据放MySQL做关联分析；冷数据归档至对象存储。消息队列（Kafka/RabbitMQ）用于削峰填谷，避免采集波动压垮下游。
四、误区与复盘
- 误区一：只抓不存原始数据。解析失败时无法回溯，建议原始HTML/JSON先落对象存储。
- 误区二：忽略合规与频率。金融数据版权敏感，需遵守robots协议与授权范围。
- 误区三：去重只看URL。同一内容多URL转载会导致告警重复，必须结合内容哈希。
- 误区四：清洗过度。把股票代码、金额等关键实体误删，直接影响风险评分。
复盘要点：采集管道的核心指标是“完整率、及时率、准确率、重复率”。建议每日生成数据质量报告，异常时自动暂停对应源并通知负责人。
综上，多源采集不是单点技术，而是一条从接入、解析、治理到存储的完整链路。掌握爬虫与API协同、清洗去重策略和分层存储方案，才能为后续的金融舆情风险分类与告警提供稳定、干净、可追溯的数据底座。