SAP 的云端战略与常驻内存运算装置共同发展

在最近举行的 SAP SAPPHIRE 2011 大会上，SAP 发布了高性能分析装置（HANA）软件，将运行在与Dell 和Intel 合作的云平台上。这种伙伴关系可以让SAP 的用户把他们的SAP 应用部署到Dell 的虚拟集成系统（VIS）数据中心平台。 SAP 的CTO 和执行理事会成员Vishal Sakka 也描绘了未来的HANA 应用云的预想： 将让用户能够访问SAP 的Business Intelligence OnDemand，Carbon Impact 和Sales & Operations Planning 以及其他的应用。除了迁移他们自己的应用， SAP 还会在HANA 上认证第三方的应用。

去年一年中，自从 HANA 在 SAP Sappire 2010 首次发布后，它就占据了 SAP 的战略路线图的首要位置。 据猜测 SAP 的在内存常驻运算方面的作为是对 Oracle 的 Exadata 产品的响应，因为多数的 SAP 的用户使用的是 Oracle 数据库，并且会把 Oracle 的 Exadata 视为一个走向下一代数据处理平台的步骤。和只能运行在 Oracle 产品线上的 Exadata 不同，HANA 装置获得了厂商的广泛支持，包括 IBM、富士通、Dell、思科以及惠普都会销售这款产品。

根据 ZDNet 的 Dennis Howlett 的说法， SAP 投资把 HANA 结合到云端是出于更加充分的理由：

这不是简单的收入问题，SAP 已经做出过统计，显示存储是运行他们的系统最大的成本，远远超出了运行 SAP 应用服务器的成本。 运行测试系统比实际系统更加昂贵， 而运行在云端则可以大大消减总拥有成本。

从技术角度来说，IBM 的 SAP 顾问和优秀的 SAP 博客作者 Vijay VijayaShankar 提出几点疑问：

HANA 云端版的大问题是“你要怎么执行 ETL， 它会是实时的吗？”。细节还有待披露——但我特别担心的一个用例是云端的 Sales and Operations Palnning 模块，一般来说这是个 ETL 集中的活动，就算是对常驻内存的解决方案来说速度也是一个可预见的问题。再加上访问云端的带宽问题和安全性与基础数据私密性的担心，我总体觉得 S&OP 对多数用户来说更适合自主维护而不是按需使用。也许有那么几家不需要那么大的数据量等等的可以这样用——但还是难以想象这个会在 SAP 的大商店里受到欢迎。对于在近期内把 HANA 放到云端我还有一个关心的问题就是 SAP 对应基础设施规模的能力。HANA 还没有实际应用足够长的时间来获取关于规模的有效信息，SAP 很有可能会低估或高估提供 HANA 服务所需的规模。 显然哪种情况的结果都很糟糕。

HANA 应用了常驻内存、数据源无关的计算引擎， 要处理的数据存放在 RAM 中，而不是从二级存储设备中获取，这样提供了性能的提升。这个平台还提供了建模工作环境， 简单到业务用户也可以使用。根据与 IBM 合作，由 WinterCorp 审计的第一个官方的比较测试，HANA 可以轻松地处理对 1.3TB 数据每小时 10，000 次查询，并在数秒内得到结果。这个测试在 IBM x3850 X5 服务器上实施，其装载了 32 核、0.5TB 内存，以及一个 RAID 5 的磁盘系统，该磁盘系统结合 SAP HANA 软件可以处理最大 1.3TB 的数据，因为 SAP HANA 压缩数据并按列存储。HANA 以线性方式升级，也就是说如果你需要更多的内核或内存，按 SAP 说法你只需要增加更多的节点。
Vijay VijayaShankar 分享了关于 HANA 受到好评的实时性能的一些评论。

我认为说 HANA 存在严重的问题 ，更适当的词应该是“ 正确时机”（Right Time），就像 Ray Wang 在 twitter 上指出的——至少在现在，在 HANA 成为 ECC 和其他产品的支撑骨架之前。问题在于“用户会有实时的体验吗？”。多数用户不会坐在机房 HANA 机箱的旁边——他们会在广域网、VPN 连接之类上面。事实是 SAP 不辞辛苦把 HANA 系统从实验室弄到展示厅，而不是远程连接过去，这让我知道 HANA 没法给使用者实时体验。

还有压缩能力：

我从头到尾读过 Hasso 的书的 PDF 版，也在推特上说过我对它有些失望。其中一个就是 HANA 的压缩问题。就算是在宣讲会上，它也给人一个印象，好像用户可以看到 10 倍的数据压缩。我觉得这很难让人相信，因为 DB2、ORACLE 这些产品都在压缩数据方面做的很好。所以如果 DB2 只能压缩数据到 5 倍，HANA 能再把它压缩 10 倍吗？Hasso 跟我解释说他指的是平均可以压缩原始数据 10 倍，而不是已经压缩过的数据。但要知道，用户“看到”的是已经压缩过的数据，会用 HANA 的结果与之相比。还有，在宣讲会上提过，数据库不能根据这个压缩比来衡量大小—— 由于技术原因它还需要额外的空间。

Vijay VijayaShankar 在 PCWorld 的访谈中分享了 HANA 体系结构的一些细节：

HANA 构建在 SAP 具有悠久历史的技术的超集上，包括 MaxDB 数据库和 TREX 常驻内存引擎。根据一份 SAP 文档，HANA 放在内存中的数据由一个记录事务并具有能创建数据库映像的保存点的持久化层提供支持，这让它能够从停电或其它的中断中恢复。 HANA 与支持常用查询语言如 SQL 和 MDX 的 BI（业务智能）应用兼容。

查看英文原文： SAP’s Cloud Strategy Evolves With In-Memory Computing Appliance