提高从 Azure 流分析 到 Azure SQL 数据库 的吞吐量性能

本文讨论在使用Azure 流分析将数据加载到Azure SQL 数据库时实现更好的写入吞吐量性能的提示。

Azure 流分析中的 SQL 输出支持并行写入作为选项。 此选项允许 完全并行 的作业拓扑，其中多个输出分区并行写入目标表。 但是，在Azure 流分析中启用此选项可能不足以实现更高的吞吐量，因为它在很大程度上取决于数据库配置和表架构。 索引、聚类分析键、索引填充因子和压缩选项会影响加载表的时间。 有关如何优化数据库以提高基于内部基准的查询和加载性能的详细信息，请参阅 SQL 数据库性能指南。 并行写入到 SQL 数据库时，不能保证写入顺序。

下面是每个服务中的一些配置，可帮助提高解决方案的总体吞吐量。

Azure 流分析

• 继承分区 - 此 SQL 输出配置选项支持继承上一个查询步骤或输入的分区方案。 启用此功能后，如果您的作业具有完全并行的拓扑并写入到基于磁盘的表中，预期会看到更好的吞吐量。 对于许多其他输出，分区已经自动完成。 使用此选项进行批量插入时，表锁定（TABLOCK）也被禁用。

• Batch Size - SQL 输出配置允许根据目标表/工作负荷的性质在Azure 流分析 SQL 输出中指定最大批大小。 批大小是每次批量插入事务发送的最大记录数。 在聚集列存储索引中，大约 100K 的批大小允许进行更多的并行化、最小日志记录和锁定优化。 在基于磁盘的表中，10K（默认）或更低版本可能最适合你的解决方案，因为较大的批大小可能会在批量插入期间触发锁升级。

• 输入消息优化 - 如果已使用继承分区和批大小进行优化，则增加每个分区每个消息的输入事件数有助于进一步提升写入吞吐量。 输入消息优化允许Azure 流分析内的批大小达到指定的批大小，从而提高吞吐量。 这可以通过在 EventHub 或 Blob 中使用 压缩 或增加输入消息大小来实现。

SQL Azure

• 分区表和索引 - 使用 分区 SQL 表和分区索引，并在表中采用与分区键（例如 PartitionId）相同的列，能够显著减少写入期间分区之间的争用。 对于分区表，需要在 PRIMARY 文件组上创建 分区函数 和 分区方案 。 在加载新数据时，这也会增加现有数据的可用性。 日志 IO 限制可能会因分区数量达到上限，您可以通过升级 SKU 来提高此限制。

• 避免唯一键冲突 - 如果在Azure 流分析活动日志中收到多个键冲突警告消息，请确保你的作业不受在恢复情况下可能发生的唯一性约束冲突的影响。 可以通过在索引上设置 IGNORE_DUP_KEY 选项来避免此问题。

Azure 数据工厂 和 In-Memory 表

• 将 In-Memory 表用作临时表 - In-Memory 表能够支持高速数据加载，但数据必须能够适应内存容量。 基准测试显示，从内存中表批量加载到基于磁盘的表的速度比使用单个写入器直接插入到具有标识列和聚集索引的基于磁盘的表中快约 10 倍。 为了利用大容量插入的性能，请使用 Azure 数据工厂 设置一个复制作业，以便将数据从内存表复制到基于磁盘的表。

避免性能缺陷

大容量插入数据比使用单个插入加载数据要快得多，因为避免了传输数据的重复开销、分析 insert 语句、运行语句和发出事务记录。 相反，采用更高效的路径进入存储引擎来流传输数据。 但是，此路径的设置成本远高于基于磁盘的表中的单个 insert 语句。 盈亏平衡点通常约为 100 行，超过此数量后，大容量加载几乎总是更有效。

如果传入事件速率较低，则可以轻松地创建小于 100 行的批大小，这使得批量插入效率低下，并且占用过多的磁盘空间。 若要解决此限制，可以执行以下操作之一：

• 创建一个 INSTEAD OF 触发器，以便对每一行使用简单的插入操作。
• 如上一部分所述，请使用 In-Memory 临时表。

写入非聚集列存储索引（NCCI）时，会出现另一种这种情况，其中较小的批量插入可以创建过多的段，导致索引崩溃。 在这种情况下，建议改用聚集列存储索引。

总结

总之，在 SQL 输出的Azure 流分析中使用分区输出功能，使作业的并行化与 SQL Azure中的分区表保持一致，这可以显著提高吞吐量。 利用 Azure 数据工厂 来协调将数据从 In-Memory 表移动到基于磁盘的表中，可以带来数量级别的吞吐量提升。 如果可行，提高消息密度也可能是提高整体吞吐量的主要因素。

后续步骤

• 理解 Azure 流分析 的输出
• Azure 流分析输出到 Azure SQL 数据库