Embed Size (px)
Citation preview
第 3 章
SAP HANA 架构介绍
前面我们已经介绍了有关 SAP HANA 的技术点和创新架构，相信读者在读完前面的两章
之后，已经对 SAP HANA 有了很多的了解，本章将详细介绍 SAP HANA 软件本身的架构，
以及其中各个组件的作用和彼此之间的关系。
此外，在本章中我们会为读者介绍 SAP HANA 及其外围系统之间的关系，SAP HANA在单节点架构中重要的服务组件，这些服务组件各自在运行中所起的作用，以及分布式架构
的实现机制。本章还会介绍 SAP HANA 的技术路线图，以及 SAP HANA 与其他类似的数据
处理应用设备的特性对比，其中包含 Oracle、IBM、Teradata 等厂商的产品。
3.1 SAP HANA 及相关外围系统
这里所描述的 SAP HANA 架构，如图 3-1 所示，其实是 SAP HANA 一体化设备及其外
围软件环境的整体架构，以及这些组件之间的关联关系。
（1）SAP HANA 工作台
对于现在看到的 SAP HANA 工作台，用户可以使用这个工作台进行 HANA 建模、系统
日常管理和监控等操作。这个客户端软件将应用开发和系统管理集成在一起，所以用户在使
用的时候只需要切换到不同的视图即可。在 HANA 当前的产品研发计划中，SAP 也将为用
户提供更多选择，与更多市场现有的软件进行集成，比如在 SAP Sybase Power Designer 中进
行 HANA 业务建模，并且支持第三方的监控和备份工具软件等。
（2）数据展现和访问接口
存在于 SAP HANA 系统中的信息，用户可以根据不同的目标群体，使用不同的方式进行
展现。HANA 的展示层之所以提供如此丰富的工具，一方面是为了满足客户在技术平台的需
求，另一方面是为了针对不同的用户群体提供最简单、最直观的数据浏览界面。无论用户使
用哪几种工具来显示 HANA 的数据，均可以通过同一个访问点（虚拟视图、HANA 模型）来
访问所需数据。图 3-2 是 SAP BI 提供的展现工具及其适用人群。
3.1 SAP HANA及相关外围系统 ◆ 53
仪表盘
2
3
4
4SAP
2
1
Web-I Explorer 水晶报表 VI
JDBC PythonODBC R
C + +MDX
HANA 工作台
系统管理 / 监控 HANA 建模数据加载
DXCSAP LT
Data Services
其他的数据源或系统
SAP BW
MS SQL
其他DB...
Oracle/DB2
商务套件ERP/CRM..
应用RDBMS Data Volumes Log Volumes
磁盘存储层
持久存储层
权限管理
认证管理
认证
会话管理
事务管理
元数据管理
SAP HANA 内存计算引擎
请求处理 / 执行控制
Relational Engines
SQL Parser MDXSQL Script Calc Engine
行存储 列存储
Page Management Logger
SAP BI 4.0
图 3-1 SAP HANA 和外围系统（OLAP 方式）
专业趋向
管理 / 运营
普通用户
业务分析
技术趋向
搜索、浏览 企业级报表交互式、特定分析仪表盘方式、简明可视化的展现方式
水晶报表
展示
CrystalReport
DashboardDesign仪表盘
方式WebIntelligence
交互式
分析
BOExplorer数据
浏览器
图 3-2 SAP BI 提供的展现工具及其适用人群
作为 SAP HANA 认证的 BI 工具之一，SAP BI 提供了丰富的数据分析工具和方法，帮助
企业用户从 HANA 的海量数据中实时挖掘出支持企业运营和决策的信息。SAP BI 之所以提
供了不同的工具来展现这些数据，是因为这些信息所面向的人群不同，例如针对企业的管理
层，使用 Dashboard 方式展现企业的经营状态报表，而针对于高级的业务分析师，可以使用
Explorer 或 Web Intelligence 来展现报表。如果用户不考虑使用 SAP BI 作为 HANA 的最终数
54 ◆ 第3章 SAP HANA架构介绍
据展现形式，也可以考虑使用自开发的方式来访问这些数据，通过使用 HANA 提供的标准接
口就可以进行操作。
除了 SAP BI 这一商务智能软件以外，用户也可以基于 HANA 提供的标准数据接口开发
应用程序。例如，在 Windows 平台，基于 ODBC 接口开发 .NET 应用，基于 JDBC 接口开发
Java 应用等。
（3）数据加载
将数据抽取到 SAP HANA 中是非常容易的，在 HANA 环境下提供了众多的 ETL 工具，
例如使用 SLT 可以实现数据的实时同步抽取。而使用 Data Services 组件可以根据业务需
求，定时周期性地从多个数据源抽取最新的业务数据，并将其填充至 HANA 内存中。Data Services 支持超过 100 种的数据源类型（如 Oracle、MS SQL Server、SAP ERP、文本文件等），
可以对这些抽取过来的数据进行清洗和转换。
还可以利用 DXC（Direct Extractor Connection）方式直接抽取 SAP 系统中的标准数据源，
用户无须直接一一寻找业务数据所在的数据库表。
（4）对数据源的支持
从图 3-1 的架构图中可以看到，SAP HANA 支持所有的主流系统的数据源。对于 SAP 系
统而言，可以使用 SLT（SAP Landscape Transformation）和 Data Services，以及 DXC 的方式
进行数据复制。对于非 SAP 系统的数据源，同样也可以使用 Data Services 和 SLT 进行数据
的抽取。
如果数据源是普通的 CSV 文件，可以使用 HANA 的工作台，或者使用 IMPORT 命令直
接上传这些数据到 HANA 中，然后在 HANA 的建模工具中直接预览这些上传到 HANA 中的
数据。
3.1.1 SAP HANA 系统
SAP HANA 系统由 6 个主服务组件构成，如图 3-3 所示。在这些服务中，最常见服务组
件应该是 Index Server（索引服务器），其中包含了数据的实际存储和处理数据的引擎等几个
重要部分。
在 SAP HANA Studio → Landscape 标签页中，用户能看到当前 HANA 系统所有运行的
服务进程。从图 3-4 中我们能看见有很多个服务正处于运行状态，同时也可以看到每个服务
所占用的系统资源等信息。
在图 3-4 所示的 SAP HANA 服务组件中，Name Server 相当于整个 HANA 数据库系统环
境中的“通信员”，通过 Name Server 可以知道当前 HANA 服务器的部署情况。例如，在分
布式的 HANA 环境下有多个 HANA 服务器节点，而 Name Server 知道当前哪个节点运行正
常，以及哪些数据分布在哪些节点上。XS Server 可以将持久层的数据模型封装成 HTTP 的方
式供外部使用，而且它还具有对这些发布出去的服务进行搜索的功能，并且内置一个应用服
务器。
3.1 SAP HANA及相关外围系统 ◆ 55
应用程序客户端
应用程序客户端
R RSQLMDX
HTTPRESTHTML
Index Server Pre-processor Server
StatisticsServer
XSServer
NameServer
SQL
R
SAP HANAStudio
SAP HANA 数据库管理系统
图 3-3 SAP HANA 数据库组件
图 3-4 SAP HANA 服务组件一览
Statistics Server 负责收集所有数据库组件运行的状态、执行效率和资源的消耗状态，还
监控 HANA Studio 的访问，并且返回不同的提示信息给登录的用户。SAP HANA 数据库底层
是使用 C++ 开发的，目前的版本是运行在 SUSE Linux 操作系统之上，如果在服务器端看到
这些进程，我们至少应该大致清楚这些服务是做什么的。下面简单列举几个：
Hdbnameserver：Name Server（名字服务器）。 ❏
Hdbindexserver：Index Server（索引服务器）。 ❏
Hdbstatisticsserver：Statistics Server （统计分析服务器）。 ❏
Hdbpreprocessor：Pre-processor Server （预处理器服务器）。 ❏
Hdbxsengine：XS Engine （ XS 引擎或 XS Server）。 ❏
Hdbdaemon：以正确的顺序开始或停止其他进程。 ❏
Index Server 是 HANA 最核心的组件，承担着内存管理、事务管理、元数据管理器及权
限认证、多版本并发控制（MVCC）等众多的管理工作。篇幅所限，本书不会对上述服务组
56 ◆ 第3章 SAP HANA架构介绍
件一一详细介绍。下面将以 Index Server 组件为例来介绍其详细的功能单元。
3.1.2 Index Server通过前面的学习，相信读者已经了解了 HANA 数据库中的一些服务组件，现在就开始介
绍 Index Server。由于 Index Server 中包含太多的应用服务组件，因此这里仅对一些重要的组
件进行简要介绍。
如图 3-5 所示，从上往下看，对于外部应用客户端来说，系统每次接收到的用户请求都
会在连接和会话管理中得到处理，连接和会话管理会帮忙建立一个用户会话和数据库连接，
然后客户端的软件就可以使用 SQL 语句与 SAP HANA 的数据库进行通信。例如，MS-Excel通过使用 ODBO 进行数据源连接，使用 MDX 接口和 SAP HANA 的数据库进行通信。
验证
数据库客户端（应用服务器、分析性技术等）
R
RR
R
R
R
R
连接和会话管理 会话参数
资源库
事务管理
对象存储
临时结果
权限管理
元数据管理
持久管理层
数据卷 磁盘存储 日志卷SAP HANAIndex Server
关系型存储
行存储
行存储
磁盘存储
SQL 处理器
存储过程处理
器
计划引擎
MDX引擎
计算引擎
请求处理和执行控制
DB 页管理 日志记录
图 3-5 Index Server 的架构和组件间的相互关联关系
因为 Index Server 中这些功能组件都是相互作用的，所以下面会按照彼此的关联关系对
Index Server 里面的这些组件做简要介绍。
3.1 SAP HANA及相关外围系统 ◆ 57
（1）请求接受、连接会话的处理
SQL 语句的每次执行过程都是一个事务处理的过程，会话管理组件会向新发起的用户
会话分配一个新的事务，然后由事务管理组件专门用来协调用户会话所对应的这个事务，
控制事务的独立性，保持事务执行的可追溯性和关闭事务。例如，在一个数据库事务发起
Commit 或 Roll-back 的时候，事务管理会通知计算引擎去执行所需的动作和事件。
当前端应用软件（例如 BI 4.0 的各种报表工具）发起一个请求去访问 HANA 中的数据
时，这个请求会先经过会话管理，然而最终负责分析这个请求的是请求处理和执行控制组
件，这个组件包含了很多子功能，例如解析 SQL 的语法和执行命令。
（2）请求处理和执行控制
一般来说，数据操作类型的执行都是由 SQL 处理器组件自行完成，而其他类型的请求被
分配到其他的组件中。例如，数据类型定义的 SQL 申明会被分配给元数据管理组件来进行处
理，事务控制类型的请求就会被分配给“事务管理”组件来处理，计划命令的处理则由计划
引擎来处理，对存储过程的解析和执行会由存储过程处理器来完成。Index Server 中的组件各
司其职，共同实现一个强大而复杂的功能。
SAP HANA 数据库有自己的编程语言，SQLScript 可以用来编写一些数据存储过程和复
杂的逻辑等，而 L 语言则用于实现可以被 SQLScript 所调用的一些运算逻辑，用于实现用户
定义的一些功能，除此之外，SAP HANA 数据库也支持 MDX 语言。
Index Server 还包含了一个叫做计划引擎的组件，该组件可以允许对财务计划的应用在数
据库层面进行一些基本的计划操作，例如为已有的数据创建一个新的数据版本。计划引擎还
可用于执行一些反聚合的操作，将数据从高层聚合到低层聚合进行目标值的分布。
（3）数据的持久组件
资源库组件提供对元数据的版本管理，例如建模的视图、存储过程，以及它支持内容的
导入或导出，可以用于将 SAP HANA 的新应用内容交付给客户。在图 3-5 的最下面部分可以
看到，SAP HANA 提供数据的存储，并提供行存储、列存储、基于磁盘的持久层（未发布）。
持久层用于保持数据库事务的完整性，在第 2 章已经介绍过，这个功能来自 MaxDB 数
据库系统的功能，用来保证数据被完全恢复到最后一次成功执行 Commit 的状态。为了达到
这些目标，持久层采用写 Log 日志到闪存，并使用 Save point 的组合方式将数据从内存备份
到磁盘存储的方式。
（4）访问认证组件
所有访问 SAP HANA 数据库的请求都将在验证组件中完成，除了通过用户 ID 和密码进
行的访问 SAP HANA 之外，还支持 SAML 认证和 Kerberos 认证，以及和其他系统做单点登
录的登录验证方式。
目前的 HANA 版本只支持行、列式两种存储方式。对象存储方式是将原来基于
LiveCache 技术集成到 HANA 的新应用中，这种存储方式在当前的 HANA 版本还未对用户最
终发布，不过 HANA 在不断融合各种技术应用。对象存储是基于内存存储技术的，主要用于
优化和计算大型图形化数据的操作。和行、列存储不同的是，对象存储不是基于关系型数据
58 ◆ 第3章 SAP HANA架构介绍
库的存储方式，也不是将图形数据保存在数据库表中，而是保存在由持久层所提供的容
器中。
3.1.3 XS ServerXS Server（过去的名称为 XS Engine）是 SAP HANA 中一个非常重要的组件。XS 是
Extended Application Services（扩展应用服务）的缩写，从“应用服务”可以看出，SAP HANA 的 XS Server 专注于实现用户应用，在 HANA 系统与最终用户之间的人机交互方面提
供了更多选择。
众所周知，SAP HANA 支持行业标准数据库接口，如 JDBC、ODBC、ODBO 等。在
SAP HANA 和最终用户之间，需要额外架设一个应用层。在应用层，开发人员使用 Java或 .NET 等编程语言，封装数据访问接口，实现业务逻辑，并为最终用户定制用户界面，这
就是通常所说的“三层架构”。相应地，企业需要支付额外的软、硬件的费用。
XS Server 内置了一个轻量级的 Web 应用服务器，不需要其他任何额外的软件即可在
SAP HANA 上实现 B/S（浏览器 / 服务器）应用。打开 SAP HANA 的“黑盒子”，可以发现，
HANA 上的 B/S 应用的工作原理与“三层架构”对应，如图 3-6 所示。
数据存储层。Index Server 负责处理应用执行过程的所有数据查询及更新等操作，内 ❏
置的 OLAP、计算引擎可以高效地执行数据密集型操作。
应用层。在 XS Server 中，开发人员可以使用多种方式，把用户和 HANA 中的业务数 ❏
据真正关联起来。例如，当业务逻辑非常复杂时，可以使用 JavaScript 等脚本语言进
行服务器端应用开发。
展现层。从传统的 HTML，到最新最流行的 HTML5，均可在 XS Server 中开发部署。 ❏
提示
SAP 在 XS Server 中预置了大量的 JavaScript API，可用于：
访问服务器会话（Session）。 ❏
调用 SQL 语句。 ❏
访问资源库。 ❏
发送邮件或 HTTP 请求。 ❏
访问当前 HTTP 请求、回复对象。 ❏
XS Server 支持 OData（Open Data Protocol，OASIS 行业标准）等多种方式，让外部的
程序可以访问 HANA 中存储的数据。外部应用可通过 HTTP 请求 / 回复方式，进行数据查
询、更新，甚至创建数据库表等操作。企业已有的业务系统可以通过此种接口方式，与 SAP HANA 实时数据平台进行整合。
读者应该可以注意到，图 3-6 中仅用了一个矩形来表示 XS Server。确实，XS Server 是SAP HANA 中最新的一个战略性的组件，还未被大规模使用，当然目前也未向外部开发人员
开放。因此，当前 SAP HANA 系统中仅有一个 XS Server 实例。未来，随着 XS Server 的开
3.1 SAP HANA及相关外围系统 ◆ 59
放和大范围使用，SAP 会在 HANA 系统中开发出多个 XS Server 实例。这在技术上是非常容
易实现的。
B/S 用户界面（HTML 5,
SAPUI5 ）
用户
R
R R
HTTP
XS Server
HTTPEmail
Index Server 数据（驻内存）
磁盘卷
SAP HANA 服务器
数据存储层
展现层
应用层 外部服务XS Server
图 3-6 XS Server 应用示意图
至本书截稿之时，SAP HANA 中已经发布了多个基于 XS Server 的应用，例如文本模糊
搜索、DXC（Data eXtractor Connection，会在介绍加载数据 DXC 时进行说明）等。通常，将
所有这些应用称为 XS 应用。
3.1.4 SAP HANA 的开发接口
SAP HANA 提供了一整套的预定义接口的 API，客户端的软件或用户自己开发的程序可
以通过使用这一套 API 来访问 SAP HANA 中的数据和应用服务。接下来，我们将开始了解
这些基本的开发接口及其用途。
1．SQL 和 SQLScriptSAP HANA 是一个开放的系统，对标准 ANSI 92 SQL 全部支持，因为 SAP HANA 数据
库层的 SQL 的实现是基于 P*time 组件的，而 P*time 很早就实现了 ANSI SQL 92 全部特性，
60 ◆ 第3章 SAP HANA架构介绍
之后还在 SAP HANA 标准上为用户提供了很多额外的 SQL 扩展语言（这些扩展语言的官方
名称是 SQLScript），例如 Oracle 也基于 SQL 提供了 PL Plus，而且有标准的开发指导手册
（参考本书最后的附录部分）。以下是 SQLScript 的一些特性说明：
可以创建一个基于行或列的数据库表，而且还支持在两种存储之间互相转换。 ❏
支持定义和查询临时表。 ❏
支持几种特别类型的 SQL 视图。这些视图和列式数据的视图不同，这几种特别类型 ❏
的视图是 OLAP 层的视图（星形模型）或 Calculation View 等。
对很多 SQL 的语法都做了特别的扩展。用户可以使用这些扩展的参数，而以往的标 ❏
准 SQL 没有提供这些参数供用户使用。
支持基于数据库表和视图级别的全文本检索。 ❏
支持 SAP HANA 提供的计划引擎。用户可以通过 SQLScript 来调用这些计划引擎的 ❏
功能。
SQLScript 是 SAP HANA 默认的开发语言，它提供了 Table Type 类型的数据结构。用户
可以定义一个 Table Type 类型的变量，此类型的变量可以保存任何 SQL 查询返回的临时结
果，其结构由返回的数据类型自动进行匹配定义。在使用 SQL 执行一些复杂的计算逻辑时，
Table Type 能够作为一个临时表保存某些中间运算值。SQLScript 是包含 SQL 的，这意味着
SQLScript 中可以包含标准的 SQL 语句。
2．MDXSAP HANA 数据库也提供了 MDX （多维度查询表达式）。目前版本的 SAP HANA 提供的
MDX 的特性只能通过 MS Excel 和其他支持工具来访问和使用。目前 SAP HANA 对于绝大
多数的 MDX 规范和特性都支持，并且会继续在这方面进行开发。
3．REST Service 和 XS Server在前面我们了解了 XS Server 这一组件，它是一个轻量级的应用服务器，支持客户端程
序通过 HTTP 的方式来访问 SAP HANA 系统。 XS Server 提供的服务可以通过编写服务器端
应用程序来实现。
要访问 XS Server 提供的 HTTP 服务，就要用到 REST 接口，通过这个接口，应用开发
人员可以使用 XS Server 将 HANA 内存数据库中的数据和资源通过 HTTP 的方式发布。当前
在 XS Server 中开发的 HTTP 服务均是通过服务器端的 JavaScript 来实现的，而且增强了对
SAP HANA 的数据结构的支持，用户可以编写 JavaScript 来访问 SAP HANA 数据库中的数
据，使用 SQL/SQLScript 来调用其中的业务逻辑。
4．HANA Client LibrariesSAP HANA 提供了一组封装好的技术组件，这组组件被广泛称为 P HANA Client，其实
它是一组客户端的驱动程序，用于在不同的平台下访问 SAP HANA 中的数据提供接口。以下
是 HANA Client 提供的数据接口及其描述：
为标准 Java 应用程序提供 SAP HANA Database JDBC 驱动。 ❏
3.1 SAP HANA及相关外围系统 ◆ 61
为 Windows 系统提供 ODBC 驱动，例如 Office 集成，直接通过 ODBC 数据源来访问 ❏
HANA。
为 SAP ABAP 应用系统服务器提供的 DBSL（Database Shared Library），使 ABAP 可 ❏
以访问 HANA 数据库。DBSL 并未包含在 HANA Client 软件包中，而是作为 SAP Basis Kenerl 的一部分来发布。
为 Python 提供了 Python Database API。 ❏
为 MDX 方式提供了 ODBO 接口。 ❏
3.1.5 分布式 SAP HANA 系统
我们已经了解了 SAP HANA 数据库系统的一些重要的服务器组件，以及其承担的功能和
作用。由于单台服务器物理内存和 CPU 处理能力的限制，在用户需要处理和存储的数据超
过单台系统的容量之后，可以将 HANA 部署成多节点的方式，这样既能保证 HANA 的高
可用性，又能对 HANA 做一个横向扩展，以支持更加庞大的数据处理任务和更多的用户并
发访问。
再看一下在分布式环境下多台 SAP HANA 服务器节点是如何协同工作的。图 3-7 是一个
简单的说明，可以看到这个环境中有 3 台 HANA 的物理服务器节点。
IndexServer
IndexServer
NameServer
NameServer
SAP HANA 数据库实例
Pre-processor Server
Pre-processor Server
Pre-processor Server
IndexServer
StatisticsServer
XSServer
NameServer
服务器 A 服务器 B 服务器 C
共享存储，在所有服务器节点可见（Shared Nothing）
图 3-7 使用共享存储实现 Scale-Out 和 HA（物理或虚拟化）
在分布式 HANA 数据库环境下，一个整体 SAP HANA 数据库系统一般可以由多台
HANA 数据库的服务器节点组成，而且是统一管理的。系统的不同组件都能看到来自外部的
客户端软件的请求，而且在数据库层面共享一组元数据，每次来自客户端的请求都能被分配
到不同的服务器中，这样的场景依然被认为是一个数据库系统，和 SAP 的其他产品一样，通
过统一的 SID 来进行标识。
从图 3-7 中可以看出，这个 SAP HANA 数据库实例（Instance）有 3 个不同的服务器，而
且都安装在不同的物理服务器上，每个实例都有自己的 Index Server、Pre-processor Server 等，
但是只有服务器 A 中才有 XS Server 和 Statistics Server，并且一个 SAP HANA 数据库系统范
围内只会有一个这样的服务器存在，这个服务器 A 有点类似一个主服务器，用于监控和调度
62 ◆ 第3章 SAP HANA架构介绍
各个服务器之间的计算汇总和处理任务等，这是 SAP HANA 最典型的分布式数据库系统。
分布式的系统架构是为了解决单个物理服务器计算资源限制的一种架构，反映在
SAPHANA 上则是可以提升整体的内存容量、计算能力，以及可以避免单点故障等。在分
布式的环境下，为了实现最好的运行性能和负载均衡，在每个服务器节点上都会运行 Index Server 及其相关的服务组件。
通过图 3-8，我们来了解一下在 HANA 中的横向扩展和防止单点故障是如何实现的：
在持久层方面，所有的服务器都安装和运行在同一个共享存储上，但是每个服务器都 ❏
有自己独立的内存、闪存和处理器资源。
每个独立的服务器节点都运行着一个 HANA Host（每新加一个服务器节点，就会在这 ❏
个服务器节点上安装一个 HANA 软件），而且每个服务器节点上都有自己独立的 Index Server、Name Server 等，在一个集群环境中可以定义 3 个 Master Name Server，但是
同一时间点只会有一台 Name Server 成为活动的 Master Name Server，另外两个则处
于随时替代的状态。
所有服务器节点的故障侦测工作是由处于 Active 状态的 Master Name Server 来监控完 ❏
成的。
服务器1
服务器2
服务器3
服务器4
服务器5
服务器备机
共享存储（物理或虚拟）
图 3-8 集群和防止单点故障
在图 3-8 中，共享存储每一个节点上都有 Index 和 Log 文件，如果任何一个节点出现故
障，处于 Standby 的服务器将出错节点服务器的数据和日志从共享存储读进自己的服务器内
存，然后替代这个故障节点开始工作。
图 3-9 是目前全球最大的单个 HANA 集群系统，此系统拥有 4000 多个 CPU 内核和
500TB 内存容量，以及超过 100 个 IBM X5 的 HANA 服务器节点，每个单节点的最小内存超
过 1TB（最少可以存放几个 PB 的未压缩数据）。在这种大型 HANA 集群系统中，磁盘对于
HANA 来说只是备份和掉电的持久层介质而已，运行期无磁盘 I/O。
SAP HANA 从一开始就在软件架构层面支持多节点来保障用户的高可用性，虽然不同的
硬件厂商推出硬件层面上的高可用性和集群的思路不同，但是基本上都是遵照单个节点加共
享存储的方式。关于高可用性和横向扩展的话题，将在本书第 12 章详细讲解，并且会列举
出不同的硬件厂商提供的高可用性和横向扩展方案。
3.2 SAP HANA技术路线图 ◆ 63
图 3-9 HANA 集群系统
3.2 SAP HANA 技术路线图
从前面关于 SAP HANA 发展历史的介绍中我们已经看到 SAP HANA 对于 SAP 公司自身
来说已经不是一项新技术，在过去和现在一些新发布的产品和即将发布的 ERP on HANA 第
一版，以及 SAP 对外发布的官方文件（例如 SAP Database Roadmap External Version）中都
能看到，SAP HANA 已经成为 SAP 发展下一代核心数据库平台产品中最重要的产品。由于
SAP HANA 也是 SAP 数据管理战略平台的一个重要产品，因此在介绍它时也会涉及其他的
一些 SAP 数据库产品，但是由于篇幅和相关性方面的原因，这里就不做太多介绍了。
SAP 在保护客户现有 IT 投资的前提下不断创新，提出了下一代实时数据平台的策略，
其中实时正是 SAP HANA 众多技术要点中最为突出和最为吸引用户的亮点。从 SAP 当前公
布的实时数据平台路线图（如图 3-10 所示）来看，SAP HANA 技术发展大体上分为 3 个阶段。
1．不中断的集成
SAP HANA 企业版本发布之初的全称是 SAP High Performance Analytic Appliance，简称
为 SAP HANA，从字面上来看是指面向分析型的应用系统，可视为一种创新的 OLAP 应用系
统，但是现在的 SAP HANA 已经不仅仅是一个面向分析的应用系统，至于原因，下文会详细
解释。
不中断的集成意味着 SAP HANA 将以不中断当前 IT 架构的方式进入企业信息系统的范
围，主要是作为企业 OLTP 和分析数据管理平台，具体体现在针对 OLTP 系统的应用化分析，
以及数据深入挖掘分析。
在此阶段，SAP HANA 体现的主要价值是和企业的现有信息系统架构进行集成，或者
是让各类企业都能从 SAP HANA 中受益，反映到具体的软件产品和范围就是：将原有 BW迁移到 BW ON HANA 之上，或者让 HANA 作为 SAP ERP 的应用加速器，或者利用 SAP HANA 作为现有 EDW 系统的补充，弥补其在海量数据处理和敏捷性上的短板。
64 ◆ 第3章 SAP HANA架构介绍
2．深入优化
SAP HANA 用于扩展 OLTP 在性能方面要求极高的业务，以及处理海量数据这种集成应
用。例如，SAP HANA 中的文本模糊检索、语义分析和非结构化数据存储，以及通过 Data Services 从 Hadoop 中做数据的抽取和分析等。
对于用户来说，SAP HANA 将成为 SAP 所有 OLTP 和 OLAP 应用产品系统的底层数据
库，除了可以在数据库上进行迁移之外，在基于新软件体系的应用架构中可以获益良多，例
如应用开发的简化，充分利用 SAP HANA 高性能的运算能力，减少数据冗余和维护成本。
3．融合
将 OLTP 和 OLAP 在一个系统实现平衡融合，既可以利用 OLTP 的数据处理，又可以运
行 OLAP 的分析应用，同一份数据无须为了应对不同需求而存储多份，而且数据不需要 ETL转换的过程，还可以实现实时业务处理和分析。对于企业的 IT 架构来说，这是最理想的状
态，这是 SAP HANA 要达到的目标，而且这一目标也越来越近，越来越清晰。从最近一些新
发布的产品版本中我们已经很清楚地看到，SAP HANA 不仅擅长分析，而且对 OLTP 的事务
性处理照样“拿手”。
第三方 BI客户端
SAP商务套件
产品
SAPBW
数据仓库
SAP大数据应用
SAP分析
SAP移动应用
客户定制化应用
SAP NetWeaver 平台或采用云平台的 NetWeaver
SAP 实时数据平台
开放开发者 API 和接口
com
mon
Mod
elin
gsy
base
pow
erD
esig
ner
MPP
Scal
e-O
ut
SAP Sybase ASE SAP Sybase IQ
SAP Sybase SQLA
SAP Sybase ESP
HA
DO
OP
3rd pa
rty D
B
Com
mon
Lan
dsca
pe M
anag
emen
t
SAP SybaseReplication Server
SAP DataServices SAP MDG, MDM
SAP HANA
SAP Smart Data Services Platform
图 3-10 SAP 实时数据平台路线图
目前，客户已经在广泛使用 BW 7.3 powered by SAP HANA 这个版本。其实 HANA 作为
BW 的底层数据库已经承担了大量的 OLTP 任务。在 2013 年上半年发布的 ERP powered by SAP HANA 的第一个版本中，继续深入优化 ABAP 的内核，让 ABAP 虚拟机和 SAP HANA从底层就能有良好的集成，并且提升所有模块的关键功能（通过调查全球 ERP 客户使用频率
最高和性能有待提升的事务代码，如财务月结、未清项目结算，以及库存计算和查询等这些
3.3 一体化设备的竞争 ◆ 65
利用率相当高的事务处理）。之后还会陆续推出新的版本，这些不断更新的版本就是为了充
分利用 SAP HANA 的数据运算功能而对 ERP 源代码所做的修改和完善。
在 ERP powered by SAP HANA 发布的同时，我们还看到 SAP 其他的核心应用 CRM、
PLM 和 SCM 都已经 Powered By SAP HANA，而且会持续地升级更新，将原有系统功能的业
务处理逐渐下沉到 SAP HANA 中，因此 HANA 将成为 SAP 产品的高性能底层数据平台。
3.3 一体化设备的竞争
介绍高性能数据计算一体机设备时，不可避免地会讲解到其他厂商推出的一些数据处理
产品。作为 SAP HANA 的最直接的竞争对手，就不得不提到 Oracle 公司的 Exadata 系列一体
机设备，当然，还有其他的一些海量数据处理产品，接下来我们会将这些产品与 SAP HANA进行一些基础特性和竞争分析。这些特性对比信息是作者根据个人经验和知识积累做出的一
些总结，仅供读者参考。图 3-11 是 SAP HANA 和 Oracle Exadata 两个产品在直观上的表现，
稍后将会详细阐述两者的差异。
SAP HANA高性能内存数据库 PC 服务器
PC 服务器
存储（可选）
存储（必需）Oracle
标准数据库
SAP HANA一体化设备
OracleExadata 一体机
图 3-11 两种产品的直观感受
3.3.1 不同的创新
SAP HANA 代表的是目前最先进的内存计算技术，在软件架构上做了彻底的创新，是从
头到尾重新设计并开发完成的产品，属于技术革命性产品。2010 年末，SAP 第一个发布了基
于高性能内存计算技术的数据处理设备——HANA。
Oracle 公司的 Exadata 一体机产品，也是针对用户需要进行海量数据库处理的需求，以
及改善 Oracle 数据库对于海量数据处理的一些不足而推出的，不过其硬件部分打包了 Sun 公
司原有的硬件产品。Exadata 一体机的设计思路是不对用户应用层做任何修改，但是希望通
过硬件层面的升级来解决传统 Oracle 数据库的瓶颈问题，这个出发点是对的，因为这样可以
在一定程度上保护现有的应用系统投资。
从 Oracle 公司目前推出的 Exadata 系列产品的宣传卖点上来看，也主推了“内存计算”
这点。在 SAP 推出 HANA 这款产品 8 个月之后，Oracle 公司也推出了 Exalytics，也是一款
基于内存计算技术的一体化分析设备，其他的厂商也陆续推出以“大内存”或“高性能计算”
为亮点的数据处理产品，这已经能说明整个市场和行业已经认识到内存计算这一技术趋势和
优化需求。
66 ◆ 第3章 SAP HANA架构介绍
作为 SAP 公司全面竞争对手的 Oracle 公司，面对 SAP HANA 侵蚀其传统数据库市场份
额的形势，自然也推出了一些新版本的产品。接下来我们就相关技术点做一些创新性对比，
如图 3-12 所示。
创新在此
创新在此
SAP HANA Oracle Exadata
软件架构
新一代内存计算技术
无磁盘 I/O 方式，软件管理硬件
行 + 列存储，压缩
支持 OLTP 的列式
MPP+ 共享内存 + 无共享
硬件
多核 CPU单机～ 2.5TB，1 ～ 100 节点
250TB 内存
Fusion-IO 闪存
磁盘作为备份，数据全保存在内存
交换机（集群时才需要）
万兆网络交换
CPU-CPU 直连，内存共享的并发计算
存储（集群时才需要）
用于做备份，Scale-Out/HA 等方面
存储（必需）
不仅存储数据，并且利用存储软件
进行数据计算 + 智能扫描
交换机（必需）
InfiniBand 方式交换机
服务器 <-> 存储之间数据传输
硬件
多核 CPUFull Rack ～ 4TB，1 ～ 8 Full Racks32TB 内存
Fusion-IO 闪存
数据保存在磁盘
软件架构
Oracle 标准企业版数据库
磁盘技术，无更多优化可能
传统行存储和 DB 技术
支持 OLTP 的应用
软件架构无任何变化
图 3-12 不同的创新
在 Exadata 一体机的数据存储层面，不再是简单地存储数据库的数据，而是通过智能扫
描（Smart Scan）为 Oracle 数据库系统减负，并且承担了一部分数据块的查询和计算工作，
在这一点上的大胆创新绝对是值得赞许的。Exadata 一体机在软件部分则继续维持和使用标
准的基于磁盘架构的 Oracle 企业版数据库（Oracle Enterprise Database 11g ～ 12c），从 Oracle公司最近刚发布的 ExadataX3 版本来看，也只是以更大内存容量、更快磁盘读写速度、更
高网络带宽、更大闪存容量等作为亮点，而在 Oracle 企业版数据库软件架构上并没有任何
改变。
从 X2 到 X3，在 Exadata 一体机中，更多的是 Sun 公司原来的硬件和软件部分，这种打
包销售和一体化的方式，也是为了证明 Oracle 在收购 Sun 公司之后，希望将原有 Sun 公司亏
损的硬件业务加以扭转，证明收购是正确的。
总体来说，这种硬件上的打包解决方案不可能将有几十年发展历史的 Oracle 数据库的设
计核心突然一下就转变为内存计算。Oracle ExadataX3 自称内存计算的机器，虽然有点名
3.3 一体化设备的竞争 ◆ 67
不符实，但是对于 Oracle 现有的客户，如果希望提升 Oracle 数据库的整体性能，还是不错
的选择。
点评
标准 Oracle 企业版数据库安装在打包的 2TB ～ 4TB 内存的一体机上就成为“内存计算”
机器吗？过去 Oracle 数据库安装在普通 PC 服务器上为什么就不是“内存计算”机器呢？所
谓的“内存计算”技术并非是以硬件服务器的大内存为标准的，而是软件架构本身为在内存
中管理数据库系统而设计的。
3.3.2 内存计算与缓存数据
毫无疑问，所有的软件供应商都看到了内存计算技术在海量数据处理速度上的绝对优
势，于是很多厂商在 SAP HANA 发布之后都顺势推出了支持大内存的服务器，那么这些传统
数据库系统架设在拥有几百 GB 到几个 TB 内存的硬件服务器上是否就立即变身成基于内存
计算技术的数据库系统呢？答案显然是“不可能”。下面将对比内存计算与将数据从磁盘缓
存到闪存的技术差异。
（1）大内存对于传统数据库系统的作用
更强的计算能力和更大的内存容量，能够为软件系统提供一个好的基础。针对上层的软
件系统来说，加大内存能够给数据库系统提供更多的缓存空间，从而减少磁盘 I/O（将尽可能
多的数据放在内存中，此时，在访问数据库系统时，若要访问的数据刚好在内存中，就无须
从磁盘读取）。
（2）传统数据库加上大内存不等于内存数据库
例如，Oracle 公司发布的 Exadata 系列数据库一体机产品，其软件系统是标准 Oracle 企
业版数据库，其软件架构基本没有任何革新，但是，从硬件上看，从之前发布的 X2 到最
新发布的 X3，其内存容量从几百个 GB 上升到了几个 TB，硬件计算能力和内存容量确实
提升了很多（例如，Exadata X3 Full Rack 版本提供 4TB 的内存、22TB 的 Flash-Card 存储，
500TB 的存储，以及基于 Intel x86 架构的 PC 服务器 + 智能扫描存储节点）。这种硬件配置
对于企业的事务应用和业务交易系统来说，还是提供了较为强大的处理能力。
（3）闪存不是内存
Exadata x3 Full Rack 版本提供了 4TB 内存和 22TB 闪存，这样也只能将一部分数据放
在内存中，并非如宣传所说，全部数据都在内存中，而且这里提供的 22TB 的闪存可以直
接缓存磁盘的数据库。虽然闪存比磁盘的读写速度快了至少一倍，但是内存还是比闪存快
1000 倍。
SAP HANA 当前最大的集群，早已可以提供 250TB 内存（到 2013 年上半年，内存容量
将继续翻番，可以存放超过 2PB 的原始数据），加上 4000 个 CPU 内核各自负责访问本地内
存，这样最大化了并发访问，而且 SAP HANA 也有巨大的闪存（与内存大约是 1 ∶ 1.1 的关
系），当然 HANA 不会将数据存放在闪存中。
68 ◆ 第3章 SAP HANA架构介绍
从一定程度上来看，内存数据库系统容量可以有多大这已经不是技术的问题，而是投资
回报和客户是否有这么多应用要处理的问题。目前 SAP HANA 官方认证的很多家硬件厂商都
提供超过 16TB 内存的多节点集群硬件服务器，无论是可扩展性和基于内存计算的容灾方案，
所有主流的硬件供应厂商都能提供很好的解决方案。
（4）是减少磁盘 I/O 还是彻底消除磁盘 I/O显然，Oracle Exadata 希望减少磁盘 I/O 而非彻底消除磁盘 I/O，因为它还是基于传统架
构进行逐步优化和过渡的产品。相信在不久的将来，Oracle 公司也会推出全内存计算的版本，
当然前提是 Oracle 公司要彻底重新设计 Oracle 数据库的架构。
表 3-1 是来自 SAP 官方的特性和说明对比，主要是为了对两种不同的应用设备做一些最
基础技术架构的区分。
表 3-1 SAP HANA 和 Oracle Exadata 的特性对比
特性对比 SAP HANA Oracle Exadata
100% 内存数据库
内存中存放超过 1PB 的原始数据
简化的平台
自由选择硬件供应商
基于 Intel x86 平台
基于 Linux 平台
超过 10 万倍性能提升的客户案例
3.3.3 混搭和简约
Oracle Exalytics 也是 Oracle 公司一体机系列的产品之一，如图 3-12 所示，其定位是分
析型应用系统，其硬件基于 1TB 内存、4 颗 CPU 的 PC 服务器。从软件方面看，这款一体机
包含了 3 个独立的数据处理系统，以及 Essbase 数据库、TimesTen 数据库和 Oracle BIEE 分
析套件，当然还内置了一些业务功能库，并且可以提供与 R 的集成。乍看上去，这的确是一
个比较复杂而混搭的系统架构，而且刚发布不久，在客户市场上和 Exadata 也有一定的重合
之处，目前全球的客户案例非常少。
Oracle 公司目前并未发布最新的超过 1TB 内存的 Exalytics 产品，而且这 1TB 内存还
不能全部用于存放数据，需要留出 50% 的内存容量作为运行空间。如果用户需要在 Oracle BI 分析套件中对数据做快速多维分析，需要将这些数据从 TimesTen 中导出，然后导入到
Essbase 数据库中，做一个行列转换，相当于一份数据在 Exalytics 中存留两份，这种做法只
是为了满足 Essbase 内存计算和列存储的需要。如果用户需要进行一些统计分析（Oracle 称其为“高级虚拟化”），则必须再次将数据导出，放到处理区域，使用 R 统计编程语言进行计
算，然后再将结果存储到其他位置。而以上所有的操作，在使用 SAP HANA 时则没有上述的
所有这些“转来转去、导入导出”的过程。
3.3 一体化设备的竞争 ◆ 69
图 3-13 Oracle Exalytics（来自 Oracle 官方）
SAP HANA 对于用户来说就是一个整体简约的平台，支持数据库表在行、列存储之间做
格式转换，但是不会产生任何的冗余存储和副本。存放在 HANA 中的最明细的数据，不会衍
生出多个不同的副本版本，也不会因为在 HANA 中建模以后生成物化视图数据。
HANA 的定位非常清楚，它不只适用于数据分析系统，而且是一个通用数据平台。因
此，SAP 公司并未将 HANA 和 BI 4.0 商务智能软件打包成一个 SAP 版本的“Exalytics”。
3.3.4 SAP HANA 与 Teradata 及 Oracle 系列产品的对比
前面我们已经对 SAP HANA 和 Exadata 做了一些基本比较，为了更加全面地了解市场上
其他的一体化设备，表 3-2 列举了更多的产品信息指标来进行对比，仅供读者参考。
表 3-2 不同的一体化设备技术信息参照表
对比指标 Teradata SAP HANA Oracle Exadata Oracle Exalytics
发布时间 1996 年 2011 年 2008 年 2012 年
客户市场稳定的客户市
场
超过 615 家客户（截止
到 2012 年 10 月）超过 1000 台 未知
产品类型 设备 设备 设备 设备
工作方式 磁盘技术 内存计算技术闪存加速 OLTP存储加速 OLAP
内存计算 + 磁盘技
术
支持 OLAP OLTP/OLAP OLTP/OLAP OLAP
业务应用 无 超过 35 个 无 无
集成 SAP 额外开发 无缝集成 额外开发 额外开发
运行 BW 未知 可以 未知 未知
集成 Oracle 额外开发 无缝集成 无缝集成只和 Exadata、
Oracle 数据库集成
压缩数据 不压缩 5 ～ 20 倍 5 ～ 10 倍 未知
70 ◆ 第3章 SAP HANA架构介绍
对比指标 Teradata SAP HANA Oracle Exadata Oracle Exalytics
硬件供应商 TeradataH P、 I B M、F u j i t s u、
Dell、Cisco、Hitachi、NEC
Sun Sun
CPU 架构 Intel x86 Intel x86 Intel x86 Intel x86
内存计算技术 否 是 否 是
支持最大内存 未知 2TB ～ 250TB 4TB ～ 32TB 1TB
操作系统 未知 SUSE Linux 11 SP1 64 位Oracle Linux 5 or Solaris
11 64 位未知
网络系统 未知 10GB 以太网对内：Infiniband；对外：10GB 以太网
未知
提示
1）关于 SAP HANA 性能基准及测试报告的详细信息，读者可以参考“ SAP HANA Performance，Efficient Speed and Scale-Out for Real-Time Business Intelligence”文档，这是
SAP 官方公布的数据测试报告。
2）读者可以进入本书的新浪微群获得此文档资源，或者通过 http://www.saphana.com/docs/DOC-1647 中提示的下载链接进行下载。
3.4 实时计算的应用价值
我们已经了解了 SAP HANA 给用户带来的最直观的感受是什么，那就是极速和实时，从
过去的几个小时、几十个小时的业务处理变成现在的几秒钟就能看到结果。也就是说，过去
从信息发生，再到加工处理，最后经过漫长的时间才能看到计算结果，发展到如今的实时计
算。从“过去发了什么”变成了“现在正在发生什么”的业务运维状态，这些都是切实的变
化。那么，应用 SAP HANA 能够给企业和用户带来什么竞争优势呢？
（1）更快和更好地进行决策
立即访问相关信息，无须漫长等待。对于拥有海量信息的企业信息化系统而言，有针 ❏
对性的业务分析对数据库而言无疑存在巨大的数据吞吐压力，而 SAP HANA 在处理
业务相关的计算速度接近实时。
基于实时信息的快速反应。企业的经营管理者可以实时了解企业经营状态的业务数 ❏
据，完全消除信息延迟而带来的影响，以更快速地做出明智的决策，从而抓住潜在的
商机。
（2）创造革新的应用
支持将大量交易与分析能力相结合的创新型应用，提升商务智能，从而显著改进现有 ❏
的计划流程、预测流程、定价优化流程及其他流程。
（续）
3.4 实时计算的应用价值 ◆ 71
加速事务操作，实时访问，做出更佳决策。 ❏
实时操作数据与分析数据结合，支持计划与预测，内置各种分析和预测引擎等。 ❏
（3）降低 IT 的负担和风险
完善而丰富的应用开发生态圈，众多的上层应用（来自 SAP、合作伙伴和客户） ❏
显著降低硬件及维护的成本。 ❏
快速而灵活的部署方式，例如基于 SAP HANA 的 RDS 快速解决方案，极大地降低了 ❏
用户在实施上的投入。
（4）简化企业的应用平台架构
SAP HANA 将企业的海量数据从众多业务系统中分离出来，摒弃传统数据仓库模型的 ❏
物化视图，实现海量数据的实时分析，从而体现出数据的最大价值。
不必中断现有的任何系统，却为软件架构的应用层层级进行了大幅度“瘦身”。 ❏
列存储方式最大化减少数据的重复，降低数据存储的容量，减少了企业在运维上的 ❏
投入。
