今天我瀏覽了 GRVT 的行情（ticker）數據源結構，主要是因爲弄清楚單個 ticker 更新究竟包含什麼信息，對於把我在這次迭代（sprint）中構建的市場數據全景圖完善收尾非常關鍵。
一個 ticker 大概會展示最新成交價、24 小時內的最高價與最低價、24 小時成交量，以及可能還會給出在同一時間窗口內的百分比變化。它以緊湊的快照形式提供，而不需要客戶端自己從原始成交歷史中推導這些統計指標。
我覺得值得注意的是：從本質上說，這是一層方便性的“封裝”，建立在我之前查看過的、從成交（trades）數據源技術上可以推導出來的數據之上。理論上，客戶端可以自行處理完整的成交歷史來計算 24 小時的最高價、最低價和成交量，但由 GRVT 進行計算並直接進行流式分發，這會消除原本每一個客戶端都不得不獨立維護同樣滾動計算所帶來的真實計算負擔。
這也呼應了我這周在 GRVT 更廣泛的數據源設計中注意到的一種模式：原始的細粒度數據存在（例如訂單簿深度、單筆成交），同時也存在彙總、預先計算好的視圖——用於那些實際上並不需要完整細節的場景。
在以本次迭代的收尾結論爲“GRVT 的 API 暴露面似乎始終圍繞同樣的取捨來設計”這一點上：需要精確度的人使用細粒度數據，需要快速獲得準確概覽的人使用匯總後的數據。
@grvt_io #grvt
一個 ticker 大概會展示最新成交價、24 小時內的最高價與最低價、24 小時成交量，以及可能還會給出在同一時間窗口內的百分比變化。它以緊湊的快照形式提供，而不需要客戶端自己從原始成交歷史中推導這些統計指標。
我覺得值得注意的是：從本質上說，這是一層方便性的“封裝”，建立在我之前查看過的、從成交（trades）數據源技術上可以推導出來的數據之上。理論上，客戶端可以自行處理完整的成交歷史來計算 24 小時的最高價、最低價和成交量，但由 GRVT 進行計算並直接進行流式分發，這會消除原本每一個客戶端都不得不獨立維護同樣滾動計算所帶來的真實計算負擔。
這也呼應了我這周在 GRVT 更廣泛的數據源設計中注意到的一種模式：原始的細粒度數據存在（例如訂單簿深度、單筆成交），同時也存在彙總、預先計算好的視圖——用於那些實際上並不需要完整細節的場景。
在以本次迭代的收尾結論爲“GRVT 的 API 暴露面似乎始終圍繞同樣的取捨來設計”這一點上：需要精確度的人使用細粒度數據，需要快速獲得準確概覽的人使用匯總後的數據。
@grvt_io #grvt
