在項目開發過程中，經常會遇到HANA模型運行效率的問題；
以我們項目為例，HANA平台要求模型運行時間不能超過10秒，但是在大數量和計算邏輯復雜的情況下（例如：ERP中的BKPF和BSEG量表的年數據總量超過20億條），HANA模型的運行時間基本上都在1分鍾以上。在不關聯其它表，單單是幾個板塊的BKPF和BSEG表UNION ALL，運行時間都超過1分鍾。鑒於這種情況，項目組對HANA模型是否存在優化空間，進行了分析和探討，也請教了HANA平台的專家對HANA的優化給出可行性建議。
最終的分析結果，最簡單、最高效的優化方法就是減少數據量，當然這個方法基本上不用說，沒什么技術含量，僅僅是數量級的減少。對我們程序員來說，當然不能滿足這么簡單粗暴的方法。
經過討論，制定幾條優化的方向：
1.將復雜的可視化模型通過SQL SCIRPT替換；
2.現有的模型都是通過計算視圖實現的。查看了相關資料后，發現HANA的屬性視圖、分析視圖、計算視圖對應不同的處理機制。屬性視圖擅長大數據量的關聯。分析視圖適合邏輯運算。計算視圖是在效果上可以理解為集合屬性和分析視圖的兩種功能。於是采用將數據量比較大的關聯和匯總通過屬性視圖實現。
3.拆分大的模型為幾個小的模型組合。
4.圖形化和SQL SCRIPT結合使用；
5.模型落地；
確定了方向后，項目組開始針對以上幾點進行驗證；
首先，將復雜的可視化模型全部用SQL實現，實驗的結果並不理想。於是上網查相關資料，發現可視化模型和SQL模型的處理機制不一樣，HANA對可視化模型的運算速度要高於SQL的運行效率。而我們將SQL模型和可視化模型的運行速度進行比較，發現SQL模型的運行時間要大於可視化模型。例如，同樣的數據量，同樣的邏輯，最終的結果是SQL的運行時間比可視化模型的運行時間多一秒左右。當然這只是經過多次運行以后得出的規律行時間差。通過以上的對比，我們發現SQL替換可視化模型的方案不可行。
其次，我們將BSEG和BKPF幾大板塊UNION ALL的過程以屬性視圖實現，通過最后實驗對比，發現屬性視圖並不比計算視圖速度快。
再次，拆分大的模型為幾個小的模型組合。經過分析，我們發現HANA實際上是動態查詢機制，在計算過程中並不存儲中間計算數據，也就是說，不管你拆分成幾個模型，最終的結果都是從最底層開始，逐漸的累積到最后，形成一個大的SQL動態的查詢數據。通過對最終視圖的執行計划分析，我們發現最終視圖的執行計划包含了幾個小模型的運算軌跡，按照小模型的運算軌跡累加，最終得到最終模型的結果。實際上拆分成幾個小模型，理論上來講運行速度比不上一個完成的大模型的運行速度。舉個例子，有A、B、C三個視圖，邏輯關系是A調用B視圖，B調用C視圖，假設A是B的聚合結果，在C上做數據排重處理，如果C包含6列，其中一列是差異項，其它幾列部分差異，那么在B中，不點亮C中的差異項，那么B中不點亮差異列的PROJECT會自動排重，即使你沒有做排重操作，一樣會排重其它幾列的重復項。也就是說HANA的模型是通過動態SQL查詢數據，在查詢的過程中，HANA會根據自己的規則對動態SQL進行優化。
第四，圖形化和SQL結合方式，在邏輯復雜的情況，通過可視化模型不能實現業務邏輯的需要，那么就需要應用SQL進行運算，這樣的結果在一定程度上來說是會減少運行時間，但這個減少的前提是通過可視化模型實現復雜業務邏輯會以增加PROJECT的方式實現業務邏輯，這樣會給可視化模型造成很大的壓力，因此會增加運行時間。所以，這個方法只是對可視化模型的補充，並不是優化。
第五，模型落地，實際上就是動態查詢物化，這樣減少了中間的運算過程，很大的提高了運行效率，但是我本人認為這並不符合HANA本身的內存存儲、內存運算的機制，傳統數據庫依然可以通過物化視圖的方式實現運行效率的提高，並不代表優化的可行。
通過以上幾種分析，最終發現並沒有達到我想要的優化結果。但是也不是一無所獲。在驗證的過程中，我們確認了HANA運行機制的幾個關鍵點：
1.HANA模型可以理解為動態的SQL查詢。
2.HANA模型的運算邏輯從下到上的整體運行。
3.計算視圖實際上包含了分析視圖和屬性視圖的運行機制。
以上幾點的確認，為我們接下來進一步分析優化可行性提供基礎論據；
經過實際數據的驗證和分析，以及項目組成員和HANA平台專家的討論，最終我們總結出以下幾點是HANA優化的可行方案：
1.減少數據，通過FILTER、JOIN的先后順序、左右關系盡量減少數據量。在最底層視圖中，進行數據過濾，通過關聯關系剔除數據以達到數據量減少的目的。我們經過驗證發現通過JOIN的先后順序會優化視圖運行時間，減少時間在一秒左右。
2.減少PROJECT和aggregation的數量。在建模過程中，要先根據需求對模型進行設計。設計過程中，盡可能的最大化的利用PROJECTION，減少不必要的PROJECTION。因為HANA的運行軌跡是按照模型的軌跡進行運算的，所以每增加一個PROJECTION就會增加一次運算，哪怕是最基本搜索。
3.減少相同數據的使用次數。比如在開發過程中，我們會將同一部分數據通過不同條件分成兩個PROJECTION，然后再對兩個PROJECTION進行邏輯運算，這樣的應用根據HANA的運行軌跡分析，會將同一部分數據進行兩次運算，數據量級會增大，影響運行效率。可以通過行專列，或者IF條件對不同條件的數據進行計算。這樣的話就減少了同一量級數據的重復使用。
4.減少點亮不必要字段，這個很好理解，畢竟HANA是列式存儲，每增加一列，會增加參與運算的數據量。
5.在新建列的時候，盡量避免在同一視圖中使用CE運算機制和SQL運算機制。要么使用CE運算機制，要么使用SQL，不要既有CE又有SQL。畢竟兩個運算機制不一樣，混在一起使用會增加運算負擔。
以上幾點經過我們項目組的分析和驗證，是有效的優化HANA模型的方法。
雖然我們最終找到了HANA的優化方法，但是我不並滿意。從以上幾點，我們可以很直觀的感覺到，對HANA底層的認知，還是浮於表面，並沒有深入到HANA的內部機制，從內部機制和使用規范上進行優化。也就是說HANA對我們來說就像一個黑盒一樣，我們能看到顏色、形狀等這些表象的東西，並沒有打開盒子看內部構造，所以提出的優化方案都很膚淺。
曾經有大神說過，理論上來說HANA不存在優化的必要，只要資源足夠，那么HANA的運行效率是不需要擔心的。但是從技術角度來說，我不認可這樣的觀點。如果不去研究深層次的東西，只是簡單粗暴的堆積木，那么對技術的提高以及能力的提高沒有任何幫助，最終淪為真正的搬磚的。
我始終認為，在技術的路上，要不段深挖，不斷的探索，不段的嘗試，才能提高自己，看清前路。