引言：
SAP邀请了我从分析师的角度，来评论一下“HANA与Exalytics”之间存在的争论。这个比较很有趣，所以我也欣然从命。这篇文章会让你们了解我对它们的看法。你们会看到，我不会把两者分得很清晰(而不看到文章最后，我和SAP之间关系也不会完全披露)。
Exalytics：
首先，来说说每个分析师都知道的事吧：Oracle生产了好些我们在零售业中称为山寨货的产品。
他们认为这是一个好行当，我觉得这也没错。这个模式很简单。当有人创造了一个产品，并证明了市场，Oracle(或者拿SAP打比方也无妨)就会开发出一个类似的产品。所以，一有 了VMWare (或其他厂商) 的 vSphere，就出现了Oracle的Oracle VM;Red Hat建立了一个围绕Linux的商业模式, Oracle 就创建了 “Oracle Linux –坚不可摧的商业核心”。
分析师们也深谙此道，并从此获利不菲。那些山寨产品——说得好听点就是“Oracle的紧跟潮流的产品”——在性能上与它们的效仿对象都能兼容。但在某些方面，或者某些边缘，Oracle声称自己的产品更胜一筹。
这些话让听到的人很困惑。他们一困惑，就会打电话给我们。作为一名分析师，我接到的这样的电话也不在少数，我也仔仔细细地研究过Oracle的一些产品。一直以来，我都认为Oracle能提供的产品，与你能在Pennys或者Target上看到的差不多，它们对于付不起或者不想付溢价的人来说是合适的替代品。这些人往往会限制自己的供应商数目，对产品也没什么太高的期望。
我这么想，是因为你对当今的市场只能抱有这种观感。毕竟就像在下雨前你匆忙从路边摊买到的一把伞一样，你会觉得这真好，因为它可以遮雨。但是你也不会指望这把伞能耐用到陪你走过多年的风风雨雨。
软件当然比一把伞更复杂。软件行业并不十分透明化，有时候要分辨出各种声明背后真实的含义是件很困难的事。你要一直、一直往下挖得很深——就像有时候我的客户会指责我——“挖到了杂草的根部”，这时候也许你就能得到真相，但是也会失去一部分说服力。
这一点让我想到了现在这个争论。这对我来说又是个熟悉的循环。SAP创造了HANA, Oracle紧接着生产了Exalytics，两者都是储存在内存中的数据库应用。于是我又接到了很多的电话。
HANA： 重要的特性
我会带你们过一遍两者的区别，与此同时希望我不要“挖到杂草根部”。在这个过程中我会引入一些比喻，如果你们觉得我说的没有说服力，请不要客气马上联系我。
要进行说明的话，我就要避开那些像是“内存中”或是“分析”的术语。鉴于SAP和Oracle现在正在用同样的词语，我们要关注的是“内存中”或是“分析”等术语要解决的更深层的问题。
而这些问题其实并不单一。问题1：传统的行式数据库能很好地存储数据，但在输出上则欠缺了一点。问题2，为了解决 问题1而诞生的众多“分析数据库”——包括但不限于SAP在使用的列式数据库——性能刚好相反。
我们需要的，往往是一个能很好地存储数据的列式数据库，或是一个能很好地输出数据的行式数据库。
HANA处理这个问题的方式就十分有意思。在它们的数据库中，你可以选择处理数据的方式：要么行式要么列式。(如果你想的话，你可以在脑中模拟出一个控制切换的开关。)所以，如果你需要优化只读，然后让列式数据库达到其设计目的——一份快速灵活的分析报告的话，你可以拨动开关，告诉HANA： “我要运行报告。”。如果需要优化写入，使行式数据库达成所愿——完成事务行为，你可以拨动开关，告诉HANA：“我正在进入一个事务。”
其实数据都是一样的，拨动开关决定的只是你的访问模式。
我以前的同行、现在的一名SAP主管Adam Their曾经向我解释道：“其实这是一个反分析的数据库。”(这应该不是SAP的官方说法，但是我很能理解。)他们是怎么让数据库“反分析”的呢?这个时候就要快速钻入杂草底部了。他们使用在内存中的功能来做缓存和索引,其速度远远超过原本内存价格下跌之前可能达到的速度。
[空谈警报：Hasso看了我这篇博客的未删减版后，拦住我说：“David，你那个拨动开关的说法不对啊。你以为是挥舞什么魔法棒吗?HANA要复杂的多。”你们也可以看到之前的评论，网友大多对“开关”这个词很感冒。好吧，我承认，我在这里完全是在空谈。那些想要知道的更详细的网友可以关注我的下一篇博客：“行与列的故事”。]
内存中的处理方式还解决了另外一个很大的问题。在传统的SQL数据库中，你可以进行的唯一的一种操作就是SQL——对行和行内字段的操作。问题就在于，在传统的数据库中数据上进行的策略操作：比如一个数据统计功能(一个回归分析、或者更加简单的数目计算等)，有时候也会变得复杂而又困难。
然而在HANA中，商业功能(非市场营销从业人员称之为统计分析程序)是被植入进数据库的。如果你想做一个预报，你可以仅运行一个合适的数据功能。那就不像纯SQL数据库那么笨重了。而且它非常，非常的快。我亲眼看到过三个数量级的速度提升。
Exalytics： 重要的特性
我指出了HANA可以行式(对事务)也可以列式(作为一个良好的分析数据库)的特点;我也提到了HANA中植入的商业功能。提到以上内容的时候，我并不是在比较HANA和Exalytics之间关联的优点。
为什么呢?这个。。。因为在Exalytics中，你也可以在事务中心的数据库中输入数据，或是在分析数据库上的数据上运行报告。在Exalytics中，你也能有一个业务功能库。
但是完成这一切的方式大为不同。
在Exalytics中，内存中的数据库(Oracle在十余年前购买的一个旧的Times10产品)衍生出事务能力。分析能力则由Essbase(Oracle5年前购买的产品)而来。业务能力库则是R统计编程语言开放源代码的实现。
所以Oracle一定会辩称重要的特性它都有;甚至它有一个边缘，使得产品明显优于他家。如果你购买了Oracle 的Exalytics，你会得到经过测试、久经考验非常好用的数据库与功能库。因为Times10自从成立以来就成为了Salesforce.com的核心;Essbase是Hyperion的心脏，全球2000强大多数都用它;而国内每一所大学都使用R语言。
困惑了吧?这是应该的，是时候打电话给分析师了。
HANA 与 Exalytics
到底两者区别何在，区别又有什么意义呢?如果你是一个很一本正经的数据库学究，你马上就能明白了：
在HANA中，数据都存储在一块儿;在Exalytics里，数据被分开存放。
所以在HANA里，如果你想在数据上运行报告，拨动那个虚拟的开关吧;在Exalytics里，你需要从Times10数据库中抽离出数据，转换他们，然后再导入Essbase。在HANA中，如果你要运行一个数据项目并存储结果，直接照做便是;在Exalytics中，你要从，比方说是 Times10的数据库中抽出数据，将它们挤到R语言能够操作的地方，运行项目，然后再将数据挤回Times10中。
这又有什么大不了的?所以说，如果你是一个一本正经的数据库学究，你就能领悟了。(为这篇文章做研究的时候，我问了一位学究为什么这个很重要，然后他给了我一个经典的耸肩和大白眼儿。)
我想我能明白。。我猜移动数据也花时间。既然牵涉到的数据库并不能完美兼容，移动数据之前就要先将其转换。(Essbase是出了名的不处理特殊字符的，至少它不习惯这么做。)因为每个数据库中的数据都不同，时间和版本就必须卡得很准。当你在移动很大容量的数据时(比如以兆字节计数的)，你就得为空间问题担忧了。而我确定1TB Exalytics 只有 300 GB 的实际内存空间。
关于Oracle，有一件事是肯定的：他们对以上这些缺陷了如指掌。在他们的市场文化中，他们尽可能地批评了这些观点。"Exalytics," Oracle 宣称, “它的通道有无线带宽，这些通道能使数据能在数据库之间飞速地流动。Exalytics有统一管理工具，让你能对数据进行追踪。”的确，移动数据时也许会发生一些问题，但是 Oracle一直努力让你专心于“久经考验非常好用”的理论。 所以它的意思是，如果你非要在数据库之间移动数据的话，既然这些数据库这么好，这么靠谱，基础设施都这么齐全了，还怕什么呢，走你!
只要几个数据库在一个盒子里就行啦，他们会这么说，而且他们的工具更好用更可靠。
还困惑吗?只要你不是学究应该就没问题了。否则，我觉得你可能是。而且我觉得你可能会被激怒了。“这篇文章写了几百行，都没解释清楚这两样产品有什么区别!”我能听到你这么说哦。
[警告升级了：在评论中，一名Exalytics砖家说我对于客户如何使用他们产品所做的标明是错误的。如果他说对了(我觉得他是对的)，那么跟Oracle的市场营销说的完全不同的是：Exalytics与HANA在事实上根本就不可比。现在你更加应该读完这篇文章剩下的部分——关于HANA 到底是个什么。读的时候就理所当然的认为HANA是自成一派的好了。]
HANA: 设计理念
所以你认为以什么样的方式思考HANA和Exalytics，才能完全想清楚“集所有功能于一体”和“Infiniband管道连接所有东西于一个盒子”之间的区别?在我看来，正确的方式就是思考运行在两者之上的设计理念。
在这里我认为，有一个很明显的区别，在Times10或Essbase或者其他传统数据库中，设计理念是这样的：如果你想处理数据，把它移到为这种处理而设计的引擎中去。是的，会有成本。你可能需要做一些处理来得到数据，这需要一定的时间。不过这些成本是很少的，因为一旦你把数据放到容器中后，你将能进行一大堆的处理，不然你是无法做到的。
这是一个非常正常又常见的设计理念。你可以发现同样的设计理念运行于我40年前一个夏天使用的工具上，当时用来帮助一名木匠。他的工具很大，很贵又强大—例如像钻床和台锯—它们就是你工作时会带上的所有工具。所以如果你正在建造，比如厨房，你会先在现场测量，然后回到商店去买你需要的东西。
在HANA中，设计理念完全不同：不要移动数据。数据在哪就在哪完成工作。从某种意义上说，它和现代木工业的设计理念相同。如今，我老板的儿子可以一个人驾驶一辆卡车、卸载移动式台锯和用电池的电钻，在现场就可以完成所有工作，这一切都已变得更容易、更便捷、更灵活和更可靠。
那么，为什么在数据处理时携带工具到现场是更好呢(如木工)?你可以更灵活地做事，并且做的更快。
让我给你举个例子来告诉你我的意思。我以一个几年前我见过的，相对轻型的BI工具演示作为我的开始。
这个销售/演示人员是个怪人，需要经常出差。他从TSA网站上下载了所有美国机场安全门的等待时间。在演示中他说，“假如你现在在出租车上。你可以打开数据库和每个检查点的等待时间图表，所以你现在可以说出在哪个门停下。”
这个想法很赞，可视化工具也是。但是在一天结束的时候，他曾做过的事就很有限。因为系统基本上只是从数据库取出数据、使用SQL语句，你所得到的就是等待时间的列表，这点比较难处理。而你真正想要的是根据一天的时间和其他事情，得到每个门发生延时的可能性，这些信息恰恰是你无法在出租车上获得的。
可能更糟的是，他使用的不是真正的实时数据。为了达到这个目的，到目前为止，最重要的数据是最近的数据，但他没有;他甚至无法处理一个RSS提要。
现在，考虑下HANA的 更广泛的功能可以为这个例子做的事。首先，数据几乎可以不间断地导入到HANA中。即如果他有一个运行的RSS提要，他可以保证数据库一直是最新的。然后，他可以使用HANA中的商务功能对检查门的延迟时间进行分析。他可以在一个地方完成所有他想做的事，这给了他更好和更可靠的信息。
那么，是什么使它更好?
请听我慢慢道来。HANA和Exalytics之间最本质的区别是在HANA中，所有数据都放在一个地方。这是否是一个重大差异?好吧，对某些人来说是，对另一些人来说不是。作为一名分析师，我得暂时保留意见说，“我们走着瞧。”
不过，目前来看，这似乎是个重大区别。以下是原因。
当我看到一个新的设计理念时—我认为可以肯定地说，HANA代表其中一个—我想做两个测试。它是否简化了?它是否成果颇丰?
回到我当初教书时，我经常用两个故事解释这个测试：
一百年前左右，汽车没有电池或者电子系统。如今电子系统完成的事情在过去被认为完全是用另一种方式进行的，完全独立的功能。要发动汽车，你需要用手摇;要照亮车前的道路，你需要使用油灯，在现在车灯的位置。
然后出现了一个新的设计理念：电池和电线。这个想法以突出的成绩通过了这两项测试。它简化了。你可以使用同样的设备做很多不同的事(发动车，照亮道路)，以更方便和更直接的方式(从仪表盘发动车或操作车灯)。而且它的成果也很多。一旦你有了电，你就可以用相同的想法做完全不同的事情，就像启动暖风电机或者操作自动门锁。
那HANA呢?简化并卓有成效?让我们试着与Exalytics做比较。简化?诚然，同时思考行和列是一个有点令人费解的想法。但是当你想到从概念上来讲，把所有数据放在数据库中是很简单的，但考虑到把数据移动到其他地方才能执行各种操作，相较之下，它确实简化了很多。
成果颇丰?
不管你相信与否，我花费了一段时间才弄清楚这点，但是Exalytics确实帮助了我。当我开始将商业函数库与Oracle提供的“高级可视化”比较时，我顿时豁然开朗。当提到数据统计时，它们是相当的一对一;HANA开发人员很自觉地试图合并与数据库等价的标准统计功能，而Oracle则自觉地让你访问R函数库。
但是商业函数库也支持：看好了，例如固定资产折旧或按年计算之类的函数，而高级可视化不支持。
这是很重要的一点，不单单因为HANA函数库的功能比R多，而是HANA使用相同的设计理念(商业函数库)以丰富各种数据库的能力。在分析方面，他们使用统计函数以丰富分析功能;在事务方面，他们使用折旧计算以丰富事务功能。或者，他们使用同样的基本富集机制。
我认为这正是Oracle发现很难去匹配的东西。当然，他们可以写折旧计算函数，他们已经这样做好几年了。但是要将这个与Times10数据
库无缝工作，我猜测他们不得不在Exalytics中创建一个新的数据存储区，以及管理工具中的新管道和修改。
HANA会生出脚吗?
那么，当你有两个相互竞争的设计理念，其中一个比另一个更简化更有成效时，将会发生什么?
让我回到我的汽车比喻中。
把你自己放到一百年前，然后想象一些汽车制造商或其他制造商，缺少新型电子系统的汽车，于是决定使用成熟的技术，尽快生产漂亮的手工制作的汽车，可以做到新型电池汽车做到的一切，投入市场。它有清脆、黄铜油灯笼、红木曲柄，以及在杂志上面带微笑的司机站在汽车旁的广告和图片。
广告的潜台词大致如下：“为什么你想要一个全新的系统，故障点很多很多，而我们已经有了它们有的一切。看，他们有车灯，我们也有，但我们的更可靠更成熟;他们有启动装置，我们也有，但我们的更漂亮、可靠、成熟，任何司机可以操作。”
我可以看到，人们很可能会相信他们，至少一段时间。但在某些时候，每个人都明白有电子系统的才是正确的设计理念。也许它会发生在暖风电动机和室内照明灯推出下个版本的时候;也许当司机走了蹄铁匠的路时，你才会意识到它的发生。但当它发生时，你才会意识到，煤油灯和曲柄最终会倒在路旁。
关于作者
我在马萨诸塞州的剑桥市经营一家小型分析公司，提供大部分企业应用的战略咨询。我不是一个数据库专家，但在过去的一年里，我一直与SAP合作了很多与HANA相关的工作，所以我对HANA相当熟悉。我不和甲骨文合作，但是我相当了解Times10数据库和Essbase数据库，因为我多年涉及Salesforce(Times10)和Hyperion(Essbase)的内容。
