SAP HANA 实战

内存计算

OLTP：Online Transaction Processing，联机事务处理系统的简称。
OLAP：Online Analytical Processing，联机分析处理系统的简称。
SAP HANA：SAP 公司推出的基于新一代内存计算技术的高性能实时数据平台。
BI：商务智能软件，以 SAP BI、Oracle Hyperion、IBM Congress 为典型代表，通常与数据挖掘、支持企业管理的业务运营和决策联系在一起。
RDBMS：关系型数据库管理系统，以 MS SOL Server、SAP Sybase ASE、IBM DB2、Oracle 和 MySOL 为典型代表。
列式数据库：列式数据库是相对传统的行存储数据库而言的，是以列存储相关技术为设计架构进行数据存储的关系型数据库，主要适合批量数据处理和即时查询。
内存计算：内存计算是指为了消除磁盘 I0 在应用系统中的数据吞吐瓶颈，而将应用系统的数据部分或全部放在内存中以供访问，从而提升系统性能的一种技术。
写优化：专门为提升数据修改的性能而设计的。行存储数据库基本上都是这样的架构。
读优化：为了提升数据查询和计算的性能而设计的，一般列式数据库使用较多，被视为读优化的数据库。

实时数据平台

NUMA：Non Uniform Memory Access 的缩写，中文意思为非一致性内存访问。这是一种硬件设计架构与之对应的是一致性内存访问(UMA)。在 NUMA 架构下，内存访问是 CPU 内核通过自己集成的内存控制器来访问自己的本地内存，而 UMA 方式则是所有的 CPU 内核都通过同一个 FSB 前端总线芯片组来访问内存。由于这个前端总线的带宽有限，在多核多 CPU 的架构下会出现数据链路阻塞，而且会出现 CPU 内核间的资源争用情况，所以现在 NUMA 架构使用广泛，而 UMA 渐渐被芯片领导厂商所抛弃。

QPI：Quick Path Interconnect 的缩写，是基于 Intel(英特尔)公司 x86 芯片的快速通道互连技术，是 Intel 公司全面抛弃了沿用几十年的 FSB 架构之后的全新技术，主要用来实现 CPU 内核和 CPU 芯片之间的直接互连，极大地增加了带宽，而且不需要统一通过 FSB 来进行数据通信。

IMDB：In-Memory Database 的缩写，中文意思为内存数据库，是对应基于磁盘技术的数据库而产斗的，利用内存计算技术构建的一种数据库系统。主要的创新是将数据保存在内存中，磁盘仅仅作为持久层来加快数据的读取速度，极大地提升了系统性能。内存数据库抛弃了传统磁盘数据库的设计模式，重新设计整体的架构和优化数据的存储等各个方面。如果不重新开始设计数据库架构，是无法将磁盘架构的数据库实现为内存数据库的。

列存储：列存储是相对于传统 RDBMS 的行存储而言的，通过将数据以一列一列的方式来存储从而提升数据的读优化、快速查找和聚合速度。采用列存储的数据库一般称为列式数据库。

MPP：Massive Parallel Processing 的缩写，中文意思为大规模并行处理，是指通过多个计算机硬件系统构建一个集群系统，在用户执行数据处理请求时，可以根据这个任务请求生成很多个子任务并分发到各个系统上去执行，避免不同服务器的跨系统数据读取，最后做合并运算处理，返回给用户。充分利用多个服务器节点的运算能力，做到真正的并行，而非传统的流水式运算，从而极大地提升计算机的处理能力。

动态聚合：对数据库中的数据做动态聚集(例如求合、平均操作)，其中动态指的是不会在数据库层创建任何临时结果集，查询结束之后聚合出来的结果集会失效过期，内存被自动收回。在传统 BI 产品中，因为数据库的性能关系，都无法做动态聚合，需要产生临时结果集，写到数据库的数据库表中。

只插入：是 SAP HANA 对数据的更新方式。传统的数据库更新方式是直接修改原来的值以达到更新数据的目的，而只插人是将更新数据变成插入一条新数据到原来的数据库表中，采用时间戳、数据老化和多版本并发控制方式保证访问数据的 ACID 原则，旧版本的数据将会在 Delta Merge 过程中被合并。

MVCC：Multi Version Concurrency Control 的缩写，中文意思为多版本并发控制。SAP HANA 使用 MVCC 来实现数据的并发访问控制。
S 锁：即共享锁，数据库系统提供的锁定机制。例如，当一个事务执行一条 SELECT 语句进行数据读取时，系统会为被选择的数据加上 S 锁，此时其他的事务都可以读取这条被加锁的记录，但是不允许对此数据进行更新，只有在读取执行完毕之后，S 锁才会被解除，真正的更新操作才能执行。

ACID：传统关系型数据库中的 ACID 理论，即事务原子性(A)、数据一致性(C)、事务隔离性(I)、事务持久性(D)。
BASE：海量数据处理下的新型数据库设计原则，即基本可用、软状态、数据一致性。
CAP：关于系统架构设计的一致性、可用性、分区容错性的理论。
事务隔离级别：SQL 标准定义的数据库隔离级别依次是 Read Uncommitted、Read Committed、Repeatable ReadSerializable。级别越高对事务处理的 ACID 保证就越高，但是也意味着数据库的并发能力越差主流数据库产品都会以自己的技术来实现这些支持级别。

行存储、列存储以及历史表

SAP HANA 采用了行列混合的存储模式，即在单一个数据库系统中，能够支持两种不同的数据存储模式。一般认为，列存储对数据的读取优于行存储，而行存储对数据的更新更加擅长。
列存储较适用于：
海量数据的统计计算和访问只会在需要访问的某几个单列中进行。
对于需要经常对表结构进行新增字段的扩展，十分灵活。
对非常多的行记录、列字段进行各种操作运算，例如进行聚合、平均等。
当最主要的列中有较多的重复的数据条目的时候，在这些列中可以对重复的数据进行非常大比例的压缩。

行存储较适用于：
应用系统在某一个时间点只处理那种单行的记录。
应用系统需要访问这一记录的所有列的信息，避免跳跃式读取，延长磁盘/内存的寻址时间。
列中包含最主要的不重复的数据。
没有快速聚合或进行快速查询的需求。
数据库表中的记录不太多的情况。

(1)行存储
在 SAP HANA 中，行存储是基于内存存储架构而设计的，这种内存行存储是特别为了高性能的并发写入数据（OLFIT 专利，后面会有详细介绍）和读取数据而设计的。举例来说，行存储用于 SAP HANA 自己的系统表，在 SAP HANA 的 SYS 这个 Schema 下面的所有数据库表，都是以行存储方式存在的，主是用来处理 HANA 系统自身的运算数据。
行存储在 SAP HANA 中被应用在数据库的元数据管理和应用服务器的内部数据管理上（例如，保存 ABAP 服务器的数据库表记录，或是系统配置的信息、内存运行期的索引结构等）​。此外，应用开发人员也可以选择将某些数据库表的类型设置为行存储方式，并且 SAP HANA 也支持行存储表和列存储表之间的 SQL Join。

(2)列存储
列存储在 SAP HANA 中一般用于保存业务数据信息，这样做是为了在压缩数据机制下获得充分的性能来支持动态聚合和海量数据瞬间计算的能力。所有和业务系统相关的数据库表都是以列存储来实现的，因为采用了只插入、异步合并和 MVCC 等机制。

tips:SAP HANA 在解决数据库写入性能上有独一无二的专利技术（国际申请：PCT/KR2002/0010602002.6.4；国际公布：WO2002/101557-英文）​，这就是优化无锁索引遍历并行控制方案。使用该方案，在索引树的每个节点中，OLFIT 方案保存一个锁、一个版本号，以及指向索引树同一级的下一节点的链接。索引遍历涉及从树根开始的一致节点读取操作。为了保证无锁条件下节点读操作的一致性，每个节点的更新操作先取得一个锁，并在该节点内容更新后增加版本号。每个节点的读取操作均从读取版本号到内存开始，并以校验当前版本号与内存中保存的版本号是否一致结束。如果当前版本号与内存中保存的版本号相同，则读取操作是一致的，否则，重新进行节点读取操作，直至校验成功。这个专利的并行控制方案适用于多种索引结构，例如适用于 B+/-树、CSB+/-树，以及各种变体。

(3)Temporal Table（历史表）
HANA 还提供了 Temporal Table（简称为历史表或临时表）这种类型的数据库表。它和普通数据库表的区别就是，所有历史表中的数据更新都不会对原始的数据记录进行真正的更新。
Temporal Table 的特点：
插入新数据记录。系统会插入新的数据。
更新旧数据记录。系统会插入更新后的数据，并且生成新版本，即使在版本合并期间的历史版本也不会被删除。
删除数据，不会删除原始的数据记录，而是插入新数据，并且在数据的“有效期至”这列中设置删除的当前的时间戳。

定义 Temporal Table 时不能指定特定的数据库主键（Primary Key）​。Temporal Table 保留原始数据记录，以及对原始数据进行的所有的数据更新操作和历史记录，这样用户可以查询到数据过去的历史状态。保存在 Temporal Table 中的数据称为最新数据，同样的，数据对象的其他版本包含着历史的数据。

用户可以使用 SQL 来创建 Temporal Table，比如通过“CREATE GLOBAL TEMPORARYCOLUMN TABLE 表名 （字段名类型） ”这样的形式。例如，通过 CREATE GLOBAL TEMPORARY TABLE TEST（A int,B int,C int）创建 Temporal Table，或者在 HANA 中使用向导创建数据库表时设置成 Temporal Table 创建 Temporal Table。

并发控制和一致性

只插入意味着数据库更新方式是通过插入新数据记录来进行的，而非直接修改原始数据库的数据记录来完成 ​。而对于数据的并发访问控制，过去基于锁机制得到很多的实现。例如，在读事务访问数据记录时，加 S 锁，写事务此时则无法对此数据进行更新，但是其他的读事务也可以访问该数据，这种机制有效地保证了一致性。但是锁机制带来的问题是，一旦锁定数据记录对象，意味着该数据被独有，直到被释放，这种方式会在一定程度上影响数据库系统的吞吐性能。当然，随着新的数据库技术的发展，因数据库锁机制而造成的数据处理延时问题也被解决了一部分，但是问题依然存在。

(1)读取不加锁
HANA 使用 MVCC 机制来保证所有数据读取的一致性。HANA 中所有的数据存储（列存储、行存储等）方式都实现了 MVCC。与传统架构中基于 S 锁的并发控制访问机制相比，HANA 提供了更高的数据并发访问，因为它允许在事务读取数据还未结束的情况下对此数据进行“更新”​（插入新版本的数据）​，因为读取类型的事务不需要去锁定任何数据记录，这样可以将系统并发能力提升更多。

事务 1 开始执行新数据的插入，在成功提交之后生成版本 1.0，然后事务 2 开始读取数据，接着事务 3 开始更新这条数据，这里是通过插入新版本的数据的方式来实现的，在事务 3 还没有结束之前，事务 4 也开始读取数据，但是由于事务 3 没有完成提交，此时事务 2 和事务 4 读取的数据版本依然是 1.0 版本。在事务 3 完成数据提交及生成新版本 2.0 之后，因为还有最后一个事务 4 没有结束读取 1.0 版本的数据记录，所以 1.0 版本的数据依然处于有效状态，等事务 4 一结束，1.0 版本的数据生命周期就结束了。之前由于 2.0 版本的数据已经产生，按照时间的顺序，新产生的事务 5 访问的数据记录是 2.0 版本，依此类推。在后续的异步数据合并中，版本 1.0 的数据会从内存中移除。接下来介绍数据合并的过程。

(2)版本合并
对于除 Temporal Table 类型以外的数据库表，同一份数据记录的所有旧版本在没有任何业务请求访问之后都将被隐藏，然后这些旧版本的数据会被删除，从内存中被释放出来。这一过程称为“列存储（使用 Delta Merge 进行合并）​”或“行存储（使用 Version Consolidation 进行合并）​”​，统一简称为“版本合并”​。
版本合并的过程并不是实时同步完成的，而是后台异步来做的。也可以通过执行一个定期的后台作业或者手动去触发这一过程。

两个重要的 ID：
事务 ID 和提交 ID。事务 ID 对应写事务开始的序列号，提交 ID 表示写事务提交的序列号，SAP HANA 中的事务管理器负责维护以上两种 ID。

• TID（Transaction ID，简称为 TID、事务 ID，列存储使用）​。
• CID（Commit ID，简称为 CID、提交 ID，行存储使用）​。

以 TID 为例子，当一个新的写事务产生的时候，系统会生成一个新的递增 TID 号码，然后将它分配给这个写事务，这个 TID 将作为此数据库事务的唯一标识符，但它仅仅只代表这个写事务在 SAP HANA 中的事务顺序而已。CID 和 TID 很类似，用来表示一个写事务提交序列。SAP HANA 中的事务管理器内部保存着最新一个 CID，也就是系统中最近的一次写事务 CID。在一个事务被成功提交后，这个最新的 CID 号被自动递增，然后这个新 CID 被分配给已提交事务。CID 对应这一个事务当时提交的时间戳，而事务管理器维护着 CID 和时间戳之间的对照表。
事务管理器维护着 TID 和 CID 的一对一映射关系。

版本合并和存储方式：
因为在 HANA 中支持行、列两种存储方式，所以不同的数据存储方式在版本合并上的操作是不同的，但是都是由事务管理器（Index 服务器的功能组件）这一组件来负责哪些数据版本需要在合并的过程被删除。行存储的数据库表在合并过程中使用提交 ID 来进行版本合并，而列存储的数据库表则使用事务 ID 来决定对哪些数据版本进行合并。

写入时锁：
SAP HANA 在数据行使用排他写锁（Exclusive Write Lock）​，对于每一次的数据写操作，当前请求会获得一个数据行的写锁，对同一份数据的并发写操作必须等待其他的写锁被释放。前面介绍了只插入，这种方式可以实现数据的更新。SAP HANA 也提供了应用层的手动请求写锁方式，比如在 SQL SELECT 语句的后面增加 FOR UPDATE 可以进行排他锁定，从而防止其他用户同时对这条数据进行修改。即使发生死锁现象，系统的事务管理器会实时监测到是否相同的数据上存在死锁，然后自动终止其中一个事务。

数据更新

1、列存储
在列存储方式下，对表中的数据进行更新（增加、删除、修改）是不会直接修改物理的最原始的记录的。更新操作总是先插入一条新版本的数据记录到内存中，然后在后台通过定期的版本合并来完成对数据的真正更新。
（1）列存储下的两个数据存储区域

• Main 内存区域，所有数据的最原始的存储区域。例如，初始化导入到 HANA 中的采购订单信息，经过第一次 Delta Merge 之后就常驻在 Main 内存区域中。
• Delta 内存区域，所有最近的数据更新都会写入到这个区域中。例如，对过去某个采购订单的数量、金额、送货地址 3 个字段信息进行修改，修改过的信息和未修改的字段信息会形成一条新的记录，然后将其插入到 Delta 内存区域。

（2）列存储的一致性视图
Delta 和 Main 内存区域什么时候开始进行合并呢？用户可以在 HANA 中设置两个区域合并的技术参数，如合并频率、触发合并的事件、使用多少系统线程进行数据合并、是否自动合并、自动合并开始的阈值、是否使用智能合并功能等。

（3）Delta Merge
HANA 中的数据更新是通过只插入的机制来实现的，因此，Delta 内存区域和 Main 内存区域之间的合并过程可以称为 Delta Merge。
将 Delta 内存区域中收集的更新数据移动到 Main 内存区域中，因为 Main 内存区域的数据经过轻量级数据压缩（数据字典替换和长度压缩）​，而且有助于读取优化。

Main 内存区域和 Delta 内存区域在数据进行合并前后的 3 种状态：

• 合并前（Before Merge）​，所有读取数据的操作总是会从 Main1 和 Delta1 区域读取，所有的数据更新操作记录都会被写入 Delta 内存区域。

• 合并中（During Merge）​，所有数据的写入操作都保存在 Delta2 这个新的增量区域中。所有数据读取操作则从 Main1、Delta1 及 Delta2 中去读，保证数据访问的一致性。
  Delta1 区域中没有来得及提交的事务将被复制到 Delta2 区域中，然后系统会重新开辟一块主存储区 Main2，接下来将 Main1 中的全部数据和 Delta1 中的已经提交事务的数据进行合并，保存在 Main2 这个新主存储区域中。
  对于非 Temporal Table 类型的数据库表而言，合并操作会删除所有多余版本的数据，使数据的状态变成最新状态。对 Temporal Table 来说，合并操作会将数据库表中记录的一些旧版本移动到 Temporal Table 的 Main 存储区域中。

• 合并后（After Merge）​，一旦新的 Main2 和 Delta2 开始负责数据读取和写入，就意味着新旧存储区域已经切换完毕。然后，新的 Main2 和 Delta2 中的数据内容将被写入到持久层的虚拟日志文件中（可以看成闪存）​，随后通过异步方式写到磁盘中。此时旧 Main1 和 Delta1 将被系统从内存中删除。所以，无论如何，在某个时间点，新旧的存储总会同时存在一会儿，这需要系统拥有足够大的内存空间对数据进行这种合并操作。

2、行存储
HANA 中的行存储是基于内存计算技术的，也是为高并发的读写而设计的。和列存储一样，行存储使用 MVCC 来实现数据库的事务隔离。因为 HANA 的行存储是为了最大化利用多核的并发计算能力和基于内存技术而设计的，所以行存储数据表的索引（HANA 中的行存储需要配备索引）也全部都是保存在内存中的。和列存储的 Main 内存区域和内存 Delta 区域类似，行存储也使用两块存储区域来保存数据，如下：

• Segment 区域，保存行存储数据库表的数据文件。
• Transactional Vision Memory 区域（简称 TVM 区域）​，保存那些需要被合并的数据版本。

聚合或 SQL

在 HANA 中，所有多维度的分析和计算处理都是实时通过 SQL 完成的，基于任何一个数据模型的分析查询，无论使用多少维度，钻取分析有多少层，都不需要事先计算好各个维度的结果集。

数据分区

SAP HANA 对于分布式环境下的数据分区提供了两种方式：

• 不同数据库表分布在不同的服务器上。例如，服务器 A 处理销售类的数据库表，服务器 B 存放关于库存类的数据库表，服务器 C 则处理财务相关的数据库表。当然，用户在后期也可以不断调整数据的分布，以达到最佳的系统资源利用率。
• 数据库表被水平切割，并分布在不同的服务器上。分布式 HANA 环境下的每个服务器节点的 CPU 只处理分布在本地内存中的数据，然后将不同服务器计算好的中间结果汇总。

最小化传输数据

HANA 的一个特点是可以将数据的传输做到最小化。我们使用应用层支持的编程语言（例如 C/JAVA/.NET 等）在应用系统的内存中进行数据处理、基本筛选、各种运算等，必要时还需要将新产生的数据写回数据库中。
传统的应用系统开发模式大体如上，数据计算的大部分工作基本都在应用层解决，这就对应用服务器的性能提出了很高的要求，如运算能力强、高可用性、支持高并发等。而 SAP HANA 的出现将改变这种传统的计算方式，用户可以将应用层中的很多计算逻辑、表间关联、取数逻辑在 HANA 中实现，这样数据库返回的仅仅是计算好的结果，或是已经完成了大部分计算的结果集，这样从数据库传输到应用层的数据就会大大减少，网络传输时间变短，系统响应的时间变快，最终整体性能得到提升，同一时间内可以支持更多并发访问。以 ABAP 编程语言为例，一般性的应用可能都包含数据查询、更新等。开发人员可以使用程序运行期分析工具对这个程序的执行时间进行整体分析，从而可以清楚地知道数据库整体开销时间以及程序自身多消耗多少时间。然后将 ABAP 中耗时的数据读取逻辑和计算逻辑在 HANA 中实现，之后直接使用 ABAP 去读取 HANA 中结算好的结果集，再用程序测试工具来对比，能够发现 ABAP 在数据库读取和在应用层计算的时间都明显减少，而且整体执行时间也明显缩短。

并行处理

并行处理的目的是为了最大化地利用所有能够使用的计算资源，从而达到负载均衡，进而支持更多的并发访问来提升系统的整体处理效率。SAP HANA 是基于 Intel 多核 CPU 架构的，这使得并行处理数据变得相对简单，因为列存储采用垂直分区（类似 Table Partition，即表分区）​，这就意味着不同列的数据可以很轻松地并行处理。

SAP HANA 架构

SAP HANA 及相关外围系统

(1) SAP HANA 工作台对于现在看到的 SAP HANA 工作台，用户可以使用这个工作台进行 HANA 建模、系统日常管理和监控等操作。这个客户端软件将应用开发和系统管理集成在一起，所以用户在使用的时候只需要切换到不同的视图即可。

(2) 数据展现和访问接口
作为 SAP HANA 认证的 BI 工具之一，SAP BI 提供了丰富的数据分析工具和方法，帮助企业用户从 HANA 的海量数据中实时挖掘出支持企业运营和决策的信息。SAP BI 之所以提供了不同的工具来展现这些数据，是因为这些信息所面向的人群不同，例如针对企业的管理层，使用 Dashboard 方式展现企业的经营状态报表，而针对于高级的业务分析师，可以使用 Explorer 或 Web Intelligence 来展现报表。如果用户不考虑使用 SAP BI 作为 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) 对数据源的支持
SAP HANA 支持所有的主流系统的数据源。对于 SAP 系统而言，可以使用 SLT（SAP Landscape Transformation）和 Data Services，以及 DXC 的方式进行数据复制。对于非 SAP 系统的数据源，同样也可以使用 Data Services 和 SLT 进行数据的抽取。
如果数据源是普通的 CSV 文件，可以使用 HANA 的工作台，或者使用 IMPORT 命令直接上传这些数据到 HANA 中，然后在 HANA 的建模工具中直接预览这些上传到 HANA 中的数据。

SAP HANA 系统

SAP HANA 系统由 6 个主服务组件构成。在这些服务中，最常见服务组件应该是 Index Server（索引服务器）​，其中包含了数据的实际存储和处理数据的引擎等几个重要部分。
在 SAP HANA Studio→Landscape 标签页中，用户能看到当前 HANA 系统所有运行的服务进程。能看见有很多个服务正处于运行状态，同时也可以看到每个服务所占用的系统资源等信息。

SAP HANA 服务组件中，Name Server 相当于整个 HANA 数据库系统环境中的“通信员”​，通过 Name Server 可以知道当前 HANA 服务器的部署情况。
例如，在分布式的 HANA 环境下有多个 HANA 服务器节点，而 Name Server 知道当前哪个节点运行正常，以及哪些数据分布在哪些节点上。XS Server 可以将持久层的数据模型封装成 HTTP 的方式供外部使用，而且它还具有对这些发布出去的服务进行搜索的功能，并且内置一个应用服务器。
Statistics Server 负责收集所有数据库组件运行的状态、执行效率和资源的消耗状态，还监控 HANA Studio 的访问，并且返回不同的提示信息给登录的用户。SAP HANA 数据库底层是使用 C++开发的，目前的版本是运行在 SUSE Linux 操作系统之上：

• Hdbnameserver：Name Server（名字服务器）​
• Hdbindexserver：Index Server（索引服务器）​
  对于外部应用客户端来说，系统每次接收到的用户请求都会在连接和会话管理中得到处理，连接和会话管理会帮忙建立一个用户会话和数据库连接，然后客户端的软件就可以使用 SQL 语句与 SAP HANA 的数据库进行通信。例如，MS-Excel 通过使用 ODBO 进行数据源连接，使用 MDX 接口和 SAP HANA 的数据库进行通信。
• Hdbstatisticsserver：Statistics Server（统计分析服务器）​
• Hdbpreprocessor：Pre-processor Server（预处理器服务器）​
• Hdbxsengine：XS Engine（XS 引擎或 XS Server）​
  XS Server（过去的名称为 XS Engine）是 SAP HANA 中一个非常重要的组件。XS 是 Extended Application Services（扩展应用服务）的缩写，从“应用服务”可以看出，SAP HANA 的 XS Server 专注于实现用户应用，在 HANA 系统与最终用户之间的人机交互方面提供了更多选择。
  XS Server 内置了一个轻量级的 Web 应用服务器，不需要其他任何额外的软件即可在 SAP HANA 上实现 B/S（浏览器/服务器）应用。打开 SAP HANA 的“黑盒子”​，可以发现，HANA 上的 B/S 应用的工作原理与“三层架构”对应：
  1、数据存储层。Index Server 负责处理应用执行过程的所有数据查询及更新等操作，内置的 OLAP、计算引擎可以高效地执行数据密集型操作。
  2、应用层。在 XS Server 中，开发人员可以使用多种方式，把用户和 HANA 中的业务数据真正关联起来。例如，当业务逻辑非常复杂时，可以使用 JavaScript 等脚本语言进行服务器端应用开发。3、展现层。从传统的 HTML，到最新最流行的 HTML5，均可在 XS Server 中开发部署。
• Hdbdaemon：以正确的顺序开始或停止其他进程

SAP HANA 的开发接口

1、SQL 和 SQLScript
2、MDX
3、REST Service 和 XS Server
4、HANA Client Libraries

分布式 SAP HANA 系统

使用共享存储实现 Scale-Out 和 HA（物理或虚拟化）：

在分布式 HANA 数据库环境下，一个整体 SAP HANA 数据库系统一般可以由多台 HANA 数据库的服务器节点组成，而且是统一管理的。系统的不同组件都能看到来自外部的客户端软件的请求，而且在数据库层面共享一组元数据，每次来自客户端的请求都能被分配到不同的服务器中，这样的场景依然被认为是一个数据库系统，和 SAP 的其他产品一样，通过统一的 SID 来进行标识。
这个 SAP HANA 数据库实例（Instance）有 3 个不同的服务器，而且都安装在不同的物理服务器上，每个实例都有自己的 Index Server、Pre-processor Server 等，但是只有服务器 A 中才有 XS Server 和 Statistics Server，并且一个 SAP HANA 数据库系统范围内只会有一个这样的服务器存在，这个服务器 A 有点类似一个主服务器，用于监控和调度各个服务器之间的计算汇总和处理任务等，这是 SAP HANA 最典型的分布式数据库系统。

分布式的系统架构是为了解决单个物理服务器计算资源限制的一种架构，反映在 SAPHANA 上则是可以提升整体的内存容量、计算能力，以及可以避免单点故障等。在分布式的环境下，为了实现最好的运行性能和负载均衡，在每个服务器节点上都会运行 Index Server 及其相关的服务组件。

HANA 中的横向扩展和防止单点故障是如何实现的：
在持久层方面，所有的服务器都安装和运行在同一个共享存储上，但是每个服务器都有自己独立的内存、闪存和处理器资源。
每个独立的服务器节点都运行着一个 HANA Host（每新加一个服务器节点，就会在这个服务器节点上安装一个 HANA 软件）​，而且每个服务器节点上都有自己独立的 Index Server、Name Server 等，在一个集群环境中可以定义 3 个 Master Name Server，但是同一时间点只会有一台 Name Server 成为活动的 Master Name Server，另外两个则处于随时替代的状态。
所有服务器节点的故障侦测工作是由处于 Active 状态的 Master Name Server 来监控完成的。

SAP HANA 应用场景

数据集市和实时报表

SAP HANA 作为一个高性能的内存计算平台，没有传统数据集市的“预先计算”过程。用户访问的结果都是在内存中实时计算得出的，不需要在聚合层的中间存储，这使得在 SAP HANA 上进行数据建模变得非常简单和灵活，无论是对模型的重新动态聚合，还是增加和更新维度等操作，都没有传统 EDW 的数据重新计算和聚合的过程。
一些客户在使用 SAP HANA 之前，也使用过一定数量的数据集市，这些数据集市都是基于传统关系型数据库创建的，并且使用 SAP BI 作为信息建模和展现平台。
这类企业用户使用 SAP HANA 替换原有的数据集市，但是出于项目实施周期性能提升等方面的考虑，并未在 SAP HANA 中进行建模，而是继续沿用 SAP BI 作为建模和展现平台，这其实是将 SAP HANA 当做一个高性能数据库使用而已。
因为在使用 HANA 替换原有关系型数据库之后，已经整体提升了数据集市的性能，所以很多原来在 SAP BI 层面创建的模型并未在 HANA 中重新实现。只有在业务场景性能提升有限的情况下，才会考虑在 HANA 中重新建模。
举例来说，能源企业在智能电表、电网系统、计费和分析系统中应用 HANA 去实时分析城市每个区域的电力消耗和供应的关系，将这样的信息投射到 GIS 上，以便于降低企业的运营成本。

企业级数据仓库

HANA 除了作为一个敏捷数据集市之外，还可以作为新一代的企业级数据仓库的平台。而海量数据处理是 SAP HANA 最为擅长的操作之一。SAP HANA 按照企业的需求和具体的应用场景可以有多种实现方式。用户可以使用以下方案来搭建企业级数据仓库：
1、BW on HANA；
对于建立一个企业级数据仓库来说，除了底层的数据库，还需要上层应用的支持，那就不得不提到 SAP NetWeaver BW（下文简称 SAP BW）这个产品。SAP BW 是对 SAP Business Suite 支持最全面、最强大的数据仓库产品。SAP BW 中还内置了一整套的业务内容（BI Content）​，同时也集成了 SAP 过去 20 多年的最佳业务实践。
2、SAP HANA，附加 SAP Sybase IQ、HBase、Hadoop 等用于存储冷、温数据和非结构化数据。

传统企业级数据仓库架构和以 SAP HANA 作为基础的企业级数据仓库的区别：
1、传统企业级数据仓库的临时表
基于传统关系型数据库的企业级数据仓库，在从原始数据的抽取到根据不同业务需求创建不同的数据模型的过程中，会生成大量的聚合层数据，也就是说，按照详细的需求，针对业务需要处理的分析维度和指标来生成预先计算好结果的“临时表”​（或称“聚合表”​）​，这个临时表会经过源数据的抽取、建模、转换和计算后最终生成。
2、HANA 虚拟模型实现动态聚合

SAP HANA 基础知识

实施 SAP HANA 前的准备工作

（1）基础架构和应用部署方面

• HANA 在企业应用中的定位。
• 需要放入到 HANA 的数据量、增长率、扩容、硬件配置、并发访问数量。❏ 采用单节点还是集群方式，因为直接关系到硬件方面的部署方式。
• 是否考虑 High Availability（高可用）和 Disaster Recovery（灾备）等方案。
• 数据量太过庞大，以及考虑投资，是否需要采用 SAP Sybase IQ 存放“冷或温数据”等。

（2）数据加载方案方面

• 数据源的类型和数量。
• 多少业务场景的数据需要实时同步到 HANA，每天产生的增量数据有多少。
• 多少业务场景采用 ETL 工具进行定时抽取，采用何种增量抽取方式。
• 是否需要在 ETL 工具中进行数据的清洗和转换工作。

（3）数据模型的实现方面

• 如果企业现有的数据仓库或数据集市系统采用的是 BI+RDBMS 方式，那么在使用 HANA 之后，是否保留全部原有模型，只把 HANA 当做一个高性能数据库使用。
• 如果有的模型不做任何改变，效率提升不高，那么是否考虑在 HANA 中创建模型，今后开发新应用是否全都在 HANA 中建模。

（4）数据展现和 ERP 集成方面

• 采用何种商务智能软件来展现数据。
• 自行开发的 BI 平台基于什么数据接口。
• 是否采用 SAP HANA 加速器方式。
• 是否考虑迁移到 Business Suite powered by SAP HANA。
• 新开发的 ABAP 应用程序是使用 Open SQL 还是 Native SQL。

（5）系统的监控和备份恢复等方面

• 是否将 HANA 监控集成到 Solution Manager 的 DBACockpit 中。
• 是否考虑使用第三方的数据备份恢复软件。

软件安装

SAP HANA 软件的 3 个核心组件：
SAP HANA 数据库（SAP HANA Database）：SAP HANA 核心组件，支持数据库对象行存储和列存储。内置 SQL、MDX、OLAP、计算和计划等多种引擎，为不同的应用场景自动选择最佳的操作引擎，提供最优的性能。
SAP HANA 工作台（SAP HANA Studio）：HANA 顾问、系统管理员均可使用工作台集成开发/管理工具完成各类数据库(包括但不限于表、视图、存储过程等)的创建、数据建模，以及 HANA 系统配置、监控、管理等工作。
SAP HANA 客户端（SAP HANA Client）：HANA 支持的多种数据库接口驱动的集合。上层应用/分析工具可通过相应的接口访问 HANA 数据库。

SAP HANA 是一体化设备，也就是说，SAP HANA 数据库软件必须安装和运行在 SAP 认证的硬件上，并且服务器的操作系统也是固定的，即采用 Novell SUSE Linux Enterprise11 SP1 版本。这台一体化设备为企业的海量数据提供了高性能的、基于内存的数据存储及运算平台。外部应用访问 HANA 中存储的数据或运算得到的结果时，需要使用 HANA 提供的驱动程序，这些都是 SAP HANA 客户端提供的，因此需要在外部应用的服务器（如 SAP BusinessObjects（BO）BI 商务智能套件的应用服务器）上安装 SAP HANA 客户端软件。

参数：
System ID（系统 ID，SID）是３位字符组成的系统标识符，首字符必须为字母，后两位可为字母或数字。该系统标识符主要用于为 SAP 系统命名，因此必须保证唯一，尤其是当企业拥有多套 SAP 系统时。
Instance Number（实例号）和登录端口有关。如果选择 00，在连接 SAP HANA 时端口号则是 30015，SID+Instance Number 组成一个唯一的 SAP HANA 环境。
Installation Path（实例路径）是 SAP HANA 数据库系统安装路径，推荐采用默认路径/usr/sap。
Restart instance after machine reboot：如果选择 Restart instance after machine reboot（服务器重启后重启实例）复选框，则每次服务器重启后，SAP HANA 数据库也会自动启动。
User Name 和 Password，是 HANA 实例管理员用户和密码。在安装 SAP HANA 时，默认会在 Linux 系统中创建一个系统管理员，用户名称是ADM，前面指定了这个 SAP HANA 的 SID 是“HDB”​，因此当前安装的这个 SAP HANA 系统的 Linux 系统管理员名称就是 HDBADM，在登录到 Linux 系统中进行 HANA 系统重启、停止操作时会用到这个用户。
System Administrator Login Shell（系统管理员登录的 Shell）用于设置当前 SAP HANA 系统管理员的登录路径。
System Administrator Home Directory（系统管理员的主目录）用于设置当前 SAP HANA 系统管理员的主目录。设置了此目录后，使用 SIDADM 登录到 Linux，系统将自动切换到此目录下。

在上面的步骤中输入ADM 的密码之后，其他信息不需要修改，然后单击“Next”按钮，进入下一步，此时安装向导提示用户输入 HANA 数据库系统的数据和日志文件的保存路径。
Location of Data Volumes（数据文件的路径）是指 SAP HANA 的数据文件的保存路径，通常都在磁盘存储层上。例如，在加电重启操作系统和 SAP HANA 时，SAP HANA 会访问磁盘，将数据从磁盘读取到内存中。
Location of Log Volumes（日志文件的路径）是指 SAP HANA 的日志文件的保存路径。在看到这里的内容之前，读者应该了解 SAP HANA 正式生产环境的硬件服务器都提供 Fusion-IO 卡或 SSD 固态硬盘，在 HANA 中对数据的任何修改都会同时写进闪存（日志）和内存（数据）中，只有这两者都保存成功，数据的修改才算提交成功，而这里的日志文件必须写在 Fusion-IO 卡上，因为它提供了相对传统磁盘更快的读写速度。
在 SAP HANA 的硬件服务器中，存放日志文件的总体存储空间一般由多块 Fusion-IO 卡共同组成，比如 1TB 的空间是由多块 320GB 的 Fusion-IO 卡组成，在操作系统层面合并成一个虚拟盘，当然现在也有一些单块卡也能达到 1TB，而且不需要通过软件进行虚拟的合并。

在默认情况下，如果用户不做任何修改，数据文件和日志文件都将保存在本地磁盘路径中，在 SAP HANA 生产环境安装情况下，用户需要修改默认的路径，并且在安装 SAP HANA 之前配置好相应的数据文件和日志文件的挂载点。
SYSTEM 用户是 SAP HANA 系统管理员账号，首次使用 SAP HANA 工作台访问 HANA 数据库时，需要用到这个用户，这和前面的ADM 这个操作系统层面的管理员账号是不同的。例如，用户可以直接使用ADM 账号登录到 HANA 服务器的 Linux 操作系统，然后执行系统的重启、停机等操作。

SAP HANA STUDIO 使用

SAP HANA 工作台提供了以下 3 类视角：
建模视角（Modeler Perspective）；
管理控制台视角（Administration Console Perspective）；
生命周期管理视角（Lifecycle Management Perspective）；

建模工具

SAP HANA STUDIO 协助用户进行应用系统搭建所需的所有数据库开发工作，例如，最常使用的 SQL 查询、创建数据库表、信息建模（即创建列视图）​、开发存储过程等。
SAP HANA 开发对象列表:
（1）Catalog 节点：包含了所有信息模型激活后所生成的对象。此外，展开 Catalog 节点还可以浏览其他数据库标准对象，如数据库表、权限对象等。
Users 即 HANA 系统的访问账号，首次登录 HANA 系统只能使用安装时设置的 SYSTEM 账号，之后可在 Users 中创建新的账号并分配特定的权限。
Roles 是一系列有相关性权限的角色的集合。在创建用户时为其分配角色，该用户即拥有相应的权限。
EFASHION_TUTORIAL 是 HANA 中一个例子 Schema 的名称。Schema 与 Oracle 等数据库中的表空间有相似之处，逻辑上拆分了数据库表等对象。例如，不同 Schema 下可以存在同一名称的数据库表。但是 Schema 并未真正关联实际存储空间。
Column Views，列存储的数据库视图。
Procedures，存储过程。
Table Types，定义了可作为存储过程输入/输出参数的表格类型。
Tables，HANA，数据库表，既可有传统行存储的表，也可以有列存储的表。
Views，数据库视图对象，如传统的行存储的数据库视图。

（2）Content 节点：外部应用不会直接访问 Content 节点下的对象，这些对象只是 HANA 中模型的定义信息，它访问的是模型激活后所生成的实体，如列视图、存储过程等。

管理工具

“Landscape”选项卡，可以监控 HANA 的系统服务。
SAP 系统管理员可以在不重启系统的情况下，在 RZ11 中修改部分系统参数，这样会立即影响系统行为；也能在 RZ10 中永久修改系统参数。
“Configuration”选项卡中，采用树状结构的方式显示了所有系统配置相关的参数，修改其中任意参数的值即可改变系统表现的行为。
indexserver.ini 节点，再展开下级的 password_policy 节点，可以找到多个与用户密码相关的系统参数。例如，设置 force_first_password_change 参数值为 true，可以强制要求用户在使用新的用户名登录系统时，必须修改 HANA 用户的初始密码。

数据库表

对于存在于 SAP 系统中的数据，可以使用 SLT、Data Services、Sybase Replication Server 等多种方式将其抽取到 SAP HANA 中，还可以基于 SAP 系统应用层的 Data Source、Function Module 等进行数据抽取。
同一个 HANA 模型用到的不同的数据库表，可以来自不同的 Schema，也可以使用不同的数据抽取方式。
在 HANA 中，数据库表的同步方式与数据抽取策略相关，而数据抽取策略取决于业务需求。例如，如果希望实时查看库存信息，那么对与库存相关的数据库表就要使用 SLT 实时数据复制技术。
在 HANA 工作台中进行建模时，虽然可以从多个不同的 Schema 引用所需的数据库表，但是为了便于管理和运维，建议将相同业务场景所使用的数据库表放在同一个 Schema 下。

TPC（Transaction Processing Performance Council，事务处理性能委员会）是业界公认的用来测试数据仓库性能的基准，它是非常公正和中立的一个平台，而 TPC-H 是基于这个而衍生出来的测试数据仓库性能的基准版本。根据统计，目前几乎所有的数据库产品都在这个模型之上完成过各种各样的性能测试。在 TPC-H 模型中一共定义了 8 个数据库表：
Order 销售订单的基本信息清单表(事实表)
Lineltem 销售订单的行项目清单表(事实表)
Customer 客户信息主数据(维度表)
Nation 国家代码主数据，例如美国、中国、日本(维度表)
Region 地区代码主数据，例如亚太区、北美(维度表)
PartSupp 可用于销售订单的部件主数据(维度表)
Part 销售订单中包含的所有部件主数据(维度表)
Supplier 销售订单中包含的所有部件的供应商的主数据(维度表)

加载数据到 SAP HANA

SAP HANA 支持的所有的数据加载方式：

1、利用标准接口 JDBC、ODBC 或者 Python 等向 HANA 中写入数据。例如，HANA 工作台中的 Import 就是通过 JDBC 来访问 HANA 的。
2、DXC 方式，基于 SAP 应用层的加载技术，基本原理是利用系统中内嵌的 BW 的 ETL 功能，从 SAP 系统中预置的数据源（Data Source）对象抽取数据。
3、数据服务是一个标准 ETL 工具。DS 支持超过几十种不同类型数据源，是和 Informatica、Data Stage 类似的通用型 ETL 工具。
4、SLT，基于触发器技术的实时同步方式，它对 SAP Basis 系统版本的支持从 4.6C 开始至最新版本。
5、SAP Sybase ESP，是通过事件流处理器这个软件将来自外部感应器的数据、事务交易、事件等信息实时传输到 SAP HANA。和数据服务不同的是，ESP 本身不是一个标准通用 ETL 数据加载工具。在当前客户的系统环境中，如果正在使用 ESP 方案，而且这些数据也需要在 HANA 中进行处理，可以直接使用 ESP 将这些数据传输到 HANA 中。
6、SAP Replication Server，简称 SRS 或复制服务器，Sybase Replication Server 是其前身。通过 Replication Agent 实时捕捉源系统中的数据库日志和提交的事务并传输给 Replication Server，然后 Replication Server 将恢复成可执行的 SQL 语句传输给 ECDA 组件，因为 ECDA 和目标数据库（例如 SAP HANA）是通过 ODBC 相连的，故发送给目标数据库（例如 SAP HANA）去执行这些 SQL 语句。相比基于触发器技术的 SLT，使用 SRS 对源数据库系统压力比较小。

关于 Schema

HANA 使用 Schema 来对数据库表进行隔离和区分。和其他数据库中的“Schema”这一术语相比，HANA 中的 Schema 更像是一个“数据库”的概念。每个 Schema 都有自己的拥有者，以及对这个 Schema 下数据库表进行各种操作的权限合集。每个 Schema 都是一个独立的命名空间，数据库表能够存放在这里，用户还可以创建新的存储过程、索引、触发器、数据库视图等对象。

Tips：SAP HANA 系统自带了多个 Schema（如 SYS、SYSTEM）​，用于存放系统本身的数据库表及其他标准对象。通常，不建议用户使用（例如，放入用户自己的数据库表和视图）系统 Schema。当用户需要自己创建数据库对象时，建议用户创建新的 Schema。

创建 Schema：
1．使用 SQL 代码以 SYSTEM 用户登录 HANA 系统，然后在 SQL 编辑器中输入：CREATE SCHEMA HANA_TPCH
单击鼠标右键并利用“刷新”选项来刷新用户导航区的 Catalog 文件夹，新创建的 HANA_TPCH 立即显示出来。

2．使用 HANA 提供的向导工具
使用向导方式来创建一个 User，同时系统会自动创建出和该用户相同名称的一个 Schema。
在创建 HANA_TPCH 用户时，系统会创建一个同名的 Schema，又称 HANA_TPCH，这个 Schema 的所有者为 HANA_TPCH 用户。

使用 IMPORT 命令

使用 IMPORT 向导工具从本地加载数据:
即依次单击 HANA 工作台的 Menu→File→Import 选项。在“Import”窗口中，展开文件夹“SAP HANA Content”​，然后选择“Data from Local File”​.
Source File，本地 CSV 数据文件的位置和路径。
Field Delimiter，CSV 文件的分隔符，在本例中使用逗号作为不同数据列的数据分隔符，例如有的 CSV 文件使用$、&、#等作为数据的分隔符。
Import all data，是否导入全部数据。
Start Line 和 End Line，可以选择导入数据的起始行和结束行。
Target Table，是导入到新创建的数据库表中，还是将数据导入到已有的 Schema 下的某个目标数据库表中。

使用 IMPORT 命令从服务器端加载数据:
使用 SQLScript 的 IMPORT 命令从服务器来加载数据，用户需要事先将数据文件上传到 HANA 服务器端的某个临时目录下。以下是 IMPORT 命令的 SQL 语法:
IMPORT FROM[文件类型] <文件路径> [INTO<数据库表名>] [WITH<导入命令的参数>]

文件类型，这里的参数值是 CSV FILE 或 CONTROL FILE。
文件路径，数据文件存放在 HANA 服务器端的 Linux 操作系统下的绝对路径和文件名。采用“/usr/tmp/xxx.csv”格式。❏
数据库表名，数据文件导入的目标表，一般采用“Schema 名称.数据库表名”格式。
导入命令的参数，在使用 IMPORT 命令加载数据时，可以附带指定一些参数，以下就所有可用的参数介绍:
THREADS<线程数量>，可以指定用于并发导入数据的线程数量，默认是 1 个进程，但是最多可以指定 256 个。线程越多，CPU 利用率越高，导入数据的速度就越快。
BATCH<每次事务提交的记录数>，指多少条记录执行一次数据库事务提交动作。使用 THREADS 和 BATCH 可以达到最佳的数据导入性能，一般建议设定 10 个并发，然后超过一万条记录执行一次 COMMIT 动作即可。
TABLE LOCK，是否快速锁定 Column 表。
NO TYPE CHECK，不执行导入数据的类型匹配检查。
SKIP FIRST<跳过多少行>ROW，忽略多少行数据记录，不导入。
RECORD DELIMITED BY’分行符 ‘ ，数据行结束的标识符，默认是\n。
FIELD DELIMITED BY’分隔符’ ，列分隔符。

IMPORT FROM CSV FILE ‘/tmp/downloads/NATION/data.csv’
INTO “HANA_TPCH”.”NATION”
WITH RECORD DELIMITED BY ‘\n’
FIELD DELIMITED BY ‘,’
THREADS 40
将数据从 HANA 服务器的/tmp 目录中的一个 CSV 文件加载到 HANA_TPCH 这个 Schema 下面的 NATION 数据库表中，其中数据行以回车符\n 作为换行标志，每一行以逗号来分割数据的字段，并且开启 40 个并行进程进行数据的加载。

使用 SLT

SLT 是 SAP TDMS 软件的一个功能组件，用于进行 SAP 系统之间的精准数据复制。SLT 基本原理是通过在源系统的数据库表中创建对应的触发器，然后利用新增数据日志记录器等组件将源系统中的数据更新实时传输到 SAP HANA 中。SLT 支持非 SAP 系统和 SAP 系统作为数据复制的源头系统。

基本原理

SLT 是 SAP TDMS 软件的一个功能组件，用于进行 SAP 系统之间的精准数据复制。SLT 基本原理是通过在源系统的数据库表中创建对应的触发器，然后利用新增数据日志记录器等组件将源系统中的数据更新实时传输到 SAP HANA 中。SLT 支持非 SAP 系统和 SAP 系统作为数据复制的源头系统。
安装方式：
（1）将 SLT 安装在一台独立的服务器上：SAP 建议用户将 SLT 独立安装在单独的服务器上。STL 作为源 SAP 系统和 HANA 之间的一个桥梁，进行实时数据的复制工作。
（2）将 SLT 作为一个组件安装在源 SAP 系统中： SLT 将使用源 SAP 系统的计算资源，包含 CPU、内存资源等，并且占用源 SAP 系统（事务代码 SM50）中的一部分后台进程用于实时数据同步、实时监控等操作。

SLT 场景演示

使用 DS

传统的 ETL 采用数据批量处理的方式，定期执行后台作业。数据从多个业务系统中抽取出来，并进行必要的处理（例如转换、合并、过滤清洗等）​，然后再加载到分析系统中。
前面介绍过的 SLT 的数据同步是以数据库表为单位的，在源端和目标端两个结构相同的数据库表之间采用一对一方式进行数据复制，且不提供额外的复制转换机制，因此并不属于一个标准的 ETL 工具。当数据源为 SAP 应用系统，而且分析结果需要反映出当前时间点在源系统中的所有最新业务数据时，SLT 是不二之选。除此之外的其他任何业务需求都推荐采用 ETL 方式，从种类繁多的源系统中抽取数据，然后将其转换并最终加载到 HANA 中。
SAP BusinessObjects Data Services（DS）4.0 / 4.1 是通过 SAPHANA 认证的 ETL 工具。

数据加载方式小结

SLT 是从源 SAP 系统实时加载数据的最佳方案，但是从源系统中执行数据复制的数据库表的数量需要加以控制，否则容易造成触发器大量滥用，从而对源数据库系统造成巨大压力。建议对需要进行数据加载的业务场景做优先级区分，只有对实时性要求较高的场景，才考虑使用 SLT 方式进行数据的同步加载，并且 SLT 所在的服务器配置的后台进程和服务器硬件 CPU 核数比例要适当。
数据服务（DS）是最佳 ETL 工具，并且可以完成非常复杂的数据转换、清洗及合并工作，基本上支持所有 SAP 系统和非 SAP 系统。
而 DXC 的方式可以较好地重用 SAP 系统中的内置标准数据源、业务逻辑，可以为用户节约大量的时间，无须找到每个所需业务数据真正的后台的数据库表及其字段。

SAP HANA 建模入门

HANA 工作台为 Attribute View（属性视图）​、Analytic View（分析视图）及 Analytic Privilege（分析权限）的创建提供了完全图形化的用户界面，还可以以写脚本（代码）的方式开发 Procedure（存储过程）​。另外，Calculation View（计算视图）会比较特殊，既可以在图形化界面中完成操作，也可以选择编写脚本的方式。

建模准备

分解 TPC-H

TPC-H 模型中包含了记录交易信息（即销售订单相关）的两张事实表，与它们相连的还有 6 张维度表。仿照 ROLAP（Relational OLAP）中的星形模型，可以在 HANA 中创建如下模型：

• 把客户主数据、国家、地区等数据库表关联起来构成 1 张属性视图，从而允许用户从客户或者销售区域的维度对订单数据进行分析。
• 把部件数据、部件主数据、供应商主数据关联起来构成 1 张属性视图，从而允许用户从部件或者供应商的维度对订单数据进行分析。
• 销售订单和订单行项目关联在一起作为事实，并与前面两个属性视图一起构成分析视图，从而组成一个“星形的”对销售订单进行分析的 Cube。

建模用户授权

所有 TPC-H 的数据库表都保存在对应 HANA_TPCH 用户的 Schema 中；而 MODELER_A 则是接下去即将创建的建模账号名称。
“MODELER_A”的权限分为两块，其一是使用 HANA 工作台的建模工具来创建、修改和删除 HANA 模型的权限；另外，由于示例中的模型会基于“HANA_TPCH”Schema 中的数据库表，因此“MODELER_A”需要拥有对这个 Schema 的访问权限（即 HANA 中的 SQL 权限）​。因此，需要分为两步来完成建模账号的授权。
对于进一步的操作，比如激活模型，甚至预览模型的数据，都会出现权限问题。产生这个问题的原因是，激活 HANA 模型（属性视图、分析视图、计算视图等）会在“_SYS_BIC”Schema 中生成相应的列视图，使用模型实际上就是从这些生成的列视图中选取数据。该 Schema 的所有者，即系统账号“_SYS_REPO”​，需要对于模型的基础表所在的 Schema 拥有访问权限。

新建 Package

如果把 HANA 中的模型想象成在操作系统中保存的各类文件，在这种情况下 Package 就等同于文件夹。在文件夹中还可以创建子文件夹，因此通常会采用这种文件夹多层嵌套的形式，管理大量有关联的文件，也使得管理和查找文件变得非常便利。在实际 HANA 项目中也是如此，都会使用多个“同级”或“上下级”关系的 Package 来保存模型。
选中其中的“Content”节点并单击右键，在弹出的快捷菜单中依次选择菜单项 New→Package。

属性视图

从建模方法来看，HANA 建模应该划分为 ROLAP（Relational OLAP）的范畴，因此属性视图取代了传统 RDBMS 中的维度表。并且，我们可以使用属性视图实现更加灵活、复杂的功能。

• 可以在多张 OLTP 业务表的基础上，构建单个维度。
• 可以暴露数据库表的部分列，或添加新列（Calculated Column）​。
• 可以预先设置过滤条件（Filter）​，减少查询时的数据量，提高效率。
• 可以创建 Hierarchy（层次结构）​，实现分析中常用的钻取功能。

属性视图——客户主数据

步骤 1：创建视图
步骤 2：添加数据库表
步骤 3：定义视图结构
步骤 4：为视图添加新列：
对前面创建的客户属性视图进行扩展：在 TPC-H 模型中客户表提供了账户余额信息（字段“C_ACCTBAL”​）​，在客户属性视图中添加新的计算字段，即为视图中的客户记录设置“欠债账户”标记。
步骤 5：检查和激活视图
步骤 6：预览数据
查询属性视图的数据，不仅可以使用前面介绍的在 HANA 工作台中集成的工具，还可以由用户自己编写并执行 SQL 语句。
在激活属性视图后，会在“_SYS_BIC”这个 Schema 中生成对应的列视图，读者可以展开这个 Schema→Column View 看到所有生成的列视图，同时该列视图的名称遵循下列命名规范：//…/< 属性视图名称>
Package 允许层层嵌套，因此在列视图的命名中，会把所有 Package 层级都列出来并用“/”分割。在本例中，​“CUSTOMER”属性视图存放在“demo”Package 中，因此对应的列视图的名称为“demo/CUSTOMER”​。

更多特性：预置过滤条件

分析视图

属性视图中提供了从客户主数据、供应商主数据、部件主数据角度进行业务分析的维度。那么，如何将这些可用的分析维度和实际需要的分析指标关联起来呢？答案是：通过分析视图（Analytic View）​。分析视图的主要作用和主要操作步骤如下:
（1）加入事实表，从而提供分析指标的数据基础前面的两个属性视图相关的事实表（Fact Table）需要加入到分析视图的“Data Foundation”中。对应 TPC-H 模型，Orders、LineItem 这些数据库表保存着销售订单的具体信息（金额、折扣、销售数量、总价等）​，因为这些信息都是业务人员关心的分析指标，所以这两个数据库表都需要加入进来，并且两个表之间要进行关联，然后设定哪些字段为“Data Foundation”的输出字段。
（2）将分析指标（事实表）和分析维度（属性视图）关联起来将事实表加入到“Data Foundation”后，需要在“Logical Join”​（只有分析视图才有）中加入所需的两个属性视图。然后，将属性视图和事实表关联起来。如果有需要，也可以创建新的计算列（Calculated Column）字段，创建输入参数和设定列限制。
（3）设定分析指标和分析维度在“Semantics”中定义哪些字段为分析属性，哪些字段为分析指标。

步骤 1：创建分析视图
分析视图的工作界面和属性视图类似，只是多了一个“Logical Join”的操作面板。
步骤 2：添加事实表

• 在这个 Data Foundation 中，使用了两个事实表，并且将两个表中的很多字段添加为输出列，这些字段有数值、金额、字符等类型。但是，只有数值类型的数据库字段可以设置为分析指标（Measure）​。
• 在同一个分析视图中，所有的“原始”分析指标字段只能来自同一个事实表，否则系统会提示错误。
  例如，ORDERS 表提供了总金额字段 O_TOTALPRICE，LINELTEM 表提供了 L_QUANTITY 字段，如果在 Semantics 中直接将这两个字段设定为 Measure，然后激活，系统会提示错误。
  如果一定要输出两个事实表的字段作为 Measure，可以在 Logical Join 中定义一个新的 Calculated Column 字段（类型必须相同）​，然后将 O_TOTALPRICE 直接赋予这个新字段列，最后再将这个新创建的 Calculated Column 字段设定为 Measure，再次激活这个分析视图，这样就能达到在同一个分析视图中同时输出两个事实表的字段作为分析指标的目的。

步骤 3：添加属性视图
步骤 4：为视图添加新列
步骤 5：指定分析指标
由于 HANA 分析视图是 Cube 结构，因此存在两种字段类型：Attribute，即是前面谈到的分析维度；Measure，等同于分析指标。分析视图上所有字段初始都会作为 Attribute 存在，因此需要手工指定哪些是 Measure。

SAP HANA 建模进阶

计算视图

View Type：采用可视化（Graphical）方式，还是脚本（SQLScript）方式。
1、可视化方式
在某些对象被计算视图引用后，用户可以对引用的对象进行数据过滤和重新组合。例如，只输出所需的字段、创建新的计算属性（Calculated Attribute）和计算指标（Calculated Measure）​、设定过滤器、设定分析的层级等功能。
2、脚本方式
在创建计算视图时，如果选择脚本方式，在脚本方式下，用户需要在右边的输出面板中定义输出字段名称和类型，然后在中间的部分编写代码获得所需的数据。与可视化环境下几个重构操作相似的功能，在脚本方式下是通过调用对应的 CE 操作（Calculation Engine Operator）来实现的。

计算操作

• 合并操作
  合并（Union）操作的主要功能是可以将多个计算视图中的引用对象合并，然后输出合并后的数据结果集。
• 投影操作
  投影（Projection）操作主要用来对引用对象的输出做进一步的处理，如选择需要输出的字段，增加额外的过滤器、计算列等，然后创建一个 Output 对象的连接，将投影中所定义的字段全部供 Output 来使用。
• 聚合操作
• 连接操作
  连接（Join）操作就是将两个引用对象进行连接。与合并不同的是，连接操作需要两个对象之间指定连接字段，最终只有字段值相同的值才会被选择出来。

示例 1：计算视图——可视化方式

TPC-H 模型已经实现以下内容：

• 属性视图 CUSTOMER：构建了客户主数据的维度。
• 属性视图 SUPPLIER_PART：构建了供应商和产品部件主数据的维度。
• 分析视图 CUSTOMER_ORDER：将销售订单表和上述两个属性视图做了关联，从而完成了 TPC-H 模型的展现。基于这个分析视图所产生的列视图，开发人员在 BO 中可以直接使用这些模型，然后进行数据的加工整理，定义输入和输出的格式。
  现在，创建一个可视化的计算视图，综合利用各种不同的操作来实现如下业务需求：
• 重用分析视图 CUSTOMER_ORDER。
• 对 1998 年和 1997 年的销售订单数据进行环比分析。
• 分析维度包含地区、国家、年份、市场细分，分析指标为销售金额。

SQLScript

何时应该使用 SQLScript 呢？
SAP 官方的建议：① 能够使用标准 SQL 的时候，尽量用 SQLScript 来代替，如创建存储过程时；② 使用属性视图和分析视图，以及可视化计算视图无法满足业务需求时。

表类型

用户可以在某个 Schema 中定义一个表类型，该表类型在不同的存储过程被引用，作为输入/输出参数传递值，可以参考以下 SQL 代码：

CREATE TYPE tt_customer AS TABLE (
  c_custkey INTEGER,
  c_name VARCHAR(25),
  c_address VARCHAR(40)
);

在存储过程中，可以利用 Table Type 作为输入/输出参数的引用类型在存储过程中，可以利用 Table Type 作为输入/输出参数的引用类型:

CREATE PROCEDURE test(
  in customer_id char(3),
  out customer_name varchar(25),
  out customer_tab tt_customer
) LANGUAGE SQLSCRIPT SQL SECURITY INVOKER READS SQL DATA AS
BEGIN
customer = select c_name from "HANA_TPCH"."CUSTOMER" where c_custkey = 1;
customer_tab = select c_custkey,c_name,c_address fr0m "HANA_TPCH"."CUSTOMER" where c_custkey=1;
END;

存储过程

存储过程的定义可以通过以下的 SQL 命令方式来实现，即直接使用 CREATE PROCEDURE 就可以完成，另外，需使用 CALL 命令调用。在以下代码中，​[ ]中的内容表示可选项目，不是一定要定义的。例如，存储过程不一定非要指定参数和权限设定等。

CREATE PROCEDURE 存储过程名称 [(<参数定义>)] [LANGUAGE <LANG>] [SQL SECURITY <mode>] [READS SQL DATA [WITH RESULT VIEW <view name>]]
AS [本地变量定义]
BEGIN
主体SQL代码...
END

DROPPROCEDURE DEMO_1;
CREATEPROCEDURE DEMO_1(IN id INT,OUT o1 tt_customer)
    LANGUAGE SQLSCRIPT
    READS SQL DATA
        v_name VARCHAR(30);
        v_test INT := 0;
AS
BEGIN
tab = SELECT * FROM CUSTOMER WHERE C_CUSTKEY = :id;
o1 = SELECT c_custkey,c_name,c_address FROM :tab;
END;
CALL DEMO 1(1，01=>?);

计算引擎函数

CE Function 的全称是 Calculation Engine Plan Operator（计算引擎计划操作）​，而这里简称其为 CE Function。它其实就是封装了一些数据传输功能，并且在计算引擎中更加高效执行的一组函数库。
通常来说，能够使用 CE Function 替代的 SQL 语句，尽量使用 CE Function。当然，CE Function 和 SQL 语句也是可以混合使用的（SAP 官方不建议混合使用）​，但在执行顺序上尽量不要来回交叉使用，如前一句使用 SQL 语句，接着使用 CE Function，然后又使用 SQL 语句。

示例 2：计算视图——脚本方式

HANA 内容生命周期管理

SAP HANA 同样提供业务内容开发的生命周期管理（Content Lifecycle Management，CLM）功能，而 SAP HANA Repository 负责对用户创建的业务内容进行管理和监控。
SAP HANA 应用开发中提供了 Delivery Unit（应用发布单元，DU）这样一个概念，用户可以将它看成一个开发项目包或一个功能单元。DU 可以将相关的 Package 一起打包，然后在各个 HANA 系统之间进行导入或导出。用户可以为 DU 定义不同的版本，还可以定义不同的 DU 之间的依赖关系。例如，导出一个 DU 的同时，另一个 DU 也必须同时导出，否则可能在导入 DU 时，系统会提示导入错误等信息。

创建 DU

SAP HANA 应用开发中提供了 Delivery Unit（应用发布单元，DU）这样一个概念，用户可以将它看成一个开发项目包或一个功能单元。DU 可以将相关的 Package 一起打包，然后在各个 HANA 系统之间进行导入或导出。用户可以为 DU 定义不同的版本，还可以定义不同的 DU 之间的依赖关系。例如，导出一个 DU 的同时，另一个 DU 也必须同时导出，否则可能在导入 DU 时，系统会提示导入错误等信息。
一个 DU 就是一个独立的应用发布包，用户可以下载然后导入这个应用单元到自己的 SAP HANA 系统中。

创建 Package

Package 之间可以是并列或上下级关系，应用开发人员可以使用 Package，逻辑上封装 HANA 应用的各个组成部分（信息模型对象）​。

导入和导出功能

SAP HANA 与商务智能的结合

SAP Visual Intelligence

SAP Visual Intelligence（发布在新版本 SAP BI 4.x 套件中，简称 VI）是为单个用户提供数据可视化的分析工具。与 SAP BI 中其他分析工具不同，由于 VI 未采用 B/S（浏览器/服务器）架构，因此用户在安装 VI 软件时不需要同时安装 BI 应用服务器。在本地计算机上安装 VI 软件后，用户可以连接 SAP HANA 系统，通过可视化、交互式的方式分析 SAP HANA 中的数据，而且用户可以将浏览和生成的分析结果保存为一个本地文件，即使在未连接到 SAP HANA 系统的情况下，也可以进行离线分析。VI 软件的下载路径：http://service.sap.com/swdc。

SAP BusinessObjects Explorer

SAP BusinessObjects Explorer（以下简称为 Explorer）是数据探索工具，与 SAP 商务智能套件中的其他工具不同，Explorer 展现的样式固定，无法按照业务要求进行设计，因此使用 Explorer 不能直接生成企业运营所需的各类报表。Explorer 的受众偏向于企业内部的数据分析师，如财务人员轻点鼠标并通过简单地拖拉即可实现企业数据的钻取、切片、切块、转轴等数据分析手段。
从技术角度看，对于用户在 Explorer 中的每一个操作，比如变换维度，Explorer 服务器都会生成相应的 SQL 语句，发送给底层数据库进行查询。过去，由于传统数据库的性能瓶颈，用户无法真正感受到 Explorer 即席查询（Ad hoc Query）的价值。SAP HANA 的海量数据实时分析，真正为 Explorer 带来了新生。

SAP Web Intelligence

SAP Web Intelligence（下文简称 WebI）与 Explorer 功能相似，都是用来协助业务用户完成各类动态的数据分析，比如钻取、切片等。使用 WebI 可以根据业务需求定制报表的显示样式，因此，WebI 开发的报表可以“固化”企业已有的成熟的分析方法。当业务用户第二次打开报表时，无须设置分析指标、维度或样式等，即可直接获得期望的分析结果。

EXCEL

外部应用，如 Windows 平台的 Excel，可以通过 ODBO（微软公司发布的多维数据处理规范）标准 OLAP 数据库接口访问 HANA，并且通过 MDX（多维表达式）查询分析视图、计算视图等多维数据集。本章会重点介绍使用 Excel 连接 HANA，并且借助 Excel 数据透视表（PivotTable）展现和分析 HANA 中的多维数据集。

Tableau

SAP HANA 应用开发

JDBC/ODBC 是 SAP HANA 对外的通用访问接口，无论是 ETL 工具、BI 软件，还是事务型应用都可以基于该接口和 SAP HANA 进行数据交互。而 OData 和 Server-Side Javascript，以及 HTML5 则是 SAP HANA 支持的原生应用开发方式，这种应用可以直接部署在 SAP HANA 中，使用 XS Server 作为轻量级的 Web 应用服务器，协助用户完成一些创新应用的开发和实现。

ABAP 和 SAP HANA 开发

• SAP HANA 加速 ABAP
  ABAP 能够访问到 SAP HANA 中的数据、虚拟模型、数据库视图、调用 SAP HANA 中的存储过程等。在这个阶段，SAP HANA 基本上是作为 SAP ABAP 系统的一个“外挂数据库”或“第二数据库”而存在的，一般称之为加速器方式。
• ABAP 运行在 SAP HANA 之上
• ABAP 计算逻辑下沉 SAP HANA

ABAP 访问 HANA 的准备工作

（1）升级到 SAPKernel 7.0X 以上
（2）安装 SAP HANA Client
（3）Unicode 系统：SAP ABAP 应用服务器需要的是 Unicode 方式，出于对非 Unicode 系统的支持，可参考 Notes-1700052。
（4）安装 DBSL 组件：SAP ABAP 应用服务器上需要 DBSL 组件，DBSL 就是使 SAP ABAP 能够访问 SAP HANA 的一套链接库文件，其实将其理解成驱动程序文件也可以。

配置连接

步骤 1：配置 ABAP 到 HANA 的数据库连接
登录到 SAP ABAP 系统，然后运行“DBCO”事务代码，就可以为当前的 ABAP 系统配置一个到额外的数据库的连接。
步骤 2：测试 ABAP 到 HANA 的连通性
SE38：ADBC_TEST_CONNECTION

三种 ABAP 访问 SAP HANA 的方式

• OPEN SQL 访问数据库表/视图

SELECT XXX INTO TABLE xxx FROM zcustomer
--修改后ABAP 程序
SELECT XXX INTO TABLE xxx FROM zcustomer CONNECTION ('TR1')

--ABAP
DATA:LV COUNT TABLE TYPE I.
DATA:BEGIN OF LINE,
     C_NAME TYPE STRING,
END OF LINE.
DATA:TAB TYPE TABLE OF LINE.

SELECT C_NAME INTO TABLE TAB FROM ZCUSTOMER CONNECTION ('TR1').
DESCRIBE TABLE TAB LINES LV_COUNT_TABLE.
WRITE '内表中记录的条数:'.
WRITE LV_COUNT_TABLE.

• Native SQL 访问 OLAP 视图
• Native SQLADBC 访问 OLAP 视图

SAP HANA 加速器

SAP HANA 加速器就是将 SAP 系统中的 ABAP 程序读取数据的路径做一个重定向，即从 SAP ABAP 底层数据库读取数据定向为从 SAP HANA 中读取数据。
SAP HANA 加速器（或 SAP HANA 应用加速器）指的是 SAP HANA 作为 SAP ABAP 应用的数据基础，从而提升原 SAP 应用程序的执行性能。
SAP 官方推出的 CO-PA Accelerator（获利分析加速器）和 CO-PA Reporting（获利分析报表）应用都是利用上述这种原理。
除了 SAP 官方发布的加速器应用外，我们也可以使用 SAP HANA 直接加速客户在 SAP ABAP 系统上的定制化开发程序。举例来说，如果用户希望加速 ABAP 程序 ZXXX，那么只需安装好加速器 Add-on 软件（SWT2DB，如何下载可参考 SAP Note 1696402）​，并且将这个 ZXXX 程序中访问到的较大的数据库表复制到 HANA 中，然后做一些基本配置就可以完成对这个程序的加速。
采用加速器的方式不需要修改现有系统的程序代码 ​，用户只需要做一些配置即可完成对原有 ERP 系统中的程序代码进行加速。

R 和 SAP HANA

R 是一个开源的编程语言，是用来实现统计分析及统计绘图的软件环境。
R 语言既是一种解释型的编程语言，也包含了一整套的数据处理、计算和制图软件，在更大程度上被理解成一种数学计算软件，为了更好地统一和规范，统称为 R 语言，这样更容易理解。R 语言大多都是以源代码方式发布的，任何人都可以基于 R 发布自己的功能模块，并且 R 语言可以在多个操作系统平台上运行，如 UNIX/Linux、Windows 和 Mac OS。

SAP HANA 分布式架构实战

HANA 分布式架构介绍

在 SAP HANA 分布式架构下，HANA 服务器有 3 种角色类型：Master（主服务器）​、Slave（工作服务器，或称从属服务器）​、Standby（备用服务器，保证高可用性）​，并且这 3 种角色的服务器都能够处理来自客户端的请求。
HANA 在分布式架构下和单节点下的区别是：

• 对数据文件的访问要有高 I/O 带宽。
• 对日志文件的访问要有高 IOPS。
• 不停机无限扩展的可能。

主服务器和工作服务器都能用于存储数据库表及其分区，并且承担数据计算的任务，两者区别：

• 主服务器充当整个分布式环境的事务协调者角色。
• 主服务器保存所有的主要元数据，而工作服务器只会缓存自身需要的那部分元数据。
• 在分布式环境中，可以配置多个备用主服务器，也可以有多个工作服务器，但是处于活动状态的主服务器只有一个。

单节点 HANA 服务器

单节点 HANA 指的是用户未配置备用 HANA 节点，即在 HANA 生产系统中仅仅只有一个主服务器节点，未配置任何工作服务器和备用服务器的情景。如果 HANA 主服务器停机，不会有备用的服务器提供切换，只有恢复 HANA 主服务器之后，才能对用户继续提供服务。这种单节点架构不考虑异常单点故障的情况，而且允许短时间停机和重启等。

HANA 集群的灾备恢复方案

惠普公司是第一个获得 SAP 认证的 HANA 集群灾备恢复方案的厂商，其方案是基于 HP P6000Continuous Access 软件、IBRIX X9300 网络存储网关，以及 SAN Boot 技术来实现的，支持同步复制模式和异步复制模式的随时切换，并且采用基于 IBRIX 数据存储访问管理的集中式 SAN 网络，使节点内的数据通信具备极小延迟，具备更好扩展性。
惠普公司的 SAP HANA 灾备恢复方案是基于磁盘存储系统的数据复制技术的，其主要原理是所有写入 HANA 生产系统中的数据（数据和日志）通过存储层面复制到 HANA 灾备系统中。这个 HANA 灾备系统通常都是处于冷备状态，在 HANA 生产系统发生故障时，HANA 灾备系统接替成为新的 HANA 生产系统。目前，惠普公司针对 SAP HANA 集群的灾备恢复方案有两种模式：同步复制和异步复制。

演示：HANA 分布式架构

HANA_1（机器名：Linux-s41d）​、HANA_2（机器名：Linux-8ggx）​、HANA_3（机器名：Linux-4eyr）​。这 3 台服务器的本地磁盘上都安装了 SUSE Linux 操作系统，然后都通过局域网连接到 1 个共享存储服务器 HANA_0（服务器名：Linux-hana）​。
共享存储服务器上，需要先创建一个/hana 目录，然后将一部分磁盘设备挂载到这个目录上，并且在这个目录下创建 data 和 log 两个子目录，分别用来保存 HANA 中的数据文件和日志文件。
共享存储服务器 HANA_0；
主服务器 HANA_1；
工作服务器 HANA_2；
备用服务器 HANA_3；

步骤 1：在 HANA 服务器和存储服务器之间配置 NFS：
1）首先，在共享存储系统（HANA_0）中配置 NFS 服务，将/hana 目录对这 3 个 HANA 服务器发布，并且开放所有权限，这个目录将作为 3 个 HANA 服务器安装 HANA 软件的目录。
2）分别登录到 3 个 HANA 服务器的 Linux 系统，在服务器根目录下创建 hana 目录，以及在/hana 目录下再创建 data 和 log 这两个子目录。

步骤 2：安装 HANA 主服务器:
最先安装的肯定是主服务器部分。HANA 主服务器的安装和单节点环境（单个 HANA 服务器）的 HANA 服务器安装相同，无任何区别，以下是两种安装方式：
1）执行./hdbsetup 程序，使用图形化界面进行安装；2）执行./hdbinst 程序，使用命令行的方式进行安装：

./hdbinst-sapmnt=/<hanamnt>--datapath=/<hanamnt>/data/<SID>--logpath=/<hanamnt>/log/<SID>

在安装完 HANA 主服务器后，执行“top-uadm”命令检查 HANA 所有的进程是否都已经处于运行状态。

步骤 3：安装 HANA 工作服务器：
在安装 HANA 主服务器时，我们选择了/hana 目录作为 HANA 的安装目录，而安装工作服务器时并不需要原始的 HANA 安装软件，而是以 root 用户身份进入到/hana//global/hdb/install/bin 这个目录下，然后执行./hdbaddhost 命令，即可以开始进行工作服务器的安装。安装程序会检测到当前已经安装好的 HANA 服务器，并且提示用户输入需要安装的工作服务器的角色“worker”。

步骤 4：安装 HANA 备用服务器：
和安装工作服务器大致一样，即执行./hdbaddhost 命令进行安装。选择 IndexServer role 时输入的是“standby”而非“worker“。

HANA 分布式架构的文件结构

以 root 用户身份登录到共享存储服务器（HANA_0）：

• /hana/DS1/HDB00 下包含了 3 个 HANA 服务器的工作目录。
• /hana/data 保存着所有服务器的数据文件。
• /hana/log 保存着所有服务器的日志文件。
  回到共享存储服务器的/hana 目录：
• /hana/data/mnt00001 是第一个 HANA 服务器（HANA_1）的数据文件目录。
• /hana/data/mnt00002 是第二个 HANA 服务器（HANA_2）的数据文件目录。
• /hana/log/mnt00001 是第一个 HANA 服务器（HANA_1）的日志文件目录。
• /hana/log/mnt00002 是第二个 HANA 服务器（HANA_2）的日志文件目录。

如果再安装一个 HANA 工作服务器，那么其目录将是 mnt00003，依此类推。HANA_3 服务器在安装时选择的角色是“standby”​，这表示 HANA_3 是一个备用的服务器，在正常情况下处于休眠状态，并且不对外提供任何数据访问服务，只有在集群中某个节点失效的情况下，才会替代那个故障节点进行工作。因此，它本身不会产生数据和日志文件，即使其他的服务器节点失效，这个备用节点也只是将失效节点的数据和日志文件接管过来，并不会新生成自己的数据和日志文件。

演示：模拟服务器停机

• 测试场景 1：将工作服务器停机，备用服务器立即转换成为工作服务器，接管原先工作服务器的所有数据，并且提供用户访问数据的服务。
• 测试场景 2：将主服务器停机，备用服务器立即转换成为主服务器，然后接管原主服务器的所有数据，并且提供用户访问数据的服务。

SAP HANA 系统管理

SAP HANA 系统管理中最为常见的一些系统管理内容：系统启动停机、备份恢复、升级、表分区和系统配置管理、监控、审计、安全管理等。

启动和停止

（1）单节点 SAP HANA 环境下的启动和停止
（2）分布式 SAP HANA 环境下的启动和停止

备份、恢复和升级

SAP HANA 基于内存计算技术，并且运行期的数据都来自 SAP HANA 服务器的主内存。然而，SAP HANA 也使用持久层存储数据，而且内存中的数据也会异步定时地同步到磁盘中，以保障在意外情况下数据的恢复和回滚。
SAP HANA 采用异步定期（Save Point）的方式将内存中的所有数据保存到持久层磁盘中。除此之外，SAP HANA 的所有数据更新操作都记录在持久层（闪存，Flash）的 Redo Log 中。在执行数据库事务提交时，Redo Log 将会写入到持久层磁盘中。如果 HANA 系统出现掉电之后重启的情况，就可以从本地磁盘加载数据，并且将未提交到磁盘中的 Redo Log 进行重演（Replay）​，最终将数据库恢复到掉电前的最后一刻的状态。

备份原因：如果 HANA 服务器的持久层（磁盘和闪存，闪存可以被视为持久层的一部分）都损坏了，数据库如何恢复？备份就是为了防止因本地服务器硬件损坏导致数据丢失而采取的最妥善的办法。
何时备份：

• 在将所有的数据第一次加载到 SAP HANA 之后。
• 隔一段时间就应该做备份。
• 在升级 SAP HANA 数据库软件之前（建议将配置文件也备份）​。
• 在分布式环境中增加新 SAP HANA 服务器节点之前（在分布式环境中新增加一个 HANA 服务器节点的操作会破坏当前 Redo Log 的信息文件）​。

如果没有做任何额外的配置，那么每次系统备份出来的数据文件和日志文件将被存放在系统默认的文件目录中。

内存使用管理

SAP HANA 目前运行在 x86 架构和 Linux 系统之上，在 Linux 下，硬件服务器中所有可用内存被分配给应用程序去管理，并且大部分内存都是在 SAP HANA 主程序的完全控制之下。
在内存计算技术中，管理和跟踪自身消耗的内存是非常重要的，为了达到这个目的，HANA 会预先分配和管理其自身的内存池（Memory Pool）​。驻内存的数据库的数据、线程堆栈、临时计算、中间计算结果和其他数据结构等信息都将使用这个内存池中的内存。

内存使用监控

SAP HANA 提供了内存管理器、内存池、外部指标等信息（例如，服务器层面的常驻内存的大小和虚拟内存大小，以及 Linux 进程层面常驻内存大小）​，利用 SAP HANA 工作台提供的这些指标信息，可以帮助用户精确地估计 SAP HANA 当前的内存使用情况。

（1）SAP HANA 使用的内存在内存监控中，Used Memory 和 Peak Used Memory 是最重要的内存使用指标。Used Memory 代表 SAP HANA 使用内存的大小，Peak Used Memory 记录着当前 HANA 系统曾经使用内存的最高峰值，而 Allocation Limit 是分配给当前 HANA 系统能够使用的最大的内存。

（2）列存储表

-- 查询 HANA 系统中所有列存储的数据库表一共使用了多少内存
SELECT
    ROUND(SUM(MEMORY_SIZE_IN_TOTAL)/1024/1024) AS "Column Tables MB Used"
FROM M_CS_TABLES

-- 显示当前SAP HANA系统中所有Schema占用的内存空间
SELECT
    SCHEMA_NAME AS "Schema",
    ROUND(SUM(MEMORY_SIZE_IN_TOTAL) /1024/1024) AS "MB Used"
FROM M_CS_TABLES
GROUP BY SCHEMA_NAME
ORDER BY "MB Used" DESC

-- 列出某个Schema中所有的表使用的内存大小
SELECT
    TABLE_NAME AS "Table",
    ROUND(MEMORY_SIZE_IN_TOTAL/1024/1024, 2) AS "MB Used"
FROM M_CS_TABLES
WHERE
    SCHEMA_NAME = '<Schema名称>'
    ORDER BY "MB Used" DESC

-- 显示某个数据库表未压缩前的大小，以及在Main区域、Delta区域中数据所占用内存大小
SELECT
    COLUMN_NAME AS "Column", LOADED,
    ROUND(UNCOMPRESSED_SIZE/1024/1024) AS "Uncompressed MB",
    ROUND(MEMORY_SIZE_IN_MAIN/1024/1024) AS "Main MB",
    ROUND(MEMORY_SIZE_IN_DELTA/1024/1024) AS "Delta MB",
    ROUND(MEMORY_SIZE_IN_TOTAL/1024/1024) AS "Total Used MB",
    ROUND(COMPRESSION_RATIO_IN_PERCENTAGE/100,2) AS "Compr. Ratio"
FROM M_CS_Columns
WHERE
    TABLE_NAME= '<数据库表名称>'

-- 某个数据库表在内存中的整体压缩比（或者直接查看数据库表的Runtime Information，能都得到数据库表每一个数据列的精确压缩比
SELECT
    ROUND(SUM(MEMORY_SIZE_IN_MAIN) / 1024  /1024 , 2) as
    "Memory Size in MAIN-MB",
    ROUND(SUM(MEMORY_SIZE_IN_DELTA) / 1024  /1024 , 2) as
    "Memory Size in Delta-MB",
    ROUND(SUM(MEMORY_SIZE_IN_TOTAL) / 1024  /1024 , 2) as
    "Total Size in Memory-MB",
    ROUND(SUM(UNCOMPRESSED_SIZE) /1024 / 1024 ,2 )
    as "Uncompressed Total Size in Memory-MB",
    ROUND(ROUND(SUM(UNCOMPRESSED_SIZE) /1024 / 1024 ,2 ) /
    ROUND(SUM(MEMORY_SIZE_IN_TOTAL) / 1024  /1024 , 2),2)
as "Compressed Rate"
FROM M_CS_COLUMNS
WHERE
    SCHEMA_NAME= '<Schema名称>'and
    TABLE_NAME= '<数据库表名称>'

（3）行存储表

-- 显示当前HANA系统中所有行存储表使用了多少内存空间
SELECT
    ROUND(SUM(USED_FIXED_PART_SIZE +
    USED_VARIABLE_PART_SIZE)/1024/1024) AS "Row Tables MB Used"
FROM M_RS_TABLES

-- 显示所有Schema中每个行存储表单独使用的内存空间
SELECT
    SCHEMA_NAME,
    TABLE_NAME,
    ROUND((USED_FIXED_PART_SIZE +
    USED_VARIABLE_PART_SIZE)/1024/1024, 2) AS "MB Used"
FROM M_RS_TABLES
WHERE
    SCHEMA_NAME = 'SYS'
ORDER BY "MB Used "DESC, TABLE_NAME

SAP HANA 内存限制配置

打开 SAP HANA 系统的“Administration”界面，然后切换到“Configuration”选项卡，再依次展开“global.ini” -> “memorymanager” -> “global_allocation_limit”​，选中“global_all ocation_limit”属性，然后单击鼠标右键，在弹出的快捷菜单中选择“Change”功能，然后输入新的值保存即可。

-- 读取当前HANA系统对内存分配限额的设定
SELECT
    HOST,
    ROUND (ALLOCATION_LIMIT/1024/1024) AS "限制分配多少MB内存"
FROM "PUBLIC"."M_HOST_RESOURCE_UTILIZATION"

内存操作

对于 SUSE Linux 操作系统而言，HANA 和其他应用程序一样，只是 HANA 是由很多不同的 Linux 进程组成的一个集合。Linux 程序会保留一些内存给操作系统使用，所有这些保留的内存称为“虚拟内存”​（Virtual Memory）​。

Total Resident（常驻内存）​，表示被 Linux 进程（SAP HANA、其他的 Linux 应用程序）所操作和使用的物理内存。通常，操作系统占用的 HANA 硬件服务器内存不会超过 3GB，其他的内存全都是被 SAP HANA 占用的。

-- 获得当前HANA系统的常驻内存和物理内存
SELECT
ROUND((USED_PHYSICAL_MEMORY + FREE_PHYSICAL_MEMORY)/1024/1024/1024,
        2) AS "Physical Memory GB",
ROUND(USED_PHYSICAL_MEMORY/1024/1024/1024,
        2) AS "Resident GB"
FROM PUBLIC.M_HOST_RESOURCE_UTILIZATION

• 物理内存（Physical Memory）就是 HANA 硬件服务器的内存。
• 分配内存限制（Allocation Limit）表示 HANA 最多可以使用的内存。
• 当数据库表增大（插入很多新数据等）或者临时计算空间变大而需要更多的内存时，SAP HANA 程序会从现存的内存池中获得这些内存。
• 如果内存池无法满足所需内存的请求，那么 SAP HANA 内存管理器会向操作系统请求，然后保留更多的内存，此时 SAP HANA 进程控制的虚拟内存（Virtual Memory）就又变大了。
• 当数据库表的数据被删除或者临时计算完成时，很多自由的内存空间被释放出来，这些内存就会返回到 SAP HANA 内存管理器，然后返还给内存池。这样，SAP HANA 使用的内存（Used Memory）就变小了。
• 在使用的内存变小之后，SAP HANA 进程控制的虚拟内存和常驻内存（Resident Memory）并不会受到影响。并且使用的内存很多时候都低于常驻内存的大小，这是比较好的一种情况

表分区管理

表分区就是将数据库表拆分成多份，这些拆分后的数据分布到不同的服务器上，并且由不同的 CPU 负责进行计算。最终目的是为了提升性能（更多并发、更快访问、更高 CPU 利用率等）​。
SAP HANA 对数据库表的分区提供了以下两种方式。

• 单层分区
  包含散列、循环、范围这 3 种分区方式。散列分区（Hash Partition）​，是相对简单的一种分区方式，可以将数据非常均匀地分布到不同的服务器节点上，避免数据的倾斜分布，有效提高 I/O 吞吐。循环分区（Round-robin Partition）​，将数据均匀地分布在所有服务器节点上。范围分区（Range Partition）是基于数据库表的某个字段的范围值进行分区。

• 多层分区
  在单层分区的基础上再进行数据的分区，如散列–范围分区（Hash-Range Partition）​、循环–范围分区（Round robin-Range Partition）​、散列–散列分区（Hash-Hash Partition）等都属于这种多层分区模式。这种多层分区在数据的业务部分比较复杂的情况下，可以将各种不同的分区方式的优势组合利用，从而达到最佳的效率状态。

表分区功能目前只适用于列存储表。
虽然表分区一般在分布式 HANA 环境下使用，但是在单节点的 HANA 环境下采用分区也能提升性能。
如果一个数据库表拥有超过 2 千万条记录，出于性能的考虑，可以对此表进行数据的分区。此外，如果一个数据库表不能进行数据分区，那么它是无法保存超过 20 亿条数据记录的。

查看表分区

方式 1：Schema 的数据库表分布
方式 2：查看数据库表运行期的属性

单层分区的创建

- （1）创建散列分区：创建了一个数据表 TEST，包含 4 个分区，并且以字段 A 作为分区键；分区所用的字段必须来自数据库表的主键或全部主键。
CREATE COLUMN TABLE test (a INT, b INT, PRIMARY KEY (a))
PARTITION BY HASH (a)
PARTITIONS 4

- （2）创建循环分区：循环分区不需要指定任何字段作为分区键。创建了一个无主键数据库表TEST_2（采用循环分区的数据库表必须没有主键）​，一共带有4个分区。
CREATE COLUMN TABLE test_2 (a INT, b INT)
PARTITION BY ROUNDROBIN
PARTITIONS 4

- （3）创建范围分区：创建了一个数据库表TEST_3，一共带有4个分区，数据记录被写入哪个分区取决于该条记录的a字段的值在哪个分区定义的范围之内。
- 范围分区使用“值<=VALUES<值”​，单值分区使用“VALUE= 值”​。
- 创建范围分区需要对这个数据库表的数据分布有一定的了解。如果插入一条数据记录到一个范围分区的数据库表中，a字段的值不在定义的范围中，系统会出错。此时，用户可以定义一个在范围之外的大分区，使用PARTITION OTHERS参数。
- 范围分区的字段必须来自数据库表的主键。

CREATE COLUMN TABLE test_3 (a INT, b INT, PRIMARY KEY (a))
PARTITION BY RANGE (a)
    (PARTITION 1 <= VALUES< 100,
    PARTITION 100 <= VALUES< 200,
    PARTITION VALUE = 300,
    PARTITION OTHERS)

多层分区的创建

对于某些数据库表，使用那些非主键的字段作为分区键也是非常能够提升性能的，但是在散列分区和范围分区中，只能使用主键作为分区键，那么如何才能克服这些限制因素呢？答案是使用多层分区。多层分区其实是一种不同分区的组合方式，HANA 当前提供了散列–范围、循环–范围、散列–散列这 3 种多层分区的方式。

- （1）创建散列–范围分区：第一层分区有4个分区，采用散列分区的方式，分区键是a，来自数据库表的主键字段。
- 在第一层分区基础上又进行范围分区，每个分区被分为3个分区，并且使用字段b作为分区键。
- 分区的总份数= 第一层分区数量×第二层分区的数量。
CREATE COLUMN TABLE test_4 (a INT, b INT, PRIMARY KEY (a))
PARTITION BY
    HASH (a) PARTITIONS 4,
    RANGE (b)
        (PARTITION 1   <= VALUES< 100,
        PARTITION 100 <= VALUES< 200,
        PARTITION OTHERS)

- （2）创建循环–范围分区
CREATE COLUMN TABLE test_5 (a INT, b INT)
PARTITION BY
    ROUNDROBIN PARTITIONS 4,
    RANGE (b)
        (PARTITION 1  <= VALUES< 100,
        PARTITION 100 <= VALUES< 200,
        PARTITION OTHERS)

- （3）创建散列–散列分区
CREATE COLUMN TABLE test_6 (a INT, b INT, PRIMARY KEY (a))
PARTITION BY
    HASH (a) PARTITIONS 4,
    HASH (b)PARTITIONS 8

多 HANA 节点下的分区

分布式 HANA 环境下存在多个 HANA 服务器节点，在创建数据库表时，可以使用函数 GET_NUM_SERVERS 得到当前所有可用 HANA 服务器节点的数量，从而让数据库表根据现有服务器数量自动调整分区的数量，以达到数据均匀分布的目的。

-（1）分区数自动指定
CREATE COLUMN TABLE test (a INT, b INT, PRIMARY KEY (a))
PARTITION BY HASH (a)
PARTITIONS GET_NUM_SERVERS()

-（2）分区数手动指定
CREATE COLUMN TABLE test_8 (a INT, b INT, PRIMARY KEY (a))
PARTITION BY HASH (a)
PARTITIONS 4

• 在 SAP 官方文档中，BW 主数据表均采用循环分区的方式分布在所有的工作服务器节点中。像 DSO、Fact 或 PSA 表在预定的规则中也是被循环分布在所有工作服务器节点之中的。
• 只有行存储表（ABAP 系统表、DDIC 等）分布在 HANA 主服务器节点之中。

分区后的基本操作

初次创建好的分区未必是最优的，数据的利用率和访问频率会随着时间的变化而发生变化，因此数据库管理员需要针对这样的现状对已有的数据库分布进行调整。