SAP HANA專案過程中優化分析以及可行性驗證
在專案開發過程中，經常會遇到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的執行效率是不需要擔心的。但是從技術角度來說，我不認可這樣的觀點。如果不去研究深層次的東西，只是簡單粗暴的堆積木，那麼對技術的提高以及能力的提高沒有任何幫助，最終淪為真正的搬磚的。
我始終認為，在技術的路上，要不段深挖，不斷的探索，不段的嘗試，才能提高自己，看清前路。