本次分享內(nèi)容：

時序數(shù)據(jù)平臺主要業(yè)務(wù)場景

時序數(shù)據(jù)平臺體系架構(gòu)

時序數(shù)據(jù)平臺核心技術(shù)

PART01 時序數(shù)據(jù)平臺主要業(yè)務(wù)場景

 

 

上圖為數(shù)據(jù)的整體架構(gòu)，大部分公司都是差不多的：

原始數(shù)據(jù)：MySQL、服務(wù)端的 Log、APP-Data、Sensor，大家知道現(xiàn)在穿戴設(shè)備很多，比如手表等，這樣都會產(chǎn)生很多數(shù)據(jù)，這些數(shù)據(jù)都稱為時序數(shù)據(jù)，隨著時間的變化不斷產(chǎn)生數(shù)據(jù)。

數(shù)據(jù)采集層：sqoop、DataStream、SDK、Gataway

數(shù)據(jù)加工層：數(shù)據(jù)存在 kafka 里，再經(jīng)過一些流計算處理(Flink、Sparkstreaming)

數(shù)據(jù)存儲分析層：

離線存儲分析平臺：技術(shù)棧包括最底層的 HDFS、Kudu、GP 等數(shù)據(jù)存儲，在這之上要做很多的計算，包括 Hive、Spark、Impala 等，他的應(yīng)用場景包括數(shù)倉報表、機(jī)器學(xué)習(xí)、模型訓(xùn)練等;

在線存儲計算平臺：應(yīng)用的業(yè)務(wù)場景包括，交易訂單，優(yōu)惠券，用戶畫像等，這里主要應(yīng)用的是 HBase;

時間序列存儲計算平臺：應(yīng)用場景包括，業(yè)務(wù)設(shè)備監(jiān)控，實時廣告平臺，物聯(lián)網(wǎng)應(yīng)用，相關(guān)的技術(shù)包括 OpenTSDB、Druid、InfluxDB 等。

所以會根據(jù)不同的業(yè)務(wù)使用不同的平臺來處理相關(guān)的數(shù)據(jù)，對于我們來說最大的工作是在數(shù)據(jù)存儲端。

 

 

時序數(shù)據(jù)主要包括時間列、維度列和指標(biāo)列，這 3 列缺一不可(特別是時間列)。

工業(yè)互聯(lián)網(wǎng)時代，會源源不斷產(chǎn)生各種各樣的時序數(shù)據(jù)，時序數(shù)據(jù)平臺有以下幾種典型場景：

系統(tǒng)監(jiān)控：

物理機(jī)、云主機(jī)、容器：CPU、內(nèi)存、IO 等

組件服務(wù)：數(shù)據(jù)庫集群、Kafka 集群、HBase 集群

任務(wù)監(jiān)控：

查看指定 hadoop 任務(wù)耗用內(nèi)存、CPU、IO 利用率等

查看集群消耗資源 TopN 任務(wù)、節(jié)點(diǎn)等

統(tǒng)計集群任務(wù)執(zhí)行耗時

應(yīng)用性能監(jiān)控：

應(yīng)用調(diào)用次數(shù)，錯誤占比，頁面加載延遲統(tǒng)計、地域統(tǒng)計分析

慢加載追蹤，慢 SQL

異常會話追蹤

鏈路監(jiān)控：

調(diào)用鏈全息排查

全局調(diào)用拓?fù)?/p>

鏈路依賴項分析梳理

業(yè)務(wù)監(jiān)控統(tǒng)計：

a. 電商

業(yè)務(wù)大盤：查看單量，金額，發(fā)貨等業(yè)務(wù)指標(biāo)

異常大盤：查看超賣，庫存校準(zhǔn)耗時，商品回調(diào)耗時，各種類型下單錯誤等異常指標(biāo)

b. 廣告

廣告曝光點(diǎn)擊消耗實時統(tǒng)計

流量地域分配

以基礎(chǔ)系統(tǒng)監(jiān)控服務(wù)為例，舉例描述兩個應(yīng)用場景：

物理機(jī)基礎(chǔ)硬件指標(biāo)監(jiān)控

 

 

HBase-RegionServe 指標(biāo)監(jiān)控

 

 

直觀地看，以上數(shù)據(jù)的橫坐標(biāo)都是時間戳，即設(shè)備隨著時間不斷吐數(shù)據(jù)。

時序數(shù)據(jù)應(yīng)用場景的核心特征：

時間區(qū)間查詢，最近時間區(qū)的數(shù)據(jù)的查詢頻率遠(yuǎn)大于歷史數(shù)據(jù);

多維條件查詢，即多維字段隨機(jī)組合查詢;

 

 

支持 TTL 機(jī)制，數(shù)據(jù)可以自動過期;

支持高壓縮率，數(shù)據(jù)壓縮比要達(dá)到 10 以上;

支持高效聚合;

支持集群可擴(kuò)展，服務(wù)高可用，數(shù)據(jù)高可靠。

PART02 時序數(shù)據(jù)平臺架構(gòu)體系

時序序列平臺以監(jiān)控類系統(tǒng)體系架構(gòu)為例，如下圖所示：

 

 

將多數(shù)據(jù)來源的數(shù)據(jù)(如 Agent 采集器，打點(diǎn)日志、流式數(shù)據(jù)，IoT Hub 等)，通過 Kalfa 工具(分布式消息隊列系統(tǒng))進(jìn)行流式處理，匯集到網(wǎng)易時序數(shù)據(jù)平臺上。

PART03 時序數(shù)據(jù)平臺核心技術(shù)

在上述架構(gòu)體系中，數(shù)據(jù)庫作為其核心環(huán)節(jié)�？紤]到 DDB(分布式 MySQL)實時寫入性能不足，HBase/ES 等開源 NoSQL 平臺多維查詢以及聚合計算等功能不夠;針對海量時序數(shù)據(jù)這類應(yīng)用場景，因此需要專門的時序數(shù)據(jù)庫。

現(xiàn)有市場上較成熟的時序數(shù)據(jù)庫主要包括 Druid、OpenTSDB、InfluxDB 等。網(wǎng)易結(jié)合以上各類時序數(shù)據(jù)庫的優(yōu)缺點(diǎn)，自主研發(fā)分布式時序數(shù)據(jù)庫平臺，支持高性能寫入和讀取，支持多維條件查詢，支持聚合計算，且運(yùn)行開銷較小，可私有化、分布式部署。

 

 

該時序數(shù)據(jù)庫的分布式集群結(jié)構(gòu)與 hadoop，Hbase，Kudu 等架構(gòu)非常相似：多臺服務(wù)器用來存儲數(shù)據(jù)，并通過 Raft 保證數(shù)據(jù)的一致性。數(shù)據(jù)的分布式計算是在分布式節(jié)點(diǎn)(node)上完成的，每個 node 上的數(shù)據(jù)存儲計算系統(tǒng)稱之為 shard server。在 Shard Server 的底層數(shù)據(jù)存儲中，原始數(shù)據(jù)存一份，再按照索引的方式再存一份。

 

 

網(wǎng)易時序數(shù)據(jù)平臺的數(shù)據(jù)存儲方式是這樣的：

1、DataBase 中建立若干 StorePolicy(類似 MySQL 數(shù)據(jù)庫中的表結(jié)構(gòu))，其作用為：

(1) 指定數(shù)據(jù)過期時間;

(2) 指定數(shù)據(jù)副本數(shù)量;

(3) 指定分片時間間隔。

2、每個 StorePolicy 中，按照指定的時間間隔建立若干 ShardGroup。將最新寫入的數(shù)據(jù)(稱之為熱數(shù)據(jù))存到對應(yīng)的 ShardGroup 中，再通過哈希分片的方式將該 ShardGroup 分片成若干個 Shard，這些 Shard 會分布至整個集群。

 

 

以上圖為例，同一時間段不同 shard 分布到不同的節(jié)點(diǎn)上。例如：左側(cè)大方框中包含的 6 條記錄，代表該時間段的記錄分布在 6 個 shard 里;右側(cè)小方框中的 5 和 6，代表該 shard 共有 2 個副本，分別分布在集群中的 5 號節(jié)點(diǎn)和 6 號節(jié)點(diǎn)。

由此可以看出，同一時間段的多個 shard 是分布在多個節(jié)點(diǎn)上。這樣做的好處是：查找指定時間段的數(shù)據(jù)時，只需要在相應(yīng)節(jié)點(diǎn)中查到對應(yīng)的 shard 里的數(shù)據(jù)即可，避免了全局遍歷的情況。

3、數(shù)據(jù)在 shard 中的存儲方式：

(1) 時間線列式存儲：

具體來說，SeriesKey 相當(dāng)于原始數(shù)據(jù)(DataSource)，具有不同維度;存儲的時候，所有的時間存到一起，所有的 value 單獨(dú)存在一起，這種存儲方法叫做列式存儲。列式存儲有兩大好處：

每一列數(shù)據(jù)類型相同，因此壓縮率非常高;

方便對列做聚合計算。

 

 

什么是列式存儲?

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫如 Oracle、MySQL、SQL SERVER 等，都采用的是行式存儲法 (Row-based)，在基于行式存儲的數(shù)據(jù)庫中，數(shù)據(jù)是按照行數(shù)據(jù)為基礎(chǔ)邏輯存儲單元進(jìn)行存儲的，每行中的數(shù)據(jù)在存儲介質(zhì)中以連續(xù)存儲形式存在。

不同于行式存儲，列式存儲以列為基礎(chǔ)單元，每列的數(shù)據(jù)在存儲介質(zhì)中以連續(xù)存儲的形式存在。

針對海量分布式數(shù)據(jù)背景的 OLAP(on-line analysis processing)，列式存儲可在內(nèi)存中高效組裝各列數(shù)據(jù)并形成關(guān)系集，可避免全表掃描，顯著減少 IO 消耗。

(2) 倒排索引

支持 sql 語句進(jìn)行條件篩選;在條件篩選的過程中，使用倒排索引方法，實現(xiàn)快速定位，可“直達(dá)用戶需求”。

正排索引：key-value 中，通過 key 去尋找 value;

倒排索引：通過 value(或包含 value)去尋找對應(yīng)的 key。

正排索引需要首先對全局進(jìn)行掃描遍歷，進(jìn)而從中做篩選;而倒排索引可以僅抽取符合條件的 value 值，節(jié)省大量的資源。

(3) shard 自動擴(kuò)容

數(shù)據(jù)庫作為分布式系統(tǒng)，需要考慮系統(tǒng)的擴(kuò)容(即增加節(jié)點(diǎn))。

增加節(jié)點(diǎn)后，為保證數(shù)據(jù)存儲的均衡，將不再更新的數(shù)據(jù)(即歷史數(shù)據(jù))作為 cold shard，平均分布到集群的所有節(jié)點(diǎn)(包括新增加的節(jié)點(diǎn))中，而實時更新的數(shù)據(jù)(即 hot shard，隨時間不斷寫入)不做任何處理。

(4) 多級存儲優(yōu)化

考慮到時序數(shù)據(jù)的一個特點(diǎn)：熱數(shù)據(jù)查詢概率遠(yuǎn)大于冷數(shù)據(jù)。針對這一特性，做了如下兩個優(yōu)化：

A. 考慮到數(shù)據(jù)文件可能存在多級索引，針對冷數(shù)據(jù)，只加載一級索引即 root 索引;針對熱數(shù)據(jù)，會加載所有索引。

B. 因此針對集群服務(wù)器配置方面，每個集群 12 塊盤，只需要 1 塊 ssd 用來存儲 hot shard 即可，其余均使用普通 hhd 即可，最大程度降低硬件成本。

cluster 是整個集群，包含 n 個 node;

node 通常掌控獨(dú)立的資源，包括 cpu 等;一臺機(jī)器可以多個 node。

shard 一般是從數(shù)據(jù)角度來說。例如，1000 條數(shù)據(jù)按 id 分，存 10 份，就是 10 個 shard。

shards 分散在多個 node 上。

最后通過以上手段，來實現(xiàn)剛剛所說的時序數(shù)據(jù)應(yīng)用場景的核心特征：時間區(qū)間查詢，多維條件查詢，支持 TTL 機(jī)制，支持高壓縮率，支持高效聚合，支持集群可擴(kuò)展，服務(wù)高可用，數(shù)據(jù)高可靠。

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。