內(nèi)存集群計(jì)算：交互式數(shù)據(jù)分析

黃 嵐， 孫 珂， 陳曉竹， 周敏奇

（1.電子科技集團(tuán)第三十二研究所，上海 200233；2.華東師范大學(xué) 數(shù)據(jù)科學(xué)與工程研究院，上海 200062）

0 引 言

大數(shù)據(jù)（big data）處理目前已經(jīng)成為時(shí)髦詞匯和研究熱點(diǎn).按照應(yīng)用的類型，大數(shù)據(jù)大致可以分為三大類：WEB數(shù)據(jù)、決策數(shù)據(jù)和科學(xué)數(shù)據(jù).以谷歌、亞馬遜為代表的互聯(lián)網(wǎng)公司由于其獨(dú)特的技術(shù)需求和成功的商業(yè)應(yīng)用模式直接催生了云計(jì)算和大數(shù)據(jù)的概念.搜索引擎及其他互聯(lián)網(wǎng)信息服務(wù)所面臨的大數(shù)據(jù)問題是典型的WEB大數(shù)據(jù)問題；被稱為科學(xué)研究第四范式，數(shù)據(jù)密集型科學(xué)發(fā)現(xiàn)要處理的數(shù)據(jù)屬于科學(xué)數(shù)據(jù)；用于政府部門和商業(yè)機(jī)構(gòu)決策支持的數(shù)據(jù)則是決策數(shù)據(jù).這三類數(shù)據(jù)的應(yīng)用環(huán)境和應(yīng)用需求各有特點(diǎn)，相關(guān)的技術(shù)研發(fā)和應(yīng)用部署構(gòu)成了當(dāng)前大數(shù)據(jù)研發(fā)和應(yīng)用的亮麗風(fēng)景.相比而言，決策數(shù)據(jù)這類大數(shù)據(jù)更多地沿襲了傳統(tǒng)數(shù)據(jù)管理的技術(shù)和理念.但由于應(yīng)用環(huán)境和硬件技術(shù)的發(fā)展，相關(guān)研究面臨新的挑戰(zhàn)和機(jī)遇.眾所周知的決策數(shù)據(jù)應(yīng)用就是耳熟能詳?shù)纳虅?wù)智能（Business Intelligence，BI）.據(jù)Gartner統(tǒng)計(jì)，2010年全球BI市場(chǎng)已達(dá)570億美元，并預(yù)計(jì)2014年將達(dá)810億美元［57］.而BI是內(nèi)存計(jì)算系統(tǒng)的一個(gè)非常重要的應(yīng)用.

2011年，SAP公司推出“更強(qiáng)勁、更簡捷、更睿智”的HANA內(nèi)存計(jì)算（In－memory）系統(tǒng)，引起了廣泛關(guān)注.該內(nèi)存計(jì)算系統(tǒng)具有兩大特點(diǎn)：（1）與傳統(tǒng)數(shù)據(jù)倉庫相比，具有更高的分析靈活性（flexibility），能夠勝任各種即興（ad hoc）的分析任務(wù)，這是傳統(tǒng)數(shù)據(jù)倉庫無法做的；（2）與傳統(tǒng)的基于磁盤的數(shù)據(jù)分析系統(tǒng)項(xiàng)目相比，具有更高的處理性能.內(nèi)存計(jì)算系統(tǒng)的主要特點(diǎn)是基于內(nèi)存構(gòu)建分布式系統(tǒng)，以內(nèi)存計(jì)算方式存儲(chǔ)并處理所有數(shù)據(jù).內(nèi)存計(jì)算系統(tǒng)主要依據(jù)內(nèi)存的數(shù)據(jù)存取效率比磁盤的數(shù)據(jù)存取效率高200倍左右，進(jìn)而通過內(nèi)存計(jì)算可以大幅提升系統(tǒng)的數(shù)據(jù)處理能力，特別地，當(dāng)數(shù)據(jù)訪問量越大時(shí)，其性能提升越明顯.內(nèi)存計(jì)算系統(tǒng)正是由于上述兩大特點(diǎn)，從而能夠較好地滿足目前或者未來BI對(duì)于海量數(shù)據(jù)的分析處理需求.

當(dāng)下，內(nèi)存計(jì)算在研究和系統(tǒng)開發(fā)方面已經(jīng)成為極度熱門的熱點(diǎn).然而，內(nèi)存計(jì)算的研究已經(jīng)有50多年的歷史.內(nèi)存計(jì)算數(shù)據(jù)管理系統(tǒng)的發(fā)展不僅與具體的數(shù)據(jù)管理應(yīng)用的發(fā)展和需求息息相關(guān)，還與計(jì)算機(jī)硬件的發(fā)展密不可分；計(jì)算機(jī)組件、體系架構(gòu)、拓?fù)浣Y(jié)構(gòu)的發(fā)展、演化推動(dòng)了分布式內(nèi)存數(shù)據(jù)管理系統(tǒng)的發(fā)展.內(nèi)存數(shù)據(jù)管理系統(tǒng)的發(fā)展，大致可以分成四個(gè)階段：共享內(nèi)存多處理機(jī)、分布式共享內(nèi)存、集中式混存優(yōu)化、分布式全內(nèi)存數(shù)據(jù)管理系統(tǒng).

本文通過分析內(nèi)存數(shù)據(jù)管理的發(fā)展歷程與應(yīng)用、計(jì)算機(jī)硬件發(fā)展歷程之間的關(guān)聯(lián)關(guān)系，論證網(wǎng)絡(luò)通信將成為未來內(nèi)存集群計(jì)算系統(tǒng)的新瓶頸，需要從系統(tǒng)的拓?fù)浣Y(jié)構(gòu)，數(shù)據(jù)部署，多核、多處理器、集群等多粒度并行處理等方面研究并設(shè)計(jì)新系統(tǒng)，最后實(shí)現(xiàn)交互式分析處理的功能.

1 內(nèi)存數(shù)據(jù)管理發(fā)展歷程

基于內(nèi)存計(jì)算的數(shù)據(jù)管理和分析技術(shù)的發(fā)展與計(jì)算機(jī)硬件的發(fā)展歷程密切相關(guān)，它大致可以分成如下四個(gè)階段：

圖1 內(nèi)存數(shù)據(jù)管理的發(fā)展歷程Fig.1 History of in－memory data management

1.1 共享內(nèi)存多處理機(jī)

上世紀(jì)50年代，隨著第二代計(jì)算機(jī)（晶體管計(jì)算機(jī)）的出現(xiàn)，大幅度促進(jìn)了計(jì)算機(jī)的發(fā)展，但是當(dāng)時(shí)計(jì)算機(jī)的性能與需求之間存在著巨大的差距.于是，構(gòu)建大型計(jì)算機(jī)（mainframe）成為了當(dāng)時(shí)的一種熱潮，并主要采用通過增加處理器數(shù)量，擴(kuò)大內(nèi)存容量，提升計(jì)算機(jī)的整體處理能力.

2.2 分布式共享內(nèi)存系統(tǒng)

20世紀(jì)80年代，涌現(xiàn)出大量的關(guān)于分布式共享內(nèi)存系統(tǒng)的研究，假設(shè)的前提是內(nèi)存容量會(huì)趕上超過磁盤的容量.系統(tǒng)大致可以分成三類：（1）多處理器共享內(nèi)存系統(tǒng)，如Encore的Multimax，SGI的Iris等，這些系統(tǒng)的處理器數(shù)量受到共享總線帶寬的限制，系統(tǒng)可擴(kuò)展性較低；2）分布式共享內(nèi)存系統(tǒng)，這類系統(tǒng)主要通過如下三種方式實(shí)現(xiàn)對(duì)共享內(nèi)存中不同粒度、不同結(jié)構(gòu)數(shù)據(jù)的訪問：通過硬件實(shí)現(xiàn)類似于虛擬內(nèi)存式的分布式內(nèi)存共享，如ivy［9］，Mirage［10］，Dash［11］等；通過操作系統(tǒng)實(shí)現(xiàn)類似于虛擬內(nèi)存式的分布式內(nèi)存共享，如 Mermaid等；通過編譯器利用消息傳遞方式實(shí)現(xiàn)分布式內(nèi)存共享，如Munin［12］等；（3）主存數(shù)據(jù)庫，這類系統(tǒng)考慮到內(nèi)存容量有限性，將頻繁訪問的數(shù)據(jù)構(gòu)建主存數(shù)據(jù)庫（MMDB），非頻繁問的數(shù)據(jù)構(gòu)建磁盤數(shù)據(jù)庫，或者根據(jù)不同的訪問要求將數(shù)據(jù)分成更多的存儲(chǔ)層次［13］，并實(shí)現(xiàn)不同層次數(shù)據(jù)庫的統(tǒng)一訪問，即聯(lián)邦數(shù)據(jù)庫［14］.

1.3 集中式緩存優(yōu)化系統(tǒng)

自Bill Wulf和Sally McKee于1994年提出內(nèi)存墻［15］問題之后，涌現(xiàn)出大量的關(guān)于集中式內(nèi)存數(shù)據(jù)管理方面的研究.內(nèi)存墻是指處理器性能與內(nèi)存訪問效率之間的差距越來越大（CPU頻率每年增長60%，而內(nèi)存訪問速度每年增長10%［32］），以及隨后顯現(xiàn)的內(nèi)存訪問延遲、訪問帶寬、應(yīng)用數(shù)量可擴(kuò)展性、緩存可擴(kuò)展性也逐步成為性能瓶頸.為了緩解內(nèi)存墻的影響，針對(duì)緩存層次結(jié)構(gòu)［16］，出現(xiàn)了以緩存為中心的數(shù)據(jù)管理技術(shù)方面的大量研究，并由此構(gòu)建了大量的主存數(shù)據(jù)庫系統(tǒng)，如 MonetDB［33］，EaseDB［33］，F(xiàn)astDB［35］，TimesTen［36］（后兩者未實(shí)現(xiàn)緩存優(yōu)化）.這類研究主要可以分為兩類，即緩存感知技術(shù)和緩存參數(shù)無關(guān)技術(shù).緩存感知技術(shù)需要知曉系統(tǒng)緩存的結(jié)構(gòu)、緩存容量、緩存位寬等系統(tǒng)參數(shù)，并通過分塊［17］，緩沖［18，19］，分區(qū)［20，17］等技術(shù)提高緩存數(shù)據(jù)的時(shí)間局部性；通過壓縮［21］、聚類［22］等技術(shù)實(shí)現(xiàn)緩存數(shù)據(jù)的空間局部性；由此可大幅提升索引結(jié)構(gòu)［23］、表連接操作［24］、數(shù)據(jù)庫架構(gòu)［20］等的性能.這類技術(shù)的系統(tǒng)性能度量標(biāo)準(zhǔn)主要采用外部內(nèi)存模型（external memory model，也稱為緩存感知模型）［25］.緩存參數(shù)無關(guān)技術(shù)則是在無需了解系統(tǒng)緩存結(jié)構(gòu)、緩存容量等系統(tǒng)參數(shù)的情況下，通過如下兩類方法提升系統(tǒng)系能，即分而治之方法和分?jǐn)偹惴?分而治之方法主要通過遞歸聚類［26］實(shí)現(xiàn)空間局部性和遞歸分區(qū)［27］實(shí)現(xiàn)時(shí)間局部性，并可大幅提高緩存無關(guān)B＋樹［29，30］等的性能.這類技術(shù)的系統(tǒng)性能度量主要采用緩存參數(shù)無關(guān)模型［28］.分?jǐn)偹惴▌t是針對(duì)一組操作進(jìn)行優(yōu)化，使得這一組操作的平均開銷比較低［26，27］.實(shí)驗(yàn)證實(shí)即使高度優(yōu)化后的緩存參數(shù)無關(guān)算法的性能依舊遠(yuǎn)低于緩存感知算法的性能［31］.

1.4 分布式全內(nèi)存數(shù)據(jù)管理系統(tǒng)

內(nèi)存的容量大幅增長，特別是分布式集群環(huán)境下內(nèi)存容量已經(jīng)能夠滿足數(shù)據(jù)庫事務(wù)處理和數(shù)據(jù)分析的需求；2006年之后，出現(xiàn)了面向事務(wù)處理和數(shù)據(jù)分析的兩大類內(nèi)存數(shù)據(jù)管理系統(tǒng).面向事務(wù)處理的內(nèi)存數(shù)據(jù)管理系統(tǒng)主要通過全內(nèi)存操作、去除事務(wù)處理中斷、內(nèi)嵌高可用特性及災(zāi)難恢復(fù)機(jī)制等方式實(shí)現(xiàn)高吞吐量的聯(lián)機(jī)事務(wù)處理，這類系統(tǒng)包括H－store［37］，VoltDB［38］，HANA［39］.而現(xiàn)有的面向數(shù)據(jù)分析的內(nèi)存數(shù)據(jù)管理系統(tǒng)又可以進(jìn)一步分為數(shù)據(jù)存儲(chǔ)系統(tǒng)和分布式執(zhí)行框架.Memchached［40］及其擴(kuò)展 Membase（或Couchbase）［41］是最早實(shí)現(xiàn)的全內(nèi)存式數(shù)據(jù)存取系統(tǒng)，該類系統(tǒng)使用DHT實(shí)現(xiàn)網(wǎng)絡(luò)拓?fù)涞臉?gòu)建以及數(shù)據(jù)的布局及查詢，具有較高的可擴(kuò)展性.RamCloud［42］采用聯(lián)邦方式實(shí)現(xiàn)了內(nèi)存數(shù)據(jù)的并發(fā)控制、事務(wù)處理、一直維護(hù)及多租戶特性（multi－tenancy），并通過日志結(jié)構(gòu)文件系統(tǒng)［43］實(shí)現(xiàn)了內(nèi)存數(shù)據(jù)的快速恢復(fù)［44］.Piccolo［46］提供了分布式內(nèi)存互斥表的存儲(chǔ)架構(gòu)，而RDD（Resilient Distributed Datasets）［45］提出了針對(duì)迭代式計(jì)算的分布式數(shù)據(jù)集抽象，并同時(shí)實(shí)現(xiàn)了批量式和細(xì)粒度的讀操作、寫操作、恢復(fù)操作等.分布式處理框架主要可以分成兩大類，即無環(huán)數(shù)據(jù)流式處理和有環(huán)迭代式處理.DryadLINQ［47］，Pig［48］，F(xiàn)lumeJava［49］，Storm［50］，Ciel［51］實(shí)現(xiàn)了類似于 MapReduce式的無環(huán)數(shù)據(jù)流式處理，而 Twister［52］、HaLoop［53］，Pregel［54］，Spark［56］則提供了迭代式數(shù)據(jù)處理框架.但是，這類系統(tǒng)均沒有考慮到內(nèi)存墻問題，即均沒有考慮分布式環(huán)境下，結(jié)合異構(gòu)的緩存、內(nèi)存特性提升系統(tǒng)的處理性能.

綜上所述，幾十年來內(nèi)存數(shù)據(jù)管理技術(shù)的發(fā)展與應(yīng)用的需求、計(jì)算機(jī)硬件的發(fā)展密不可分.內(nèi)存數(shù)據(jù)管理技術(shù)的發(fā)展與演化，其主要目的是要解決海量數(shù)據(jù)處理、復(fù)雜數(shù)據(jù)分析與當(dāng)時(shí)硬件內(nèi)存容量的有限性、硬件處理瓶頸之間的矛盾關(guān)系，進(jìn)而依次采用了共享內(nèi)存多處理器，分布式共享內(nèi)存處理系統(tǒng)，以提升數(shù)據(jù)存儲(chǔ)容量和處理性能.然后當(dāng)數(shù)據(jù)存儲(chǔ)媒介的發(fā)展技術(shù)發(fā)生較大變革之后，即硬盤容量和內(nèi)存容量的發(fā)展速度從1989年之后開始倒掛，導(dǎo)致內(nèi)存數(shù)據(jù)管理技術(shù)研究方向的重大轉(zhuǎn)折，即重回以磁盤為主要存儲(chǔ)媒介的數(shù)據(jù)管理技術(shù).然而，1994年內(nèi)存墻的提出，則是進(jìn)一步促進(jìn)了集中式內(nèi)存數(shù)據(jù)管理技術(shù)的發(fā)展.然而，當(dāng)前大數(shù)據(jù)環(huán)境下（特別是商務(wù)智能），又進(jìn)一步為基于內(nèi)存計(jì)算的分布式數(shù)據(jù)管理系統(tǒng)提出了迫切需求.

下面從當(dāng)前的大數(shù)據(jù)分析需求和計(jì)算機(jī)硬件發(fā)展（特別是內(nèi)存）兩方面展開研究，最后確定內(nèi)存計(jì)算的主要研究內(nèi)容（分布式環(huán)境下，異構(gòu)的緩存、內(nèi)存系統(tǒng)體系架構(gòu)，內(nèi)存數(shù)據(jù)易潰等特性）并以實(shí)現(xiàn)海量數(shù)據(jù)的實(shí)時(shí)交互式分析為最終目標(biāo).

2 實(shí)時(shí)交互式數(shù)據(jù)分析

幾十年來，數(shù)據(jù)分析領(lǐng)域的目標(biāo)從未改變過，即實(shí)現(xiàn)對(duì)大規(guī)模數(shù)據(jù)的實(shí)時(shí)交互式分析.隨著計(jì)算機(jī)硬件技術(shù)的發(fā)展，以及數(shù)據(jù)管理技術(shù)在商務(wù)智能領(lǐng)域的應(yīng)用越來越廣泛，并形成了巨大商業(yè)價(jià)值.特別是內(nèi)存數(shù)據(jù)庫系統(tǒng)時(shí)代的來臨，使得實(shí)時(shí)交互式分析成為了可能，進(jìn)一步拓展了數(shù)據(jù)分析的領(lǐng)域，使得某些原先無法實(shí)現(xiàn)的數(shù)據(jù)分析任務(wù)成為了可能.

2.1 巨大的BI市場(chǎng)和新的應(yīng)用需求

眾所周知的決策數(shù)據(jù)應(yīng)用就是耳熟能詳?shù)腂I.首先是新興實(shí)時(shí)分析應(yīng)用的出現(xiàn).新型設(shè)備，如智能電網(wǎng)中的實(shí)時(shí)電表［58］，供應(yīng)鏈中物流的RFID［59］等的出現(xiàn)必將產(chǎn)生新的應(yīng)用需求.譬如，通過每家每戶的實(shí)時(shí)電表數(shù)據(jù)分析當(dāng)前用電量情況，精確調(diào)整各地發(fā)電廠的供電量；通過RFID芯片實(shí)時(shí)跟蹤并追溯各類商品，優(yōu)化商品供應(yīng).類似的應(yīng)用均需以數(shù)據(jù)流方式處理大量數(shù)據(jù)，并實(shí)時(shí)獲得分析結(jié)果，進(jìn)而優(yōu)化各類服務(wù).其次是用戶對(duì)實(shí)時(shí)分析的要求.這要求數(shù)據(jù)分析由以前的批處理式分析（如Hadoop處理框架）向?qū)崟r(shí)交互式分析（interactive analysis）轉(zhuǎn)變.所謂實(shí)時(shí)交互式分析是指，用戶期待零等待的分析響應(yīng)時(shí)間.針對(duì)這樣的應(yīng)用需求，為支持在線事務(wù)處理、交互式分析，近實(shí)時(shí)挖掘，有必要對(duì)傳統(tǒng)的數(shù)據(jù)管理架構(gòu)進(jìn)行重新審視［2］.另外的是針對(duì)操作型數(shù)據(jù)直接進(jìn)行復(fù)雜、即席的分析型應(yīng)用需求.傳統(tǒng)數(shù)據(jù)集市、數(shù)據(jù)倉庫等均針對(duì)預(yù)先定義的分析服務(wù)類型，抽取、轉(zhuǎn)換、加載數(shù)據(jù)，最終實(shí)現(xiàn)相關(guān)分析；周期性檢查操作數(shù)據(jù)存儲(chǔ)中的新增數(shù)據(jù)，優(yōu)化分析結(jié)果，因而無法滿足實(shí)時(shí)、即席的復(fù)雜分析型服務(wù).再一個(gè)變化就是數(shù)據(jù)存儲(chǔ)模式的變化.存儲(chǔ)由OLAP方式向按列存儲(chǔ)模式轉(zhuǎn)變.數(shù)據(jù)量激增之后，傳統(tǒng)的在線分析的局限性越來越明顯，如數(shù)據(jù)存取性能下降，連接處理復(fù)雜化等.最后值得一提的是自助式商務(wù)智能（self－service BI）的提出.傳統(tǒng)BI服務(wù)需要專業(yè)計(jì)算機(jī)人員通過復(fù)雜的SQL語言實(shí)現(xiàn)，自助式BI需要提供更為簡單易用的分析語言，以支持非專業(yè)人員的分析應(yīng)用需求.

2.2 潛在的實(shí)時(shí)交互式數(shù)據(jù)分析應(yīng)用

隨著內(nèi)存數(shù)據(jù)庫時(shí)代的來臨，實(shí)時(shí)交互式分析拓展了BI的應(yīng)用領(lǐng)域，主要體現(xiàn)在提升傳統(tǒng)BI數(shù)據(jù)分析時(shí)效性，由新硬件設(shè)備的引入而帶來的新型BI服務(wù).這類技術(shù)和系統(tǒng)可能的應(yīng)用主要包括：

· 傳統(tǒng)的BI分析與決策支持.不論是不同地域還是不同行業(yè)的企業(yè)，也不論是小型公司還是跨國企業(yè)，均產(chǎn)生了大量與貨幣、交易、監(jiān)管、服務(wù)等相關(guān)的數(shù)據(jù)，并需實(shí)時(shí)管理、分析、處理，以輔助他們企業(yè)規(guī)劃、實(shí)時(shí)決策.例如，實(shí)時(shí)預(yù)測(cè)未來商品需求、銷售訂單處理、銷售分析、過期銷售追蹤等［6］.而分布式全內(nèi)存數(shù)據(jù)管理系統(tǒng)可以大幅提升各類企業(yè)BI分析和實(shí)時(shí)決策的能力.

· 由新興設(shè)備引入的新型BI服務(wù).舉例來說，智能電網(wǎng)中為每家每戶安裝的實(shí)時(shí)電表，電表每隔一小段時(shí)間發(fā)送一次電量消耗數(shù)據(jù)，電力公司分析上述數(shù)據(jù)，可以實(shí)時(shí)優(yōu)化各地發(fā)電廠的供電量，提供電子耗電賬單，優(yōu)化每家每戶的用電設(shè)備（如監(jiān)測(cè)到住戶外出時(shí)，提供自動(dòng)斷電服務(wù)等），而用戶則可以實(shí)時(shí)查看用電情況.供應(yīng)鏈管理中通過為物流商品部署RFID后，則可以實(shí)時(shí)跟蹤并追溯商品的物流狀態(tài)，銷售狀態(tài)，庫存情況等，優(yōu)化商品供應(yīng).

· 面向分析的自動(dòng)訂貨決策.大型購物廣場(chǎng)通過分析歷史銷售數(shù)據(jù)，當(dāng)前商品的流行趨勢(shì)，預(yù)測(cè)未來商品的銷售數(shù)量，并自動(dòng)完成商品的訂購，包括選擇上游商品廠商，確定訂購商品的型號(hào)，數(shù)量，送貨時(shí)間，送貨地點(diǎn)等.

目前，分布式內(nèi)存數(shù)據(jù)管理系統(tǒng)受到了越來越多的關(guān)注，并已出現(xiàn)了一些商業(yè)系統(tǒng)，如SAP的 HANA［39］、IBM 的solidDB［55］、Oracle的 TimesTen［36］、Stonebraker的 VoltDB［38］等，但是這類系統(tǒng)遠(yuǎn)未成熟，尚需大量的完善工作.

3 網(wǎng)絡(luò)通信將成為內(nèi)存集群計(jì)算的瓶頸

四十多年來，計(jì)算機(jī)硬件的高速發(fā)展，特別是內(nèi)存容量和內(nèi)存訪問性能方面的提升，使得通過內(nèi)存管理海量商務(wù)數(shù)據(jù)，并提供實(shí)時(shí)分析服務(wù)成為可能.計(jì)算機(jī)硬件體系架構(gòu)方面遇到的功耗墻、頻率墻、內(nèi)存墻等問題，使得計(jì)算機(jī)體系結(jié)構(gòu)發(fā)生了較大的變化.為此，有必要重新研究并設(shè)計(jì)基于內(nèi)存計(jì)算的高性能數(shù)據(jù)管理與分析技術(shù).

計(jì)算機(jī)硬件在性能、體系結(jié)構(gòu)方面的演化，使得內(nèi)存數(shù)據(jù)管理系統(tǒng)成為必然選擇.40多年來，計(jì)算機(jī)各組件（CPU，內(nèi)存，磁盤，網(wǎng)絡(luò)等）在容量和性能上有了極大的提高，特別是內(nèi)存容量的大幅增長，使其具備了存儲(chǔ)、管理海量數(shù)據(jù)的能力；而內(nèi)存容量的激增又加劇了馮諾依曼瓶頸問題［7］.為了緩解這一問題，人們?cè)O(shè)計(jì)了多層次緩存架構(gòu)、共享緩存架構(gòu)；芯片制造方面遇到的功耗墻、頻率墻等問題，使處理器逐步由單核向多核再到眾核發(fā)展，并出現(xiàn)了多核共享緩存的架構(gòu)、多處理器共享內(nèi)存的架構(gòu)；內(nèi)存墻問題［15］，大容量閃存的出現(xiàn)，如固態(tài)盤（SSD）、相變存儲(chǔ)器（PCM）等，又使計(jì)算機(jī)存儲(chǔ)結(jié)構(gòu)發(fā)生了較大變化.可見，計(jì)算機(jī)在體系結(jié)構(gòu)和組成原理上已發(fā)生了較大變化，勢(shì)必導(dǎo)致數(shù)據(jù)管理構(gòu)架的重大變革.另一方面，多年以來針對(duì)當(dāng)時(shí)計(jì)算機(jī)硬件架構(gòu)設(shè)計(jì)、開發(fā)的DBMS［1］，以及對(duì)OLAP系統(tǒng)的優(yōu)化、修補(bǔ)，已經(jīng)無法適應(yīng)當(dāng)前計(jì)算機(jī)的存儲(chǔ)架構(gòu)，更無法充分發(fā)揮計(jì)算機(jī)的性能.為此，需要一套全新的數(shù)據(jù)管理架構(gòu)，而分布式內(nèi)存數(shù)據(jù)管理則是一個(gè)較好的選擇，逐步實(shí)現(xiàn)數(shù)據(jù)管理方式由以處理器為中心到以內(nèi)存為中心的轉(zhuǎn)變.

3.1 非統(tǒng)一內(nèi)存訪問（NUMA）

隨著處理器多核技術(shù)的發(fā)展，單臺(tái)服務(wù)器擁有的能夠訪問內(nèi)存處理核心（core）的數(shù)量越來越多.如果所有的處理核心通過共享總線的方式訪問內(nèi)存，那么該總線必將成為內(nèi)存訪問的瓶頸.于是，非統(tǒng)一內(nèi)存訪問（NUMA）的服務(wù)器體系架構(gòu)應(yīng)運(yùn)而生.在該非統(tǒng)一內(nèi)存訪問機(jī)制下，每個(gè)處理器均有從屬于自己的內(nèi)存，如圖2所示.在NUMA環(huán)境下，處理器與處理器之間通過QPI（Quick Path Interconnect）總線連接，實(shí)現(xiàn)跨處理器的內(nèi)存訪問.

在NUMA環(huán)境下，服務(wù)器的內(nèi)存容量、內(nèi)存帶寬得到了極大的提升.例如，一臺(tái)包含有2個(gè)處理器的服務(wù)器，可以容納768 GB內(nèi)存；而一臺(tái)包含有8個(gè)處理器的服務(wù)器的內(nèi)存可以達(dá)到3TB.如果按照2014年年中的內(nèi)存價(jià)格計(jì)算，購買768 GB內(nèi)存僅需6 000美元，而3 TB的內(nèi)存價(jià)格僅有24 000美金.內(nèi)存價(jià)格大幅下降和容量的大幅上升，使得內(nèi)存數(shù)據(jù)庫系統(tǒng)成為可能.NUMA的服務(wù)器架構(gòu)不僅內(nèi)存容量大幅上升，同時(shí)也使得內(nèi)存訪問帶寬有了極大的提升.內(nèi)存的多通道連接方式能夠大幅提升整個(gè)服務(wù)器中內(nèi)存訪問的帶寬，內(nèi)存多通道連接方式如圖3所示.對(duì)于一臺(tái)包含有兩個(gè)處理器的服務(wù)器而言，如果單個(gè)處理器在其四個(gè)通道上均安裝有內(nèi)存，那么該臺(tái)服務(wù)器能夠具有的總內(nèi)存訪問帶寬可以達(dá)到102.4 GB／s.由此可見NUMA環(huán)境下，服務(wù)器可以安裝大容量的內(nèi)存并可獲得足夠的訪問帶寬.

圖2 單節(jié)點(diǎn)處理器連接架構(gòu)Fig.2 Architecture of the single processor

圖3 NUMA內(nèi)存訪問Fig.3 NUMA memory access

內(nèi)存容量和訪問帶寬均獲得了極大的提升能力，但是內(nèi)存訪問延時(shí)方面，其性能提升的幅度有限.盡管處理器在內(nèi)存訪問方面已經(jīng)做了很多優(yōu)化（如內(nèi)存數(shù)據(jù)預(yù)取等），但是內(nèi)存訪問延遲依舊較大.針對(duì)于當(dāng)前包含有多級(jí)緩存的處理器架構(gòu)，內(nèi)存數(shù)據(jù)訪問延遲可以分成三大類，即內(nèi)存數(shù)據(jù)的順序訪問、隨機(jī)訪問、全域隨機(jī)訪問.由于cache的存在導(dǎo)致訪問延時(shí)的較大變化，具體內(nèi)存訪問延時(shí)如表1所示.

表1 Intel E5－2697，2.7Ghz，內(nèi)存訪問延遲Tab.1 Memory access latency for Intel E5－2697，2.7 Ghz

3.2 網(wǎng)絡(luò)訪問與延遲

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，當(dāng)前數(shù)據(jù)中心的網(wǎng)絡(luò)帶寬已經(jīng)有了大幅的提升，截止2014年，大部分的數(shù)據(jù)中心已經(jīng)大范圍內(nèi)普及萬兆網(wǎng)，而一些20 GB／s，40G B／s的InfiniBand網(wǎng)絡(luò)也逐步在各大數(shù)據(jù)中心使用.在部署并使用了上述網(wǎng)絡(luò)的環(huán)境下，其與機(jī)器之間的數(shù)據(jù)傳輸?shù)膸捠亲銐虻?

但是，按照當(dāng)前計(jì)算機(jī)系統(tǒng)發(fā)送消息的機(jī)制，待發(fā)送的消息需要在操作系統(tǒng)、以太網(wǎng)卡的緩存中進(jìn)行緩存并進(jìn)行轉(zhuǎn)發(fā)，同時(shí)待發(fā)送的網(wǎng)絡(luò)包在經(jīng)過交換機(jī)的時(shí)候需要緩存、尋址、轉(zhuǎn)發(fā)等操作，致使網(wǎng)絡(luò)數(shù)據(jù)包在經(jīng)過網(wǎng)絡(luò)傳輸?shù)臅r(shí)候存在較大的延遲，如圖4所示.據(jù)統(tǒng)計(jì)不同種類的網(wǎng)絡(luò)延遲如表2所示.

圖4 數(shù)據(jù)包在計(jì)算機(jī)間的傳輸Fig.4 Package transmission between nodes

表2 各類網(wǎng)絡(luò)延遲Tab.2 Latency of networks

3.3 通信瓶頸

按照當(dāng)前的計(jì)算機(jī)硬件配置內(nèi)存集群計(jì)算系統(tǒng)，可以通過如下方法計(jì)算整個(gè)系統(tǒng)的瓶頸，在獲悉整個(gè)系統(tǒng)的瓶頸之后，即可進(jìn)一步改良算法以提升整個(gè)內(nèi)存集群系統(tǒng)的性能.然而，整個(gè)內(nèi)存集群計(jì)算系統(tǒng)瓶頸的獲悉，主要可以通過分析整個(gè)系統(tǒng)I／O性能獲得.以某一內(nèi)存集群計(jì)算系統(tǒng)為例，該集群中單臺(tái)服務(wù)器包含有2個(gè)Intel E5－2697處理器，24條32 GB的內(nèi)存條，10塊7 200轉(zhuǎn)的磁盤，各臺(tái)機(jī)器通過10 GB的以太網(wǎng)互聯(lián)，針對(duì)上述內(nèi)存集群計(jì)算系統(tǒng)計(jì)算處理器處理不同媒介I／O（如內(nèi)存、磁盤、網(wǎng)絡(luò)）時(shí)的效率.通過計(jì)算可以獲得，處理器處理內(nèi)存中的每比特位的數(shù)據(jù)平均需要4個(gè)時(shí)鐘周期，處理磁盤中的每比特位數(shù)據(jù)需要27個(gè)時(shí)鐘周期，而然處理網(wǎng)絡(luò)中另外一臺(tái)機(jī)器內(nèi)存中的每比特位數(shù)據(jù)需要13個(gè)時(shí)鐘周期.由此可以推出，在內(nèi)存集群計(jì)算環(huán)境下，網(wǎng)絡(luò)通信將成為整個(gè)系統(tǒng)的瓶頸（見圖5）.

綜上所述，網(wǎng)絡(luò)通訊是整個(gè)內(nèi)存集群計(jì)算系統(tǒng)的瓶頸，上層的商務(wù)智能分析系統(tǒng)需要著重針對(duì)該系統(tǒng)瓶頸進(jìn)行優(yōu)化.

圖5 系統(tǒng)的瓶頸（2＊Intel E5－2697處理器［2.7 Ghz，12核，24線程］，24＊32 GB RAM［1600］，10＊72 k HDD，10 GB以太網(wǎng)）Fig.5 System bottleneck（2＊Intel E5－2697 Processor［2.7 Ghz，12 Cores，24 Threads］，24＊32 GB RAM［1600］，10＊72 k HDD，10 GB Ethernet）

5 內(nèi)存數(shù)據(jù)庫系統(tǒng)值得探索方向

根據(jù)上述對(duì)內(nèi)存集群系統(tǒng)的分析，在如下方面仍需較多的研究投入，如可以針對(duì)目前的硬件體系架構(gòu)，以及用戶對(duì)數(shù)據(jù)分析的需求，構(gòu)建分布式全內(nèi)存數(shù)據(jù)管理系統(tǒng)，重點(diǎn)研究分布式系統(tǒng)的拓?fù)浣Y(jié)構(gòu)、數(shù)據(jù)存儲(chǔ)管理策略、分布式并行調(diào)度模式等.

（1）針對(duì)高性能、高可靠服務(wù)器的無共享分布式全內(nèi)存系統(tǒng)拓?fù)浣Y(jié)構(gòu) 針對(duì)分布式系統(tǒng)所采用服務(wù)器的高性能、高可靠性，以及內(nèi)存數(shù)據(jù)的易失性，研究并確定分布式系統(tǒng)的總體架構(gòu)（如主從架構(gòu)、基于DHT的分布式架構(gòu)等），并以實(shí)現(xiàn)整體分布式系統(tǒng)的處理高效性、可靠性、可擴(kuò)展性、可容錯(cuò)性為主要研究目標(biāo).

（2）面向異構(gòu)和多層次緩存、內(nèi)存體系結(jié)構(gòu)的分布式數(shù)據(jù)布局與索引策略 為了緩解內(nèi)存數(shù)據(jù)訪問效率與處理器頻率之間的不匹配問題（即內(nèi)存墻），以及處理器高功耗問題（即功耗墻），目前服務(wù)器大多采用多處理器、多核、多層緩存架構(gòu)（如核內(nèi)獨(dú)立第一、二層緩存，核間共享第三層緩存），并通過QPI（quick path interconnect）［8］連接內(nèi)存與各處理器，實(shí)現(xiàn)非統(tǒng)一存儲(chǔ)器存?。╪on－uniform memory access）的共享內(nèi)存架構(gòu)；而且服務(wù)器之間存在著緩存層次、緩存容量、緩存介質(zhì)、緩存對(duì)齊模式等不統(tǒng)一、不一致的情況.針對(duì)上述共享緩存、共享內(nèi)存架構(gòu)、異構(gòu)緩存內(nèi)存等特性，設(shè)計(jì)全新的分布內(nèi)存數(shù)據(jù)組織結(jié)構(gòu)，考慮單服務(wù)器內(nèi)緩存感知的數(shù)據(jù)結(jié)構(gòu)對(duì)齊（align）、填補(bǔ)（padding）方法，以避免對(duì)不同層次結(jié)構(gòu)中高速緩存行的并發(fā)訪問；提出全新的內(nèi)存數(shù)據(jù)布局策略、預(yù)取策略、數(shù)據(jù)訪問策略，以提升緩存的命中率針對(duì)內(nèi)存墻瓶頸；考慮服務(wù)器間或緩存參數(shù)無關(guān)數(shù)據(jù)備份策略、數(shù)據(jù)調(diào)度方法；定義全新的內(nèi)存數(shù)據(jù)訪問性能的度量標(biāo)準(zhǔn)（如緩存未命中次數(shù)替代傳統(tǒng)的磁盤I／O次數(shù)）.針對(duì)內(nèi)存訪問隨機(jī)訪問的特性（隨機(jī)訪問復(fù)雜度為O（1）），設(shè)計(jì)全新的緩存常駐索引策略，以提升數(shù)據(jù)檢索效率.在新的硬件環(huán)境下，先前所有針對(duì)磁盤特性設(shè)計(jì)的數(shù)據(jù)布局、索引策略均不再適用，需要針對(duì)內(nèi)存、緩存設(shè)計(jì)全新的算法.

（3）跨核、跨處理器、跨服務(wù)器的多粒度并行處理框架 分布式全內(nèi)存數(shù)據(jù)管理系統(tǒng)是共享緩存、共享內(nèi)存、無共享系統(tǒng)的復(fù)合系統(tǒng)，結(jié)合各類系統(tǒng)的優(yōu)缺點(diǎn)，以及應(yīng)用服務(wù)的復(fù)雜度、所需的時(shí)效性，設(shè)計(jì)有效的并行處理策略，提供應(yīng)用與應(yīng)用之間、應(yīng)用內(nèi)部、操作與操作之間、操作內(nèi)部的并行策略，以提升系統(tǒng)的并發(fā)度，提高內(nèi)存數(shù)據(jù)的局部性（節(jié)點(diǎn)局部性、空間局部性、時(shí)間局部性），降低網(wǎng)絡(luò)信息交互，提升內(nèi)存數(shù)據(jù)訪問性能；設(shè)計(jì)基于流水線式內(nèi)存化并行處理（如MapReduc等）框架；基于迭代式的內(nèi)存化并行處理框架（暫無相應(yīng)系統(tǒng)），以滿足各類網(wǎng)頁數(shù)據(jù)、商務(wù)智能數(shù)據(jù)、科學(xué)數(shù)據(jù)的處理需求.

（4）緩存感知、內(nèi)存感知的分布式數(shù)據(jù)一致性維護(hù) 內(nèi)存數(shù)據(jù)具有易失性，服務(wù)器斷電或者崩潰時(shí)，數(shù)據(jù)將丟失；研究內(nèi)存數(shù)據(jù)的備份策略、數(shù)據(jù)更新的日志策略、無共享系統(tǒng)環(huán)境下備份的并發(fā)更新，以保持?jǐn)?shù)據(jù)備份與備份之間的按需一致性、數(shù)據(jù)的容錯(cuò)性、數(shù)據(jù)的可恢復(fù)性等.研究共享緩存、共享內(nèi)存環(huán)境下，緩存、內(nèi)存中共享數(shù)據(jù)操作的并發(fā)可見性，即緩存、內(nèi)存數(shù)據(jù)操作一致性（coherence）.研究合理的數(shù)據(jù)一致性維護(hù)策略（如加鎖、加時(shí)間戳等）實(shí)現(xiàn)系統(tǒng)細(xì)粒度、可擴(kuò)展的并發(fā)控制.

（5）輕量級(jí)數(shù)據(jù)壓縮機(jī)制及壓縮感知數(shù)據(jù)處理 考慮到內(nèi)存容量的有限性，以及內(nèi)存數(shù)據(jù)與CPU處理頻率之間的不平衡性，通過有效的數(shù)據(jù)壓縮技術(shù)，可以提高內(nèi)存的使用效率，減少CPU的等待時(shí)間，增加QPI帶寬的利用率.研究通過輕量級(jí)壓縮技術(shù)，如共有值壓縮、行程編碼、聚集編碼、間接編碼等壓縮技術(shù)，而非重量級(jí)編碼技術(shù)如Lempel－Ziv編碼等，并結(jié)合內(nèi)存、緩存的結(jié)構(gòu)特性實(shí)現(xiàn)對(duì)按列存儲(chǔ)的結(jié)構(gòu)化數(shù)據(jù)或非結(jié)構(gòu)化數(shù)據(jù)的壓縮處理，提高數(shù)據(jù)處理性能.研究壓縮感知的查詢執(zhí)行技術(shù)、壓縮感知的數(shù)據(jù)分析技術(shù)等，以進(jìn)一步提升數(shù)據(jù)處理時(shí)效性.

5 總 結(jié)

商務(wù)智能不斷對(duì)實(shí)時(shí)交互式數(shù)據(jù)分析提出了更高的需求，而計(jì)算機(jī)硬件的發(fā)展，特別是內(nèi)存技術(shù)的發(fā)展（如內(nèi)存容量、NUMA內(nèi)存架構(gòu)等）使得內(nèi)存集群計(jì)算已經(jīng)成為可能并且是未來發(fā)展的主要趨勢(shì).同時(shí)內(nèi)存集群計(jì)算為實(shí)時(shí)交互式數(shù)據(jù)處理提供了硬件基礎(chǔ).通過仔細(xì)分析當(dāng)前內(nèi)存集群計(jì)算系統(tǒng)的瓶頸問題，推出網(wǎng)絡(luò)通信是該類系統(tǒng)的主要性能瓶頸.為了解決這一瓶頸，同時(shí)考慮到數(shù)據(jù)存儲(chǔ)媒介的變化（即有磁盤轉(zhuǎn)向內(nèi)存），內(nèi)存集群計(jì)算系統(tǒng)的網(wǎng)絡(luò)拓?fù)?、并行處理框架等均是為了急需重點(diǎn)研究的問題.

［1］ STONEBRAKER M，CETINTEMEL U.“One size fits all”：an idea whose time has come and gone［C］／／Proceedings of ICDE’2005.

［2］ STONEBRAKER M，MADDEN S，ABADI D，J，et al.The end of an architectural era：（it’s time for a complete rewrite）［C］／／Proceedings of VLDB’2007.

［3］ GRAY J.A Conversation with Jim Gray［J］.Queue Storage，2003，1（4）.

［4］ THACKER C P.Improving the future by examining the past［C］／／Proceedings of ISCA’10.

［5］ BONCZ P A，KERSTEN M L，MANEGOLD S.Breaking the memory wall in MonetDB［J］.Communications of the ACM，2008，51（12）.

［6］ HASSO P，ALEXANDER Z.In－memory data management：an inflection point for enterprise applicaions［M］.Springer，2011.11.

［7］ Von Neumann Bottleneck［EB／OL］.http：／／c2.com／cgi／wiki？VonNeumannBottleneck，1973.

［8］ INTEL.An introduction to the Intel QuickPath interconnect［EB／OL］.http：／／www.intel.com／technology／quickpath／introduction.pdf，retrieved January 14th 2011.

［9］ LI K，HUDAN P.Memory coherence in shared virtual memory systems［J］.ACM trans.Computer Systems，1989，74（4）：321－359.

［10］ Fleisch B，Popek G.Mirage：a coherent distributed shared memory design［C］／／Proceedings of 14th Symposym Operation system Principles，1989：211－223.

［11］ LENOSKI D，et al.The directory－based cache coherence protocol for the Dash multiprocessor［C］／／Proceedings of 17th Int Symp Computer Architecure，1990：148－159.

［12］ BENNETT J K，CARTER J B，ZWAENEPOEL W.Munin：distributed shared memory based on type－specific memory coherence［C］／／Proceedings of principles and practice of parallel programming，1990.

［13］ STONEBRAKER M.Managing persistent objects in a multi－level store［C］／／Proceedings of SIGMOD，1991：2－11.

［14］ SHENTH A P，LARSON J A.Federated database systems for managing distributed，heterogeneous，and autonomous databases［J］.Journal ACM Computing Surveys，1990，22（3）.

［15］ WUIF W A，MCKEE S A.Hitting the memory wall：implications of the obvious［J］.ACM SIGARCH Computer Architecture News，1994，23（1）：20－24.

［16］ HENNESSY J L，PATTERSON D A.Computer architecture：aquantitative approach［M］.Morgan Kaufmann Pub，2002.

［17］ SHATDAL A，KANT C，NAUGHTON J F.Cache conscious algorithms for relational query processing［C］／／Proceedings of VLDB’1994，510－521.

［18］ HE B，LUO Q，CHOI B.Cache－conscious automata for XML filtering［J］.TKDE，2006，18（12）：1629－1644.

［19］ ZHOU J，ROSS K A.Buffering accesses to memory－resident index structures［C］／／Proceedings of vldb’2003.

［20］ BONCZ P，MANGEGOLD S，KERSTEN M.Database architecture optimized for the new bottleneck：Memory access［C］／／Proceedings of VLDB’1999.

［21］ BOHANNON P，MCLLROY P，RASTOGI R.Main－memory index structures with fixed－size partial keys［J］.SIGMOD Record，2001，20（2）.

［22］ CHILIMBI T M，HILL M D，LARUS J R.Cache－conscious structure layout［C］／／Proceedings of SIGPLAN’1999.

［23］ bOHANNON P，MCLLROY P，RASTOGI R.Main－memory index structures with fixed－size partial keys［C］／／Proceedings of Sigmod Record，2001，30（2）.

［24］ CHEN S，AILAMAKI A，GIBBONS P B.Improving hash join performance through prefetching［J］.TODS，2007，32（3）.

［25］ AGGARWAL A，VITTER J，et al.The input／output complexity of sorting and related problems［J］.Communications of the ACM，1988，31（9）.

［26］ HE B，LUO Q.Cache－oblivious nested－loop joins［C］／／Proceedings of CIKM’2006.

［27］ HE B，LUO Q.Cache－oblivious hash join，Technical report HKUST－cs06－04，2006

［28］ FRIGO M，LEISERSON C E，PROKOP H，et al.Cache－oblivious algorithms［C］／／Proceedings of FOCS’1999.

［29］ BENFDER M A，DEMAINE E D，F(xiàn)arach－Colton M.Cache－oblivious B－trees［C］／／Proceedings of FOCS’2000.

［30］ BENDER M A，DUAN Z，LACONO J，et al.A locality－preserving cache－oblivious dynamic dictionary［J］.Journal Algorithms，2004，52（2）.

［31］ YOTOV K，ROEDER T，PINGALI K，et al.An experimental comparison of cache－oblivious and cache－conscious programs［C］／／Proceedings of SPAA’2007.

［32］ AILAMAKI A.Database architectures for new hardware［C］／／Proceedings of VLDB’2004.

［33］ HE B，LI Y，LUO Q，et al.EaseDB：A cache－oblivious in－memory query processor［C］／／Proceedings of SIGMOD’2007.

［34］ BONCZ P，GRUST T，van KEULEN M.et al.MonetDB／XQuery：a fast XQuery processor powered by a relational engine［C］／／Proceedings of SIGMOD’2006.

［35］ FASTDB.2002.http：／／www.ispras.ru／knizhnik／fastdb.html.

［36］ TIMESTEN.2006.http：／／www.oracle.com／timesten／index.html.

［37］ KALLMAN R，KIMURA H，NATKINS J，et al.H－store：a high－performance，distributed main memory transaction processing system［C］／／Proceedings of VLDB’2008.

［38］ VoltDB，2009，http：／／voltdb.com.

［39］ HANA，2012，http：／／www.sap.com／solutions／technology／in－memory－computing－platform／hana／overview／index.epx.

［40］ Memcached－a distributed memory object caching system，http：／／memcached.org，2003.

［41］ Membase，http：／／www.couchbase.com／membase.

［42］ OUSTERHOUT J，AGRAWAL P，ERICKSON D.et al.The case for RAMClouds：scalable high－performance storage entirely in DRAM［J］.ACM SIGOPS operation systems review，2010，43（4）.

［43］ ROSENBLUM M，OUSTERHOUT J K.The design and implementation of a log－structured file system［J］.ACM transactions on computer systems，1992，10（1）.

［44］ ONGARO D，RUMBLE S M，STUTSMAN R.et al.Fast crash recovery in RAMCloud［C］／／Proceedings of SOSP’2011.

［45］ Resilient distributed datasets：A fault－tolerant abstraction for in－memory cluster computing，Resilient distributed datasets：A fault－tolerant abstraction for in－memory cluster computing，Technical Report UCB／EECS－2011－82，EECS Department，University of California，Berkeley，2011.

［46］ POWER R，LI J.Piccolo：building fast，distributed programs with partitioned tables［C］／／Proc.OSDI 2010，2010.

［47］ YU Y，ISARD M，F(xiàn)ETTERLY D，et al.Currey.DryadLINQ：A system for general－purpose distributed dataparallel computing using a high－level language［C］／／OSDI’08，2008.

［48］ OLSTON C，REED B，SRIVASTAVA U.et al.Tomkins.Pig latin：a not－so－foreign language for data processing［C］／／Proceedings of SIGMOD ‘08，1099－1110.

［49］ CHAMBERS C，RANIWALA A，PERRY F.et al.Flumejava：easy，ef？cient data－parallel pipelines［C］／／Proceedings of the 2010 ACM SIGPLAN conference on Programming language design and implementation，PLDI’10.ACM，2010.

［50］ Storm，https：／／github.com／nathanmarz／storm.

［51］ MURRAY D G，SCHWARZKOPF M，SMOWTON C，et al.Hand.Ciel：a universal execution engine for distributed data－？ow computing.In NSDI，2011.

［52］ EKANAYAKE J，LI H，ZHANG B，et al.Twister：a runtime for iterative mapreduce［C］／／HPDC’10，2010.

［53］ BU Y，HOWE B，BALAZINSKA M，et al.Ernst.HaLoop：efficient iterative data processing on large clusters.Proc.VLDB Endow.，3：285－296，September 2010.

［54］ MALEWICZ G，AUSTERN M H，BIK A J C，et al.Pregel：a system for large－scale graph processing［C］／／Proceedings of SIGMOD’2010.

［55］ SolidDB，http：／／www－01.ibm.com／software／data／soliddb／

［56］ ZAHARIA M，CHOWDHURY M，F(xiàn)RANKLIN M J，et al.Spark：cluster computing with working sets［C］／／Proceedings of the 2nd USENIX conference on Hot topics in cloud computing，2010.

［57］ Garter.Gartner Taps Predictive Analytics as Next Big Business Intelligence Trend，http：／／www.enterpriseappstoday.com／business－intelligence／gartner－taps－predictive－analytics－as－next－big－business－intelligence－trend.html，2012.4.

［58］ SCHAPRANOW M P，KOHNE R.ZEIER A.Enabling real－time charging for smart grid infrastructures using inmemory databases［C］／／1st IEEE LCN Workshop on Smart Grid Networking Infrastructure，2010.

［59］ SCHAPRANOW M P，ZEIER A，Plattner H.A formal model for enabling RFID in pharmaceutical supply chains［C］／／44th Hawaii International Conference on System Sciences，2011.