作者：張觀石，虎牙直播業務運維負責人，《運維前線》聯合作者，擁有多年網際網路業務運維經驗。
原文來自微信公眾號：DBAplus社群

為什麼會講時序資料庫呢？各位DBA可能主要關注關係型資料和各種NoSQL，而時序資料庫最近有一種興起趨勢，所以特地拿來講一講。

一、時序資料庫簡介

時序資料庫是一種為了處理時間序列資料而特別優化的資料庫。它以時間系列為關鍵索引，特別適合於連續時間分片的資料儲存和檢索。主要用於處理帶時間標籤（按照時間的順序變化，即時間序列化）的資料。

在傳統行業，如電力行業、化工行業、物聯網等各型別實時監測、檢查與分析裝置所採集、產生的資料，都是時間序列資料，這些工業資料的典型特點是：產生頻率快（每一個監測點一秒鐘內可產生多條資料）、嚴重依賴於採集時間（每一條資料均要求對應唯一的時間）、監測點多資訊量大（常規的實時監測系統均有成千上萬的監測點，監測點每秒鐘都產生資料，每天產生大量資料）。

目前很多企業對於時序大資料的儲存和處理往往採用關係型資料庫的方式進行處理，但由於關係型資料庫天生的劣勢導致其無法進行高效的儲存和資料的查詢。時序資料庫通過使用特殊的儲存方式，使得時序大資料可以高效儲存和快速處理海量時序資料，是解決海量資料處理的一項重要技術。該技術採用特殊資料儲存方式，極大提高了時間相關資料的處理能力，相對於關係型資料庫它的儲存空間減半，查詢速度極大的提高。特別在網際網路行業的運維監控，業務監控中使用。

• 時間序列

我們常說的時間戳，timestamp，unix_time 是一個時間點，而無數個時間點連線起來就是所謂的時間系列，簡稱時序。

• 時序資料

帶維度標籤、以時間點或時間範圍為索引的資料也稱為時序資料。理解為某一度量指標在某一時間點的一個值。

• 時序資料結構

從以上幾點可以瞭解時序資料應該包括幾個方面：度量指標、標籤、值、時間點。

舉個例子，度量指標資料：

Usercount platform=dbaplus speaker=zhangguanshi 1497344217 value=500

這裡分成幾個部分：

• Metric：usercount
• Timestamp：1497344217
• Value：500
• Tags：platform=dbaplus，speaker=zhangguanshi

各部分解釋：

• Metric：監控項/指標度量，如同時線上使用者usercount。
• Tags：標籤/維度，在OpenTSDB裡面，Tags由tagk和tagv組成，即tagk=tagv。標籤是描述Metric的屬性，分享主題的講師，tags可為speaker=zhangguanshi。
• Value：一個Value表示一個metric的實際數值，譬如上面的500
• Timestamp：即時間戳，用來描述產生時序資料的時間點，上面的1497344217
• Data Point：即某個Metric在某個時間點的數值。
  1）Data Point包括以下部分：Metric、Tags、Value、Timestamp
  2）上面描述的本場分享在21:09時候的同時線上使用者，就是1個DataPoint

資料特點：

• 基本上都是插入，沒有更新的需求；
• 資料基本上都有時間屬性，隨著時間的推移不斷產生新的資料，舊的資料不需要儲存太久；
• 業務方對時序資料通常有幾個查詢需求；
• 獲取最新狀態，查詢最近的資料（例如感測器最新的狀態）；
• 展示區間統計，指定時間範圍，查詢統計資訊，例如平均值，最大值，最小值，計數等；
• 獲取異常資料，根據指定條件，篩選異常資料。

跟普通資料的區別1：

• 時序資料庫就是存放時序資料的資料庫；
• 而時間序列是無窮的，不斷遞增的，而指標也可以成千上萬，為海量資料而設計的；
• 時序資料是特別為順序寫入；
• 時間是資料庫插入查詢的核心條件，以時間為連續條件。

跟傳統資料庫的區別2：

• 時序資料庫簡單，沒有複雜模式/正規化設計。某一度量指標在某一時間點只會有一個值；
• 沒有事務；
• 寫多讀少無更新；
• 順序讀、區間範圍讀；
• 基數大。

時序資料庫要解決的問題：

• 以時間點為順序產生的資料；
• 資料量大，資料來源多；
• 資料的維度多，不同指標有不同維度；
• 統計查詢複雜，如任意時間訪問，多粒度的檢索；
• 需要快速響應查詢；
• 對中小團隊收益特別大。

二、業界使用時序資料庫情況

• 簡介

在《解密Google SRE》一書中作者提到了Google的監控系統borgmon 和 prometheus非常像。prometheus是一款開源的時序資料庫，可以想見Google也是用的類似時序資料庫進行監控。Fackbook開源了時序資料庫引擎Beringei。他們內部也用的這個做監控。阿里巴巴的Goldeye黃金眼，也是一款時序資料庫；百度雲產品TSDB，主要用於物聯網相關的監控；國內非常火的監控系統Open-falcon也是一款開源時序資料庫。當然還有知名的開源軟體：Graphihe、OpenTSDB、InfluxDB、Druid、TimeScaleDB等。

我們看下DB-Engine網站對時序資料庫的排行。

出處：https://db-engines.com/en/ranking/time+series+dbms
參考資料：http://liubin.org/blog/2016/02/25/tsdb-list-part-1/

這裡以OpenTSDB為例重點介紹下時序資料庫的一些技術。

• 介紹Opentsdb及相關元件

• Tsd和儲存層

OpenTSDB的核心，本身比較簡單，是Java實現的一套程式。用來讀寫底層儲存及資料處理。

儲存：

OpenTSDB底層儲存使用的HBase，自然ZooKeeper、HBase、Hadoop HDFS是少不了的。其架構分散式、高可用也是由HBase實現。

Rowkey的設計是亮點：

Rowkey: metric + timestamp + tagk1 + tagv1… + tagkN + tagvN
HBase(main):003:0> scan ‘tsdb’
ROW COLUMN+CELL
\x00\x00\x01U\x9C\xAEP\x00\x column=t:q\x80, timestamp=1497344217, value=\x17 00\x01\x00\x00\x01\x00\x00\x 02\x00\x00\x02

說OpenTSDB沒有設計模式是指上層上報來的資料，在底層OpenTSDB還是有儲存表的，在往HBase中寫入和查詢使用了一套自定義的資料結構，OpenTSDB的儲存格式是在HBase儲存了幾個表：

• Data Table：表名預設叫tsdb ，儲存時序資料的表。
• UID Table：表名tsdb-uid，UID對映表，時序資料儲存時不用實際的字串，而是經過此表對映之後，取得一個UID，儲存在data table中的其實是整個uid。
• Meta Table：元資料表，時間序列資料的索引表。
• Tree Table ：樹表，也是儲存元資料用的。
• Rollup 表：儲存rollup 和 pre-aggregation的資料。

• WebUI

OpenTSDB有多個展示端，Grafana是其中一個支援得較好的。前面文章也講到了Grafana，這裡不多講。

• 採集層

採集支援udp協議、http協議、telnet。可使用多種採集上報方式，包括指令碼、應用內上報等。

儲存資料最簡單的方式是：

$ telnet localhost 4242
put sys.cpu.user 1497344217 23 host=web01 user=mirzhang

• 告警層

官方推薦是bosun，一套強大的開源告警軟體。

• 外掛

開發了新外掛，如支援內部uid到主播的對映。

三、虎牙直播業務監控實踐

• 背景

大家可能都知道直播是眾多網際網路行業中技術比較複雜的技術，視訊從主播端採集到推流節點，到轉推環節，到分發網路，到觀眾端，這麼複雜的鏈路中要保障音視訊直播的流暢是很有挑戰的。

視訊質量指標很多：

• 感官卡頓比
• 網路卡頓比
• 錯誤率
• 慢速比
• 視訊載入成功率
• 播放時延
• 卡比例
• 視訊載入時間
• 連線時間
• RTT

微服務的質量指標：
虎牙直播後端是微服務架構，我們把數千個微服務的成功率，呼叫次數、延時等資訊都通過時序資料庫來監控。

同時線上使用者規模大
維度多：分端、分地區、分主播、分線路

所以部分使用者說卡的時候，要分析N多種情況。

• 基本架構

整套系統包括採集、儲存分析、輸出等幾個部分，採集端使用了多種採集手段和方法。

在系統的使用層包括賬號、安全這些通用措施，也包括TSDB資料層，儲存層，及前端展示UI層。

輸出是利用時序資料庫中的資料實現運維需求。

• 技術架構

我們採集了所有能採集到的質量相關資料，其中包括主播、觀眾、中間各個環節。採集資料規模非常的大，要實時採集，儘可能實時展示，所以全部都直接讀寫TSDB是不行的，我們通過流式計算的環節進行預處理，這一層是微服務架構，可以很容易擴充套件。原始資料可能是各種複雜格式的，通過預處理也可以達到過濾、聚合、預計算的目的，可以按業務的需求進行靈活處理。

我們微服務的質量資料，包括成功率、呼叫延時資料原來是通過MySQL儲存，通過開發web後臺來展示，後來改造為通過時序資料庫來儲存展示。

• 監控告警

Bosun 是一個新型的監控和告警系統，由Stack Exchange團隊打造，使用Golang編寫，支援定義複雜的告警規則，支援OpenTSDB、Graphite、Logstash-Elasticsearch 等資料來源。bosun 將是Zabbix、Nagios的有力競爭者。

bosun從TSDB讀取時序資料，可以經由bosun表示式做一系列的計算，根據告警策略傳送告警，告警的內容是定義好的bosun模板。

這些質量監控告警不斷持續反饋給各相關人員、廠商。實時告警打通各渠道：微信、QQ、釘釘、YY、郵件等。

• 時序資料的其它用途

我們還通過TSDB API從時序資料庫獲取資料，定製各種定期報告如日報、週報等。

質量資料效果圖：