数据源分类与识别：结构化、半结构化与非结构化
做金融Agent，第一关就是跟数据源打交道。我见过太多团队，模型选得再好，策略再牛，结果数据源没搞清楚，项目直接翻车。
数据源分三类：结构化、半结构化、非结构化。说白了，就是数据长得规不规整的问题。咱们一个一个聊。
结构化数据源：数据库与CSV
结构化数据，就像Excel表格。行是记录，列是字段。规规矩矩，清清楚楚。
数据库是结构化数据的典型代表。MySQL、PostgreSQL、Oracle，这些关系型数据库，存的就是结构化数据。每个表有固定的Schema，字段类型、长度、约束都定义好了。
金融场景常见数据库表
- 交易流水表：trade_id, account_id, symbol, quantity, price, trade_time
- 持仓表：account_id, symbol, position, cost_basis, market_value
- 行情表：symbol, date, open, high, low, close, volume
CSV是另一种常见的结构化数据源。我早期做量化回测时，天天跟CSV打交道。交易所导出的历史行情，基本都是CSV格式。
CSV有个坑——字段分隔符不统一。有的用逗号，有的用分号，还有用制表符的。我曾经遇到过一个CSV文件，里面某个字段的值本身就包含逗号，结果解析出来全乱了。
避坑指南
我曾经在解析某交易所的CSV行情数据时，发现日期字段格式不统一。有的行是"2024-01-15"，有的行是"01/15/2024"。解析前一定要先做格式标准化。
结构化数据的优势很明显：查询快、关系清晰、支持SQL。但缺点也突出——灵活性差。字段一旦定义好，想改就得动Schema。
半结构化数据源：JSON与XML
半结构化数据，有结构但结构不固定。JSON和XML是典型代表。
JSON现在几乎是金融API的标配。RESTful接口返回的数据，十有八九是JSON格式。为什么？因为JSON灵活，可以嵌套，可以表达复杂的数据关系。
举个例子，一个股票行情API返回的JSON：
{
"symbol": "AAPL",
"price": 185.50,
"timestamp": "2024-01-15T14:30:00Z",
"indicators": {
"ma5": 183.20,
"ma20": 180.15,
"volume_ratio": 1.25
},
"level2": [
{"price": 185.55, "volume": 1000},
{"price": 185.60, "volume": 500}
]
}
你看，JSON可以嵌套对象，也可以嵌套数组。这在结构化数据里很难直接表达。
XML现在用得少了，但在金融领域还有一席之地。比如SWIFT报文、FIX协议，底层都是XML格式。我做过一个跨境支付项目，对接SWIFT系统，解析XML报文那叫一个痛苦——标签嵌套太深了。
我的经验
处理JSON时，我习惯先用json.loads()解析，然后用json_normalize()展平嵌套结构。XML的话，用xml.etree.ElementTree或者lxml库。我个人更推荐lxml，性能好，功能全。
半结构化数据的核心问题是什么？Schema不固定。同一个API，今天返回的字段和明天返回的字段可能不一样。你想想看，如果某个字段突然没了，你的解析逻辑就崩了。
非结构化数据源：PDF、新闻、研报
非结构化数据，就是没有固定格式的数据。金融领域里，这类数据量最大，也最难处理。
PDF是金融文档的常见格式。年报、季报、招股说明书，全是PDF。PDF的问题在于——内容提取困难。文字可能被分割成多个文本框，表格可能被渲染成图片，字体编码可能不标准。
我做过一个项目，需要从PDF年报中提取财务数据。PDF里明明有表格，但用PyPDF2提取出来全是乱码。后来改用pdfplumber，配合正则表达式，才勉强搞定。
PDF提取工具对比
| 工具 | 优点 | 缺点 |
|---|---|---|
| PyPDF2 | 轻量、简单 | 对复杂PDF支持差 |
| pdfplumber | 表格提取强 | 速度慢 |
| PyMuPDF | 速度快、功能全 | 学习曲线陡 |
| OCR（Tesseract） | 能处理扫描件 | 准确率依赖图片质量 |
新闻是另一种重要的非结构化数据源。财经新闻、公司公告、政策解读，这些文本数据对金融Agent来说价值巨大。但新闻的格式五花八门——标题、正文、作者、发布时间，每个网站的布局都不一样。
我记得有一次做舆情分析，需要从多个财经网站抓取新闻。有的网站用JSONP，有的用SSR，有的用客户端渲染。光解析HTML就写了十几个不同的解析器。
研报就更复杂了。券商研报通常包含文字、图表、表格、公式。而且研报的PDF质量参差不齐——有的清晰，有的模糊，有的甚至是从图片扫描的。
避坑指南
我曾经处理过一份研报PDF，里面有个表格，但PDF的文本层是空的——整个表格是图片。用OCR识别后，数字"0"和字母"O"混在一起，小数点被识别成逗号。嗯，这里要注意：非结构化数据的清洗，往往比提取更耗时。
三类数据源的核心差异
咱们用一张表总结一下：
| 维度 | 结构化 | 半结构化 | 非结构化 |
|---|---|---|---|
| Schema | 固定 | 灵活 | 无 |
| 查询方式 | SQL | JSONPath/XPath | 全文搜索/NLP |
| 存储方式 | 关系型数据库 | NoSQL数据库 | 文件系统/对象存储 |
| 处理难度 | 低 | 中 | 高 |
| 金融典型场景 | 交易流水、持仓 | API行情、SWIFT报文 | 研报、新闻、公告 |
你想想看，一个金融Agent要处理的数据，往往是这三种类型的混合。比如一个量化策略，需要从数据库拿历史行情（结构化），从API拿实时数据（半结构化），从研报里提取基本面信息（非结构化）。
知识体系总览
下面这张图，把三类数据源的核心逻辑串起来了：
说白了，数据源分类的核心就一句话：先识别，再处理。拿到一个数据源，先问自己三个问题：
- 这个数据有固定的Schema吗？
- 数据是自描述的（JSON/XML）还是需要额外解析的？
- 数据是机器可读的还是需要OCR/NLP处理的？
这三个问题问完，你就知道该用什么工具、什么策略来处理了。我在项目中见过太多人，拿到数据就开始写代码，结果做到一半发现数据格式不对，又得重来。嗯，先花10分钟搞清楚数据源类型，能省你后面10个小时的返工时间。
公众号:蓝海资料掘金营，微信deep3321