一喊废、時(shí)序業(yè)務(wù)全景
TSDB自2016年開始服役氮墨，到現(xiàn)在已經(jīng)三年了纺蛆，參與了三次阿里巴巴雙11大促。2016年是 TSDB 元年规揪，2017年開始在阿里巴巴內(nèi)部做大規(guī)模推廣桥氏。下圖展示了2017年和2018年大促狀態(tài)下TSDB吞吐表現(xiàn)。寫入的峰值從2017年的2000w TPS到2018年有了翻倍的增長猛铅，增長到了4000w TPS字支。查詢峰值從8000 QPS轉(zhuǎn)到了2w QPS。這些都是阿里巴巴核心業(yè)務(wù)的吞吐量情況奸忽，日均有800TB的時(shí)序數(shù)據(jù)堕伪，累計(jì)超過了數(shù)百億的時(shí)間線，覆蓋了集團(tuán)130+的業(yè)務(wù)栗菜。
時(shí)序業(yè)務(wù)覆蓋場景
時(shí)序業(yè)務(wù)覆蓋的場景從基礎(chǔ)設(shè)施到上層應(yīng)用欠雌，覆蓋各個(gè)主要系統(tǒng)層面「沓铮基礎(chǔ)設(shè)施層主要負(fù)責(zé)物理機(jī)器和操作系統(tǒng)的監(jiān)控富俄〗矗基礎(chǔ)運(yùn)維層包括Sunfire，云監(jiān)控和GOC蛙酪。Sunfire是阿里巴巴統(tǒng)一監(jiān)控和日志采集報(bào)警系統(tǒng)齐苛；云監(jiān)控是阿里云上統(tǒng)一的監(jiān)控系統(tǒng)；GOC是全球應(yīng)急調(diào)度指揮系統(tǒng)桂塞，包含報(bào)警數(shù)據(jù)凹蜂，故障定級數(shù)據(jù)等。資源調(diào)度層包含海量的容器阁危，包括現(xiàn)在在服役的集團(tuán)調(diào)度系統(tǒng)以及業(yè)界流行的Kubernetes玛痊。集群管理層面最突出的是DBPaaS業(yè)務(wù),DBPaaS承擔(dān)阿里巴巴所有數(shù)據(jù)庫實(shí)例的監(jiān)控和調(diào)度，每秒的吞吐量在千萬量級狂打。上層應(yīng)用包括IoT場景應(yīng)用如盒馬門店和菜鳥IoT擂煞；以及APM場景應(yīng)用如黃金眼和電商指標(biāo)監(jiān)控，還有安全部的核心鏈路監(jiān)控等趴乡。覆蓋的場景從DC到上層的SaaS对省。
對大數(shù)據(jù)以及人工智能概念都是模糊不清的，該按照什么線路去學(xué)習(xí)晾捏，學(xué)完往哪方面發(fā)展蒿涎，想深入了解，想學(xué)習(xí)的同學(xué)歡迎加入大數(shù)據(jù)學(xué)習(xí)qq群：458345782惦辛，有大量干貨（零基礎(chǔ)以及進(jìn)階的經(jīng)典實(shí)戰(zhàn)）分享給大家劳秋，并且有清華大學(xué)畢業(yè)的資深大數(shù)據(jù)講師給大家免費(fèi)授課，給大家分享目前國內(nèi)最完整的大數(shù)據(jù)高端實(shí)戰(zhàn)實(shí)用學(xué)習(xí)流程體系 胖齐。
面臨的挑戰(zhàn)
目前玻淑，時(shí)序數(shù)據(jù)庫所面臨的挑戰(zhàn)有很多，包括業(yè)務(wù)方提出的需求和挑戰(zhàn)呀伙。如淘寶魔兔這個(gè)無線端APM應(yīng)用补履，他和終端用戶的具體交互行為相關(guān)，會遇到高頻率区匠，低延遲查詢的挑戰(zhàn)干像。另外，大多數(shù)OLAP系統(tǒng)和分布式系統(tǒng)都會涉及的長時(shí)間驰弄，多維度海量數(shù)據(jù)聚合分析。還有時(shí)序數(shù)據(jù)庫特有的發(fā)散時(shí)間線速客，比如如何聚合大量時(shí)間線戚篙？以及雙11大促狀態(tài)下的極高流量沖擊苛蒲，對整個(gè)時(shí)序數(shù)據(jù)庫容量的挑戰(zhàn)是非常大的献酗。
二喘批、TSDB介紹
TSDB架構(gòu)
阿里巴巴內(nèi)部TSDB和在阿里云上售賣的TSDB是同一套架構(gòu)，只是在能力上有所不同令漂。下圖從左到右分別是采集端，云端（Server）TSDB硫朦，以及更靠近用戶的各種協(xié)議（可視化文黎，Grafana展示和時(shí)序洞察，時(shí)序洞察可以將時(shí)序數(shù)據(jù)導(dǎo)入進(jìn)來直接查看分析）痛倚。采集端實(shí)現(xiàn)了一套邊緣計(jì)算的方案规婆。邊緣計(jì)算主要應(yīng)用在IoT場景下、資源受限或不穩(wěn)定的環(huán)境下蝉稳；另外邊緣計(jì)算與云端TSDB打通抒蚜，云端TSDB可以直接下發(fā)規(guī)則，在邊緣做數(shù)據(jù)清洗和計(jì)算耘戚，最終實(shí)現(xiàn)邊云一體化嗡髓。
時(shí)序引擎整個(gè)架構(gòu)包含的內(nèi)容比較多，最核心的是底層TSDB核心的時(shí)序引擎收津，上層包括計(jì)算引擎饿这，TSQL引擎和智能分析引擎。底層TSDB核心的時(shí)序引擎包含幾個(gè)模塊撞秋，時(shí)序索引长捧，流式數(shù)據(jù)的聚合，存儲引擎和穩(wěn)定性管理部服。時(shí)序索引指的是關(guān)于時(shí)間線的查詢和過濾唆姐。流式數(shù)據(jù)的聚合指的是如何在內(nèi)存里做高效的海量數(shù)據(jù)的聚合分析。存儲引擎提供了時(shí)序數(shù)據(jù)海量數(shù)據(jù)存儲的解決方案廓八。穩(wěn)定性管理阿里巴巴最看重奉芦，即如何保證TSDB能夠長時(shí)間在集團(tuán)和云上安全穩(wěn)定的運(yùn)行。其中計(jì)算引擎是阿里自研的時(shí)序流計(jì)算引擎剧蹂，提供了預(yù)聚合声功，降精度（降采樣）持續(xù)查詢的能力，其中持續(xù)查詢在告警或復(fù)雜事件分析場景下用的比較多宠叼。TSQL引擎也是阿里自研的先巴，帶有分布式執(zhí)行器和優(yōu)化器。TSQL引擎能夠擴(kuò)充時(shí)序分析的能力冒冬，降低用戶使用的門檻伸蚯。智能引擎可以提供一些已訓(xùn)練好或生成好的模型算法庫，提供行業(yè)定制的解決方案简烤。
TSDB能力對比
動(dòng)態(tài)schema支持剂邮。NoSQL數(shù)據(jù)庫基本都支持tags寫入，但TimescaleDB基于傳統(tǒng)的關(guān)系數(shù)據(jù)庫 Postgres横侦，所以不支持動(dòng)態(tài)schema挥萌。
多值模型绰姻。多值模型在時(shí)序場景下能極大地提升寫入速度。在監(jiān)控一個(gè)風(fēng)力發(fā)電點(diǎn)的時(shí)候引瀑，它可能既有風(fēng)向又有風(fēng)速狂芋，一次性寫入兩個(gè)指標(biāo)要比單值模型下一次寫入一個(gè)指標(biāo)要好很多。另外多值模型對上層的SQL模型更友好憨栽，比如做select查詢時(shí)可以基于多個(gè)值做分析等帜矾。
時(shí)序索引。相對來說徒像，OpenTSDB基于HBase行過濾黍特，沒有時(shí)序索引。但TSDB锯蛀，InfluxDB等都構(gòu)建了時(shí)序索引灭衷，這樣做是為了優(yōu)化查詢的效率。
預(yù)聚合和降精度旁涤。Facebook Gorrila出來以后翔曲，時(shí)序壓縮開始越來越引起大家關(guān)注，針對時(shí)序數(shù)據(jù)的特點(diǎn)做一些壓縮劈愚，比如時(shí)間戳是連續(xù)的瞳遍，數(shù)據(jù)是穩(wěn)定的，采用 delta-of-delta 或者 xor 等方式進(jìn)行時(shí)序壓縮菌羽，最終壓縮的效率要比通用壓縮提高很多倍掠械。
SQL能力。SQL 接口能夠降低用戶使用 TSDB 的門檻注祖，可以讓熟悉 SQL 的用戶直接上手操作時(shí)序模型猾蒂；并且能通過 SQL 擴(kuò)充時(shí)序分析能力等。
集群能力是晨。InfluxDB在開源領(lǐng)域有一些高可用肚菠、集群的解決方案，但穩(wěn)定的高可用方案需要收費(fèi)的商業(yè)版本支持罩缴。TimescaleDB目前還在開發(fā)過程中蚊逢。OpenTSDB基于Hadoop生態(tài)，所以其可擴(kuò)展性沒有問題箫章。
TSDB給2018年雙11補(bǔ)充了哪些彈藥烙荷。首先在保證穩(wěn)定性的前提下，提供一套能夠滿足各個(gè)業(yè)務(wù)方的解決方案檬寂。滿足高頻率低延遲查詢奢讨、高性能聚合、海量數(shù)據(jù)低成本存儲焰薄、海量時(shí)間線管理的方案拿诸。另外，在功能模塊上優(yōu)化了時(shí)序索引塞茅，做了一個(gè)基于KV存儲的索引亩码，可以實(shí)現(xiàn)無限時(shí)間線的讀寫。以及參考 Facebook Gorilla做的分布式緩存存儲野瘦，滿足高頻率低延遲查詢描沟。最后是計(jì)算引擎。在技術(shù)方面鞭光，首先做的也是時(shí)序索引優(yōu)化吏廉，流式聚合引擎，預(yù)聚合和降精度惰许，工作負(fù)載管理席覆，以及自研的時(shí)序壓縮。
三汹买、核心技術(shù)
海量時(shí)序數(shù)據(jù)存儲
如何解決低成本存儲問題佩伤？下圖是雙11阿里內(nèi)部業(yè)務(wù)的具體使用場景。DBPaaS專注于阿里巴巴集團(tuán)內(nèi)部所有數(shù)據(jù)庫實(shí)例監(jiān)控和分析晦毙。其涉及的指標(biāo)包括底層所有機(jī)器生巡，容器，操作系統(tǒng)以及上層各種數(shù)據(jù)庫實(shí)例指標(biāo)见妒。所有指標(biāo)存在一套數(shù)據(jù)庫里面孤荣，可以做統(tǒng)一的查詢和分析，而且DBPaaS保存了歷年雙11數(shù)據(jù)庫表現(xiàn)性能的數(shù)據(jù)须揣，每一年雙11當(dāng)天的詳細(xì)數(shù)據(jù)都在一套數(shù)據(jù)庫里盐股。DBPaaS業(yè)務(wù)帶來的挑戰(zhàn)實(shí)際上是非常大的，首先因?yàn)镈BPaaS監(jiān)控的是所有數(shù)據(jù)庫實(shí)例返敬，這些實(shí)時(shí)監(jiān)控指標(biāo)要納入雙11光明頂大屏遂庄，也就是阿里巴巴核心作戰(zhàn)指揮室大屏，如何保證準(zhǔn)確劲赠、及時(shí)涛目、穩(wěn)定的大屏展示就給 TSDB 帶來了極大挑戰(zhàn)；另外凛澎，日常寫入均值是1000w TPS霹肝，到了雙11峰值達(dá)到1400w+ TPS，如此大量的數(shù)據(jù)怎么存儲塑煎。最后每天新增數(shù)據(jù)達(dá)數(shù)百TB沫换，數(shù)據(jù)的保存本身就是一個(gè)挑戰(zhàn)。
時(shí)序數(shù)據(jù)壓縮最铁。下圖左邊是一個(gè)表格讯赏，每一行代表一個(gè)時(shí)間序列垮兑，與OpenTSDB中表結(jié)構(gòu)一樣。由于時(shí)序模型比較單一漱挎，KV基本上都是類似設(shè)計(jì)系枪。0到3600代表過去一小時(shí)的數(shù)據(jù)，數(shù)據(jù)是秒級采集的磕谅，也就是說一行數(shù)據(jù)一共有3600列私爷，每列都有一個(gè)值。對于OpenTSDB來說整個(gè)存儲沒有壓縮膊夹。如果是毫秒級衬浑，一列需要360w秒，當(dāng)然時(shí)間窗口是可以調(diào)的放刨，但總的來說是受限制的工秩。阿里在存儲層參考Facebook Gorilla的思想，引入了時(shí)序壓縮算法宏榕。通過列合并的方式將所有時(shí)間戳和value分別聚合成兩個(gè)大的數(shù)據(jù)塊拓诸，之后對數(shù)據(jù)塊應(yīng)用時(shí)序壓縮算法，接著底層KV存儲會使用通用的塊壓縮進(jìn)行壓縮麻昼。整體壓縮率可以達(dá)到15:1奠支，這里壓縮率是根據(jù)線上真實(shí)的業(yè)務(wù)數(shù)據(jù)計(jì)算出來的。具體的壓縮算法如下抚芦，時(shí)間戳使用了delta-delta,浮點(diǎn)型用了XOR編碼倍谜，整型用了簡單的variable length encoding，字符串使用通用壓縮叉抡。需要說明一點(diǎn)尔崔。因?yàn)榘⒗飪?nèi)部有明確需求，所以不會使用有損壓縮褥民，但是這些算法實(shí)際上是支持的季春。
下圖是真實(shí)業(yè)務(wù)場景下的數(shù)據(jù)壓縮效果。壓縮前數(shù)據(jù)有6T消返，使用通用的塊壓縮载弄，壓縮完的結(jié)果是715G，不到1/10撵颊。時(shí)序壓縮和塊壓縮一起應(yīng)用的場景下可以到413G宇攻，整個(gè)壓縮效率可以達(dá)到15:1左右。時(shí)序壓縮加塊壓縮相比塊壓縮仍有40%的提升倡勇，這對于存儲成本的降低是有很大意義的逞刷。另一個(gè)好處就是時(shí)序壓縮在塊壓縮之前，做完時(shí)序壓縮數(shù)據(jù)體積已經(jīng)很小了，塊壓縮效率也不會受到影響夸浅。在大查詢場景下仑最，rt降低一半，當(dāng)做長時(shí)間范圍scan時(shí)题篷，數(shù)據(jù)已經(jīng)被高度壓縮词身，IO效率很高，rt可以降低一半番枚。
預(yù)聚合和降精度
數(shù)據(jù)降采樣，多層級時(shí)間縮放损敷。比如給客戶做一個(gè)報(bào)表葫笼，這個(gè)報(bào)表有多個(gè)時(shí)間層級，給客戶看過去一年拗馒，一個(gè)月或一周不同粒度的詳細(xì)數(shù)據(jù)路星，這是一個(gè)下鉆的過程。如果直接使用TSDB從詳細(xì)數(shù)據(jù)做聚合的話用戶體驗(yàn)很差诱桂，響應(yīng)時(shí)間可能特別長洋丐。
海量數(shù)據(jù)的聚合，統(tǒng)計(jì)分析挥等。對過去半年的數(shù)據(jù)做sum 友绝、min、max操作肝劲，甚至做P99迁客，P55分位的統(tǒng)計(jì)。這種情況下計(jì)算量特別大辞槐，如果直接從詳細(xì)數(shù)據(jù)里聚合也是不可行的掷漱。
時(shí)間線的Join。統(tǒng)計(jì)交易量的成功數(shù)量榄檬，失敗數(shù)量和總量卜范，并且計(jì)算其成功比率等。因?yàn)檎麄€(gè)數(shù)據(jù)的采集是成體系的從采集端到展示端鹿榜，直接修改采集端的采集來源可能不太靈活海雪，因此需要引擎支持多個(gè)時(shí)間線做 join 計(jì)算。
實(shí)時(shí)異常檢測犬缨，實(shí)時(shí)計(jì)算喳魏。給整個(gè)運(yùn)維大屏提供準(zhǔn)確，及時(shí)的數(shù)據(jù)怀薛，或者將異常的點(diǎn)發(fā)送給客戶做報(bào)警等刺彩。
下圖是計(jì)算引擎和存儲引擎一起提供的解決方案。首先阿里有一套自研的時(shí)序流計(jì)算引擎〈淳螅考慮到TSDB團(tuán)隊(duì)既要輸出阿里云公有云客戶嗡害，也要輸出阿里巴巴集團(tuán)內(nèi)部客戶，還要輸出專有云客戶畦攘。在不同場景下部署資源是受限的霸妹。我們基于 Apache Beam，設(shè)計(jì)了一套自研的時(shí)序流計(jì)算引擎的語義的框架知押。底層可以支持Flink叹螟，Spark，JVM內(nèi)存台盯，在大規(guī)陌照溃或小規(guī)模場景下都能做計(jì)算。在此基礎(chǔ)上静盅，時(shí)序流計(jì)算引擎提供了持續(xù)查詢能力良价，可以提供持續(xù)查詢的視圖，做報(bào)警或者復(fù)雜事件分析時(shí)可以直接查詢蒿叠、分析數(shù)據(jù)流中的時(shí)序數(shù)據(jù)明垢。時(shí)序流計(jì)算引擎和TSDB是打通的，用戶的數(shù)據(jù)寫進(jìn)來之后市咽，一部分?jǐn)?shù)據(jù)轉(zhuǎn)發(fā)給流計(jì)算引擎痊银。用戶可以和TSDB交互制定策略來決定哪些數(shù)據(jù)需要降采樣，哪些數(shù)據(jù)需要預(yù)聚合魂务。另外可以制定一些報(bào)警的規(guī)則曼验，下發(fā)給TSDB，然后TSDB將規(guī)則下發(fā)給時(shí)序流計(jì)算的持續(xù)查詢,最終實(shí)現(xiàn)報(bào)警粘姜。TSDB寫入的是詳細(xì)數(shù)據(jù)鬓照，時(shí)序流計(jì)算寫入的是概要數(shù)據(jù)，就是降采樣或預(yù)聚合以后的數(shù)據(jù)孤紧。TSDB端做查詢時(shí)用戶可以查詢預(yù)聚合數(shù)據(jù)豺裆。上層支持包括各種聚合算子，如 min号显，max臭猜，sum，count押蚤，p99蔑歌，P95 和中位數(shù)分位統(tǒng)計(jì)等，多個(gè)時(shí)間線之間的Join揽碘，亂序數(shù)據(jù)和重復(fù)數(shù)據(jù)的寫入等次屠。
2.高頻园匹、低延遲查詢
淘寶魔兔支撐著阿里內(nèi)部500+移動(dòng)端應(yīng)用無線數(shù)據(jù)的分析和監(jiān)控，是一個(gè)Mobile APM 場景的應(yīng)用劫灶。Mobile APM的特點(diǎn)是讀寫吞吐與用戶的交互相關(guān)裸违，屬于事件型時(shí)序數(shù)據(jù)。比如雙11大促的某一刻突然有一個(gè)活動(dòng)上來本昏，用戶集中訪問應(yīng)用中的某個(gè)功能時(shí)供汛，會產(chǎn)生成倍的突發(fā)流量。雙 11 監(jiān)控到的淘寶魔兔的查詢峰值達(dá)到了4000 QPS涌穆，下圖能夠看到寫入流量由均值 60萬 TPS 飆升到峰值600萬 TPS 左右怔昨，約有10倍的流量沖擊。另外蒲犬，業(yè)務(wù)方根據(jù) TSDB 而制定的一些實(shí)時(shí)的策略和決策會直接影響移動(dòng)端應(yīng)用的用戶體驗(yàn)朱监，所以業(yè)務(wù)方要求TSDB rt在20ms以內(nèi)。在這樣的場景下原叮，傳統(tǒng)TSDB，比如 OpenTSDB在查HBASE時(shí)IO路徑是非常長的巡蘸，整個(gè)查詢中會發(fā)生很多抖動(dòng)和毛刺奋隶。讀寫rt P99分布在20ms內(nèi)對OLAP系統(tǒng)來說是很難達(dá)到的。
為了支持高頻悦荒、低延遲查詢唯欣，我們參考Facebook Gorilla 設(shè)計(jì)了基于Java的分布式緩存方案，集群基于Zookeeper實(shí)現(xiàn)分片和容量調(diào)整搬味，可以實(shí)現(xiàn)動(dòng)態(tài)的擴(kuò)容和縮容境氢。整個(gè)雙11下來支撐了1000w+TPS寫入和 10 倍流量沖擊。其中最關(guān)鍵的是TSMem節(jié)點(diǎn)的設(shè)計(jì)碰纬。TSMem首先要解決兩個(gè)問題萍聊，一是如何實(shí)現(xiàn)如此高的吞吐。二是怎么保證查詢99% 的 rt 都維持在20ms以內(nèi)悦析，保持極低的延遲寿桨。TSMem 基于Disruptor 框架，將用戶并發(fā)讀寫的請求在 RingBuffer里做暫存强戴。采用多個(gè)生產(chǎn)者亭螟，一個(gè)消費(fèi)者模式。一個(gè)消費(fèi)者在消費(fèi)到用戶請求后骑歹，會將請求分發(fā)到對應(yīng)的 worker線程预烙。Worker線程池里面每一個(gè)線程對應(yīng)一個(gè)時(shí)序緩存分片，所以實(shí)際上是基于Disruptor 做了內(nèi)存 sharding道媚。一個(gè) worker 線程對應(yīng)一個(gè)shard扁掸，這樣的好處不用考慮鎖或其它資源的競爭翘县。另外值得注意的是把寫請求和讀請求都分配到同一個(gè)請求的鏈路上來，由同一個(gè)worker線程同時(shí)處理也糊，可以實(shí)現(xiàn)無鎖的讀寫炼蹦。另外利用RingBuffer的batching特性，一個(gè)簡單的寫入或小批量的寫入通過RingBuffer之后可以積攢成一個(gè)大的batch狸剃，然后在worker線程里做一次批量操作掐隐，可以極大提升吞吐量。另外一個(gè)的問題怎么保證高效的內(nèi)存管理和極低毛刺的rt钞馁。首先要降低JVM GC 的影響虑省，把所有的時(shí)序數(shù)據(jù)存在時(shí)序數(shù)據(jù)塊中，在內(nèi)存里做基于引用計(jì)數(shù)的chunk池化管理僧凰。這樣做的好處是沒有過多臨時(shí)對象的創(chuàng)建探颈，所以整個(gè) GC 很平穩(wěn)。減少了大量數(shù)據(jù)塊的創(chuàng)建和開銷训措。也會抹平掉在極端條件下突然申請一個(gè)新的很大的時(shí)序塊所造成的延遲的抖動(dòng)伪节。
3.高效聚合分析
Sunfire是阿里統(tǒng)一的日志和基礎(chǔ)監(jiān)控報(bào)警平臺。整個(gè)平臺覆蓋了集團(tuán)內(nèi)部5w+的應(yīng)用绩鸣。監(jiān)控指標(biāo)覆蓋從基礎(chǔ)設(shè)施到上層應(yīng)用怀大，包括IaaS，PaaS呀闻，SaaS以及無線應(yīng)用化借。這個(gè)場景帶來的挑戰(zhàn)是由于覆蓋的應(yīng)用特別多，業(yè)務(wù)復(fù)雜捡多，數(shù)據(jù)體量大蓖康，因此每秒掃描的時(shí)序數(shù)據(jù)量特別大。比如垒手，在大促時(shí)某個(gè)業(yè)務(wù)要做提前的擴(kuò)容蒜焊，上一批新的機(jī)器就相當(dāng)于一批新的時(shí)間序列的創(chuàng)建。最高的情況下可以達(dá)到每秒幾十萬時(shí)間線的創(chuàng)建淫奔。下圖展示的是在某一天有一批新的機(jī)器上線后的整個(gè)消費(fèi)過程山涡。累計(jì)的時(shí)間線在大促當(dāng)天統(tǒng)計(jì)達(dá)到60億，而且還在不停增長唆迁。如何解決每秒掃500w時(shí)間點(diǎn)鸭丛？如果在OpenTSDB內(nèi)存里做聚合計(jì)算直接響應(yīng)用戶查詢，需要把所有點(diǎn)堆在內(nèi)存中唐责，這會給系統(tǒng)造成極大的不穩(wěn)定因素鳞溉。另外一個(gè)是時(shí)間線創(chuàng)建的速度。比如說 OpenTSDB 是基于UID表的鼠哥，那字典表的原子操作也會有一個(gè)性能瓶頸熟菲，大概是20w TPS看政，這個(gè)瓶頸也會阻止業(yè)務(wù)的發(fā)展。
時(shí)序索引
高維聚合分析涉及到TSDB引擎兩個(gè)內(nèi)部的模塊抄罕。流式聚合引擎和時(shí)序索引允蚣。時(shí)序索引包括兩部分內(nèi)容，一部分是構(gòu)建出來的索引呆贿，另一部分索引的評估器嚷兔。時(shí)序索引整個(gè)查詢流程如下圖，首先會解析查詢做入，然后通過評估器給查詢做優(yōu)化冒晰，最終會把查詢具體執(zhí)行的步驟交給時(shí)序索引進(jìn)行查詢，最終返回時(shí)間線竟块。然后流式聚合引擎會根據(jù)查詢出的時(shí)間線從底層時(shí)序數(shù)據(jù)存儲中把查詢時(shí)間范圍內(nèi)的時(shí)序數(shù)據(jù)全部提取上來壶运，最終通過降采樣、預(yù)聚合計(jì)算后返回給用戶浪秘。
下圖展示的是時(shí)間線的生命周期圖蒋情。在不同階段有的時(shí)間線會消亡，有的時(shí)間線會創(chuàng)建出來耸携。用戶在查詢t2~t3時(shí)間范圍的時(shí)序數(shù)據(jù)的時(shí)候恕出，不會希望查到t0~t2時(shí)間范圍內(nèi)已經(jīng)消亡的時(shí)間線。因?yàn)槎嘁粭l時(shí)間線违帆，在流式聚合引擎去底層存儲撈數(shù)據(jù)點(diǎn)的時(shí)候就會多一次IO 操作。之前的存儲在InfluxDB 1.3之前是全內(nèi)存的時(shí)間線索引金蜀。全內(nèi)存的時(shí)間線索引不會對時(shí)間范圍做篩選刷后，在用戶查詢t2~t3的數(shù)據(jù)的時(shí)候，會返回所有的時(shí)間線渊抄，InfluxDB 1.3之后有基于文件的索引之后尝胆，可以直接返回這兩條時(shí)間線，性能提升很多护桦。
與InfluxDB創(chuàng)建落盤的時(shí)序索引的出發(fā)點(diǎn)一樣含衔，我們 TSDB 基于KV做了一套落盤的索引，其本質(zhì)上就是倒排索引二庵。時(shí)序索引的一個(gè)特性是給倒排索引增加了時(shí)間戳贪染。在倒排基礎(chǔ)上增加了時(shí)間戳后，索引查詢時(shí)支持首先根據(jù)tag和value過濾出目標(biāo)時(shí)間線催享，接著根據(jù)時(shí)間維度再做一次篩選杭隙，最終過濾效果會好很多。另外把整個(gè)倒排索引持久化到KV存儲總因妙，這樣索引節(jié)點(diǎn)可以實(shí)現(xiàn)無狀態(tài)運(yùn)行痰憎，支持水平擴(kuò)展票髓，并支持時(shí)間線的TTL。
下圖是時(shí)序索引的評估器铣耘，評估器要做的事情就是在用戶查詢時(shí)序索引時(shí)實(shí)現(xiàn)更高的查詢效率洽沟。評估器的數(shù)據(jù)來源包括 HyperLogLog 計(jì)數(shù)器，比如倒排里面某個(gè)tag或者整個(gè)倒排究竟有多少時(shí)間線;另外還來自 BloomFilter蜗细，記錄某個(gè)時(shí)間線究竟是否存在裆操；另外評估器的數(shù)據(jù)來自內(nèi)存里面的時(shí)序索引緩存。評估器在查詢的時(shí)候首先會選擇整個(gè)倒排里面較小的集合進(jìn)行運(yùn)算鳄乏，并支持對運(yùn)算查詢條件的優(yōu)先級排序跷车。如用戶提供了等于查詢或模糊匹配時(shí)，我們會首先執(zhí)行確定性更強(qiáng)的等于查詢橱野，當(dāng)然同時(shí)也要比較集合的大小朽缴。比如用戶查詢提供了兩個(gè)條件，分別是機(jī)房維度和IP維度水援，評估器首先判斷要優(yōu)先查詢IP維度密强，因?yàn)镮P維度對應(yīng)的 tag 包含的時(shí)間線更多，過濾時(shí)效率會更高蜗元。因此或渤，BloomFilter和HLL雖然是粗略的統(tǒng)計(jì)，但在兩個(gè)查詢條件涉及的集合存在數(shù)量級差別時(shí)奕扣，依然能有效提高查詢效率薪鹦。另外比如如果BloomFilter 反饋時(shí)間線不存在，那整個(gè)查詢就可以立即終止惯豆。!
流式聚合引擎
前面介紹的預(yù)聚合和降采樣是在數(shù)據(jù)寫入TSDB之前進(jìn)行的池磁，流式聚合引擎是TSDB進(jìn)程內(nèi)部的用戶查詢時(shí)的聚合和計(jì)算的引擎。流式聚合引擎基于pipeline 方案設(shè)計(jì)楷兽，整個(gè) pipeline 包含有不同的步驟地熄，它提供10+核心聚合算子，20+ 填充策略芯杀，10+插值算法端考。可以把用戶的復(fù)雜查詢轉(zhuǎn)化成一些簡單的算子組合揭厚，轉(zhuǎn)換的結(jié)果可以保證整個(gè)查詢結(jié)果準(zhǔn)確性却特。前面提到的時(shí)序索引查到時(shí)間線后會交給流式聚合引擎，從時(shí)序數(shù)據(jù)存儲里面將具體的時(shí)間序列撈出來棋弥，根據(jù)用戶的查詢條件做降采樣核偿，或者缺點(diǎn)填充，聚合操作等顽染。整個(gè)pipeline里其實(shí)不止圖上列出的幾類算子漾岳，還包括 topN轰绵、limit、插值等算子尼荆，采用松耦合方式設(shè)計(jì)左腔，擴(kuò)展性很好。另外整個(gè)pipeline從數(shù)據(jù)庫撈數(shù)據(jù)時(shí)捅儒，是以小批量的方式撈出來液样，然后再交給流式引擎里面其它算子。本質(zhì)上是一個(gè)火山模型巧还。撈出來的小批量數(shù)據(jù)在內(nèi)存里面是以列式存儲鞭莽，每一個(gè)算子計(jì)算性能很高。另外內(nèi)存里的流式聚合引擎可以與寫入 TSDB 之前做的預(yù)聚合和降精度生成的結(jié)果做無縫銜接麸祷。假設(shè)降采樣提前計(jì)算出五分鐘粒度的數(shù)據(jù)并寫入 TSDB澎怒，此時(shí)如果用戶的查詢剛好是五分鐘粒度降采樣查詢，那么流式計(jì)算引擎就不需要從時(shí)序數(shù)據(jù)庫里面撈詳細(xì)數(shù)據(jù)進(jìn)行計(jì)算阶牍，而是直接撈五分鐘粒度的數(shù)據(jù)做進(jìn)一步迭代計(jì)算即可喷面。所以說整個(gè)TSDB和計(jì)算引擎是打通的。
穩(wěn)定性保障
工作負(fù)載管理
因?yàn)門SDB既要提供集團(tuán)內(nèi)部和專有云客戶走孽，同時(shí)也要在公有云上服務(wù)外部客戶惧辈，所以穩(wěn)定性是非常重要的。TSDB 從三個(gè)層面做了穩(wěn)定性和安全層面的保障磕瓷。第一是資源隔離盒齿。第二是做時(shí)間線和時(shí)序數(shù)據(jù)細(xì)粒度的流控。最后是全面的指標(biāo)監(jiān)控困食。
資源隔離县昂。主要是讀寫線程的分離，保證查詢的鏈路突然有故障時(shí)不會影響寫入陷舅，寫入鏈路有故障的時(shí)候也不會影響查詢。另外是慢查詢和大查詢的資源隔離审洞。根據(jù)用戶提供的查詢條件莱睁，計(jì)算一個(gè)指紋，通過指紋和歷史查詢記錄芒澜，可以判斷是不是一個(gè)大查詢或者慢查詢仰剿。如果是慢查詢，TSDB會直接將該查詢放入一個(gè)單獨(dú)的隔離隊(duì)列里面痴晦，該隊(duì)列是資源受限的南吮。假如是一個(gè)正常查詢，TSDB 就會將當(dāng)期查詢放到資源更加充足的隊(duì)列里面誊酌，從一定程度上可以加速整個(gè)查詢部凑。
全面監(jiān)控指標(biāo)露乏。包括TSDB整體吞吐量，響應(yīng)時(shí)間涂邀，IO層面的關(guān)鍵指標(biāo)瘟仿，還包括各個(gè)核心模塊如時(shí)序索引模塊或者流式聚合模塊的核心指標(biāo)”让悖可以很清晰劳较，快速地了解到TSDB內(nèi)部究竟發(fā)生了什么，快速定位客戶的問題浩聋。
時(shí)間線和時(shí)序數(shù)據(jù)細(xì)粒度的流控观蜗。端到端流控目的是在突發(fā)流量場景下或用戶負(fù)載突然增加時(shí)，保護(hù)引擎不會受到影響甚至 crash衣洁。首先墓捻，TSDB 會在讀寫入口做IO線程的資源控制。其次會在 TSDB 內(nèi)部兩個(gè)大的核心模塊的入口和IO出口處對流量做一個(gè)控制闸与。另外毙替，流控的維度非常多，比如可以針對時(shí)間線模型進(jìn)行流量控制践樱。時(shí)間線過多的時(shí)候厂画，說明該業(yè)務(wù)在設(shè)計(jì)時(shí)序模型時(shí)可能是有問題的，需要做預(yù)聚合之類拷邢，降低查詢覆蓋的時(shí)間線袱院。其他維度，諸如查詢覆蓋的時(shí)序數(shù)據(jù)點(diǎn)數(shù)量瞭稼，IO層面如吞吐量等忽洛，以及整個(gè)查詢耗時(shí)統(tǒng)計(jì)等。
四环肘、總結(jié)和展望
上面提到的幾個(gè)場景都是 TSDB 在 2018年已經(jīng)解決或者正在解決的問題欲虚。接下來介紹下，TSDB要往那些方向發(fā)展悔雹，要做些什么功能复哆、特性，滿足哪些需求腌零。第一個(gè)是冷熱數(shù)據(jù)的異構(gòu)存儲梯找，其目的就是降低用戶的成本。因?yàn)楝F(xiàn)在數(shù)據(jù)價(jià)值越來越受到重視益涧，最好能把用戶的詳細(xì)數(shù)據(jù)給長久保存下來锈锤，因此需要提供一個(gè)詳細(xì)數(shù)據(jù)、長時(shí)間的存儲解決方案，比如跟阿里云OSS打通等久免。第二個(gè)是Serverless的讀寫能力浅辙。Serverless讀寫能力實(shí)現(xiàn)之后，可以讓TSDB有全域的分析計(jì)算能力妄壶。全域分析計(jì)算能力指的是首先高頻低延遲的短時(shí)間的查詢摔握，另外是OLAB系統(tǒng)長時(shí)間高維度的聚合分析，然后是歷史詳細(xì)數(shù)據(jù)或歷史某一段時(shí)間數(shù)據(jù)的分析丁寄。歷史數(shù)據(jù)怎么分析氨淌，或者冷數(shù)據(jù)怎么分析都是Serverless來解決的。Serverless還可以降低計(jì)算伊磺，查詢盛正，寫入等的成本，降低客戶成本屑埋。第三是擁抱時(shí)序生態(tài)豪筝。比如說學(xué)習(xí)和借鑒Prometheus 系統(tǒng)設(shè)計(jì)或者其他商用 TSDB 和監(jiān)控解決方案，以及擁抱開源社區(qū)摘能，提供高可用续崖、穩(wěn)定的適配和替代方案，把 TSDB 的優(yōu)勢团搞，如流式計(jì)算严望、時(shí)序索引、計(jì)算引擎或SQL引擎等等提供出來逻恐，給客戶一個(gè)更好的解決方案像吻。然后是時(shí)序智能分析，希望能夠做更多的穩(wěn)定复隆、可靠的模型拨匆，深入到行業(yè)內(nèi)部給客戶解決一些具體問題。
