數據倉庫開發的三大原則

Gartner 估計，近 70% 到 80% 的新啟動的商業智能項目都失敗了。 這是由多種原因造成的，從錯誤的工具選擇到 IT 和業務利益相關者之間缺乏溝通。 在成功實施跨行業的 BI 項目後，我希望在這篇博文中分享我的經驗，並強調商業智能項目失敗的關鍵原因。 本文將根據應管理數據倉庫構建方式的三個原則提出故障應對措施。 遵循這些數據倉庫概念應該可以幫助您作為數據倉庫開發人員在開發過程中導航，避免常見的坑洼甚至 BI 實施的天坑。

商業智能數據倉庫實施

雖然成功的商業智能數據倉庫的標準會因項目而異，但所有項目都需要滿足某些最低要求。 以下是成功的商業智能數據倉庫中通常存在的主要屬性列表：

• 價值：商業智能項目可以跨越數月甚至數年的過程。 但是，重要的是要在項目的早期向您的業務利益相關者展示數據倉庫的好處，以確保持續的資金和興趣。 理想情況下，利益相關者應該在項目的前三週內從新系統中獲得一些有意義的商業價值。
• 自助式 BI：等待 IT 完成數據請求或進行數據分析的時代已經結束。 現在，任何 BI 項目的成功都是通過它使業務用戶自己從系統中提取價值的能力來衡量的。
• 成本： BI 項目通常具有較高的前期實施成本。 為了平衡和抵消高昂的初始成本，設計維護成本低的倉庫非常重要。 如果客戶需要一個成熟的 BI 開發人員團隊來確保/診斷數據質量問題，對數據模型進行例行更改或處理 ETL 故障，則係統的預算成本將很高，並且有可能在一段時間後關閉.
• 適應性：適應不斷變化的業務需求的能力至關重要。 重要的是要牢記市場上提供的無數 BI 工具以及它們發展以包含更多功能和特性的速度。 再加上業務不斷發展，對倉庫的要求也會發生變化； 適應性要求數據倉庫的設計能夠在未來使用替代的 BI 工具，例如不同的後端或可視化工具，並且能夠適應經常無法預見的需求變化。

通過我構建成功解決方案的經驗，或許更重要的是，參與失敗的項目，我得出的結論是，三個關鍵原則對於增加成功實施商業智能係統的可能性至關重要。 但是，在詳細介紹它們之前，讓我們從一些上下文開始。

什麼是數據倉庫？

在深入研究不同的數據倉庫概念之前，了解數據倉庫實際上是什麼很重要。

數據倉庫通常被認為是為幫助滿足業務實體的日常報告需求而創建的商業智能係統。 它們沒有與 OLTP 數據系統相同的實時性能要求（在標準實現中），而 OLTP 系統將只包含與業務的一小部分相關的數據，而數據倉庫則希望包含與業務相關的所有數據。業務。

只有當倉庫被視為“萬物數據”的中心樞紐，而不僅僅是生成運營報告的工具時，數據倉庫模型才能為企業帶來好處。 所有運營系統都應與數據倉庫進行雙向通信，以輸入數據並接收有關如何提高運營效率的反饋。 任何業務變化，例如價格上漲或供應/庫存減少，都應首先在您的數據倉庫環境中進行原型設計和預測，以便您的業務能夠可靠地預測和量化結果。 在這種情況下，所有數據科學和數據分析功能都將以數據倉庫為中心。

數據倉庫有很多組件，它不僅僅是一個數據庫：

• 數據庫是您存儲數據的媒介。
• 數據倉庫不僅包括從數據中提取業務價值所需的工具和組件，還可以包括集成管道、數據質量框架、可視化工具甚至機器學習插件等組件。

這是數據庫和數據庫倉庫結構之間差異的更直觀表示。 數據庫或新的邏輯數據元存儲（如 Hive）形成了數據倉庫恆星系統的中心恆星，所有其他組件作為其旋轉行星。 但是，與星型系統不同，數據倉庫可以有一個或多個數據庫，並且這些數據庫應該可以與新技術互換，正如我們將在本文後面討論的那樣。

第一數據倉庫原則：數據質量至高無上

數據倉庫只有在業務利益相關者信任其中的數據時才有用和有價值。 為了確保這一點，必須構建自動捕獲和糾正（在可能的情況下）數據質量問題的框架。 數據清理應該是數據集成過程的一部分，定期進行數據審計或數據分析以識別任何數據問題。 在實施這些主動措施的同時，您還需要在不良數據滑過這些門並由用戶報告時考慮採取被動措施。

為確保用戶對數據倉庫系統的信心，應優先調查業務用戶突出顯示的任何不良數據。 為了幫助完成這些工作，應在平台中構建數據沿襲和數據控制框架，以確保支持人員能夠快速識別和修復任何數據問題。 大多數數據集成平台都集成了一定程度的數據質量解決方案，例如 MS SQL Server 中的 DQS 或 Informatica 中的 IDQ。

如果您在數據集成管道中使用商業工具，請利用這些內置平台，但除此之外，請確保構建有助於保持數據質量的機制。 例如，大多數數據集成工具缺乏跟踪數據沿襲的良好功能。 為了克服這個限制，可以使用一系列控製表構建自定義批處理控制框架，以跟踪系統內發生的每個數據流。

如果您的業務利益相關者在您的平台中遇到質量不佳的情況，很難重新獲得他們的信任，因此對數據質量框架的前期投資應該是值得的。

第二個數據倉庫原則：翻轉三角形

該圖說明了大多數數據倉庫的實施和使用中的工作分工。

大部分精力都花在了構建和維護倉庫上，而擁有用於業務分析的倉庫所帶來的增值只是一小部分工作量。 這是商業智能項目經常失敗的另一個原因。 有時，項目週期需要很長時間才能向客戶展示任何有意義的價值，當系統最終到位時，仍然需要大量的 IT 工作才能從中獲得任何業務價值。 正如我們在介紹中所說，設計和部署商業智能係統可能是一個昂貴且漫長的過程。 因此，利益相關者理所當然地期望迅速開始從他們的商業智能和數據倉庫工作中獲得附加值。 如果沒有實現附加值，或者如果結果為時已晚而沒有任何實際價值，那麼沒有什麼能阻止他們拔掉插頭。

數據倉庫開發的第二個原則是翻轉三角形，如圖所示。

您選擇的商業智能工具和部署的框架需要確保進入倉庫的大部分工作是提取業務價值，而不是構建和維護它。 這將確保您的業務利益相關者的高度參與，因為他們將立即看到投資該項目的價值。 更重要的是，您使企業能夠自給自足地提取價值，而無需如此強烈地依賴 IT。

您可以通過在構建倉庫時遵循增量開發方法來遵守此原則，以確保您盡快交付生產功能。 遵循 Kimball 的數據集市策略或 Linstedt 的 Data Vault 數據倉庫設計方法將幫助您開發可增量構建的系統，同時順利應對變化。 在您的平台中使用語義層，例如 MS SSAS 多維數據集，甚至是 Business Objects Universe，為您的數據提供易於理解的業務接口。 在前者的情況下，您還將為用戶提供一種從 Excel 查詢數據的簡單機制——它仍然是最流行的數據分析工具。

結合支持自助式 BI 的 BI 工具（如 Tableau 或 PowerBI）只會有助於提高用戶參與度，因為與編寫 SQL 相比，查詢數據的界面現在已大大簡化。

在填充數據庫之前將源數據存儲在數據湖中將有助於在入職流程的早期向用戶公開源數據。 至少高級用戶（例如商業量化分析師）現在可以通過在文件頂部連接 Hive/Impala 等工具來消化源數據（通過原始文件）。 這將有助於將企業分析新數據點所需的時間從數週減少到數天甚至數小時。

數據庫倉庫原則之三：即插即用

數據即將成為石油的數字等價物。 近年來，我們見證了可用作數據倉庫平台一部分的工具數量和創新速度呈爆炸式增長。 引領潮流的是目前可用的無數可視化工具，後端的高級選項緊隨其後。 鑑於這種環境和業務需求不斷變化的傾向，請務必記住，隨著業務和技術的變化，您需要更換技術堆棧的組件，甚至隨著時間的推移引入/刪除其他組件。

根據個人經驗，如果一個平台能夠持續 12 個月而不發生某種重大變化，那將是幸運的。 在這些情況下，合理的努力是不可避免的； 但是，應該始終可以更改技術或設計，並且您的平台應設計為滿足這種最終需求。 如果倉庫的遷移成本太高，企業可以簡單地認為成本不合理並放棄您構建的內容，而不是將現有解決方案遷移到新工具。

建立一個能夠滿足所有可以想像的未來需求的系統是不可能的。 因此，在構建數據倉庫時，需要一定程度的理解，即您現在設計和構建的任何東西都可以被時間取代。 為此，我主張盡可能使用通用工具和設計，而不是將您的平台與運行它的工具緊密耦合。 當然，這需要經過仔細規劃和考慮後才能完成，因為許多工具（尤其是數據庫）的強大之處在於它們的個性和緊密的互補性。

例如，與使用 Python 或 SSIS 在數據庫外部提取和處理數據相比，使用數據庫中的存儲過程來創建新的業務分析數據時，ETL 性能得到顯著提高。 關於報告層，可視化工具將提供其他工具無法提供的某些功能——例如，Power BI 支持自定義 MDX 查詢，但 Tableau 不支持。 我的意思不是提倡在您的系統中拋棄存儲過程或避免使用 SSAS 多維數據集或 Tableau。 我的目的只是為了宣傳在證明任何將您的平台與其工具緊密耦合的決定時要注意的重要性。

另一個潛在的天坑是在集成層中。 使用 SSIS 之類的工具進行數據集成非常容易，因為它具有調試功能或易於與 SQL Server 平台一起使用。 然而，將數百個 SSIS 包遷移到另一個工具將成為一個非常昂貴的項目。 如果您主要在做“EL”，請使用通用工具進行處理。 使用 Python 或 Java 之類的編程語言編寫一個通用加載器來加載暫存層將有助於減少您原本需要的單個 SSIS 包。 這種方法不僅有助於降低維護和未來遷移成本，而且有助於自動化數據載入過程的更多方面，而無需編寫新的單個包（與原則 2 一致）。

在所有這些情況下，您需要在直接收益和未來遷移成本之間做出實際折衷，以確保倉庫不會因為無法處理變更或變更需要太多時間而報廢，努力，或者投資。

包起來

某個商業智能係統可能失敗的原因有很多，也有一些常見的疏忽可能導致最終失敗。 不斷變化的技術環境、由於誤解為操作系統的次要優先級而導致的數據系統預算有限，以及處理數據的絕對複雜性和困難性意味著在設計和設計時不僅需要仔細考慮近期目標，還需要仔細考慮未來計劃。構建數據倉庫的組件。

本文中概述的數據倉庫基礎知識旨在幫助您在考慮這些重要事項時提供指導。 當然，考慮到這些原則並不能保證成功，但它們肯定會大大幫助您避免失敗。