日吞吐萬億，騰訊雲時序數據庫CTSDB解密

1、背景

隨着移動互聯網、物聯網、大數據等行業的高速發展，數據在持續的以指數級的速度增加，好比咱們使用手機訪問互網絡時的行爲數據，各類可穿戴設備上報的狀態數據，工廠中設備傳感器採集的指標數據，傳統互聯網公司的監控數據等。實際上，這些按照時間順序記錄系統、設備狀態變化的數據都是時序數據（Time Series），它廣泛存在於互聯網、物聯網、IT基礎設施中。

得益於軟硬件技術的快速發展，處理如此龐大的時序數據集的成本在持續下降，更多公司開始持續收集、分析數據，用於異常處理、趨勢預測、精準營銷、風險控制等場景，但願利用數據的潛在價值，提升公司盈利能力和競爭力。這裏舉兩個例子：

1.下圖爲某共享單車在舊金山某熱門區域的車輛借還狀況。經過分析該區域車輛的歷史借還數據，單車公司可優化熱點時間段的車輛補給。

2. 下圖爲某互聯網服務的出入流量歷史記錄。從圖中能夠明顯看到入流量（藍色線）在某時間段有毛刺，服務提供商可基於此段時間排查服務有無異常。能夠進一步基於流量監控作告警，使運維人員可以及時處理線上問題。

2、傳統時序數據解決方案存在大量問題

傳統的時序數據解決方案及問題以下：

1. MySQL等關係型數據庫：

• 寫入吞吐低：單機寫入吞吐低，很難知足時序數據千萬級的寫入壓力；
• 存儲成本大：對於時序數據壓縮不佳，需佔用大量機器資源；
• 維護成本高：單機系統，須要在上層人工的分庫分表，維護成本高；
• 查詢性能差：適用於交易處理，海量數據的聚合分析性能差。

2. Hadoop、Spark等批處理系統

• 數據延遲高：離線批處理系統，數據從產生到可分析，耗時數小時、甚至天級；
• 查詢性能差：不能很好的利用索引，依賴批處理任務，查詢耗時通常在分鐘級以上。

3. HBase

• 多維分析能力差：HBase能夠較好的知足寫入壓力，但對於非RowKey前綴的查詢性能較差；
• 維護成本：使用HBase須要同時維護HBase和Hadoop等系統，且HBase的穩定性會進一步加大維護成本。

3、寫入、存儲、查詢多環節優化，時序數據庫優點明顯

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的權限管理；
• 沒有針對時間序列的多維度對比分析工具。

4、歷經每日萬億寫入吞吐，騰訊雲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！

歡迎對時序數據庫和分佈式存儲感興趣的同窗加入咱們！