在專案開發過程中，經常會遇到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的執行效率是不需要擔心的。但是從技術角度來說，我不認可這樣的觀點。如果不去研究深層次的東西，只是簡單粗暴的堆積木，那麼對技術的提高以及能力的提高沒有任何幫助，最終淪為真正的搬磚的。
我始終認為，在技術的路上，要不段深挖，不斷的探索，不段的嘗試，才能提高自己，看清前路。
儲存過程中的優化建議
一 盡量避免對同一張表尤其是資料量較大的表進行重複訪問，可以考慮先根據條件提取資料到臨時表中，然後再做連線。二 儘量減少update 語句的使用，盡量使用select 語句查出盡量簡練的資料然後使用update 應為在資料庫操作中update 要鎖表而select 不會三 盡量避免游標的使用，在運算...
TensorRT優化過程中的dropout問題
使用tensorrt之前，你一定要注意你的網路結構是否能夠得到trt的支援，無論是cnn還是rnn都會有trt的操作。例如 tf.nn.dropout features,keep prob trt就不支援。這個也不奇怪，因為trt在要求輸入中，只要你傳入樣本資料，那你就不能feed乙個數值，所以以後...
專案過程中的角色和職能
專案管理的角色 1。專案經理 2。業務專家 3。系統設計師 4。程式工人 5。程式研發員 6。標準化監控人員 7。產品質量管理員 8。專案資源管理員 1。專案經理 專案的主管人員，也是專案的決策者。1。負責把握專案範圍，與客戶談判 處理商務事情。2。要負責專案開發的進度，調配專案資源。3。掌握專案變...