SAP HANA

SAP HANA™：下一代业务应用程序和实时分析

思考间探索分析大数据

SAP HANA™：下一代业务应用程序和实时分析

目录

4 变革商业运行方式

5 当代企业解决方案

6 技术转移

8 SAP HANA平台概览

运用新的业务数据处理方式

10 技术基础

执行控制

SQLScript 表函数的计算模型

并行执行

13 列式和行式数据存储

在列式存储和行式存储中选择

列式表的优势

时态表

16 SAP HANA让业务应用程序获益

17 数据管理技术方式的模式转变

了解更多

新数据库解决方案突破了传统数据库架构的限制

变革商业运作方式

SAP 推出了一类新的加速下一代业务应用程序解决方

案。SAP HANA 是一个内存数据库，将数据处理、分析

数据处理以及业务逻辑处理功能组合至内存中，突破

了传统交易型数据库架构中，开发支持实时业务应用

的限制。

近些年，我们观察到了相互关联的技术和社会变革。

计算机系统处理器内核数在持续增长，以及大量整合

的高速缓存。主存空间已经几乎变为无限，能够存储

任何规模企业的所有业务数据。随着移动设备数量的

爆炸式增加，供做出决策的信息需能够在几秒内提

供。业务、风险和机会的变化需要实时跟踪，以保持

企业的竞争力。

依靠长期的业务经验和富有远见的研究，SAP利用先进的技

术创建了构建业务应用程序新范式，即通过SAP HANA实

现。SAP HANA能让您对联机交易数据结构(OLTP)执行实时联

机事务处理分析(OLAP)。因此，您可以通过创建业务应用程

序处理今天的需求、实时的业务洞察力，这在过去是既不

可行，也不划算的。

SAP HANA 引入了完全不同的思考方式：从技术角度关心如

何构建应用程序，而从业务角度则思考如何利用新的功能。

SAP 提供了一个渐进的路线图，使您的组织能够安全地探索

当今日新月异的技术，在并排 (side-by-side) 场景中抓住机

遇，为业务的增长做好准备。

SAP HANA能让您对联机交易数据结构(OLTP)执行实时联机事

务处理分析(OLAP)。因此，您可以通过创建业务应用程序处

理今天的需求、实时的业务洞察力，这在过去是既不可行，

也不划算的。.

数据管理解决方案分离为事务和分析处理

SAP HANA™：下一代业务应用程序和实时分析 5

Data mart

Database

当代企业解决方案

当前业务系统的架构反映了商业解决方案漫长进化过程中的技术

条件：

• 数据库层：数据库管理系统专门设计为优化有限主存硬件上的

性能，以及低速 I/O 的主要瓶颈。主要集中于优化磁盘访问，

例如，通过最大限度地减少在处理查询时，读入到主存中的磁

盘页数。

• 业务程序层：商业软件利用顺序处理范例开发。目前场景中的

数据表从数据库中获取，一行接一行处理，并将结果返回至数

据库中。

正如 Plattener 和 Zeier 在他们最近有关内存数据管理的书中讨论

的，技术数据库的限制迫使数据管理解决方案分离为事务处理和

分析处理：

• 联机事务处理（OLTP）系统具有高度规范化的数据记录数，并

加快了插入、更新和删除操作的速度。这种高度标准化的缺点

是，当涉及到数据查询时，由于可能需要联接多个表，这将严重

影响性能。

• 联机应用处理 (OLAP) 系统开发为解决大型企业的要求，即使分

析它们的数据。这些系统利用专门的数据结构设计、优化读取性

能，并提供复杂分析数据的快速处理。

将数据从企业的事务系统迁至分析系统，然后为预定义的报表做准备。

图1展示了当代解决方案中典型的企业软件状况：大型组织拥有

多个企业资源计划系统(ERP)，每一个都有其运营数据自己的数

据库。分析数据在批量脱机处理中整合至企业级数据仓库，供企

业用户通过商业智能（BI）解决方案使用。需要根据近期（但不

实时）数据生成自定义报表的业务部门，使用额外的数据集市和

本地的BI客户端。

图1: 典型企业软件现状

Corporate business intelligence (BI)

Enterprise data warehouse

Database

Local BI SAP® ERP

(or SAP CRM, SAP SRM,

SAP SCM)

BI

Data mart

SAP® ERP (or SAP CRM, SAP SRM,

SAP SCM)

BI

Non-SAP

applications

Data mart

ETL* ETL Database Database Database Database Database

*ETL = extract, transform, load

对新计算模型的需求

技术转移

计算机体系结构发生了变化。当今的多核以及多 CPU 服务器提供了

通过主存或共享高速缓存，内核中的高速通信。主存不再是一种有

限的资源。2012 年将有 RAM 超过 2 TB 的服务器可供使用。

现代计算机体系结构创造了新的可能性，但也带来了新的挑战。由

于所有相关的数据保存在内存中，磁盘访问不再是性能的一个限制

因素。2012 年服务器处理器将多达 80 个内核，在不久的将来更将

达到 128 个内核。随着内核数的增多，CPU 将可以在每个时间间隔

内处理更多的数据。

这意味着性能瓶颈存在于 CPU 的高速缓存和主存之间（参见图 2）。

优化的数据库技术应着眼于优化访问存储器的处理核心。缓存内存

数据的简单磁盘访问优化，可能不会产生性能上的突破。

图 2: 硬件体系: 当前和过去的性能瓶颈

cPu

Core

CPU cache

Performance bottleneck

today: CPU waiting for data

to be loaded from memory

into cache

为了提供当前存储器层次结构的大小和访问速度的一个直观感

受，下表比较了该层次结构中不同的层（英特尔 Nehalem 架构中

的 CPU 特性）。

Main memory

Disk

Performance bottleneck in the past: Disk I/O

内存类型 大小 延迟

L1 cache 64 KB ~4 cycles [2 ns]

L2 cache 256 KB ~10 cycles [5 ns]

L3 cache (shared) 8 MB 35–40+ cycles [20 ns]

Main memory GBs up to terabytes 100–400 cycles

Solid state memory GBs up to terabytes 5,000 cycles

Disk Up to petabytes 1,000,000 cycles

SAP HANA™：下一代业务应用程序和实时分析 7

由于传统业务的解决方案依赖于OLTP数据库，他们无法有效地使

用现有的硬件。图3示展示了SAP®ERP应用的体系结构。

数据从数据库层传送至应用逻辑层以进行处理。正如图2所展示

的，性能瓶颈存在于主存和CPU之间。简单的将内存缓存驻留在传

统数据库不再是一个解决方案。一半的CPU执行时间浪费在阻塞的

原因有两个：等待数据从主内存中加载至CPU缓存中，而事实上，

顺序处理的业务应用程序不能正确地使用增长的处理内核。需要

发展一种新的计算模式，即集中于利用CPU高速缓存和大规模并行

多核处理。

图 3: SAP® ERP2三层架构

Presentation

Native client Mobile client Web client

Business logic

Dispatcher and request queue management

Shared memory and caches Work process 1 Work process n

Application server

Persistence

Database management system

直接在内存中优化程序和计算

SAP HANA平台概述

为商业数据处理带来了新途径

SAP HANA平台实现了数据处理中新的业务途径。事实上，它远

远超过了数据库的传统定义，并且其性质远不只是内存中磁盘数

据结构上的本地缓存。

SAP HANA的概念图如图4。虽然下面讨论的许多概念可能是行业中

已知的，SAP HANA具体的协同作用，利用了 SAP在不同领域的专

业知识，正在创建一个新类型的解决方案。

完整的数据库作为后台

图 4: SAP HANA™ 平台的概念图

SQL SQLScript MDX* Other

SAP HANA，首先也是最重要的是，它集成了一个完整的数据库管

理系统（DBMS）：使用标准的SQL接口、事务的隔离和恢复 (ACID

[原子性，一致性，隔离性，耐久性) 性能] 和高可用性。SAP

HANA支持大多数入门级SQL92。 使用Open SQL的SAP应用程序可

以在SAP HANA平台上运行，而不用改变。SQL是SAP HANA的标准

接口。额外的功能如自由搜索功能，被实现为SQL扩展。该方法简

化了SAP HANA应用程序的消耗。

分析和特殊接口

除了SQL，SAP HANA通过使用多维表达式（MDX）直接支持了商

务智能客户端的使用，如Microsoft Excel和商业智能消费服务

（BICS），它是SAP的Business Objects™解决方案的一个内部接口。

对于分析规划，用户可以重复综合分析报告上的值。为了重新计算

内存中的计划引擎，可以通过SAP HANA立即传送一个单一的值。

并行数据流计算模型 为了直接利用大规模并行多核处理器，SAP HANA对SQL的处理指

令进行管理，使之成为一个优化的模型，从而允许并行执行，并

极大地扩展了内核的数量。这种优化包括分区中的数据部分，在

这些分区中计算可以并行执行。SAP HANA支持不同主机上的分

布。为了由多个主机并行处理，大表可能进行分区。

Search

App extensions

Business function library

Predictive analysis library

Parallel calculation engine

图5总结了英特尔团队与SAP合作执行的规模测试结果。测试表明了

规模是接近线性的。使用双核的处理时间为16.8秒，使用32内核提

高了1.4秒。超线程增加了一个额外的20％的改善。

应用逻辑扩展

relational stores

Row based

Columnar

Managed appliance

*MDX = multidimensional expression

Objects graph store

特定应用程序的逻辑延伸了并行数据流的计算模型，该逻辑在处

理节点上是模型的一部分。功能语言SQL Script和命令式语言_

“L”能够支持它，它可以要求SAP HANA预测分析库中的已组装

程序算法执行先进的统计计算。应用逻辑的语言和概念在SAP开发

者社区的内部和外部中演变成为了协作的结果。

SAP HANA™ for Next-Generation Business Applications and real-time Analytics 9

商务功能库和预测分析库

SAP在具体的端口和SAP HANA内基础设施的应用程序功能业务

上，充分利用了其深厚的应用专业知识，从而充分地直接在主存

储器中通过优化计算和应用技术，处理利用内存中的计算。实例

包括货币兑换,这是作为一个全球性的公司根本上的第一步。否

则关于货币兑换的许多报告就可能利用简单的SQL，利用并行处

理。另一个例子是转换业务日历：不同的国家使用不同的民用或

商业日历，对一个财政年度也有不同的定义。

根据任务优化多个内存存储

本地的内存存储并未充分利用现代 CPU 的处理能力。SAP HANA 的

主要优化目标是在 CPU 不同的缓存层实现高命中率。这是通过数据

压缩和适应数据存储任务来完成的。例如，当处理一行行地完成处

理和消耗了大部分行内的字段时，被放置在存储器中行存储中的每

一行能顺序存储提供最佳的性能。如果计算是针对单列或好几列，

这些被扫描或合并到一个列式存储，其中每个列都能被顺序存储在

一个（压缩）内存阻塞里，提供更好的结果。一个对象的图形存储

可能从一个结构受益，在该结构中，每一个对象主体是按序列存储

的。作为另一个序列存储的图表导航存储支持非结构化和半结构化

的数据存储。

设备包

SAP HANA应用了优化，使CPU利用率发挥到了极致。设备包装可以完全控制资源和认证过程让硬件配置得到最佳的性能和可靠性。例如，SAP HANA可以自动从内存错误中自动回复，而无须重新启动系统。具有高内存的系统在统计学上对这样的错误更敏感。和一个的家电包装模型所有权的有利总成本一样，这是一个SAP HANA设计概念的基本组成部分。此外，SAP正积极研究虚拟设备和云模板，用于对SAP HANA额外的性能用例进行验证。

图 5：近线性刻度的实例

在64核的SAP HANA™ on 4S Nehalem-EX (2.26 GHz) 联接 TPC-H数据集(120,000,000,000条记录)

Processing time

(milliseconds)

16,822

10,000

8,598

4,410

20% improvement due

to hyper threading with

64 logical cores

2,484 1,339 1,116

1,000

1 2

4 8

线程数

16 32 64

设计和建造优化

R

技术基础

执行控制

执行控制如图6中所示。SQL脚本，MDX和规划引擎接口可以被看作是域特定的编程语言或模型，可以用来和SAP HANA互动。其特定的编译器的工件在不同的域特定语言中被翻译成常见的表示方法，我们称之为“计算模型”。

计算模型是一个有向非循环图，箭头代表数据流和并表示操作

的节点。这种方法和循环的排斥、递归使自动的大规模并行处

理成为可能。

对待计算模型最简单的方法是把他们认为是数据流图，在图

上，建模工具将数据源定义为输入及在输入上面不同的数据操

作（连接，聚集，投影等）。

计算引擎自动将一个模型断开为可以被并行处理的操作（模型优

化）。这些操作被传递到数据库的优化器，并由它决定访问行或列

存储的最佳方案，这一点利用了基于成本的优化和数据库统计。图

7 中说明了并行过程路径。

图 6: 处理链 (概念图)

Standard SQL statement

SQLScript MDX* query Planning model Other language/model

SQLScript compiler MDX compiler Planning engine Other compiler

calculation model (data flow graph)

R

SQL processor

R

R

calculation engine

Logical execution plan

Model optimizer (rule based)

R*

Model executor

R

Calculation engine

operators

R

Intermediate results

Statistics

Database optimizer

Physical

Script execution runtime

execution plan R

Database executor

R R

Intermediate results

Execute user-defined

function Row store

*MDX = multidimensional expression; *R = request

Column store R

SAP HANA™：下一代业务应用程序和实时分析 11

document

SA

P H

AN

A™

SQLScript 表函数的计算模型

图 7: 并行处理路径

代码层

如图 8 所示，SQLScript 使 SAP HANA 上的代码层成为可能，它是

SAP HANA 数据库上丰富的存储过程语言。SQLScript 程序可能包

含 SQL 语句，可以调用其他程序。它用于编写程序业务流程逻辑

及定义复杂的数据流。SQLScript 首先被编译成“L”（C++）有限

子集，然后被编译为本地代码。SAP 已经直接在 C ++中开发一个

业务功能库（BFL），它包括在数据库层进行业务处理的功能。BFL

可以被其上层调用。

SQLScript

SQLScript 组成的 SQL 查询和函数调用的函数可以表示无环数据流

图。在“L”语言实现的这些功能通常转化为只包含一个转换节点

类型“L 脚本”的计算模型。在某些情况下，为了嵌入 SQL 查询和

必要的代码序列节点，可以与在创建 SQL 节点的同时，创建一个

更复杂的图表。

Relational

operation

Relational

operation

Relational

operation

Relational

operation

Relational

operation

Procedural

operation

Relational

operation

每个节点都有输入和输出和一组将输入转化为输出的操作。除了它

们的主要操作，每个节点还可以有一个用于过滤的结果集滤波条

件。操作的输入和输出的表值操作数。输入可以连接到SAP HANA

表或节点的输出。

计算模型支持多种节点类型：

• 节点的设置操作如投影，聚合，连接，联合，减，交集

• SQL 节点，执行节点属性的SQL语句 。

• 脚本节点用于描述复杂的操作，不能由数据转换的曲线图进行

描述。这样的节点的功能可以由一个程序的脚本所描述。

为了启用并行执行，计算模型可能会包含分割和连接操作。分割操

作被用于分区输入表，以便在分区标准的基础上进行后续处理步

骤。分割和结合操作就可以在不同分区之间并行执行。

Parallel 1 Parallel 2 Parallel 3

图 8: SAP HANA中的代码层

Application server

SQLScript

L

c++

Business function library (BFL)

创建计算模型的编译器，尝试将尽可能多的输入程序变换成只包含

设定操作节点和 SQL 节点的计算模型。然而， 这并非对所有情况

都适用。例如，循环中依赖于以前的迭代的结果迭代不能被转换成

数据流图。在这种情况下，特定于域的模型中不能转化成数据流转

换的部分被翻译成在“L”语言脚本里的程序代码节点。

计算模型比传统的 SQL 查询或 SQL 的视图更强大，原因有二：

• 这些模型提供了定义专门的参数化计算模式的可能性，与此同

时实际的查询已被发出。不像SQL视图，计算模型不描述实际的

要执行的查询，相反，它描述了计算结构。执行计算模型时提

供了附加信息。计算引擎使用实际参数、属性列表、分组属性

等，与调用来实例化一个具体查询的计算模型。为了进行实际

查询，此“实例化模型”得到了优化，它不包含属性、节点、

或是特定调用中不需要的数据流。

• 这些模型允许通过 SQLScript 或 “L”语言的命令式脚本，执行

更 灵 活 的 、 基 于 脚 本 的 操 作 。

并行执行

SAP HANA 被设计为能在可用内核的数量，和跨越主机分配使用的

并行执行上很好地进行扩展。具体而言，多核平台的优化解释了以

下两个关键因素：

• 只要允许并行机执行的部分， 数据就可能被分区。

• 可以避免的顺序处理包括寻找替代方法，如线程锁。

并行聚合

SAP HANA进行聚合操作在节点内的共享内存架构上，产生了一定

数量并行行动的线程，这些线程能平等获得该节点上的内存数据。

正如图9上方所示，每个聚合函数在循环的方式如下：

1. 获取输入关系的一个小分区

2. 聚合该分区

3. 重复步骤1，直到处理完成一个完整的输入关系

每个线程都有一个独立的哈希表，编写自己的汇总结果。聚集线程

结束时，缓存的哈希表被合并到使用范围分区的合并线程中。每个

合并线程对一定范围负责。

图 9: SAP HANA™使用并行聚合在线程间分配工作

Aggregation

thread 1

Aggregation

thread 1

table

Aggregation

thread 2

local hash table 1 local hash table 1 Cache-sized hash tables

Buffer

Merger

thread 1

Part hash table 1

Part hash table 2

Merger

thread 2

SAP HANA的特有属性

SAP HANA™：下一代业务应用程序和实时分析 13

列式和行式数据存储

SAP HANA的特有属性是行存储和列存储位于同一引擎中。

从概念上来说，一张数据库表是一个二维的数据结构，以行和列形

式组织单元。而计算机内存则是以线性顺序组织。对于存储至线性

存储器中的表，如图10中所示有两个选项供选择。行式存储形式存

储表中含有所有字段的行。在列式存储中，一列的条目被存储在连

续的存储单元。

图 10: 行式存储和列式存储中的表

table

country Product Sales

US Alpha 3,000

US Beta 1,250

JP Alpha 700

UK Alpha 450

在列式存储和行式存储中选择

在SAP HANA中，你可以指定一张表以行式方式或是列式方式存储。

推荐使用行式存储方式，如果：

• 表中记录数很少，例如配置表等。

• 程序一次只处理一条记录（对于单条记录的许多select和update

语句）。

• 程序通常需要访问所有记录。

• 列主要包含不同的值，进而压缩率很低。

• 不需使用聚合和快速搜索。

举例来说，行式存储用于SAP HANA数据库元数据、应用程序服务器

内部数据如ABAP服务器系统表、以及配置表。此外，程序开发人员

应决定将业务表设为行式存储，如果其满足上述条件。

推荐使用列式存储方式，如果：

• 只对单列或者几列执行计算。

• 只根据几列的值搜索表。

• 表中有大量的列。

• 表中有大量的行，并且需要执行基于列的操作（聚合、扫描

等等）。

• 大多数列只含有少量的不同值（相较于行数），进而压缩率很

高。

行式存储

Row 1 US

Alpha

3,000

Row 2 US

Beta

1,250

Row 3 JP

Alpha

700

Row 4 UK

Alpha

450

列式存储

Country US

US

JP

UK

Product Alpha

Beta

Alpha

Alpha

Sales 3,000

1,250

700

450

SAP HANA允许行式表与列式表之间的联接。然而，联接相同存储方

式的表效率更高。因此，需要经常与业务数据联接的主数据表应为

列式存储。

列式表的优势

当满足了上述列出的条件后，列式表有诸多优势。

更高的列操作性能。对于单列的操作，例如搜索或是聚合，可以实

现为循环访问一个存储在连续存储单元的数组。这种方式具有较高

的空间局部性，可以有效地在CPU缓存中执行。

更高的数据压缩率。列式存储允许高效数据压缩，尤其如果将该列

排序，连续内存中将含有大量相同值，因此就可以使用例如运行长

度编码或者簇编码的压缩方法。这对有着大量列、却只含有相较于

行数几个不同值的SAP应用程序来说是特别有用，例如国家代码或

状态码以及外键。

这种高度的冗余，使得列式数据的压缩非常有效。在基于行的存

储中，连续的存储单元包含不同的列中的数据，所以不能使用如

运行长度编码的压缩方法。列式数据库与传统的面向行的数据库

系统相比，压缩因子是其10倍。

列式数据组织方式也可以使用高效的数据压缩。不仅节省了内

存，也同时增加了速度的原因如下：

• 压缩后的数据可以更快地加载到CPU高速缓存中。由于限制因

素只存在于内存和CPU缓存之间的数据传输，性能增益将超过

解压需要的额外时间。

• 列根据字典编码以位编码整数序列方式存储。可以对整数执行是

否相等的检查（例如，在扫描或联接操作过程中），速度远比字

符串比较操作快。

• 压缩可以加快扫描和聚合操作，如果开发人员了解压缩。由

于良好的压缩率，计算一列值的总和会快很多；如果该列以

运行长度编码，则相同值的求和可以由一个乘法代替。

消除额外的索引。在许多情况下，列存储无需额外的索引结构。将

数据存储在列中就像每一列有一个内置索引。内存中的列式存储扫

描速度和压缩机制，尤其是字典压缩，已经使读操作具有非常高的

性能。在许多情况下，将不再需要额外的索引结构，可以减少复杂

性并消除定义和维护元数据的工作。

并行。列式存储也可以很容易地并行使用多个处理器内核来执行操

作。在列式存储中，数据已被垂直分割。这意味着不同列上的操

作，可以很容易地并行处理。如果需要搜索或聚集多列，这些操作

中的每一个可以被分配给不同的处理器核心。此外，列操作可以通

过分割为不同处理器核心处理的多个部分，并行执行。图 11 展示

了两种选择。列 A 和 B 分别在不同的内核中处理，而列 C 则被分至

两个不同的内核中的分区处理。

更高的列操作性能。利用列式数据组织结构，对于单列的操作，例

如搜索或是聚合，可以实现为循环访问一个存储在连续存储单元的

数组。这种方式具有较高的空间局部性，并可以有效地在 CPU 缓存

中执行。

时态表（Temporal Tables）

正如上文提到的，SAP HANA 支持时态表，允许查询数据的历史状

态。时态表的操作不会实际覆盖现有的记录。相反，写操作总是将

数据记录的新版本插入到数据库中。不同版本的记录用时间戳标示

其有效性。应用程序可以告诉 SAP HANA，后续的查询将对数据库

中的历史视图进行处理。

SAP HANA™：下一代业务应用程序和实时分析 15

图 11: 列式存储的并行例子

core 1 core 2

Processed by Processed by

column A column B column c

1000032 4545 2500

67867868 76 21

2345 6347264 78675

89886757 435 3432423

234123 3434 89089

21 1252 562356

2342343 342455

78787 3333333

9999993 8789 123

13427777 4523523 56743

23423 6767312 342564

123123123 789976 4523523

1212 20002 1343414

2009 2346098 33129089

454544711 78787 3665364

Processed by

Processed by

core 3

core 4

SAP HANA 让业务应用程序获益

传统的业务应用程序使用物化的聚合来提高读取性能。这意味着程

序开发人员需定义额外的表，存储冗余的聚合结果，如其他表的求

和计算。物化的聚合在每次写入物化数据之后或在预定的时间进行

计算和存储。读操作则直接读取物化结果而非每次重新计算。

随着扫描速度达到每毫秒数兆字节，内存中的列存储可以高性能地

计算大量动态数据，以期消除在许多情况下的物化聚合，从而消除

高达30％原本所需的表。

在金融应用中，不同类型的总账及结余通常根据不同的分类账户持

久化为物化聚合：总账，应付账款，应收账款，现金明细账，物料

分类账，等等。使用内存列存储，所有总额和余额可以从会计凭证

项目中高性能的动态计算，因此可以消除这些物化聚合。

消除物化聚合有诸多好处：

• 简化的数据模型：使用物化聚合时需要建立额外的表，这使得数

据模型变得更复杂。例如，在SAP Business ByDesign金融数据模

型的解决方案中，持久化的总额和结余以星型模式存储。该模

型为总额和结余引入具体的业务对象，每一个对象由一张事实

表和多张维度表组成。在SAP HANA中，如果总额和余额是动态

计算，则所有这些表都可以删除。一个简化的数据模型使得开

发更高效，消除编程错误的源头，并提高可维护性。

• 简化的业务逻辑：应用程序需要在聚合项目新增、删除、或修

改之后更新聚合值，或需要在一定的时间间隔安排运行特定的

聚合，如一天一次。通过消除持久化的聚合，将不再需要这种

额外的逻辑。

• 更高级别的并发：使用物化聚合时，每次更新聚合的写操作需

要获取一把写入锁。这限制了并发性，并可能导致性能问题。

如果没有物化聚合，将只写入文件。这是可以同步实现，并且

无需任何锁。

• 聚合值的“及时性”：使用动态聚合时，聚合值总是最新的；

但物化聚合只在计划的时间更新值。

SAP提供了一个渐进的路线图，使您的组织能够安全地探

索当今日新月异的技术，在并排 (side-by-side) 场景中抓住

机遇，为业务的增长做好准备。

SAP HANA™：下一代业务应用程序和实时分析 17

数据管理技术方式的模式转变

SAP 正引领我们对数据管理技术的思维方式的模式转变。这种反思

影响我们如何构建业务应用程序以及我们在使用时的期望。用这种

新技术的企业将有可能增强他们的竞争优势，不仅大大加快数据查

询速度，也包括业务处理速度。SAP 与客户、顾问和开发人员紧密

合作，共同创造直接的业务收益和更长远的角度以及路线图。

作为大型企业中业务线的推动者，您可能会在短期内与顾问工作，

开发一个业务运营数据的实时报告。您可能集中在两个或三个特定

的业务场景和部署以并排、不中断的方式部署 SAP HANA。您的 IT

团队将逐渐得到使用 SAP HANA 的经验，学会利用它的灵活性，并

进一步扩展业务-用户社区内的利用率。您的组织将为内存计算做

好准备，并同时获得直接的商业利益。

了解更多

欲了解更多 SAP HANA内容, 请访问

www.experiencesaphana.com 和 www.sap.com/hana.

补充阅读

J. Krueger, M. Grund, C. Tinnefeld, J. Schaffner, S. Mueller, and A. Zeier,

“Enterprise Data Management in Mixed Workload Environments”

(Hasso Plattner Institute for IT Systems Engineering, 2009)

http://ares.epic.hpi.uni-potsdam.de/apps/static/papers/2009

_JK_Enterprise_Data_Management_in_Mixed_Enviroments.pdf

H. Plattner, “A Common Database Approach for OLTP and OLAP Using

an In-Memory Column Database” (SIGMOD’09, June 29–July 2, 2009)

http://www.sigmod09.org/images/sigmod1ktp-plattner.pdf

H. Plattner, “Enterprise Applications – OLTP and OLAP – Share One

Database Architecture” (Hasso Plattner Institute for IT Systems

Engineering, 2010)

http://epic.hpi.uni-potsdam.de/pub/Home/InMemoryDataProcessing

2010/ShareOneDB.pdf

H. Plattner and A. Zeier, In-Memory Data Management: An Inflection Point

for Enterprise Applications (Springer-Verlag, April 2011)

“Analyzing Business as It Happens: SAP In-Memory Appliance Software

(SAP HANA™) runs on the Intel® Xeon® processor to generate superior,

real-time business intelligence” (Intel|SAP, April 2011)

http://www.intel.com/en_US/Assets/PDF/whitepaper/mc_SAP_wp.pdf

D. Mettica and S. Lucas, “Prepare for the Quantum Leap in Real-Time

Analytics. How in memory analytics is going to change everything about

your enterprise” (IBM|SAP, June 2011)

http://www.sdn.SAP.com/irj/scn/go/portal/prtroot/docs/library/uuid

/d023f28a-6f9b-2e10-ec83-d84e518c3629?QuickLink=index

脚注

1. Source: Plattner, Hasso and Zeier, Alexander, In-Memory Data

Management: An Inflection Point for Enterprise Applications (Springer-

Verlag, April 2011).

2. Ibid.

3. Restricted subset of C++ used internally at SAP.

4. Source: “Analyzing Business as It Happens: SAP In-Memory Appliance

Software (SAP HANA™) runs on the Intel® Xeon® processor to generate

superior, real-time business intelligence” (Intel|SAP, April 2011).

5. Ibid.

www.SAP.com/contactSAP

50 110 843 (12/01) ©2011 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign,

SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other

SAP products and services mentioned herein as well as their respective

logos are trademarks or registered trademarks of SAP AG in Germany

and other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other

Business Objects products and services mentioned herein as well as their

respective logos are trademarks or registered trademarks of Business

Objects Software Ltd. Business Objects is an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and

other Sybase products and services mentioned herein as well as their

respective logos are trademarks or registered trademarks of Sybase, Inc.

Sybase is an SAP company.

All other product and service names mentioned are the trademarks of

their respective companies. Data contained in this document serves

informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials

are provided by SAP AG and its affiliated companies (“SAP Group”)

for informational purposes only, without representation or warranty of any

kind, and SAP Group shall not be liable for errors or omissions with respect

to the materials. The only warranties for SAP Group products and services

are those that are set forth in the express warranty statements

accompanying such products and services, if any. Nothing herein should

be construed as constituting an additional warranty.