數據倉庫暫存架構
這是一個關於數據倉庫設計的問題。我們正在建立一個醫療保健數據倉庫，並從兩個主要的源系統開始，這些系統結合了大約 20,000 個表和 2 TB 的數據。1）它是高維數據 2）我們不想嚴重影響 OLTP 系統
我們選擇了增量式 Kimball 設計。我的問題是，是否應該對所有數據進行暫存，然後將其分類為插入/更新並放入數據倉庫。然後為下一次增量載入清除暫存數據。
這將為您留下 1 個數據副本。
另一種方法是將其增量載入到登台中，將其分類為插入/更新，並以與源系統相同的格式儲存。然後我們會將來自源系統的數據從完整副本合併到數據倉庫中。
這實際上會給您留下 2 個數據副本，一個以源系統的形式存在，另一個載入到實際的數據倉庫中。
對此的最佳做法是什麼？本來以為最好只把副本存入數據倉庫，每次載入時清空源表。
但是，在這種情況下，如果您必須返回現有維度並添加一列，則必須重新載入所有相關源表。另外，您會失去歷史嗎？
不過，將它儲存兩次似乎真的效率很低……只是想對設計、你的經驗和最佳實踐有一些想法。
我個人有用於提取、轉換和持久數據儲存的臨時表。
您是否進行完全導出或增量載入將取決於您擁有的工具、您的策略以及您的應用架構和數據是否支持它。有時您無法避免完全導出。
向維度添加列並不是什麼大問題，但回填歷史數據可能非常困難或根本不可能。試圖回顧性地重建應用程序如何看待某個時間點將是一項艱鉅的任務。你需要一個很好的案例來證明這一點。
您提到的所有事情都是可能的，但只有您才能決定成本/收益是否值得。
我們通常發現 ODS（操作數據儲存，源系統的副本）首先對 ETL 流程的分層非常有用（有助於維護和故障排除），但最終對操作報告非常有用。
您還可以添加索引和編寫瘋狂的查詢。反對。
您還可以使用它進行故障排除（因為您擁有從中載入的數據的副本，而不是真實源中的移動目標）。然後，如果您可以讓您的複制工具每五分鐘向 ODS 中註入一次，您就擁有了一個非常有用的架構。
忘記這裡的“低效率”。當您無法對 ETL 流程進行故障排除時，您將遇到真正的低效率，因為它被壓縮為一層，並且您沒有 ODS 層可用於故障排除。