最近業界有很多技術和產品都認為屬于內存計算的范疇，由于我個人也從事于內存計算產品的研發，所以想借個機會，跟各位聊聊到底什么是內存計算技術，以及比較一些現在兩種比較主流的內存計算技術Apache Spark和SAP HANA，它們的特點和區別。

什么是內存計算技術？

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

Apache Spark的設計思路

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

圖1. Spark的核心機制圖

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

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

在效率層面，由于·使用Scala這樣基于JVM的高級語言來構建，顯而易見會有一定程度的損失，標準Java程序執行時候的速度基本接近C/C++ O0模式的程度，會比C/C++ O2模式的速度慢60%左右。

在技術創新方面，個人覺得Spark還談不上創新，因為它其實屬于比較典型In-Memory Data Grid內存數據網格，無論從7-8年前的IBM WebSphere eXtreme Scale到最近幾年新出，并用于12306的Pivotal Gemfire都采用較類似的架構，都主要通過多臺機器拼成一個較大內存網格，里面存儲的數據都接近Key-Value模式，并且這個內存網格會根據很多 機制來確保數據會持久穩定地保存在內存中，并能保持數據的更新和恢復，而在網格上面使用一些常見的算子，來執行靈活的查詢，并且用戶可以寫的程序來直接調 用這些算子。

圖2. Spark的生態圈

但是在整體架構的展現形式方面的，個人覺得Spark的確是領先同類開源產品兩個身位的，因為它已經接近實現其Full Stack的夢想，它包括Spark Streaming，GraphX，MLBase，還有BlinkDB這個絕對的亮點（雖熱個人覺得隨著計算能力的提高，大數據在今后直接算也是可行 的）。還有，個人真心對AMPLab的推廣能力深深佩服。個人對Spark的總結是“創新的產品生態，較為傳統的技術”。

SAP HANA的設計思路

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

圖3. SAP HANA計算引擎

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

在存儲數據結構方面，HANA是行存和列存都支持，但是根據我碰到的一些用戶反饋，用戶基本上還是以使用列存為主。

圖4. SAP HANA產品全貌

在產品形態方面，它主要還是提供多種工具和產品接入，都主要以分析為主，比如類似SAP NetWeaver或者BO這樣BI工具，還有支持文本分析，以及各種預測算法，并且在這些之上，開發出很多針對某些行業的應用，比如，財務方面，物流方 面和廣告方面的，所以根據部分用戶的反饋， HANA如果只是當它內存數據庫來用，其實價值不是特別大，但是如果能把它當中開發平臺來使用，那么就很物盡其用，因為它上面能利用的庫和應用比較多。在 銷售方式方面，還是傳統的License模式。總體而言，個人覺得SAP HANA這樣內存計算平臺“有特色的技術，較傳統的產品形態”。

綜述

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

對于那些希望有一整套Full Stack的支持初創企業，個人支持你們去使用Spark，因為他們這個群體本身的特色就是喜歡嘗試新鮮的東西，數據不會特別大，需求會比較多變，同時也不會使用到特別復雜的功能，所以Spark對他們而言，更適合。

對于HANA的，個人覺得特別適合那些傳統企業，因為它的SQL接口更成熟，速度更快，可以做到復雜查詢實時出結果，于此同時它提供的文本分析工具 和數據挖掘工具，但可惜許可證成本太高，并且也因為這個原因，導致使用HANA的群體比較小，沒有一個生態群，所以HANA技術上的創新也很難造福千千萬 萬的程序員。