一个交易应用要接5家数据供应商,同一种资产却有12种命名方式——这不是技术难题,是命名权的战争。
从"简单调用API"到"代码翻译地狱"
![]()
TradingGoose团队最初的想法很直接:做一套通用数据连接器,让用户能自由切换Alpaca、Yahoo Finance、Alpha Vantage、Finnhub等多个数据源,既能按需选择,也能多源备份。
美股还算规矩。苹果股票在Alpaca是AAPL,在Yahoo Finance也是AAPL,复制粘贴就能用。
一迈出美股市场,混乱开始指数级膨胀。
同一只上海交易所的股票,在不同平台可能是:
外汇市场更离谱。EUR/USD货币对在Yahoo Finance叫EURUSD=X,在Finnhub变成OANDA:EUR_USD——前缀、分隔符全不同。加密货币是重灾区:BTC/USD在Alpaca是BTC/USD,在Yahoo是BTC-USD,在Finnhub是BINANCE:BTCUSD,在Alpha Vantage又是BTCUSD。
后缀系统也各自为政:^表示指数、.ETF标记基金、=X标记外汇对。有的平台prepend交易所标识,有的干脆不用分隔符。
没有统一的"canonical identity"(规范标识符),开发者就得为每个平台、每类资产维护一套字符串转换逻辑。供应商一改格式,全线崩溃。
开源世界早有先驱:两种截然不同的解法
CCXT选择了"动态归一化"。所有加密货币交易对被统一成BASE/QUOTE格式,比如BTC/USDT。无论交易所用BTCUSDT(Binance)、XXBTUSDT(Kraken的X/Z前缀)、tBTCUSD(Bitfinex的t前缀)还是BTC_USDT(Poloniex的下划线),CCXT都翻译成同一套标准。
每个交易所类维护一个hardcoded的commonCurrencies字典,把非标准代码映射到规范形式。仅Kraken就有30多条映射:XXBT→BTC、XETH→ETH、ZEUR→EUR。Bitfinex还要处理历史遗留:UST→USDT、LUNA→LUNC。每次交易所分叉或升级,字典得手工更新。
这套系统在加密货币圈内运转良好,但边界也很清晰:跨资产类别时力不从心,且维护成本随交易所数量线性增长。
QuantConnect的LEAN走了另一条路:为每个证券 engineered 一个永久、不可变的标识符。SecurityIdentifier把证券类型、市场代码、行权价、期权类型、到期日、看跌/看涨标记全部编码进一个64位整数,用嵌套模偏移实现紧凑存储。
Symbol类包裹这个底层ID,同时提供一个可变的Value字段——人类可读的股票代码。代码可以随时间变化(公司更名、合股),但底层标识符恒定不变。
处理代码变更和退市时,LEAN用CSV映射文件,每个证券一个文件。
TradingGoose的困境:没有现成答案
CCXT和LEAN代表了两个极端:前者轻量但局限于加密资产,后者精密但工程复杂度高。TradingGoose需要覆盖股票、外汇、加密货币多类资产,又不能承受LEAN级别的架构重量。
更麻烦的是供应商的"命名政治"。Yahoo Finance的EURUSD=X、Finnhub的OANDA:EUR_USD、Alpha Vantage的裸BTCUSD——这些差异不只是技术选择,背后是各平台的历史路径、商业协议和数据授权体系。
统一标识符意味着要在这些利益格局中建立"通用语",而数据供应商未必有动力配合。
TradingGoose团队最终意识到,这个问题没有一次性解决方案。他们得在CCXT式的轻量适配和LEAN式的永久标识之间,找到适合自己业务规模的平衡点——同时接受一个事实:每新增一个数据源,就是新增一份需要持续维护的"翻译契约"。
这大概是多源数据整合最隐蔽的成本:不是API调用费,是命名权协调的无限游戏。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.