Skip to Content

原文链接:http://www.saphana.com/community/blogs/blog/2012/05/06/hana-vs-exalytics-an-analysts-view

引言:

SAP邀请了我从分析师的角度,来评论一下“HANAExalytics”之间存在的争论。这个比较很有趣,所以我也欣然从命。这篇文章会让你们了解我对它们的看法。你们会看到,我不会把两者分得很清晰(而不看到文章最后,我和SAP之间关系也不会完全披露)。

Exalytics

首先,来说说每个分析师都知道的事吧:Oracle生产了好些我们在零售业中称为山寨货的产品。

他们认为这是一个好行当,我觉得这也没错。这个模式很简单。当有人创造了一个产品,并证明了市场,Oracle(或者拿SAP打比方也无妨)就会开发出一个类似的产品。所以,一有 VMWare (或其他厂商) Vsphere,就出现了OracleOracle VMRed Hat建立了一个围绕Linux的商业模式, Oracle 就创建了 Oracle Linux –坚不可摧的商业核心”。

分析师们也深谙此道,并从此获利不菲。那些山寨产品——说得好听点就是“Oracle的紧跟潮流的产品”——在性能上与它们的效仿对象都能兼容。但在某些方面,或者某些边缘,Oracle声称自己的产品更胜一筹。

这些话让听到的人很困惑。他们一困惑,就会打电话给我们。作为一名分析师,我接到的这样的电话也不在少数,我也仔仔细细地研究过Oracle的一些产品。一直以来,我都认为Oracle能提供的产品,与你能在Pennys或者Target上看到的差不多,它们对于付不起或者不想付溢价的人来说是合适的替代品。这些人往往会限制自己的供应商数目,对产品也没什么太高的期望。

我这么想,是因为你对当今的市场只能抱有这种观感。毕竟就像在下雨前你匆忙从路边摊买到的一把伞一样,你会觉得这真好,因为它可以遮雨。但是你也不会指望这把伞能耐用到陪你走过多年的风风雨雨。

软件当然比一把伞更复杂。软件行业并不十分透明化,有时候要分辨出各种声明背后真实的含义是件很困难的事。你要一直、一直往下挖得很深——就像有时候我的客户会指责我——“挖到了杂草的根部”,这时候也许你就能得到真相,但是也会失去一部分说服力。

这一点让我想到了现在这个争论。这对我来说又是个熟悉的循环。SAP创造了HANA, Oracle紧接着生产了Exalytics,两者都是储存在内存中的数据库应用。于是我又接到了很多的电话。

HANA 重要的特性

我会带你们过一遍两者的区别,与此同时希望我不要“挖到杂草根部”。在这个过程中我会引入一些比喻,如果你们觉得我说的没有说服力,请不要客气马上联系我。

   

要进行说明的话,我就要避开那些像是“内存中”或是“分析”的术语。鉴于SAPOracle现在正在用同样的词语,我们要关注的是“内存中”或是“分析”等术语要解决的更深层的问题。

而这些问题其实并不单一。问题1:传统的行式数据库能很好地存储数据,但在输出上则欠缺了一点。问题2,为了解决 问题1而诞生的众多“分析数据库”——包括但不限于SAP在使用的列式数据库——性能刚好相反。

我们需要的,往往是一个能很好地存储数据的列式数据库,或是一个能很好地输出数据的行式数据库。

HANA处理这个问题的方式就十分有意思。在它们的数据库中,你可以选择处理数据的方式:要么行式要么列式。(如果你想的话,你可以在脑中模拟出一个控制切换的开关。)所以,如果你需要优化只读,然后让列式数据库达到其设计目的——一份快速灵活的分析报告的话,你可以拨动开关,告诉HANA:“我要运行报告。”如果需要优化写入,使行式数据库达成所愿——完成事务行为,你可以拨动开关,告诉HANA:“我正在进入一个事务。”

其实数据都是一样的,拨动开关决定的只是你的访问模式。

我以前的同行、现在的一名SAP主管Adam Their曾经向我解释道:“其实这是一个反分析的数据库。”(这应该不是SAP的官方说法,但是我很能理解。)他们是怎么让数据库“反分析”的呢?这个时候就要快速钻入杂草底部了。他们使用在内存中的功能来做缓存和索引,其速度远远超过原本内存价格下跌之前可能达到的速度。

[空谈警报:Hasso看了我这篇博客的未删减版后,拦住我说:“David,你那个拨动开关的说法不对啊。你以为是挥舞什么魔法棒吗?HANA要复杂的多。”你们也可以看到之前的评论,网友大多对“开关”这个词很感冒。好吧,我承认,我在这里完全是在空谈。那些想要知道的更详细的网友可以关注我的下一篇博客:“行与列的故事”。]

内存中的处理方式还解决了另外一个很大的问题。在传统的SQL数据库中,你可以进行的唯一的一种操作就是SQL——对行和行内字段的操作。问题就在于,在传统的数据库中数据上进行的策略操作:比如一个数据统计功能(一个回归分析、或者更加简单的数目计算等),有时候也会变得复杂而又困难。

然而在HANA中,商业功能(非市场营销从业人员称之为统计分析程序)是被植入进数据库的。如果你想做一个预报,你可以仅运行一个合适的数据功能。那就不像纯SQL数据库那么笨重了。而且它非常,非常的快。我亲眼看到过三个数量级的速度提升。

Exalytics 重要的特性

我指出了HANA可以行式(对事务)也可以列式(作为一个良好的分析数据库)的特点;我也提到了HANA中植入的商业功能。提到以上内容的时候,我并不是在比较HANAExalytics之间关联的优点。

为什么呢?这个。。。因为在Exalytics中,你也可以在事务中心的数据库中输入数据,或是在分析数据库上的数据上运行报告。在Exalytics中,你也能有一个业务功能库。

但是完成这一切的方式大为不同。

Exalytics中,内存中的数据库(Oracle在十余年前购买的一个旧的Times10产品)衍生出事务能力。分析能力则由EssbaseOracle5年前购买的产品)而来。业务能力库则是R统计编程语言开放源代码的实现。

所以Oracle一定会辩称重要的特性它都有;甚至它有一个边缘,使得产品明显优于他家。如果你购买了Oracle Exalytics,你会得到经过测试、久经考验非常好用的数据库与功能库。因为Times10自从成立以来就成为了Salesforce.com的核心;EssbaseHyperion的心脏,全球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的市场营销说的完全不同的是:ExalyticsHANA在事实上根本就不可比。现在你更加应该读完这篇文章剩下的部分——关于HANA到底是个什么。读的时候就理所当然的认为HANA是自成一派的好了。]

HANA: 设计理念

所以你认为以什么样的方式思考HANAExalytics,才能完全想清楚“集所有功能于一体”和“Infiniband管道连接所有东西于一个盒子”之间的区别?在我看来,正确的方式就是思考运行在两者之上的设计理念。

在这里我认为,有一个很明显的区别,在Times10Essbase或者其他传统数据库中,设计理念是这样的:如果你想处理数据,把它移到为这种处理而设计的引擎中去。是的,会有成本。你可能需要做一些处理来得到数据,这需要一定的时间。不过这些成本是很少的,因为一旦你把数据放到容器中后,你将能进行一大堆的处理,不然你是无法做到的。

这是一个非常正常又常见的设计理念。你可以发现同样的设计理念运行于我40年前一个夏天使用的工具上,当时用来帮助一名木匠。他的工具很大,很贵又强大例如像钻床和台锯它们就是你工作时会带上的所有工具。所以如果你正在建造,比如厨房,你会先在现场测量,然后回到商店去买你需要的东西。

HANA中,设计理念完全不同:不要移动数据。数据在哪就在哪完成工作。从某种意义上说,它和现代木工业的设计理念相同。如今,我老板的儿子可以一个人驾驶一辆卡车、卸载移动式台锯和用电池的电钻,在现场就可以完成所有工作,这一切都已变得更容易、更便捷、更灵活和更可靠。

那么,为什么在数据处理时携带工具到现场是更好呢(如木工)?你可以更灵活地做事,并且做的更快。

让我给你举个例子来告诉你我的意思。我以一个几年前我见过的,相对轻型的BI工具演示作为我的开始。

这个销售/演示人员是个怪人,需要经常出差。他从TSA网站上下载了所有美国机场安全门的等待时间。在演示中他说,“假如你现在在出租车上。你可以打开数据库和每个检查点的等待时间图表,所以你现在可以说出在哪个门停下。”

这个想法很赞,可视化工具也是。但是在一天结束的时候,他曾做过的事就很有限。因为系统基本上只是从数据库取出数据、使用SQL语句,你所得到的就是等待时间的列表,这点比较难处理。而你真正想要的是根据一天的时间和其他事情,得到每个门发生延时的可能性,这些信息恰恰是你无法在出租车上获得的。

可能更糟的是,他使用的不是真正的实时数据。为了达到这个目的,到目前为止,最重要的数据是最近的数据,但他没有;他甚至无法处理一个RSS提要。

现在,考虑下HANA 更广泛的功能可以为这个例子做的事。首先,数据几乎可以不间断地导入到HANA中。即如果他有一个运行的RSS提要,他可以保证数据库一直是最新的。然后,他可以使用HANA中的商务功能对检查门的延迟时间进行分析。他可以在一个地方完成所有他想做的事,这给了他更好和更可靠的信息。

那么,是什么使它更好?

请听我慢慢道来。HANAExalytics之间最本质的区别是在HANA中,所有数据都放在一个地方。这是否是一个重大差异?好吧,对某些人来说是,对另一些人来说不是。作为一名分析师,我得暂时保留意见说,“我们走着瞧。”

不过,目前来看,这似乎是个重大区别。以下是原因。

当我看到一个新的设计理念时我认为可以肯定地说,HANA代表其中一个我想做两个测试。它是否简化了?它是否成果颇丰?

回到我当初教书时,我经常用两个故事解释这个测试:

一百年前左右,汽车没有电池或者电子系统。如今电子系统完成的事情在过去被认为完全是用另一种方式进行的,完全独立的功能。要发动汽车,你需要用手摇;要照亮车前的道路,你需要使用油灯,在现在车灯的位置。

然后出现了一个新的设计理念:电池和电线。这个想法以突出的成绩通过了这两项测试。它简化了。你可以使用同样的设备做很多不同的事(发动车,照亮道路),以更方便和更直接的方式(从仪表盘发动车或操作车灯)。而且它的成果也很多。一旦你有了电,你就可以用相同的想法做完全不同的事情,就像启动暖风电机或者操作自动门锁。

HANA呢?简化并卓有成效?让我们试着与Exalytics做比较。简化?诚然,同时思考行和列是一个有点令人费解的想法。但是当你想到从概念上来讲,把所有数据放在数据库中是很简单的,但考虑到把数据移动到其他地方才能执行各种操作,相较之下,它确实简化了很多。

成果颇丰?

不管你相信与否,我花费了一段时间才弄清楚这点,但是Exalytics确实帮助了我。当我开始将商业函数库与Oracle提供的“高级可视化”比较时,我顿时豁然开朗。当提到数据统计时,它们是相当的一对一;HANA开发人员很自觉地试图合并与数据库等价的标准统计功能,而Oracle则自觉地让你访问R函数库。

但是商业函数库也支持:看好了,例如固定资产折旧或按年计算之类的函数,而高级可视化不支持。

这是很重要的一点,不单单因为HANA函数库的功能比R多,而是HANA使用相同的设计理念(商业函数库)以丰富各种数据库的能力。在分析方面,他们使用统计函数以丰富分析功能;在事务方面,他们使用折旧计算以丰富事务功能。或者,他们使用同样的基本富集机制。

我认为这正是Oracle发现很难去匹配的东西。当然,他们可以写折旧计算函数,他们已经这样做好几年了。但是要将这个与Times10数据

库无缝工作,我猜测他们不得不在Exalytics中创建一个新的数据存储区,以及管理工具中的新管道和修改。

HANA会生出脚吗?

那么,当你有两个相互竞争的设计理念,其中一个比另一个更简化更有成效时,将会发生什么?

让我回到我的汽车比喻中。

把你自己放到一百年前,然后想象一些汽车制造商或其他制造商,缺少新型电子系统的汽车,于是决定使用成熟的技术,尽快生产漂亮的手工制作的汽车,可以做到新型电池汽车做到的一切,投入市场。它有清脆、黄铜油灯笼、红木曲柄,以及在杂志上面带微笑的司机站在汽车旁的广告和图片。

广告的潜台词大致如下:“为什么你想要一个全新的系统,故障点很多很多,而我们已经有了它们有的一切。看,他们有车灯,我们也有,但我们的更可靠更成熟;他们有启动装置,我们也有,但我们的更漂亮、可靠、成熟,任何司机可以操作。”

我可以看到,人们很可能会相信他们,至少一段时间。但在某些时候,每个人都明白有电子系统的才是正确的设计理念。也许它会发生在暖风电动机和室内照明灯推出下个版本的时候;也许当司机走了蹄铁匠的路时,你才会意识到它的发生。但当它发生时,你才会意识到,煤油灯和曲柄最终会倒在路旁。

关于作者

我在马萨诸塞州的剑桥市经营一家小型分析公司,提供大部分企业应用的战略咨询。我不是一个数据库专家,但在过去的一年里,我一直与SAP合作了很多与HANA相关的工作,所以我对HANA相当熟悉。我不和甲骨文合作,但是我相当了解Times10数据库和Essbase数据库,因为我多年涉及SalesforceTimes10)和HyperionEssbase)的内容。

SAP是我们其中一个客户,但他们并没有委托编辑本文,他们也不以任何方式编辑或提供编辑。

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply