想開始一個討論的技術加入兩個相對較大的表每天大致相等的大小。我意識到這可能是一個難題,磚,但檢查細節。

[Michael42]

輸入數據:

• 每天一批加載的數據集,大約1000萬件一天的交易。
• 另一個日常批量裝載大致相同的大小。
• 在每一行中的一個數據集應該有一個對應的行其他數據集。

問題解決:

• 問題是確定在每個數據集相關的行。
• 這是一個匹配的問題可以描述為一係列的一對一的內心的兩個數據集之間的聯接。
• 連接列總是帳戶/日期/和數量。
• 但是也有不同的匹配規則,在每個數據集的附加列,需要探索如果發現匹配多個行兩側在應用上麵的基本規則。例如,當多個行兩側有相同的帳戶和日期,但數量值很常見。
• 此外,有時一個匹配項從一個數據集在任何一天不能到達另一個數據集,直到第二天,甚至幾天後。

輸出:

• 匹配行:一旦發現一組獨特的一對一的匹配,可以將他們轉移到一個結果集匹配的行。
• 無與倫比的行:剩下的無與倫比的行從兩側應該被添加到明天的數據集對後續匹配後的一天。

好奇有人會使用什麼技術去解決這個使用磚。

我的新磚,隻有最近收到一個數據工程助理證書。

有額外的細節問題我可以進入如果進行進一步的討論。道歉如果這個似乎不適合討論這個論壇。

[Lennart]

我過去處理類似的事情。

訂單係統有秩序應該是匹配的項目,對相應的產品在另一個係統,作為主人和發票處理。

至於與磚碼字考慮這樣做,看看你是否可以得到需要的行對相同的工人加入,這樣你就可以避免shuffeling在最初閱讀?

另一件事要注意這樣的問題是如果你有多個候選匹配規則,但在匹配什麼取決於如果已經匹配的記錄。

在這種情況下,你可能有某種reccursive問題在你的手,可以繼續生產更多的比賽,當你多次運行相同的操作在同一數據集。

至於如何解決這一問題,至少試著給所有行獨特的鍵來減少查詢的complexitiy / cognetive開銷在處理業務規則。

也考慮做一個鏈接/結表和存儲匹配的密鑰對與時間戳等有用的元數據,匹配規則使用等鑰匙丟失的表會自動elligible未來匹配和它可以用來加入表再次一起在其他上下文沒有複製的邏輯。

[Michael42]

謝謝你Lennart,

這是有幫助的。