一、背景
隨著移動網際網路、物聯網、大資料等行業的高速發展，資料在持續的以指數級的速度增長，比如我們使用手機訪問互網路時的行為資料，各種可穿戴裝置上報的狀態資料，工廠中裝置感測器採集的指標資料，傳統網際網路公司的監控資料等。實際上，這些按照時間順序記錄系統、裝置狀態變化的資料都是時序資料（Time Series），它普遍存在於網際網路、物聯網、IT基礎設施中。
得益於軟硬體技術的快速發展，處理如此龐大的時序資料集的成本在持續降低，更多公司開始持續收集、分析資料，用於異常處理、趨勢預測、精準營銷、風險控制等場景，希望利用資料的潛在價值，提高公司盈利能力和競爭力。這裡舉兩個例子：
1.下圖為某共享單車在舊金山某熱門區域的車輛借還情況。通過分析該區域車輛的歷史借還資料，單車公司可優化熱點時間段的車輛補給。
2. 下圖為某網際網路服務的出入流量歷史記錄。從圖中可以明顯看到入流量（藍色線）在某時間段有毛刺，服務提供商可基於此段時間排查服務有無異常。可以進一步基於流量監控做告警，使運維人員能夠及時處理線上問題。
二、傳統時序資料解決方案存在大量問題
傳統的時序資料解決方案及問題如下：
1. MySQL等關係型資料庫：
- 寫入吞吐低：單機寫入吞吐低，很難滿足時序資料千萬級的寫入壓力；
- 儲存成本大：對於時序資料壓縮不佳，需佔用大量機器資源；
- 維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；
- 查詢效能差：適用於交易處理，海量資料的聚合分析效能差。
2. Hadoop、Spark等批處理系統
- 資料延遲高：離線批處理系統，資料從產生到可分析，耗時數小時、甚至天級；
- 查詢效能差：不能很好的利用索引，依賴批處理任務，查詢耗時一般在分鐘級以上。
3. HBase
- 多維分析能力差：HBase可以較好的滿足寫入壓力，但對於非RowKey字首的查詢效能較差；
- 維護成本：使用HBase需要同時維護HBase和Hadoop等系統，且HBase的穩定性會進一步加大維護成本。
三、寫入、儲存、查詢多環節優化，時序資料庫優勢明顯
1. 時序資料模型及特點
在引入時序資料庫之前，先要了解【時序資料】的模型及特點。
1.1 時序資料的數學模型
前面介紹了時序資料的場景，也說明了分析時序資料的意義及傳統方案。那麼時序資料該怎樣儲存呢？資料的儲存要考慮其數學模型和特點，時序資料當然也不例外。這裡以一段時序資料為例，介紹下時序資料的數學模型。
下列資料記錄了一段時間內某叢集裡各機器上各埠的出入流量，每半小時記錄一個觀測值：
- metric： 相關聯的資料集合，類似於關係型資料庫中的 table；
- point： 一個時序資料點，類似於關係型資料庫中的 row；
- timestamp： 時間戳，表徵時序資料產生的時間點；
- tag： 維度列，用於描述裝置/系統的屬性，表明是哪個裝置/模組產生的，一般不隨著時間變化；
- field： 指標列，用於描述裝置/系統狀態的變化，隨時間平滑波動。
1.2 時序資料特點
- 資料模式： 時序資料隨時間增長，相同裝置/系統的維度資訊不變，指標平滑變化，這點從上面的Network表的資料變化可以看出。
- 寫入： 持續高併發寫入，無更新操作：時序資料庫面對的往往是百萬甚至千萬數量級終端裝置的實時資料寫入（如摩拜單車2017年全國車輛數為千萬級），但資料大多表徵裝置狀態，寫入後不會更新。
- 查詢： 按不同維度對指標進行統計分析，且存在明顯的冷熱資料，一般只會頻繁查詢近期資料。
2. 時序資料庫
2.1 時序資料庫
時序資料庫是管理時序資料的專業化資料庫，並針對時序資料的特點對寫入、儲存、查詢等流程進行了優化，從而解決時序資料處理難題：
- 儲存成本：
o 利用維度重複、時間遞增、指標平滑變化等特性，合理選擇編碼壓縮演算法，提高資料壓縮比；
o 通過預降精度，對歷史資料做聚合，節省儲存空間。
- 高併發寫入：
o 資料批量寫入，降低網路開銷；
o 資料先寫入記憶體，再週期性的dump為不可變的檔案儲存，提高寫入速度。
- 低查詢延時，高查詢併發：
o 優化常見的查詢模式，通過索引等技術降低查詢延時；
o 通過快取、routing等技術提高查詢併發。
2.2 開源時序資料庫對比
目前行業內比較流行的開源時序資料庫產品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其產品特性對比如下圖所示：
從上表可以看出，開源的時序資料庫存在如下問題：
- 沒有free、易用的分散式版本（OpenTSDB支援分散式部署，但依賴系統過多，維護成本高）；
- 聚合能力普遍較弱，而時序資料大多需要來做統計分析；
- 沒有free的許可權管理；
- 沒有針對時間序列的多維度對比分析工具。
四、歷經每日萬億寫入吞吐，騰訊雲CTSDB技術架構
騰訊CTSDB（Cloud Time Series Database）是一種分散式、高效能的時序資料庫，針對時序資料的高併發寫入、存在明顯的冷熱資料、IoT使用者場景等做了大量優化，同時也支援各行業的日誌解析和儲存。在騰訊內部支撐騰訊雲等每日萬億寫入吞吐的場景，經過嚴苛的壓力打磨。其架構如下圖所示：
1. CTSDB主要特點
- 高效能：（具體效能資料參考後文測試部分）
o 支援批量寫入、高併發查詢，以及強大的分析聚合能力；
o 通過橫向擴充套件，線性提升系統效能；
o 支援sharding、routing，加速查詢。
- 高可靠：
o 分散式系統，支援多副本；
o 機架感知，自動錯開機架分配主從副本。
- 易使用：
o 豐富的資料型別，REST介面，資料寫入查詢均使用json格式；
o 原生分散式，彈性可伸縮，資料自動均衡；
o 許可權系統：支援使用者名稱密碼、機器白名單的許可權系統。
- 低成本：
o 支援列儲存，高壓縮比（0.1左右），降低儲存成本；
o 支援資料預降精度：降低儲存成本的同時，提高查詢效能。
o 副本數可按需調整。
- 相容開源生態：
o 相容Kibana/Logstash/Beat等元件，方便資料採集及視覺化分析；
o 支援從MySQL、Kafka等開源生態同步資料，方便遷移。
2. 競品效能對比測試
這裡選用業界較為流行的InfluxDB來與CTSDB做效能對比測試。
2.1 寫入效能測試
(1) CTSDB單節點叢集與InfluxDB單機版寫入效能對比
橫座標：併發數（寫入執行緒數） ，縱座標：QPS（單位：萬次/s）
結論: CTSDB單節點寫入效能最高在19w，InfluxDB在15w。
(2) CTSDB單節點叢集與CTSDB雙節點叢集寫入效能對比
橫座標：併發數（寫入執行緒數） ，縱座標：QPS（單位：萬次/s）
結論：CTSDB單節點叢集寫入最高可達20w，雙節點叢集寫入效能34w。
2.2 查詢效能測試
(1) CTSDB單節點叢集與InfluxDB單機版查詢效能對比
橫座標：併發數（查詢執行緒數） ，縱座標：QPS（單位：次/s）
結論：
- CTSDB查詢效能整體比InfluxDB好很多，當併發數較高時（40），CTSDB查詢效能比InfluxDB高出近4倍，在2w左右。
- 在併發執行緒數達到50時，InfluxDB出現連結錯誤，拒絕查詢請求；此時，CTSDB可正常查詢。
(2) CTSDB單節點叢集與雙節點叢集查詢效能對比
橫座標：併發數（查詢執行緒數） ，縱座標：QPS（單位：次/s）
結論：在併發數較高的情況下，雙節點叢集查詢效能較單節點叢集有了大幅度提升，呈現了查詢效能線性擴充套件的趨勢。
關於我們
1. 我們的現狀
作為騰訊唯一的時序資料庫，CTSDB支撐了騰訊內部20多個核心業務（微信彩票、財付通、雲監控、雲資料庫、雲負載等）。其中，雲監控系統記錄了騰訊內部各種軟硬體系統的實時狀態，CTSDB承載了它所有的資料儲存，在每秒千萬級資料點的寫入壓力、每天20TB+資料量的寫入場景下穩定執行，足以證明CTSDB可以穩定支撐物聯網的海量資料場景。
2. 我們的未來
CTSDB已經在騰訊雲正式開始公測，為時序資料處理提供技術服務，我們將在降低儲存成本、提升易用性和豐富功能性等方面進一步優化CTSDB！
歡迎對時序資料庫和分散式儲存感興趣的同學加入我們！