摘要：阿里雲TSDB是阿里自研的一種高性能，低成本，穩定可靠的在線時序時空數據庫產品。該產品統一了阿里巴巴集團90%以上的APM數據和事件型數據的存儲和計算，並在廣泛應用於外部的物聯網，工業製造，電力，化工以及IT運維等行業。本文中，阿里雲智能數據庫產品事業部技術專家伊翼就爲大家介紹了阿里雲TSDB的種種黑科技。
專家簡介：伊翼（花名：老滾）。阿里雲智能數據庫產品事業部技術專家，主要從事TSDB核心引擎的研發工作。
直播回放
鏈接：https://yq.aliyun.com/live/1044
議題PPT下載，戳這裏！
https://yq.aliyun.com/download/3563
本次分享的內容主要包括以下四個方面：
- 走進時序數據庫
- 認識阿里雲TSDB
- 阿里雲TSDB技術內幕
- 未來與展望
一、走進時序數據庫
熟悉而又陌生的時序數據
時序數據庫本身是一個比較新的概念，直到5年前，DB-Engine纔將時序數據庫列爲一個獨立的分類。雖然時序數據庫的概念比較新，但是時序數據卻由來已久。從古至今，在我們的日常生活中，時序數據從未缺席。古代記錄災害與祥瑞出現時間的縣誌也能夠發揮類似今天時序數據庫的作用，幫助決策者指定相關的決策，地方官員可以根據縣誌中的記錄判斷是否需要進行祭祀，也可以決策是否需要向中央朝廷報告祥瑞以謀取升遷等，因此當時的縣誌也發揮了類似於OLAP的功能。但由於理念和技術的限制，當時所記錄的時序數據信息是有限的，精度也是有限的。
技術發展到今天，時序數據所能記錄的信息和精度都有了極大的提升。如下圖所示的是杭州市空氣監測時序數據片段。由此可以看出，時序數據有一些共同的特徵，比如多樣的指標值、比較穩定的採集頻率以及任何一個數據點都有時間戳。在技術飛速發展的今天，時序數據的規模越來越大，增長速度也越來越快。因此，我們需要面對一些問題，比如面對如此大規模的時序數據，應該將其存放在哪裏。
時序數據庫的概念
在十幾年前，時序數據只能選擇存放在關係型數據庫中，但是隨着通信技術的發展，特別是互聯網技術的發展，時序數據的增長速度呈現指數級別，使用關係型數據庫來存儲時序數據顯然跟不上時代的節奏了，所以時序數據庫應運而生。時序數據庫就是一類專門爲處理時間序列數據而設計並優化的數據庫管理系統。
相較傳統的關係型數據庫，時序數據庫的特點如下：
存儲的任何一條數據記錄都必然帶一個時間戳
通常高頻訪問熱數據
數據寫入頻率相對穩定，且遠大於數據讀取的頻率
通常按照時間窗口查詢數據
基本不提供單點數據的更新或刪除功能
無需提供類似關係型數據庫事務級別的數據強一致性
目前，使用時序數據庫的行業應用越來越廣泛。
電力行業：智能電錶、電網、發電設備的集中監測
交通行業：實時路況，路口流量監測，卡口數據的採集與分析
石油石化：油井、運輸管線、運輸車隊的實時監測
物流行業：車輛、集裝箱的追蹤監測
環境監測：天氣、空氣、水文、地質環境等監測
物聯網：電梯、鍋爐、機械、水錶、氣表等各種聯網設備的數據採集、分析與檢測
軍工行業：軍事裝備的數據採集、存儲與分析
製造業：生產過程管控，流程數據、供應鏈數據採集與分析
互聯網：互聯網應用的PV/UV數據，基礎設施的性能監控
時序數據庫的迅猛發展
由於時序數據庫的適用性非常廣泛，因此其在DB-Engine上的受關注度一直處於增長態勢。面對這樣的關注度增長態勢，時序數據庫技術的發展也作出了積極的響應。無論是在開源領域還是商用領域，都推出了大量的時序數據庫產品，比如InfluxDB、OpenTSDB、TimescaleDB以及阿里雲時序時空TSDB等。
二、認識阿里雲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億。
三、阿里雲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操作。
四、未來與展望
最後爲大家介紹一下，阿里雲數據庫技術團隊目前在時序時空領域所做的工作和嘗試。
阿里雲TSDB自研引擎的未來像
阿里雲TSDB自研引擎的未來四個發展方向主要包含四點：
- 冷熱數據異構存儲；對於用戶而言，往往希望將時序數據全部保存下來，因此需要考慮寫入、存儲以及查詢成本等。而對於時序數據而言，用戶往往對於熱數據更感興趣，因此可能需要考慮冷熱數據異構存儲。目前，TSDB正在嘗試與阿里雲OSS存儲解決方案進行打通。
- Serverless讀寫能力；希望能夠賦予阿里雲TSDB以Serverless讀寫能力，擁有該項能力就可以進一步降低存儲和計算成本。
- 擁抱時序生態；未來，TSDB還將更加緊密地擁抱時序生態。TSDB目前已經對接了Prometheus的生態，而在未來會進一步對接更多開源生態，希望能夠通過與生態的對接使得阿里雲TSDB中一些比較有意義的特性能夠發揮更大的價值。
- 時序智能分析；阿里雲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還能夠支持海量圍欄，同時檢測大規模移動目標。
本文作者：七幕
本文爲雲棲社區原創內容，未經允許不得轉載。