Hologres揭祕：雲原生存儲引擎

Hologres（中文名交互式分析）是阿里雲自研的一站式實時數倉，這個雲原生系統融合了實時服務和分析大數據的場景，全面兼容PostgreSQL協議並與大數據生態無縫打通，能用同一套數據架構同時支持實時寫入實時查詢以及實時離線聯邦分析。它的出現簡化了業務的架構，與此同時爲業務提供實時決策的能力，讓大數據發揮出更大的商業價值。從阿里集團誕生到雲上商業化，隨着業務的發展和技術的演進，Hologres也在持續不斷優化核心技術競爭力，爲了讓你們更加了解Hologres，咱們計劃持續推出Hologers底層技術原理揭祕系列，從高性能存儲引擎到高效率查詢引擎，高吞吐寫入到高QPS查詢等，全方位解讀Hologers，請你們持續關注！
往期精彩內容：
2020年VLDB的論文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》

本期咱們將介紹Hologers的存儲引擎

1、背景介紹

MaxCompute 交互式分析（Hologres）是阿里雲自研開發的HSAP（Hybrid Serving/ Analytical Processing）服務/分析一體化系統 ，融合了實時服務和分析大數據的場景，全 面兼容PostgreSQL協議並與大數據生態無縫打通。它的出現簡化了業務的架構，與此同時爲 業務提供實時作出決策的能力，讓大數據發揮出更大的商業價值。關於架構更詳細的介紹， 請看文末VLDB論文 。

跟傳統的大數據和OLAP系統相比，HSAP系統面臨着以下的挑戰：

• 高併發的混合工做負載：HSAP系統須要面對遠遠超出傳統的OLAP系統的併發查詢。在實踐中，數據服務的併發遠遠超出OLAP的查詢。例如，咱們在現實的應用中見到數據服務須要處理高達每秒鐘數千萬個查詢，這比OLAP查詢的併發高出了5個數量級。同時，和OLAP查詢相比，數據服務型查詢對延遲有着更加苛刻的要求。複雜的混合查詢負載對系統的延遲和吞吐有着很是不一樣的取捨。如何在高效地利用系統的資源同時處理好這些很是不 同樣的查詢，而且保證每一個查詢的SLO是個巨大的挑戰。
• 高吞吐實時數據導入：在處理高併發的查詢負載的同時，HSAP系統還須要處理海量的實時數據導入。從傳統的OLTP同步過來的數據只是這其中的一小部分，其餘還有大量的數據來自日誌等沒有強事務語意的系統。實時導入的數據量遠遠超過了傳統的HTAP或者OLAP系統。和傳統的OLAP系統的另一個區別是對數據的實時性有着很高的要求，導入的數據須要在秒級甚至亞秒級可見，這樣才能保證咱們服務和分析結果的時效性。
• 彈性和可擴展性：數據導入和查詢負載可能會有突發的高峯，這對HSAP系統提出了很高的彈性和可擴展性的要求。在現實的應用中，咱們注意到數據導入峯值能達到是平均的2.5倍，查詢的峯值可能達到平均的3倍。數據導入和查詢的峯值可能不必定同時出現，這也須要系統有根據不一樣的峯值作迅速調整的能力。

基於上訴背景，咱們自研了一款存儲引擎（Storage Engine），主要負責管理和處理數據， 包括建立，查詢，更新，和刪除（簡稱 CRUD）數據的方法。存儲引擎的設計和實現提供了HSAP場景所須要的高吞吐，高併發，低延遲，彈性化，可擴展性的能力。根據阿里集團業務和雲上客戶的需求，咱們不斷創新和打磨，發展到今天，能支持單表PB級存儲，並完美支撐2020年天貓雙11核心場景千億個級別的點查詢和千萬個級別的實時複雜查詢 。

下面，咱們將會對Hologres底層的存儲引擎作詳細的介紹，並介紹存儲引擎落地Hologres的具體實現原理和技術亮點。

2、數據模型

Hologres存儲引擎的基本抽象是分佈式的表，爲了讓系統可擴展，咱們須要把表切分爲 分片（shard）。 爲了更高效地支持Join以及多表更新等場景，用戶可能須要把幾個相關的 表存放在一塊兒，爲此Hologres引入了表組（Table Group）的概念。分片策略徹底同樣的一 組表就構成了一個表組，同一個表組的全部表有一樣數量的分片。用戶能夠經過 「shard_count」來指定表的分片數，經過「distribution_key」來指定分片列。目前咱們只支持Hash的分片方式。

表的數據存儲格式分爲兩類，一類是行存表，一類是列存表，格式能夠經過「orientation"來指定。

每張表裏的記錄都有必定的存儲順序，用戶能夠經過「clustering_key"來指定。若是沒有指定排序列，存儲引擎會按照插入的順序自動排序。選擇合適的排序列可以大大優化一些查詢的性能。

表還能夠支持多種索引，目前咱們支持了字典索引和位圖索引。用戶能夠經過「dictionary_encoding_columns"和「bitmap_columns"來指定須要索引的列。

下面是一個示例：

這個例子建了LINEITEM和ORDERS兩個表，因爲LINEITEM表還指定了主鍵（PRIMARY KEY），存儲引擎會自動創建索引來保證主鍵的惟一。用戶經過指定「colocate_with「把這兩個表放到了同一個表組。這個表組被分紅24個分片（由shard_count指定）。 LINEITEM將根據L_ORDERKEY的數據值來分片，而ORDERS將根據O_ORDERKEY的數據值來分片。LINEITEM的L_SHIPINSTRUCT以及ORDERS的O_ORDERSTATUS字段將會建立字典。LINEITEM的L_ORDERKEY, L_LINENUMBER, L_SHIPINSTRUCT字段以及ORDERS的O_ORDERKEY,O_CUSTKEY,O_ORDERSTATUS字段將會建立位圖索引。

3、存儲引擎架構

1）整體架構

每一個分片（Table Group Shard， 簡稱Shard）構成了一個存儲管理和恢復的單元 （Recovery Unit）。上圖顯示了一個分片的基本架構。一個分片由多個tablet組成，這些tablet會共享一個日誌（Write-Ahead Log，WAL）。存儲引擎用了Log-Structured Merge （LSM）的技術，全部的新數據都是以append-only的形式插入的。 數據先寫到tablet所在的內存表 (MemTable)，積累到必定規模後寫入到文件中。當一個數據文件關閉後，裏面的內容就不會變了。新的數據以及後續的更新都會寫到新的文件。 與傳統數據庫的B±tree數據結構相比，LSM減小了隨機IO，大幅的提升了寫的性能。

當寫操做不斷進來，每一個tablet裏會積累出不少文件。當一個tablet裏小文件積累到必定數量時，存儲引擎會在後臺把小文件合併起來 （Compaction），這樣系統就不須要同時打開不少文件，能減小使用系統資源，更重要的是合併後文件減小了，提升了讀的性能。

在DML的功能上，存儲引擎提供了單條或者批量的建立，查詢，更新，和刪除（CRUD操做）訪問方法的接口，查詢引擎能夠經過這些接口訪問存儲的數據。

2）存儲引擎組件

下面是存儲引擎幾個重要的的組件：

• WAL 和WAL Manager
  WAL Manager是來管理日誌文件的。存儲引擎用預寫式日誌(WAL) 來保證數據的原子性 和持久性。當CUD操做發生時，存儲引擎先寫WAL，再寫到對應tablet的MemTable中，等 到MemTable積累到必定的規模或者到了必定的時間，就會把這個MemTable切換爲不可更改的flushing MemTable， 並新開一個 MemTable接收新的寫入請求。 而這個不可更改的flushing MemTable就能夠刷磁盤，變成不可更改的文件； 當不可更改的文件生成後，數據就能夠算持久化。 當系統發生錯誤崩潰後，系統重啓時會去WAL讀日誌，恢復尚未持久化 的數據。 只有當一個日誌文件對應的數據都持久化後，WAL Manager纔會把這個日誌文件 刪除。
• 文件存儲
  每一個tablet會把數據存在一組文件中，這些文件是存在DFS裏 （阿里巴巴盤古或者Apache HDFS ）。 行存文件的存儲方式是Sorted String Table（SST） 格式。 列存文件支持兩種存儲格式： 一種是相似PAX的自研格式， 另一種是改進版的Apache ORC格式 （在AliORC的基礎上針對Hologres的場景作了不少優化）。 這兩種列存格式都針對文件掃描的場景作了優化。
• Block Cache (Read Cache)
  爲了不每次讀數據都用IO到文件中取，存儲引擎經過BlockCache把經常使用和最近用的數據放在內存中，減小沒必要要的IO，加快讀的性能。在同一個節點內，全部的Shard共享一個Block Cache。 Block Cache有兩種淘汰策略： LRU （Least Recently Used，最近最少使用） 和 LFU （Least Frequently Used, 最近不經常使用）。 顧名思義，LRU算法是首先淘汰最長時間未被使用的Block，而LFU是先淘汰必定時間內被訪問次數最少的Block。

3）讀寫原理

Hologres支持兩種類型的寫入：單分片寫入和分佈式批量寫入。兩種類型的寫入都是原子的（Atomic Write)，即寫入或回滾。單分片寫入一次更新一個shard，可是須要支持極高 的寫入頻率。另外一方面，分佈式批寫用於將大量數據做爲單個事務寫到多個shard中的場景， 而且一般以低得多的頻率執行。

單分片寫入

如上圖所示，WAL管理器在接收到單分片寫請求後，（1）爲寫請求分配一條Log Sequence Number （LSN），這個LSN是由時間戳和遞增的序號組成，而且（2）建立一條新的日誌，並在文件系統中的持久化這條日誌。這條日誌包含了恢復寫操做所需的信息。在徹底保留這條日誌後，才向tablet提交寫入。以後，（3）咱們會在相應tablet的內存表（MemTable) 中執行這個寫操做，並使其對新的讀請求可見。值得注意的是，不一樣tablet上的更新能夠並行化。當一個MemTable滿了之後，（4）將其刷新到文件系統中，並初始化一個新的MemTable。最後，（5）將多個分片文件在後臺異步合併（Compaction）。在合併或MemTable刷新結束時，管理tablet的元數據文件將相應更新。

分佈式批量寫入

接收到寫入請求的前臺節點會將寫請求分發到全部相關的分片。這些分片經過兩階段提交機制（Two Phase Commit) 來保證分佈式批量寫入的寫入原子性。

多版本讀

Hologres支持在tablet中多版本讀取數據。讀請求的一致性是read-your-writes，即客戶端始終能看到本身最新提交的寫操做。每一個讀取請求都包含一個讀取時間戳，用於構造讀的snapshot LSN。若是有一行數據的LSN大於snapshot LSN的記錄， 這行數據就會被過濾掉， 由於他是在讀的snapshot產生後才被插入到這個tablet的。

四. Hologres存儲引擎技術亮點

1）存儲計算分離

存儲引擎採用存儲計算分離的架構，全部的數據文件存在一個分佈式文件系統（DFS, 例如阿里巴巴盤古或者Apache HDFS）的裏面。當查詢負載變大須要更多的計算資源的時候能夠單獨擴展計算資源； 當數據量快速增加的時候能夠快速單獨擴展存儲資源。計算節點和存儲節點能夠獨立擴展的架構保證了不須要等待數據的拷貝或者移動就能快速擴展資源； 並且，能夠利用DFS存多副本的機制保證數據的高可用性。 這種架構不但極大地簡化了運維，並且爲系統的穩定性提供了很大的保障。

2）異步執行流程

存儲引擎採用了基於事件觸發, 非阻塞的純異步執行架構, 這樣可以充分發揮現代CPU多core的處理能力，提升了吞吐量， 支持高併發的寫入和查詢。這種架構得益於HOS（HoloOS) 框架，HOS在提供高效的異步執行和併發能力的同時，還能自動地作CPU的負載均衡提高系統的利用率。

3）統一的存儲

在HSAP場景下，有兩類查詢模式，一類是簡單的點查詢（數據服務Serving類場景），另外一類是掃描大量數據的複雜查詢（分析Analytical類場景）。 固然，也有不少查詢是介於二者之間的。這兩種查詢模式對數據存儲提出了不一樣的要求。行存可以比較高效地支持點查詢，而列存在支持大量掃描的查詢上有明顯的優點。

爲了可以支持各類查詢模式，統一的實時存儲是很是重要的。存儲引擎支持行存和列存的存儲格式。根據用戶的需求，一個tablet能夠是行存的存儲格式 （適用於Serving的場景）； 也能夠是列存的存儲格式（適用於Analytical的場景）。 好比，在一個典型HSAP的場景，不少用戶會把數據存在列存的存儲格式下，便於大規模掃描作分析；與此同時，數據的索引存在行存的存儲格式下，便於點查。並經過定義primary key constraint （咱們是用行存來實現的）用來防止數據重複·。無論底層用的是行存仍是列存，讀寫的接口是同樣的，用戶沒有感知，只在建表的時候指定便可。

4）讀寫隔離

存儲引擎採用了snapshot read的語意，讀數據時採用讀開始時的數據狀態，不須要數據鎖，讀操做不會被寫操做block住； 當有新的寫操做進來的時候，由於寫操做是append-only，全部寫操做也不會被讀操做block住。這樣能夠很好的支持HSAP的高併發混合工做負載場景。

5）豐富的索引

存儲引擎提供了多種索引類型，用於提高查詢的效率。一個表能夠支持clustered index 和non-clustered index這兩類索引。一個表只能有一個clustered index， 它包含表裏全部的列。一個表能夠有多個non-clustered indices。在non-clustered indexes裏，除了排序用的non-clustered index key外，還有用來找到全行數據的Row Identifier (RID)。 若是clustered index存在， 並且是獨特的，clustered index key就是RID； 不然存儲引擎會產生一個獨特的RID。 爲了提升查詢的效率，在non-clustered index中還能夠有其餘的列， 這樣在某些查詢時，掃一個索引就能夠拿到全部的列的值了 （covering index)。

在數據文件內部，存儲引擎支持了字典和位圖索引。字典能夠用來提升處理字符串的效率和提升數據的壓縮比，位圖索引能夠幫助高效地過濾掉不須要的記錄。

五. 結語

存儲引擎的設計思路和研發方向是爲了更好的支持HSAP的場景，能高效的支持高吞吐的實時寫入和交互式查詢，並且對離線的批量寫入作了優化。在寫入量和存儲量每一年都成倍的增加下，Hologres經受住了嚴苛的考驗，完美地度過了多個雙11。 「Hologres頂住了5.96億每秒的實時數據洪峯，單表存儲高達2.5PB。基於萬億級數據對外提供多維分析和服務，99.99%的查詢能夠在80ms之內返回結果」。這組數據充分顯示了存儲引擎的技術能力， 同時也印證了咱們技術架構和實現的優點。

固然，Hologres仍是一個新產品，HSAP是個新理念， 「今天的最好只是明天的開始」， 咱們還在不斷地精益求精，聆聽客戶的反饋，從此會在穩定性，易用性，以及功能和性能上持續提高。

做者：江淵，阿里巴巴資深技術專家，在數據庫和大數據領域有多年豐富的經驗。

後續咱們將會陸續推出有關Hologres的技術底層原理揭祕系列，具體規劃以下，敬請持續關注！

Hologres揭祕：首次公開！阿里巴巴雲原生實時數倉核心技術揭祕Hologres揭祕：首次揭祕雲原生Hologres存儲引擎（本文）Hologres揭祕：深度解析高效率分佈式查詢引擎Hologres揭祕：透明加速MaxCompute查詢核心原理Hologres揭祕：如何實現MaxCompute與Hologres數據同步速度快百倍Hologres揭祕：如何支持高吞吐UpsertHologres揭祕：如何支持在線服務場景的超高QPSHologres揭祕：如何支持高併發查詢Hologres揭祕：如何支持高可用架構Hologres揭祕：如何支持資源隔離，支持多種負載Hologres揭祕：向量檢索引擎Proxima原理與使用實踐Hologres揭祕：讀懂執行計劃，查詢性能翻十倍Hologres揭祕：分佈式系統如何設計Shard與Table GroupHologres揭祕：如何支持更多Postgres生態擴展包Hologres揭祕：高吞吐寫入Hologres的N種姿式......