最近重新梳理 SAP HANA Cloud 的版本体系时，有一个细节很容易让人产生误判。打开 SAP HANA Cloud Central，看到的是一个统一的 SAP HANA Cloud 产品入口。日常管理数据库、查看实例状态、调整配置、执行升级，也都集中在这套管理体验里。站在使用者视角，很自然会认为 SAP HANA Cloud 应该像很多 SaaS 服务一样，由 SAP 在后台把整个产品统一更新，我们只负责使用最新版。实际情况没有这么简单。SAP HANA Cloud 有两套需要分开理解的层级，一套是 service level，另一套是 component level。前者覆盖 SAP HANA Cloud Central、SAP HANA cockpit 等日常管理工具，后者才是承载数据和计算工作的数据库组件，包括 SAP HANA Cloud, SAP HANA database，以及 SAP HANA Cloud, data lake。它们虽然挂在同一个 SAP HANA Cloud 名字下面，版本发布频率、发布时间、补丁周期、自动升级规则都可能不一样。这个区别看起来像产品文档里的概念划分，到了真正的生产运维环境里，却会直接影响升级计划。管理界面已经出现一个新能力，并不代表底层 SAP HANA database 已经运行在支持这个能力的 QRC 上。SAP HANA database 已经完成 QRC 升级，也不代表与它集成的 data lake Relational Engine 同时完成了升级。更容易被忽略的一层是，data lake 即便已经进入新的 QRC，相同 binary 中的一部分能力仍可能晚些时候才被正式解锁。所以研究 SAP H