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)的内容。