问题标签 [parallel-data-warehouse]

我在 SQL 并行数据仓库 / APS 工作。我正在尝试在单个 SELECT 语句中设置多个变量的值。我的代码是：

PDW 抛出以下错误：

解析错误... '=' 附近的语法不正确

这不是 PDW 上的有效语法吗？如果不是，我该如何解决？

我需要删除系统表中的一些数据。有什么我可以做的吗？

我想知道 Azure 数据仓库和 Microsoft 并行数据仓库 (PDW) 之间的主要区别。

我在这里阅读了一篇关于Azure 数据仓库的文章。此外，还有一篇关于Microsoft PDW的文章。

从特性和功能来看，它们看起来很相似。但是，我想知道它们之间的主要区别以及在什么情况下，一个比另一个更好。

有没有办法将数据从 T-SQL 语句导出到 Azure blob storage .csv，并在 Azure 数据仓库中使用标头？

Azure 数据仓库和 Azure 数据湖如何比较 1) 外部表 2) 内部表 3) 列存储聚集索引 4) 从 SQL Server Management Studio 连接到内部和外部表到内部/外部表。

尝试从 Azure 数据仓库连接到 Azure Blob 存储时出现错误

有什么不对？

我使用 Looker 管理存储在 Amazon RedShift 数据库中的数据。尽管 Looker 具有仪表板功能，但我想使用 Tableau 来实现更好的可视化。有没有办法可以将 Tableau 连接到 Looker 数据库。
（PS：我不希望将 Tableau 直接连接到 RedShift/S3，因为这会将我的数据暴露给 Tableau 服务器）。谢谢你。

我需要获取存储过程中使用的表列表，但是在 Azure Datawarehouse sp_depends 中不受支持。

我想到的另一种选择是从 INFORMATION_SCHEMA.ROUTINES 获取存储过程代码，然后运行脚本以从存储过程定义中获取 [schema].[tablename] 但这里的问题是将整个存储过程存储到一个变量。VARCHAR(MAX) 的存储限制为 8000，如果我的 proc 超过此限制，那么我将无法获得完整的表列表。

我试图在连接到 Azure SQL DW 的 SSMS 中运行这个简单的代码，但它失败了。我尝试了一些不同的变化，但它们似乎都没有工作。

我正在研究使用 datavault 2.0 方法。我了解散列并尝试应用它的原因。我想在数据库的“暂存”阶段应用它，而不是将其加载到 DV 中。

如果表中有业务键，那么很容易将其应用到该表（可能成为集线器）。但是有像“orderdetail”这样的表（可能成为链接），它们通过代理键多次引用其他元素。

临时表是否应该同时包含每个外键的代理序列以及引用实体 BK 的散列？

示例：如果我有一个带有 customerId 代理序列的订单表，但客户表有一个用作 BK 的 CUST-000xxx 引用，我是否应该在订单和客户之间执行“连接”以解析“CUST-000xxx”所以我可以散列它并将其包含在订单临时表中？

我在想，当从暂存区加载 DV 中的数据时，这可能会解决，但是在那个特定时刻，暂存区中可能不存在客户参考，因为订单可能只是一个新订单没有改变的现有客户。

DV 2.0 规定，所有使用哈希的业务都是为了提高性能并简单地并行加载数据，而无需在 DV 本身中进行昂贵的查找。因此，这个问题通常是如何解决的。

在此处添加示例：

订单 - orderid - customerid - order_ref - salespersonid

客户 - customerid - customer_ref

人 - 人名 - 全名 - 登录

为了填充订单，我应该像这样在源数据库中加入：

或者是在 datavault 中解析的外键解析，因此查询更简单，例如：

这对我来说不是很清楚。我的理解是，通过散列避免了昂贵的查找，因此不为外键在暂存时生成散列对性能没有贡献？