從零開始構建OLAP解決方案時應該記住什麼？

Question

我正在爲一家運行基於MS SQL數據庫服務器的軟件產品的公司工作，並且通過多年來我在PHP中開發了20-30個相當先進的報告，直接從數據庫中獲取數據。這非常成功，人們對此感到滿意。

但它也有一些缺點：

• 對於新的變化，它可以是相當密集的發展
• 用戶不能嘗試多與數據 - 它被鎖定到一個硬編碼的視圖
• 它可以爲大報告

我正在考慮逐漸將基於OLAP的方法，它可以從Excel或一些基於Web的服務進行查詢會很慢。但我希望這樣做的方式是在IT環境中引入最少量的新複雜性 - 最少量的不同服務，同步作業等等！

我在這方面有一些問題：

1）工作流相關：

• 什麼是「黑盒子SQL服務器」的良好發展路線，以「OLAP準備使用」 ？
• 應該設置哪些服務器和服務，以及應該編寫哪些腳本？
• 哪些是最難/最關鍵/最耗時的部件？

2）ETL：

• 我想這是最好有單獨的服務器爲他們的數據倉庫和生產SQL？
• 這些如何保持同步（推/拉）？使用哪些技術/語言？
• 對我來說，SSIS看起來過於複雜，圖形化的工作流程對我沒什麼吸引力 - 我寧願喜歡一個基於文本的腳本來完成這項工作。這是可行的嗎？
• 或者只有一個源和一個目的地使用圖形客戶端有利嗎？

3）發展：

• 這如何（數據集成的多，分析服務）可以有效地從CLI工具維護？
• 設置可以輕鬆地在生產和開發之間來回切換嗎？

我很滿意任何只涵蓋其中一部分的答案 - 儘管它是MS環境，但我也有興趣瞭解其他技術的優勢。

Answer 1

我只有與微軟OLAP的經驗，所以這裏是我對於我所知道的兩分錢：

1. 如果要實現立方體，那麼生產的SQL Server從源多維數據集分開。多維數據集需要很多SELECT DISTINCT column_name FROM source.table。您不希望多維數據集處理阻止您的關鍵任務生產系統。

2. 雖然您可以使用標準關係表實現OLAP多維數據集，但您會很快發現，除非您的數據是分類帳式系統，否則您可能需要完全重新處理事實和維度表，並且這將需要重新查詢源數據庫一遍又一遍地。對於構建一個單獨的數據倉庫來說，這對於事實表使用分類帳式事務是一個很大的爭論。例如，如果客戶訂購了一些東西然後取消它，那麼您的源系統可能會將其作爲狀態更改進行跟蹤。在您的事實表中，您可能需要將此顯示爲具有正數量和收入流的排序以及具有負數量和收入流的取消行。

3. 對於您的環境來說，OLAP可能會矯枉過正。您似乎提出的主要問題是您的報告是靜態的，用戶希望直接訪問數據。您可以構建數據模型，併爲SSRS中的用戶提供Report Builder訪問權限，或者在Cognos，Business Objects等其他BI套件中編寫訪問權限報告。我通常不推薦這種方法，因爲它超出了大多數用戶應該具有的方式知道獲取數據，但在一家小商店這可能已經足夠並且很容易實現。讓我們面對它 - 用戶通常只想將數據導入到Excel中以進一步操縱它。因此，如果您不想爲他們提供Web前端，而只想讓他們從Excel中獲取數據，則可以讓他們直接訪問數據庫中的生產數據副本。這種方法的缺點是用戶通常不瞭解SQL或數據庫關係。 OLAP可幫助您避免強制用戶學習SQL或關係，但在您的最終實現起來並不容易。如果你只有幾個高級用戶需要這種訪問方式，那麼可以很容易地告訴少數高級用戶如何在Excel中對數據庫進行基本查詢，他們將很樂意明天獲得此信息。 OLAP將不會在明天準備就緒。

4. 如果您只有幾種源數據系統，那麼您可以避免構建超級動態靜態報告。例如，我有一個用C＃編寫的報告，基本上允許用戶從30列的列表中選擇任意數量的列，並過濾幾個日期範圍字段和字段過濾器列表中的數據。這份簡單的報告涵蓋了來自最終用戶的所有特別報告請求中的大約40％，因爲它涵蓋了所有基本的核心客戶指標和領域。我們最近將此報告移至SSRS，並允許我們將字段數增加到大約100個，並改善了整體用戶體驗。無論報告平臺如何，即使在靜態報告系統的範圍內，也可以爲用戶提供一些動態的靈活性。

5. 如果您只有幾個數據庫，則可以備份和恢復數據庫作爲ETL。但是，如果你想做的事情超出這個範圍，那麼你可能會咬緊牙關並使用SSIS（或其他一些ETL工具）。一旦進入數據倉庫的ETL，您將使用面向圖形的設計工具。編碼適用於應用程序，但ETL更多地涉及工作流程，這就是爲什麼這些工具傾向於在圖形用戶界面上進行融合。你可以解決這個問題並嘗試從文本編輯器編碼數據倉庫，但最終你會失去很多。 See this post for more details on the differences between loading data from code and loading data from SSIS。

反饋如何使用塊上來關係數據存儲

它可以實現在關係數據存儲立方體，但也有使用這種方法的一些重大問題。技術上可行的主要原因是如何配置DSV。 DSV本質上是物理數據庫與多維數據集/維度定義之間的邏輯層。您可以定義命名查詢或在數據庫中創建視圖來平滑數據，而不是將關係表導入DSV。

這種方法的優點如下：

1. 這是比較容易實現的，因爲你沒有建立開始使用OLAP整個ETL子系統。

2. 這種方法很適合原型構建如何構建更長期的解決方案。您可以在1-2天內對其進行原型設計，並展示當今OLAP的一些優點。

3. 爲了支持OLAP多維數據集，一些非常非常大的表不必完全重複。我有幾十億個幾乎完全標準化的事實表的行表。他們沒有的唯一列是日期鍵，並且它們還包含一些根本不應該有空值的字段上的NULL值。您可以創建代理日期鍵併爲視圖或命名查詢中的空值設置值，而不是複製這些非常大型的表。如果您不會看到複製表的巨大性能優勢，那麼這可能會成爲數據庫本身以更原始格式留下的候選者。

這種方法的缺點如下：

1. 如果您還沒有建立一個真正的金博爾方法的數據倉庫，那麼你可能不是在總賬式跟蹤交易。 Kimball方法事實表（至少據我瞭解）總是通過增加和減少行來改變數值。如果有人取消部分訂單，則無法更新單個事務的多維數據集中的值。相反，您必須平衡具有負值的交易。如果您必須更新事務，那麼您將不得不完全重新處理多維數據集的分區以替換可能是非常昂貴操作的值。除非您的源系統是分類帳式交易系統，否則您可能必須在您的ETL子系統中構建分類帳式副本。

2. 如果您不構建Kimball方法數據倉庫，那麼您可能在數據庫中使用了不可見的主鍵和可能的非整數主鍵。這直接影響了多維數據集內的查詢性能。它也讓你擁有理論上不靈活的數據倉庫。例如，如果您有一個使用整數密鑰的產品訂購系統，並且您開始使用第二個產品訂購系統作爲傳統系統的替代品，或者與舊系統一起使用，您可能很難僅通過整合DSV，因爲每個系統都有不同的數據點，指標，工作流程，數據類型等等。更糟糕的是，如果它們具有相同的數據類型以用於訂單ID和訂單ID值在系統之間重疊，那麼您必須聲明一個代理鍵可以在兩個系統中使用。這可能是困難的，但並非不可能實現，而不使用扁平數據倉庫。

3. 如果從關係數據存儲開始，然後移動到展平數據庫，則可能必須構建系統兩次。坦率地說，我認爲重複工作的數量是微不足道的。您從關係數據存儲中構建多維數據集所學的大部分內容都將轉化爲設置新的OLAP多維數據集。但主要問題是，您可能會完全創建一個新的多維數據集，然後舊多維數據集的任何用戶都必須遷移到新的多維數據集。在SSRS或Excel中構建的任何報告可能會在此時中斷，並且需要從頭開始重寫。因此，重建多維數據集的主要成本實際上是重建依賴對象 - 而不是重建多維數據集本身。

讓我知道你是否希望我擴大上述任何一點。祝你好運。

Answer 2

你基本上要求百萬美元的問題「我如何建立一個DWH」。這不是一個可以果斷回答的問題。

儘管如此，這裏是一個Kickstart：

如果你正在尋找一個最低可行的產品，要知道，你是在一個數據環境，而不是一個純粹的軟件之一。在數據量大的環境中，增量式構建產品要困難得多，因爲在系統中引入變化的努力量要大得多。想想看，如果你在一個軟件中做出的每一個變化都必須以某種方式向後兼容你曾經做過的任何事情。現在你明白了微軟在:-)。此外，數據系統還涉及許多第三方工具，如DB，ETL工具和報告平臺。您所做出的選擇應該對您的系統的預期發展是可行的，否則您可能不得不完全取代這些工具。

雖然您可以從基於簡單複製SQL的數據庫克隆開始，然後將其聚合或推送到OLAP，但我建議您從一開始就使用真正的ETL工具弄髒自己的手。如果您預見到需要增長，這一點尤其如此。 10次​​中的9次，需要將增長。

如果您不介意成本，MS-SQL是數據庫的理想選擇。自然的ETL工具是SSIS，也是一個可靠的工具。

即使您的第一次轉換僅僅是「將此表並將其轉儲到那裏」，您仍可在流程管理（有作業運行？會發生什麼情況，如果失敗等）和調試方面獲得很多。另外，隨着要求和/或特殊情況必須處理，更容易有機地增長。