Polymarket数据为什么散？这一款开源索引器把行情和成交塞进同一个DuckDB
把CLOB市场元数据与Polygon链上成交合并写入一个DuckDB文件，可断点续传，可用SQL查询，适合做预测市场研究与策略回放。
适合：需要批量拉取Polymarket历史成交、做预测市场研究与策略复盘的个人或小团队。
先说结论
Polymarket研究难，数据散是头号原因。市场元数据在CLOB接口里，历史成交埋在Polygon合约里，两边口径不一致，时间戳还错位。要做一次像样的复盘，往往要先拉一堆API，再清洗脚本折腾半天。
nahrek/polyledger的思路很直接：写一个Python任务，把CLOB元数据和Polygon链上交易按市场维度合并，落盘成一个DuckDB文件，可断点续传，最后用一句SELECT就能查。
它不能帮你做决策，但能把决策前那条最脏的数据通路给打通。
真正的问题
预测市场的数据之所以难用，症结在三处。
一是来源分裂。一边是Polymarket官方CLOB接口，能拿到市场标题、规则、结果和盘口；另一边是Polygon链上事件，能拿到真实的下单、成交和结算。两者不互通，命名空间也不一样。
二是同步成本。链上数据用普通RPC节点逐条轮询，速度慢、成本高，遇到断网或脚本崩溃就要从头再来。
三是查询割裂。CSV和JSON只适合一次性分析，做不了稳定的回放和对比。一份能复现的本地数据文件，往往比一份漂亮的可视化更值钱。
把这三件事串起来，是这类索引器的核心价值。
怎么做更省力
| 步骤 | 关键动作 | 建议工具 |
|---|---|---|
| 初始化 | 配置RPC，启用断点续传 | Python脚本 |
| 拉取元数据 | 调用CLOB接口，拿到市场列表 | polyledger自带模块 |
| 同步成交 | 通过HyperSync批量取链上事件 | hypersync客户端 |
| 合并落库 | 写入DuckDB，建立索引 | DuckDB CLI或Python SDK |
上表里有一个值得单独说的点：链上数据那一段用的是Envio的HyperSync而不是传统节点轮询。差别在于，HyperSync是面向历史回放的批量协议，吞吐比JSON-RPC高一两个数量级，这也是它能把“几分钟跑完几个月数据”变成现实的基础。
数据落进DuckDB之后，剩下就是SQL的活了。比如想看某个市场从开盘到结算的成交分布：
SELECT timestamp, price, side, size
FROM trades
WHERE market_id = ?
ORDER BY timestamp;如果你要把这份数据整理成可读报告，可以用职场汇报生成器把查询结论拼成结构化文本；要做研究复盘或对外分享，再用Markdown智能编辑器排版输出。
哪些坑要避开
一是不要把它当成实时数据源。它是索引器，定位在历史回放和批处理，把它当成行情API用就错了。
二是注意RPC和HyperSync的配额。批量拉取很快，但有限速。公共节点通常扛不住完整历史，部署前先算一笔账。
三是市场元数据和链上交易的ID不一定一致。要按tokenID或conditionID做映射，否则会出现“同一个市场两个名字”的尴尬。
四是DuckDB是单文件，适合个人研究和中等规模分析；数据量到了亿级行数，要考虑切分或迁移到ClickHouse，否则单文件会膨胀到几百 GB。
五是Polymarket的合约和接口都在演进，老脚本可能因为ABI升级失效，最好把版本固定在依赖里。
现在就能动手
如果你手里正好有预测市场的研究需求，最快的起步方式是：先克隆仓库，按README里的步骤跑通最小流程，目标是生成一份只覆盖一两个市场的DuckDB文件。接着用DuckDB CLI打开，跑几条聚合SQL验证字段含义。最后再扩大拉取范围，把CLOB的盘口数据和链上成交在同一张表里JOIN，确认口径一致。
过程中如果需要把查询结果整理成可分享的图表或工作流说明，可以顺手用Markdown智能编辑器输出。整条链路打通后，原本要花一两天拼数据的研究，往往能压缩到几小时。