本文內容來自 SAP 社區(qū)博客：Calculation Engine (CE) Functions – Rest in Peace

CE Function，即 Calculation Engine，是 HANA SPS02 中引入的一種機制，它允許直接訪問 HANA 列存儲。它們允許極其精確地控制如何精準投影、計算和聚合列。

事實上，它們是原始 HANA 列存儲如何建模向量函數(shù)的直接表示。

CE Function 執(zhí)行的效率如何？

它們完全繞過了 SQL 優(yōu)化器，意味著您想要執(zhí)行的任何操作都在列存儲中運行，并且您始終可以獲得 HANA 的全部性能。CE 函數(shù)總是在列引擎中運行，并且如果您返回適度的結果集，則能獲得很高的執(zhí)行效率。它們實際上有效地編譯成一種稱為 L 的語言，它是 HANA 的中間語言，與 C++ 非常相似。

不過 CE Function 的編寫也比傳統(tǒng)的 SQL 要麻煩一些。

您必須指定每一列，當存儲過程的取數(shù)邏輯越來越復雜時，這往往意味著大量的復制和粘貼以及代碼的激活。編輯器不會給你太多幫助，錯誤信息也很簡潔。簡而言之，您必須是一名專業(yè)的 SQL 程序員，并且對 HANA 列存儲具有一定的實操經(jīng)驗，才能熟練使用 CE 函數(shù)編寫良好的 SQLScript。

然后，2012年時，伴隨著 HANA SPS04 的“Project Orange” 這個項目的進展，HANA 數(shù)據(jù)庫已經(jīng)足夠成熟，可以用于 SAP BW，但 BW 從未使用過 CE 功能。相反，BW 團隊有自己的專有方式來使用 HANA。

這很快被證明是 BW 中的一個限制，導致一個新的概念誕生了：Calculation Scenario. 現(xiàn)在，當您在 BW 7.4 中編譯 BW 對象時，會創(chuàng)建一個 HANA 視圖，該視圖可以通過 BW 的 OLAP 引擎訪問，也可以直接被 HANA 數(shù)據(jù)庫訪問。兩者是可以互換的，但是 CE 功能對于 BW 的需求來說限制太多了。

然后在 2013 年出現(xiàn)了 HANA 上的 Business Suite。商務套件通過 OpenSQL 接口廣泛使用 ANSI SQL，并在 HANA SPS06 中首次亮相。由于 Business Suite 的編程方式，HANA 團隊必須讓 SQL 的執(zhí)行效率比以前更高才行，并且 SQL 優(yōu)化器進行了大量開發(fā)。從 HANA SPS06 開始，SQL 和 HANA Information Views 之間通常幾乎沒有區(qū)別。

在此期間，超過一半的 SAP HANA 客戶使用 BW，而 Business Suite 也是新增 go live 客戶數(shù)量增長最快的 SAP 產(chǎn)品之一。這些產(chǎn)品本身都沒有使用 CE 技術，因此 CE 技術得到的開發(fā)關注比較有限，幾乎沒有引入新功能。從 HANA SPS05 開始，就沒有新的優(yōu)化了。

從 HANA SPS07 開始，我們發(fā)現(xiàn) Graphical Calculation Views 總是比 CE Function 要快。在HANA SPS08 中，我們發(fā)現(xiàn) SQL、Analytical View 和 Graphical Calculation Views 在很多情況下都有完全相同的 Execution plans. 這三者都具有相同的運行時行為，選擇哪種模型只是您進行設計時的偏好問題。

事實上，可以將極其復雜的視圖創(chuàng)建為級聯(lián)計算視圖(cascaded Calculation Views)，視圖編譯器將折疊(collapse)和簡化視圖，并創(chuàng)建一組優(yōu)化后的列投影、計算、向量連接和聯(lián)合作為單個計算場景。這種處理方式可以被視為 HANA 環(huán)境下進行建模的一個亮點。

請注意，腳本化計算視圖(Scripted Calculation View)仍然有其一席之地——您可以在 SQLScript 中調用業(yè)務函數(shù)、預測函數(shù)和其他存儲過程對象。當然，在 HANA SPS09 中，也可以通過圖形建模器來完成其中的一些工作。

總結

以上是生活随笔為你收集整理的关于 HANA CE Function的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。