你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文讨论在使用 Azure 流分析将数据加载到 Azure SQL 数据库时实现更好的写入吞吐量性能的提示。
Azure 流分析中的 SQL 输出支持并行写入作为选项。 此选项允许 完全并行 的作业拓扑，其中多个输出分区并行写入目标表。 但是，在 Azure 流分析中启用此选项可能不足以实现更高的吞吐量，因为它在很大程度上取决于数据库配置和表架构。 索引、聚类分析键、索引填充因子和压缩选项会影响加载表的时间。 有关如何优化数据库以提高基于内部基准的查询和加载性能的详细信息，请参阅 SQL 数据库性能指南。 并行写入到 SQL 数据库时，不能保证写入顺序。
下面是每个服务中的一些配置，可帮助提高解决方案的总体吞吐量。
Azure 流分析
继承分区 – 此 SQL 输出配置选项支持继承上一个查询步骤或输入的分区方案。 启用此选项后，写入到基于磁盘的表以及对作业使用完全并行拓扑时，吞吐量预期会提高。 对于许多其他输出，分区已经自动完成。 使用此选项执行批量插入时，还会禁用表锁定 (TABLOCK)。
注释
如果输入分区超过 8 个，则继承输入分区方案可能不是合适的选择。 包含单个标识列和聚集索引的表曾经达到过此上限。 在这种情况下，请考虑在查询中使用 INTO 8，以显式指定输出编写器的数量。 根据架构和索引的选择，观察结果可能会有所不同。
批大小 - SQL 输出配置允许根据目标表/工作负荷的性质在 Azure 流分析 SQL 输出中指定最大批大小。 批大小是每次批量插入事务发送的最大记录数。 在聚集列存储索引中，大约 100K 的批大小允许进行更多的并行化、最小日志记录和锁定优化。 在基于磁盘的表中，10K（默认）或更低版本可能最适合你的解决方案，因为较大的批大小可能会在批量插入期间触发锁升级。
输入消息优化 - 如果已使用继承分区和批大小进行优化，则增加每个分区每条消息的输入事件数有助于进一步提升写入吞吐量。 输入消息优化允许 Azure 流分析中的批大小达到指定的批大小，从而提高吞吐量。 这可以通过在 EventHub 或 Blob 中使用 压缩 或增加输入消息大小来实现。
SQL Azure
分区表和索引 - 在包含与分区键（例如 PartitionId）相同的列的表中使用分区 SQL 表和分区索引可以在写入期间明显减少分区之间的争用。 对于分区表，需要在 PRIMARY 文件组上创建 分区函数 和 分区方案 。 在加载新数据时，这也会增加现有数据的可用性。 根据分区的数量，可能会达到日志 IO 限制；升级 SKU 可以提高限制。
避免唯一键冲突 – 如果在 Azure 流分析活动日志中收到 多个密钥冲突警告消息 ，请确保作业不受在恢复情况下可能发生的唯一约束冲突的影响。 可以通过在索引上设置 IGNORE_DUP_KEY 选项来避免此问题。
Azure 数据工厂和 In-Memory 表
- In-Memory 表作为临时表 - In-Memory 表 允许高速数据加载，但数据需要容纳在内存中。 基准测试显示，从内存中表批量加载到基于磁盘的表的速度比使用单个写入器直接插入到具有标识列和聚集索引的基于磁盘的表中快约 10 倍。 若要利用此大容量插入性能， 请使用 Azure 数据工厂设置复制作业 ，以便将数据从内存中表复制到基于磁盘的表。
避免性能缺陷
批量插入数据比通过单次插入加载数据的速度要快得多，因为避免了传输数据、分析 insert 语句、运行该语句以及发出事务记录的重复开销。 相反，采用更高效的路径进入存储引擎来流传输数据。 但是，此路径的设置成本远高于基于磁盘的表中的单个 insert 语句。 保本点通常约为 100 行，如果超过此数量，批量加载几乎总是更高效。
如果传入事件速率较低，则可以轻松地创建小于 100 行的批大小，这使得批量插入效率低下，并且占用过多的磁盘空间。 若要解决此限制，可以执行以下操作之一：
- 创建 INSTEAD OF 触发器，以对每一行使用简单插入。
- 使用上一部分所述的内存中临时表。
写入非聚集列存储索引（NCCI）时，会出现另一种这种情况，其中较小的批量插入可以创建过多的段，导致索引崩溃。 在这种情况下，建议改用聚集列存储索引。
总结
总之，使用 Azure 流分析中用于 SQL 输出的分区输出功能，使作业的并行化与 SQL Azure 中的已分区表保持一致，这可以显著提高吞吐量。 利用 Azure 数据工厂来协调从内存中表到基于磁盘的表的数据移动，可让吞吐量获得指数级的提升。 如果可行，提高消息密度也可能是提高整体吞吐量的主要因素。