优化 Azure Integration Runtime 的性能
数据流在运行时启动的 Spark 群集上运行。 活动的集成运行时 (IR) 中定义了所用群集的配置。 定义集成运行时时，需考虑三个性能注意事项：群集类型、群集大小和生存时间。
有关如何创建 Integration Runtime 的详细信息，请参阅 Integration Runtime。
若要开始使用数据流集成运行时，最简单的方法是从计算大小选取器中选择小、中或大。 请参阅下面这些大小的群集配置的映射。
群集大小
数据流将数据处理分发到 Spark 群集中的各个核心，以并行执行操作。 具有更多核心的 Spark 群集会增加计算环境中的核心数。 核心越多，对数据流的处理能力越高。 增加群集的大小通常可轻松缩短处理时间。
默认群集大小为四个驱动程序核心和四个工作器核心（小）。 处理更多数据时，建议使用较大的群集。 以下是可能的大小选项：
| 工作器核心 | 驱动程序核心 | 核心总数 | 说明 |
|---|---|---|---|
| 4 | 4 | 8 | 小 |
| 8 | 8 | 16 | 中型 |
| 16 | 16 | 32 | 大 |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
数据流按 vcore-hrs 定价，这意味着群集大小和执行时间都会对价格产生影响。 纵向扩展时，每分钟的群集成本将增加，但总时间将缩短。
提示
群集大小对数据流性能的影响程度有上限。 根据数据的大小，当群集大小增加到某一程度时，将不再能优化性能。 例如，如果核心多于数据分区，则添加更多核心将无济于事。 最佳做法是从小规模开始，然后纵向扩展以满足性能需求。
自定义无序分区
数据流将数据划分为多个分区，并通过不同的进程对其进行转换。 如果分区中的数据大小超过进程可在内存中保存的大小，进程将失败并显示“OOM (内存不足)”错误。 如果数据流包含大量具有联接/聚合的数据，建议尝试以增量方式更改无序分区。 可以将其设置为 50 到 2000，以避免 OOM 错误。 数据流运行时中的“计算自定义属性”是一种控制计算需求的方法。 属性名称为“无序分区”，且为整型。 此自定义应仅在已知方案中使用，否则可能会导致不必要的数据流失败。
在增加无序分区的同时，确保数据分布良好。 每个分区大致约有 1.5 GB 数据。 如果数据倾斜，增加“无序分区”将没有帮助。 例如，如果有 500 GB 数据，则 400 到 500 个无序分区应该可行。 无序分区的默认限制为 200 个，适用于大约 300 GB 数据。
- 在 ADF 门户中的“管理”下，选择自定义集成运行时，然后进入编辑模式。
- 在“数据流运行时”选项卡下，转到“计算自定义属性”部分。
- 选择“属性名称”下的“无序分区”，输入所选的值，如 250、500 等。
也可以通过编辑运行时的 JSON 文件来实现此操作，方法是将具有属性名称和值的数组添加到清理属性等现有属性之后。
生存时间
默认情况下，每个数据流活动都会根据 Azure IR 配置启动新的 Spark 群集。 冷群集启动需要几分钟时间，且完成启动后才能开始处理数据。 如果管道包含多个顺序数据流，则可以启用生存时间 (TTL) 值。 指定生存时间值可使群集在执行完成后保持一定时长的活跃度。 如果新作业在 TTL 时间内开始使用 IR，则它将重新使用现有群集，且启动时间将显著缩短。 第二个作业完成后，群集将再次保持 TTL 时长的活跃度。
但是，如果大部分数据流并行执行，则建议为用于这些活动的 IR 启用 TTL。 一个群集一次只能运行一个作业。 如果有一个可用群集，但启动了两个数据流，则只有一个数据流可使用该活跃群集。 第二个作业将启动自己的独立群集。
注意
默认情况下，使用自动解析集成运行时时，生存时间不可用。
相关内容
请参阅与性能相关的其他数据流文章：