說明：
本文基于SIGMOD 2018的論文《RAPID: In-Memory Analytical Query Processing Engine with ExtremePerformance per Watt》整理而成。
MySQL HeatWave使用的引擎，即為RAPID引擎。
一介紹
目前正處于資料量急速膨脹的時代，而大資料時代又決定了資料處理系統的硬體和軟體的發展。現代企業對日常分析和商業智能類工作負載的要求，則強調了當今的IT系統在性能和功耗方面的局限性。為了應對這一趨勢，現代資料處理系統需要重新思考軟體設計和底層硬體的支援。而不是通過将軟體和硬體隔離的方式來設計現代的資料處理系統。
縱觀硬體的格局，可以看到，越來越多的半導體被用于更多的處理核心、大型緩存、新的指令集以及其它進階功能。主存儲器的成本也在不斷降低。是以，現有的資料處理系統可以通過利用硬體的最新進展來提供更高的性能。遵循硬體的設計邏輯，系統需要通過更高的并行度、更大的緩存，以及更多針對互聯的資料放置，和先進的矢量處理，進而進行擴充，以實作更高的絕對性能。
一般來說，當今的商用硬體，往往是針對通用業務提供最佳性能。是以，硬體雖然會增加功耗和複雜性，但是不一定就能夠為特定應用提供最佳的性能表現。而這往往隻會增加現代雲資料中心的性能/電源要求的挑戰。對于現代的雲資料中心而言，系統除了能夠提供高性能之外，還需要有功耗意識。
而從曆史上看，資料處理系統的設計，是由商業硬體驅動的。其目标為，通過相應地調整軟體設計來利用新的硬體性能。但是，我們也可以用相反的方式來思考這個問題：硬體應該如何為資料處理進行量身定制？高效的關系型資料處理，究竟需要哪些功能？同樣，為了降低功耗和讓處理器設計更簡單，哪些不必要的功能又是可以放棄的？對以上問題進行回答，就可以将硬體設計進行收斂，進而緊密內建軟體和硬體，以進行高效的資料處理。由于是從頭開始重新設計架構，并能夠充分考慮軟硬體協同，是以就能夠提供極緻的查詢執行性能，并為分析處理帶來至少一個數量級的性能提升。
RAPID查詢處理引擎，與被稱之為資料處理單元（Data Processing Unit，DPU）的新處理器共同設計。DPU由32個被稱之為dpCore的低功耗處理器核心組成。dpCore是一個簡單的有序CPU，具有簡單的分支預測功能、16KB的SRAM緩存，以及32KB的SRAM暫存器。每個dpCore均可以執行簡單的類MIPS指令，且具有為資料庫處理量身定制的單指令周期延遲。DPU并非緩存一緻的，與DRAM之間的傳輸，是使用了稱之為DMS的資料移動系統來明确程式設計實作的。DMS是資料shuffle和分區的核心，且無dpCore的參與。從本質上來說，DPU抛棄了許多複雜的元件，例如大型緩存、複雜的分支預測器、進階指令，以及緩存一緻性，進而能夠以更低的功耗和更小的尺寸來處理資料。
RAPID是一種關系型查詢處理引擎，旨在支援現代的分析型工作負載，與現有的資料庫系統相比，它更強調在低功耗的情況下的查詢性能。RAPID是可插拔的，可以附加到OCI MySQL資料庫雲服務（MDS）以解除安裝分析類查詢。
二RAPID DPU架構
RAPID DPU是一種低功耗、可程式設計的處理單元，專門被設計用來在40nm制造技術下以5.8W的額定功率來加速資料處理。每個處理核心在800MHz下消耗51mW的動态功率。DPU的主要設計目标，是通過硬體設計，來加速處理分析類工作負載。
圖1 RAPID DPU架構圖
2.1 dpCore
DPU包含32個資料處理核心（dpCore），采用簡單低功耗設計，可以協同實作資料并行性。dpCore被組織成4個宏，每個宏包含8個核心。dpCore使用了面向通用計算的64位MIPS類指令集架構（ISA）。為了加速分析類查詢運算符（例如選擇，連接配接等），ISA提供了單周期指令，例如位矢量加載（Bit-Vector Load，BVLD），過濾器（Filter，FLT），以及哈希碼生成（CRC32）等。
dpCore實作了一個簡單的雙流水線，一個用于算術邏輯單元（Arithmetic Logic Unit，ALU），另外一個用于加載存儲單元（Load-store Unit，LSU）。ALU支援低功耗乘法器，該乘法器可以将流水線分隔為多個指令周期，但是不支援浮點運算。doCore使用了一個簡單的分支預測器來預測反向分支。記憶體處理模型則比較寬松，帶有隔離挂起加載以及存儲相關的指令。doCore沒有記憶體管理單元，采用直接尋址方式。
2.2 DMEM與緩存
每個dpCore都包含一個32KB的SRAM暫存器，稱之為資料存儲器，簡稱為DMEM。DMEM主要負責dpCore的單周期延遲，以及快速臨時的存儲。由軟體進行管理。
dpCore也支援通用的緩存分層結構，包含私有的16KB L1-D緩存，以及8KB的L1-I緩存。同時在宏内部，dpCore之間也共享256KB的L2緩存。為了降低晶片的複雜度和功耗，硬體不負責緩存之間的資料一緻性。相反，ISA則為軟體管理的一緻性提供了緩存重新整理和無效指令。
2.3資料移動系統（DMS）
RAPID DPU具備DMS這一片上可程式設計資料移動引擎，用于在DRAM和dpCore之間移動資料。大多數的資料通路，都是使用DMS來通過DMEM的。與使用CPU緩存和硬體預存器的傳統方法相比，DMS更節能，并且可以處理不規則的資料通路模式。DMS支援在傳輸資料時涉及水準hash/範圍分區，以及分散/聚集的複雜通路模式。DMS能夠将資料直接放入DMEM，使得dpCore立即可用，且無需任何開銷。
2.4片上通信
被稱之為原子事務引擎（ATE）的硬體，允許dpCore之間進行通信。ATE包含1個連接配接了8個dpCore和4個宏的2級交叉開關，用于管理消息傳遞，并保證通過該互聯的資料能夠進行點對點的排序。在每個dpCore上，硬體ATE引擎管理DMEM指針并傳遞消息和中斷。ATE使得我們能夠在硬體的支援下進行有效地消息傳遞和原語同步（例如互斥鎖、隔離）。
2.5 DPU總體組織
總而言之，圖1就描繪出了整個RAPID DPU片上系統（SoC）的示意圖。4個dpCore宏，以及DMEM就構成了執行大部分操作的dpCore複合體。此外，SoC還包括一個電源管理單元（PMU或者M0），兩個ARM Cortex-A9雙核處理器、一個郵箱控制器（MBC，MailBox Controller，是一個硬體隊列，用來進行A9、dpCore，以及M0之間的通信），以及一些外圍元件，例如PCIe以及DRAM控制器等。
三RAPID軟體架構
RAPID引擎可以內建到Oracle的OCI MySQL 資料庫雲服務（MDS）上。圖2就描述了這一內建的RAPID進階架構。
圖2 RAPID軟體架構圖
與MySQL內建的主要目标，是能夠在使用者應用或者查詢不做修改的情況下，也可以加速分析類工作負載。是否解除安裝此類操作，則依賴于RAPID所支援的操作，以及在RAPID中所估計的執行成本。查詢的解除安裝部分在RAPID當中執行，結果被發送回MySQL進行進一步的處理。在這裡，MySQL就是RAPID引擎中的資料來源，是以需要将其中的表加載進RAPID當中，并且在源表資料發生變化時，需要将這些更改傳播到RAPID當中。
3.1查詢編譯和優化
MDS的SQL查詢分析器對RAPID使用的成本模型進行了擴充，進而能夠基于成本進行解除安裝決策。MySQL接收SQL查詢，然後進行解析、語義分析、規範化、分解，常量處理，以及數個查詢重寫階段。MDS的執行計劃生成器将會考慮：i)完全解除安裝：隻使用RAPID引擎；ii)部分解除安裝：解除安裝查詢的某些片段；iii)完全不解除安裝。
如果a)RAPID支援某一查詢片段的關系運算符，并且b)該片段中的運算符所使用的表已經被加載進RAPID引擎，則該查詢片段就是解除安裝操作的候選對象。基于成本的優化器采用了自下而上的工作方式。對于每個候選片段，都會考慮RAPID的執行、結果的網絡傳輸，以及後繼處理的累積成本。
一旦執行計劃生成器确定了成本最低的執行計劃，就可以生成查詢的執行計劃（Query ExecutionPlan，QEP）了。并且作為代碼生成的一部分，也将會建構邏輯運算符樹。它通常包含一個或者多個占位符節點，用于标記哪些子樹會被用于RAPID解除安裝。對于占位符節點下的每個子樹，都會執行RAPID編譯（參見5.2小節）。它會在占位符節點中生成、序列化，以及存儲RAPID 的QEP。
3.2查詢執行解除安裝模型
MDS中的執行範例，是基于拉取方式的，并遵循疊代器模式。每個運算符都實作了一組方法：allocate()、start()、fetch()、close()，以及release()。執行自上而下進行，結果自下而上進行傳播。一旦MDS在RAPID運算上調用start()，就會檢查查詢對RAPID的可接受性以確定事務語義（可參見3.3小節）。在成功的準入檢查之後，RAPID QEP将會被發送到每個RAPID的執行節點上。RAPID節點然後執行個體化接收到的QEP并排程執行。
RAPID端的執行，則是基于推送方式的。資料以流式的方式推送到QEP的運算符，當資料從根運算符流出時，則通過網絡進行傳輸，并以RDMA（Remote Direct Memory Access，遠端直接記憶體通路）的方式放入MDS的記憶體緩存區。一旦MDS的RAPID運算符檢索到了資料，就會進行後繼處理，例如解碼或者其他轉換操作等。
如果不滿足接受标準，或者在RAPID當中運作失敗，則RAPID運算符就會報告失敗，或者是退回到MDS生成的替代執行計劃。
注：拉取方式vs推送方式
拉取方式，即pull-based模型（即經典的火山模型）；推送方式，即push-based模型。
推送和拉取兩種模型中，其控制流和資料流的關系如下：
由上圖可知，拉取模型的設計更加符合查詢執行的直覺印象，上層算子按需向下層算子擷取資料并執行。其本質上，就是一層層的虛函數調用。
推送模型則剛好相反，通過将上層的計算下推到資料産生的運算符中，由資料的最終生産者驅動上層運算符對資料進行消費。
推送模式的問題主要是：1）無法使前一步産生的資料由下一步過程直接複用；2）虛函數的調用，會影響CPU的流水線執行（因為分支預測可能會失效），進而影響效率。
3.3一緻的查詢執行
按照事務語義的要求，查詢所依賴的更改，在查詢執行之前，都需要在RAPID引擎中可用。是以，為了滿足這一要求，就需要使用在記憶體日志中收集的事務日志。查詢檢查點，是掃描、編碼并将所有更改從關聯表的記憶體日志發送到RAPID引擎的活動。為了避免在查詢時遇到長時間運作的查詢檢查點，一般可以利用定期的背景程序來掃描和傳播日志中的資料更改。
注：在目前的MySQL HeatWave設定中，将表加載進HeatWave之後，每隔200ms，或者是當資料更改量達到64MB的時候，就會自動觸發背景程序，将這些更改傳播到HeatWave節點上。
此外，如果查詢的系統改變号（SCN）——一個單調遞增的時間戳——不比它所操作的任何表的SCN小，則該查詢就可以被RAPID引擎接受。是以，在送出查詢時，查詢的SCN将會與片段通路的表的SCN進行比較。
3.4網絡與其他元件
RAPID依賴于MDS和OCI對象存儲來實作持久性和故障恢複。如果RAPID節點出現故障，則恢複協定會調出備用的RAPID節點，并使用正确的資料集分區進行加載。在恢複期間，除非有副本，否則無法使用RAPID叢集進行查詢解除安裝。RAPID中繼資料中，包含了有關加載到RAPID中的基表、系統狀态、表統計資訊、分區資訊，以及列的編碼資訊。RAPID節點通過高帶寬的Infiniband網絡進行連接配接。同時，在頂部實作了一個自定義網絡層，進而允許排程動态适應工作負載的網絡傳輸。
四資料與存儲模型
4.1資料與存儲
RAPID将整個資料存儲在主記憶體當中，而可靠性和持久性則由MDS和OCI對象存儲來保證。RAPID引擎中的表，由一個或者多個水準分區組成。每個分區都包含稱之為塊（chunk）的資料水準切片。塊内的資料，是以列式布局存儲的一組表中的行。存儲在塊中的表中的每一列，都稱之為矢量。它是列資料的平面數組。RAPID DPU中的矢量大小的最佳值為16KB，因為這裡啟用了雙緩沖，以及DMS傳輸和計算的overlap。最後，運算符進行資料傳輸的機關為tile，包含64+行資料。表的整體存儲組織如下圖3所示。
圖3 RAPID中表的存儲結構
4.2資料編碼
DPU中有意識地缺少了對原生浮點運算的支援。此外，記憶體尋址有着嚴格的對齊規則，這就使得可變寬度列的存儲變得複雜起來。是以，RAPID使用固定寬度編碼來處理所有常見的資料類型。尤其是，廣泛使用了十進制縮放二進制數值編碼（Decimal Scaled Binary Number，DSB）和字典編碼。
在十進制編碼中，将會使用每個矢量的公共标量，該标量被選為最小值，以避免值中的小數點。然後使用公共标量将DSB值解碼回原始的十進制數字。DSB編碼通過避免浮點計算而顯著提示了性能。但是，對于一些極端情況（例如，像1/3這樣的值），則需要存儲異常值并單獨處理。對于固定長度和可變長度的字元串，使用字典編碼。該字典允許更新操作，以及範圍查找來評估字首掃描和範圍掃描。此外，還在每個列矢量上面應用了其他編碼，以進行輕量級壓縮（例如，運作長度編碼）。
4.3更新
RAPID支援對已加載的表進行周期性更新。這是通過對表的每個更新單元（Update Unit，UU）進行跟蹤來完成的。UU包含了一組已更改的行、SCN，以及過期SCN。在RAPID端，跟蹤器子產品負責在查詢處理期間擷取具有有效SCN的資料矢量。跟蹤器使用索引來通路有效的UU及其最新版本。是以，就可以同時處理來自查詢處理和更新作業的通路請求。随着時間的推移，累積的更新會導緻大量的過期矢量占據記憶體，是以又引入了定期的系統範圍垃圾回收作業。
4.4高效的資料加載
這裡采用了一種高效的機制将資料加載進RAPID節點。加載操作，從MDS的LOAD指令開始。将會有多個掃描線程協同工作，直接從磁盤上收集和緩沖資料記錄。同時，并行度也會被自動進行調整，進而實作最大的磁盤帶寬。此外，直接讀取磁盤，就可以避免對記憶體緩沖池造成污染。
出處：https://www.modb.pro/db/150185