Hologres揭秘：如何支援超高QPS線上服務（點查）場景

簡介：

本期我們將揭秘Hologres如何支援超高QPS線上服務（點查）場景。

Hologres（中文名互動式分析）是阿里雲自研的一站式實時數倉，這個雲原生系統融合了實時服務和分析大資料的場景，全面相容PostgreSQL協議並與大資料生態無縫打通，能用同一套資料架構同時支援實時寫入實時查詢以及實時離線聯邦分析。它的出現簡化了業務的架構，為業務提供實時決策的能力，讓大資料發揮出更大的商業價值。從阿里集團誕生到雲上商業化，隨著業務的發展和技術的演進，Hologres也在持續不斷最佳化核心技術競爭力，為了讓大家更加了解Hologres，我們計劃持續推出Hologres底層技術原理揭秘系列，從高效能儲存引擎到高效率查詢引擎，高吞吐寫入到高QPS查詢等，全方位解讀Hologres，請大家持續關注！

往期精彩內容：

2020年VLDB的論文《Alibaba Hologres： A cloud-Native Service for Hybrid Serving/Analytical Processing》

Hologres揭秘：首次公開！阿里巴巴雲原生實時數倉核心技術揭秘

Hologres揭秘：首次揭秘雲原生Hologres儲存引擎

Hologres揭秘：Hologres高效率分散式查詢引擎

Hologres揭秘：高效能原生加速MaxCompute核心原理

Hologres揭秘：最佳化COPY，批次匯入效能提升5倍+

本期我們將揭秘Hologres如何支援超高QPS點查。

傳統的 OLAP 系統在業務中往往扮演著比較靜態的角色，以透過分析海量的資料得到業務的洞察（比如說預計算好的檢視、模型等），從這些海量資料分析到的結果再透過另外一個系統提供線上資料服務（比如HBase、Redis、MySQL等）。這裡的服務（Serving）和分析（Analytical）是個割裂的過程。與此不同的是，實際的業務決策過程往往是一個持續最佳化的線上過程。服務的過程會產生大量的新資料，我們需要對這些新資料進行復雜的分析。分析產生的洞察實時反饋到服務，讓業務的決策更實時，從而創造更大的商業價值。

Hologres定位是一站式實時數倉，融合分析能力（Analytical）與線上服務（Serving）為一體，減少資料的割裂和移動。本文的內容將會針對Hologres的服務能力（核心為點查能力），介紹Hologres到底具備哪些服務能力，以及背後的實現原理。

通常我們所說的點查場景是指Key/Value查詢的場景，廣泛用於線上服務。由於點查場景的廣泛需求，市場上存在多種KV資料庫定位於支援高吞吐、低延時的點查場景，例如被大家廣而熟知的HBase，它透過自定義的一套API來提供點查的能力，在許多業務場景都能夠獲得較好的效果。但是HBase在實際使用中也會存在一定的缺點，這也使得很多業務從HBase遷移至Hologres，主要有以下幾點：

當資料規模大到一定程度的時候，HBase在效能方面將會有所下降，無法滿足大規模的點查計算，同時在穩定性上也變得不如人意，需要有經驗的運維支援

HBase提供的是自定義API，上手有一定的成本。Hologres直接透過SQL提供高吞吐、低延時的點查服務。相比於其它KV系統提供自定義API，SQL介面無疑更加的簡單易用。

HBase採用Schema Free設計，沒有資料型別，對於檢查資料質量，修正資料質量也帶來了複雜度，查錯難，修正難。Hologres具備與Postgres相容的幾乎所有主流資料型別，可以透過Insert/Select/Update/Delete標準SQL語句對資料進行檢視、更新。

在Hologres中的點查場景是指行存表基於主鍵（PK）的查詢。

——建行存表BEGIN；CREATE TABLE public。holotest （ “a” text NOT NULL， “b” text NOT NULL， “c” text NOT NULL， “d” text NOT NULL， “e” text NOT NULL，PRIMARY KEY （a，b））；CALL SET_TABLE_PROPERTY（‘public。holotest’， ‘orientation’， ‘row’）；CALL SET_TABLE_PROPERTY（‘public。holotest’， ‘time_to_live_in_seconds’， ‘3153600000’）；COMMIT；—— Hologres透過SQL進行點查select * from table where pk = ？； —— 一次查詢單個點select * from table where pk in （？，？，？，？，？）； —— 一次查詢多個點

點查場景技術實現難點

正常情況下，一條SQL語句的執行，需要經過SQL Parser進行解析成AST（抽象語法樹），再由Query Optimizer處理生成Plan（可執行計劃），最終透過執行Plan拿到計算結果。而要想透過SQL做到高吞吐、低延時、穩定的點查服務，則必須要克服如下困難：

在不破壞PostgreSQL生態的情況下，SQL介面如何做到高QPS？

如何做低甚至避免SQL解析與最佳化器的開銷

一套高效的Client SDK如何與後端儲存進行互動？

如何在低消耗的情況下，做到高併發的互動

如何減少訊息傳遞過程中的開銷

如何感知後端的壓力、配合做到最好的吞吐與延遲

後端儲存如何在高效能的情況下更加穩定？

如何最大化利用cpu資源

如何減少各種記憶體的分配與複製、避免熱點key等問題對系統帶來的不穩定性

如何減少冷資料IO的影響

在克服上述3大類困難後，整體的工作方式就可以非常的簡潔：在接入層（FrontEnd）上直接透過Client SDK與後端儲存通訊。

下面將會介紹Hologres是如何克服以上3大困難，從而實現高吞吐低延時的點查。

降低、避免SQL解析與最佳化器的開銷

Query Optimizer進行Short Cut

由於點查的Query足夠簡單，Hologres的Query Optimizer進行了相應的short cut，點查Query並不會進入Opimizer的完整流程。Query進入FrontEnd後它會交由Fixed Planner進行處理，並由其生成對於的Fixed Plan（點查的物理Plan），Fixed Planner非常輕，無需經過任何的等價變換、邏輯最佳化、物理最佳化等步驟，僅僅是基於AST樹進行了一些簡單的分析並構建出對應的Fixed Plan，

從而儘量規避掉最佳化器的開銷。

Prepared Statement

儘管Query Optimizer對點查Query進行了short cut，但是Query進入到FrontEnd後的解析開銷依然存在、Query Optimizer的開銷也沒有完全避免。

Hologres相容Postgres，Postgres的前、後端通訊協議有extended協議與simple協議兩種：

simple協議：是一次性互動的協議，Client每次會直接傳送待執行的SQL給Server，Server收到SQL後直接進行解析、執行，並將結果返回給Client。simple協議裡Server無可避免的至少需要對收到的SQL進行解析才能理解其語義。

extended協議：Client與Server的互動分多階段完成，整體大致可以分成兩大階段。

第一階段：Client在Server端定義了一個帶名字的Statement，並且生成了該Statement所對應的generic plan（不與特定的引數繫結的通用plan）。

第二階段：使用者透過傳送具體的引數來執行第一階段中定義的Statement。第二階段可以重複執行多次，每次透過帶上第一階段中所定義的Statement名字，以及執行所需要的引數，使用第一階段生成的generic plan進行執行。由於第二階段可以透過Statement名字和附帶的引數來反覆執行第一個階段所準備好的generic plan，因此第二個段在Frontend的開銷幾乎等同於0。

為此Hologres基於Postgres的extended協議，支援了Prepared Statement，做到了點查Query在Frontend上的開銷接近於0。

高效能的內部通訊

BHClient是Hologres實現的一套用於與後端儲存直接通訊的高效Private Client SDK，主要有以下幾個優勢：

1）Reactor模型、全程無鎖的非同步操作

BHClient工作方式類似reactor模型，每個目標shard對應一個eventloop，以“死迴圈”的方式處理該shard上的請求。由於HOS對排程執行單元的抽象，即使是shard很多的情況下，這種工作方式的基礎消耗也足夠低。

2）高效的資料交換協議binary row

透過自定義一套內部的資料通訊協議binary row來減少整個互動鏈路上的記憶體的分配與複製。

3）反壓與湊批

BHClient可以感知後端的壓力，進行自適應的反壓與湊批，在不影響原有Latency的情況下提升系統吞吐。

穩定可靠的後端儲存

1）LSM（Log Structured Merge Tree）

Hologres的行存表採取LSM進行儲存，相比於傳統的B+樹，LSM能夠提供更高的寫吞吐，因為它不會出現任何的隨機寫，Append Only的操作保證了其只會順序的寫盤。

一個行存tablet上會存在一個memtable，和多個immutable memtable。

資料更新都會寫入到memtable中，當memtable寫滿後會轉變為immtable memtable，immutable memtable會Flush成Key有序的SST（Sorted String Table）檔案，SST檔案一旦生成則不能修改，因此不會發生隨機寫的操作。

SST檔案在檔案系統裡面按層組織，除了level 0上的SST檔案間無序，且存在overlap外，其它level上的SST檔案間有序，且無overlap。因此查詢的時候，對於level 0上的檔案需要逐個遍歷，而其它level的檔案可以二分查詢。底層的SST檔案透過Compaction成新的SST檔案去到更高層，因此低層的資料要比高層的新，所以一旦在某層上找到了滿足條件的key則無需往更高層去查詢。

2）基於C++純非同步的開發

採用LSM對資料進行組織儲存的系統並不僅僅只有Hologres，LSM在谷歌的“BigTable”論文中被提出後，很多的系統都對其進行了借鑑採用，例如HBase。Hologres採用C++進行開發，相較於Java，native語言使得我們能夠追求到更極致的效能。同時基於HOS（Hologres Operation System）提供的非同步介面進行純非同步開發，HOS透過抽象ExecutionContext來自我管理CPU的排程執行，能夠最大化的利用硬體資源、達到吞吐最大化。

3）IO最佳化與豐富的Cache機制

Hologres實現了非常豐富的Cache機制row cache、block cache、iterator cache、meta cache等，來加速熱資料的查詢、減少IO訪問、避免新記憶體分配。當無可避免的需要發生IO時，Hologres會對併發IO進行合併、透過wait/notice機制確保只訪問一次IO，減少IO處理量。透過生成檔案級別的詞典及壓縮，減少檔案物理儲存成本及IO訪問。

總結

Hologres致力於一站式實時數倉，除了具備處理複雜OLAP分析場景的能力之外，還支援超高QPS線上點查服務，透過使用標準的Postgres SDK介面，就能透過SQL獲得低延時、高吞吐的線上服務能力，簡化學習成本，提升開發效率。

作者：周思華（花名：思召），阿里巴巴技術專家，現從事互動式分析引擎Hologres研發工作。

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

Hologres揭秘：首次公開！阿里巴巴雲原生實時數倉核心技術揭秘

Hologres揭秘：首次揭秘雲原生Hologres儲存引擎

Hologres揭秘：深度解析高效率分散式查詢引擎

Hologres揭秘：高效能原生加速MaxCompute核心原理

Hologres揭秘：最佳化COPY，批次匯入效能提升5倍+

Hologres揭秘：如何支援超高QPS線上服務（點查）場景

Hologres揭秘：如何支援高吞吐Upsert

Hologres揭秘：如何支援高併發查詢