SAP HANA 数据库—架构概览 | StoneDB学术分享会 #6

翻译：王学姣

审校：李浩，宇亭

责编：宇亭

 

导语

本篇是StoneDB学术分享会专栏的第六篇，在上一期里，我们分享了奠定 HTAP 数据库基础的现象级论文《A Common Database Approach for OLTP and OLAP Using an In-Memory Column DataBase》，如果说，上一期 SAP 在 2009 年的论文只是初步的提出了一个看起来很强悍并且可行的理论，那么三年后，SAP 在 2012 年发表的这篇《The SAP HANA Database – An Architecture Overview》，则用一个实打实的架构体系向世界宣布了一体化 HTAP 数据库——SAP HANA 的强大（我们已经不是吹概念了，而是实现了有木有，直接给全世界看我们的架构体系啦~）

这下子，信仰“One Size Doesn't Fit All”的学者和商业团队们可慌了神，说好的，OLAP 数据库和 OLTP 数据库要分开卖的呢？你们 SAP 怎么这么不讲武德啊？一个内存数据库非要来抢我们两个派系的生意？

不过，市场并不会接受吐槽，SAP HANA 以其高水平的研发团队、极致的性能和独特的营销技巧在数据库行业开始异军突起~

 

摘要

随着企业发展，企业级应用对数据库的要求变得越来越严苛。这些应用程序要求数据库系统能基于事务数据生成复杂的报告，且要保证多达上万的用户能够同时对相同数据进行读取、更新操作。SAP HANA 数据库旨在使用一个数据库管理系统同时处理事务性和分析性工作负载。为了实现这一目标，我们设计了一个列存引擎。该列存引擎利用现代硬件（多 CPU 内核、大容量主内存和缓存），支持数据压缩、数据库内核并行最大化，提供层次结构（hierarchy）专用的数据结构、用于特定领域的语言支持等企业应用所需的数据库扩展。在本文中，我们将重点介绍 SAP HANA 数据库的架构。我们还会公布在真实的企业应用场景中通过 SAP HANA 数据库收集的反馈和洞察。

简介

关于企业数据的全方位解读已经成为每个企业的核心资产（小编注：这就是数据价值）。企业数据通过各种渠道，如以 SAP ERP 为代表的企业资源规划系统、生产环境中使用的传感器或 Web 界面，成批或逐笔输入。举个例子，销售过程中会产生订单创建、修改和删除等操作。这些订单是生产计划和交付的基础。因此，销售过程往往会针对记录进行查找、插入和更新操作。这类数据处理通常被称为联机事务处理（Online Transaction Processing，OLTP）。OLTP 是当前基于磁盘（disk-based）的行存（row-oriented）数据库系统的强项。（小编注：MySQL 就是这种基于磁盘和行存的 OLTP 数据库）

根据我们的仔细观察，一个看似非常简单的销售过程可能包含大量复杂的分析处理。例如，作为销售流程的一部分，检查交付产品的可用性需要汇总预期销售额、预期交付量和生产批次的完成情况，以及将最终库存与客户需求进行比较。类似地，销售组织将对基于最近的销售和成本信息生成的盈利能力度量指标感兴趣，因为这个指标方便他们进行销售策略的规划。以上这类工作负载被认为是联机分析处理（Online Analytical Processing，OLAP）。通过将数据复制到读取优化的数据仓库中，可以执行周期性任务，如季度末结算或客户细分。对于这些类型的报告，列存（column-stores）变得越来越流行[3]。

此外，分析型应用需要过程逻辑，而过程逻辑，例如根据销售数量对不同产品进行聚类（clustering）或对客户行为进行分类，并不能用简单的 SQL 来表达。常规的做法是将所有需要的数据从数据库转移到应用上，然后在应用上进行处理。因此，优化的数据结构和元数据不能被使用，而且如果后续业务流程需要用到相关中间结果，中间结果还必须回传到数据库中。

理想情况下，数据库应该能够在单个系统中处理所有上述工作负载和特定应用（Application-specific）的逻辑[13]。这一发现促使了我们开发了 SAP HANA DB。SAP HANA DB 的 In-Memory 列式存储基于 SAP TREX 文本引擎[15]和 SAP BI 加速器（SAP BIA）[10]，可快速处理 OLAP 查询。SAP HANA DB 的高性能 In-Memory 行式存储源自专为 OLTP 工作负载而设计的 P*Time[2]。SAP HANA DB 的持久性则来源于 SAP MaxDB 数据库系统的成熟技术，包括日志、恢复和持久存储特性。截至目前࿰