星型模式，代理鍵

我們有一個遙測數據的大而寬的平面文件。他們每天都會到達。星型模式，代理鍵

我打算在ADLA DB中創建星型模式，它將填充來自這些寬大文件的數據。（貌似ADLA DB提供了很多的功能（相對於原料ADLS）：索引，statisctics，壓縮，配送管理...）

要生成我們可以使用代理鍵之一：

ROW_NUMBER
哈希

哈希是什麼？我們可以使用哪些功能來實現它？（我正在考慮C＃）

來源

2017-03-16 churupaha

這不是你的問題的答案。但認爲值得一提的是，根據您的建議，您需要處理的事實是，您目前無法在ADL表中使用USQL進行UPDATE或DELETE。您可能需要更多地查看分區，以便重新運行。 –

是的，我明白了。我將使用Date for FactXXX表進行分區。 – churupaha

首先我想明白你爲什麼要使用代理鍵。

當前的U-SQL表格專爲支持批量查詢而設計，您可以提前知道大部分預期查詢。所以你設計你的分配鍵和方案（散列，直接散列，範圍）和聚集索引來優化最昂貴的工作。

例如，如果您需要使用直接散列來管理數據傾斜，那麼使用代理鍵是有意義的，但否則可能會增加複雜性以利用分區/分配消除。

至於實現你自己的散列函數，C＃有一些內置的散列函數，或者你可以自己寫。例如，C＃Object.GetHashCode方法。

來源

2017-03-19 22:48:43

我們有一個存儲在CSV中的遙測時間線數據。這些CSV廣泛（很多列）。預計它們會很大，但是我可以控制1-4Gb內的每個尺寸（ADLA引擎所期望的）。我想要將這些數據逐步加載到ADLA DB中，以使用如下功能：分區，分佈，兼容連接/聚合，統計等。此外，這些數據非常多且很寬（很多列）。通過兼容性爲所有主要查詢創建一個單一的分佈式模式，以便爲一個平坦的寬表創建聯接/組。我想將平面結構分解爲星型模式。 – churupaha

在這種情況下，我們將有一些事實表共享一些Dim表。這些事實表不會像源平面表那麼廣泛，我可以在每個具體的案例中選擇合適的分配模式。另外它應該會導致數據集的大小減小。而且這些事實表幾乎全部由整數組成，而不是大字符串（就像我們在平面模式中）。它應該給聚合帶來好處（或者至少對於Azure DWH來說是這樣）。爲了實現星型模式，我需要一種爲DimTables生成代理鍵的方法。我可以使用row_number或某種哈希。 – churupaha

它不應該破壞與源數據相比較的價值分佈。因爲如果我們在源平面表中有一個值爲'Biiiiig string 1'，'Biiiiig string 1'，'Biiiiig string 1'，'Biiiiig string 2'，'Biiiiig string 3'的列，那麼它們將被替換爲整數1，1，2，3 – churupaha

星型模式，代理鍵

回答

相關問題