星型模式，代理键
我们有一个遥测数据的大而宽的平面文件。他们每天都会到达。星型模式，代理键
我打算在ADLA DB中创建星型模式，它将填充来自这些宽大文件的数据。 （貌似ADLA DB提供了很多的功能（相对于原料ADLS）：索引，statisctics，压缩，配送管理...）
要生成我们可以使用代理键之一：
- ROW_NUMBER
- 哈希
哈希是什么？我们可以使用哪些功能来实现它？ （我正在考虑C＃）
首先我想明白你为什么要使用代理键。
当前的U-SQL表格专为支持批量查询而设计，您可以提前知道大部分预期查询。所以你设计你的分配键和方案（散列，直接散列，范围）和聚集索引来优化最昂贵的工作。
例如，如果您需要使用直接散列来管理数据倾斜，那么使用代理键是有意义的，但否则可能会增加复杂性以利用分区/分配消除。
至于实现你自己的散列函数，C＃有一些内置的散列函数，或者你可以自己写。例如，C＃Object.GetHashCode方法。
我们有一个存储在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
这不是你的问题的答案。但认为值得一提的是，根据您的建议，您需要处理的事实是，您目前无法在ADL表中使用USQL进行UPDATE或DELETE。您可能需要更多地查看分区，以便重新运行。 –
是的，我明白了。我将使用Date for FactXXX表进行分区。 – churupaha