企业官网建设流程全解析

做量化或者搞数据分析的朋友，应该都经历过找行情数据源的痛苦。免费接口不稳定，付费API又怕被坑，等数据真的拉下来开始清洗的时候，才发现字段对不上、复权方式不对、tick数据缺失，一天的时间全耗在数据上面了。

我这两年陆陆续续把主流的行情数据源都摸了一遍，从Tushare到Polygon再到TickDB，每个都实际跑过数据、踩过坑。这篇就把我的实测结果和判断标准整理出来，给正在选型或者准备换数据源的朋友一个参考。这期内容不是纯文档搬运，而是我拿真实行情去拉数、对比、验证之后的结果，结论都是基于实际操作得出的。

1. 测评之前的思路：为什么拿这三个放一起比

1.1 三个数据源的定位差异

先说清楚，Tushare、Polygon、TickDB这三个完全不是一个物种，把它们放在一起对比不是因为技术实现类似，而是因为它们在实际工作中经常会被同一个团队或同一个人拿来轮换着用。

Tushare是国内的Python财经数据接口，起家早、用户多，覆盖A股、基金、期货、宏观等数据，积分制度决定你能调用多少量。它的优势在于数据面广、社区成熟，尤其是A股的基础数据非常全，适合做日线级别策略研究和因子挖掘。

Polygon.io是海外市场的数据API服务商，主攻美股、期权、加密货币和外汇，REST API和WebSocket流都做得很规范。很多欧美量化爱好者高频使用它。它的优势是文档清晰、数据结构统一、全球市场覆盖，适合做跨市场或者美股策略。

TickDB则是侧重高性能行情数据存储和查询的时序数据库，如果拿它和Tushare、Polygon去比，其实不太公平，因为它本身不是数据供应商，而是帮你把行情数据落库、管理、查询的那个基础设施。比如你用Polygon拉下来一堆tick数据，不可能一直放在CSV里，这时候TickDB这类时序数据库就派上用场了。它擅长处理海量逐笔成交数据、分钟级快照，提供高性能的点查和区间查询能力。

顺带提一句，搜索的时候要注意，Polygon这个名字在PCB圈子里面还有一层含义，指的是Altium Designer里面的铺铜操作，有时候搜“Polygon not poured”会出来一堆电路板设计的内容，跟行情API没有关系，搜资料的时候别走错片场。

1.2 测评维度和方法

我这次对比没有只看“能不能拉到数据”，而是围绕五个维度做了一套自己的验证方法：

• 数据覆盖率：对比同一标的、同一时间段，三个数据源的数据完整性。
• 数据准确性：抽查复权因子、分钟线和tick级的字段，看有没有异常值或者价格跳变。
• 接口稳定性：连续调用、高频请求下是否容易限流或者断连，报错信息是否友好。
• 性能表现：从发起请求到拿到结果，再到入库查询，整个链路的时间消耗。
• 上手成本：注册、认证、文档质量、代码示例是否齐全，能不能让新人在半天内跑通。

我的实测环境是本地的Python 3.10，用requests和pandas做数据拉取，TickDB部署在一个8核32G的Linux服务器上。所有的测试脚本我都保留着，下面会直接给出关键代码和返回结果的对比，你可以照着跑。

2. 逐个拆解：三个数据源的接入方式和实操要点

2.1 Tushare：A股数据的老大哥

Tushare给我的整体感觉是“够用，但门槛在积分上”。注册之后要先登录官网，完善个人信息，然后在“个人主页-接口TOKEN”里面拿到一串token，后面调用所有接口都要带上它。

它最常用的接口是pro_bar和daily，前者是复权行情，后者是未复权行情。积分不同能调用的接口也不同，比如日线行情需要120积分，而分钟线需要2000积分。新用户默认会有一定积分，但一般不够用，需要靠注册、关注公众号、社区贡献等途径攒积分。

import tushare as ts import pandas as pd ts.set_token('你的token') pro = ts.pro_api() # 获取平安银行日线行情 df = pro.daily(ts_code='000001.SZ', start_date='20240101', end_date='20240131') print(df.head())

写代码简单，但我实测下来的几个关键点要提醒你：

• Tushare的daily接口返回的是不复权价格，如果直接拿去算收益率，遇到除权除息日会出现价格跳空，必须配合adj_factor复权因子做后复权或前复权。
• 分钟线接口stk_mins（或者是旧版的ts.pro_bar）会有频率限制，积分不够的时候连续请求会被限制，报错信息是类似“抱歉，您每分钟最多访问该接口X次”的提示。
• 节假日和数据更新时点需要自己维护，比如某些交易日的数据在当天晚上才更新完，如果盘中就去拉当天数据，经常会拿到不完整的数据。

实际用下来，Tushare更适合拿来做日线级别的因子分析和策略回测，它的数据覆盖了财务指标、资金流向、龙虎榜等衍生数据，这在做因子挖掘的时候很有价值。但它不适合高频交易或者盘中实时行情，因为数据更新频率和数据粒度都跟不上。

2.2 Polygon：美股与全球市场的API先行者

Polygon的使用体验和Tushare是完全不同的风格。它通过订阅制获取API Key，根据套餐不同，可以访问的数据范围、请求限额都不一样。最基础的Starter套餐每个月只有一定次数的免费请求，但每个月的免费额度很有限，想要高频拉数的话得升级到Developer或者Business套餐。

Polygon的REST API设计非常统一，比如获取某只股票某一天的OHLCV数据，请求方式是这样的：

import requests API_KEY = 'your_polygon_key' ticker = 'AAPL' date = '2024-01-15' url = f"https://api.polygon.io/v1/open-close/{ticker}/{date}" params = {'apiKey': API_KEY} resp = requests.get(url, params=params) data = resp.json() print(data)

返回结果是一个JSON对象，里面包含open、close、high、low、volume这些字段，还会附带pre_market和after_hours盘前盘后数据，这是很多免费源没有的。

我在实测中比较满意的地方有两个：

• 数据字段规范化程度很高，不管是股票、期权还是加密货币，API结构非常接近，切换标的类型的学习成本很低。
• 文档和示例代码做得用心，每个接口页面都有交互式调试面板，新手照着文档就能跑通。

但Polygon也有限制。它的分钟级历史数据如果拉取范围太大，响应时间会很长，而且免费档位下每分钟只能请求5次，所以批量拉数时需要对请求做节流控制。另外，它对A股、港股这些亚洲市场覆盖较弱，如果你的策略只在国内市场，用它反而会绕远路。

2.3 TickDB：面向逐笔行情的时间序列数据库

TickDB在这三个里面最特殊，它解决的是“拿到了行情数据之后怎么存、怎么查”的问题。你可以把Tushare和Polygon看成水源，TickDB则是水塔，你自己从水源引水，然后储存在水塔里面，需要用水的时候直接开龙头。

我用TickDB主要是为了存储和复现逐笔交易数据，因为A股和美股的高频tick数据量非常大，一天的数据压缩成CSV可能有几百MB甚至几个GB，用pandas直接读文件做研究，内存根本扛不住。TickDB的数据模型是面向金融时序优化的，底层用列式存储和时间分片，支持毫秒级甚至微秒级的查询性能。

它的接入方式相对直接，支持HTTP API和多种语言SDK。我在服务器上部署好后，用Python SDK把Polygon拉下来的tick数据写入TickDB，然后做区间查询，整个过程非常顺滑。下面是写入和查询的简化示例：

from tickdb import TickDBClient client = TickDBClient(host='localhost', port=8080) db = client.get_database("market_data") # 查询某只股票某一天的所有tick记录 result = db.query( "SELECT ts, price, volume FROM ticks " "WHERE symbol = 'AAPL' AND date = '2024-01-15' " "ORDER BY ts LIMIT 1000" ) for row in result: print(row)

TickDB的查询语法和SQL非常接近，学习门槛不算高。它真正吸引人的地方是性能——我测试过在几千亿行的表上做时间范围查询，如果时间分区裁剪生效，单次查询延迟基本在百毫秒以内。这个性能对于回测系统和高频策略研究来说非常有价值。

它的短板也很明显。数据本身你得自己搞定，TickDB不带任何行情数据，需要配合Tushare、Polygon或者券商的数据接口一起使用。此外，部署和维护一个数据库服务，本身就需要一些工程能力，如果你只是做个小回测实验，不想搭服务器、做备份，那它前期使用成本确实稍高一些。

3. 实战对决：数据质量与性能的硬核比拼

3.1 数据完整性对比

我拿美股苹果(AAPL)在2024年1月2日到1月31日之间的日线数据做了完整性对比，同时用Tushare拉了A股贵州茅台(600519.SH)的同期数据，再把TickDB作为存储查询端跑一遍结果。

先说结论：三个源在基础日线数据上，只要是正常交易日，OHLCV数据都能对得上，没有出现整行缺失的情况。但在细节上有几点不同：

• Polygon会有盘前盘后数据，而Tushare没有，如果你做事件驱动策略需要用到盘前跳空缺口，Polygon更合适。
• 在复权因子上，Tushare提供官方复权因子，计算后复权价格只需要做一次乘法；Polygon则提供adj_factor字段，两个源换算后的复权价格基本一致，差在个位数的小数点。
• TickDB不生成数据，它只忠实地保存你写入的数据。所以完整性的好坏完全取决于你上游数据源质量，库本身不会丢数据，前提是你写入时做了主键去重和乱序处理。

我还做了分钟线级别的抽样对比。用Tushare拉取某只A股一天的1分钟线，用Polygon拉取AAPL同一天的1分钟线，两者在各自市场内都正常。但如果你要做跨市场同一策略，时区对齐就是个麻烦点。Tushare返回的时间是北京时间，Polygon返回的时间是美东时间，如果直接拼在一起做特征，需要先统一成UTC时间戳，这个细节容易被忽略。

3.2 响应速度和限流表现

接口性能直接影响数据拉取效率。我做了一个简单测试：分别调用Tushare的daily接口、Polygon的/v2/aggs/ticker/{ticker}/range接口，以及TickDB的本地查询，统计从发起请求到返回结果的时间。测试网络环境在本地宽带，Polygon走的是正常公网出口（我这里不做任何非常规网络手段）。

测试结果如下表：

Tushare的限流是我最头疼的地方。积分低的时候，跑一个批量更新脚本，经常跑到一半报错，要等一分钟再继续。后来我改成请求中间加sleep，配合重试机制，才勉强稳定下来。

Polygon限流虽然严格，但报错信息给得很规范，响应头里会带x-remaining-requests和x-request-reset字段，程序可以通过读取这些字段动态调整请求频率。这一点比Tushare体验好，不知道怎么限的、限到什么时候才能恢复，Polygon都写得明白。

TickDB没有限流问题，限制只来自服务器本身的CPU和内存，不过如果查询条件没走索引，全表扫描照样会把CPU打满。

3.3 数据入库与查询：TickDB实战场

为了测试TickDB的实际效果，我做了这样一个实验：用Polygon的API拉取某只股票过去一年的分钟线数据，总共大约25万条记录，清洗后写入TickDB，然后在上面跑几个常见查询——查某一天全部K线、查某一段时间的最高价、以及聚合计算日均成交量。

写入时间大约花了20秒，这其中包括网络拉数和本地入库。查询测试的结果让我比较惊喜，在已经建好时间索引的情况下，查询某一天的数据只需要50毫秒左右，聚合计算也基本都在100毫秒级别。如果换成用pandas直接读CSV，光是加载全部数据到内存就要几十秒，查询更是没法比。

这也验证了我前面的判断：TickDB这类时序数据库真正的主场是大量历史数据的反复查询和多维度聚合分析。如果你的工作流里只有“每天拉一次数据、存个CSV、用excel看一眼”，那没必要上数据库；但如果你在做分钟级或者tick级的策略回测，需要反复读取不同时间段的数据，那它绝对值得投入时间。

4. 实测中的常见问题与选型建议

4.1 高频踩坑实录：数据源故障排查手册

我在实际测试过程中碰到过不少问题，有的是数据源本身的问题，有的是自己使用姿势不对。这里整理一份清单，你遇到类似现象可以直接对照排查。

还有一种很隐蔽的情况：Tushare的分钟线数据在盘中可能会出现延迟或者数据不完整的情况，因为它的分钟数据在收盘后才会校验补全。如果你在盘中拉数据，建议只看当日已收盘的K线，或者等当日收盘后一小时再拉全量数据。

4.2 数据源选型决策表：按需取用

我不太喜欢下“某某最好”这种结论，更愿意给你一个按场景选型的参考。

有一点我需要提醒：数据源和数据仓库是两个层面的事。不要在代码里面直接散落一堆CSV文件，时间一长你会发现不同时期的数据格式都不一致。建议尽早确立“上游API采集、中游清洗入库、下游查询分析”的架构，不管上游用哪家，中间层用TickDB这类时序库统一纳管，后续换数据源的时候成本会小很多。

4.3 成本对比：别只看接口价格

很多人选数据源只看接口订阅价格，但其实总成本包括学习成本、运维成本和时间成本三个部分。

• Tushare在高积分需求下看起来很便宜，但要凑积分和维护脚本，一周统计下来花的时间也要算成本。
• Polygon的付费订阅试用比较灵活，Starter档适合做验证，正式研究建议直接上Developer档，避免中途被限流打断思路。
• TickDB如果自己部署，服务器费用和运维成本不是零；如果选托管服务，就按数据量计费。但数据仓库本身是长期资产，这个钱我觉得值得花。

从实际体验来讲，我自己的组合是“Tushare取A股数据 + Polygon取美股数据 + TickDB统一落库”。日线级别的策略用Tushare和Polygon各跑一份做交叉验证，tick级的研究只往TickDB写。这套组合跑了差不多两个月的模拟盘，整体数据稳定性我是满意的。

最后再分享一个小经验：无论你最终选择哪个数据源，千万不要只用一个源就去跑实盘策略。哪怕是再靠谱的供应商，也会偶尔出现数据延迟、漏数据、字段异常的问题。我建议至少找两个独立来源做交叉校验，哪怕只是对同一个标的抽几个交易日核对一下，也能过滤掉很多潜在的脏数据问题。数据准了，策略才有讨论的余地。