刀尖上的乾坤大挪移 ：RapidsDB技術大起底

大數據和互聯網時代，正沖擊每一個行業，技術的日新月異，令人目不暇接，但是從整個行業來看，基于Hadoop的批量大數據處理方式，以及基于內 存數據庫和內存計算的實時處理和分析，已經慢慢成熟，并且成為了事實上的標準。隨著內存閃存造價的不斷下降和技術的不斷成熟，基于MPP海量并行技術的內 存數據倉庫，不再是遙不可及的傳說，并成為了我們身邊觸手可及的應用。使用標準的PC服務器，我們就能夠在企業中隨意搭建這么一套內存MPP的數據倉庫， 并結合業務對身邊的大數據作出實時的決策。

本篇文章來自柏睿數據CTO劉睿民先生，作為國產軟件在高端基礎技術上吃螃蟹的人，劉睿民將會介紹柏睿數據公司出品的重要產品— MPP內存數據倉庫Rapids DB的重要特性，以及實現過程中的一些技術細節。

RapidsDB 進入關鍵應用系統

早在2014年，公司成立尚短，產品尚在研發階段的時候，作為國產的一款內存數據庫，RapidsDB就已經引起了國內主要運營商和一些對數據查詢處理速度有高要求的企業的關注，并提出了試用申請。

2014年12月，隨著RapidsDB V1.0版本推出，作為一款海量數據高速處理引擎，RapidsDB正式進入聯通實際項目，作為客戶用戶搜索的一個重要數據處理平臺投入使用，緊密耦合了 當下的Hadoop技術，每日為上億級別的數據提供處理支持。這意味著RapidsDB已經有能力滿足海量數據的處理要求，同時也能夠支持復雜、高可靠的 企業級應用。

RapidsDB 組件

RapidsDB產品設計之初就是一個完全并行的，基于分布式內存的分析型數據倉庫。理論上來說，它是可以運行在一系列不同的新一代存儲介質之上，使用最接近人類思維的SQL語句來操縱及查詢分布在并行節點上的千億級別數據。

RapidsDB的一個簡單的示意如圖1所示，用戶只需要專注于SQL語句的編寫，復雜的分布式內存處理及查詢優化，則交由系統底層來自動處理。

圖1 RapidsDB示意

存儲在各個節點內存中的分布式數據，被統一地管理和訪問，用戶將查詢語句提交給RapidsDB的分布式查詢引擎DQS，DQS（Distributed Query System）又由DQC和DQE幾個組件來共同組成。

以下我對組成RapidsDB的幾個部件進行一個簡要的說明。

數據存儲（Data Store）

The Data Store是一種分布式內存數據存儲系統，我們往往把需要查詢的數據存儲在節點對應的內存當中，Data Store由Storage Engine進行管理。并且通過DQS的接口進行查詢和簡單的事務處理。

分布式查詢系統（DQS）

分布式查詢系統為用戶提供了查詢內存數據的SQL接口。用戶不需要知道知道數據存儲在哪一個節點當中，DQS保存了數據存儲相關的元數據，通過解析用戶的查詢語句，DQS能夠直接和存儲的數據進行交互。

DQS連接器

DQS支持與底層存儲的引擎接口插件技術，也可以叫做DQS連接器。連接器被部署在每一個節點的存儲引擎當中，利用本地存儲引擎的能力，將用戶查詢語句直接在該節點進行處理。在未來，連接器還將提供相應的SDK，允許第三方開發的連接器訪問他們自己選擇的存儲引擎。

分布式查詢協調器（Distributed Query Coordinator）

DQC接收用戶提交的指令并進行處理。用戶可以通過命令行界面（CLI）提交查詢，或通過RapidsDB的編程API提交查詢。DQC將解析查 詢語句，然后建立一個并行查詢計劃，同時將該查詢計劃交給分布在每一個節點的執行者（DQEs）執行。DQC將吸收所有DQEs的結果，其中可能包括額外 的處理如聚集或排序，然后將結果返回給調用者。

分布式查詢執行器Distributed Query Executor (DQE)

分布式查詢執行器（DQE）負責響應在每一個Data Store中的數據子集。通常在每個有存儲引擎實例運行的節點中，都會有一個DQE系統。DQE負責執行查詢計劃，DQE將使用相關DQS連接器在查詢計劃與相關的存儲引擎進行通信。并且返回查詢結果給用戶。

配置管理（Configuration Management）

RapidsDB使用ZooKeeper作為集群配置管理工具。

RapidsDB 功能介紹

RapidsDB雖然主要的訴求是一款面向分析的分布式內存數據倉庫，其實它本身具有OLTP和OLAP雙引擎，能夠滿足簡單的事務處理和 ACID操作，同時又有最大可能性能滿足時下大數據所面臨的超大規模數據庫跨節點的大表關聯應用，并且在提供實用功能的同時，可以通過實時添加節點數及內 存大小，來實現性能的橫向擴展。

數據分布方式

整體而言，RapidsDB使用Shared Nothing結構：整個數據庫的數據分散到集群的多臺機器上。RapidsDB的數據分布策略是基于哈希的，存儲在RapidsDB中的每一張表，對數 據的主鍵哈希取模后的結果，對應于數據存儲的節點。相較于BigTable基于主鍵的連續范圍分段的方法，哈希方法的好處是數據分散均勻，沒有動態數據調 整的煩惱。但也有很多缺點，采用這種方法后，集群的規模是事先確定好的。另外，數據哈希被分散后，數據的連續性被打亂了，在這個數據結構上做范圍查詢需要 動用服務這張表的所有機器。

數據事務處理

為了充分發揮多核機器的性能，而又不引入多線程執行事務的復雜性，Rapids DB的數據分片規模是按照集群核數來劃分的。一臺物理機器上可能運行多個Rapids DB服務器進程，每個進程對應于一個核，服務器進程之間都是通過網絡進行通信。在單個進程內，只使用單線程，所有的事務執行都按順序進行。

多個事務在多個服務器節點同時執行，Rapids DB保證如果事務之間有沖突，那么事務的執行是完全隔離的，即達到SERIALIZABLE ISOLATION。Rapids DB會事先分析好存儲過程之間的關系，如果兩個事務可能存在沖突，則不讓這兩個進程在同一個時間執行。

圖2  Rapids DB并發處理

在Rapids DB的并發處理中，每一個事務在執行之前都要等待一個Round Trip時間，顯然會增加事務執行的時延。這么做是為了確保別的節點沒有發起比這個事務更早的事務，保證事務執行的順序。在實現中，Rapids DB用了另外一種優化方法。例如A，B兩個節點，分別要執行事務1和2，A節點開始執行事務1的時間是T1，如果A收到B發了事務2的執行需求，并且T2 > T1，那么A節點可以確認從B節點不會有更早的事務再發送過來，A節點就不必等Round Trip時間，可以直接執行事務1。當整個系統壓力比較大時，這個優化方法效果尤其明顯，事務的時延有效降低。

Rapids DB還花了很大精力在處理事務之間的邏輯關系，盡可能對事務分門別類進行處理，以期獲得更好的性能。

數據安全保障

和傳統數據庫提供的HA解決方案不同，Rapids DB提供三種HA能力：K-safety，網絡故障檢測，存活結點重連(rejoin)。

K-safety（通過數據多副本方式實現數據安全）

當配置成K-safety時，Rapids DB會自動地復制數據庫分區，K表示副本的個數。例如K=0時表示沒有副本，所以任何一個結點的故障，都會導致整個數據庫集群停止服務。當K=1時表示有 1個副本，即一共2份拷貝。RapidsDB中的副本是可以讀寫的，而不是傳統的主從復制關系。

關于數據同步問題的解決，任何發生在復制分區上的操作，都會發送給各個拷貝的結點去執行，來保證一致性。如果其中一個結點失敗，那么數據庫會繼續 發送這個操作給失敗的結點。因此在這一點上Rapids DB與傳統數據庫有很大不同，不存在多主(multi-master)情況下的數據同步沖突問題。所以K-safety也叫做同步多主復制。

網絡故障檢測

當網絡發生故障時，Rapids DB的結點彼此之間被物理隔離開，而認為對方已經發生故障。那么K-safety機制會使這兩側的結點繼續分別提供服務。如果不及時檢測到的話，這種“分 離的大腦”(split brain)會導致嚴重的數據同步問題。因此，Rapids DB會自動檢測網絡故障，立即評估出哪一側結點應該繼續服務，并快照另一側的結點數據后停掉服務。網絡故障解決時，可以直接使用下面將介紹到的存活結點重 連技術將結點重新加入到集群中。

存活結點重連

萬一出現了離線的節點，離線了的RapidsDB結點可以通過rejoin操作重新加入到集群中。具體過程是：首先從兄弟結點獲得一份數據拷貝，當追趕上兄弟結點時，此存活結點就可以回到正常狀態，繼續接受任務了。

數據編程接口

Rapids DB提供了主流編程語言的相應接口，可以通過客戶端連接后編程，對數據庫進行操作，復雜查詢使用CLI方式訪問。Rapids DB編程當中的事務操作，從需求來看，既需要支持復雜的事務操作，又需要快速的執行過程。由于RapidsDB主要聚焦的是分析性的復雜查詢，因此對事務 的控制方面，所有事務均采用自動提交，不支持手動提交事務。不允許用戶使用傳統的OLTP中“Begin Transaction”和“End Transaction”的語法模式，而是完全基于Java編寫的存儲過程。用戶通過寫Java存儲過程完成應用程序的邏輯，作為一個先置條件將Java 存儲過程提交到RapidsDB。運行時，用戶程序調用存儲過程完成事務操作，所有事務的運行邏輯是由RapidsDB在服務器進程中完成的。這保證了事 務不會被人為打斷，并且服務器可以預先判斷各個事務的邏輯，提高并發效率。

系統橫向比較

橫向比較而言，許多人會首先想到Oracle的內存數據庫TimesTen。最明顯的區別就是，TT不是個MPP的架構，無法橫向擴展；而 RapidsDB強調的不僅僅是內存中存儲數據，還更加強調內存中可以執行復雜計算及復雜查詢。雖然TT支持數據復制功能，但是RapidsDB是一個真 正的MPP Cluster，一個表可以被Hash到每一個節點上，CPU并行計算，以此來提高硬件利用率，而TT則只是單純通過數據復制來提高性能。

作者： 劉睿民

簡介： 柏睿數據科技有限公司董事長兼CTO、艾諾威訊（北京）科技有限公司首席執行官、聯想中國服務總部首席技術顧問、國家信標委ISO SC32國際專家國家信標委ISO WG10 IoT物聯網國際協調員。