余楷,李志方,周敏奇,周傲英

(華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院,上海200062)

非阻塞事務(wù)型實(shí)時(shí)數(shù)據(jù)注入技術(shù)研究與實(shí)現(xiàn)

余楷,李志方,周敏奇,周傲英

(華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院,上海200062)

伴隨著大數(shù)據(jù)時(shí)代來臨,傳統(tǒng)數(shù)據(jù)庫系統(tǒng)已逐漸無法應(yīng)對(duì)海量數(shù)據(jù)處理帶來的挑戰(zhàn),而分布式數(shù)據(jù)庫系統(tǒng)得到了越來越多的部署和應(yīng)用.分布式數(shù)據(jù)庫系統(tǒng)部署數(shù)據(jù)于多臺(tái)機(jī)器上,利用大規(guī)模并行計(jì)算技術(shù)實(shí)現(xiàn)了對(duì)海量數(shù)據(jù)的存儲(chǔ)、管理和分析.但針對(duì)金融領(lǐng)域嚴(yán)苛的事務(wù)型實(shí)時(shí)數(shù)據(jù)注入需求,現(xiàn)有分布式數(shù)據(jù)庫系統(tǒng)對(duì)其支持有限,其主要原因在于利用鎖和兩階段提交等方式實(shí)現(xiàn)分布式事務(wù)處理,無法做到非阻塞式數(shù)據(jù)注入,極大地影響了數(shù)據(jù)注入的性能.華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院自主研發(fā)的分布式內(nèi)存數(shù)據(jù)庫系統(tǒng)—-CLAIMS,已能提供面向關(guān)系型數(shù)據(jù)集的實(shí)時(shí)數(shù)據(jù)分析服務(wù),但尚不能支持實(shí)時(shí)數(shù)據(jù)注入.針對(duì)上述實(shí)時(shí)數(shù)據(jù)注入的問題,本文重點(diǎn)分析了現(xiàn)有數(shù)據(jù)注入技術(shù)和基于分布式事務(wù)處理的實(shí)現(xiàn)方式,設(shè)計(jì)了面向元數(shù)據(jù)的集中式事務(wù)處理策略,利用無鎖編程技術(shù),實(shí)現(xiàn)了支持分布式事務(wù)的高性能實(shí)時(shí)數(shù)據(jù)注入框架,并通過熱備機(jī)制實(shí)現(xiàn)系統(tǒng)的高可用性.上述框架在CLAIMS系統(tǒng)中的實(shí)現(xiàn),經(jīng)充分實(shí)驗(yàn)表明:該框架能夠?qū)崿F(xiàn)高通量的事務(wù)型實(shí)時(shí)數(shù)據(jù)注入,同時(shí)支持低延時(shí)的實(shí)時(shí)數(shù)據(jù)查詢.

分布式數(shù)據(jù)庫;實(shí)時(shí)數(shù)據(jù)注入;事務(wù);CLAIMS

0 引言

隨著信息技術(shù)的快速成熟和互聯(lián)網(wǎng)的高速發(fā)展,傳統(tǒng)行業(yè)加速信息化.大型企業(yè)的數(shù)據(jù)規(guī)模普遍已經(jīng)達(dá)到TB級(jí),甚至PB級(jí),同時(shí)每天仍以TB的量級(jí)不斷增加.應(yīng)對(duì)海量數(shù)據(jù)對(duì)數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)分析帶來的巨大挑戰(zhàn),目前業(yè)界使用的解決方案是基于MapReduce框架[1]的HADOOP和SPARK[2].兩者構(gòu)建在分布式文件系統(tǒng)HDFS上,由其負(fù)責(zé)將巨大的數(shù)據(jù)集分派到集群中的多個(gè)節(jié)點(diǎn)進(jìn)行存儲(chǔ),同時(shí)提供良好的容錯(cuò)性[3],實(shí)現(xiàn)數(shù)據(jù)的多備份策略. HADOOP使用MapReduce模式實(shí)現(xiàn)并行計(jì)算,具有天然的容錯(cuò)能力;后者主要在內(nèi)存中處理和分析所有數(shù)據(jù),不寫回中間結(jié)果到磁盤,極大地提高性能.同樣地,內(nèi)存數(shù)據(jù)庫將數(shù)據(jù)全部存放于內(nèi)存,使數(shù)據(jù)的查詢分析性能提升一個(gè)數(shù)量級(jí).SAP HANA[4-5]和Exalytics[6]作為內(nèi)存數(shù)據(jù)庫的代表,提供數(shù)據(jù)的實(shí)時(shí)查詢分析,達(dá)到秒級(jí)的響應(yīng)速度.

數(shù)據(jù)從事件發(fā)生到支持決策經(jīng)歷多次延遲:數(shù)據(jù)注入延遲、分析延遲、決策延遲,實(shí)時(shí)數(shù)據(jù)的價(jià)值依次遞減.為了減少企業(yè)因數(shù)據(jù)延遲帶來的經(jīng)濟(jì)損失,數(shù)據(jù)需要在實(shí)際產(chǎn)生后立刻實(shí)時(shí)注入數(shù)據(jù)庫系統(tǒng)中,同時(shí)立即提供實(shí)時(shí)的查詢和數(shù)據(jù)分析,以同時(shí)降低注入延遲和分析延遲.而數(shù)據(jù)的實(shí)時(shí)存儲(chǔ)和分析都基于實(shí)時(shí)數(shù)據(jù)注入的基礎(chǔ)上,因此數(shù)據(jù)注入延遲更顯重要.大數(shù)據(jù)環(huán)境下的數(shù)據(jù)注入不僅注入數(shù)據(jù)量非常巨大,同時(shí)數(shù)據(jù)注入的速度要求極高.實(shí)際需求中,實(shí)時(shí)注入和實(shí)時(shí)分析同時(shí)執(zhí)行,并按需實(shí)現(xiàn)兩者隔離(如實(shí)現(xiàn)read committed等隔離級(jí)別).在更加嚴(yán)格的金融領(lǐng)域,數(shù)據(jù)注入必須支持事務(wù),保證數(shù)據(jù)的持久性和一致性.以上現(xiàn)實(shí)需求對(duì)數(shù)據(jù)注入提出以下要求:

1.實(shí)現(xiàn)較高性能的數(shù)據(jù)注入,壓縮注入延遲在毫秒量級(jí),實(shí)現(xiàn)數(shù)據(jù)注入的實(shí)時(shí)性;

2.通過事務(wù)處理的方式保證實(shí)時(shí)數(shù)據(jù)注入過程中數(shù)據(jù)的完整性和一致性;

3.對(duì)數(shù)據(jù)注入和數(shù)據(jù)分析進(jìn)行必要的隔離,以保證數(shù)據(jù)實(shí)時(shí)注入不影響實(shí)時(shí)數(shù)據(jù)查詢、分析執(zhí)行及其正確性.

面對(duì)大數(shù)據(jù)時(shí)代對(duì)海量數(shù)據(jù)存儲(chǔ)管理和實(shí)時(shí)分析的需求,華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院自主研發(fā)了支持高性能數(shù)據(jù)查詢的集群感知分布式內(nèi)存數(shù)據(jù)庫--CLAIMS(Cluster Aware In-Memory SQL engine).CLAIMS系統(tǒng)基于Master-Slave的Shared-Nothing架構(gòu),利用大規(guī)模并行計(jì)算提供基于關(guān)系型數(shù)據(jù)集的高性能實(shí)時(shí)數(shù)據(jù)分析[7],并極大降低分析延遲.然而,針對(duì)注入延遲問題,CLAIMS暫時(shí)不能提供高效的解決方案.

針對(duì)CLAIMS的數(shù)據(jù)注入框架無法實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)注入并實(shí)現(xiàn)系統(tǒng)容錯(cuò)等問題,本文摒棄傳統(tǒng)基于分布式事務(wù)處理的實(shí)現(xiàn)方式,廣泛使用無鎖結(jié)構(gòu)與算法,以等價(jià)的面向元數(shù)據(jù)的集中式事務(wù)處理方式替代傳統(tǒng)的分布式事務(wù)型實(shí)時(shí)數(shù)據(jù)注入方式.主要貢獻(xiàn)如下:

1.擴(kuò)展傳統(tǒng)的單機(jī)數(shù)據(jù)注入為面向分布式系統(tǒng)的數(shù)據(jù)注入,充分利用集群多臺(tái)機(jī)器的資源,避免由于單機(jī)資源耗盡導(dǎo)致的性能瓶頸.

2.結(jié)合HDFS系統(tǒng)中文件只能截?cái)?無法被修改的特性,設(shè)計(jì)實(shí)現(xiàn)面向服務(wù)的分布式并發(fā)控制機(jī)制.該系統(tǒng)基于無鎖思想,利用事務(wù)快照實(shí)現(xiàn)“讀寫分離”,預(yù)分配分布式節(jié)點(diǎn)內(nèi)存來實(shí)現(xiàn)“寫寫分離”,大幅度提升數(shù)據(jù)注入和查詢的性能,實(shí)現(xiàn)非阻塞實(shí)時(shí)數(shù)據(jù)注入.

3.在實(shí)時(shí)數(shù)據(jù)注入的同時(shí),對(duì)外提供強(qiáng)一致性的實(shí)時(shí)數(shù)據(jù)查詢分析,并實(shí)現(xiàn)數(shù)據(jù)的快照隔離級(jí)別.

4.實(shí)驗(yàn)證明本文所提出的分布式實(shí)時(shí)數(shù)據(jù)注入框架具有較高的數(shù)據(jù)注入性能、較低的數(shù)據(jù)注入延遲與較高的事務(wù)型數(shù)據(jù)注入吞吐量,滿足大多數(shù)實(shí)時(shí)注入的需求,并提供數(shù)據(jù)的完整性保證.

本文第1節(jié)介紹數(shù)據(jù)實(shí)時(shí)注入實(shí)現(xiàn)技術(shù)和分布式事務(wù)處理的方式,以及本文實(shí)驗(yàn)基于的CLAIMS系統(tǒng)的架構(gòu);第2節(jié)闡述分布式數(shù)據(jù)注入的設(shè)計(jì)、分布式事務(wù)管理的設(shè)計(jì)實(shí)現(xiàn)等;第3節(jié)對(duì)實(shí)現(xiàn)的框架進(jìn)行測試和對(duì)比實(shí)驗(yàn);最后一節(jié)是本文的總結(jié).

1 相關(guān)工作

實(shí)時(shí)數(shù)據(jù)注入是指數(shù)據(jù)從消息隊(duì)列系統(tǒng)注入到數(shù)據(jù)庫系統(tǒng)的延時(shí)較低(通常在毫秒級(jí)別),并實(shí)現(xiàn)對(duì)數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)實(shí)時(shí)更新,是大幅提升數(shù)據(jù)的處理價(jià)值的必要前提.對(duì)實(shí)時(shí)數(shù)據(jù)的實(shí)時(shí)分析,包括數(shù)據(jù)注入的實(shí)時(shí)性和數(shù)據(jù)分析的實(shí)時(shí)性,并通過隔離數(shù)據(jù)注入和數(shù)據(jù)分析實(shí)現(xiàn)數(shù)據(jù)分析的一致性.本文工作主要面向CLAIMS系統(tǒng)的分布式系統(tǒng)環(huán)境,實(shí)現(xiàn)事務(wù)型實(shí)時(shí)數(shù)據(jù)注入.下面從分布式實(shí)時(shí)注入、分布式系統(tǒng)的事務(wù)處理、CLAIMS系統(tǒng)三個(gè)方面來介紹本文的相關(guān)工作.

1.1 分布式數(shù)據(jù)實(shí)時(shí)注入

目前流行的大數(shù)據(jù)分析工具對(duì)數(shù)據(jù)實(shí)時(shí)注入支持較不完善,例如Facebook開源的分布式SQL查詢引擎Presto和SPARKSQL都針對(duì)于分布式查詢問題,在海量數(shù)據(jù)上提供分布式的SQL查詢能力,但無法保證實(shí)時(shí)的數(shù)據(jù)加載[8-9].Druid是一個(gè)列存儲(chǔ)的分布式數(shù)據(jù)存儲(chǔ)[10],專門為了快速導(dǎo)入海量數(shù)據(jù)并立即對(duì)外提供查詢而設(shè)計(jì),但是它查詢上不支持SQL,使其在電信、金融服務(wù)等依賴SQL的行業(yè)無法廣泛使用.不同于Druid,Pinot同時(shí)支持實(shí)時(shí)數(shù)據(jù)注入和SQL語句查詢.Pinot[12]劃分?jǐn)?shù)據(jù)為兩類,離線數(shù)據(jù)(存于HADOOP等)和在線的準(zhǔn)實(shí)時(shí)數(shù)據(jù)(存于Kafka).然而Pinot不支持SQL中極為重要的JOIN語義,因此無法滿足現(xiàn)實(shí)的需求.同時(shí)其受限于Kafka支持的“At Least Once”消息消費(fèi)模型[13],可能出現(xiàn)重復(fù)冗余的消息,應(yīng)用場景有限.因此實(shí)時(shí)數(shù)據(jù)注入需要支持事務(wù)的四個(gè)特性:ACID[11](原子性、一致性、隔離性、持久性).Vertica[14]、HAWQ[15]作為支持批量數(shù)據(jù)事務(wù)型注入功能的系統(tǒng)代表,不能將最新插入的數(shù)據(jù)反映在查詢中,無法滿足實(shí)時(shí)查詢的需求.目前支持事務(wù)型分布式數(shù)據(jù)實(shí)時(shí)注入和數(shù)據(jù)實(shí)時(shí)查詢的系統(tǒng)只有VoltDB,因此該系統(tǒng)是本文的實(shí)驗(yàn)對(duì)照對(duì)象.

1.2 分布式系統(tǒng)的事務(wù)處理

分布式系統(tǒng)中數(shù)據(jù)處于不同的機(jī)器節(jié)點(diǎn),需要事務(wù)支持來保證數(shù)據(jù)的ACID特性.

1.2.1 兩階段提交

分布式事務(wù)一般通過鎖和兩階段提交協(xié)議(Two-phase Commit,2PC)來實(shí)現(xiàn)[23],分為一個(gè)協(xié)調(diào)者和多個(gè)資源管理者角色.該協(xié)議將分布式事務(wù)劃分為兩個(gè)階段:預(yù)提交階段和提交階段.協(xié)議的執(zhí)行通過阻塞操作完成,大幅影響計(jì)算資源的使用率和事務(wù)性能,兩階段提交涉及多次節(jié)點(diǎn)間的網(wǎng)絡(luò)通信,通信時(shí)間大大延長.由于鎖的阻塞,資源的等待時(shí)間大量增加.其核心問題是如果協(xié)調(diào)者宕機(jī),整個(gè)系統(tǒng)將處于不可用狀態(tài).針對(duì)2PC的缺點(diǎn),三階段提交協(xié)議被提出[25],但其網(wǎng)絡(luò)延遲再次增大,無法作為有效的解決方案.

1.2.2 多版本事務(wù)處理

除了基于鎖的事務(wù)并發(fā)控制,多版本事務(wù)并發(fā)控制得到廣泛的使用.每個(gè)數(shù)據(jù)項(xiàng)對(duì)應(yīng)于多個(gè)副本,更一般的情況是,不同事務(wù)可以對(duì)相同數(shù)據(jù)項(xiàng)的不同版本進(jìn)行讀和寫[20].基于多版本的并發(fā)控制方法可以實(shí)現(xiàn)寫寫分離和讀寫分離以避免事務(wù)執(zhí)行過程中的阻塞.SQL Server 2014中的Hekaton內(nèi)存計(jì)算框架就是基于多版本并發(fā)控制實(shí)現(xiàn)[21].表中的每個(gè)元組均保存有多個(gè)不同版本的副本(基于時(shí)間戳),刪除和修改元組時(shí)創(chuàng)建新的版本.讀取數(shù)據(jù)的時(shí)候根據(jù)時(shí)間戳只讀取定版本的數(shù)據(jù).由于Hekaton系統(tǒng)是集中式數(shù)據(jù)庫,對(duì)使用的單臺(tái)機(jī)器性能有較高要求,因此在可拓展性和成本方面有較多要求,嚴(yán)重地限制其應(yīng)用場景.

1.2.3 基于單線程的事務(wù)處理

多線程并發(fā)的事務(wù)處理有許多限制和要求,甚至反而降低性能,因此單線程的事務(wù)并發(fā)處理框架被提出.該框架將數(shù)據(jù)進(jìn)行切分,在每個(gè)數(shù)據(jù)分區(qū)上僅有單個(gè)線程進(jìn)行讀寫,避免事務(wù)執(zhí)行的沖突,從而完全避免鎖的開銷和其他多線程并發(fā)控制的開銷.Micheal Stonebraker主導(dǎo)的H-Store/VoltDB分布式內(nèi)存數(shù)據(jù)庫就基于單線程的事務(wù)處理,簡化并發(fā)控制的機(jī)制[16].通過在集群中簡單增加節(jié)點(diǎn)的方式VoltDB可實(shí)現(xiàn)性能的線性增加,因此目前的分布式事務(wù)處理系統(tǒng)中VoltDB擁有幾乎最高的性能.

1.3 CLAIMS系統(tǒng)

CLAIMS系統(tǒng)作為分布式內(nèi)存計(jì)算系統(tǒng),提供高性能的實(shí)時(shí)交互式數(shù)據(jù)分析與處理.不同于NOSQL[26],CLAIMS支持SQL92,兼容金融等領(lǐng)域的歷史上層應(yīng)用.

圖1 CLAIMS系統(tǒng)架構(gòu)圖Fig.1System architecture of CLAIMS

CLAIMS系統(tǒng)采用經(jīng)典的主從架構(gòu)(Master-Slave),集群包括一個(gè)主節(jié)點(diǎn)和若干個(gè)從節(jié)點(diǎn),如圖1所示.主節(jié)點(diǎn)接收SQL語句并解析,生成查詢計(jì)劃分發(fā)給從節(jié)點(diǎn),最后匯總結(jié)果集,管理和調(diào)度每臺(tái)機(jī)器上的計(jì)算資源和查詢執(zhí)行過程.主節(jié)點(diǎn)包括SQL解析器、查詢優(yōu)化器、數(shù)據(jù)字典管理器、集群資源管理器、全局調(diào)度器、協(xié)調(diào)器六個(gè)組件.從節(jié)點(diǎn)主要負(fù)責(zé)在內(nèi)存實(shí)際存取數(shù)據(jù)和接收并執(zhí)行查詢計(jì)劃,由執(zhí)行器、資源管理器、單機(jī)調(diào)度器、存儲(chǔ)管理器四個(gè)組件組成.

2 實(shí)時(shí)數(shù)據(jù)注入框架的設(shè)計(jì)實(shí)現(xiàn)

為了實(shí)現(xiàn)面向CLAIMS的事務(wù)型實(shí)時(shí)數(shù)據(jù)注入框架,在深刻理解CLAIMS系統(tǒng)架構(gòu)的基礎(chǔ)上,參考各類分布式事務(wù)處理系統(tǒng)的設(shè)計(jì)經(jīng)驗(yàn),本文提出新型的事務(wù)處理控制方式,設(shè)計(jì)并實(shí)現(xiàn)以下的一系列功能:

1.針對(duì)實(shí)時(shí)數(shù)據(jù)注入對(duì)應(yīng)的追加型事務(wù),采用面向元數(shù)據(jù)的集中式事務(wù)處理的策略,實(shí)現(xiàn)事務(wù)性數(shù)據(jù)注入,以避免直接對(duì)分布式數(shù)據(jù)注入操作實(shí)現(xiàn)事務(wù)性管理.

2.非阻塞式分布式數(shù)據(jù)注入框架,將傳統(tǒng)的集中式單機(jī)數(shù)據(jù)注入轉(zhuǎn)變?yōu)榉植际綌?shù)據(jù)注入,充分利用多臺(tái)機(jī)器的性能,避免性能受限于單機(jī)的處理瓶頸.

3.提供強(qiáng)一致性的數(shù)據(jù)查詢模型,實(shí)時(shí)注入的數(shù)據(jù)在后續(xù)的實(shí)時(shí)查詢中即時(shí)可見,支持在實(shí)時(shí)注入更新的數(shù)據(jù)集上實(shí)時(shí)查詢.

4.使用log-shipping技術(shù)實(shí)現(xiàn)數(shù)據(jù)熱備,面對(duì)服務(wù)機(jī)器宕機(jī)支持快速切換,對(duì)外提供高可用性的服務(wù),滿足金融領(lǐng)域的可用性要求.

在當(dāng)前的CLAIMS的系統(tǒng)架構(gòu)基礎(chǔ)下,本文設(shè)計(jì)如圖2的系統(tǒng)架構(gòu),并實(shí)現(xiàn)并行的實(shí)時(shí)數(shù)據(jù)注入框架和原有的實(shí)時(shí)數(shù)據(jù)分析框架,兩者之間互不阻塞.

圖2 CLAIMS數(shù)據(jù)注入框架Fig.2Framework of data ingestion in CLAIMS

2.1 框架總體設(shè)計(jì)

如圖2所示,實(shí)時(shí)數(shù)據(jù)注入框架主要分為數(shù)據(jù)實(shí)時(shí)注入器以及事務(wù)管理器(TM)、HDFS持久存儲(chǔ)層.數(shù)據(jù)注入器主要分為主注入器(下稱Coordinator)和從注入器(下稱Worker).完整的數(shù)據(jù)注入框架包括一個(gè)事務(wù)管理器、多個(gè)Coordinator、多個(gè)Worker和持久存儲(chǔ)層HDFS.其中Coordinator和Worker可共存于同一機(jī)器節(jié)點(diǎn).

數(shù)據(jù)注入引擎中各組件功能如下所示:

·TM:管理所有事務(wù)相關(guān)的數(shù)據(jù)并維護(hù)事務(wù)狀態(tài),向其他節(jié)點(diǎn)提供事務(wù)管理服務(wù).

·Coordinator:多個(gè)Coordinator獨(dú)立提供服務(wù).每個(gè)Coordinator從MQ拉取數(shù)據(jù)注入請(qǐng)求,對(duì)數(shù)據(jù)進(jìn)行合法性等檢查,向TM申請(qǐng)事務(wù)的支持,獲得該事務(wù)預(yù)分配的注入地址后,將注入任務(wù)切分為多個(gè)Worker上的子任務(wù)并分發(fā)給對(duì)應(yīng)的Worker.在Worker完成(commit或者abort)事務(wù)后收集反饋,提交給TM.接收反饋超時(shí)則采取重試一次的策略,再失敗則認(rèn)定事務(wù)失敗,并提交給TM.

·Worker:每個(gè)Worker負(fù)責(zé)該節(jié)點(diǎn)上綁定的所有數(shù)據(jù)分區(qū)的讀寫操作.其接收從Coordinator發(fā)送的注入任務(wù),并在對(duì)應(yīng)數(shù)據(jù)分區(qū)上實(shí)際執(zhí)行.所注入的數(shù)據(jù)被保存Worker節(jié)點(diǎn)的內(nèi)存中,提供快速查詢與訪問.

·持久存儲(chǔ)層:CLAIMS系統(tǒng)采用HDFS作為Worker內(nèi)存中已提交的歷史數(shù)據(jù)持久化的介質(zhì).一旦寫入HDFS中,則由HDFS保證數(shù)據(jù)不會(huì)丟失.

Coordinator同Worker共用機(jī)器以充分利用每個(gè)節(jié)點(diǎn)的性能.一般情況可選用單Coordinator多Worker的架構(gòu),實(shí)現(xiàn)難度較低,對(duì)性能要求較高時(shí)可采用多Coordinator多Worker架構(gòu)來提高系統(tǒng)的吞吐率,防止單一的Coordinator成為系統(tǒng)的瓶頸.理論上可通過增大Coordinator和Worker節(jié)點(diǎn)的數(shù)量達(dá)到近線性橫向拓展CLAIMS的數(shù)據(jù)注入處理能力. 2.2事務(wù)并發(fā)控制

2.2.1 事務(wù)對(duì)象模型

傳統(tǒng)數(shù)據(jù)采用頁模型和對(duì)象模型[20],其任何對(duì)數(shù)據(jù)的高層操作最終都要映射為一組對(duì)磁盤頁的Read/Write動(dòng)作.內(nèi)存數(shù)據(jù)庫將表存放在內(nèi)存中,直接進(jìn)行隨機(jī)讀寫操作,相比傳統(tǒng)數(shù)據(jù)庫減少很多限制.本文采用內(nèi)存條帶的概念描述事務(wù)執(zhí)行的對(duì)象,并以如下的三元組的形式描述內(nèi)存條帶s的概念:

s表示在分區(qū)part上,以該分區(qū)的起始地址記為0地址,在［pos,pos+length)之間的連續(xù)內(nèi)存空間.對(duì)于任意二個(gè)內(nèi)存條帶si和sj,如果滿足下面的條件,則稱si和sj是重疊的,表示為si∩sj=?;否則為不重疊,表示為si∩sj?.

類似頁模型,在內(nèi)存條帶s上,本文定義Read和Write二種基本操作,它們表示的含義如下所示:

Read(t,s):掃描分區(qū)s.part中［pos,pos+length)范圍內(nèi)的數(shù)據(jù);

Write(t,s,d):將分區(qū)s.part中［pos,pos+length)范圍內(nèi)的數(shù)據(jù)寫為d,其中t表示某一個(gè)事務(wù).

在分布式事務(wù)t的執(zhí)行中,需要對(duì)多個(gè)內(nèi)存條帶同時(shí)進(jìn)行讀寫操作,所以本文稱一組內(nèi)存條帶的集合為內(nèi)存向量,如下所示:

在內(nèi)存向量上本文拓展了Map,Merge以及Filter三種輔助操作,如下所示:

·Map:該函數(shù)將單個(gè)內(nèi)存向量劃分成多個(gè)內(nèi)存向量的集合.

其中λ為劃分函數(shù),Map操作將所有λ函數(shù)值相同的內(nèi)存條帶劃分到同一個(gè)內(nèi)存向量.在本框架具體實(shí)現(xiàn)中,λ函數(shù)按part值進(jìn)行劃分,每個(gè)part對(duì)應(yīng)一個(gè)內(nèi)存向量.

·Merge:該函數(shù)將內(nèi)存向量內(nèi)相鄰的內(nèi)存條帶進(jìn)行合并,如下所示:

通過合并相鄰內(nèi)存條帶,多次的讀寫簡化為單次讀寫,有效地降低讀寫IO次數(shù),提高系統(tǒng)性能.

·Filter:該函數(shù)對(duì)內(nèi)存向量進(jìn)行過濾,去除所包含的不滿足條件的內(nèi)存條帶.

其中f為過濾函數(shù),Filter函數(shù)將f函數(shù)值為false的內(nèi)存條帶過濾掉,僅保留結(jié)果為true的內(nèi)存條帶集.

通過引入內(nèi)存條帶上的Read/Write操作,以及內(nèi)存向量上的Map,Merge和Filter輔助操作,本文將復(fù)雜的分布式事務(wù)的執(zhí)行過程抽象成上述簡單操作的組合.

2.2.2 事務(wù)處理模型

在CLAIMS的數(shù)據(jù)注入框架中包括消息隊(duì)列MQ,1個(gè)用于集群資源管理的節(jié)點(diǎn)M,1個(gè)用于分布式事務(wù)管理的節(jié)點(diǎn)TM,n個(gè)用于執(zhí)行查詢和注入任務(wù)的工作節(jié)點(diǎn),組成的集合為S.系統(tǒng)中每個(gè)節(jié)點(diǎn)i的機(jī)器都有m個(gè)可利用的處理器核心,組成的集合為Corei.CLAIMS集群中所有被創(chuàng)建的表的集合為T,并且每個(gè)表Ti對(duì)應(yīng)的分區(qū)的集合為PTi.為了簡化問題,本文統(tǒng)一地將所有表中的所有分區(qū)的集合定義為P.

數(shù)據(jù)注入過程中,交易系統(tǒng)將不斷產(chǎn)生的交易流水實(shí)時(shí)地不間斷地分批發(fā)送到作為中間件的消息隊(duì)列MQ中,并隨后被注入到CLAIMS中.對(duì)于某批次b中這些元組所對(duì)應(yīng)的分區(qū)的集合為Pb.對(duì)于某個(gè)分布式注入事務(wù)t,本文定義分區(qū)pi上的注入數(shù)據(jù)d的動(dòng)作為Write(t,si,d),其中si是TM在pi上分配的內(nèi)存條帶,滿足si.part=pi∧pi∈Pb.當(dāng)P′中所有分區(qū)上的操作都成功時(shí),使用操作Commit(t)使注入的t所注入的數(shù)據(jù)對(duì)其他事務(wù)可見;否則調(diào)用Abort(t)撤銷t進(jìn)行的所有修改.

在數(shù)據(jù)被實(shí)時(shí)地注入CLAIMS系統(tǒng)的同時(shí),企業(yè)的分析用戶通過M節(jié)點(diǎn)向CLAIMS集群發(fā)送所要執(zhí)行的SQL查詢語句q.本文假設(shè)q執(zhí)行過程中所要掃描的分區(qū)的集合為Pq, Pq中每個(gè)分區(qū)上已提交的內(nèi)存條帶組成的集合記為sq.q在執(zhí)行過程中依次對(duì)sq中的每個(gè)內(nèi)存條帶都執(zhí)行Read操作,即可獲取查詢q所需數(shù)據(jù).

在數(shù)據(jù)庫的研究領(lǐng)域中,沖突可串行化提供了事務(wù)執(zhí)行所必需的隔離性,在商用系統(tǒng)中具有重要的應(yīng)用價(jià)值,通常被商用數(shù)據(jù)庫強(qiáng)制滿足并執(zhí)行.CLAIMS的實(shí)時(shí)注入引擎和查詢引擎所產(chǎn)生的調(diào)度利用寫寫分離策略保證寫事務(wù)之間的無沖突,利用多版本快照策略來保證讀寫分離,從而保證讀寫事務(wù)并發(fā)控制調(diào)度沖突可串行.

2.2.3 事務(wù)管理器

在分布式實(shí)時(shí)數(shù)據(jù)注入框架中,事務(wù)管理器(TM)主要對(duì)外提供三種服務(wù):第一是原子性分配注入事務(wù)所需的資源并維護(hù)事務(wù)在整個(gè)生命周期內(nèi)的狀態(tài)信息;第二是基于事務(wù)的狀態(tài)信息生成查詢事務(wù)所需要的事務(wù)快照,實(shí)現(xiàn)讀寫分離;第三是周期性地合并連續(xù)內(nèi)存上的連續(xù)事務(wù),依據(jù)合并的事務(wù)信息,幫助各個(gè)Worker節(jié)點(diǎn)發(fā)起數(shù)據(jù)持久化.

為了提供上述服務(wù)功能,TM節(jié)點(diǎn)在內(nèi)存中維護(hù)事務(wù)狀態(tài)表和內(nèi)存分配表.事務(wù)狀態(tài)表記錄并維護(hù)已創(chuàng)建事務(wù)的編號(hào)、事務(wù)提交狀態(tài)和分配內(nèi)存向量等信息.內(nèi)存分配表記錄每個(gè)數(shù)據(jù)分區(qū)的末尾地址,記錄下次分配內(nèi)存的起始地址.

考慮現(xiàn)代機(jī)器基本是多核多CPU,為了充分利用機(jī)器各CPU的性能,TM設(shè)計(jì)成多線程并發(fā)控制結(jié)構(gòu).對(duì)于TM所需要維護(hù)的兩個(gè)結(jié)構(gòu):事務(wù)狀態(tài)表和內(nèi)存分配記錄表,本文摒棄基于鎖的阻塞式策略,采用不同的多線程并發(fā)結(jié)構(gòu)實(shí)現(xiàn)非阻塞式的并發(fā)操作.

現(xiàn)代多級(jí)存儲(chǔ)器體系中,處理器和內(nèi)存之間通常有三級(jí)緩存(cache),緩存的訪問速度遠(yuǎn)大于內(nèi)存.由于緩存大小有限,一般使用LRU算法[26]保存最近頻繁訪問的內(nèi)存,因此滿足“局部性”的程序可充分利用cache顯著提高程序運(yùn)行速率.同時(shí)每個(gè)核有獨(dú)立的L1緩存,由硬件保障其一致性.某個(gè)緩存數(shù)據(jù)的修改會(huì)導(dǎo)致其他核的緩存無效,導(dǎo)致重新載入.

基于上述兩個(gè)cache特性,事務(wù)狀態(tài)表拋棄傳統(tǒng)的由多線程全局共享的方式,切分為多個(gè)線程局部的事務(wù)狀態(tài)子表,如圖3所示.每個(gè)事務(wù)子表由其獨(dú)占的線程負(fù)責(zé)讀、寫、回收等操作.基于線程局部的事務(wù)表切分方式避免多線程并發(fā)操作的沖突,并在一定程度上維持事務(wù)的多線程的性能加速,同時(shí)此方式將事務(wù)子表長久地保存于L1緩存中,免于緩存不命中,同時(shí)每個(gè)CPU只保存一部分的子表,相互間沒有交疊,避免出現(xiàn)緩存失效,減少因?yàn)樽颖眍l繁換入換出緩存帶來的額外性能開銷.

當(dāng)創(chuàng)建注入事務(wù),本文通過特定的策略確定其所在的事務(wù)狀態(tài)子表,并轉(zhuǎn)發(fā)任務(wù)給對(duì)應(yīng)工作線程.當(dāng)讀事務(wù)獲取快照時(shí),基于流水線執(zhí)行方式,對(duì)所有事務(wù)狀態(tài)表的工作線程發(fā)送創(chuàng)建快照的任務(wù),最后合并所有的子快照,得到最終的快照.具體步驟見章節(jié)2.3與2.4.

圖3 事務(wù)狀態(tài)表結(jié)構(gòu)Fig.3Transaction state table structure

內(nèi)存分配狀態(tài)表只有各自數(shù)據(jù)分區(qū)的尾部地址信息,所有對(duì)該表操作的沖突均來自對(duì)尾部地址的并發(fā)讀和寫,本文利用無鎖編程技術(shù),采用原子性操作來操作各自分區(qū)的尾部地址,實(shí)現(xiàn)非阻塞事務(wù)創(chuàng)建和事務(wù)資源無沖突的分配.每個(gè)注入事務(wù)在創(chuàng)建事務(wù)之前獲得其所需要的內(nèi)存空間大小,原子性地修改尾部地址,達(dá)到預(yù)分配內(nèi)存的目的,每個(gè)事務(wù)之間申請(qǐng)的資源沒有重疊,從而天然地支持無沖突事務(wù)并發(fā).

2.3 數(shù)據(jù)注入

CLAIMS系統(tǒng)底層以HDFS為文件存儲(chǔ)系統(tǒng),由于HDFS只支持?jǐn)?shù)據(jù)追加到文件末尾而不支持原地修改,CLAIMS采用日志式存儲(chǔ),注入的數(shù)據(jù)均以追加的模式添加到對(duì)應(yīng)分區(qū)的末尾.針對(duì)傳統(tǒng)數(shù)據(jù)庫支持的UPDATE操作,本文將其分解為兩個(gè)INSERT操作,分別在原表和隱藏的deleted表中各插入一條數(shù)據(jù),注入新值到原表之中,插入舊值到deleted表.查詢同時(shí)查詢兩張表,增加JOIN操作過濾舊值保留新值,等價(jià)于UPDATE操作.

TM節(jié)點(diǎn)對(duì)每個(gè)分布式注入事務(wù)分配互不重疊的內(nèi)存條帶,如圖4所示.因此CLAIMS系統(tǒng)在處理數(shù)據(jù)注入的過程中,對(duì)每個(gè)事務(wù)訪問的資源進(jìn)行隔離,事務(wù)實(shí)現(xiàn)寫寫分離.得益于此,不同的注入事務(wù)可實(shí)現(xiàn)完全的并行執(zhí)行,同時(shí)事務(wù)不會(huì)因?yàn)橄嗷_突而中止,大幅減少事務(wù)的失敗率.只有事務(wù)涉及的每個(gè)內(nèi)存條帶上的注入都成功執(zhí)行,提交事務(wù),之后注入的數(shù)據(jù)即時(shí)可見.

圖4 事務(wù)內(nèi)存分配圖Fig.4Memory allocation for transaction

注入事務(wù)的完整執(zhí)行過程分為如下步驟,如圖5所示.

1.數(shù)據(jù)到達(dá):Coordinator節(jié)點(diǎn)從MQ中讀取最新的數(shù)據(jù)包,開始執(zhí)行數(shù)據(jù)注入過程.

2.創(chuàng)建事務(wù):Coordinator節(jié)點(diǎn)解析獲得注入的若干條元組,并按照每個(gè)元組對(duì)應(yīng)的分區(qū)進(jìn)行劃分.計(jì)算該事務(wù)在每個(gè)分區(qū)上的內(nèi)存需求量后,Coordinator向TM發(fā)起創(chuàng)建注入事務(wù)t的請(qǐng)求.TM節(jié)點(diǎn)分配t執(zhí)行所需資源,例如事務(wù)ID,所注入的內(nèi)存條帶等,并返回申請(qǐng)者.這些操作同步地追加到磁盤中的日志文件,用于故障后恢復(fù)TM.發(fā)起事務(wù)后給消息隊(duì)列MQ發(fā)送確認(rèn)信息.

3.數(shù)據(jù)注入:Coordinator創(chuàng)建事務(wù)成功后,按照分區(qū)的劃分將元組進(jìn)行打包,生成數(shù)據(jù)日志,并發(fā)送到對(duì)應(yīng)分區(qū)所在的Worker節(jié)點(diǎn)上.數(shù)據(jù)日志中包含對(duì)應(yīng)的內(nèi)存條帶以及所要注入的數(shù)據(jù).Worker節(jié)點(diǎn)收到數(shù)據(jù)日志,按照日志的內(nèi)容將數(shù)據(jù)注入對(duì)應(yīng)的內(nèi)存條帶中,并反饋結(jié)果給Coordinator.

4.日志遷移:Worker節(jié)點(diǎn)完成注入操作后,轉(zhuǎn)發(fā)數(shù)據(jù)日志到其他Worker節(jié)點(diǎn)上進(jìn)行備份,最后給Coordinator發(fā)送確認(rèn)信息.

5.提交事務(wù):Coordinator完成分布式數(shù)據(jù)注入后根據(jù)各Worker節(jié)點(diǎn)的反饋向TM節(jié)點(diǎn)請(qǐng)求提交事務(wù)或者撤銷事務(wù).TM將事務(wù)的提交或撤銷記錄在磁盤的日志文件中.

6.數(shù)據(jù)持久化:Worker節(jié)點(diǎn)周期性將各個(gè)分區(qū)在內(nèi)存中已提交的數(shù)據(jù)整理并寫入HDFS中,將注入CLAIMS的數(shù)據(jù)持久化.一旦寫入HDFS成功,即認(rèn)為數(shù)據(jù)不會(huì)丟失.

圖5 數(shù)據(jù)注入流程圖Fig.5Data ingestion flow chart

2.4 數(shù)據(jù)查詢分析

為了保證實(shí)時(shí)查詢結(jié)果的一致性,本文支持事務(wù)執(zhí)行的隔離性,并提供已提交讀,可重復(fù)讀,沖突可串行化等隔離級(jí)別[11].CLAIMS系統(tǒng)中使用多版本并發(fā)控制,對(duì)每個(gè)讀事務(wù)都創(chuàng)建事務(wù)快照,實(shí)現(xiàn)快照隔離級(jí)別,保證事務(wù)之間的隔離性.本框架對(duì)TM節(jié)點(diǎn)管理的元數(shù)據(jù)進(jìn)行多版本控制而不是數(shù)據(jù)本身的多版本控制.

本文引入“快照”的概念來描述數(shù)據(jù)庫某個(gè)一致性版本的子集.本文定義分區(qū)集合P上已提交的內(nèi)存條帶的集合為快照SP,如下所示:

其中t.v為事務(wù)t所申請(qǐng)的內(nèi)存向量,t.commit為事務(wù)t的提交狀態(tài).當(dāng)獲取到SP后,本文通過遍歷SP所包含的內(nèi)存條帶,并依次調(diào)用Read來讀取P分區(qū)集合上的數(shù)據(jù).為了減少Read操作執(zhí)行的次數(shù),以降低開銷,本文利用定義的Map和Merge函數(shù)對(duì)快照SP進(jìn)行化簡.首先將SP利用Map函數(shù)按照分區(qū)進(jìn)行劃分,得到每個(gè)分區(qū)的快照的集合ΠP,如下所示:

對(duì)ΠP中每個(gè)快照使用Merge函數(shù)合并相鄰的內(nèi)存條帶,得到簡化后的Π′P:

Coordinator接受用戶的SQL查詢,通過數(shù)據(jù)字典管理器獲取要查詢的表,進(jìn)而確定需要進(jìn)行掃描的分區(qū)集合P,向TM節(jié)點(diǎn)申請(qǐng)獲取在P上的最簡化的內(nèi)存快照.編譯后的查詢計(jì)劃中的Scan算子通過對(duì)所有內(nèi)存中的數(shù)據(jù)進(jìn)行過濾,只讀取在中的數(shù)據(jù).通過每個(gè)Core獲取快照方式是基于流水線方式,如圖6所示.從第一個(gè)Core向其加入本地的已提交事務(wù)立即轉(zhuǎn)發(fā)給下一個(gè)Core,同時(shí)處理下一個(gè)讀事務(wù)的請(qǐng)求.基于Pipeline的處理方式最大程度地提高每個(gè)核的利用率,增加事務(wù)的吞吐量,在事務(wù)足夠多的理想情況下,雖然每個(gè)Core都是單線程,實(shí)現(xiàn)的性能接近多線程并行的性能.本框架的事務(wù)管理器避免因多線程處理之間并發(fā)操作帶來的鎖或其他控制結(jié)構(gòu)的額外開銷,且基本達(dá)到多線程處理的性能,實(shí)現(xiàn)非阻塞式事務(wù)處理,具有較高的工程創(chuàng)新意義.

上述可得,本文設(shè)計(jì)的事務(wù)管理器支持事務(wù)的強(qiáng)一致性.一旦事務(wù)提交,后續(xù)的讀事務(wù)都能立刻訪問這個(gè)提交事務(wù)的元數(shù)據(jù)快照,已提交事務(wù)的結(jié)果能即時(shí)訪問.

2.5 高可用方案

在金融領(lǐng)域,用戶需要實(shí)時(shí)地訪問、分析、修改金融交易數(shù)據(jù),而且服務(wù)方不能中斷或停機(jī),一旦無法提供服務(wù),會(huì)給企業(yè)造成無法估算的損失.尤其是數(shù)據(jù)庫系統(tǒng)需要保證提供不間斷的數(shù)據(jù)服務(wù),盡量減少系統(tǒng)處于不可用狀態(tài)的時(shí)間,做到數(shù)據(jù)庫的高可用性.

圖6 實(shí)時(shí)數(shù)據(jù)查詢流程圖Fig.6Real-time data query flow chart

本文設(shè)計(jì)的數(shù)據(jù)注入框架考慮到滿足系統(tǒng)的高可用性,采用雙機(jī)熱備等方案.CLAIMS是基于內(nèi)存的數(shù)據(jù)庫,相對(duì)于傳統(tǒng)的磁盤數(shù)據(jù)庫,出錯(cuò)率相對(duì)較低,在兩臺(tái)機(jī)器上備份數(shù)據(jù)在絕大部分情況下可滿足需求.如圖5所示,Worker在接收到Coordinator節(jié)點(diǎn)發(fā)送過來的子事務(wù)請(qǐng)求后,一方面將該日志格式的數(shù)據(jù)轉(zhuǎn)發(fā)給綁定的另一臺(tái)熱備機(jī)器上,另一方面將數(shù)據(jù)切實(shí)地寫入到本機(jī)的內(nèi)存中,兩者并行,可壓縮Worker工作的時(shí)間.兩個(gè)操作均完成后,給Coordinator發(fā)送反饋.熱備機(jī)器收到日志后,在本機(jī)回放日志,再發(fā)送確認(rèn)消息給Worker,保證Worker與熱備機(jī)器維護(hù)有相同的數(shù)據(jù),一旦原Worker出錯(cuò)或者宕機(jī),系統(tǒng)快速將請(qǐng)求轉(zhuǎn)發(fā)給熱備機(jī)器,理論上系統(tǒng)的不可用時(shí)間僅相當(dāng)于請(qǐng)求切換時(shí)間,保證極高的可用性.

同樣地,事務(wù)管理器全局唯一,有宕機(jī)后導(dǎo)致整個(gè)系統(tǒng)不可用的風(fēng)險(xiǎn).事務(wù)管理器同樣支持熱備,實(shí)時(shí)地將事務(wù)日志發(fā)送給備機(jī),同時(shí)備機(jī)在本機(jī)上重做所有事務(wù)日志.

3 實(shí)驗(yàn)

前文已經(jīng)提及,在分布式工具中,只有VoltDB支持事務(wù)型的數(shù)據(jù)實(shí)時(shí)注入和數(shù)據(jù)實(shí)時(shí)查詢,因此將其作為本文的實(shí)驗(yàn)對(duì)比對(duì)象.對(duì)于CLAIMS,由TM獨(dú)占一臺(tái)機(jī)器,設(shè)置12個(gè)線程運(yùn)行,另一臺(tái)機(jī)器負(fù)責(zé)發(fā)起注入事務(wù);對(duì)于VoltDB,一臺(tái)機(jī)器作為其master,設(shè)置注入器sites為12,另一臺(tái)機(jī)器負(fù)責(zé)發(fā)起注入事務(wù).測試服務(wù)器基于CentOS release 6.5(Final)系統(tǒng),CPU型號(hào)為Intel(R)Xeon(R)CPU E5-2620 0@2.00 GHz,雙路,共12核,可超線程到24核,機(jī)器擁有165 G內(nèi)存和100 G以上大小的硬盤以及千兆網(wǎng)卡.本文采用TPC-H基準(zhǔn)測試集的LINEITEM表作為數(shù)據(jù)注入的實(shí)驗(yàn)數(shù)據(jù)集.本文假設(shè)每個(gè)批次的注入事務(wù)包括150個(gè)元組,每個(gè)元組大小為200字節(jié),數(shù)據(jù)由TPC-H數(shù)據(jù)生成器生成.

實(shí)驗(yàn)1測試4臺(tái)機(jī)器,在每個(gè)機(jī)器分布一個(gè)partition的環(huán)境下,不同注入線程數(shù)下CLAIMS與VoltDB的吞吐量及其單個(gè)注入時(shí)延,結(jié)果如圖7所示.實(shí)驗(yàn)結(jié)果顯示:在不同線程數(shù)下,CLAIMS系統(tǒng)的注入引擎的事務(wù)吞吐量均遠(yuǎn)大于VoltDB.隨著注入線程數(shù)不斷增大,在不超過機(jī)器物理核數(shù)量時(shí),CLAIMS的吞吐量大幅增加,時(shí)延基本穩(wěn)定在10 ms之內(nèi),直到線程數(shù)約等于機(jī)器物理核數(shù)量時(shí),其吞吐量達(dá)到上限,穩(wěn)定在1300TPS左右.線程數(shù)繼續(xù)增大到16線程,由于各注入線程競爭CPU,導(dǎo)致其吞吐量開始大幅下降,同時(shí)事務(wù)時(shí)延急劇增加.VoltDB在線程數(shù)為3時(shí)達(dá)到其吞吐量的峰值,其后略降,穩(wěn)定在60TPS,其事務(wù)時(shí)延隨著注入線程數(shù)量增長呈線性遞增趨勢.實(shí)驗(yàn)說明CLAIMS在不超過物理核數(shù)的線程數(shù)下能提供極高的事務(wù)吞吐量和極低的時(shí)延,完全滿足大量實(shí)時(shí)注入任務(wù)的需求,同時(shí)充分利用機(jī)器的性能,對(duì)比VoltDB具有較大的性能優(yōu)勢.

圖7 實(shí)驗(yàn)1測試結(jié)果Fig.7Result of experiment 1

實(shí)驗(yàn)2測試4臺(tái)機(jī)器,在采用12個(gè)注入線程的環(huán)境下,不同partition(均勻分布在4臺(tái)機(jī)器上)下兩個(gè)系統(tǒng)的吞吐量和時(shí)延,實(shí)驗(yàn)結(jié)果如圖8所示.實(shí)驗(yàn)表明,在不同partition數(shù)量下,CLAIMS仍提供較高的注入事務(wù)吞吐量,遠(yuǎn)大于VoltDB的性能.兩者的吞吐量都隨著partition數(shù)量的增大而下降,主要因?yàn)閱蝹€(gè)事務(wù)被分解為更多的子事務(wù)處理(每個(gè)partition作為一個(gè)子事務(wù)).在單次注入平均時(shí)延方面,CLAIMS在partition較少時(shí)延遲遠(yuǎn)低于VoltDB,在partitions per machine=3左右,急劇增長,因?yàn)楫?dāng)前版本的CLAIMS在Worker上僅實(shí)現(xiàn)了單線程處理,因此在達(dá)到單線程處理極限后延遲大幅增加,在partition數(shù)量較大時(shí),增速放緩.Worker上的優(yōu)化將作為后續(xù)工作進(jìn)行.VoltDB的單次事務(wù)延時(shí)隨partition數(shù)量增加呈現(xiàn)線性增長趨勢,在partition數(shù)量較大時(shí)相比CLAIMS具有一定優(yōu)勢.

圖8 實(shí)驗(yàn)2測試結(jié)果Fig.8Result of experiment 2

實(shí)驗(yàn)3測試基于TPC-H數(shù)據(jù)集在4臺(tái)機(jī)器各分布1個(gè)partition的環(huán)境下,實(shí)時(shí)注入時(shí)實(shí)時(shí)SQL查詢的延時(shí)情況,并進(jìn)行對(duì)比,結(jié)果如表1所示.實(shí)驗(yàn)結(jié)果顯示,實(shí)時(shí)注入對(duì)大部分實(shí)時(shí)查詢的性能影響較小,基本延時(shí)增長在10%以內(nèi),查詢達(dá)到秒級(jí)響應(yīng),但對(duì)于長查詢,影響稍大,達(dá)到12%,仍處于可接受范圍之內(nèi).總體來看,實(shí)時(shí)注入框架能保證數(shù)據(jù)的實(shí)時(shí)查詢不受較大影響.

表1 實(shí)驗(yàn)3測試結(jié)果Tab.1Result of experiment 3

4 總結(jié)

分布式環(huán)境下,事務(wù)型實(shí)時(shí)數(shù)據(jù)注入在電信、金融和電子商務(wù)等領(lǐng)域有著巨大的需求和廣泛的應(yīng)用前景.本文介紹了目前分布式數(shù)據(jù)實(shí)時(shí)注入的研究現(xiàn)狀,闡述事務(wù)并發(fā)控制的幾種方式,面向自主研發(fā)的分布式內(nèi)存數(shù)據(jù)庫CLAIMS,設(shè)計(jì)了一套高可用、高性能、高通量的分布式數(shù)據(jù)實(shí)時(shí)注入框架,保證了數(shù)據(jù)的實(shí)時(shí)注入,同時(shí)結(jié)合CLAIMS的執(zhí)行引擎提供實(shí)時(shí)的數(shù)據(jù)分析查詢,詳細(xì)說明了數(shù)據(jù)注入和數(shù)據(jù)查詢的整個(gè)流程.經(jīng)試驗(yàn)證明,本文所提出的實(shí)時(shí)數(shù)據(jù)注入框架具有良好的性能,并能提供實(shí)時(shí)的數(shù)據(jù)注入服務(wù)和實(shí)時(shí)數(shù)據(jù)分析服務(wù),能夠較好滿足金融等領(lǐng)域的實(shí)際需求.

［1］DEAN J,GHEMAWAT S.MapReduce:Simplified data processing on large clusters[J].Communications of the ACM,2008,51(1):107-113.

［2］ZAHARIA M,CHOWDHURY M,FRANKLIN M J,et al.Spark:Cluster computing with working sets [C]//Proceedings of the 2nd USENIX Conference on Hot Topics in Cloud Computing.Berkeley:USENIX Association,2010:10.

［3］SHVACHKO K,KUANG H,RADIA S,et al.The hadoop distributed file system[C]//Proceedings of IEEE Conference on MSST.2010:1-10.

［4］胡健,和軼東.SAP內(nèi)存計(jì)算--HANA[M].北京:清華大學(xué)出版社,2013.

［5］F?RBER F,CHA S K,PRIMSCH J,et al.SAP HANA database:Data management for modern business applications[J].ACM Sigmod Record,2012,40(4):45-51.

［6］GLIGOR G,TEODORU S.Oracle exalytics:Engineered for speed-of-thought analytics[J].Database Systems Journal,2011,2(4):3-8.

［7］WANG L,ZHOU M Q,ZHANG Z J,et al.Elastic pipelining in in-memory DataBase cluster[R].2016.

［8］TRAVERSO M.Presto:Interacting with petabytes of data at Facebook[EB/OL].(2013-11-07)[2016-06-10]. http://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/ 10151786197628920.

［9］ARMBRUST M,XIN R S,LIAN C,et al.Spark SQL:Relational data processing in spark[C]//Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data.ACM,2015:1383-1394.

［10］YANG F,TSCHETTER E,LéAUTé X,et al.Druid:A real-time analytical data store[C]//Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data.2014.

［11］GARCIA-MOLINA H,ULLMAN J D,WIDOM J.Database System Implementation[M].Upper Saddle River, NJ:Prentice Hall,2000.

［12］NAGA P N.Real-time Analytics at Massive Scale with Pinot[EB/OL].[2016-06-10].https://engineering. linkedin.com/analytics/real-time-analytics-massive-scale-pinot.

［13］KREPS J,NARKHEDE N,RAO J,et al.Kafka:A distributed messaging system for log processing [C]//Proceedings of the NetDB.2011:1-7.［14］LAMB A,FULLER M,VARADARAJAN R,et al.The vertica analytic database:C-store 7 years later [C]//Proceedings of the VLDB Endowment.2012:1790-1801.

［15］CHANG L,WANG Z,MA T,et al.Hawq:A massively parallel processing sql engine in hadoop[C]//Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data.2014.

［16］STONEBRAKER M,WEISBERG A.The VoltDB main memory DBMS[J].IEEE Data Eng Bull,2013:21-27.

［17］BRYANT R E,O′HALLARON D R.深入理解計(jì)算機(jī)系統(tǒng)[M].北京:機(jī)械工業(yè)出版社,2013.

［18］ESWARAN K P,GRAY J N,LORIE R A,et al.The notions of consistency and predicate locks in a database system[J].Communications of the ACM,1976,19(11):624-633.

［19］STONEBRAKER M.One Size Fits None-(Everything You Learned in Your DBMS Class is Wrong)[R/OL]. (2013-05-30)[2016-07-01].http://slideshot.epfl.ch/talks/166.

［20］WEIKUM G,VOSSEN G.Transactional Information Systems:Theory,Algorithms,and the Practice of Concurrency Control and Recovery[M].San Francisco:Morgan Kaufmann Publishers,2002.

［21］DIACONU C,FREEDMAN C,ISMERT E,et al.Hekaton:SQL server’s memory-optimized OLTP engine [C]//Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data.2013.

［22］MICHAEL M M.High performance dynamic lock-free hash tables and list-based sets[C]//Proceedings of the 14th Annual ACM Symposium on Parallel Algorithms and Architectures.2002:73-82.

［23］LAMPSON B W,STURGIS H E.Crash Recovery in a Distributed Data Storage System[R].Palo Alto,California: Xerox Palo Alto Research Center,1979.

［24］SKEEN D.Nonblocking commit protocols[C]//Proceedings of the 1981 ACM SIGMOD International Conference on Management of Data.1981.

［25］HAN J,HAIHONG E,LE G,et al.Survey on NoSQL database[C]//Proceedings of the 2011 6th International Conference on Pervasive Computing and Applications.2011:363-366.

［26］O’NEIL E J,O’NEIL P E,WEIKUM G.The LRU-K page replacement algorithm for database disk buffering [C]//Proceedings of the ACM SIGMOD International Conference on Management of Data.1993:297-306.

(責(zé)任編輯:林磊)

Research and implementation of transactional real-time data ingestion technology without blocking

YU Kai,LI Zhi-fang,ZHOU Min-qi,ZHOU Ao-ying
(Institue for Data Science and Engineering,East China Normal University, Shanghai200062,China)

With the advent of big data era,traditional database systems are facing difficulties in satisfying the new challenges brought by massive data processing,while distributed database systems have been deployed widely in real applications.Distributed database systems partitioned and the dispatched the data across machines under a designed scheme and analyzed all the massive data in massive parallel manner.In facing of the requirements of the transactional real-time data ingestion from financial field, distributed database systems are ineffective and inefficient due to their implementation ofthe distributed transaction processing based on the lock and two-phase commit,which lead to the impossibility of non-blocking data ingestion.CLAIMS is a distributed in-memory database system designed and implemented by Institute for Data Science and Engineering of ECNU.It supports real-time data analysis towards relational data set but is incapable of real-time data ingestion.To address these problems,we analyzed data ingestion technology and distributed transaction processing algorithms first,and proposed to mimic the transactional data ingestion in the distributed environment with the centralized transaction processing based on meta data,and eventually achieved the real-time data ingestion with high availability and without blocking.The experiment results with the implementation of the proposed algorithms in CLAIMS proved that the proposed framework could achieve high throughput transactional real-time data ingestion as well as low latency real-time query processing.

distributed database system;real-time data ingestion;transaction processing;CLAIMS

TP392

A

10.3969/j.issn.1000-5641.2016.05.015

1000-5641(2016)05-0131-13

2016-05

國家自然科學(xué)基金重點(diǎn)項(xiàng)目(61332006),上海市基金(13ZR1413200)

余楷,男,碩士研究生.研究方向?yàn)閮?nèi)存數(shù)據(jù)庫系統(tǒng).E-mail:yukai@gmail.com.

周敏奇,男,副教授.研究方向?yàn)閷?duì)等計(jì)算、云計(jì)算、分布式數(shù)據(jù)管理、內(nèi)存數(shù)據(jù)管理系統(tǒng). E-mail:mqzhou@sei.ecnu.edu.cn.