最近業(yè)界有很多技術(shù)和產(chǎn)品都認(rèn)為屬于內(nèi)存計(jì)算的范疇，由于我個(gè)人也從事于內(nèi)存計(jì)算產(chǎn)品的研發(fā)，所以想借個(gè)機(jī)會(huì)，跟各位聊聊到底什么是內(nèi)存計(jì)算技術(shù)，以及比較一些現(xiàn)在兩種比較主流的內(nèi)存計(jì)算技術(shù)Apache Spark和SAP HANA，它們的特點(diǎn)和區(qū)別。

       什么是內(nèi)存計(jì)算技術(shù)？

       關(guān)于內(nèi)存計(jì)算，就像云計(jì)算和大數(shù)據(jù)一樣，其實(shí)無論在百度百科還是Wikipedia都沒有非常精確的描述，但是有幾個(gè)共通的關(guān)鍵點(diǎn)，我在這里給大家總結(jié)一下：其一是數(shù)據(jù)放在內(nèi)存中，至少和當(dāng)前查詢工作涉及到的數(shù)據(jù)放在都要放在內(nèi)存中；其二是多線程和多機(jī)并行，也就是盡可能地利用現(xiàn)代x86 Xeon CPU線程數(shù)多的優(yōu)勢來加速整個(gè)查詢；其三是支持多種類型的工作負(fù)載，除了常見和基本的SQL查詢之后，還通常支持?jǐn)?shù)據(jù)挖掘，更有甚者支持Full Stack（全棧），也就是常見編程模型都要支持，比如說SQL查詢，流計(jì)算和數(shù)據(jù)挖掘等。

       Apache Spark的設(shè)計(jì)思路

       大家都知道，現(xiàn)在Apache Spark可以說是最火的開源大數(shù)據(jù)項(xiàng)目，就連EMC旗下專門做大數(shù)據(jù)Pivotal也開始拋棄其自研十幾年GreenPlum技術(shù)，轉(zhuǎn)而投入到Spark技術(shù)開發(fā)當(dāng)中，并且從整個(gè)業(yè)界而言，Spark火的程度也只有IaaS界的OpenStack能相提并論。那么本文作為一篇技術(shù)文章，我們接著就直接切入它的核心機(jī)制吧。

       圖1. Spark的核心機(jī)制圖

       在Spark的核心機(jī)制方面，主要有兩個(gè)層面：首先是RDD（Resilient Distributed Datasets），RDD是Spark的最基本抽象，是對分布式內(nèi)存的抽象使用，實(shí)現(xiàn)了以操作本地集合的方式來操作分布式數(shù)據(jù)集的抽象實(shí)現(xiàn)，它表示已被分區(qū)，不可變的并能夠被并行操作的數(shù)據(jù)集合，并且通常緩存到內(nèi)存中，并且每次對RDD數(shù)據(jù)集的操作之后的結(jié)果，都可以存放到內(nèi)存中，下一個(gè)操作可以直接從內(nèi)存中輸入，省去了Map Reduce框架中由于Shuffle操作所引發(fā)的大量磁盤IO。這對于迭代運(yùn)算比較常見的機(jī)器學(xué)習(xí)算法, 交互式數(shù)據(jù)挖掘來說，效率提升比較大。其次，就是在RDD上面執(zhí)行的算子（Operator），在Spark的支持算子方面，主要有轉(zhuǎn)換（Transformation）和操作（Action）這兩大類。在轉(zhuǎn)換方面支持算子有 map， filter，groupBy和join等，而在操作方面支持算子有count，collect和save等。

       Spark常見存儲(chǔ)數(shù)據(jù)的格式是Key-Value，也就是Hadoop標(biāo)準(zhǔn)的Sequence File，但同時(shí)也聽說支持類似Parquet這樣的列存格式。Key-Value格式的優(yōu)點(diǎn)在于靈活，上至數(shù)據(jù)挖掘算法，明細(xì)數(shù)據(jù)查詢，下至復(fù)雜SQL處理都能承載，缺點(diǎn)也很明顯就是存儲(chǔ)空間比較浪費(fèi)，和類似Parquet列存格式相比更是如此，key-Value格式數(shù)據(jù)一般是原始數(shù)據(jù)大小的2倍左右，而列存一般是原始數(shù)據(jù)的1/3到1/4。

       在效率層面，由于·使用Scala這樣基于JVM的高級(jí)語言來構(gòu)建，顯而易見會(huì)有一定程度的損失，標(biāo)準(zhǔn)Java程序執(zhí)行時(shí)候的速度基本接近C/C++O0模式的程度，會(huì)比C/C++ O2模式的速度慢60%左右。

       在技術(shù)創(chuàng)新方面，個(gè)人覺得Spark還談不上創(chuàng)新，因?yàn)樗鋵?shí)屬于比較典型In-Memory Data Grid內(nèi)存數(shù)據(jù)網(wǎng)格，無論從7-8年前的IBM WebSphere eXtreme Scale到最近幾年新出，并用于12306的Pivotal Gemfire都采用較類似的架構(gòu)，都主要通過多臺(tái)機(jī)器拼成一個(gè)較大內(nèi)存網(wǎng)格，里面存儲(chǔ)的數(shù)據(jù)都接近Key-Value模式，并且這個(gè)內(nèi)存網(wǎng)格會(huì)根據(jù)很多機(jī)制來確保數(shù)據(jù)會(huì)持久穩(wěn)定地保存在內(nèi)存中，并能保持?jǐn)?shù)據(jù)的更新和恢復(fù)，而在網(wǎng)格上面使用一些常見的算子，來執(zhí)行靈活的查詢，并且用戶可以寫的程序來直接調(diào)用這些算子。

       圖2. Spark的生態(tài)圈

       但是在整體架構(gòu)的展現(xiàn)形式方面的，個(gè)人覺得Spark的確是領(lǐng)先同類開源產(chǎn)品兩個(gè)身位的，因?yàn)樗呀?jīng)接近實(shí)現(xiàn)其Full Stack的夢想，它包括Spark Streaming，GraphX，MLBase，還有BlinkDB這個(gè)絕對的亮點(diǎn)（雖熱個(gè)人覺得隨著計(jì)算能力的提高，大數(shù)據(jù)在今后直接算也是可行的）。還有，個(gè)人真心對AMPLab的推廣能力深深佩服。個(gè)人對Spark的總結(jié)是“創(chuàng)新的產(chǎn)品生態(tài)，較為傳統(tǒng)的技術(shù)”。

       SAP HANA的設(shè)計(jì)思路

       其實(shí)至少10年前就有一波內(nèi)存計(jì)算的風(fēng)潮，那時(shí)代表性的產(chǎn)品主要有用于OLTP事務(wù)加速的Timeten和Altibase，，而2010年開始的內(nèi)存計(jì)算技術(shù)產(chǎn)品，最有代表性的莫過于SAP HANA，由于HANA公開資料比較少，所以在技術(shù)方面的描述沒辦法像Spark那樣的詳細(xì)，那么我這邊先根據(jù)部分公開的資料和我的一些理解稍微和大家聊聊它使用到的一些核心技術(shù)。

       圖3. SAP HANA計(jì)算引擎

       主要有三個(gè)方面，首先，在性能優(yōu)化方面，它盡可能地利用Intel x86 CPU特性，當(dāng)然這是和他們在HANA設(shè)計(jì)初期就和德國Intel深度合作有關(guān)，主要做了兩個(gè)設(shè)計(jì)：其一是全面利用最新的Intel指令集，在處理邏輯上面，全面采用Vector Processing的理念從而盡可能地使用最新的SSE4.1和SSE4.2等指令集，還有就是在NUMA場景下降低消耗，使其多線程性能提升參數(shù)盡可能地接近1；其二是在數(shù)據(jù)結(jié)構(gòu)方面，為了盡可能地利用好Cache，并盡可能少地訪問內(nèi)存，所以推出了緩存敏感的CSB（Cache Sensitive B+）樹來代替?zhèn)鹘y(tǒng)的B樹；其次，HANA還支持動(dòng)態(tài)編譯，無論是SQL查詢還是MDX查詢等，在HANA內(nèi)部都會(huì)都被轉(zhuǎn)譯一個(gè)公共的表示層，名為L語言，并且在執(zhí)行之前會(huì)使用LLVM來進(jìn)行編譯為二進(jìn)制代碼，并執(zhí)行，這樣做的好處主要是避免傳統(tǒng)數(shù)據(jù)庫引擎繁瑣的Switch-Case邏輯，并且由于這些Switch-Case邏輯很容易導(dǎo)致Context切換，所以如果避免類似的邏輯，這樣對整體性能裨益良多；還有就是完全內(nèi)存化，也就是確保所有數(shù)據(jù)都在內(nèi)存中，就算是用來做數(shù)據(jù)安全性的Snapshot快照也不使用廉價(jià)的硬盤，而是使用昂貴的SSD來做保存，這樣保存和恢復(fù)都更快。

       在存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)方面，HANA是行存和列存都支持，但是根據(jù)我碰到的一些用戶反饋，用戶基本上還是以使用列存為主。

       圖4. SAP HANA產(chǎn)品全貌

       在產(chǎn)品形態(tài)方面，它主要還是提供多種工具和產(chǎn)品接入，都主要以分析為主，比如類似SAP NetWeaver或者BO這樣BI工具，還有支持文本分析，以及各種預(yù)測算法，并且在這些之上，開發(fā)出很多針對某些行業(yè)的應(yīng)用，比如，財(cái)務(wù)方面，物流方面和廣告方面的，所以根據(jù)部分用戶的反饋， HANA如果只是當(dāng)它內(nèi)存數(shù)據(jù)庫來用，其實(shí)價(jià)值不是特別大，但是如果能把它當(dāng)中開發(fā)平臺(tái)來使用，那么就很物盡其用，因?yàn)樗厦婺芾玫膸旌蛻?yīng)用比較多。在銷售方式方面，還是傳統(tǒng)的License模式�？傮w而言，個(gè)人覺得SAPHANA這樣內(nèi)存計(jì)算平臺(tái)“有特色的技術(shù)，較傳統(tǒng)的產(chǎn)品形態(tài)”。

       綜述

       為什么要聊聊內(nèi)存計(jì)算這個(gè)問題，因?yàn)槲一趥�(gè)人多年的研發(fā)經(jīng)驗(yàn)，對于常見的SQL分析而言，由于其本身讀寫形式是連續(xù)讀，而連續(xù)讀硬盤本身的讀寫能力也是挺強(qiáng)的，再加上存儲(chǔ)數(shù)據(jù)本身是壓縮的，所以當(dāng)硬盤個(gè)數(shù)和CPU個(gè)數(shù)比較匹配的話（比如1：1），那么在執(zhí)行數(shù)據(jù)分析的時(shí)候，數(shù)據(jù)是否在內(nèi)存并不是極為關(guān)鍵，性能比在1比6左右，也就是數(shù)據(jù)完全在內(nèi)存比數(shù)據(jù)完全在硬盤中快5倍左右，這個(gè)性能比在大多數(shù)情況下用戶不會(huì)覺得非常關(guān)鍵，所以個(gè)人覺得單純把全部數(shù)據(jù)放在內(nèi)存中的意義不是特別大，因此我特地拿出Apache Spark和SAP HANA這兩款產(chǎn)品的出來比較，從而發(fā)覺現(xiàn)在其實(shí)內(nèi)存計(jì)算沒那么簡單，還是有非常多的門道的。那么對于用戶，該如何在這兩種技術(shù)之間選擇呢？下面是我個(gè)人的見解：

       對于那些希望有一整套FullStack的支持初創(chuàng)企業(yè)，個(gè)人支持你們?nèi)ナ褂肧park，因?yàn)樗麄冞@個(gè)群體本身的特色就是喜歡嘗試新鮮的東西，數(shù)據(jù)不會(huì)特別大，需求會(huì)比較多變，同時(shí)也不會(huì)使用到特別復(fù)雜的功能，所以Spark對他們而言，更適合。

       對于HANA的，個(gè)人覺得特別適合那些傳統(tǒng)企業(yè)，因?yàn)樗腟QL接口更成熟，速度更快，可以做到復(fù)雜查詢實(shí)時(shí)出結(jié)果，于此同時(shí)它提供的文本分析工具和數(shù)據(jù)挖掘工具，但可惜許可證成本太高，并且也因?yàn)檫@個(gè)原因，導(dǎo)致使用HANA的群體比較小，沒有一個(gè)生態(tài)群，所以HANA技術(shù)上的創(chuàng)新也很難造福千千萬萬的程序員。

       作者：吳朱華   來源：大數(shù)據(jù)邦

文章為作者獨(dú)立觀點(diǎn)，不代表經(jīng)管之家立場