使用數據倉庫提供重組的非 BI 數據是不好的做法嗎？
主要目標是案例優化的數據表示。這個想法是從多個數據庫收集數據，將數據保存在數據倉庫中，並在數據集市中重構/連接數據（類似於跨多個數據庫的視圖）。基本上，目的是使訪問分佈在數據庫中的數據變得更容易。
正如您在圖片中看到的那樣，計劃是擁有依賴數據集市（顯示在圖片的上半部分），以避免像獨立數據集市那樣有多個清理和載入過程（顯示在圖片的底部）。數據倉庫的 BI 方面也將被使用，但與我的問題無關。只有 DB 中的數據會被更改。DW 中表示的數據僅用於閱讀目的。所以基本概念沒有受到傷害。但我仍然覺得這裡的 DW 被濫用了。
要回答我的問題，請包括以下幾點：
- DW被濫用了嗎？
- 是否有任何帶有適合（接近）實時功能的數據連接器的 DW？
- 有哪些替代方案可以滿足這些要求，以連接來自多個數據庫的數據，並以乾淨和結構化的方式實時表示它們，而無需大量的清理和載入流程？
第一個（頂部）範例本質上是為 BI 數據倉庫和數據集市設計 ETL 流程的最常用方法。您不想要較低的範例，因為您需要建構、部署/版本和故障排除相同程式碼的多個實例。
至於“濫用”與否，這一切都取決於您如何設計數據集市。通常，星型模式是為分析而設計的，但沒有什麼可以說它不適用於 OLTP 類型的工作。我會考慮在載入時重塑數據所需的工作量 - 是否值得額外的複雜性，還是直接從您的應用程序查詢源數據庫會更好？也許源數據庫中的數據庫視圖可以做同樣的事情，但複雜性要低得多？
對“實時”BI 實施要非常小心：建構解決方案的“實時”越多，它不可避免地就會變得越複雜。
一方面，每晚執行截斷和載入的程序的建構和執行相對簡單。
以及每小時執行的增量負載，您需要開始辨識源數據中新的、更改的甚至刪除的 (!) 行。這可能很難甚至是不可能的，這取決於源數據的結構或發送給您的方式。
一個完整的“實時”解決方案（在引號內，因為除非您只有源數據庫上的視圖，否則它不是真正實時的）可能需要對每個依賴表進行某種更改擷取、觸發器或類似的複雜邏輯。所有這些事情都可能對源數據庫的性能和穩定性產生不利影響。
當這些表互動時，它會變得更加複雜和昂貴，例如，如果您需要將雪花模式連接到星型模式中。
要回答您的第三個問題，幾乎所有 ETL 工具（SSIS、Pentaho 等）都將支持基本的數據倉庫 ETL。一旦添加了近實時邏輯，平台 ETL 工具的選擇就會變得不那麼相關（無論如何，您可能需要自己編寫大部分腳本），並且解決方案變得非常依賴源數據的數據庫平台以及基礎架構和數據倉庫的平台。