本文内容来自 SAP 社区博客：[Calculation Engine (CE) Functions – Rest in Peace](https://blogs.sap.com/2014/12/11/calculation-engine-ce-functions-rest-in-peace/)

CE Function，即 Calculation Engine，是 HANA SPS02 中引入的一种机制，它允许直接访问 HANA 列存储。它们允许极其精确地控制如何精准投影、计算和聚合列。

事实上，它们是原始 HANA 列存储如何建模向量函数的直接表示。

CE Function 执行的效率如何？

它们完全绕过了 SQL 优化器，意味着您想要执行的任何操作都在列存储中运行，并且您始终可以获得 HANA 的全部性能。CE 函数总是在列引擎中运行，并且如果您返回适度的结果集，则能获得很高的执行效率。它们实际上有效地编译成一种称为 L 的语言，它是 HANA 的中间语言，与 C++ 非常相似。

不过 CE Function 的编写也比传统的 SQL 要麻烦一些。

您必须指定每一列，当存储过程的取数逻辑越来越复杂时，这往往意味着大量的复制和粘贴以及代码的激活。编辑器不会给你太多帮助，错误信息也很简洁。简而言之，您必须是一名专业的 SQL 程序员，并且对 HANA 列存储具有一定的实操经验，才能熟练使用 CE 函数编写良好的 SQLScript。

然后，2012年时，伴随着 HANA SPS04 的“Project Orange” 这个项目的进展，HANA 数据库已经足够成熟，可以用于 SAP BW，但 BW 从未使用过 CE 功能。相反，BW 团队有自己的专有方式来使用 HANA。

这很快被证明是 BW 中的一个限制，导致一个新的概念诞生了：Calculation Scenario. 现在，当您在 BW 7.4 中编译 BW 对象时，会创建一个 HANA 视图，该视图可以通过 BW 的 OLAP 引擎访问，也可以直接被 HANA 数据库访问。两者是可以互换的，但是 CE 功能对于 BW 的需求来说限制太多了。

然后在 2013 年出现了 HANA 上的 Business Suite。商务套件通过 OpenSQL 接口广泛使用 ANSI SQL，并在 HANA SPS06 中首次亮相。由于 Business Suite 的编程方式，HANA 团队必须让 SQL 的执行效率比以前更高才行，并且 SQL 优化器进行了大量开发。从 HANA SPS06 开始，SQL 和 HANA  Information Views 之间通常几乎没有区别。

在此期间，超过一半的 SAP HANA 客户使用 BW，而 Business Suite 也是新增 go live 客户数量增长最快的 SAP 产品之一。这些产品本身都没有使用 CE 技术，因此 CE 技术得到的开发关注比较有限，几乎没有引入新功能。从 HANA SPS05 开始，就没有新的优化了。

从 HANA SPS07 开始，我们发现 Graphical Calculation Views 总是比 CE Function 要快。在HANA SPS08 中，我们发现 SQL、Analytical View 和 Graphical Calculation Views 在很多情况下都有完全相同的 Execution plans. 这三者都具有相同的运行时行为，选择哪种模型只是您进行设计时的偏好问题。

事实上，可以将极其复杂的视图创建为级联计算视图(cascaded Calculation Views)，视图编译器将折叠(collapse)和简化视图，并创建一组优化后的列投影、计算、向量连接和联合作为单个计算场景。这种处理方式可以被视为 HANA 环境下进行建模的一个亮点。

请注意，脚本化计算视图(Scripted Calculation View)仍然有其一席之地——您可以在 SQLScript 中调用业务函数、预测函数和其他存储过程对象。当然，在 HANA SPS09 中，也可以通过图形建模器来完成其中的一些工作。

ITPub博客

关于 HANA CE Function

最新文章