時間序列數據存儲的體系結構
背景
近年來，隨著物聯網的發展，時間序列數據呈爆炸式增長。 根據過去兩年在DB-Engines中收集的數據庫類型的增長趨勢，時間序列數據庫一直在快速增長。 這些大型開源時間序列數據庫的實現各不相同，但沒有一個是完美的。 但是，可以結合使用這些數據庫的優勢來實現完美的時間序列數據庫。
表存儲是阿里云開發的分布式NoSQL數據庫。 它具有多模型設計，其中包括與BigTable相同的寬列模型，以及消息數據的時間軸模型。 在存儲模型，數據大小以及寫入和查詢功能方面，它可以更好地滿足時間序列數據方案的要求。 但是，作為通用模型數據庫，如果時間序列數據存儲要充分利用基礎數據庫的功能，則表的模式設計和計算集成需要特殊的設計，例如用于HBase和UID編碼的OpenTSDB的RowKey設計。 。
本文涉及該體系結構，重點關注時間序列數據的數據模型定義和核心處理流程，以及基于表存儲構建時間序列數據存儲的體系結構。 將來，將有一篇關于解決方案的文章，它將為時間序列數據和元數據存儲提供高效的架構設計和索引設計。 最后，還將有一篇關于計算的文章，提供了一些用于時間序列數據流計算和時間序列分析的項目設計。
什么是時間序列數據？
時間序列數據分為兩種主要類型："監視"時間序列數據和"狀態"時間序列數據。 當前的開源時間序列數據庫都集中在時間序列數據的監視類型上，并且在這種情況下針對數據特征進行了特定的優化。 但是，根據時間序列數據的特征，還有另一種類型的時間序列數據，即"狀態"時間序列數據。 這兩種時間序列數據對應于不同的場景。 顧名思義，監視類型對應于監視方案，而狀態類型則適用于其他方案，例如跟蹤和異常狀態記錄。 我們最常見的程序包跟蹤用于狀態時間序列數據。
兩種類型的數據都歸為"時間序列"的原因是，它們在數據模型定義，數據收集以及數據存儲和計算方面都完全一致，并且可以抽象出相同的數據庫和相同的技術體系結構。
時間序列數據模型
在定義時間序列數據模型之前，我們首先對時間序列數據進行抽象表示。
· 個人或團體（WHO）：描述產生數據的主題。 該主題可以是人，監視指標或對象。 它通常描述一個人具有多維屬性，并且可以使用某個唯一ID來定位該人。 例如，使用一個人的ID來找到一個人，然后使用設備的ID來找到一個設備。 也可以通過多維屬性來定位個人。 例如，通過使用群集，計算機ID和進程名稱來查找進程。
· 時間（WHEN）：時間是時間序列數據的最重要特征，并且是將其與其他數據區分開的關鍵屬性。
· 位置（WHERE）：通常使用緯度和經度的二維坐標來定位位置； 并通過與緯度，經度和海拔的三維坐標來確定與科學計算有關的領域，例如氣象學。
· 狀態（WHAT）：用于描述特定個人在特定時刻的狀態。 用于監視的時間序列數據通常是數字描述狀態，而跟蹤數據使用事件表示的狀態，其中對于不同的場景有不同的表達式。
上面是時間序列數據的抽象表示。 每個開源時間序列數據庫都有自己的時間序列數據模型定義，該模型定義了要監視的時間序列數據。 以OpenTSDB數據模型為例：
監視時間序列數據模型定義包括：
· 指標：用于描述監視指標。
· 標簽：用于定位被監視對象，使用一個或多個標簽對其進行描述。
· 時間戳記：收集監視值的時間點。
· 值：收集的監視值，通常是數字。
監視時間序列數據是時間序列數據的最典型類型，并且具有特定的特征。 監視時間序列數據的特征確定這些類型的時間序列數據庫具有特定的存儲和計算方法。 與狀態時間序列數據相比，它在計算和存儲方面有特定的優化。 例如，聚合計算將具有幾個特定的數字聚合函數，并且存儲上將有專門優化的壓縮算法。 在數據模型中，監視時間序列數據通常不需要表達位置，即時空信息。 但是，總體模型與我們對時間序列的統一抽象表示相關。
基于監視時間序列數據模型，我們可以根據上述時間序列數據抽象模型定義以下時間序列數據的完整模型：
定義包括：
· 名稱：定義數據的類型。
· 標簽：描述個人的元數據。
· 位置：數據的時空信息。
· 時間戳：生成數據的時間戳。
· 值：與數據相對應的值或狀態。 可以提供多個值或狀態，這些值或狀態不必一定是數字。
這是一個更完整的時間序列數據模型，與OpenTSDB的監視時間序列數據的模型定義有兩個主要區別：首先，元數據中還有一個維度，位置。 其次，它可以表達更多的價值。
時間序列數據查詢，計算和分析
時間序列數據具有自己的特定查詢和計算方法，其中大致包括以下類型：
時間線檢索
根據數據模型定義，可以使用名稱標簽位置來定位個人。 每個人都有自己的時間軸，時間軸上的點是時間戳和值。 對于時間序列數據查詢，需要首先定位時間軸，這是基于元數據的一個或多個值的組合進行檢索的過程。 您還可以根據元數據的關聯進行深化。
時間范圍查詢
通過檢索找到時間軸后，將查詢時間軸。 在時間軸上的單個時間點上的查詢很少，并且查詢通常在連續時間范圍內的所有點上進行。 通常在此連續時間范圍內對缺失點進行插值。
聚合
可以查詢單個時間軸或多個時間軸。 對于多個時間軸的范圍查詢，通常會匯總結果。 此匯總適用于不同時間軸上同一時間點的值，通常稱為"后匯總"。
"后聚合"的對立面是"預聚合"，它是在時間序列數據存儲之前將多個時間線聚合為一個時間線的過程。 預聚合計算數據然后存儲它，而后聚合查詢存儲的數據然后計算它。
下采樣
下采樣的計算邏輯與聚合類似。 不同之處在于，下采樣是針對單個時間軸而不是多個時間軸。 它在單個時間軸上聚合時間范圍內的數據點。 下采樣的主要目的之一是在很大的時間范圍內顯示數據點。 另一個是降低存儲成本。
分析
進行分析以從時間序列數據中提取更多價值。 有一個特殊的研究領域稱為"時間序列分析"。
時間序列數據處理程序
時間序列數據處理的核心過程如上所示，包括：
· 數據模型：對于時間序列數據的標準定義，收集的時間序列數據必須符合模型的定義，包括時間序列數據的所有特征屬性。
· 流計算：時間序列數據的預聚合，下采樣和后聚合。
· 數據存儲：該存儲系統可提供高吞吐量，大容量和低成本的存儲，并支持冷/熱數據的分離以及有效的范圍查詢。
· 元數據檢索：提供時間軸元數據的存儲和檢索，順序為數千萬至數億，并支持不同的檢索方法（多維過濾和位置查詢）。
· 數據分析：提供時間序列數據的時間序列分析和計算功能。
現在讓我們看一下可以在這些核心流程中使用的產品的選擇。
數據存儲
時間序列數據是典型的非關系數據。 它的特點是高并發，高吞吐量，大數據量以及高寫入和低讀取。 查詢模式通常是范圍查詢。 這些數據特征非常適合與NoSQL類型的數據庫一起使用。 一些流行的開源時間序列數據庫使用NoSQL數據庫作為數據存儲層，例如基于HBase的OpenTSDB和基于Cassandra的KairosDB。 因此，就"數據存儲"的產品選擇而言，我們可以選擇開源分布式NoSQL數據庫（例如HBase或Cassandra）或云服務（例如阿里云的Table Store）。
流計算
對于流計算，我們可以使用JStrom，Spark Streaming和Flink等開源產品，或者使用阿里巴巴的Blink和云產品StreamCompute。
元數據搜索
時間軸的元數據也將很大，因此我們將首先考慮使用分布式數據庫。 另外，由于查詢模式需要支持檢索，因此數據庫需要支持倒排索引和位置索引，因此可以使用開源的Elasticsearch或Solr。
數據分析
數據分析需要強大的分布式計算引擎。 我們可以選擇開源軟件Spark，云產品MaxCompute或無服務器SQL引擎，例如Presto或云產品Data Lake Analytic。
開源時間序列數據庫
根據DB-Engines上數據庫的發展趨勢，我們看到時間序列數據庫在過去兩年中發展迅速，并且出現了許多出色的開源時間序列數據庫。 主要時間序列數據庫的每種實現都有其自身的優點。 以下是從多個維度對這些數據庫進行的全面比較：
· 數據存儲：所有數據庫都使用分布式NoSQL（LSM引擎）存儲，包括開源分布式數據庫（例如HBase和Cassandra）以及云平臺（例如BigTable）以及自行開發的存儲引擎。
· 聚合：預聚合完全依賴于外部流計算引擎，例如Storm或Spark Streaming。 在聚合后級別上，查詢聚合后是一個交互式過程，因此通常不依賴于流計算引擎。 不同的時間序列數據庫提供了單線程簡單方法或并發計算方法。 自動下采樣也是后聚合過程，但是它是流過程而不是交互過程。 此計算適用于流計算引擎，但不能以這種方式實現。
· 元數據存儲和檢索：傳統的OpenTSDB沒有專用的元數據存儲，并且不支持元數據的檢索。 通過掃描數據表的行鍵來獲取和查詢元數據。 KairosDB使用表在Cassandra中存儲元數據，但由于需要掃描該表，因此檢索效率非常低。 Heroic的二次開發基于KairosDB。 它使用Elasticsearch進行元數據存儲和索引，并支持更好的元數據檢索。 InfluxDB和Prometheus獨立地實現索引編制，但是索引編制并不容易，并且需要數以千萬計至數億美元的時間軸元數據。 在較早的版本中，InfluxDB實現了一個內存中的元數據索引，它的限制更為嚴格。 例如，時間軸的規模受到內存大小的限制，并且內存索引結構必須掃描所有時間軸元數據，從而導致更長的節點故障轉移時間。
· 數據分析：除了Elasticsearch之外，大多數TSDB均不具備分析功能，除了具有用于后聚合的查詢和分析功能外。 這是一個重要的優勢，它使Elasticsearch可以在時間序列分析領域立足。
表存儲時間序列數據存儲
作為阿里云開發的分布式NoSQL數據庫，表存儲使用與Bigtable相同的"寬列"數據模型。 就存儲模型，數據大小以及寫入和查詢功能而言，該產品非常適合時間序列數據方案。 我們還支持監視時間序列產品（例如CloudMonitor），狀態時間序列產品（例如AliHealth的藥物跟蹤）以及核心服務（例如郵政包裹跟蹤）。 還有一個完整的計算生態系統來支持時間序列數據的計算和分析。 在我們的未來計劃中，我們對時間序列方案進行了特定的優化，例如元數據檢索，時間序列數據存儲，計算和分析以及降低成本。
以上是基于表存儲的時間序列數據存儲，計算和分析的完整架構。 這是一種無服務器架構，可以通過組合云產品來提供完整時間序列方案所需的所有功能。 每個模塊都有分布式架構，提供強大的存儲和計算功能，并且資源可以動態擴展。 每個組件也可以用其他類似的云產品替換。 與開放源時間序列數據庫相比，該體系結構具有靈活性并具有巨大優勢。 下面分析了此體系結構的核心優勢：
存儲與計算分離
存儲和計算的分離是技術架構的一種主要形式。 它的核心優勢是提供更靈活的計算和存儲資源配置，更靈活的成本以及更好的負載平衡和數據管理。 為了讓用戶真正享受存儲和計算分離帶來的好處，必須在云環境的上下文中提供用于存儲和計算分離的產品。
表存儲以技術架構和產品形式實現存儲和計算的分離，并可以以相對較低的成本自由分配存儲和計算資源。 這在時序數據場景中尤其重要，在時序場景中，計算相對恒定，而存儲量卻呈線性增長。 優化成本的主要方法是分配恒定的計算資源和無限可擴展的存儲，從而使計算驅動存儲而無需承擔額外的計算成本。
冷/熱數據分離
時間序列數據的顯著特征是熱數據訪問和冷數據訪問之間的明顯區別，最近寫入的數據被更頻繁地訪問。鑒于此特性，熱數據采用具有更高IOPS的存儲介質，從而大大提高了整體查詢效率。表存儲提供了兩種類型的實例：高性能實例和容量實例，分別對應于SSD和SATA存儲介質。該服務功能允許用戶自由分配具有不同規范的表，以用于不同精度級別的數據以及查詢和分析的不同性能要求。例如，對于高并發和低延遲查詢，將分配高性能實例；對于冷數據存儲和低頻查詢，將分配容量實例。對于需要更高速度的交互式數據分析，可以分配高性能實例。對于時間序列數據分析和脫機計算的方案，可以分配容量實例。
對于每個表，可以自由定義數據的TTL。 例如，對于高精度表，可以配置相對較短的TTL。 對于低精度表，可以配置更長的TTL。
大部分存儲用于冷數據。 對于這些訪問頻率較低的數據，我們將通過使用擦除編碼和極限壓縮算法來進一步降低存儲成本。
數據流閉環
流計算是時間序列數據計算中的核心計算方案。 它對時間序列數據執行預聚合和后聚合。 常見的監視系統體系結構是使用前端計算解決方案。 數據的預聚集和下采樣都在前端計算中執行。 也就是說，在存儲數據之前先對其進行處理，而存儲的只是結果。 不再需要第二個下采樣，并且最多可能需要聚合后查詢。
Table Store與Blink緊密集成，現在可以作為Blink維護表和結果表使用。 源表已經開發完畢，可以發布了。 表存儲可以用作Blink的源和后端，并且整個數據流可以形成一個閉環，從而提供更靈活的計算配置。 進入Blink后，原始數據將進行數據清洗和預聚合，然后寫入到熱數據表中。 這些數據可以自動流入Blink進行后聚合，并且支持一定時間段內的歷史數據回溯。 聚合后的結果可以寫入冷庫。
除了與Blink集成之外，表存儲還可以與Function Compute集成以進行事件編程，并且可以在時間序列方案中啟用實時異常狀態監視。 它還可以通過Stream API讀取增量數據以執行自定義分析。
大數據分析引擎
Table Store與阿里云開發的分布式計算引擎（例如MaxCompute（以前稱為ODPS））深度集成。 MaxCompute可以直接讀取Table Store上的數據以執行分析，從而消除了數據的ETL處理。
整個分析過程目前正在經歷一些優化。 例如，通過索引優化查詢，并在底部提供更多運算符來進行下推計算。
服務能力
總之，Table Store的服務功能具有零成本集成，即用型功能，全局部署，多語言SDK和完全托管服務的特點。
元數據存儲和檢索
元數據也是時間序列數據的非常重要的組成部分。 就數量而言，它比時間序列數據要小得多，但就查詢復雜度而言，它要復雜得多。
根據上面提供的定義，元數據可以主要分為"標簽"和"位置"。 標簽主要用于多維檢索，而位置主要用于位置檢索。 因此，為了從底層存儲中高效檢索，標簽必須實現反向排名索引，而位置需要實現位置索引。 服務級別監視系統或跟蹤系統的時間軸順序為數千萬到數億，甚至更高。 元數據還需要分布式檢索系統來提供高并發低延遲解決方案。 在行業中，更可取的實現方式是使用Elasticsearch來存儲和檢索元數據。
摘要
表存儲是支持多種數據模型的通用分布式NoSQL數據庫。 當前可用的數據模型包括寬列（BigTable）和時間軸（消息數據模型）。
在行業中類似數據庫產品（例如HBase和Cassandra）的應用程序中，時間序列數據是非常重要的領域。 Table Store一直在探索時間序列數據存儲領域。 我們還在不斷完善用于流計算數據，數據分析優化和元數據檢索的閉環構建，并努力提供統一的時間序列數據存儲平臺。
(本文翻譯自Alibaba Cloud的文章《Table Store Time Series Data Storage — Architecture》，參考：https://medium.com/@Alibaba_Cloud/table-store-time-series-data-storage-architecture-f686e85cf259)
