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

（1.電子科技集團第三十二研究所，上海 200233；2.華東師范大學 數據科學與工程研究院，上海 200062）

0 引 言

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

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

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

本文通過分析內存數據管理的發(fā)展歷程與應用、計算機硬件發(fā)展歷程之間的關聯(lián)關系，論證網絡通信將成為未來內存集群計算系統(tǒng)的新瓶頸，需要從系統(tǒng)的拓撲結構，數據部署，多核、多處理器、集群等多粒度并行處理等方面研究并設計新系統(tǒng)，最后實現交互式分析處理的功能.

1 內存數據管理發(fā)展歷程

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

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

1.1 共享內存多處理機

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

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

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

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

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

1.4 分布式全內存數據管理系統(tǒng)

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

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

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

2 實時交互式數據分析

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

2.1 巨大的BI市場和新的應用需求

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

2.2 潛在的實時交互式數據分析應用

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

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

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

· 面向分析的自動訂貨決策.大型購物廣場通過分析歷史銷售數據，當前商品的流行趨勢，預測未來商品的銷售數量，并自動完成商品的訂購，包括選擇上游商品廠商，確定訂購商品的型號，數量，送貨時間，送貨地點等.

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

3 網絡通信將成為內存集群計算的瓶頸

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

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

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

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

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

圖2 單節(jié)點處理器連接架構Fig.2 Architecture of the single processor

圖3 NUMA內存訪問Fig.3 NUMA memory access

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

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

3.2 網絡訪問與延遲

隨著網絡技術的發(fā)展，當前數據中心的網絡帶寬已經有了大幅的提升，截止2014年，大部分的數據中心已經大范圍內普及萬兆網，而一些20 GB／s，40G B／s的InfiniBand網絡也逐步在各大數據中心使用.在部署并使用了上述網絡的環(huán)境下，其與機器之間的數據傳輸的帶寬是足夠的.

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

圖4 數據包在計算機間的傳輸Fig.4 Package transmission between nodes

表2 各類網絡延遲Tab.2 Latency of networks

3.3 通信瓶頸

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

綜上所述，網絡通訊是整個內存集群計算系統(tǒng)的瓶頸，上層的商務智能分析系統(tǒng)需要著重針對該系統(tǒng)瓶頸進行優(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以太網）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 內存數據庫系統(tǒng)值得探索方向

根據上述對內存集群系統(tǒng)的分析，在如下方面仍需較多的研究投入，如可以針對目前的硬件體系架構，以及用戶對數據分析的需求，構建分布式全內存數據管理系統(tǒng)，重點研究分布式系統(tǒng)的拓撲結構、數據存儲管理策略、分布式并行調度模式等.

（1）針對高性能、高可靠服務器的無共享分布式全內存系統(tǒng)拓撲結構 針對分布式系統(tǒng)所采用服務器的高性能、高可靠性，以及內存數據的易失性，研究并確定分布式系統(tǒng)的總體架構（如主從架構、基于DHT的分布式架構等），并以實現整體分布式系統(tǒng)的處理高效性、可靠性、可擴展性、可容錯性為主要研究目標.

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

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

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

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

5 總 結

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

［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，Farach－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，FETTERLY 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，FRANKLIN 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.