騰訊技術工程 | 騰訊唯一時序數據庫：CTSDB解密

背景：隨著互聯網的高速發展、大數據的迅速膨脹和物聯網的飛速崛起，我們發現生活和工作中的大部分數據漸漸和時間產生了關聯。比如微信運動的實時步數、股票每天的收盤價格、共享單車的設備狀態等等。為了存儲這些與時間相關的數據，積極擁抱物聯網時代，各大企業紛紛推出自家的時序數據庫。本文將對時序數據庫的基本概念、應用場景及騰訊時序數據庫CTSDB做簡要介紹。

1. 時序數據

1.1 什么是時序數據？

在引入時序數據庫之前，先要了解“時序數據”的概念：按照時間順序記錄系統、設備狀態變化的數據被稱為時序數據（TimeSeries Data）。它普遍存在于IT基礎設施、運維監控系統和物聯網中。

時序數據從時間維度上將孤立的觀測值連成一條線，從而揭示軟硬件系統的狀態變化。孤立的觀測值不能叫時序數據，但如果把大量的觀測值用時間線串起來，我們就可以研究和分析觀測值的趨勢及規律。其意義體現在兩方面：

（1）從時間軸往后看，時序數據可做成報表，觀測數據變化規律、捕獲異常。這里舉兩個例子：
下圖為共享單車在舊金山某熱門區域的每小時車輛的借還數量。通過分析該區域車輛數目的歷史數據，單車公司可得知熱點借車時間段是否需要車輛補給。

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

（2）從時間軸向前看，時序數據可以建立數學模型、做統計分析，預測事物發展趨勢。
舉例，下圖為聯合國在2015年分析過往人口增長趨勢后，發布的人口數字及預測報告。從圖中可以看出未來非洲人口將持續增長，這是任何一個跨國企業都不該忽略的市場，也預示著當地政府面臨重大挑戰。

1.2 時序數據的數學模型

上面介紹了時序數據的基本概念，也說明了分析時序數據的意義。那么時序數據該怎樣存儲呢？數據的存儲要考慮其數學模型和特點，時序數據當然也不例外。所以這里先介紹時序數據的數學模型和特點。

下圖為一段時序數據，記錄了一段時間內的某個集群里各機器上各端口的出入流量，每半小時記錄一個觀測值。這里以圖中的數據為例，介紹下時序數據的數學模型（不同的時序數據庫中，基本概念的稱謂有可能不同，這里以騰訊CTSDB為準）：

• metric： 度量的數據集，類似于關系型數據庫中的 table；

• point： 一個數據點，類似于關系型數據庫中的 row；

• timestamp： 時間戳，表征采集到數據的時間點；

• tag： 維度列，代表數據的歸屬、屬性，表明是哪個設備/模塊產生的，一般不隨著時間變化，供查詢使用；

• field： 指標列，代表數據的測量值，隨時間平滑波動，不需要查詢。

如上圖所示，這組數據的metric為Network，每個point由以下部分組成：

• timestamp：時間戳

• 兩個tag：host、port，代表每個point歸屬于哪臺機器的哪個端口

• 兩個field：bytes_in、bytes_out，代表piont的測量值，半小時內出入流量的平均值

同一個host、同一個port，每半小時產生一個point，隨著時間的增長，field（bytes_in、bytes_out）不斷變化。如host：host4，port：51514，timestamp從02:00 到02:30的時間段內，bytes_in 從 37.937上漲到38.089，bytes_out從2897.26上漲到3009.86，說明這一段時間內該端口服務壓力升高。

1.3 時序數據特點

• 數據模式： 時序數據隨時間增長，相同維度重復取值，指標平滑變化：這點從上面的Network表的數據變化可以看出。

• 寫入： 持續高并發寫入，無更新操作：時序數據庫面對的往往是百萬甚至千萬數量級終端設備的實時數據寫入（如摩拜單車2017年全國車輛數為千萬級），但數據大多表征設備狀態，寫入后不會更新。

• 查詢： 按不同維度對指標進行統計分析，且存在明顯的冷熱數據，一般只會頻繁查詢近期數據。

2. 時序數據庫

有了時序數據后，該存儲在哪里呢？首先我們看下傳統的解決方案在存儲時序數據時會遇到什么問題。

2.1 傳統解決方案

時序數據往往是由百萬級甚至千萬級終端設備產生的，寫入并發量比較高，屬于海量數據場景。傳統的時序數據解決方案主要有兩種：關系型數據庫（MySQL）、Hadoop生態。

·        MySQL：在海量的時序數據場景下存在如下問題

• 存儲成本大：對于時序數據壓縮不佳，需占用大量機器資源；

• 維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；

• 寫入吞吐低：單機寫入吞吐低，很難滿足時序數據千萬級的寫入壓力；

• 查詢性能差：適用于交易處理，海量數據的聚合分析性能差。

·        Hadoop生態（Hadoop、Spark等）

• 數據延遲高：離線批處理系統，數據從產生到可分析，耗時數小時、甚至天級；

• 查詢性能差：不能很好的利用索引，依賴MapReduce任務，查詢耗時一般在分鐘級。

2.2 時序數據庫

時序數據庫是管理時序數據的專業化數據庫，并針對時序數據的特點對寫入、存儲、查詢等流程進行了優化，這些優化與時序數據的特點息息相關：

1) 存儲成本：

利用時間遞增、維度重復、指標平滑變化的特性，合理選擇編碼壓縮算法，提高數據壓縮比；

通過預降精度，對歷史數據做聚合，節省存儲空間。

2)  高并發寫入：

批量寫入數據，降低網絡開銷；

數據先寫入內存，再周期性的dump為不可變的文件存儲。

3)  低查詢延時，高查詢并發：

優化常見的查詢模式，通過索引等技術降低查詢延時；

通過緩存、routing等技術提高查詢并發。

2.3 開源時序數據庫對比

目前行業內比較流行的開源時序數據庫產品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其產品特性對比如下圖所示：

從上表可以看出，開源的時序數據庫存在如下問題：

• 沒有free、易用的分布式版本（OpenTSDB支持分布式部署，但依賴系統過多，維護成本高）；

• 聚合能力普遍較弱，而時序數據大多需要來做統計分析；

• 沒有free的權限管理；

• 沒有針對時間序列的多維度對比分析工具。

騰訊CTSDB（Cloud Time Series Database）是一種分布式、高性能、多分片、自均衡的時序數據庫，針對時序數據的高并發寫入、存在明顯的冷熱數據、IoT用戶場景等做了大量優化，同時也支持各行業的日志解析和存儲，其架構如下圖所示。

1. CTSDB主要特點

1)  高性能：（具體性能數據將在后文給出）

支持批量寫入、高并發查詢；

通過集群擴展，隨時線性提升系統性能；

支持sharding、routing，加速查詢。

2)  高可靠：

支持多副本；

機架感知，自動錯開機架分配主從副本。

3)  易使用：

豐富的數據類型，REST接口，數據寫入查詢均使用json格式；

原生分布式，彈性可伸縮，數據自動均衡；

4)  低成本：

支持列存儲，高壓縮比（0.1左右），降低存儲成本；

支持數據預降精度：降低存儲成本的同時，提高查詢性能。

副本數可按需調整。

5)  強大的聚合能力：

max,min,avg,percentile,sum,count,group by等常用聚合；

復雜的腳本聚合（例如可對多字段間的計算結果做聚合）；

時間區間聚合、GEO聚合、嵌套聚合。

6)  亮點能力:

數據監控告警：對存入數據進行數據量、字段統計、基線對比等監控，通過微信、短信、郵件告警；

權限系統：支持用戶名密碼、機器白名單的權限系統；

數據時效性：支持數據過期刪除；

數據導出。

2. 競品性能對比測試

這里選用業界較為流行的InfluxDB來與CTSDB做性能對比測試。

2.1 測試場景

CTSDB與InfluxDB對比測試：CTSDB與InfluxDB均單節點部署，單節點占用24個cpu核心，128g內存，萬兆網卡,，磁盤SSD RAID0。

CTSDB單節點集群與雙節點集群對比測試：用以驗證CTSDB的線性擴展能力。

2.2 寫入性能測試

數據樣例：

導入的數據由InfluxDB的官方測試工具產生，https://github.com/influxdata/influxdb-comparisons。

數據為若干host的時序數據，每個point包含10個tag（均為string類型），10個filed（均為float類型），timestamp為時間戳（一個host每10秒一個點）。

樣例如下所示：

測試結果：
(1) CTSDB單節點集群與InfluxDB單機版寫入性能對比

 橫坐標：并發數（寫入線程數），縱坐標：QPS（單位：萬次/s）

結論:CTSDB單節點寫入性能最高在19w，InfluxDB在15w。

(2) CTSDB單節點集群與CTSDB雙節點集群寫入性能對比

橫坐標：并發數（寫入線程數），縱坐標：QPS（單位：萬次/s）

結論:CTSDB單節點集群寫入最高可達20w，雙節點集群寫入性能34w。

2.3 查詢性能測試

查詢樣例：

這里以CTSDB的查詢語句為例：

查詢語句解讀：
取出1個host的全量數據，然后任取一個小時做過濾后，按分鐘粒度分桶（groupby，最終結果有60個桶），最后輸出所有的桶，并計算桶內所有數據的usage_user字段最大值 。

注意這里的查詢使用了CTSDB的routing功能，用以加速查詢。

查詢結果樣例：

測試結果：

(1) CTSDB單節點集群與InfluxDB單機版查詢性能對比

橫坐標：并發數（查詢線程數），縱坐標：QPS（單位：次/s）

結論：CTSDB查詢性能整體比InfluxDB好很多，當并發數較高時（40），CTSDB查詢性能比InfluxDB高出近4倍，在2w左右。在并發線程數達到50時，InfluxDB出現鏈接錯誤，拒絕查詢請求；此時，CTSDB可正常查詢。

(2) CTSDB單節點集群與雙節點集群查詢性能對比

橫坐標：并發數（查詢線程數），縱坐標：QPS（單位：次/s）

結論：在并發數較高的情況下，雙節點集群查詢性能較單節點集群有了大幅度提升，呈現了查詢性能線性擴展的趨勢。

我們的現狀

作為騰訊唯一的時序數據庫，CTSDB支撐了騰訊內部20多個核心業務（微信×××、財付通、云監控、云數據庫、云負載等）。其中，云監控系統的記錄了騰訊內部各種軟硬件系統的實時狀態，CTSDB承載了它所有的數據存儲，在每秒千萬級數據點的寫入壓力、每天20TB+數據量的寫入場景下穩定運行，足以證明CTSDB可以穩定支撐物聯網的海量數據場景。

我們的未來

CTSDB即將在騰訊云正式上線，為物聯行業提供技術服務！我們將在降低存儲成本、提升易用性和豐富功能性等方面進一步優化CTSDB！歡迎對時序數據庫和分布式存儲感興趣的同學加入我們！