DTCC 2019 | 阿里雲TSDB: 教你解鎖時序時空數據庫的種種黑科技

摘要：阿里雲TSDB是阿里自研的一種高性能，低成本，穩定可靠的在線時序時空數據庫產品。該產品統一了阿里巴巴集團90%以上的APM數據和事件型數據的存儲和計算，並在普遍應用於外部的物聯網，工業製造，電力，化工以及IT運維等行業。本文中，阿里雲智能數據庫產品事業部技術專家伊翼就爲你們介紹了阿里雲TSDB的種種黑科技。

專家簡介：伊翼（花名：老滾）。阿里雲智能數據庫產品事業部技術專家，主要從事TSDB核心引擎的研發工做。

直播回放

連接：https://yq.aliyun.com/live/1044

議題PPT下載，戳這裏！

https://yq.aliyun.com/download/3563

本次分享的內容主要包括如下四個方面：

1. 走進時序數據庫
2. 認識阿里雲TSDB
3. 阿里雲TSDB技術內幕
4. 將來與展望

1、走進時序數據庫

熟悉而又陌生的時序數據
時序數據庫自己是一個比較新的概念，直到5年前，DB-Engine纔將時序數據庫列爲一個獨立的分類。雖然時序數據庫的概念比較新，可是時序數據卻由來已久。從古至今，在咱們的平常生活中，時序數據從未缺席。古代記錄災害與祥瑞出現時間的縣誌也可以發揮相似今天時序數據庫的做用，幫助決策者指定相關的決策，地方官員能夠根據縣誌中的記錄判斷是否須要進行祭祀，也能夠決策是否須要向中央朝廷報告祥瑞以謀取升遷等，所以當時的縣誌也發揮了相似於OLAP的功能。但因爲理念和技術的限制，當時所記錄的時序數據信息是有限的，精度也是有限的。

技術發展到今天，時序數據所能記錄的信息和精度都有了極大的提高。以下圖所示的是杭州市空氣監測時序數據片斷。由此能夠看出，時序數據有一些共同的特徵，好比多樣的指標值、比較穩定的採集頻率以及任何一個數據點都有時間戳。在技術飛速發展的今天，時序數據的規模愈來愈大，增加速度也愈來愈快。所以，咱們須要面對一些問題，好比面對如此大規模的時序數據，應該將其存放在哪裏。

時序數據庫的概念

在十幾年前，時序數據只能選擇存放在關係型數據庫中，可是隨着通訊技術的發展，特別是互聯網技術的發展，時序數據的增加速度呈現指數級別，使用關係型數據庫來存儲時序數據顯然跟不上時代的節奏了，因此時序數據庫應運而生。時序數據庫就是一類專門爲處理時間序列數據而設計並優化的數據庫管理系統。

相較傳統的關係型數據庫，時序數據庫的特色以下：
 存儲的任何一條數據記錄都必然帶一個時間戳
 一般高頻訪問熱數據
 數據寫入頻率相對穩定，且遠大於數據讀取的頻率
 一般按照時間窗口查詢數據
 基本不提供單點數據的更新或刪除功能
 無需提供相似關係型數據庫事務級別的數據強一致性

目前，使用時序數據庫的行業應用愈來愈普遍。
 電力行業：智能電錶、電網、發電設備的集中監測
 交通行業：實時路況，路口流量監測，卡口數據的採集與分析
 石油石化：油井、運輸管線、運輸車隊的實時監測
 物流行業：車輛、集裝箱的追蹤監測
 環境監測：天氣、空氣、水文、地質環境等監測
 物聯網：電梯、鍋爐、機械、水錶、氣表等各類聯網設備的數據採集、分析與檢測
 軍工行業：軍事裝備的數據採集、存儲與分析
 製造業：生產過程管控，流程數據、供應鏈數據採集與分析
 互聯網：互聯網應用的PV/UV數據，基礎設施的性能監控

時序數據庫的迅猛發展

因爲時序數據庫的適用性很是普遍，所以其在DB-Engine上的受關注度一直處於增加態勢。面對這樣的關注度增加態勢，時序數據庫技術的發展也做出了積極的響應。不管是在開源領域仍是商用領域，都推出了大量的時序數據庫產品，好比InfluxDB、OpenTSDB、TimescaleDB以及阿里雲時序時空TSDB等。

2、認識阿里雲TSDB

阿里雲時序時空TSDB架構

以下圖所示的是阿里雲時序時空TSDB的總體架構，從左到右依次是採集端、TSDB服務端以及靠近最終用戶和開發者的實例端。在採集端，阿里雲時序時空TSDB採用了邊緣計算的解決方案，其能夠應用在資源受限或者網絡情況不穩定的場景下。採集端能夠和服務端進行打通，服務端能夠向邊緣下發各類各樣的規則，使得邊緣端可以直接進行數據清洗和計算，這就實現了「邊雲一體化」。圖中的中間部分是TSDB的服務端，它也分爲幾個組件，TS計算引擎主要負責預聚合、降精度以及持續查詢，TSQL引擎主要負責處理SQL查詢，此外還有一個基於已經訓練好的模型算法庫，提供各行業定製化解決方案的智能引擎。在這三個引擎下面就是TSDB的時序引擎。

接下來爲你們介紹阿里雲時序時空TSDB在功能層面的一些特性。

特性1：強力的數據模型支持

阿里雲TSDB支持多樣的數據模型，同時支持了多值模型和單值模型。舉例而言，溫度監控設備須要每間隔一段時間向數據庫上報溫度數據，其上報的數據中必然帶有一個時間戳以及溫度值，這樣最基礎的數據形式稱之爲單值模型。而若是上報的數據中不只僅包含了一個時間戳和室內溫度，還包含了室外溫度以及空氣溼度等，這樣的數據就能夠稱之爲多值模型。其實，時序數據庫對於多值模型的支持並非行業要求，所以即使是在開源領域，各類數據庫對於多值模型的支持也不一樣。支持多值模型的好處在於能夠提高數據的寫入效率，另一方面就是對於業務應用的開發者而言可使得設計更加直觀。

除了對於多值模型的支持以外，阿里雲TSDB還支持多種的數據類型，不只支持傳統數據類型，還可以支持字符串類型數據，而且可以支持精確到毫秒的時間戳。

特性2：降採樣&數據聚合

對於時序數據庫而言，降採樣和數據聚合也是很是重要的特性。依舊以溫度採集爲例，溫度採集設備可能上報數據的頻率很是高，好比每秒鐘上傳一次數據，可是在作數據查詢的時候並不須要按照原始的數據採集頻率進行分析和展現，所以就須要對於上報的數據進行降採樣操做，好比將按秒採樣的數據降採樣爲按小時或者按天進行分析和展現。

與之相對的，數據聚合在分析和展現中也很是重要。一般狀況下，有不少個數據採集設備，不一樣設備每隔一段時間上報數據的時候就認爲這些數據屬於不一樣的時間序列，而隨着設備的增多，必然使得時間序列變得很是多，而在作分析和查詢的時候並不須要對多個時間序列進行分析，只須要將其進行彙總，好比使用匯總後的平均值進行分析。這種狀況下就是對於一個數據的指標值按照時間維度將多個時間序列聚合成一條，這就是數據聚合。不管是降採樣仍是數據聚合，阿里雲TSDB都提供了很是豐富的聚合算子，有了這樣的能力，就能夠僅憑藉阿里雲原生能力來知足各類複雜的查詢分析場景。

特性3：SQL查詢能力

因爲時序數據庫自己屬於比較新的概念，爲了下降開發人員以及數據分析人員使用時序數據庫的門檻和學習成本，阿里雲TSDB也提供了基於SQL的查詢接口。有了SQL的查詢接口，用戶就能夠很是方便地使用SQL來操做時序模型。而阿里雲TSDB的SQL接口也基於時序場景進行了算法上的優化，能夠將SQL中的過濾、聚合等操做所有下推到TSDB的內核中，這樣就能夠最優化的方式來處理時序數據的分析和查詢。

特性4：內置對接Prometheus

在最新版的阿里雲TSDB中，已經實現了內置對接Prometheus的能力。Prometheus是一個很是適用於監控Kubernetes集羣的工具，可是其對於監控數據的存儲能力比較薄弱，雖然社區也考慮到這一點而且提供了Prometheus Adapter的第三方組件來將Prometheus的數據對接到各類各樣的數據源上，可是當數據鏈路中增長一個組件就意味着查詢性能的下降。爲了在阿里雲TSDB對接Prometheus的同時保持較高的查詢效率，TSDB內置了對接Prometheus的能力。通過測試，內置對接Prometheus的方式相對於經由Prometheus Adapter中轉方式的查詢性能要高不少。

特性5：邊緣計算能力

阿里雲TSDB的邊緣端計算能力處於行業內的領先地位。由於在物聯網應用和工業大數據的應用場景中，沒法保證數據的採集端是實時在線的，這樣的場景就是邊緣計算的用武之地。考慮到用戶數據的可用性，TSDB邊緣端再設計的時候也採用了高可用架構。當網絡情況恢復穩定的時候，邊緣段會將數據同步給阿里雲TSDB服務端，這樣能夠方便用戶在服務端進行統一的數據分析和查詢。

與其餘時序數據庫的功能對比

下圖中的表格列出了目前主流的時序數據庫在功能特性上的支持狀況對比。

接下來爲你們介紹幾個阿里雲TSDB實際的應用案例。

案例1: 某互聯網餐飲系統研發企業

該企業在本身的解決方案中將阿里雲TSDB整合了進去，利用阿里雲TSDB高性能寫入將整個鏈路中的全部時序數據以及業務指標所有寫入了TSDB中，藉助TSDB優越的查詢性能以及將監控系統整合在一塊兒，從而支持了對於整個解決方案中全部鏈路節點的實時監控，與此同時提升了系統的總體穩定性。

案例2:某直播平臺運維監控APM

該直播平臺原來的APM系統中將全部採集到的時序數據所有經過消息隊列存儲到OpenTSDB集羣中，可是很快就發現OpenTSDB的寫入存在瓶頸，並且OpenTSDB在時序索引方面天生存在薄弱點，所以在面向較爲複雜的查詢的時候，幾乎處於不可用的狀態。在通過比較以後，該直播平臺選擇使用阿里雲TSDB來替換全部的OpenTSDB，而且加大了寫入規模，從實際效果來看，阿里雲TSDB達到了所指望的效果。

案例3: 阿里巴巴集團內部全業務對接

最後的一個案例是阿里巴巴集團內部的案例。從上圖能夠看出，不管是底層的資源調控、總體監控仍是上層應用，阿里雲TSDB已經覆蓋了阿里集團內部的130餘個線上業務。而在2018年雙11大促期間，阿里雲TSDB承接的來自於阿里集團內部的各個業務的時序數據，寫入TPS峯值達到了4000萬TPS，查詢峯值達到了2萬QPS，累計時間線數量超過了100億。

3、阿里雲TSDB技術內幕

時序時空TSDB引擎的核心技術

阿里雲時序時空TSDB引擎具備不少的核心技術，在本次分享中主要爲你們介紹數據壓縮、時序索引以及聚合引擎三個方面的核心技術。

數據壓縮

時序數據的規模增加速度很快，而用戶每每出於往後須要進行查詢或者分析的考慮，但願所可以存儲的時序數據越多越好。可是一般狀況下，對於大規模時序數據的查詢而言，每每很是困難。一方面須要知足用戶對於查詢的需求，另一方面須要有效地下降用戶存儲的成本。針對於以上兩方面的訴求，阿里雲TSDB研發了一套數據壓縮技術。下圖中左側是一張示意圖，其每一行表明一個時間序列，其列表明數據點。在沒有進行數據壓縮的狀況下，若是想要將其數據調整到毫秒級別，就會發現其列數會增長到360萬，這樣的數據量是很是可觀的，因此必需要進行壓縮。阿里雲TSDB所採用的壓縮思路借鑑了Facebook Gorilla的實現思路，會將時間戳和數據兩塊壓縮成兩個大數據塊，對時間戳採用了delta-delta的壓縮方法，而對於不一樣的數據類型則採用了相應的數據壓縮算法。在壓縮成兩個大數據塊基礎之上，再對其進行通用的塊壓縮。通過兩部分的壓縮就使得數據壓縮比達到15:1的效果。

以下圖所示的是真實場景下的數據壓縮效果。原始狀況下數據大約6TB，一開始嘗試最普通的塊壓縮，將數據壓縮到了715G，但此時的數據壓縮比不到10:1，而採用先進行時序壓縮再追加一次塊壓縮後使得最終數據壓縮爲413G，壓縮比達到了15:1。那麼，追求如此之高的數據壓縮比有什麼好處呢？其實主要有兩個好處，第一個好處就是可以幫助用戶下降存儲成本；另一個好處就是由於數據壓縮比很大，所以當在進行大範圍的時序數據查詢的時候，IO效率會很是高，在這個例子中能夠將查詢延時下降約50%。

時序索引

TSDB的總體查詢流程很是簡單，當用戶指定了一個查詢條件，阿里雲TSDB首先會解析這個查詢條件，同時作必定程度的優化。接下來會作兩件事情，一件是將查詢條件扔給時序索引模塊，時序索引模塊會根據查詢條件計算命中的時間線數量以及相關信息，拿到時間線信息以後再將時間線集合扔給聚合索引，聚合索引再到底層存儲上面獲取相應的時間數據並進行降採樣、聚合等操做。雖然這一過程看上去比較簡單，可是卻存在不少值得研究的點。

以下圖所示的是時間線的生命週期，若是用戶想要查詢T2-T3時間範圍內的數據，確定不但願數據中包含T0-T2已經消亡或者說再也不有新的數據進來的時間線，因此這部分也是時序索引能夠進一步研究的地方。

對於時序索引而言，還須要支持模糊查詢，所謂模糊查詢就是給出的並非一個完整的時間序列定義，而多是Tag的全量匹配，或者基於Tag或者Tag Value的模糊查詢，須要可以找到相應的時間線，此時就須要基於Tag Key或者Tag Value作一個倒排索引。在時間序列生命週期的啓發下，在倒排索引技術基礎之上，TSDB增長了時間序列生命週期的倒排索引。同時加上對於生命週期的進一步過濾，最終獲得相對較少的時間線。將這些相對較少的時間線扔給下一層進行計算的時候就會帶來一個好處就是減小了IO，提供了極致的查詢性能。除了上述優化工做以外，TSDB還將整個倒排索引持久化到存儲層，這使得索引節點能夠處於無狀態的結構，而且使得水平擴展變得很是容易，對於時間線數據實現TTL。

在時序索引模塊中還實現了一個評估器， 評估器會以本身認爲的最合適的方式計算時間線，由於當查詢條件很是複雜的時候，計算時間線的方式有不少種，就比如在關係型數據庫中作Join也有不少種方法。評估器會根據幾個相應的來源作評估，分別是HHL技術器、BloomFilter以及時序索引緩存。HHL計數器所記錄的就是倒排索引中命中的時間線數量，BloomFilter記錄的是時間線是否還真實存在的狀況，這兩部分數據並非很是精確的，它們是在過去寫入查詢的過程當中所獲得的粗略統計數據。可是當時間線自己出現量級差別的時候，這樣的評估就會變得很是有意義，其可以以最優化的代價來獲取時間線。所以，評估器的做用就相似於關係型數據庫中的CBO (Cost-based Optimizer)。

聚合引擎

時序索引的下個模塊就是聚合引擎，時序索引將查詢條件所命中的時間線集合獲取以後交給聚合索引。而聚合索引就是按照傳統關係型數據庫的執行器的火山模型模型進行設計的，咱們爲其設計了不少的聚合算子和插值算子，這些算子都是以Pipeline方式進行一輪輪迭代的。目前，一共實現了10多個核心聚合算子，20多個填充策略以及10多個插值算法，而且這些算子的數量還在不斷地增長中。

藉助聚合引擎，能夠減小內存開銷以及對於底層存儲的查詢壓力，這是由於有了算子的支持以後，只須要每次抓取少批量數據進行計算便可。此外，聚合引擎和預聚合、降採樣也進行了無縫對接，當數據寫入的時候已經實施了採樣過程，在實際查詢的時候就能夠很容易地實現採樣，聚合引擎就不會從存儲層撈取原始數據，而是直接撈取預降採樣數據，從而進行進一步的數據計算，這就減小了底層存儲的IO操做。

4、將來與展望

最後爲你們介紹一下，阿里雲數據庫技術團隊目前在時序時空領域所作的工做和嘗試。

阿里雲TSDB自研引擎的將來像

阿里雲TSDB自研引擎的將來四個發展方向主要包含四點：

1. 冷熱數據異構存儲；對於用戶而言，每每但願將時序數據所有保存下來，所以須要考慮寫入、存儲以及查詢成本等。而對於時序數據而言，用戶每每對於熱數據更感興趣，所以可能須要考慮冷熱數據異構存儲。目前，TSDB正在嘗試與阿里雲OSS存儲解決方案進行打通。
2. Serverless讀寫能力；但願可以賦予阿里雲TSDB以Serverless讀寫能力，擁有該項能力就能夠進一步下降存儲和計算成本。
3. 擁抱時序生態；將來，TSDB還將更加緊密地擁抱時序生態。TSDB目前已經對接了Prometheus的生態，而在將來會進一步對接更多開源生態，但願可以經過與生態的對接使得阿里雲TSDB中一些比較有意義的特性可以發揮更大的價值。
4. 時序智能分析；阿里雲TSDB也但願可以在時序智能方面訓練更多的模型，而且深刻到各個具體的行業中，爲行業解決特定的問題。

時序時空領域的新嘗試

阿里數據庫團隊除了在自研時序數據庫方面作了大量的工做以外，還在其餘方面進行大量的嘗試。好比開源版時序數據庫InfluxDB的雲端產品化——TSDB for InfluxDB，其瞄準的痛點就是若是用戶使用開源版本的自建InfluxDB時，會感受到內存管理不穩定，在進行一些稍微複雜的查詢時就會觸發OOM。TSDB for InfluxDB會優化和重構InfluxDB的內存管理模塊，提升穩定性。 

TSDB for InfluxDB

由於時序數據庫在整個業界而言都是比較新的技術，能夠想象若是使用自建的InfluxDB，運維成本就會很是高，而若是使用了TSDB for InfluxDB的基於阿里雲服務，運維成本就會極大地下降，除了可以獲得99.9%的SLA承諾，並可以獲得InfluxDB專家的在線技術支持。雖然阿里雲對於InfluxDB作了改動和產品化，可是不影響二者生態的兼容。TSDB for InfluxDB能夠無縫地對接到用戶的Telegraf、Chronograf以及Kapacitor工具鏈中。TSDB for InfluxDB在上月月底正式上線進行公測，公測期間無償使用，所以你們若是感興趣能夠嘗試，而且也提供了數據的零感知遷移工具，可以幫助用戶一鍵式實現數據遷移。

TSDB for Spatial Temporal

阿里雲數據庫團隊還在作的另一項嘗試就是TSDB for Spatial Temporal，其屬於存儲時空數據的數據庫。TSDB for Spatial Tempora爲基於時空數據構建大規模應用提供了兩大利器——自研的S3時空索引和高性能電子圍欄。S3 時空索引實現千萬級時空數據的秒級查詢能力，助力用戶實現時空數據的低延遲查詢分析，知足實時交互查詢及實時數據分析場景。並且TSDB for Spatial Temporal還可以支持海量圍欄，同時檢測大規模移動目標。

---

本文做者：七幕

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。