數據倉庫ETL緩慢更改維度中的主鍵？

Question

我有一個工作的MySQL數據倉庫，它被組織爲一個星型模式，我使用Talend Open Studio for Data Integration 5.1來創建ETL過程。我希望這個過程每天運行一次。我估計其中一個維度表（dimUser）將有大約200萬條記錄和23列。

我在Talend中創建了一個小測試ETL過程，但是由於可能需要每天更新的數據量，當前性能不會削減它。它需要ETL過程四分鐘來更新或將1,000條記錄插入dimUser。如果我假設記錄計數與更新或插入的時間之間存在線性關係，那麼ETL無法在3-4小時內完成（我的希望），更不用說有一天了。

因爲我不熟悉Java，所以我將ETL編寫爲Python腳本並遇到了同樣的問題。雖然，我確實發現，如果我只進行了INSERT，流程就會更快。我很確定這個瓶頸是由UPDATE語句引起的。

dimUser中的主鍵是一個自動遞增整數。我的朋友建議我放棄這個主鍵，並用多字段主鍵替換它（在我的情況下，2-3個字段）。

之前，我撕裂測試數據出來我的倉庫和更改架構，任何人都可以提供與

1. 數據倉庫
2. ETL過程的設計建議或指引
3. 多麼逼真就是每天有一個ETL進程插入或更新幾百萬條記錄
4. 我朋友的建議會大大幫助

如果您需要更多信息，請讓我知道，我會發布它。

UPDATE - 其他信息：

mysql> describe dimUser; 
Field      Type    Null Key Default   Extra 
user_key      int(10) unsigned NO PRI NULL    auto_increment 
id_A       int(10) unsigned NO  NULL 
id_B       int(10) unsigned NO  NULL 
field_4      tinyint(4) unsigned NO  0 
field_5      varchar(50)   YES  NULL 
city       varchar(50)   YES  NULL 
state      varchar(2)   YES  NULL 
country      varchar(50)   YES  NULL 
zip_code      varchar(10)   NO  99999 
field_10      tinyint(1)   NO  0 
field_11      tinyint(1)   NO  0 
field_12      tinyint(1)   NO  0 
field_13      tinyint(1)   NO  1 
field_14      tinyint(1)   NO  0 
field_15      tinyint(1)   NO  0 
field_16      tinyint(1)   NO  0 
field_17      tinyint(1)   NO  1 
field_18      tinyint(1)   NO  0 
field_19      tinyint(1)   NO  0 
field_20      tinyint(1)   NO  0 
create_date     datetime   NO  2012-01-01 00:00:00 
last_update     datetime   NO  2012-01-01 00:00:00 
run_id      int(10) unsigned NO  999 

我使用代理鍵，因爲我讀了，這是很好的做法。因爲從商業的角度來看，我想要知道潛在的欺詐活動（比如說200天的用戶與X狀態相關聯，然後第二天他們與Y狀態相關聯 - 他們可能已經移動了，或者他們的賬戶可能已經妥協），所以這就是地理數據保存的原因。字段id_B可能有一些與它關聯的id_A的不同值，但我有興趣瞭解不同的（id_A，id_B）元組。在這個信息的背景下，我的朋友建議像（id_A，id_B，zip_code）這樣的主鍵。對於絕大多數日常ETL過程（> 80％），我只希望爲現有記錄更新以下字段：field_10 - field_14，last_update和run_id（該字段是我的etlLog表的外鍵並用於ETL審計目的）。

Answer 1

這是我對你的問題的想法。

1）倉庫設計：

閱讀拉爾夫·金博爾的書：數據倉庫工具包。

您的維度表有一堆無意義名稱的列。而不是field_5，該列應該被賦予一個具有商業含義的名稱。數據倉庫便於查詢業務人員&。

我在這裏沒有看到任何事實表。瞭解用戶維度將用於什麼在設計中很重要。

2）ETL過程

您是否確定了在ETL過程中的瓶頸是什麼？它是從源頭讀取數據，轉換數據還是寫入數據庫？您可能以每秒40,000行的速度編寫，但如果您只能從XML數據源讀取1,000行/秒，則您不會走得太遠。

您是否考慮過首先將已更改的記錄加載到數據庫中的階段表中，而不進行任何轉換，然後使用SQL來轉換和更新數據？通常情況下，您會發現數據庫中的性能優於將工作分流到ETL工具。

3）如果硬件能夠處理它，每天更新數百萬條記錄是非常現實的。我認爲重要的是要明白，如果您只是在類型1維度中進行覆蓋更改（在這種情況下，刪除更改行，然後插入，可能比update/else/insert更好）。

如果您在類型2維中保留更改的歷史記錄，則可能需要考慮在單獨的小型維度中將想要跟蹤的更改字段刷新。當您有非常大的「客戶」維度時，金博爾會討論這種技術。然後，您將使用定期的快照事實表，這將允許您隨時跟蹤用戶的更改。

4）您的朋友建議使用自然業務密鑰創建主鍵不是數據倉庫環境的好主意。我們創建一個整數替代關鍵字，所以我們可以將它包含在事實表中，以使它們變得很瘦，因爲它們會比維度表大幾個數量級。