马克·赫德离开惠普之后，惠普先后请来了 SAP 前 CEO 李艾科和 Oracle 前总裁雷·莱恩，分别担任 CEO 与董事长。这两个人，恰好都跟拉里·埃里森有过节。惠普联合 SAP 对抗马克·赫德与拉里·埃里森，一场原本正常的商业竞争，就这样染上了强烈的个人恩怨色彩。SAP 与 Oracle 本来就是冤家，HANA 又选择了惠普作为最紧密的硬件伙伴，正好在市场上形成了对抗 Oracle 与 Sun 组合的另一极。
SAP 是 Oracle 真正势均力敌的对手。截至 2026 年 2 月 11 日，SAP 市值约为 2500 亿美元。Oracle 同日市值约为 4500 亿美元。这两家企业应用软件巨头之间的较量，称得上是数据库与 ERP 世界里最精彩的双雄对决之一。
图1 SAP 的股票价格走势
01. HANA 与哈索·普拉特纳的技术理想
图2 SAP HANA 标识
HANA 的全称是高性能分析一体机（High-Performance Analytic Appliance），是第一个全面支持 ACID 的事务型列式存储数据库，也是第一个 HTAP 内存数据库。不过鲜为人知的是，HANA 最早的名字叫 "Hasso's New Architecture"——哈索的新架构。这个称呼背后，藏着 SAP 创始人哈索·普拉特纳对数据库技术未来方向的全部信念与期待。
普拉特纳 1944 年生于柏林，1968 年从德国卡尔斯鲁厄理工学院毕业，拿到通信工程学位后进入 IBM 做软件开发。1972 年，他和四位前 IBM 同事一起离职，共同创立了 SAP。
图3 SAP 五位联合创始人
这五位创始人离开 IBM 时，带走的并不是什么技术或资产，而是一个想法：为企业提供一套真正意义上集成化的实时数据处理软件。他们的第一个客户，其实是五人原来在 IBM 时服务过的一个德国客户——帝国化学工业（ICI）的一家德国工厂。有传言说，他们第一款产品 SAP R/1 的整个开发过程，都是在租来的 IBM 大型机上趁夜间完成的，因为只有用户下班之后，他们才能用上那台机器。公司成立的头一年，五位创始人加一名秘书，挤在一间简陋办公室里熬夜写代码，白天再赶去客户现场做实施。SAP 的名字后来被正式确认为 "Systems, Applications and Products in Data Processing"（数据处理中的系统、应用和产品），这个全称恰好精准概括了他们此后五十年的事业。
普拉特纳后来回忆，公司刚创立时，德国传统银行界认为这群 IBM 出来的工程师不过是一帮“技术怪人”，没有银行愿意给他们贷款。五位创始人只能拿个人财产做担保，在极其拮据的条件下推进研发。1972 年，整个公司年营业额还不到 100 万德国马克。到了 1992 年，整整二十年过去，SAP 在全球已经拥有超过 3000 名员工，年营业额达到 8.96 亿德国马克。1998 年，SAP 登陆纽约证券交易所，当年收入约 84.7 亿德国马克，员工接近两万人，成为德国历史上规模最大的科技公司 IPO 之一。
从 R/1、R/2 到 1992 年推出 R/3，SAP 一路成长为全球最大的 ERP 软件厂商。R/3 的革命性在于引入了三层客户端-服务器架构，将系统明确划分为表示层、应用层和数据库层。这种架构让企业不再受限于昂贵的专有大型主机，可以按需独立升级服务器或客户端，灵活性大幅提升，IT 成本也明显下降。R/3 的另一大创举是实现了真正的“业财一体化”，把业务流程与财务数据无缝衔接起来。全球数千家跨国企业因此得以在统一系统上整合财务、供应链、人力资源等核心业务流程，流程标准化和数据集中化从此成为企业 IT 管理的主流范式。
但普拉特纳的野心远不止于 ERP。进入 2000 年代，他开始把目光投向数据库底层，思考一个更大的问题：能不能用技术手段，彻底消除企业信息系统中普遍存在的“数据时差”？也就是 OLTP 系统当天收集的数据，到了分析人员眼前，往往已经成了昨天甚至上周的旧数据。
02. 内存数据库：普拉特纳的 SIGMOD 论文
SAP HANA 的诞生与演进，不仅是企业级软件史上的一次重大技术跨越，更是对计算机底层架构与商业模式关系的重新定义。
要理解 HANA 的历史，得先回到 2006 年前后。那时全球企业正面临“数据墙”的困扰：传统的磁盘关系型数据库在处理高并发交易的同时，几乎无法胜任海量数据的实时分析。企业只能通过极其复杂的 ETL 过程，把数据搬到专门的数据仓库中。这种延迟让“实时决策”成了一种奢望。
那个年代，一个典型的大型跨国企业往往要维护三套甚至更多系统：一套跑在 Oracle 或 DB2 上的 OLTP 核心业务数据库，一套 Teradata 或 IBM Netezza 数据仓库，再加一套 SAP BW 商业智能平台。数据在这些系统之间流转，每一次流转都意味着数小时的 ETL 延迟、巨额的软硬件采购成本，以及永无止境的数据一致性维护噩梦。ETL 工具厂商因此成了一个年营收数十亿美元的产业。而这些厂商的存在，本质上是在弥补一个技术上本不该存在的架构缺陷。
正是在这种背景下，普拉特纳在哈索·普拉特纳研究院开始了新一代数据库架构的探索。HPI 于 2004 年由普拉特纳捐资创立，是一所专注于 IT 与数字化的独立研究机构，与德国波茨坦大学紧密合作。普拉特纳以自己的名字命名了这所研究院，并亲自领衔核心研究课题。他在内存数据管理方向的投入，最终成就了 HANA。HPI 不仅是 HANA 的技术摇篮，还与斯坦福大学建立了合作关系。两校研究团队在 2008 年联合完成了 HANA 的第一次重大技术演示，这次演示成为 HANA 技术可行性被正式确立的重要里程碑。
2009 年，普拉特纳在 SIGMOD 2009 会议上发表了具有里程碑意义的论文 "A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database"，正式奠定了 HANA 的学术基石。论文深刻指出，随着硬件技术进步，尤其是多核 CPU 的普及与内存价格的断崖式下跌，把整个企业级数据库完全放进内存，并利用列式存储统一处理事务与分析负载，在技术上已经可行。
这不是突发奇想，而是普拉特纳多年学术积累的结晶。这篇论文至今在 Google Scholar 上的引用次数超过 600 次，是内存数据库领域被引用最多的学术论文之一。其影响力早已超越学术界，成为整个数据库产业理解 HTAP 架构的重要参考文献。普拉特纳后来在 2011 年出版的著作 "The Impact of Columnar In-Memory Databases on Enterprise Systems" 中，对这一思想做了更系统的阐述。这本书后来也成为内存数据库领域的重要参考读物。
在普拉特纳担任 SAP 监事会主席期间（2003 年—2024 年），他持续从学术和战略两个维度推动 HANA 的演进。2024 年 5 月，80 岁的普拉特纳正式卸任 SAP 监事会主席，为这个亲手缔造了 HANA 技术基因的时代画上了句号。
03. HTAP：打破行存与列存的藩篱
普拉特纳在论文中提出的 HTAP（Hybrid Transactional/Analytical Processing，混合事务/分析处理）架构，正是 HANA 最核心的创新。
在传统数据库世界里，行存储和列存储被认为鱼与熊掌不可兼得。行存储适合单条记录的快速写入，列存储则在聚合分析上拥有无可比拟的优势。这种二元对立，催生了 OLTP 数据库和 OLAP 数据仓库两个平行市场，也造就了绵延数十年的 ETL 产业链。为什么企业不能在同一套数据库里既处理交易又做分析？答案藏在硬件瓶颈里：磁盘的随机读写速度，注定无法同时满足两种负载的极端需求。
HANA 通过引入“增量存储”（Delta Store）和“主存储”（Main Store）的双层架构，巧妙化解了这一矛盾。新发生的交易数据先高速写入行式的增量存储，保证极高的写入吞吐量；随后系统在后台异步将其合并进高度压缩的列式主存储中，供分析查询使用。这种“增量合并”（Delta Merge）机制，正是 Teradata 后来在诉讼中重点指控 SAP 涉嫌侵权的核心技术之一。
HANA 的 HTAP 创新，让企业能够在同一套数据库上既快速处理订单，又瞬间分析全年销售趋势，彻底消除了 OLTP 和 OLAP 之间的物理界限。对于一家业务前沿的企业而言，这意味着上午刚发生的销售数据，中午就能反映在管理报表上，而不用再等夜间的数据仓库抽取批次。
图4 数据仓库和 HTAP 架构数据库对比
在技术实现上，HANA 还引入了先进的字典编码（Dictionary Encoding）和位图索引技术，将数据压缩率提升到了惊人的 5:1 甚至更高。这意味着原来需要 10TB 磁盘空间的数据库，现在只需 2TB 甚至更少的内存即可容纳。更重要的是，数据在内存中是以压缩状态处理的，进一步减少了 CPU 与内存之间的数据交换频率，充分释放了多核处理器的并行能力。
04. 关键时刻：德克萨斯州的智能电表挑战
实验室里的理论要变成服务全球 500 强企业的商用产品，离不开强大的硬件支撑。HANA 早期之所以被称为“一体机”（Appliance），正是因为内存计算对底层硬件的内存带宽、CPU 缓存一致性以及 I/O 吞吐量有着近乎苛刻的要求。
2009 年至 2010 年研发关键期，惠普成了 SAP 最紧密的合作伙伴。双方合作源于一个极具挑战性的关键任务：德克萨斯州电力供应商 CenterPoint Energy 的智能电表数据挑战。该公司部署了约 230 万块智能电表，每 15 分钟收集一次用电数据，数据量比原来增长了 837%。激增的数据量让传统数据库架构在实时反馈面前显得捉襟见肘。
惠普投入了顶级工程资源，为 HANA 打造了首个认证的硬件运行环境。惠普不仅提供了大容量、高可靠性的内存池架构，还针对 HANA 的并行处理算法做了底层的芯片级调优。最终，惠普和 SAP 成功解决了 CenterPoint Energy 的业务挑战。
2010 年 5 月 17 日至 19 日，SAP 在奥兰多和法兰克福同步举办了 SAPPHIRE NOW 大会，这是 SAP 历史上规模最大的一次技术大会。主题演讲环节，普拉特纳与时任 SAP CTO 维沙尔·辛卡联合发布了最新技术愿景，喊出了那句后来被反复引用的口号：“实时计算时代已经到来”（Real time is now）。普拉特纳亲自演示了基于 HPE 硬件运行的 HANA，在处理数亿行数据时实现了秒级甚至毫秒级响应，同样的查询在传统数据库上可能需要数小时甚至数天。坐在奥兰多会场前排的众多 SAP 客户 CIO，看完演示后沉默了良久——他们意识到，自己正在目睹一场范式革命。SAP 后来把这次演示的核心理念概括为：“将整个企业置于内存之中”（The entire enterprise in memory）。
此后，惠普与 SAP 的合作关系进一步加深。虽然 SAP 与各大硬件厂商都有合作，但惠普提供的合作形态最为丰富。
图5 HPE 提供的 SAP HANA 一体机
这种生态开放性，让 HANA 一体机产品线逐渐走出了对单一硬件合作伙伴的依赖，发展成为一个真正的行业标准解决方案。
05. 从 BW 加速器到 S/4HANA 的进化
随后几年，HANA 进入爆发期。2011 年 6 月，SAP HANA 1.0 正式面向全球发布。最初它被定位为 SAP BW（商务仓库）的加速器，客户发现原本需要运行 10 小时的报表，在 HANA 上只需 10 秒。这种量变引发的质变，让 SAP 客户第一次真正感受到“实时”二字的分量。
2013 年，SAP 做出了一个重大决定：推出运行在 HANA 之上的 Business Suite（SoH）。这意味着 SAP 的核心 ERP 开始全面拥抱内存计算。对于已经在 SAP 上运行了数十年的大型企业客户而言，这是一次意义深远的迁移邀请。
图6 SAP S/4HANA 产品标识
2015 年，SAP 推出第四代 ERP 系统——SAP S/4HANA。这是一个具有分水岭意义的产品，因为它宣布只能运行在 HANA 数据库之上，彻底摆脱了对传统磁盘数据库（如 Oracle、DB2）的依赖。对 SAP 而言，这是多年积累之后的水到渠成；对 Oracle、Teradata 等传统数据库厂商而言，这无异于釜底抽薪——原本依托 SAP 生态滋养的那部分市场，将被 SAP 自己的数据库逐步蚕食。也正是这一强绑定决策，引发了后来 Teradata 发起的垄断诉讼。
到了 2016 年，HANA 收入达到 20 亿美元，还带动了数亿美元的额外许可销售，成为 SAP 历史上最成功的产品之一。2020 年，SAP 推出 HANA Cloud，将内存数据库的能力拓展到云端，为 HANA 开启了下一个十年的增长空间。
06. SAP 的四大数据库基石
HANA 的成功并非一蹴而就，其背后是 SAP 在数据库领域数十年的持续投入、积累与并购。SAP 有四个各具渊源的数据库基石产品，共同构成了 HANA 的技术底蕴。
1. MaxDB：与 MySQL 创始人的短暂联姻
早在 1990 年代，SAP 就曾开发了一款内部数据库系统——SAP DB。这是一款功能相当完整的关系型数据库，主要用于 SAP 内部系统。2003 年，MySQL 创始人蒙提·威德纽斯与 SAP 合作，将 MySQL 的技术积累与 SAP DB 的工程基础结合，重新发布了 MaxDB 产品并开源。Max 是蒙提长子的名字。2004 年，SAP 与 MySQL AB 的合作协议正式终止，MaxDB 随即归入 SAP 旗下。随着 SAP 在 2010 年收购 Sybase，MaxDB 的战略价值明显下降。
2. P*TIME：来自韩国的内存行式数据库
PTIME 是一个内存行式存储数据库，全称是 Parallel* Transact-In-Memory Engine，源自车相均的创业项目。车相均是首尔国立大学计算机科学系教授，也是一位连续创业者。2000 年，他在硅谷成立了 TIM（Transact In Memory）公司，全资控股韩国的 TIM System 公司，致力于内存数据库研究成果的商业化。据说 PTIME 在硅谷的一次 Demo 演示被维沙尔·辛卡看中。2005 年 11 月，SAP 悄然收购了 TIM 公司。此后，SAP 于 2008 年 3 月宣布将 TIM System 韩国公司改组为 SAP 韩国实验室，车相均也因此成为 SAP HANA 早期核心开发团队的重要成员。P*TIME 的内存行存储技术后来被整合进 HANA 的 Delta 存储层，成为 HANA 处理高并发写入事务的技术基础之一。
3. TREX：文本检索到列式存储的演变
TREX 是一个文本检索和信息提取系统，采用列式存储，是 SAP HANA 列存储引擎的直接前身。在用于 HANA 之前，TREX 被应用在 SAP 的商业智能加速器中，常被称为 BWA（Business Warehouse Accelerator）。TREX 的核心是一套基于列式存储的倒排索引引擎，能够对大量非结构化文本进行快速全文检索。随后，TREX 的能力逐步扩展到数值数据的分析加速领域。早在 2006 年，SAP 就开始将 BWA 作为独立产品推向市场，定位为运行在专用刀片服务器上的“内存加速器”——这也是早期 HANA 一体机概念的雏形。BWA 的实战成果，为普拉特纳在 SIGMOD 2009 上发表论文提供了宝贵的真实案例支撑，也为后来第一次 SAPPHIRE 演示中的惊人性能数字提供了工程保证。
4. Sybase：58 亿美元的数据库版图整合
2010 年 5 月 12 日，SAP 宣布以 58 亿美元全现金收购 Sybase——这是“最后一家独立数据库厂商”的完美谢幕。Sybase 在金融和电信行业根基深厚，尤其在华尔街那些需要高并发交易处理的金融机构中，Sybase ASE 长期占据核心地位。Sybase IQ 的故事尤为值得一提。这款专为分析负载设计的列式数据库，早在 1990 年代就已商业化运营，是业界最早成功商业化的列式数据库之一。其列式存储和高压缩比的技术理念，后来在很大程度上影响了 HANA 的设计方向。
通过收购 Sybase，SAP 获得的不仅是几款数据库产品，更是数百名在数据库内核、查询优化、分布式事务等领域积累多年的顶尖工程师。这次收购彻底打消了外界认为“SAP 没有真正的数据库 DNA”的质疑，大幅加速了 HANA 从实验室产品到企业级平台的演进过程。
事实上，对于成规模的应用软件公司而言，如果不能解决自身的“卡脖子”问题，发展迟早会受到制约。SAP 通过几十年的未雨绸缪、创新积累和战略并购，终于完成了自我闭环，彻底摆脱了 Oracle 数据库的束缚，为 HANA 的崛起奠定了坚实的技术和商业基础。
07. 中国实践：国网新疆电力的转型之路
SAP 最早的实践案例来自德克萨斯州的智能电表数据挑战。而在中国市场，电力系统的智能电表统计同样对性能有着严苛要求。这一横跨太平洋的技术契合，在中国市场书写了 HANA 理念的本土化故事。
早在 2019 年，云和恩墨 zData 数据库一体机就帮助国家电网新疆电力公司完成了营销业务系统的性能加速。该项目中，客户通过 zData 的“4 个计算节点 + 8 个存储节点”架构完成升级。改造完成后，客户业务高峰期等待中的活动会话数从 270 个降为 30 个，处理能力至少提升了 8 倍。
图7 新疆电力 zData 数据库一体机改造前后等待情况对比
最终，应用整体性能提升约 10 倍，I/O 性能提升 70 倍以上，系统更加稳定高效，营销扩报装、电费抄核、收费账务、95598 客服等核心业务的用户体验大幅改善。
从 HANA 到 zData，两个电力系统的案例彰显了极速计算理念的用户价值：无论是德克萨斯州的智能电表，还是新疆的电力营销系统，高性能数据处理的价值都超越了地理和文化的边界，在每一个需要实时决策的商业场景中展现其生命力。
08. 超越竞争：HANA 的历史意义
回顾 SAP HANA 的诞生与崛起，我们看到的不仅是一款数据库产品的技术成长史，更是一家软件公司通过长达数十年的战略性技术积累，最终实现从应用软件到数据库基础设施跨越式布局的商业启示录。
从 2003 年 MaxDB 的试水，到 2005 年 P*TIME 的悄然收购，到 TREX 在 BWA 中的默默验证，到 2009 年普拉特纳在 SIGMOD 的学术宣言，到 2010 年与惠普的合作突破，到同年 58 亿美元收购 Sybase，再到 2011 年 HANA 的正式亮相和 2015 年 S/4HANA 的战略绑定——这是一条清晰可见的战略布局轨迹，每一步棋都是为了下一步提前落子。把这条时间线展开，你会发现这不是天才的灵光一现，而是至少 15 年的系统性准备。
HANA 的崛起，也深刻改变了数据库一体机的市场格局。它证明了一件事：一体机的真正价值，不仅在于硬件与软件的预集成，更在于对底层计算范式的革新——从磁盘到内存，从行存到列存，从 OLTP/OLAP 分离到 HTAP 融合。这种对技术范式的把握，才是 HANA 能够成为 Oracle 真正对手的根本原因。这一判断，同样适用于云栈社区观察到的国内数据库一体机市场走向。
发表于 4 天前
|
查看: 3|
回复: 0
