翻譯：王學(xué)姣
審校：李浩、宇亭
責(zé)編：宇亭
設(shè)計(jì)：Yeekin
導(dǎo) 語
本篇是StoneDB學(xué)術(shù)分享會(huì)專欄的第七篇，在上一期里，我們分享了 SAP 在 2012 年發(fā)表的《The SAP HANA Database – An Architecture Overview》論文，主要是介紹了 SAP HANA 列式存儲(chǔ)引擎的架構(gòu)設(shè)計(jì)，該列存引擎利用現(xiàn)代硬件（多 CPU 內(nèi)核、大容量主內(nèi)存和緩存），支持?jǐn)?shù)據(jù)壓縮、數(shù)據(jù)庫內(nèi)核并行最大化，提供層次結(jié)構(gòu)（hierarchy）專用的數(shù)據(jù)結(jié)構(gòu)、用于特定領(lǐng)域的語言支持等企業(yè)應(yīng)用所需的數(shù)據(jù)庫擴(kuò)展。
本期，我們將帶大家讀一讀這篇《Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth》，瞧瞧，這個(gè)標(biāo)題就起得很有火藥味，SAP 提出列式存儲(chǔ)引擎的時(shí)候，市面上敢用行列混存做 HTAP 數(shù)據(jù)庫的基本沒幾個(gè)，但是人家竟然敢直接跟你說，SAP HANA 數(shù)據(jù)庫，就是為了結(jié)束人們對(duì)列式存儲(chǔ)的偏見而生的，誰說列式存儲(chǔ)不能做事務(wù)型工作（OLTP）的？我們 SAP HANA 證明給你看~（當(dāng)然了，現(xiàn)在列式存儲(chǔ)的數(shù)據(jù)庫其實(shí)已經(jīng)很多了，我們的 StoneDB 團(tuán)隊(duì)自研的 Tianmu 引擎就是列式存儲(chǔ)引擎）
是不是還挺橫的？一眾數(shù)據(jù)庫界的大佬也坐不住了：你們 SAP 到底哪來的底氣？別急，今天就帶大家看看這篇經(jīng)典論文，揭開 SAP HANA 數(shù)據(jù)庫的神秘面紗。
摘要
SAP HANA 數(shù)據(jù)庫是 SAP 新推出的數(shù)據(jù)管理平臺(tái)的核心。SAP HANA 數(shù)據(jù)庫的總體目標(biāo)是為事務(wù)型查詢和分析型查詢場(chǎng)景提供一個(gè)通用的、強(qiáng)大的系統(tǒng)，且在高度可擴(kuò)展的執(zhí)行環(huán)境中為不同的查詢場(chǎng)景提供相同的數(shù)據(jù)表示。本文重點(diǎn)介紹了 SAP HANA 數(shù)據(jù)庫區(qū)別于傳統(tǒng)關(guān)系型數(shù)據(jù)庫引擎的主要特性。因此，在本文中，我們首先概述了 SAP HANA 的總體架構(gòu)和設(shè)計(jì)標(biāo)準(zhǔn)。其次，SAP HANA 挑戰(zhàn)了人們關(guān)于列存數(shù)據(jù)結(jié)構(gòu)的偏見，即列存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)只在分析型工作負(fù)載中表現(xiàn)優(yōu)異，并不適合事務(wù)型工作負(fù)載。 我們概述了如何通過管理記錄（record）生命周期來使用不同的格式存儲(chǔ)不同階段的同一記錄。除了提供概念的解讀外，我們還深入探討了如何在記錄的生命周期中對(duì)其進(jìn)行高效同步，以及如何將數(shù)據(jù)庫條目從寫優(yōu)化的存儲(chǔ)格式轉(zhuǎn)移到讀優(yōu)化的存儲(chǔ)格式的一些細(xì)節(jié)。總之，本文旨在說明 SAP HANA 數(shù)據(jù)庫如何實(shí)現(xiàn)同時(shí)在分析型和事務(wù)型工作負(fù)載環(huán)境中進(jìn)行高效工作。
簡介
現(xiàn)代商業(yè)應(yīng)用中的數(shù)據(jù)管理是當(dāng)今軟件行業(yè)面臨的最具挑戰(zhàn)性的課題之一?，F(xiàn)如今，數(shù)據(jù)不僅推動(dòng)著業(yè)務(wù)發(fā)展，還為新業(yè)務(wù)理念或業(yè)務(wù)案例的發(fā)展提供了基礎(chǔ)。各種各樣的數(shù)據(jù)管理已經(jīng)成為企業(yè)的核心資產(chǎn)。此外，數(shù)據(jù)管理作為推動(dòng)和發(fā)展當(dāng)前業(yè)務(wù)的主要工具，已經(jīng)引起了高層管理者的極大關(guān)注。在系統(tǒng)方面，數(shù)據(jù)管理場(chǎng)景變得極其復(fù)雜，難以管理。一個(gè)高效、靈活、穩(wěn)健、低成本的數(shù)據(jù)管理層成為了大量應(yīng)用場(chǎng)景的核心，而這些應(yīng)用場(chǎng)景則是當(dāng)今商業(yè)環(huán)境中不可或缺的部分。
起初，傳統(tǒng) ERP 系統(tǒng)被用為處理這些應(yīng)用場(chǎng)景的信息處理中樞。從數(shù)據(jù)庫系統(tǒng)的角度來看，ERP 系統(tǒng)的 OLTP 工作負(fù)載通常需要處理成千上萬的并發(fā)用戶和事務(wù)，而這些事務(wù)常常伴隨著高更新負(fù)載和選擇性極強(qiáng)的點(diǎn)查詢（point query）。另一方面，數(shù)據(jù)倉庫系統(tǒng)（對(duì)應(yīng)于 OLTP 系統(tǒng)）要么對(duì)基于大量數(shù)據(jù)進(jìn)行聚合查詢，要么通過計(jì)算統(tǒng)計(jì)模型來分析存儲(chǔ)在數(shù)據(jù)庫中的內(nèi)容。 然而，新應(yīng)用的出現(xiàn)，例如用于識(shí)別數(shù)據(jù)流或ETL/信息集成任務(wù)中的異常的實(shí)時(shí)分析，對(duì)數(shù)據(jù)管理層提出了新的需求和挑戰(zhàn)。這些需求和挑戰(zhàn)要求一個(gè)能夠處理現(xiàn)代業(yè)務(wù)應(yīng)用的數(shù)據(jù)管理層。
Stonebraker 等人為上述問題提供了一個(gè)答案。他們?cè)?2007 年【13】提出了“The End of an Architectural Era (It's Time for a Complete Rewrite)”的觀點(diǎn)，表明傳統(tǒng)的數(shù)據(jù)庫管理系統(tǒng)不再能夠滿足變化多樣的市場(chǎng)需求。市場(chǎng)需要不同的數(shù)據(jù)庫管理系統(tǒng)用于解決不同的問題。從本質(zhì)上來說，此觀點(diǎn)證實(shí)了如下現(xiàn)狀：大型數(shù)據(jù)管理解決方案是一個(gè)包含各種系統(tǒng)的集合。這些系統(tǒng)適用于不同的應(yīng)用場(chǎng)景。例如，行存儲(chǔ)仍然主要應(yīng)用于 OLTP 領(lǐng)域。使用基于實(shí)體（entity-based）的交互模型能夠在記錄中維護(hù)邏輯實(shí)體和物理表示之間的 1:1 關(guān)系。按列組織的數(shù)據(jù)結(jié)構(gòu)在分析領(lǐng)域獲得了越來越多的關(guān)注。這種數(shù)據(jù)結(jié)構(gòu)可以避免查詢列的投影（projection），并可以提供更好的壓縮效率。鍵值存儲(chǔ)（key-value store）正在逐漸成為商業(yè)數(shù)據(jù)管理解決方案的一部分，用于處理海量數(shù)據(jù)以及為程序性的代碼提供并行執(zhí)行的平臺(tái)。此外，分布式文件系統(tǒng)提供了一種經(jīng)濟(jì)的存儲(chǔ)機(jī)制以及云彈性般靈活的并行度，使鍵值存儲(chǔ)成為了數(shù)據(jù)管理領(lǐng)域的“頭等公民”。行存儲(chǔ)、列存儲(chǔ)以及鍵值存儲(chǔ)完善了大型數(shù)據(jù)庫管理方案，使之能夠處理各種模式（schema）的數(shù)據(jù)和支持基于圖形的數(shù)據(jù)組織形式。由于模式是伴隨數(shù)據(jù)而出現(xiàn)的，系統(tǒng)通常會(huì)提供高效的方法來顯式地利用實(shí)體之間的模型化關(guān)系（modeled relationship），運(yùn)行分析型圖算法（analytical graph algorithm），并展示弱實(shí)體的倉庫（repository）。在市場(chǎng)進(jìn)行性能嘗試初期，專用系統(tǒng)（specialized system）可能被認(rèn)為是明智之舉，但包含各種專用系統(tǒng)的大型數(shù)據(jù)庫解決方案需要解決各個(gè)系統(tǒng)之間的連接、數(shù)據(jù)復(fù)制和同步任務(wù)問題，以及在多個(gè)系統(tǒng)間編排查詢場(chǎng)景，使得此類解決方案變得及其復(fù)雜。此外，為這類解決方案進(jìn)行環(huán)境配置和維護(hù)不僅操作復(fù)雜且極易出錯(cuò)，而且總擁有成本（TCO）也十分高昂。
概括來講，我們對(duì)當(dāng)前形勢(shì)進(jìn)行了如下幾方面的觀察：
使用角度：我們認(rèn)為 SQL 不再是現(xiàn)代業(yè)務(wù)應(yīng)用唯一適用的交互模型。用戶要么被應(yīng)用層這個(gè)屏障完全隔開，要么希望直接與其數(shù)據(jù)庫進(jìn)行交互。在第一種情況下，我們發(fā)現(xiàn)需要用緊耦合機(jī)制來實(shí)現(xiàn)對(duì)應(yīng)用層的最佳支持。在第二種情況下，我們發(fā)現(xiàn)需要針對(duì)特定領(lǐng)域使用具有內(nèi)置數(shù)據(jù)庫特性的腳本語言，如用于統(tǒng)計(jì)處理的 R（【4】）或用于 Hadoop 安裝的 Pig。我們還觀察到對(duì)特定領(lǐng)域和專有查詢語言的全面支持的需求，例如 SAP 提供的用于金融規(guī)劃場(chǎng)景的 FOX （【7】）。最后，我們還發(fā)現(xiàn)了一個(gè)巨大的市場(chǎng)需求：從編程的角度考慮并行性，市場(chǎng)需要直接使能用戶的機(jī)制。
成本意識(shí) ： 我們觀察到一個(gè)很明確的需求，市場(chǎng)需要一個(gè)從硬件到安裝成本，再到運(yùn)營和維護(hù)成本，為整個(gè)數(shù)據(jù)管理體系提供更低TCO 的解決方案，一個(gè)針對(duì)不同工作負(fù)載類型和使用模式（usage pattern）的融合解決方案。
性能、性能、還是性能（【16】）：我們認(rèn)為性能仍然是使用專用系統(tǒng)的主要原因。當(dāng)前所面臨的挑戰(zhàn)是提供一個(gè)在任何時(shí)候都能夠根據(jù)需求靈活地應(yīng)用專門的運(yùn)算符或數(shù)據(jù)結(jié)構(gòu)的解決方案。需要指出的是，不同的工作負(fù)載特征并不能完全證明包含各類專用系統(tǒng)的大型數(shù)據(jù)管理解決方案的合理性。我們過去處理業(yè)務(wù)應(yīng)用的經(jīng)驗(yàn)讓我們成為了特定算子集合需求假設(shè)的支持者。我們對(duì)具有獨(dú)立生命周期和管理設(shè)置的單獨(dú)系統(tǒng)（individual system）存在偏見。我們的目標(biāo)并不是提供一個(gè)單一的封閉系統(tǒng)，而是提供一個(gè)使用通用服務(wù)原語的、靈活的數(shù)據(jù)管理平臺(tái)。當(dāng)前SAP HANA 數(shù)據(jù)庫的可用功能是 SAP HANA 設(shè)備的核心部分（【2】），可被視為這種工具包的一個(gè)具體體現(xiàn)。
貢獻(xiàn)和概述
本文旨在描述 SAP HANA 數(shù)據(jù)庫平臺(tái)的全貌，并深入解釋一些為處理事務(wù)型工作負(fù)載而做的工作細(xì)節(jié)。我們首先概述了 SAP HANA 的整體架構(gòu)和設(shè)計(jì)準(zhǔn)則，強(qiáng)調(diào)了其與傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的不同之處，尤其是SAP HANA 數(shù)據(jù)庫在典型業(yè)務(wù)應(yīng)用范圍內(nèi)的以下顯著特征：
**SAP HANA 數(shù)據(jù)庫包含一個(gè)多引擎查詢處理環(huán)境。** 該環(huán)境提供支持不同結(jié)構(gòu)化程度的數(shù)據(jù)的數(shù)據(jù)抽象，包括高度結(jié)構(gòu)化的關(guān)系型數(shù)據(jù)、到不規(guī)則的結(jié)構(gòu)化數(shù)據(jù)圖（irregularly structured data graphs）、再到非結(jié)構(gòu)化的文本數(shù)據(jù)。處理引擎的整個(gè)使用范圍基于一個(gè)公共表抽象，作為底層物理數(shù)據(jù)表示，從而保證互操作性以及允許不同類型之間的數(shù)據(jù)組合。 **SAP HANA 數(shù)據(jù)庫支持在數(shù)據(jù)庫引擎中直接表示特定于應(yīng)用的業(yè)務(wù)對(duì)象（如 OLAP cube）和邏輯（特定領(lǐng)域的函數(shù)庫）** 。這允許通過底層數(shù)據(jù)管理平臺(tái)實(shí)現(xiàn)應(yīng)用語義（application semantics）交換，從而提高查詢效率，減少單個(gè)應(yīng)用到數(shù)據(jù)庫的往返次數(shù)以及數(shù)據(jù)庫和應(yīng)用之間傳輸?shù)臄?shù)據(jù)量。 **SAP HANA 數(shù)據(jù)庫針對(duì)數(shù)據(jù)管理層和應(yīng)用層之間的通信進(jìn)行了性能優(yōu)化**。例如，SAP HANA 數(shù)據(jù)庫原生支持 SAP 應(yīng)用服務(wù)器的數(shù)據(jù)類型。此外，還計(jì)劃將新的應(yīng)用服務(wù)器技術(shù)直接集成到 SAP HANA 數(shù)據(jù)庫集群的基礎(chǔ)架構(gòu)中，以支持應(yīng)用邏輯和數(shù)據(jù)庫管理功能的交叉執(zhí)行。 **SAP HANA 數(shù)據(jù)庫通過利用實(shí)現(xiàn)高度優(yōu)化的面向列的數(shù)據(jù)表示，支持在同一物理數(shù)據(jù)庫上對(duì)事務(wù)性和分析性工作負(fù)載進(jìn)行高效處理。** 該功能的實(shí)現(xiàn)依賴于復(fù)雜的多步驟記錄生命周期管理（multi-step record lifecycle management）。前三個(gè)特征我們已經(jīng)在【2】中進(jìn)行了探討，最后一個(gè)特征將在本文的第二部分進(jìn)行討論。此處我們概述了與統(tǒng)一表結(jié)構(gòu)（unified table structure）和傳播機(jī)制相關(guān)的一些細(xì)節(jié)，以便通過可控的生命周期管理流程在系統(tǒng)內(nèi)移動(dòng)記錄（record）。具體來講，**我們首先使用不同數(shù)據(jù)結(jié)構(gòu)來保存處于生命周期中不同階段的數(shù)據(jù)。然后我們重點(diǎn)關(guān)注如何高效地實(shí)現(xiàn)不同數(shù)據(jù)結(jié)構(gòu)之間的傳播步驟，從而能夠?qū)?shù)據(jù)從寫優(yōu)化存儲(chǔ)中移動(dòng)到主內(nèi)存結(jié)構(gòu)（main memory structure）中**。寫優(yōu)化存儲(chǔ)非常適合處理插入、更新和刪除操作，而主內(nèi)存結(jié)構(gòu)中的數(shù)據(jù)是高度壓縮的數(shù)據(jù)，適合處理 OLAP 查詢。順便一提，SAP HANA 數(shù)據(jù)庫還提供了運(yùn)行 SAP ERP 系統(tǒng)等企業(yè)關(guān)鍵型應(yīng)用所需的技術(shù)。例如，SAP HANA 數(shù)據(jù)庫展示了 SAP HANA 集群中各個(gè)節(jié)點(diǎn)的容錯(cuò)能力，即如果一個(gè)節(jié)點(diǎn)出現(xiàn)故障，其他節(jié)點(diǎn)會(huì)自動(dòng)接管負(fù)載。在這種情況下，查詢處理既不會(huì)被阻塞也不會(huì)停止，而是由分布式查詢執(zhí)行框架以一種對(duì)用戶透明的方式重新進(jìn)行路由。SAP HANA 數(shù)據(jù)庫也支持備份和恢復(fù)等功能。從事務(wù)行為來看，SAP HANA 數(shù)據(jù)庫使用多版本并發(fā)控制（multi-version concurrency control, MVCC）來實(shí)現(xiàn)不同級(jí)別的事務(wù)隔離。SAP HANA 數(shù)據(jù)庫支持事務(wù)級(jí)和語句級(jí)快照隔離。不夠由于篇幅限制，我們不會(huì)就該點(diǎn)進(jìn)行展開說明。
SAP HANA 數(shù)據(jù)庫的分層架構(gòu)
如【2】中所述，SAP HANA 產(chǎn)品已經(jīng)上市，由一個(gè)帶有不同組件的設(shè)備模型組成，可為數(shù)據(jù)分析場(chǎng)景提供現(xiàn)成的解決方案。這是SAP HANA 邁出的第一步，旨在在數(shù)據(jù)集市場(chǎng)景中讓客戶接受并習(xí)慣以列為導(dǎo)向、以主內(nèi)存為中心的 SAP HANA 數(shù)據(jù)庫的全新理念。截至目前，SAP 正在為 SAP Business Warehouse 產(chǎn)品提供原生支持，以顯著加快查詢和轉(zhuǎn)換場(chǎng)景，同時(shí)允許完全跳過單個(gè)物料化步驟。為了提供這種能力，SAP HANA 擁有數(shù)據(jù)加載和轉(zhuǎn)換工具以及建模工作室，以創(chuàng)建和維護(hù)進(jìn)出 SAP HANA 的復(fù)雜數(shù)據(jù)流。SAP HANA 數(shù)據(jù)庫是SAP HANA 產(chǎn)品的核心組件，負(fù)責(zé)高效和靈活的數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)查詢場(chǎng)景（【11，12】）。
圖1： SAP HANA 設(shè)備概述
SAP HANA 數(shù)據(jù)庫本身遵循嚴(yán)格的分層架構(gòu)，如圖 2 所示。與傳統(tǒng)系統(tǒng)類似，SAP HANA 數(shù)據(jù)庫區(qū)分?jǐn)?shù)據(jù)庫請(qǐng)求的編譯時(shí)（compile time）和運(yùn)行時(shí)（runtime）。此圖并未包含 SAP HANA 數(shù)據(jù)庫的所有組件，例如交易管理器（transaction manager）、授權(quán)管理器（authorization manager）、元數(shù)據(jù)管理器（metadata manager）等均未體現(xiàn)。
圖2： HANA 數(shù)據(jù)庫分層架構(gòu)概述
除了純粹的數(shù)據(jù)處理性能之外，我們還發(fā)現(xiàn)應(yīng)用層和數(shù)據(jù)管理層之間缺乏恰當(dāng)?shù)鸟詈蠙C(jī)制。這是當(dāng)前最先進(jìn)系統(tǒng)的主要缺陷之一。這成為了驅(qū)動(dòng)我們將 SAP HANA 數(shù)據(jù)庫設(shè)計(jì)為可針對(duì)不同查詢語言進(jìn)行擴(kuò)展的平臺(tái)的一個(gè)主要因素。如圖 2 所示，不同查詢語言可以通過普通連接和會(huì)話管理層進(jìn)入系統(tǒng)，實(shí)現(xiàn)同外部的交流。在第一步中，查詢字符串被翻譯成優(yōu)化之后的內(nèi)部表示（類似于抽象語法樹），這對(duì)于每一種領(lǐng)域特定（domain-specific）的語言而言都是本地實(shí)現(xiàn)的。第二步，查詢表達(dá)式被映射到一個(gè)“計(jì)算圖（calculation graph）”，從而構(gòu)成了邏輯查詢處理框架（logical query processing framework）的核心。
2.1 計(jì)算圖模型
“計(jì)算圖模型”遵循經(jīng)典數(shù)據(jù)流圖（data flow graph） 的原則。源節(jié)點(diǎn)（source node）是持久表結(jié)構(gòu)或其他計(jì)算圖的結(jié)果表示。內(nèi)部節(jié)點(diǎn)（inner node）表示消耗一個(gè)或多個(gè)傳入數(shù)據(jù)流并產(chǎn)生任意數(shù)量的傳出數(shù)據(jù)流的邏輯運(yùn)算符。此外，計(jì)算圖操作符集可以分成兩組操作符類型。一方面，計(jì)算圖模型定義了一組內(nèi)置運(yùn)算符（intrinsic operator），包括聚合（aggregation）、投影（projection）、連接（join）、聯(lián)合（union）等。SQL 可以完全映射到這類操作符。另一方面，計(jì)算圖模型提供了實(shí)現(xiàn)核心業(yè)務(wù)算法（例如貨幣轉(zhuǎn)換和日歷功能）的操作符。此外，計(jì)算圖模型支持以下類型的運(yùn)算符：
動(dòng)態(tài) SQL 節(jié)點(diǎn)（dynamic SQL node） ：計(jì)算圖模型運(yùn)算符可以對(duì)傳入的數(shù)據(jù)流執(zhí)行完整的 SQL 語句。該語句可以是參數(shù)，并且在計(jì)算圖運(yùn)行時(shí)被編譯和執(zhí)行，從而產(chǎn)生了一種“嵌套計(jì)算”模型的形式。
自定義節(jié)點(diǎn)（custom node） ：出于性能原因，可以使用自定義節(jié)點(diǎn)在 C++ 中實(shí)現(xiàn)特定領(lǐng)域的運(yùn)算符。例如，使用 SAP 專有語言 Fox【6】的規(guī)劃場(chǎng)景可以利用特殊的“分解（disaggregate）”運(yùn)算符來原生支持財(cái)務(wù)規(guī)劃情況【7】。另一個(gè)例子是通過專有的 WIPE graph 語言在數(shù)據(jù)圖中進(jìn)行圖遍歷和分析優(yōu)化。
R 節(jié)點(diǎn)（R node） ：R 節(jié)點(diǎn)（【4】）可用于將傳入的數(shù)據(jù)集轉(zhuǎn)發(fā)到 R 執(zhí)行環(huán)境。作為參數(shù)給出的 R 腳本將在 SAP HANA 數(shù)據(jù)庫之外執(zhí)行，并將結(jié)果移回到計(jì)算圖中進(jìn)行進(jìn)一步處理。
L 節(jié)點(diǎn)（L node） ：語言 L 代表 SAP HANA 數(shù)據(jù)庫的內(nèi)部運(yùn)行時(shí)語言。語言 L 被設(shè)計(jì)成 C 語言的安全子集。通常情況下，終端用戶或應(yīng)用設(shè)計(jì)者不能直接訪問。語言 L 是所有的不能直接映射到數(shù)據(jù)流圖的領(lǐng)域?qū)Ｓ谜Z言的結(jié)構(gòu)（constructs）的合集。換言之，語言L 即各種命令式控制邏輯。除了一組功能操作符之外，計(jì)算圖模型還提供了“拆分（split）”和“組合（combine）”的運(yùn)算符，以動(dòng)態(tài)定義和重新分配數(shù)據(jù)流分區(qū)，作為支持應(yīng)用定義（application-defined）的數(shù)據(jù)并行化的基礎(chǔ)構(gòu)造。
各領(lǐng)域?qū)Ｓ谜Z言的編譯器都試圖優(yōu)化從查詢腳本到計(jì)算圖的映射。對(duì)于 SQL，映射的基礎(chǔ)是有明確定義的、查詢表達(dá)式的邏輯表示。在一般情況下，映射可以使用啟發(fā)式或者基于代價(jià)的策略，這取決于輸入數(shù)據(jù)的預(yù)估大小等因素。例如，編譯器可能會(huì)決定將循環(huán)展開成常規(guī)數(shù)據(jù)流圖，或者為特定表達(dá)式生成 L 代碼【6】。在常規(guī) SQL 的情況下，這是迄今為止最大和最復(fù)雜的部分，取自 SAP P*Time1 系統(tǒng)（【1】），內(nèi)部表示直接映射到關(guān)系運(yùn)算符以捕獲SQL 語句的意圖。
圖 3 描繪了一個(gè)計(jì)算圖模型示例。計(jì)算圖模型可以通過特定領(lǐng)域語言的編譯器間接創(chuàng)建，也可以使用 SAP HANA Studio進(jìn)行可視化建模，并在 SAP HANA 數(shù)據(jù)庫的應(yīng)用級(jí)內(nèi)容倉庫中注冊(cè)為計(jì)算視圖（calculation view）。 這一過程背后的總體思想是定制復(fù)雜業(yè)務(wù)邏輯場(chǎng)景的特定段（segment），這些段可以在多個(gè)數(shù)據(jù)庫場(chǎng)景中進(jìn)行微調(diào)和重用，與實(shí)際的查詢語言無關(guān)。換言之，計(jì)算圖模型可以以虛擬表的形式在任何領(lǐng)域特定語言堆棧中被消費(fèi)。計(jì)算圖模型的集合也稱為 SAP HANA content，并擁有獨(dú)立的產(chǎn)品生命周期流程。圖3 所示的計(jì)算模型概述了 SAP HANA 數(shù)據(jù)庫與標(biāo)準(zhǔn)關(guān)系型數(shù)據(jù)庫系統(tǒng)在常規(guī)查詢計(jì)劃方面的差異。例如，從應(yīng)用的角度來看，一個(gè)操作符的結(jié)果可能會(huì)有多個(gè)消費(fèi)者（consumer）需要優(yōu)化共享的公共子表達(dá)式。其次，標(biāo)記為“script”的節(jié)點(diǎn)包含了來自計(jì)算模型設(shè)計(jì)器或由特定領(lǐng)域查詢編譯器生成的命令性語言片段。最后，節(jié)點(diǎn)“conv”顯示了使用內(nèi)置業(yè)務(wù)函數(shù)來執(zhí)行特定應(yīng)用的轉(zhuǎn)換例程，例如貨幣轉(zhuǎn)換或單位轉(zhuǎn)換。
圖3： SAP HANA 計(jì)算模型圖示例
2.2 計(jì)算圖的編譯和執(zhí)行
一旦用戶定義的查詢表達(dá)式或查詢腳本被映射到計(jì)算圖模型中的數(shù)據(jù)流圖，優(yōu)化器就會(huì)運(yùn)行經(jīng)典的基于規(guī)則或代價(jià)的優(yōu)化步驟，將邏輯計(jì)劃重構(gòu)并轉(zhuǎn)換為物理計(jì)劃，然后由分布式執(zhí)行框架執(zhí)行。執(zhí)行框架繼承自之前的 SAP 產(chǎn)品 SAP BWA（業(yè)務(wù)倉庫加速器）和SAP Enterprise Search，用于處理實(shí)際數(shù)據(jù)流和物理操作符的分布式執(zhí)行。在優(yōu)化過程中，邏輯數(shù)據(jù)流圖的片段被映射到“引擎層”提供的物理運(yùn)算符。引擎層本身由一組不同的物理操作符組成。這些物理操作符有著一些局部優(yōu)化邏輯，從而使全局計(jì)劃的片段能夠適應(yīng)實(shí)際物理操作符的特性。值得說道的是，SAP HANA 數(shù)據(jù)庫提供了以下一套運(yùn)算符：
關(guān)系運(yùn)算符：關(guān)系運(yùn)算符用于典型的關(guān)系查詢圖處理。如第3.1小節(jié)所述，關(guān)系運(yùn)算符擁有不同的特征，例如，equi-join（【5】）等運(yùn)算符直接利用統(tǒng)一表（unified table）的現(xiàn)有字典。
OLAP 運(yùn)算符：OLAP 運(yùn)算符針對(duì)具有事實(shí)表和維度表的星形連接（star-join）方案進(jìn)行了優(yōu)化。一旦優(yōu)化器識(shí)別出這種類型的場(chǎng)景，與之對(duì)應(yīng)的查詢計(jì)劃片段到 OLAP 運(yùn)算符的映射就會(huì)被枚舉為具有相應(yīng)代價(jià)估計(jì)的可行物理計(jì)劃（【8】）。
L 運(yùn)行時(shí)間：內(nèi)部語言的運(yùn)行時(shí)反映了用于執(zhí)行在指定計(jì)算圖的L節(jié)點(diǎn)中的表示L代碼的構(gòu)造塊（building code）。使用“拆分（split）和組合（combine）”運(yùn)算符對(duì)時(shí)，可以在預(yù)定義的分區(qū)上并行調(diào)用L運(yùn)行時(shí)。
文本運(yùn)算符：文本搜索分析操作符集包括 SAP Enterprise Search 產(chǎn)品中可用的功能集，以提供從相似性度量到實(shí)體解析能力的綜合文本分析特性（【14】）。
圖形運(yùn)算符：圖形運(yùn)算符最終為基于圖形的算法提供支持，以實(shí)現(xiàn)復(fù)雜的資源規(guī)劃場(chǎng)景或社會(huì)網(wǎng)絡(luò)分析任務(wù)。由于數(shù)據(jù)流圖不僅分布在多個(gè)服務(wù)器實(shí)例（通常運(yùn)行在不同物理節(jié)點(diǎn)上）之間，還分布在不同類型的運(yùn)算符上，因此 SAP HANA 提供了一個(gè)工具箱，用于保證最佳的數(shù)據(jù)傳輸和交換格式。盡管所有計(jì)算符都需要實(shí)施標(biāo)準(zhǔn)的數(shù)據(jù)傳輸協(xié)議，但不同“集合”內(nèi)外的個(gè)別運(yùn)算符可能擁有高度專業(yè)化的通信協(xié)議。例如，關(guān)系運(yùn)算符和 OLAP 運(yùn)算符以高度壓縮的專有格式進(jìn)行數(shù)據(jù)交換。此外，R 節(jié)點(diǎn)提供了一個(gè)到 R內(nèi)部數(shù)據(jù)幀格式的映射。
除了“橫向”交流之外，不同物理運(yùn)算符直接可以通過一個(gè)通用接口接入到統(tǒng)一表層（unified table layer） 。SAP HANA 數(shù)據(jù)庫提供了一個(gè)抽象的表格視圖，允許不同的計(jì)算符通過多種方法進(jìn)行訪問。這一點(diǎn)我們將在下一部分進(jìn)行詳細(xì)介紹。該通用表格結(jié)構(gòu)實(shí)現(xiàn)了數(shù)據(jù)實(shí)體的完整生命周期，其主要構(gòu)成部分為行存儲(chǔ)和列存儲(chǔ)的組合，用于捕獲最近的數(shù)據(jù)修改效果。由于 SAP HANA 數(shù)據(jù)庫中的表可以標(biāo)記為“歷史（historic）”，因此表層（table layer）實(shí)現(xiàn)了用于捕獲活躍實(shí)體（active entity）的過去值的歷史表（history table），并提供了訪問時(shí)間旅行查詢（time travel query）的方式。
最后，SAP HANA 的持久層（persistence layer）保證了系統(tǒng)的可恢復(fù)性。即使在主內(nèi)存中的數(shù)據(jù)庫狀態(tài)丟失的情況下，系統(tǒng)也依然能夠?qū)崿F(xiàn)快速恢復(fù)。虛擬文件（virtual file）是持久層的基礎(chǔ)。虛擬文件對(duì)可視化頁面的可配置大小進(jìn)行了限制。采用 SAP MaxDB 系統(tǒng)的概念，持久層依靠頻繁產(chǎn)生的保存點(diǎn)（savepoint）以非常低的資源開銷提供一致快照。更多相關(guān)細(xì)節(jié)，將在下一部分介紹。
2.3 總結(jié)
與傳統(tǒng)數(shù)據(jù)庫系統(tǒng)相比，SAP HANA 數(shù)據(jù)庫旨在利用平臺(tái)的靈活性來支持多種（專有）領(lǐng)域特定的語言。靈活的數(shù)據(jù)流模型（計(jì)算圖模型）提供了概念上的系統(tǒng)核心：一方面，查詢表達(dá)式或查詢腳本被映射到模型實(shí)例。另一方面，所有不同物理運(yùn)算符都使用相同的表層接口（table layer interface），對(duì)單個(gè)記錄實(shí)施完整的生命周期管理。日志和數(shù)據(jù)區(qū)被用于在持久存儲(chǔ)中維護(hù)主內(nèi)存數(shù)據(jù)庫的事務(wù)一致性副本。
數(shù)據(jù)庫記錄的生命周期管理
如圖 4 所示，統(tǒng)一表結(jié)構(gòu)（unified table structure）允許所有適用的物理運(yùn)算符進(jìn)行數(shù)據(jù)訪問。 統(tǒng)一表結(jié)構(gòu)的內(nèi)在實(shí)質(zhì)是系統(tǒng)為數(shù)據(jù)庫記錄提供了生命周期管理。在我們看來，統(tǒng)一表技術(shù)是系統(tǒng)能夠高性能地同時(shí)處理基于掃描的聚合查詢和極具選擇性的點(diǎn)查詢的關(guān)鍵。這成為 SAP HANA 區(qū)別于傳統(tǒng)（行存）數(shù)據(jù)庫的一個(gè)關(guān)鍵差異點(diǎn)。在就地更新（update-in-place）風(fēng)格的數(shù)據(jù)庫系統(tǒng)中，記錄從概念層面來看，在其整個(gè)生命周期中保持在同一位置，而 SAP HANA 通過物理表示的不同階段對(duì)記錄實(shí)現(xiàn)了概念上的傳播。雖然是作為一個(gè)一般概念設(shè)計(jì)的，如圖 4 所示，在一個(gè)常規(guī)表中，記錄根據(jù)生命周期被劃分為以下三個(gè)階段：
圖4： 統(tǒng)一表概念概述
L1-delta：L1-delta（L1-增量）結(jié)構(gòu)接受所有數(shù)據(jù)傳入請(qǐng)求，并以寫優(yōu)化的方式存儲(chǔ)這些請(qǐng)求，即 L1-delta 保留記錄的邏輯行格式。該數(shù)據(jù)結(jié)構(gòu)針對(duì)快速插入和刪除、字段更新和記錄投影進(jìn)行了優(yōu)化。此外，L1-delta 結(jié)構(gòu)不會(huì)對(duì)數(shù)據(jù)進(jìn)行壓縮。根據(jù)經(jīng)驗(yàn)，單個(gè)節(jié)點(diǎn)數(shù)據(jù)庫實(shí)例中，L1-delta 結(jié)構(gòu)可以存儲(chǔ)10,000到100,000行數(shù)據(jù)。這一容量因數(shù)據(jù)庫實(shí)例的工作負(fù)載特征和可用內(nèi)存大小而異。
L2-delta：L2-delta（L2-增量）結(jié)構(gòu)代表了記錄在生命周期中的第二個(gè)階段，以列存格式組織數(shù)據(jù)。與L1-delta 相比，L2-delta 采用字典編碼來優(yōu)化內(nèi)存利用。然而，出于性能考慮，字典是未排序的，需要使用二級(jí)索引結(jié)構(gòu)來實(shí)現(xiàn)對(duì)點(diǎn)查詢?cè)L問模式（access pattern）的最佳支持，例如快速執(zhí)行唯一約束檢查。L2-delta 非常適合存儲(chǔ)量超過1000萬行的場(chǎng)景。
Main store：最后，main store（主存儲(chǔ)）表示采用各種不同壓縮方案的最高壓縮率的核心數(shù)據(jù)格式。默認(rèn)情況下，一列中的所有值都通過排序字典中的位置來表示，并以位打包（bit-packing）的方式存儲(chǔ)，以便實(shí)現(xiàn)各個(gè)值的密集打包（【15】）。雖然字典總是使用各種前綴編碼方案進(jìn)行壓縮，不同壓縮技術(shù)的組合——從簡單的游程編碼方案到更復(fù)雜的壓縮技術(shù)——也被應(yīng)用于進(jìn)一步減少占用的主內(nèi)存（【9，10】）。由于 SAP HANA 數(shù)據(jù)庫最初是為復(fù)雜且高容量加載場(chǎng)景的 OLAP 密集型用例而設(shè)計(jì)的，因此該系統(tǒng)針對(duì)高效批量插入提供了特殊處理，這使得此類操作會(huì)繞過 L1-delta 直接進(jìn)入 L2-delta。與輸入位置無關(guān)，任何輸入記錄的行 ID（RowId）都在行（row）輸入系統(tǒng)時(shí)生成。并且，該行的日志在該行第一次出現(xiàn)時(shí)生成，無論是在適合常規(guī)更新/插入/刪除操作的 L1-delta 中，還是在適合大容量裝載操作的 L2-delta 中。
3.1 統(tǒng)一表訪問
不同數(shù)據(jù)結(jié)構(gòu)共享一組通用數(shù)據(jù)類型。統(tǒng)一表訪問通過一個(gè)帶有行迭代器和列迭代器的公共抽象接口實(shí)現(xiàn)。兩個(gè)迭代器都可以是基于字典（dictionary-based）的迭代器。 此外，在遵循經(jīng)典的 ONC 協(xié)議【3】,支持流水線操作，并盡可能減少中間結(jié)果的內(nèi)存需求的基礎(chǔ)上，一些物理計(jì)算符可以逐記錄或者以矢量化的方式（即逐塊）拉取記錄。其他物理計(jì)算符采用“materialize all”策略，以避免查詢執(zhí)行期間的計(jì)算符切換所產(chǎn)生的成本。優(yōu)化器根據(jù)邏輯計(jì)算圖模型來決定如何對(duì)不同種類的計(jì)算符進(jìn)行混合使用，即被采用的不同類型的物理運(yùn)算符將會(huì)被無縫集成到最終的查詢執(zhí)行計(jì)劃中。
對(duì)于使用排序字典的操作符，統(tǒng)一表訪問接口還通過全局排序字典公開表內(nèi)容。 在 L1-delta 結(jié)構(gòu)的字典完成計(jì)算和 L2-delta 結(jié)構(gòu)的字典完成排序后，兩種 delta 結(jié)構(gòu)的字典會(huì)被立刻合并至 main store 的字典中。為了實(shí)現(xiàn)唯一性約束的有效性驗(yàn)證，統(tǒng)一表為兩種 delta 和 main store 提供了反向索引（inverted index）。
記錄的生命周期采用的組織方式將單個(gè)記錄在系統(tǒng)中進(jìn)行異步傳播，而不干擾當(dāng)前正在事務(wù)控制范圍內(nèi)（transactional sphere of control）運(yùn)行的數(shù)據(jù)庫操作的組織方式。當(dāng)前的 SAP HANA 數(shù)據(jù)庫系統(tǒng)提供兩次轉(zhuǎn)換，我們稱之為 “合并步驟（merge step）” ：
L1-to-L2-delta Merge：從 L1-delta 到 L2-delta 的轉(zhuǎn)換意味著數(shù)據(jù)從按行組織變成了按列組織。L1-delta 中的行被拆分成它們對(duì)應(yīng)的列值，然后被逐列插入到 L2-delta 中。在接收端，系統(tǒng)會(huì)執(zhí)行一次 lookup 來識(shí)別出字典結(jié)構(gòu)中可能丟失的值，并且可以選擇在字典的末尾插入新條目以避免在字典中進(jìn)行任何重大的重構(gòu)操作。在第二步中，使用字典編碼（append-only 結(jié)構(gòu)）將相應(yīng)的列值添加到值向量中。這兩個(gè)步驟可以并行執(zhí)行，因?yàn)橐苿?dòng)的元組的數(shù)量是已知的，使得能夠在實(shí)際插入它們之前在新字典中保留編碼。在第三步中，從 L1-delta 中移除已經(jīng)傳播的條目（propagated entry）。所有運(yùn)行中的操作要么看到的是完整的 L1-delta 和舊的 end-of-delta 邊界，要么看到具有 L2-delta 擴(kuò)展版本的 L1-delta 結(jié)構(gòu)的截?cái)喟姹荆╰runcated version）。從設(shè)計(jì)角度來看，從 L1-delta 到 L2-delta 的轉(zhuǎn)換本質(zhì)上是增量式的，即記錄的轉(zhuǎn)換對(duì)目標(biāo)結(jié)構(gòu)的數(shù)據(jù)重組沒有任何影響。
L2-delta-to-main Merge：一個(gè)新的 main store 是基于 L2-delta 和現(xiàn)有的 main store 產(chǎn)生的。雖然 L1-to-L2-delta Merge 對(duì)運(yùn)行事務(wù)的影響很小，但 L2-delta-to-main Merge 是資源密集型任務(wù)，必須在物理級(jí)別上仔細(xì)安排并進(jìn)行高度優(yōu)化。一旦L2-delta-to-main Merge 開始，當(dāng)前的L2-delta 就會(huì)被關(guān)閉用于執(zhí)行更新操作。與此同時(shí)，系統(tǒng)會(huì)創(chuàng)建一個(gè)新的、空的 L2-delta 結(jié)構(gòu)用來作為 L1-to-L2-delta Merge 的目的端。如果 L2-delta-to-main Merge 失敗，系統(tǒng)仍然使用新的 L2-delta 用于L1-to-L2-delta Merge，并繼續(xù)嘗試使用舊版本的 L2-delta 和現(xiàn)有的main 進(jìn)行合并。第 4 章將詳述核心算法以及不同的優(yōu)化技術(shù)，例如 4.2 小節(jié)會(huì)介紹按列合并（column-wise merge），4.3 小節(jié)會(huì)介紹部分合并（partial merge）。
上述兩個(gè)合并步驟都不會(huì)對(duì)持久存儲(chǔ)產(chǎn)生直接影響，并且獨(dú)立于重啟或備份日志重放。
3.2 持續(xù)性映射
雖然 SAP HANA 數(shù)據(jù)庫是一個(gè)以內(nèi)存為中心的數(shù)據(jù)庫系統(tǒng)，但其全面的 ACID 支持保證了持久性、原子性，以及系統(tǒng)在定期關(guān)閉或系統(tǒng)故障后能夠重啟恢復(fù)。 SAP HANA 數(shù)據(jù)庫考慮了多種持久化觀點(diǎn)來構(gòu)架其持久性。一般來說，持久存儲(chǔ)無需細(xì)粒度的 UNDO 機(jī)制，因?yàn)橹挥邢裥掳姹镜?main 結(jié)構(gòu)這種量級(jí)的批量更改（bulk change）才會(huì)傳播到持久存儲(chǔ)，并且在系統(tǒng)故障后必須回滾。如圖 5 所示，SAP HANA 的持久性是基于臨時(shí) REDO 日志和短期恢復(fù)或長期備份的 save pointing 的組合實(shí)現(xiàn)的。
圖5：統(tǒng)一表的持久性機(jī)制概述
當(dāng)一條新數(shù)據(jù)進(jìn)入系統(tǒng)時(shí)，無論是在 L1-delta 還是在 L2-delta （批量插入）進(jìn)行，都只會(huì)為其創(chuàng)建一次 REDO 日志。當(dāng)一條記錄的新版本進(jìn)入 L1-delta 時(shí)，系統(tǒng)會(huì)為該新版本創(chuàng)建日志。從 L1-delta 到 L2-delta 的增量傳播過程中所發(fā)生的數(shù)據(jù)變化不會(huì)被寫入至REDO 日志中。反而是字典和 value index（值索引）中的變化會(huì)被添加到各個(gè)數(shù)據(jù)頁中的數(shù)據(jù)結(jié)構(gòu)中，這些數(shù)據(jù)結(jié)構(gòu)最終被移入至下一個(gè)保存點(diǎn)的持久存儲(chǔ)中。顯然，合并事件被寫入日志，以確保重啟后數(shù)據(jù)庫狀態(tài)的一致性。
圖 6 描繪了合并的細(xì)節(jié)。字典和值索引這兩種結(jié)構(gòu)都是基于分頁存儲(chǔ)布局（paged storage layout）。 該布局由底層存儲(chǔ)子系統(tǒng)進(jìn)行管理。無論是具有附加條目的現(xiàn)有頁或新頁，但凡是臟頁都會(huì)被存儲(chǔ)子系統(tǒng)清理掉。該功能由保存點(diǎn)基礎(chǔ)架構(gòu)（save pointing infrastructure）來控制。盡管 L2-delta 中的數(shù)據(jù)是按列組織的，但是系統(tǒng)可以在單個(gè)頁面內(nèi)存儲(chǔ)多個(gè) L2-delta 的片段，以便優(yōu)化存儲(chǔ)器消耗。特別是對(duì)于小而寬的表，這一設(shè)計(jì)尤為合理。
圖6： L1-to-L2-delta Merge 的細(xì)節(jié)圖
在保存點(diǎn)之后，REDO 日志可以被截?cái)唷?/strong> 在恢復(fù)過程中，系統(tǒng)重新加載 L2-delta 的最后一個(gè)快照。與之類似，main store 的一個(gè)新版本會(huì)被持久化至穩(wěn)定存儲(chǔ)中，并可用于重新加載統(tǒng)一表的 main store?？傊?yàn)橄惹鞍姹镜挠诚袢匀淮嬖?，無論是 L2-delta 還是main store 的變化都不會(huì)寫入日志。傳統(tǒng)的日志方案僅適用于 L1-delta。
3.3 總結(jié)
SAP HANA 數(shù)據(jù)庫中的表的物理表示分為三個(gè)層級(jí)：
L1-delta：用于高效捕獲插入、更新和刪除請(qǐng)求的行式存儲(chǔ)；
L2-delta：用于將寫優(yōu)化存儲(chǔ)和讀優(yōu)化存儲(chǔ)進(jìn)行解耦的中間結(jié)構(gòu)，是一個(gè)列式存儲(chǔ)；
Main store：該結(jié)構(gòu)不僅非常適合類似于 OLAP 的查詢，并且還使用倒排索引對(duì)點(diǎn)查詢性能進(jìn)行了針對(duì)性調(diào)優(yōu)。一條記錄在其“一生”之中，最開始通過異步復(fù)制保存至更新效率最高的存儲(chǔ)中，然后被復(fù)制到讀取效率最高的存儲(chǔ)中度過“余生”。
合并優(yōu)化
統(tǒng)一表方法的基本思想是通過將記錄從寫優(yōu)化的存儲(chǔ)結(jié)構(gòu)以透明的方式傳播至使用 L2-delta 索引的讀優(yōu)化的存儲(chǔ)結(jié)構(gòu)中，從而實(shí)現(xiàn)讀寫存儲(chǔ)之間的解耦。 雖然從 L1-delta 到 L2-delta 的轉(zhuǎn)換不會(huì)對(duì)現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)產(chǎn)生太大破壞，但 L2-delta 合并至 main store 的操作需要對(duì)表格內(nèi)容進(jìn)行重大重組。
4.1 經(jīng)典合并
在經(jīng)典合并（classic merge）操作的第一步中，L2-delta 的字典條目會(huì)被編譯到 main 的字典中，從而實(shí)現(xiàn)為特定列生成一個(gè)排序后的新的 main 字典。新字典僅包含新的 main 的有效條目，丟棄所有被刪除和修改過的記錄的條目。按字典順序排序不僅為最佳壓縮提供了先決條件，也為特殊計(jì)算符能夠直接處理字典編碼列打下了基礎(chǔ)。
圖7顯示了一次合并步驟涉及到的主要階段。在第一階段，系統(tǒng)基于使用未排序字典的 L2-delta 和使用排序字典的舊 main，生成一個(gè)新的排序字典，并保存條目新舊位置的映射。 新位置為條目在新字典中的位置；舊位置則為條目在 main 和 L2-delta 內(nèi)的位置（非顯式存儲(chǔ)）。如圖所示，一些條目同時(shí)存在于 L2-delta 和 main 的字典中，例如“Los Gatos”；還有一些條目僅出現(xiàn)在一個(gè)詞典中，例如“Campbell”在 L2-delta 中的位置為 4，在 main 的字典映射表中的值為 -1。在第二階段，系統(tǒng)會(huì)參考現(xiàn)有條目和新增條目在新字典中的位置構(gòu)建新的 main index（主索引）。 如圖7 中的示例所示，“Daily City”的條目被轉(zhuǎn)移到新 main 中，位置為 4?！癓os Gatos”也從 L2-delta 中的位置 1 和舊 main 中的位置 5 映射到了新位置 6。新 main（字典和值索引）寫入磁盤，同時(shí)舊的數(shù)據(jù)結(jié)構(gòu)被釋放。在任何情況下，系統(tǒng)都必須在主內(nèi)存中保存列（字典和main index）的新舊兩個(gè)版本，直到所有引用該列的舊版本的開放事務(wù)的數(shù)據(jù)庫操作都已執(zhí)行完畢。
圖7： L2-delta-to-main Merge 的細(xì)節(jié)圖
由于合并操作的初始版（naive version）非常耗費(fèi)資源，SAP HANA 數(shù)據(jù)庫對(duì)其進(jìn)行了許多優(yōu)化。例如，如果 L2-delta 的字典是 main 的字典的子集，那么會(huì)直接跳過用于生成字典的第一階段，從而形成了 main 條目的穩(wěn)定位置。另一種特殊情況是 L2-delta 字典的值大于 main 字典中的值，例如存在增加的時(shí)間戳。在這種情況下，如果對(duì)字典值進(jìn)行編碼的位數(shù)（number of bits）足以應(yīng)對(duì)擴(kuò)展基數(shù)（extended cardinality），則 L2-delta 字典可以直接添加到 main 字典中。
SAP HANA 數(shù)據(jù)庫還使用了正交技術(shù)（orthogonal technique）來實(shí)現(xiàn)更為復(fù)雜的優(yōu)化，例如下面即將介紹到的重排序合并（re-sorting merge）和部分合并（partial merge）策略。
4.2 重排序合并
L2-delta 和 main 之間的經(jīng)典合并（詳情請(qǐng)參考 4.1）需要條目的新舊位置之間的映射關(guān)系。這些位置用于對(duì)位打包值索引（bit-packed value index）內(nèi)的實(shí)值（real value）進(jìn)行編碼，即，用 C 來表示一個(gè)列中的值去重后的數(shù)量，系統(tǒng)需要使用 ?ld(C)? 數(shù)量的位（bit）來對(duì)該位置進(jìn)行編碼。合并操作會(huì)將舊的 main 值映射到新字典中的位置上（具有相同或增加的位數(shù)），并在新的 value index 的末尾添加 L2-delta 的條目。
合并操作的擴(kuò)展版本（extended version）旨在重新組織整個(gè)表的內(nèi)容，將所有列進(jìn)行重新布局，以提供更高的壓縮潛能。 由于 SAP HANA 數(shù)據(jù)庫列存儲(chǔ)使用了位置尋址方案，因此第 k 條記錄中的值必須位于每一列的第 k 個(gè)位置。對(duì)表中某列進(jìn)行重新排序會(huì)直接影響表中其他列的壓縮潛能。根據(jù)【9】中討論的概念，系統(tǒng)在創(chuàng)建新的 main 之前，會(huì)根據(jù) main 和 L2-delta 結(jié)構(gòu)的統(tǒng)計(jì)信息計(jì)算列的“最佳”排序順序。
圖8： Delta-to-main 重排序合并
圖 8 展示了必要的數(shù)據(jù)結(jié)構(gòu)（data structure）。除了用于字典的映射表（mapping table）將舊字典位置翻譯成新字典中的位置之外，重排序合并（re-sorting merge）的版本還創(chuàng)建了行位置的映射表，從而能夠在合并和重新排序某行的各個(gè)列之后重構(gòu)該行。圖8 顯示了合并過程之前和過程中的同一張表中的列，其中列“City”和“Prod”已經(jīng)合并，其余列（如“Time”）仍然反映合并前的狀態(tài)。因此，main 的舊版條目對(duì)應(yīng)于舊字典中的位置，例如“City”列的條目“Los Gatos”在舊字典中用值5 編碼，而在合并后的版本中用值6 編碼。一般來說，在對(duì)“City”列進(jìn)行合并后，新的 main index 顯示新詞典的位置以及對(duì)行進(jìn)行重新排序。如圖 8 中突出顯示的那樣，現(xiàn)在可以在第二個(gè)位置找到第7 行?！癙rod”列也被合并，但沒有新建字典，保留了字典位置值。然而“Time”欄還沒有合并，仍然是指舊字典和舊的排序順序。如果需要具有已經(jīng)合并的列的行構(gòu)造，則對(duì)尚未合并的列的任何訪問都需要通過行位置映射表采取額外步驟。在所有列的合并完成之后，可以消除行位置映射表。雖然系統(tǒng)可以通過“堆疊（stacking）”行位置映射表在概念上延遲不經(jīng)常訪問的列的合并，但是系統(tǒng)總是在開始新的合并生成之前完成整個(gè)表的合并操作。
因此，是否使用重新排序還需要基于成本考慮，用于平衡在所有列的合并期間用于列訪問的額外位置映射的開銷，以及由此產(chǎn)生的更高壓縮率的可能性。將合并應(yīng)用于各個(gè)列的排序標(biāo)準(zhǔn)還取決于多個(gè)因素，例如點(diǎn)對(duì)范圍訪問的比率、壓縮潛力的提高等。
4.3 部分合并
經(jīng)典合并或重排合并的主要缺點(diǎn)在于創(chuàng)建一個(gè)新版本的 main 所帶來的開銷。對(duì)于大型表或分區(qū)，要計(jì)算出一個(gè)新的字典并重新生成 main index 的確會(huì)占用額外的 CPU 和磁盤資源。而部分合并（partial merge）則通過使用以前的算法來緩和這個(gè)問題。部分合并策略體現(xiàn)了在字典中新條目數(shù)量較少的情況下，列的最佳壓縮潛能。
部分合并的核心思想是將 main 拆分成兩個(gè)或更多的獨(dú)立 main：
消極 main（active main） ：main store 中的穩(wěn)定部分，通常不參與合并過程。
積極 main（passive main） ：列中可動(dòng)態(tài)伸縮、參與和 L2-delta 的合并的部分。
圖9： 部分合并概覽
從概念上來看，部分合并策略中的合并間隔始于一個(gè)空的積極 main。 消極 main 通過分類詞典和相應(yīng)的值索引（values index）來反映常規(guī) main 結(jié)構(gòu)。當(dāng)一個(gè)合并操作開始執(zhí)行時(shí)，L2-delta 將合并至仍然為空的積極 main，而消極 main 保持不變。與完全合并（full merge）相比，部分合并有一個(gè)細(xì)微的不同之處。積極 main 的詞典以 n+1 的詞典位置值開始，而消極 main 的詞典則以 n 結(jié)束。盡管系統(tǒng)現(xiàn)在有兩個(gè)帶有本地排序字典的 main 結(jié)構(gòu)，但是各個(gè) main value index 結(jié)構(gòu)的編碼并不重疊。顯然，積極 main 的字典只保存消極 main 的字典中尚未涵蓋的新值。
圖10 顯示了部分合并后一個(gè)消極 main 和一個(gè)積極 main 的示例情況。積極 main 的字典編碼從 n+1 = 6 開始，從而可以延續(xù)消極 main 的編碼方案。 雖然消極 main 字典對(duì)應(yīng)的value index 結(jié)構(gòu)僅保存對(duì)消極main 字典中條目的引用，但是積極 main 字典的 value index 也可以展示main 字典的編碼值，使得積極 main 字典依賴于消極 main 字典。
圖10： 積極 main 和消極 main 的范圍查詢執(zhí)行
點(diǎn)訪問（point access）在消極字典中被解析。 如果找到了所請(qǐng)求的值，則相應(yīng)的位置被用作消極和積極 main 的 value index 的編碼值。執(zhí)行并行掃描以找到相應(yīng)的條目。但是，如果沒有找到所請(qǐng)求的值，則查詢積極 main 的字典。如果該值存在，則只掃描積極main 的 value index，識(shí)別出所需的行的位置。對(duì)于范圍訪問（range access），范圍會(huì)在積極 main 和消極 main 的字典中解析，并且范圍掃描在兩個(gè) main 上被執(zhí)行。對(duì)于積極 main 的字典，掃描分為兩個(gè)部分范圍（partial range），一個(gè)是消極 main 的字典的編碼范圍值，另一個(gè)是積極 main 的字典的編碼范圍值。圖 10 展示了值在C% 和L% 之間的范圍查詢的合并過程。為了保證事務(wù)的一致性，查詢處理還要求與 L1-delta 和 L2-delta 進(jìn)行類似的合并。
當(dāng)系統(tǒng)運(yùn)行時(shí)，積極 main 可能會(huì)動(dòng)態(tài)地收縮和增長，直到一次完全合并被安排好。 這種做法的主要優(yōu)點(diǎn)是將完全合并延遲到負(fù)載較低的時(shí)候執(zhí)行，并且降低了 L2-delta 到 main 或者積極 main 的合并成本。此外，該優(yōu)化策略可以通過以下方式部署為經(jīng)典合并的方案：將積極 main 的最大尺寸設(shè)置為 0 來強(qiáng)制在每個(gè)步驟中進(jìn)行（經(jīng)典）完全合并。顯然，該過程可以輕松地?cái)U(kuò)展到多個(gè)消極 main 結(jié)構(gòu)，這些消極 main 結(jié)構(gòu)形成了和本地字典的依賴性相關(guān)的邏輯鏈。這種配置非常適合那些字典變化極少或者字典很穩(wěn)定的列（例如“Customer”表中的“Country”列）。不過對(duì)于大多數(shù)列來說，系統(tǒng)將僅維持一個(gè)消極 main。
從概念上來講，部分合并優(yōu)化策略在 SAP HANA 數(shù)據(jù)庫統(tǒng)一表概念的記錄生命周期中增加了一個(gè)步驟。越接近傳輸?shù)哪┒耍瑢?duì)記錄的重組就越復(fù)雜、越耗費(fèi)時(shí)間和資源，最終形成以傳統(tǒng)列存儲(chǔ)的高度壓縮和讀取優(yōu)化格式。 此外，SAP HANA 數(shù)據(jù)庫提供了歷史表（historic table）的概念，可以透明地將記錄的歷史版本移動(dòng)到單獨(dú)的表結(jié)構(gòu)中。因此，在建表時(shí)，就必須將表定義為“historic”類型。此外，從應(yīng)用的角度來看，分區(qū)（partitioning）概念的應(yīng)用可以將最近的數(shù)據(jù)集與穩(wěn)定的數(shù)據(jù)集分隔開來。
4.4 總結(jié)
如上所述，SAP HANA 數(shù)據(jù)庫通過對(duì)記錄進(jìn)行生命周期管理，為事務(wù)型和分析型工作負(fù)載提供高效訪問。圖 11 對(duì)比了所討論的不同存儲(chǔ)格式和傳播的特征。L1-delta 針對(duì)更新密集型工作負(fù)載進(jìn)行了優(yōu)化，并且可以頻繁地將增量數(shù)據(jù)合并到 L2-delta 結(jié)構(gòu)中。L2-delta 結(jié)構(gòu)已經(jīng)針對(duì)讀取操作進(jìn)行了很好的調(diào)優(yōu)，但是與高度讀取優(yōu)化的 main 結(jié)構(gòu)相比，它產(chǎn)生了更大的內(nèi)存占用。然而，L2-delta 特別適合作為 L1-delta 行或者批量插入的目標(biāo)。如前所述，main 結(jié)構(gòu)可以被分為積極 main 和消極 main，表現(xiàn)出極高的壓縮率，并且針對(duì)基于掃描的查詢模式（query pattern）進(jìn)行了優(yōu)化。由于資源密集型重組任務(wù)，與積極 main 結(jié)構(gòu)的合并，尤其是創(chuàng)建新的 main 結(jié)構(gòu)的完全合并的頻率非常低。相比之下，L1-delta 到 L2-delta 的合并可以通過將數(shù)據(jù)附加到 L2-delta 的字典和 value index 中遞增進(jìn)行。
結(jié)論
眾所周知，列存儲(chǔ)系統(tǒng)可以為 OLAP 型工作負(fù)載提供卓越的性能。 通常而言，列式數(shù)據(jù)布局極其適合那些涉及數(shù)百萬行卻僅僅需要其中幾列數(shù)據(jù)的聚合查詢。但是，使用不同的系統(tǒng)處理 OLAP 和 OLTP 查詢的方案不再滿足現(xiàn)代業(yè)務(wù)應(yīng)用的最新需求。 主要原因可歸納為兩方面：一方面，運(yùn)營系統(tǒng)將越來越多的即時(shí)業(yè)務(wù)決策統(tǒng)計(jì)操作嵌入到個(gè)人業(yè)務(wù)流程中；另一方面，傳統(tǒng)的數(shù)據(jù)倉庫基礎(chǔ)設(shè)施需要捕獲事務(wù)流（transactions feed）以進(jìn)行實(shí)時(shí)分析。在本文中，我們基于 SAP HANA 數(shù)據(jù)庫的經(jīng)典列存儲(chǔ)架構(gòu)，概述了涵蓋查詢轉(zhuǎn)換、計(jì)劃生成和不同專用引擎交互模型的查詢處理環(huán)境。此外，我們更詳細(xì)地解釋了通用統(tǒng)一表數(shù)據(jù)結(jié)構(gòu)。這種由不同狀態(tài)組成的數(shù)據(jù)結(jié)構(gòu)為消費(fèi)查詢引擎提供了一個(gè)通用接口。本文的總體目標(biāo)是介紹一些在 SAP HANA 數(shù)據(jù)庫中實(shí)施的優(yōu)化措施，使得列存儲(chǔ)適用于大規(guī)模事務(wù)處理，糾****正人們關(guān)于列存技術(shù)僅用于 OLAP 型工作負(fù)載的偏見。
致謝
我們真誠感謝位于沃爾多夫、首爾、柏林和帕洛阿托的 SAP HANA 數(shù)據(jù)庫團(tuán)隊(duì)，感謝他們讓 HANA 的故事成為現(xiàn)實(shí)。
如果您對(duì)我們的源碼感興趣，歡迎到我們的 GitHub 代碼倉庫閱讀查看，覺得不錯(cuò)記得點(diǎn)個(gè) Star 哦~
StoneDB 代碼倉庫：https://github.com/stoneatom/stonedb
StoneDB 社區(qū)官網(wǎng)：https://stonedb.io/
