SAP HANA内存计算介绍
HANA是一个软硬件结合体，提供高性能的数据查询功能，用户可以直接对大量实时业务数据进行查询和分析，而不需要对业务数据进行建模、聚合等。用户拿到的是一个装有预配置软件的设备。至于HANA的云服务，只是对用户而言可以在不购买相关硬件的情况下享受HANA的高性能，而HANA云服务的背后还是需要更高性能的硬件支撑的。
软件方面，HANA的内存数据库（SAP In-Memory Database, IMDB）是其重要组成部分，包括数据库服务器(In-Memory Database Server)、建模工具（Studio）和客户端工具（ODBO、JDBC、ODBC、SQLDBC等）。HANA的计算引擎（Computing Engine）是其核心，负责解析并处理对大量数据的各类CRUDQ操作，支持SQL和MDX语句、SAP和non-SAP数据。比较显而易见的一点是，HANA计算引擎要快速处理用户复杂的查询请求，快速返回查询结果。
SAP内存数据库的数据并不是只在内存里，也会不停写到硬盘里，这就用到复制服务器Replication Server，包括Log-based，Trigger-based和ETL-based。这些复制服务器需要用到Sybase Replication Server、Sybase Replication Server Agent、Sybase Adaptive Server Enterprise (AES，适用性服务器)等，以及HANA Load Controller和BO Data Services。
操作系统方面，HANA目前只能运行在Suse Linux 企业版（SLES）上。
硬件方面，SAP和多个硬件厂商合作生产支持HANA的高性能服务器，包括Dell R910、Fujitsu、HP DL580、IBM x3850等，以及和Cisco（Cisco Unified Computing System. UCS）等公司的合作。直观地说，这些机器的硬盘可能是数个600GB、转速10k rpm的硬盘组成RAID，内存可能有1T，文件系统可能是ext3或GPFS（IBM通用串行文件系统，General Parallel File System）。
和HANA类似，Oracle的Exadata也是一个预配置的软硬件结合体，提供高性能的数据读写操作。Exadata机器由Exadata数据库机器、Exadata数据库服务器、Exadata存储服务器以及高速网络接口等组成。InfiniBand端口的传输速度可以达到40Gb/秒。
HANA的快在于用大内存提供内存数据库，并在内存数据库里采用列式存储从而可以将更多的数据装进内存（列式存储更适合数据压缩）。
Exadata的快在于把大部分数据库操作push到硬件，通过高性能硬件提高数据查询速度，通过采用列式结构减少需要在存储和内存间移动的数据量，通过高速网络接口提供数据传输的效率。
HANA能做什么
HANA不是一个数据仓库，而是一个平台，在这个平台之上用户可以构建数据仓库或集市、报表和仪表盘等。
HANA能做的，首先是作为内存数据库，提供数据插入、修改和高效的查询功能。
其次，作为一个平台，在HANA之上，BO报表系统可以提供更好的用户体验 – 用户几乎不需要等待数据返回。
用户可以使用HANA的建模工具直接访问ECC或其它数据源，避开BW。但也可以在HANA之上建BW，把BW那些性能问题交给HANA解决。
HANA的架构
下图比较直观地展示了HANA的软件架构：
最下层是SAP ECC、BW及其它非SAP数据源，通过Data Services和Modeling Studio把数据导入HANA，通过Replication Services写到磁盘，，通过HANA计算引擎处理数据插入和查询等操作。HANA是一个平台，在这个平台之上可以是BO、BW，以及其它产品。
SAP HANA的优势
首先，我想这么开始：
(a) 对昨天完全没抓住重点的技术方法的比较
- HANA 用户非常中意无需中断的现代科技带来的惊人利益
-
HANA
代表着下一代企业级运算，这一点在数据库技术上尤为突出。它是针对实时分析和应用的现代数据平台。它能让组织实时分析大量而又冗杂的数据，同时在真正意义上实时避免延时和减少OLTP
和OLAP之间的层次交流。HANA的
优势在于它是一套紧密集成的系统，实现了不同组成部份之间的良好交互和系统整合优化。无论向上还是向外扩展，HANA对所有部份，如OLTP,OLAP(业务以及存储业务)，文字，计划和纯应用开发都能实现良好的承接。通过HANA，简易的部署不再是梦想，没有主机动物园（虚拟主机），没有内部同步，没有物化聚集，更没有一堆的引擎！
在下文分析中，我将试着简单扼要地沟通所有观点。并且我会一直更新这个博客，以期持续提供SAP HANA的真相。下面是对部份错误观点的纠正。
#1 未来的数据库设计走向
错误: “内存数据库(In-Memory DBMS) 将不会完全取代关系型数据库(relational DBMS)”.
正确: 内存数据库（In-Memory DBMS）是未来数据库设计的主流。它已经占据了绝大部分的数据库市场－尤其是在分析，计划，模拟和实时应用领域（比如游戏市场）。它的设计基于完整详尽的学术研究，支持OLAP和OLTP。内存数据库已在性能至上的需求市场广受欢迎，另外在云计算和交互式应用的影响下，企业级市场也将逐渐向内存数据库转变。
#2. 数据库平台的作用Role of the Database Platform
错误: 内存数据库（In-memory database）只能做像MOLAP, 业务报告， 查询 & 分析，计划 & 预算, 非结构化信息处理等一小部分事情。
正确: SAP HANA 是一个通用的内存数据库平台－ 带来全新的数据，捕捉符合ACID的交互，在发生时同步分析，做数据库处理，推动业务，预测和规划到数据库中的逻辑，同时还能够支持分析终端，云端和移动运用终端等各种客户端。内存数据库的运用远不止在很小范围的使用案例中所描述的那样，它拥有更多的超越想象的主流应用。你不用为了满足不同需要而在一个盒子内加入多种技术和重复的引擎， (比如，Endeca – text Essbase - planning, TimesTen - caching, analytics).
#3. 日益增长数据量的延展 & NUMA 支持
错误: SAP HANA 对数据集市和数据仓库的支持非常有限，并不能向外扩展
正确: SAP HANA 能向外扩展无限的内核／节点，并减少硬件开销。在我们去年五月召开的SAPPHIRE
NOW会议上，
不仅如此，近期在IBM16节点的 X5服务器（ 16 nodes of IBM’s X5 servers）上运行我们的100TB标准检查程序（ benchmark），每个占用主要内存的1／2TB，同时就操作报告场景能在300毫秒－500毫秒内处理100TB的BW数据； 随机分析查询（ ad-hoc analytical queries）场景下则为800毫秒－2秒。（our recent 100TB benchmark runs on 16 nodes of IBM’s X5 servers each with ½ TB of main memory and processes 100TB of BW data in 300ms-500ms for operational reporting scenarios and 800ms-2s for ad-hoc analytical queries. ）
更进一步说，类似过期标准（ aging criteria）等标准的HANA机制能置换掉相应数据。HANA支持NUMA结构。 与之相反，公开出版文献强调 Oracle Exalytics 存在1TB的限制，并且他们曾经公开表示，对他们所有放在一起的产品 (Essbase+Endeca+TimesTen)来说，这1TB在很大程度上会被用于工作所需内存。
#4: OLTP & OLAP
错误: 据传SAP HANA的“写入性能有限”。
正错: 在一套硬件和一套操作系统上，SAP HANA 对OLTP+OLAP是单一基础。它可以向上和向外扩展（通过不同的节点能从最小单位一直到1000＋的内核），并且它能动态地调整工作负载。 我们是唯一的带有列存储（columnar store）插入的高写入性能和高分析性能的内存数据库。这是SAP HANA和其他数据库的关键区别。
#5: 存储－行，列，和文本Stores – Row, Column, and Text
错误:
正确: SAP HANA 将行，列和文本存储在一个数据库里，自然会支持非结构化数据。再者这些都被集成从而简化了所有存储间的交互和分析操作。实际上，非结构化搜索是SAP HANA的基础。它能像处理标准搜索和文本挖掘一样处理结构化数据上的搜索文本。 借助 Inxight 技术，类似标记，特征提取，单位提取或者情绪分析之类的语言学特征也能被纳入SAP HANA。 Inxight是当下市面上最好的语言分析软件。
SAP HANA 支持列存储内的大数据量压缩。行存储不需要大数据量压缩，因为它仅用于列存储的缓冲和压缩无关表格。SAP HANA 的优势在于和应用程序堆栈之间的智能集成，这使得行存储压缩变得无关紧要。
#6. 数据缓存 & 查询优化
错误: SAP HANA 和 TimesTen 都有数据缓存.
正确: 过去的数据库版本会使用缓存来提升性能。 HANA 是建立在新架构典范上的纯内存数据库。考虑到所有的数据库都是在内存中，所以HANA不缓存数据。具备世界级的查询优化器，能轻易实现大规模并行查询的操作，包括运算符内部和运算符之间的并行查询（ inter and intra-operator parallelism）。
#7: ACID 属性和事务的完整性
错误: SAP HANA 没有“没有事务完整性／正确性并且在多版本并发（ lacks multi-version concurrency ） (MVCC) 上有所欠缺”。
正确: SAP HANA 完全遵照ACID，考虑到备份和持久性，我们采用永久的存储系统。它是完全多版本并发并带有类似语句级和快照隔离之类的常规功能。
#8: 聚集和物化视图
错误: 高性能需要聚集数据的物化视图
正确: 又一个 Ha! 电动车不需要火花塞。内存中处理的每一数据的实时聚集比性能里的聚集高得多。聚集已经是过时的技术了，因为它需要花太多气力去做一些根本不必要的创建，存储，同时还要管理更改。SAP HANA 并不像传统数据库一样为系能而需要索引；无论从那一种维度的数据设置来看，这内存数据库自身就是索引。
#9: 商务智能终端
错误: SAP HANA 几乎不对任何商务智能终端提供支持provides limited support to few BI clients.
正确: 经过优化，SAP Business Objects 已经能在 SAP HANA上运行。外加现在有超多可用的第三方终端(e.g. Tableau, Tibco Spotfire) ，所以在 SAP HANA 上，我们将持续对第三方商务智能终端的完全开放态度。
#10: 规划申请和分析功能
错误: SAP HANA 不支持规划和预算编制应用程序。
正确: SAP HANA 完全支持规划应用程序。许多SAP企业性能管理程序都能在SAP HANA上运行。SAP HANA在数据库中有本地规划支持 与规划引擎。在SAP HANA中，类似分列，复制等运算符都是关系代数的一部分。除此之外，我们支持SAP 数据库内自带的规划语言FOX。
规划，而不是其他方式，对 SAP HANA 来说是一个超级大的参数（huge argument）。因为采用即时运算的缘故，SAP HANA 不需要标准多维操作（standard cube operations）。 SAP HANA 的库不仅涵盖了主要的分析和业务功能，例如汇率转换，单位换算，异动加权（ exceptional aggregation），时序分析，层次处理和预测功能，还扩展支持其他库。在HANA上的SAP BW 是不需要层的；我们将规划计算（ planning calculations）推下至HANA的数据库，提供更高的性能。SAP HANA 将支持所有的交互应用，企业仓库，BI和所有的云应用。我们也有第三方合作伙伴开发内置SAP HANA的规划软件。
#11. 操作报告 & 数据源
错误: 由于“受数据类型限制”，SAP在同步和ETL技术方面的操作报告能力有限
正确: SAP 有一套超赞的应对多源实时操作报告的解决方案（例如 SAP CO-PA Accelerator）；它们中许多是非SAP应用数据类型。SAP数据服务（ SAP Data Services）和 SAP Sybase 同步服务器（ Replication server）有市场领先的 ETL & 同步技术，能传导非SAP和SAP的数据类型。由于巨量平行架构（ massive parallelism），HANA 有非常高的批量行插入率（ bulk inserts）。实验结果显示，它不仅支持所有数据类型，传输率还能达到每小时2TB以上。
#12. 价格
错误: “SAP HANA 比Exalytics贵5－50X。” 1 TB HANA 硬件大概要支出 $362K, 另外SAP HANA 软件需要支出$3.75 M.
正确: 如果是1 TB，我们预期的硬件开销在 $40-$60K (不是$362K) 软件更不可能有吹的那么贵。当然，SAP HANA在不同市场有不同价位。
从HANA自身来看，范围从合理价位的小业务（例如$12K单节点硬件＋ $2K HANA和在HANA上运行的 SAP B1 Analytics）到非常大的，可能需要超过100TB内存的业务场景。客户不仅能针对某一应用（ BW, BPC, CO-PA, Smart Meter Analytics, etc.），也能针对数据集市和数据仓库购买HANA。 对40 TB 的数据仓库，BW 在 HANA上是非常有竞争优势的。同时，HANA的售价另含了顾客需要的一切－测试，开发和质检环境（ QA environments）和支持。 因此也不需要多一笔开支在购买数据上载，迁移，存储加速等软件 (比如Exadata) 上。综合上述因素，拿512 GB使用配置随便举例， SAP HANA比同类竞争产品节约近一半的总成本。
#13: 标准和开放性
错误: “HANA 只适应SAP的工具，仅具有限或非标准SQL”.
正确: 相当大一部分客户使用HANA处理非SAP数据和相关用例－SAP和非SAP应用用例都可以。HANA在标准 SQL 和 MDX上运行，对所有程序采取标准统一界面。在每一层上它都是开放的：
- 供应商硬件层面的可选开放：他们能自主决定是否在竞争对手前对市场采用新一代芯片的创新（Open choice on H/W vendor of your choice bringing new chip level innovations to market ahead of competition）
- BI 客户端的可选开放（Open choice of BI clients）
- 对所有平台和应用开放
-
有许多在 SAP HANA下开发的自定义（非SAP） 应用程序
举例来说， Oracle 应用和 Oracle BI 都能在SAP HANA上运行良好，没有任何异常。 Oracle 内现存的程序因IP的因素被翻译成SQL文本，这一点很好体现了SAP HANA的开放性。
#14: SAP HANA 在磁盘上的表现（on disk）
错误: SAP HANA 不支持存储在磁盘上的数据。
正确: SAP HANA 通过类似最近访问过的数据（ Least Recently Used (LRU)）一类的优先级技术支持磁盘存储数据。 SAP HANA 能将相关数据保存在内存中，另外磁盘中的数据能根据需求进行上载。
#15: 查询速度
错误: SAP HANA 在查询执行上不会比其他数据库更快。
正确: SAP HANA 将所有数据以整体形式存储在列中。另外还采取了 发展中的向量运算处理器（CPU developments in vector operations）这类英特尔最新的优势技术进行了优化。SAP HANA的前瞻性架构（ next-generation architecture）和芯片级创新（ chip level innovations）使它远远超越了市场上的任何竞争对手。打给比方，我们有四位客户经历了SAP HANA 在100,000X业务流程速度上的改善。MKI是其中的佼佼者， 显示出408,000X在零售／物流数据分析的改进。（For example we have 4 customers who have crossed 100,000X improvement on the speed of business process with SAP HANA. The leader in the pack is MKI, showing a 408,000X improvement on retail/logistics data analysis.）
#16: SAP HANA 比 Exadata & Exalytics慢
错误: “SAP HANA 连 Exadata的速度都及不上，更不用说 Exalytics”.
正确: 某客户的基础架构上曾出现过这么一个例子，对信用检查和信用额度核查的业务流程，同样的数据，同样的查询方式， SAP HANA 比 Oracle Exadata 快 15,000X 。这种实时性能是和有其固有架构导致内在延迟的多种冗余箱在交互性，分析性，内存加速和文字处理上进行的比较（ Compare this real-time performance to multiple redundant boxes for transactional, analytical, in-memory acceleration and text processing that have inherent latency in their architecture. ）我们在不止一位客户身上发现了这种情况，这里只是举这个作为例子。
现在市面上的主流方式示意图
SAP HANA所采用的新方式示意图
#17: 安装和实施体验
错误: 安装SAP HANA需要好多天，实施则需要数月甚至数年
正确: 在一个数据中心中只要几分钟，最多一个小时就能装好SAP HANA。实际上很快你就可以从我们或我们合作伙伴的云中安装。Provimi 盈利分析3个星期就gone live。
#18: 考勤－差旅（Time-travel ）
错误: 如果没有明显开销，数据库很难展现基于时间的报表。
正确: 借助 SAP HANA，你能做时间报表遍历（ you can do time traversal on your reports ）（例如比较每日实际和预测时间）compare actual vs. predicted by day) 。另外，举个例子，能用滑块来阅览时间轴和实时生成的报告，而不需要另存指标或视图。
总结
我陈述了事实并需要你相信 SAP HANA的真相。 SAP HANA的性能是对传统数据库市场的挑战。它对 OLTP+OLAP 是单一基础，只需一台硬件设备和一套操作系统。 小至mac-mini，大至1000+ 内核的服务群它都能运行。HANA的技术规范，交融了我们真正在意的各种特性：
- 爆炸式的数据量 （是的, 和你一起成长，和磁盘存储一起工作）
- 多结构数据 （是的，包括文本和机器数据）
- 新录入数据的即时分析 (yes, real, real-time)
- 高速交互 （是的，以人脑思维的速度）
-
没必要再协调数据库 （是的，更简单和更便宜）
这些提出的是在性能上大幅改进的命令。 SAP HANA 通过革命化客户互动，财务和供应链性能，为公司创建了巨大的商机和竞争优势。农夫山泉正在关掉 Oracle（ 22k在 Oracle DB的改进）。
我们也在制定新的领域，比如在医疗保健中进行革命性的基因组分析，或在全球实践实时商务银行交易，或者是我们这个时代其他重大的挑战。时代需要我们进入这些新的领域，不要固步自封，而要创建那些我们也许能将其变成现实的美丽可能。时光短暂，生命怎可被流言耽误。
