做量化研究这几年最让我头疼的其实不是策略模型的构建而是最底层的数据清洗。尤其是处理历史复权数据时通达信那个gbbq文件就像一只“黑匣子”里面明明存着所有股票的股本变迁记录——送股、配股、增发、拆细全都有——但通达信自己也说不清这个二进制文件的内部结构。网上的资料东一榔头西一棒子很多都是十几年前老股民发的帖子要么含含糊糊要么直接给个C语言代码片段让你自己去猜。我当时花了大半个月才把这个格式彻底摸透。这里说的“解密”并不是指文件加密了需要暴力破解而是通达信的gbbq文件用的是私有二进制格式没有公开文档。把它解析出来本质上是一次逆向工程。但只要搞清楚了它的存储规律用Python几十行代码就能把完整的数据一张表拉出来。这篇文章我把自己踩过的坑、验证过的方案、还有基于这份数据做复权计算的方法全部分享出来希望能帮同样在做行情数据处理的人少走弯路。1. 先搞清楚gbbq文件到底是什么为什么值得花时间解它1.1 一个被低估的数据宝藏gbbq是“股本变迁”的拼音缩写全称是“股本变迁文件”。它在通达信安装目录下的T0002文件夹中就能找到命名规则通常是gbbq_市场代码比如上交所的文件叫gbbq_sh深交所的叫gbbq_sz。文件没有扩展名大小一般在几百KB到几MB不等里面按顺序存储了该市场所有上市股票从上市以来到当前的每一次股权变动记录。为什么说它是宝藏因为A股上市公司做除权除息非常频繁每年年报季都有大批公司实施高送转、派现、配股。如果你的策略回测系统里直接用了不复权的行情数据遇到除权日就会出现价格跳空均线、MACD这些指标全部失真。而做前复权或后复权处理最核心的依据恰恰就是gbbq文件里记录的送转比例、配股比例和配股价格。我见过不少做量化的朋友他们图省事直接调用第三方数据库的复权因子但这至少有两个隐患一是不一定及时更新新除权的股票数据经常滞后二是复权因子的计算口径跟通达信不同导致回测结果和实盘对不上。直接解析gbbq文件你拿到的是所有复权计算的原始素材想按什么口径算都行还能跟通达信客户端显示的历史走势做交叉验证。1.2 这件事适合谁能解决什么具体问题如果你属于以下几类人这篇文章会非常实用第一类是量化策略开发者尤其是需要做分钟级或日级回测的复权处理是躲不开的环节。从gbbq提取的送股比例和配股信息配合日线数据就能自行算出准确的前后复权价。第二类是通达信公式与选股器重度用户。通达信的公式系统里有些函数的复权逻辑不够透明比如你用复权数据选股有时会选到一些指标值异常跳变的股票其实原因就是除权日没有正确处理。自己掌握了股本变迁数据就能在自定义指标里手动修正这些干扰。第三类是纯数据控和技术爱好者。通达信本地文件远不止gbbq一个值得研究的格式day文件存日线数据、min文件存分钟数据、gbbq文件存股本变迁这些格式互为补充。把gbbq搞定相当于打通了通达信本地数据体系的最后一环。但有一点我必须提前说明gbbq文件记录的是“事件”不是“价格”。它告诉你某只股票在某个日期发生了每10股送2股、每10股配3股、配股价8元这样的行为但要把它转化成复权因子你还需要结合该股票在对应除权日的实际价格进行计算。所以它更像是一张“事件表”是整个复权逻辑的数据底座。2. 文件结构拆解从文件头到记录体逐字节说清楚2.1 先看整体布局这个文件其实没有“表头”很多人拿到一个陌生二进制文件第一反应是找文件头、找魔数、找版本号。gbbq文件比较特殊——它没有一个标准意义上的文件头开头就直接是一条一条的定长记录。每条记录占固定的字节数我实测下来通达信Windows版生成的gbbq_sh和gbbq_sz文件中单条记录长度为132字节。这个信息非常关键定长记录意味着文件解析是一件极其简单的事先拿到文件总大小除以132就能得到总的记录条数然后从第0个字节开始按顺序依次切分即可。不过有一个细节要注意不同版本的通达信官方版、券商定制版、通达信金融终端数据结构有细微差异。早期版本这条记录可能只有80字节或者96字节新增字段后扩展到132字节。我在解析时同时兼容了两种长度具体策略是先用132字节去解析如果发现日期字段出现明显异常比如年份超过2040年就退回用96字节再试一遍。这个技巧后面在踩坑章节会详细说。2.2 132字节里到底装了些什么我把自己验证过的一个132字节记录布局整理成了一张表从左到右依次排列起始字节结束字节长度字段说明单位/编码012字节市场代码0深圳1上海232字节证券代码如1代表000001数字原值452字节未知/保留位通常为0694字节日期自1990年12月19日以来的天数也有版本按1900年1月1日算需实测10134字节送股数每10股送X股通常放大100倍存储14174字节配股数每10股配X股通常放大100倍存储18214字节配股价价格放大1000倍或100倍存储因版本而异22254字节分红每10股派X元税前放大100倍存储26294字节每股收益放大100倍30334字节每股净资产放大100倍34374字节流通股本单位股38414字节总股本单位股4213190字节保留扩展区全0或未知数据这里面的关键点有两个。第一日期不是整数日期而是一个偏移天数。最常见的是从1990年12月19日上交所开业日开始累计也有版本用1900年1月1日或1990年1月1日作为起始日。这就导致同一份数据用不同的基准日去换算年份会差好几年。我的建议是先用你已知的某个除权事件反推比如找一只近期刚除权的股票算出日期偏移量然后反推基准日。实测绝大多数通达信版本用的基准日是1990年12月19日。第二送股和配股的比例是放大后的整数。比如某股票公告“每10股送3股”文件里存的很可能是3000放大100倍也可能是30000放大1000倍。这个倍数跟版本有关我见过同一只股票在不同年份的文件里字段放大倍数不一致的情况。所以解析出数值后必须跟该股票实际公告做过比对不能用死参数。2.3 数据的排列规律按市场汇聚按日期递增gbbq文件里的记录排序也是有规律的。它不是按股票代码一路排到底而是上市日期早的股票优先存入排完一只股票的全部历史记录后再排下一只股票。在同一只股票内部则按日期从旧到新排列。这意味着你解析出来的记录是“分组连续”的一组是股票A的全部变迁历史紧跟着一组是股票B的全部变迁历史。如果直接从文件头一行行读完你会发现日期序列时不时回跳那不是数据错了而是换了一只股票。这种布局对解析很友好因为你只要读取第一条记录得到股票代码然后持续读取后续记录直到股票代码变化就把当前股票的所有历史股本变迁收集完毕。后续按证券代码分组成表效率非常高。3. 动手解密用Python把gbbq完整解析出来3.1 准备工作环境与工具清单解析gbbq文件不需要复杂的工具链我用的是Python 3.8以上版本配合标准库中的struct模块即可完成全部二进制解析。如果你打算把解析结果保存成数据库表或者CSV再装一个pandas就行。不需要额外安装任何第三方逆向工具。pip install pandas另外准备一个十六进制编辑器推荐HxD或者010 Editor。不要小看这个工具当解析结果出现莫名奇妙的多字节偏移时十六进制编辑器能让你直接看到每个字节的真实内容比如一段十六进制是00 00 0B B8还是B8 0B 00 00肉眼一看便知是大端还是小端。通达信文件统一使用小端序这点和x86架构一致Windows和Linux下的Python用默认的struct.unpack都不会出问题。3.2 第一个脚本按字节读取并拆解每条记录下面给出一段核心解析代码它不依赖第三方库直接读取二进制文件并逐个字段打印。这是整个解密过程的地基理解透彻了再扩展成批量导出。import os import struct from datetime import datetime, timedelta # 通达信gbbq文件路径请替换为你电脑上的实际路径 GBBQ_PATH C:/new_tdx/T0002/gbbq_sh # 日期基准日通达信常见的是1990年12月19日 BASE_DATE datetime(1990, 12, 19) RECORD_SIZE 132 # 根据实际文件版本调整也可能是96 # 打开文件并读取全部内容 with open(GBBQ_PATH, rb) as f: data f.read() total_size len(data) record_count total_size // RECORD_SIZE print(文件大小: {} 字节预估记录条数: {}.format(total_size, record_count)) for i in range(record_count): offset i * RECORD_SIZE record data[offset: offset RECORD_SIZE] # 小端序解析前42个字节 market struct.unpack(H, record[0:2])[0] code struct.unpack(H, record[2:4])[0] day_offset struct.unpack(I, record[6:10])[0] songgu struct.unpack(i, record[10:14])[0] # 送股 peigu struct.unpack(i, record[14:18])[0] # 配股 peigujia struct.unpack(i, record[18:22])[0] # 配股价 fenhong struct.unpack(i, record[22:26])[0] # 分红 eps struct.unpack(i, record[26:30])[0] # 每股收益 bvps struct.unpack(i, record[30:34])[0] # 每股净资产 the_date BASE_DATE timedelta(daysday_offset) # 只打印前5条记录作为验证 if i 5: print(记录{}: 日期{}, 市场{}, 代码{:06d}, 送股{}, 配股{}, 配股价{}, 分红{}, 每股收益{}, 每股净资产{}.format( i, the_date.strftime(%Y-%m-%d), market, code, songgu, peigu, peigujia, fenhong, eps, bvps ))运行这段脚本正常情况下你会看到类似下面的输出文件大小: 1549032 字节预估记录条数: 11735 记录0: 日期1991-01-02, 市场1, 代码000002, 送股0, 配股0, 配股价0, 分红0, 每股收益50, 每股净资产327如果记录0显示的时间是2099年这种明显不合逻辑的值就说明日期基准日不对需要调整BASE_DATE。如果记录0显示的时间是1990年之前也可能是记录长度不对需要尝试96字节方案。3.3 批量导出“一行一只股票”的全历史变迁表直接打印所有记录显然不现实。更实用的做法是解析全部记录后按证券代码聚合最后输出成一张csv表每只股票的所有事件按日期排列。贴心的做法是先按代码分组再按日期排序这样后续直接跟行情数据merge即可。import pandas as pd records [] for i in range(record_count): offset i * RECORD_SIZE record data[offset: offset RECORD_SIZE] market struct.unpack(H, record[0:2])[0] code struct.unpack(H, record[2:4])[0] day_offset struct.unpack(I, record[6:10])[0] songgu struct.unpack(i, record[10:14])[0] peigu struct.unpack(i, record[14:18])[0] peigujia struct.unpack(i, record[18:22])[0] fenhong struct.unpack(i, record[22:26])[0] eps struct.unpack(i, record[26:30])[0] bvps struct.unpack(i, record[30:34])[0] the_date BASE_DATE timedelta(daysday_offset) stock_code {:06d}.format(code) records.append({ date: the_date.strftime(%Y-%m-%d), market: market, code: stock_code, songgu: songgu / 100.0, # 送股注意放大倍数 peigu: peigu / 100.0, # 配股 peigujia: peigujia / 1000.0, # 配股价 fenhong: fenhong / 100.0, # 分红 eps: eps / 100.0, bvps: bvps / 100.0, }) df pd.DataFrame(records) df df.sort_values([code, date]).reset_index(dropTrue) df.to_csv(gbbq_parsed.csv, indexFalse, encodingutf-8-sig) # 显示每个股票的事件数量验证数据是否完整 print(df.groupby(code).size().describe())注意我在读配股价时用的是放大1000倍而读送股时用的是放大100倍。不同字段的放大倍数不同这是我逐一比对公告后得出的结论。如果你的通达信版本较老配股价也可能是放大100倍存储建议用一只你熟悉的配过股的股票来验证。比如某只股票在一段时期内的配股价是8.5元解析出来是8500还是850000试一次就能确定。3.4 解析完成后的校验方法为什么必须做这一步解析脚本跑通后不意味着工作结束校验才是关键。我的习惯是抽查三只不同行业的股票把解析出来的送转比例、分红金额和它们在对应年份的公告做逐一比对。只要有三条记录能对上基本就可以确认整个文件的解析逻辑是可靠的。另外数据条数本身也是一个强力信号。沪深两市约有5000多只股票上市早的公司可能有上百条历史变迁记录次新股可能只有几条。groupby(code).size()的输出结果如果显示平均每只股票有2到3条记录说明数据合理如果平均只有0.01条大概率是记录长度解析错了只读到了文件的一小部分。我把自己用过的校验脚本整理成了一个内置检查项——打印出记录数最多的10只股票。正常情况下应该是平安银行、万科A、ST这些上市最早的元老股记录数应该在50条以上。如果记录最多的是某只2015年后上市的次新股那说明排序或切分逻辑出问题了。4. 拿到股本变迁数据之后复权因子的完整计算链路4.1 为什么除权需要“复权”打包成生活化的事例先讲个简单的例子。假设某股票除权前收盘价是10元公司实施每10股送10股除权日参考价就是5元。如果你用原始价格画K线图股价在除权日当天直接“腰斩”而实际上持有人的总市值并没有变化。这种由于股本变动引起的价格断裂会严重干扰趋势判断和技术指标计算均线会掉头向下MACD会出现虚假金叉死叉动量因子会计算出吓人的负收益。复权的本质就是把历史价格调整到同一个股本口径下让价格的连续性与真实投资回报保持一致。后复权是把历史上所有价格按累计因子统一放大到当前口径前复权则是把当前及以后的价格按累计因子缩小到最早口径。无论哪种方式核心参数都来自gbbq文件中的送股比例、配股比例和分红金额。4.2 用Python计算每日复权因子复权因子的计算并不复杂关键是理解“事件对每股价值的影响”。把每日的累计因子F(t)定义为从上市日到t日每一股原始股票由于所有股本变迁事件而等价的当前股数或价值倍数。常见算法是初始化 F(0) 1 遍历按日期排序的所有股本变迁事件日期为 t_event: F(t_event) F(t_event-1) * (1 送股比例 配股比例) - 配股价 * 配股比例 F(t_之后每一天) 上一个因子值等等这个写法严格来说混淆了三种不同的因子。分开说明一下后复权因子的典型计算方式是遇到每股送转股时因子乘以(1送转比例)遇到配股时因子乘以(1配股比例)同时由于股东需要掏钱配股还要在价格上做减法调整这一步会让后复权价格带上“股东权益变动”的含义。更精确的公式是借助“除权参考价”概念除权参考价 (前收盘价 - 每股现金分红 配股价 × 配股比例) / (1 送股比例 配股比例)后复权因子在除权日要乘以(1 送股比例 配股比例)的倒数或者直接按比例调整不同计算器口径不一样。实际在量化系统里我更推荐用“累计复权因子法”factor 1.0 for each event in sorted_events: factor factor * (1 送股比例 配股比例) - 配股价 * 配股比例 然后从事件日起后续所有日期的复权因子都更新为 factor这里的“配股比例”通常大于0但小于1比如每10股配3股则配股比例0.3。这个递推公式同时考虑了送转股的存量分摊和配股的新增资金流入是在学术和业界都比较通用的口径。前复权则是在拿到最新复权因子后反推前复权价 原始价 × 最新因子 / 当日因子。后复权价 原始价 × 当日因子。两者选一即可我一般默认用后复权做回测因为后复权数据是单调递进的不会因为新增了最新一根K线而让整个历史价格全部变化更容易定位策略行为。4.3 结合日线数据生成最终的复权行情表拥有复权因子序列后结合普通日线数据就很高效了。先读取通达信day文件或从行情接口导出的OHLCV数据然后与因子序列按日期合并。核心代码示意如下# daily: 已读入的日线数据包含date, open, close, high, low, volume # factor_df: 从gbbq计算出的每日复权因子列名date, factor merged pd.merge(daily, factor_df, ondate, howleft) merged[factor] merged[factor].ffill().fillna(1.0) # 没有事件的日期沿用最近的因子 # 后复权价格 merged[close_adj] merged[close] * merged[factor] merged[open_adj] merged[open] * merged[factor] merged[high_adj] merged[high] * merged[factor] merged[low_adj] merged[low] * merged[factor]这里有三个实操细节要提醒。细节一成交量要不要复权好问题。如果送转股比例为每10股送10股总股本翻倍成交量数值理论上也该翻倍但市场成交量统计的是“股数”除权日当天成交的股数本身就对应着除权后的股本口径。如果直接拿不复权的成交量做量价分析除权日当天会出现“量比突增”的假象。很多量化框架在复权时会同步做volume_adj volume * factor / factor_shift(1)这个因子是相邻两日复权因子的比率能正确反映股本口径变化带来的成交量放大缩小。细节二除权日当天本身怎么处理由于除权参考价源于前收盘价计算实践中通常把除权日的当日价格当作已经“正确”的复权结果然后用因子把更早的历史数据统一到最新口径。因此在做前复权时最新一天的复权因子通常设为1往前逐日回溯。细节三分红对因子是否有影响如果你做的是“价格复权”通常只考虑送转股和配股因为分红后股价下调但股东权益不变不复权会导致历史价格系统性偏高。但如果你在计算总回报指数或考虑红利再投资就需要把每股分红也纳入因子计算公式改为当前收盘价减去分红再除以上一日收盘价然后连乘。这个口径在CTA策略和多因子选股里差异很大建议一开始就把口径写清楚免得回测和实盘对不上。5. 四类高频问题与排查技巧实录5.1 记录的日期全是2099年明显不对这是最常见的翻车现场。通常有两个原因一是日期基准日设错了。我实测过的通达信版本中1990年12月19日是一个高频基准日但你电脑上的券商定制版可能用2000年1月1日或2010年1月1日作为起点。解决办法很简单找一只你知道确切除权日的股票反推偏移天数然后算出基准日。比如已知某股票2023年6月15日发生了高送转事件解析出来的day_offset是11872那么基准日就是2023年6月15日往前推11872天。用这个反推值替换掉固定基准日所有日期就都正常了。二是记录长度解析错了把132字节当成96字节或反之。这会导致字节错位字段串联日期字段取到了其他字段的中间几个字节表现就是日期乱飞。遇到这种情况先用十六进制编辑器打开文件找到一只已知股票的代码和日期逐个字节对照确认字段边界后再改代码。5.2 送股比例读了1000但公告写的是10送3这是放大倍数的问题。通达信不同版本对同名字段可能采用不同的定点数标度。送股比例字段见到的有放大100倍和放大1000倍两种。我的建议是不要在代码里写死而是先解析一只明星股的已知事件做“标定”。比如贵州茅台历史上某次“10派100元”的事件如果解析出的分红字段是100000那你除以1000就是100元除以100就是1000元显然除1000才对。标定通过后再批量解析所有记录能避免一错错一片。顺带提醒一句配股价和分红也存在类似问题但不同字段的放大倍数不必然一致。我见过同一版本里送股字段放大100倍、配股字段放大100倍、配股价却放大1000倍的“混搭”情况。务必逐个字段用真实公告核对。5.3 通达信正在运行时文件被占用脚本读不到这几乎是每个初尝者都会遇到的坑。通达信客户端启动后gbbq文件会被进程锁定Windows下Python直接打开会报PermissionError。解决办法有几种最省事的是先关闭通达信再运行解析脚本如果必须实时解析比如做盘中数据同步可以复制一份文件到临时目录再读Windows下复制共享的文件是允许的用shutil.copy就能解决。import shutil shutil.copy(C:/new_tdx/T0002/gbbq_sz, C:/temp/gbbq_sz.bak)另外一个很多人不知道的技巧通达信的gbbq文件其实只在启动时加载一次盘中除权数据更新不会实时写入。所以你盘中解析到的是开盘时的旧数据如果当天有股票实施除权除息最快也要等通达信主动重新读取或重启客户端后才会体现。这对做日内策略的朋友是个挺重要的认知。5.4 解析出来只有最近几年数据历史数据缺失这通常不是解析问题而是通达信客户端设置问题。有些精简版通达信或券商定制版为了减小安装体积默认只下载最近几年的股本变迁数据。解决方法是让通达信执行“盘后数据下载”完整下载历史数据后再去重新读取gbbq文件。下载路径一般是在“系统”菜单里找到“盘后数据下载”勾选“日线和实时行情数据”和“财务数据”执行一次全量下载。完成后gbbq文件会明显变大再次解析就能看到1990年代的老数据。我实测发现某些定制版通达信只保留最近20年的数据即使下载也无法补齐早期记录这时就需要从其他渠道补充老股票的历史送转股数据或者直接用第三方数据库提供的原始财务公告文件合并进去。5.5 问题速查表故障现象可能原因解决思路文件读取报权限错误通达信客户端锁定了文件先关闭客户端或复制文件到临时路径再读取日期都变成2040年以后日期基准日设置错误用已知除权事件反推基准日打印记录时字段错位记录长度判断错误用十六进制编辑器验证字段边界尝试96/80字节送股比例与公告差10倍字段放大倍数错误用一只明星股的真实事件做标定程序能读但没有任何记录文件路径指向错误或版本不支持确认T0002目录下有gbbq文件检查文件名股票代码全对但日期乱序每只股票内部需要单独排序解析后按code分组再按date排序历史最远的记录只到2000年盘后数据未完整下载执行通达信盘后数据下载补齐历史同一事件重复出现在两个文件沪市深市各有一个gbbq文件合并时按市场代码区分避免股票代码冲突6. 应用扩展从股本变迁到选股和事件驱动策略解析出gbbq数据之后用途绝对不止复权这一件事。我后来在策略系统里直接基于这份数据做了几个事件驱动模块效果比单纯做技术指标好得多。第一个是“高送转事件预测和次新不送转股识别”。通过gbbq数据里每股收益、每股净资产这些字段再结合最新财报数据判断某只股票是否有高送转潜力。送转概率模型在很多行情软件里是被包装成付费指标的但实际上只要把历史送转比例和当期每股资本公积、未分配利润做简单的条件过滤就能得到不错的事件股备选池。第二个是“除权前后价格行为分析”。通过解析出的除权日期可以批量统计除权日前后的超额收益分布——这是事件研究法里很经典的范式。A股有些股票除权日当天有明显填权行情有些则持续贴权这些行为与基本面、送转比例、大盘环境都高度相关。有了完整的数据表回测这些行为逻辑只需要几十行代码。第三个是“股本变化监控”。增发、配股、送转这些行为本质上改变了公司的股本结构和每股含金量它们是基本面研究的重要信号。通过每日重新解析gbbq文件并对比上次解析结果就能第一时间发现哪些公司发布了新的股本变迁记录。结合公告日期做策略触发能抓到很多早期异动机会。我在实测中发现真正能稳定带来alpha的事件并不是高送转本身而是“高送转预期落空”或“高送转预期实现后的回调”。这种预期差的产生正是因为市场上绝大部分投资者做不到第一时间拿到准确的股本变迁数据。通达信gbbq数据作为事件源头相当于给你装了一个与主流行情软件同步的信息窗口。7. 个人实操经验补充关于精度、版本和长期维护最后再说几个不一定能写进教程、但在实际项目中帮了我大忙的经验。关于字段精度。gbbq文件里的股本数值是以“股”为单位的整数但A股存在大量“每10股转增1.0000股”这样精确到小数点后四位的方案。通达信在存储时会做定点化处理放大10000倍后再存整数。所以解析总股本、流通股本时要注意区分它是精确值还是放大后的值。我遇到过一次股权分置改革中的特殊情况总股本字段的放大倍数跟正常状态不一样最终发现问题出在上市公司公告里对“转增”和“送股”的表述差异上。切记数据本身没有错但是你对字段语义的理解可能错。关于不同版本通达信的兼容性。通达信官方版、通达信金融终端、各券商定制版使用的gbbq文件格式会有微调。券商定制版经常在头部增加一段自定义配置导致文件开头偏移量不同金融终端则可能在记录尾部追加额外字段。因此写通用解析器时要做好“自适应”先扫描文件前几千字节找一个连续出现N条记录的模式通过模式匹配自动确定记录长度和起始偏移。这种思路不需要硬编码所有版本靠“发现规律”而非“记住格式”来解析后续维护成本低很多。关于文件编码。gbbq文件里记录的名词和字段都是纯二进制数值不存在字符串编码问题。但如果你同时解析通达信的同花顺类文本输出要注意通达信导出的文本文件默认使用GBK编码在Python里读取时最好显式指定encodinggbk否则中文乱码会让你误以为数据有问题。关于安全感和确认步骤。我的习惯是每次解析后都会随机抽5只股票用通达信客户端手动对照一下这些股票的“历史股本变动”页面。这种对照虽然原始但极有效任何格式变化第一时间就能发现。通达信本身也提供了一个图形化查看入口在个股界面按F10进入基本资料找到“股本结构”或“分红扩股”栏目所有历史送配信息都能看到。把这些页面数据当成GroundTruth校验解析脚本的结果比自己死磕文档可靠得多。解析gbbq这件事说到底是个基础工作但基础工作的价值恰恰在于它能让你所有上层的分析、策略、指标都建立在可控、可验证的数据之上。如果你后续想把这套解析能力整合进自己的数据管线我建议直接从“每次运行都重新解析文件并缓存结果”这个模式起步既能保证数据最新又不会因为频繁读取同一个二进制文件造成IO瓶颈。用一次扎实的解析换来日复一日稳定的数据供给这笔投入非常划算。
