從 CQM 轉換為 DQM:Cognos 客戶的旅程

by 2020 年 1 月 30 日雲端0評論

無論您是考慮遷移到 IBM Cognos Analytics on the Cloud,想要使用 JDBC 驅動程序而不是本機數據庫客戶端,還是只想更好地了解查詢的性能相關特徵,採用 Dynamic Query Mode 都是一個好主意。

作為餐飲服務行業最值得信賴的領導者之一,Performance Food Group 最近作為持續改進過程的一部分從 Cognos 10.2.1 升級到 11.0.12 時,他們決定也將其軟件包從 CQM 更新為 DQM。 Sumit Kumar 是 PFG 的 IT 經理,負責監督報告、分析和諮詢,負責他們的包遷移,並負責克服他們在此過程中可能遇到的任何挑戰。

從 CQM 轉換為 DQM 的好處

Performance Food Group 遷移的原因有很多。 將 Sumit 和 PFG 作為一個整體進行轉換的主要好處之一是能夠使用包含來自同一報告中多個包的數據的報告。 動態查詢模式將允許 Sumit 使用包含來自多個主題領域(例如銷售、採購和庫存)的數據的報告,即使它們位於三個完全不同的包中。 Compatible Query Mode 沒有這個能力,所以選擇是顯而易見的。

從 Compatible Query Mode 轉換為 Dynamic Query Mode 還使他們能夠通過利用 64 位架構上的查詢執行來大大減少報表執行時間。 通過遷移,Sumit 知道他們不僅在鋪設基礎設施以使未來升級更容易,而且還使 Performance Food Group 能夠在其自動化中啟動預測分析。

轉換的好處顯而易見,但未來的挑戰是什麼?

在選擇了 13 個要轉換的 Cognos 包後,Sumit 在項目規劃和執行階段遇到了他的第一個障礙。

項目規劃和執行挑戰

第一 roadSumit 面臨的問題是在瀑布式交付或敏捷交付之間做出選擇。 Sumit 選擇後者進行 CQM 到 DQM 的轉換,因為它允許他獨立部署每個包。 當所有重要的報告都成功運行時,就會部署包,如果一些低優先級的報告有錯誤,他們無論如何都會部署包並稍後修復報告。 這使他們能夠在不浪費任何時間的情況下預先交付業務價值,但為了安全起見,他們保留了一個月的緩衝時間,以防他們需要 IBM 產品支持團隊的額外幫助。

現在 Sumit 和 Performance Food Group 已經克服了項目規劃和執行階段,現在是他們解決下一個問題的時候了:由於動態查詢模式中的包的行為而導致的技術和基礎架構挑戰。

“據 Sumit 稱,從 CQM 轉換為 DQM 非常值得花費時間和精力。 轉換後,報表執行時間平均減少了 60%!”

技術和基礎設施挑戰

Dynamic Query Mode 強制執行在 Compatible Query Mode 中可選的最佳實踐。 一個例子是使用帶正斜杠的連字符和星號作為註釋行,例如,'-' vs '/*'。 CQM 接受所有這些,而 DQM 有時接受,有時不接受,具體取決於位置。 這些看似小問題可能會導致零星錯誤甚至整個報告失敗。 高級過濾器、SQL 查詢和自定義計算中的註釋也已知會導致錯誤。 一種 比較sql查詢 工具被認為是為了格式化放置並減少該區域的錯誤發生,但調查進一步以查看所有錯誤發生。 在數據模型或包定義中包含 sum 函數也會產生錯誤,但這可以通過將其替換為 total 函數或 Sum() 與 Total() 來解決。

Dynamic Query Mode 還做出了 Compatible Query Mode 沒有的某些假設,從而導致報告輸出不同。 在 CQM 和 DQM 中運行報告可能會根據它們解釋函數的方式為您提供不同的結果。 例如,CQM 中的 Total(Total(Sales)) 將為您提供與總銷售額相等的結果並忽略重複的總數,而在 DQM 中它不會忽略重複的總數,從而為您提供不同的報告輸出。 同樣,在 CQM 和 DQM 中實現聚合選項的方式也各不相同。 計算/聚合列上的過濾器可能會導致不同的結果,具體取決於聚合屬性選擇,例如“聚合前”或“聚合後”。

其他挑戰

Dynamic Query Mode 可能會應用不同的操作順序,這可能會導致報告輸出發生變化。

  • 報告級別基數定義會導致報告輸出發生變化。
  • 即使在解決警告消息之後,報告驗證仍會顯示嚴重錯誤。 在報告編譯器向您顯示實際錯誤之前,必須修復所有警告消息。 如果報告未運行且僅顯示警告消息,則您必須先修復警告消息,然後報告才會顯示嚴重錯誤並允許您修復它。
  • 呈現包含大量數據的報告可能會因“Java 內存不足”問題而失敗,但可以通過禁用這些報告的報告屬性中的本地緩存屬性來修復,也可以通過增加查詢服務的配置內存來提供幫助
  • JVM 配置必鬚根據最佳實踐進行微調,以防止未來出現問題。

在結論

據 Sumit 稱,遷移過程非常值得花費時間和精力。 轉換後,報表執行時間平均減少了 60%! 他絕對建議將包從 CQM 轉換為 DQM,並將您的環境從 32 位轉換為 64 位。

考慮從 Compatible Query Mode 轉換為 Dynamic Query Mode 或最近轉換? 我們很樂意讓您與我們分享您的經驗或您可能擁有的任何提示和技巧!

 

想了解更多? 我們舉辦了一場 網絡研討會 在這裡,我們討論了 Performance Group 在遷移到 Dynamic Query Mode 時面臨的挑戰。 單擊此處回复網絡研討會。