獲取演示
登入
首頁 9 BI 技術論文的持續集成

首席技術官 Lance Hankins 的技術論文， Motio 公司

持續集成對商業智能的好處

商業智能行業如何從持續集成中受益

在行業術語中，商業智能 (BI) 仍然是一個相對較新的領域。 像許多基於技術的行業一樣，BI 已經在其早期階段取得了進展，實施受臨時流程和廣泛不同的成功影響。 過去，由同一組織實施的多個 BI 項目在實現非常相似的目標的過程中採用截然不同的方法是司空見慣的。 然而，近年來，具有前瞻性思維的組織通過集中 BI 知識和專業知識提高了他們的 BI 能力。 隨著“BI 能力中心”(BICC) 和“BI 卓越中心”等模型越來越流行，這些組織現在正在為整個組織定義 BI 技術堆棧、工具集、流程和技術，以確保成功並最大限度地提高投資回報率。新的 BI 計劃。 他們還從側翼類別的最佳實踐中汲取靈感，在這種情況下，是軟件行業。

BI 社區尚未認可的一種最佳實踐是持續集成 (CI)。 在軟件開發領域，CI 是在開發環境中頻繁自動構建和冒煙測試軟件代碼庫的過程。 在典型的啟用 CI 的軟件項目中，“構建服務器”監視項目的源代碼存儲庫，並在檢測到更改時提取源的干淨副本，進行完全重建，運行所有回歸測試，並主動通知開發人員任何失敗的團隊。 每個完全成功的周期 1 都會為軟件產品生成一組可安裝的二進製文件。

這種頻繁、自動化的集成可以快速捕獲引入系統的任何錯誤（通常在引入後的幾分鐘內），並且可以更輕鬆地查看是誰引入了錯誤以及何時引入的。 缺陷和不兼容性在引入後的幾分鐘內被發現時，糾正起來總是更便宜（特別是如果它們從未脫離開發環境）。

持續集成（CI）的主要原則

  • 可重複的、自動化的構建和測試過程。
  • 這些自動化的構建和測試過程經常執行，以便及早發現集成問題。
  • 頻繁的自動化週期為損壞/不兼容的工件提供早期警告。
  • 對系統的所有更改幾乎立即進行驗證和測試。

毫無疑問，CI 實踐已成為現代軟件開發組織武器庫中的寶貴工具。 CI 提高了軟件開發團隊的質量和動力。 接受 CI 概念的經驗豐富的開發團隊無法想像沒有它就可以開展任何大型軟件項目。

自 2000 年代初以來，CI 的實踐在軟件開發行業的採用率中得到了顯著的提升，這在很大程度上要歸功於 Martin Fowler 等個人的開拓性努力2 和肯特貝克。

BI 行業是否也能從持續集成的實踐中受益？

絕對地。 未來幾年，CI 的實踐將因其應用於現代 BI 開發環境的巨大潛力而得到認可。 BI 生態系統本質上是複雜的（見圖 1）。 它們通常由許多相互依存的活動部件組成。 例如，典型的 BI 生態系統可能包含：

  • 多個上游數據源。
  • ETL 流程定期從這些上游源中提取、清理和加載數據到數據集市或數據倉庫中。
  • 許多 BI 產品在這些集市或倉庫之上添加了一個“模型”層。
  • 專業 BI 作者根據此模型層（例如報告）構建 BI 內容。

 

上游數據源典型的BI生態系統

正如經驗豐富的 BI 從業者所證明的那樣——這些層中任何一層的微小變化都可能波及整個系統——在最終的 BI 輸出中產生錯誤或低效。 根據 BI 團隊在發布週期中所處的位置，這些錯誤或低效可能會在數天、數週甚至數月內被忽視。

下面是一些現實世界的例子：

  • 模型層看似無害的修改會導致數月未編輯的報告的數字發生意外變化。 這些更改還會降低同一報告的性能（這種情況更難以手動量化和檢測）。
  • 數據庫中視圖的更改會導致報表運行時間急劇增加。
  • 建模者重命名或刪除報表所依賴的列。
  • 報表作者嘗試優化報表，但在設置可選參數時，新報表不會產生正確的結果。

在大多數 BI 開發環境中，對正在開發的 BI 內容的測試通常以非常手動的方式完成（例如“運行報告、檢查數字、驗證它們是否正確”）。 BI 團隊傾向於將此手動測試集中在他們正在積極更改的工件上，而不是那些最近未修改的工件。 當對系統較低級別的更改開始向上波動並影響許多 BI 工件時，這種趨勢會導致未被發現的問題。

大多數組織會定期將 BI 內容的基線從開發環境交付到測試或質量保證 (QA) 環境中，在那裡他們將接受 QA 專業人員的更正式的測試。 根據 QA 團隊的徹底性，這裡可能會發現缺陷或性能下降，但此時，糾正這些問題的成本已大大增加。 一旦缺陷從開發環境中消失（例如進入 QA 環境），糾正它的成本就會高得多。 典型的糾正工作流程包括創建描述如何重現缺陷的問題單（由 QA 團隊）、BI 團隊對所有待處理問題單進行分類（以確定哪些問題具有優先權）、開發中問題的重現、實施修復，然後將另一個基線重新部署到 QA。 同樣，在生產環境中發現的缺陷比在 QA 中發現的缺陷修復起來更昂貴。

典型的 Staged 環境、開發環境、QA 環境、生產環境

使用 CI 的原則，BI 開發團隊可以主動檢測此類問題（通常在導致它們的更改的幾分鐘內），並在 BI 內容仍在開發環境中時採取糾正措施。 這意味著校正的總體成本要便宜得多。

那麼如何將 CI 的原則應用於典型的商業智能項目呢？ 對於一些具體的例子，我們將考慮 MotioCI™，一種商業工具，支持商業智能開發環境的持續集成。 MotioCI 為 BI 團隊提供以下功能：

商業智能的持續集成

  1. 根據相應模型自動驗證所有 BI 工件。 這可確保任何模型或數據庫更改不會“破壞”現有的 BI 工件。
  2. 為每個工件自動執行測試用例。 這些測試用例可用於確保以下事項：
    1. 工件的執行產生了準確的數據
    2. 工件的執行產生了預期的數據量
    3. 工件的性能是可以接受的（執行在預期的時間內完成）
  3. 自動一致性檢查。 對於每個工件：
    1. 驗證它是否符合顏色、字體、樣式、嵌入圖像等方面的既定項目或公司標準。
    2. 驗證各個工件的參數名稱是否一致
    3. 驗證工件之間的鑽取關係仍然有效
  4. 跟踪 BI 生態系統的變化，以便當測試開始失敗時，項目利益相關者可以清楚地了解自上一個週期以來“誰改變了什麼”。 例如：
    1. 更改了哪些模型（由誰更改？）
    2. 更改了哪些工件（由誰更改？）
    3. 相關數據源是否有架構更改？
    4. 相關數據源中的數據量是否發生了劇烈變化？

通過自動化上述過程並使其頻繁運行，團隊生成的 BI 內容將在仍處於開發環境中時不斷驗證其準確性、一致性和性能。 如果 CI 流程檢測到故障，它將主動將問題通知 BI 團隊，並將自上次成功循環以來對 BI 生態系統發生的更改進行分類。 這種方法使 BI 團隊能夠快速注意到由最近的更改引起的問題，採取糾正措施並最大限度地降低成本。

為 BI 實施持續集成的淨結果

  1. 錯誤、低效率和違反標準的行為很早就被發現（通常在引入後的幾分鐘或幾小時內）。
  2. BI 團隊獲得了無數小時，否則需要手動測試所有工件以確保某些東西沒有損壞，從而節省時間，同時保持動力（它允許 BI 作者專注於真正的開發任務）。
  3. BI 團隊在其 BI 生態系統中更加了解“誰在改變什麼”。
  4. BI 團隊產生的輸出質量要高得多。
  5. 上游 QA 組織可以將精力集中在更高級別的測試上（在將 BI 內容提升為 QA 之前，所有“懸而未決的果實”都會被自動過濾掉）。

總之，隨著 BI 行業的成熟並在商業智能的整合、管理和應用方面建立最佳實踐，新興的 BICC 應檢查和利用側翼類別（特別是軟件行業）的經驗教訓。 CI 不僅是軟件行業的最佳實踐，而且正在演變為標準操作程序。 隨著 CI 等經過驗證的實踐被採用，BICC 將繼續作為核心業務學科成熟，不僅通過提高 BI 團隊的吞吐量（對可擴展性至關重要），而且通過提高其輸出的質量。 這種雙重影響代表了 BICC 性能的飛躍，並將很快成為現代 BI 環境的支柱。

 

 

1 一個成功的周期是一個沒有測試失敗的周期。
2 Martin Fowler 描述持續集成的原始論文發表於 2000 年 XNUMX 月。