本文來源：《華為雲DTSE》第五期開源專刊，作者：向宇，華為雲資料庫高階研發工程師、黃飛騰，博士，openGemini儲存引擎架構師
在時序資料場景中，大部分的解決方案是以時間線為粒度對時序資料進行管理，這類解決方案在時間線數量不斷增長的情形下，面臨著諸多困難，包括記憶體膨脹、讀寫效能下降等，華為雲開源時序資料庫openGemini 針對該場景，提出了全新的列存引擎(HSCE)，以解決海量時間線所帶來的問題。
高基數問題長期困擾時序資料庫
時序資料是一種常見的資料型別，廣泛應用於車聯網、工業物聯網、航空航天、電力、DevOps 等領域。這類場景需要衡量事物狀態隨時間的變化，以便進行監控、分析和預測。例如，在DevOps中，我們需要監控服務的併發請求量；在工業物聯網中，我們需要監控裝置執行狀態。鑑於時序資料產生頻繁，且資料量很大，時序業務對實時性和查詢效率要求高，通常會使用時序資料庫對資料進行管理。
但在實際應用場景中，我們發現隨著裝置（例如車輛、終端裝置等）數量達到一定量級後，時序資料庫的讀寫效能會有明顯的下降，延時波動劇烈，透過升級機器規格也無明顯提升。導致這一現象的原因是海量時間線帶來的高基數問題。
什麼是時間線？
在時序資料庫中，時間線是對時間序列資料的建模，一條時間線的資料指同一資料來源產生的一系列資料點的集合，可以簡單理解為一臺裝置或者一輛車就是一條時間線。舉個例子，有如下6條時序資料，由標籤（A、B）、指標（C）和時間戳（Timestamp）組成。
A="a1",B="b1" C=2.82 1566000000
A="a2",B="b1" C=10.72 1566000000
A="a1",B="b2" C=15.82 1566000000
A="a1",B="b2" C=23.72 1568600000
A="a2",B="b3" C=1.36 1567000000
A="a2",B="b4" C=9.77 1568000000存在5條時間線，分別是
A="a1",B="b1"
A="a1",B="b2"
A="a2",B="b1"
A="a2",B="b3"
A="a2",B="b4"什麼是高基數問題（High Cardinality）？
在資料庫中，基數是指資料庫的特定列或欄位中包含的唯一值的數量。時間序列資料往往包含描述該資料的後設資料（習慣稱為“標籤 或 TAG”）。通常，主要時間序列資料或後設資料會被索引，以提高查詢效能，以便使用者可以快速找到與之匹配的所有值。時間序列資料集的基數通常由每個單獨索引列的基數的交叉乘積定義。如果有多個索引列，每個列都有大量唯一值，那麼交叉乘積的基數可能會變得非常大。這就是軟體開發人員在談論具有“高基數”的時間序列資料集時通常的意思。
比如，以智慧電錶為例，它會關聯裝置 ID、城市 ID、廠商 ID 和模型 ID 等標籤。幾百個城市，百萬級裝置，再加上不同的廠商、模型，基數輕鬆超過百億級。再比如，以網路監控為例，記錄訪問源到目的端經過的鏈路，它會關聯源IP、目的IP、運營商、路由裝置IP等標籤，上百萬IP地址產生大量鏈路資訊，基數很容易達到千億。
高基數問題根因在於時間線的倒排索引膨脹
倒排索引是時序資料庫常用的一種索引技術，主要記錄TAG和時間線之間的對應關係，給定一個或多個TAG，就可以快速找到相關的時間線，從而實現資料過濾，提升資料檢索效率。
以如下資料為例
A="a1",B="b1" C=2.82 1566000000
A="a2",B="b1" C=10.72 1566000000
A="a1",B="b2" C=15.82 1566000000
A="a1",B="b2" C=23.72 1568600000
A="a2",B="b3" C=1.36 1567000000
A="a2",B="b4" C=9.77 1568000000時序資料庫中倒排索引的組織方式如下圖所示：
現有大部分時序資料管理解決方案，通常會將資料按照時間線（即標籤值的組合）進行聚簇，時間線相同的資料再按照時間進行排序，同時構建了標籤(A)+標籤值(如a1)到時間線的倒排索引，這種儲存方式在時間線數量相對有限的情形下，可以提供極致的寫入與查詢效能，但是在處理高基數場景時，例如圖中的A和B兩個標籤列下各有數百萬不同值，那麼總體時間線數量巨大，由於倒排索引與時間線數量相關，索引項激增，會導致記憶體膨脹、讀寫效能下降等問題。
高基數問題的解決方案剖析
高基數問題的核心在於最佳化索引結構，以提高索引的檢索效率並減少記憶體佔用。目前，稀疏索引被認為是一種高效的解決方案。ClickHouse資料庫提供了一個實際的應用案例，用於我們研究這一問題。
Clickhouse在時序場景下存在侷限性
以ClickHouse為例，分析其稀疏索引結構。
ClickHouse的稀疏索引不是為每一行資料建立一個索引條目，而是為一組資料行Granular（稱為顆粒）構建一個索引條目。上圖顯示了官方如何將表中的887萬行(列值)組織成1083個顆粒，每個顆粒對應主索引的一個條目，主索引被用來選擇顆粒，就可以在主索引的支援下執行查詢。
primary.idx 作為主鍵(稀疏)索引，可以用以加速查詢，mrk2 檔案作用類似主鍵索引，用於定位特定 column(bin檔案) 對應的主鍵行所在的位置。
雖然ClickHouse的稀疏索引特別適用於處理大規模資料集，但ClickHouse資料庫可能並不總是最適合時序資料的場景。例如，時序資料通常需要對時間序列進行特定的最佳化，如時間序列索引、視窗函式和時間序列聚合，這些可能在ClickHouse中不如專門的時序資料庫那樣得到最佳化。此外，時序資料的寫入模式可能與ClickHouse的最佳化方向不完全一致，特別是在需要高吞吐量寫入時。
openGemini結合了AP資料庫優勢與時序資料庫特性，更加平衡高效
儘管如此，ClickHouse的稀疏索引技術仍然值得借鑑。透過將這種技術應用於時序資料庫，可以更有效地管理時間線資料，減少記憶體空間的使用，同時保持快速的查詢效能。因此，在openGemini在解決高基數問題時，考慮結合AP資料庫的優勢和專門的時序資料庫特性，提供一個更加平衡和高效的解決方案。
openGemini 列存引擎解決該問題的核心思路主要包括：
-
調整資料排序與索引方式：不再維護與時間線的關係，而是透過設定排序鍵對資料進行排序，在此基礎上，將資料按列儲存，並構建稀疏的聚簇索引，以支援資料的過濾查詢。
-
量化操作降低高基數列的基數：針對高基數列進行量化，以降低基數，這樣可以進一步提高資料的區域性有序性，提升索引的查詢過濾效果。
-
相容 Apache Arrow Flight 協議：Apache Arrow Flight 是一種列式資料傳輸協議，可以實現高效的資料傳輸和寫入。openGemini 利用該協議，消除了資料在寫入流程中的轉換開銷，從而提升了資料寫入效能。
假設有如下資料：
其中 A、C的基數較低，同時大部分查詢需要對 A、C、Time 等列進行過濾，那麼可以考慮將排序鍵設定為 A, C, Time 等，資料按照排序鍵排序之後變成：
排序完成之後，將資料按列儲存，儲存時以若干行(如 8192 行)為一個 Block 進行資料壓縮並序列化，在此基礎上，選取每個 Block 的第一條記錄構建稀疏的聚簇索引。
可以看到，按照這種方式組織資料，位於第一個排序鍵的列是整體有序的，位於其他位置的排序鍵則是區域性有序的，因此如果將低基數列放在排序鍵的前面，則可以使得資料的區域性有序性更好，在此基礎上，上述的稀疏聚簇索引就可以較好反映若干行或者一個 Block 的資料範圍，進而有效支援資料過濾。
考慮到如果有多個列都包含有高基列，那麼無論如何選擇排序鍵，資料的有序性可能都不會特別理想，在這種情況下，可以考慮對其中部分高基列進行量化操作，降低該列的基數，以時間列為例，假設原始資料是以秒級進行採用生成的，那麼即使僅考慮一個小時內的資料，時間列的基數都可能是數以千計，如果將時間列進行量化，使其對齊到小時粒度，那麼這一個小時內的時間列基數就會降到1或者2，在這一基礎上，使用量化過的時間列進行排序，無論將時間列放在排序鍵的哪個位置，都不會使得資料有序性劣化。同理，可以對需要排序的列進行類似的量化操作，這樣就可以保證資料的整體有序性。
總體而言，openGemini 透過上述資料排序與索引方式，可以保證索引的構建不受時間線的影響， 同時資料的有序性也可以保證索引的查詢過濾效果。同時在此基礎上， openGemini 也透過相容 Apache Arrow Flight 協議，一種列式資料傳輸協議，消除了資料在寫入流程中的轉換開銷，極大提升了資料寫入效能。
openGemini在華為雲網路運維業務的實踐
華為雲網路運維服務的核心是基於廣域網運維業務場景，提供基於運維訴求的測量資料，包括真實業務流RTT時延、丟包率、異常測量指標等，以實現對網路頻寬的精準測量和實時分析。
華為雲網路運維業務是一個典型的高基數場景，具有千億級時間線規模。業務透過Agent採集透過裝置的實時流量、實時流源目的地址、RTT時延等資訊，以方便平臺進行異常流分析、資料視覺化分析等。
openGemini列存引擎（HCSE）成功解決了網路資料的高基數問題，為平臺構築了海量網流實時資料儲存底座，相比原有解決方案，實現了端到端成本降低60%。資料處理吞吐量提升6+倍，資料分析效能（如Group By分組聚合分析）提升10+倍。
總結和展望
openGemini 透過引入新的資料排序與索引方式，開發了全新列存引擎，以解決海量時間線場景對於現有時序資料管理方案帶來的問題。透過調整資料排序與索引方式，採用量化操作降低高基數列的基數，以及相容 Apache Arrow Flight 協議等措施，成功解決了海量時間線資料管理中的記憶體膨脹、索引構建成本高等問題。這一創新提高了資料管理的效率和效能，為時序資料應用場景帶來了新的解決方案。
透過全新列存引擎以及已有的時序引擎，openGemini 可以很好解決不同場景下的指標資料管理問題，未來 openGemini 還會針對日誌、呼叫鏈等資料提供儲存解決方案，以實現對可觀測性資料的統一管理，為上層應用實現可觀測性提供一個統一儲存底座。
華為開發者空間是為全球開發者打造的專屬開發者空間，致力於為每位開發者提供一臺雲主機、一套開發工具和雲上儲存空間。匯聚昇騰、鴻蒙、鯤鵬、GaussDB、尤拉等各項根技術的開發資源及工具，總有一款適合你！ 點選連結：領取您的專屬開發者雲主機！
點選關注，第一時間瞭解華為雲新鮮技術~