一、ETL概述与金融数据特点
大家好，我是老张。在金融数据这个行当摸爬滚打了十几年，今天咱们聊聊ETL。
ETL，全称Extract-Transform-Load。说白了，就是把数据从源头拿过来，洗一洗，再存到目标库里。听起来简单？嗯，做起来可没那么轻松。
我刚开始做金融数据时，以为ETL就是个搬运工。后来才发现，搬运工也有三六九等。金融数据的ETL，绝对是搬运工里的特种兵。
1.1 ETL的核心概念
ETL三个字母，对应三个步骤：
- Extract（抽取）：从各种数据源把数据捞出来。可能是数据库、API接口、文件服务器，甚至是别人发来的Excel。
- Transform（转换）：清洗、格式化、计算。这一步最费功夫，也最容易出幺蛾子。
- Load（加载）：把处理好的数据写入目标系统。数据仓库、数据集市，或者直接喂给下游应用。
你可能会问：这不就是个数据搬运吗？有什么难的？
我举个例子。有一次，我从交易所拿到的行情数据，时间戳格式居然是"2024/1/5 9:30:00.123"。而我们的数据库要求的是"2024-01-05 09:30:00.123"。就这一个格式差异，如果不处理，下游的量化模型直接崩掉。
核心要点：ETL不是简单的数据搬家。它是数据质量的守门员。数据进仓库之前，所有问题都得在ETL环节解决。
1.2 金融数据源类型
金融数据源，我大致分成三类。这三类数据，我每天都在打交道。
1.2.1 行情数据
行情数据，就是市场实时产生的价格信息。包括：
- Level-1行情：五档买卖盘口，每秒快照。这是最基础的。
- Level-2行情：十档盘口，逐笔成交。数据量大了好几倍。
- Tick级数据：每一笔成交的详细信息。毫秒级甚至微秒级。
我记得刚入行时，处理A股的Level-2行情。一天下来，光一个股票就有几十万条tick数据。全市场4000多只股票，你想想看，数据量有多大？
个人经验：行情数据的特点是高频、海量、实时。我建议用列式存储（比如Parquet）来存历史行情，查询效率能提升10倍以上。
1.2.2 交易数据
交易数据，就是客户下单、成交、持仓的记录。这类数据的特点是：
- 强一致性要求：一分钱都不能差。
- 事务性：下单、撤单、成交，必须完整记录。
- 敏感度高：涉及客户隐私，加密是必须的。
我曾经处理过一个券商的项目。他们的交易数据，每天凌晨批量同步。有一次，因为网络抖动，丢了3000条成交记录。第二天清算时，对不上账了。嗯，那场面，至今难忘。
避坑指南：交易数据的ETL，一定要加校验机制。我习惯的做法是：抽取完成后，先比对源端和目标端的记录数。不一致？立刻告警，不要等加载完才发现。
1.2.3 基本面数据
基本面数据，包括财务报表、公司公告、行业研报等。这类数据的特点是：
- 结构化程度低：PDF、Word、图片，什么格式都有。
- 更新频率低：季报、年报，按季度或年度更新。
- 依赖人工校验：机器提取容易出错，需要人工复核。
说实话，基本面数据的ETL，比行情数据难搞多了。行情数据至少格式统一，基本面数据？同一个公司的年报，今年和去年的排版都可能不一样。
1.3 金融数据质量挑战
做金融数据ETL，最大的挑战不是技术，而是数据质量。我总结了几个常见问题：
| 问题类型 | 具体表现 | 我的处理方式 |
|---|---|---|
| 数据缺失 | 某只股票某天没有行情数据 | 停牌？还是系统漏了？先标记，再人工确认 |
| 数据重复 | 同一笔交易出现两次 | 按主键去重，保留时间戳最新的那条 |
| 数据异常 | 股价突然涨了1000% | 设置阈值，超过3个标准差就告警 |
| 数据延迟 | 本该9:30到的数据，10:00才到 | 建立超时机制，延迟超过阈值就切换备用源 |
| 格式不一致 | 日期格式、数值精度不统一 | 在Transform阶段统一标准化 |
你可能会觉得，这些问题都不难解决。但实际项目中，这些问题往往是组合出现的。数据又缺失又重复，格式还不统一。嗯，这时候就需要经验了。
我的原则：宁可数据少，不要数据错。金融交易，差一分钱都可能造成巨大损失。数据质量，永远是第一位的。
1.4 本章知识体系
下面这张图，是我自己画的。它概括了本章的核心内容。你看一眼，就能明白ETL在金融数据中的位置。
这张图，我画了三个层次。最下面是数据源，中间是ETL处理，最上面是质量挑战。你仔细看，每个层次之间都有箭头连接。这说明什么？说明数据是流动的，问题也是流动的。
好了，第一章就到这里。内容不多，但都是干货。记住一句话：ETL做得好，后面分析才靠谱。ETL做不好，再牛的模型也是白搭。
最后说一句：我见过太多团队，花大价钱买模型、搭平台，结果数据质量一塌糊涂。ETL这个环节，看似不起眼，其实是整个数据体系的基石。别忽视它。
公众号:蓝海数据掘金营，微信deep3321