5

所以 Azure SQL 数据仓库不支持标识列，因此处理代理键很棘手。有人对此有任何大胆的解决方案吗？

这是我发现的最好的，而且非常可怕。

4

6 回答 6

4

这是最好的选择 - 但您可以在 OVER 子句中使用常量值以避免必须对特定值进行排序，并且您不需要使用变量。

INSERT INTO testTgtTable (SrgKey, colA, colB)
SELECT
    ROW_NUMBER() OVER(ORDER BY (SELECT 1)) + (SELECT ISNULL(MAX(SrgKey),0) SK FROM dbo.testTgtTable) SK
  , [colA]
  , [colB]
FROM testSrcTable;
于 2016-01-30T03:55:30.573 回答
2

有时文件中存在行号或可以轻松添加。如果存在，则可以利用它来生成代理键值。这是一个多步骤的过程

  1. 将数据加载到临时表中
  2. 对目标表代理键执行 MAX() 查找以获取当前最大值
  3. CTAS 或将临时表中的数据插入到目标中。将 max_count 常量添加到 row_number 值

代码看起来像这样：

DECLARE @max_count bigint
SET     @max_count = (SELECT MAX(ID) FROM Fact)

...

CREATE TABLE Input_Load
WITH (DISTRIBUTION = ROUND_ROBIN
     ,CLUSTERED COLUMNSTORE INDEX
     )
AS
SELECT @max_count + RowNumber
,      ...
FROM   dbo.stage_table
;
于 2016-02-10T14:23:58.830 回答
2

我不认为基于业务密钥哈希值的代理密钥是一个很好的解决方案，因为您就冲突提出了这个问题。它违背了代理键的目的，即为 DW 提供唯一 ID，而不管 BK 是什么。“智能”或“智能”键的所有经典问题，或与将 BK 用作 PK 相关的问题仍然存在。

于 2017-05-02T15:51:02.657 回答
2

我们现在在 Azure SQL 数据仓库中具有标识列功能。 关联

于 2017-07-10T08:21:57.243 回答
2

Identity列特性与CTAS语句不兼容，大大降低了它作为“解决方案”的作用。它仅适用于在 ASDW 中表现不佳的 INSERTS、UPDATES、DELETES

于 2017-07-15T00:43:28.093 回答
1

随着从 SMP 到 MPP 数据仓库的迁移以及将 Hadoop、NoSQL 和其他大数据扩展引入您的 BI 生态系统，基于哈希的代理键替换基于序列的代理键是有意义的。

以下是为什么要考虑基于散列的代理键而不是基于序列的代理键的几个原因：

  • 在您的 BI 生态系统中的各种平台上使用一致的代理密钥生成方法。可以在各种环境中独立生成一致的基于哈希的密钥，可以是任何 ETL 工具（SSIS、DataStage 等）、任何 NoSQL 或 MPP 数据库或 Hadoop 实现。

  • 与 ETL 相比，基于哈希逻辑的代理键在 ELT 实现中比基于序列的代理键更有意义。“将数据加载到然后处理它”（ELT）是 MPP 和 BigData 解决方案中的首选方式。通过用哈希值计算替换查找来简化数据加载和转换过程。结果，这从 I/O 密集型操作（查找）转变为 CPU 密集型操作（散列生成）。

  • 通常所有数据加载/转换过程都可以完全并行执行，因为可以避免表之间的依赖关系，因为基于散列的代理键是一致的并且可以独立生成。

  • 在实时/近实时数据更新场景中，基于散列的代理键通常可以通过消除对允许跳过暂存区域并直接插入事实表的额外查找的需要而即时生成。

  • 跨开发、UAT 和生产环境的一致代理键。

  • 在大多数 MPP 数据仓库平台上，固定长度哈希键上的连接是相当理想的。

这里有几点建议：

  • 使用自然业务键作为维度表中主键的哈希函数的输入。

  • 使用构成主键的连接自然业务键作为事实表散列函数的输入。不要忘记按特定字符（例如|）将业务键串联起来，以避免意外冲突。

  • 使用自然业务键作为哈希函数的输入，以链接到事实表中的维度。

但是，像往常一样，一个警告！基于散列的代理键可能会产生冲突，即在给定两个不同输入值的情况下可以生成相同的散列值。有关此的更多信息，您可以在此处和此处阅读。

于 2016-01-30T10:07:14.883 回答