Azure SQL 数据仓库 (Synapse Analytics) 使用 ORC 表的 Polybase 性能

Posted 2023-03-25

【中文标题】Azure SQL 数据仓库 (Synapse Analytics) 使用 ORC 表的 Polybase 性能

【英文标题】：Azure SQL Data Warehouse (Synapse Analytics) Polybase performances with ORC table

【发布时间】：2020-07-25 19:34:14

【问题描述】：

我在 Azure 存储帐户（带 ADLS Gen2 功能）上使用 Spark（Databricks）生成了一个 ORC 表（使用 Snappy 压缩）。这个 ORC 代表大约 12 GB 的数据（12 亿行）。此表有 32 列。

生成后，我使用 Polybase 将该文件加载到 Synapse Analytics 表内的内部表中。

这是我使用不同配置的结果：

DW100c / smallrc = 3h52 DW400c / smallrc = 1h50 DW400c / xlargerc = 1h58 DW1000c / xlargerc = 0h50 DW1500c / xlargerc = 0h42

当我查看存储帐户入口/出口时，我看到了几分钟内的活动（可能是为了在 Synapse 节点之间复制 ORC 文件）......然后 Synapse 资源开始受到压力。我看到一段时间的 CPU 活动，然后内存慢慢增加，缓慢，...

这里是内存（红色）和 CPU 最大百分比（蓝色）示例：

我需要再次扩大规模吗？我认为这不是网络吞吐量的 pb。或者可能是配置问题？关于 Polybase，我不明白为什么这么慢。 Polybase 应该能够快速摄取 TB 的 ORC 数据！

BR, A.

编辑：DWU 用法

【问题讨论】：

你能发布你的代码吗？

@GregGalloway 它是从外部表中选择的。我们在外部数据源上使用托管服务身份 (SCOPE CREDENTIAL)。我的外部文件格式正在使用 ORC 和 Snappy

所以没有 CAST 函数？什么是数据类型？您是否选择了可能的最小字符串宽度？

我们使用具有最大值的 NVARCHAR，因为这是非结构化数据

意味着您正在导入 JSON 数据或可能是任意长度的数据，您稍后将在存储过程中对其进行解析？可能值得测试一下最大实际长度，看看缩小字符串列的宽度是否会提高加载性能。我担心内部数据移动缓冲区的大小将被调整为允许宽数据，并且会比常规大小的列表现更差。至少这是 Azure DW 中一个常见的最佳实践，有据可查。

【参考方案1】：

您可以尝试几件事。 Azure Synapse Analytics（以前称为 Azure SQL Data Warehosue）有一个与 DWU 相关的读取器和写入器的概念。我找不到该文档的当前版本，但我拥有的一些旧 gen1 文档表明 DWU1500 有 120 个阅读器。这强烈建议您应该将一个大文件拆分为多个文件。

我会做一些实验，从 10 个文件开始，即 10 个文件，每个文件 1.2GB，直到找到适合工作负载的最佳设置。我会说我没有用 ORC 文件对此进行测试，我不清楚 ORC 格式是否已经固有分区。试试看。

您也可以尝试 CTAS（如果您还没有使用它）。这也将利用 Synapse 的并行工作能力。

还有一个名为COPY INTO 的新功能目前处于预览阶段。根据the documentation 的说法，它与 ORC 文件兼容，不需要您拆分它们：

COPY 命令加载的文件分割指导是什么 Parquet 或 ORC 文件？ 无需拆分 Parquet 和 ORC 文件 因为 COPY 命令会自动分割文件。镶木地板和 Azure 存储帐户中的 ORC 文件应为 256MB 或更大 最佳性能。

https://docs.microsoft.com/en-us/sql/t-sql/statements/copy-into-transact-sql?view=azure-sqldw-latest#what-is-the-file-splitting-guidance-for-the-copy-command-loading-parquet-or-orc-files

COPY INTO test_orc
FROM 'https://yourAccount.blob.core.windows.net/yourBlobcontainer/folder1/*.orc'
WITH (
    FILE_FORMAT = yourFileFormat
    CREDENTIAL=(IDENTITY= 'Shared Access Signature', SECRET='<Your_SAS_Token>')
)

通过查看门户中的 DWU 使用情况来确定您是否受 DWU 限制 - 看看它是否被最大化/扁平化，我猜不是。

【讨论】：

当我看到这个（旧但仍然打开）时，再加上 Polybase 不处理分区的事实，你真的可以认为 Polybase 不兼容 Hadoop（这是明确写的在文档上）。我会尝试一些测试并回复我的结果。谢谢;)

哦，对于 DWU，它不是平坦的（相同的过程/时间流逝）并遵循内存使用模式 = 我在帖子中添加了屏幕截图