OHLCV

亚娜先选择交易所、交易对和时间间隔。交易对说明什么资产换什么资产，例如比特币兑美元。Kraken 将 Open 定义为时段内首笔交易的价格，Close 则是最后一笔的价格。High 和 Low 是实际达到的最高和最低成交价。亚娜不用逐笔阅读，就能看出价格区间和首尾变化。但这些价格都不自动等于平均价，也不是订单簿里的当前报价。 [1]

除了价格变化，亚娜还想知道实际成交了多少。Kraken 用交易对的基础资产表示 Volume，因此 BTC/USD 的成交量以比特币计。Binance 还区分计价资产的成交额，在这个例子中就是美元，并单独列出成交笔数。比特币数量、美元价值和成交次数是不同指标。一个没有单位的大数字并不能说明市场多活跃，首先要知道数据源究竟在统计什么。 [1] [2]

亚娜在别处看到不同的日线，怀疑数据有错。下结论前，她还得比较时间边界。Binance 可以通过时区参数 timeZone 定义区间，但用于选取数据的 startTime 和 endTime 仍按 UTC 这一通用世界时间基准解释。一天的起点不同，纳入的交易就可能不同。因此只写日线还不够，市场、时间范围和时间戳的含义都需要一致。 [2]

实时图上最新的蜡烛线会不断变化。Kraken 的 REST 接口供程序按需请求数据，其中始终包含当前尚未结束的时段。它的 Close 暂时只是最近已知成交价，不是最终收盘价，成交量也可能继续增加。亚娜比较已结束时段时，需要把这根未完成的蜡烛线区别开来，否则就是把已经定稿的历史与仍在形成的数据放在一起比较。 [3]

有时数据中缺少一个时段。Coinbase 提醒历史记录可能不完整，而且没有交易事件的时段不会发布蜡烛线。因此亚娜不能把空白理解成价格跌到了零。她首先需要确认，是没有发生交易，还是数据缺失。沿用上一笔价格也不会产生一笔新交易；如果图表用这种方式填补空白，就应让读者能够识别这项处理。 [4]

编写图表程序还有一个陷阱：OHLCV 这个缩写并不保证返回字段的排列顺序。Coinbase 列出的是时间、Low、High、Open、Close、Volume。Kraken 还单独提供成交笔数和 VWAP，也就是按成交数量加权的平均价格。程序必须按照具体接口的文档读取每个字段。字段错位未必让图表明显损坏，也可能画出一条看似可信、含义却错误的曲线。 [4] [1]

从 Kraken 的定义还能推导正确的区间合并方法。如果亚娜拥有同一市场完整、连续且互不重叠的时段，应取第一个 Open 和最后一个 Close。High 取各最高价中的最大值，Low 取各最低价中的最小值，可比较的 Volume 则相加。把开盘价求平均会得到另一种结果。合并前还须检查时间顺序、重复数据及缺口，相加并不能补回遗漏的交易。 [1]

Coinbase 的汇总字段没有保留完整成交顺序，也没有保留订单簿中的等待报价。蜡烛线可以同时显示高价和低价，却不告诉你哪个先出现。亚娜拿历史数据测试假设订单时，单凭 High 和 Low 无法证明价格门槛被触及的顺序，也无法证明订单真的会成交。OHLCV 是了解过去的有用摘要，但不能取代逐笔记录或自己的订单确认。 [4]