來自多個增量載入的臨時表的維度表和事實表中的一致數據
為了為我們的數據倉庫創建數據模型，我們使用 ERP 供應商提供的工具。這可能很重要，因為它有它的局限性。我們以一定的設計繼承了這個環境。我們是數據倉庫的新手，而這只是我們工作的一部分，所以我們有一個陡峭的學習曲線。:-) 我們數據倉庫的基本設計是這樣的：
$$ source $$->$$ staging table $$->$$ Persistent Staging Area table $$->$$ set of views $$->$$ dimension/fact table $$ 暫存表：只有1個源表，載入前截斷，只載入自昨天以來的記錄增量持久暫存區表：從不截斷，載入暫存表的增量記錄。所以結果是記錄永遠不會被刪除，目前記錄是根據自然鍵更新的。
每晚都會截斷並重新載入所有維度和事實表。由於持久的暫存區，這是可能的。目前，維度表或事實表中不需要歷史記錄。這在過去可能是這樣設計的，因為如果您願意，您可以完全重建所有維度和事實表。它使更改更容易實施，因為您不必每次都備份數據等。
我們正在重新考慮我們的數據倉庫設計，因為我們在過去幾年中學到了很多東西。:-) 我們有 ETL 性能問題，所以我們想看看增量載入維度和事實表，但正在努力解決以下問題。
假設我們去掉了 Persistent Staging Area 層，所以我們只有載入了 delta 記錄的臨時表。我們有一個視圖 C，它結合了來自源表 A 和 B 的數據。這個視圖 C 是維度表 D 和事實表 F 的源。（這是一個非常簡化的範例）
現在，表 A 中記錄的列值發生了變化。該列值是維度表 D 中的一個屬性。由於視圖 C 基於 2 個增量載入的臨時表，我們將根據連接類型在視圖 C 中看到此記錄。假設它是一個左外連接。我們只看到表 B 欄位的 NULL 值，以及這個更改的列值。這將作為表 B 的欄位和表 A 的欄位值的 NULL 值輸入維度表 D。這當然是不需要的，因為它會使數據不一致。目前，使用持久暫存區解決了這個問題。使用持久暫存區，那裡的記錄將被更新並正確傳播到我們的維度，因為它每晚都會重新載入。我希望我已經解釋清楚了。
所以我們想看看如何去掉 Persistent Staging Area 層，但不知道如何應對這樣的變化。因此，我們僅將更改載入到臨時表並在重新載入之前截斷這些更改（以載入新更改）的場景。我不確定你通常會如何解決這個問題。在登台表和維度或事實表之間可能總是需要某種臨時登台？或者我在這裡錯過了什麼？
所以我的問題不是關於暫存表的增量負載，我知道 CDC，或者截斷和重新載入我們的維度和事實表是不好的做法，但我可能錯過了一些關於如何從暫存表中獲取數據的關鍵資訊（僅具有增量記錄）到您的維度/事實表（由許多源表組合而成），並且只有 1 個源記錄以一致的方式更改。應該有一些中間階段來使事情保持一致對嗎？
更新以下問題：
- 不，我們想看看改變結構是否能更好地支持我們的需求並提高性能。我們認為增量載入維度和事實以及刪除 PSA 將提高性能。保存歷史記錄將在維度表和事實表中完成，而不是在 PSA 中。
- 我試圖說明目前和需要的未來情況。轉換是通過創建視圖來完成的，有時可能是一個中間臨時表。這就是工具的工作方式，此時我們正在使用建構轉換。我們想研究替代目前數據倉庫工具的其他可能性。未來情況的圖片說明瞭如果我在表 B 中找到了一條新記錄，但在表 C 中沒有找到新記錄會發生什麼。由於表 A 中缺少該自然鍵，我們將失去該記錄或獲得 NULL 值，這會使維度包含不一致的數據。順便說一下，從功能的角度來看，我認為這樣的模型不會是正確的模型。
所以我認為這裡缺少一些東西。我不確定這是如何使用我們以外的其他工具建構的。我還沒有那種經驗。在我看來，要使這樣的模型包含一致的數據，您將需要某種形式的持久暫存。我的猜測只是我上面描述的這些模型從功能的角度來看是不正確的，但我不確定。
編輯2：
我添加了一個數據範例，並將視圖的連接類型更改為左外連接。這將準確顯示我試圖說明的行為。我希望很清楚。我沒有保存一些更改，所以我不得不部分地重建繪圖，因此它可能看起來有點奇怪。
編輯3：目前情況和未來情況的區別在於，新記錄將在目前情況下使用表B中的數據載入。在新情況下，表B數據不會載入到維度中。是我的想法錯了還是設計有問題？我添加了目前情況的數據範例。您現在有了一個範例，當在第 1 天和第 2 天插入新記錄時，不同情況會如何表現。在第 2 天，您可以看到在目前情況下，表 B 中的新記錄的數據將被載入到維度中。在新情況下，表 B 的數據不會被載入到維度中，因為它是左外連接，每晚都會截斷增量登台表載入，並且沒有 PSA。我希望這能讓事情變得清楚。
好的，在您概述的
Table A/Table B場景中，我們有三種可能性：
Table A並同時Table B更新/插入 - 現有邏輯有效Table AXORTable B更新 - 可以根據 定位記錄ColA，僅更新收到的表的記錄。Table AXORTable B插入 - 暫存記錄直到另一條記錄到達。如果它的停留時間超過 x 分鐘/小時/天，請標記。看起來＃3 是您要解決的問題，如果您在分期中保持記錄直到匹配到達，則應該可以解決。可能存在新記錄
Table A同時Table B到達的情況，如果您有時間戳，這將不是要解決的問題。保留審計表將有助於解決方案 2 可能導致的任何差異。
備查; 與bbaird聊天的結果對我來說是最後的結論。當您擁有像此處描述的“未來”架構這樣的架構並且數據模型不正確或源數據存在問題時，這種情況很可能發生。對我們來說，問題是我們沒有任何數據質量檢查機制來擷取插入的錯誤記錄，如“未來”情況中所述。這意味著我們的 PSA 實際上部分地起到了數據質量機制的作用。我從未閱讀過任何描述以這種方式使用 PSA 的文件、文章書籍。可能是因為您應該在 ETL 中內置數據質量檢查機制（這不僅是為了防止此類問題）。我們沒有這個，我們的工具非常有限。
在這種特殊情況下，將進行諸如“表 B 列 A 和列 B 不能為 NULL”或“所有列的值不應等於 NULL”或“NULL 值應始終轉換為“未知”之類的檢查。這將取決於每個模型的要求。