最近业界有很多技术和产品都认为属于内存计算的范畴，由于我个人也从事于内存计算产品的研发，所以想借个机会，跟各位聊聊到底什么是内存计算技术，以及比较一些现在两种比较主流的内存计算技术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技术上的创新也很难造福千千万 万的程序员。