Azure 上的 Apache NiFi

此示例方案演示如何运行 Azure 上的 Apache NiFi。 NiFi 提供了用于处理和分发数据的系统。

Apache®、Apache NiFi® 和 NiFi® 是 Apache Software Foundation 在美国和/或其他国家/地区的商标或注册商标。 使用这些标记并不暗示获得 Apache Software Foundation 的认可。

体系结构

下载此体系结构的 Visio 文件。

工作流

• NiFi 应用程序在 NiFi 群集节点中的 VM 上运行。 VM 位于配置跨可用性区域部署的虚拟机规模集中。

• Apache ZooKeeper 在单独群集中的 VM 上运行。 NiFi 使用 ZooKeeper 群集来实现以下目的：

  • 选择群集协调器节点
  • 协调数据流

• Azure 应用程序网关为在 NiFi 节点上运行的用户界面提供第 7 层负载均衡。

• Monitor 及其 Log Analytics 功能在 NiFi 系统中收集、分析和处理遥测数据。 遥测数据包括 NiFi 系统日志、系统运行状况指标和性能指标。

• Azure Key Vault 安全地存储 NiFi 群集的证书和密钥。

• Microsoft Entra ID 提供单一登录和多重身份验证。

组件

• NiFi 提供了用于处理和分发数据的系统。
• ZooKeeper 是管理分布式系统的开源服务器。
• 虚拟机是一种基础结构即服务 (IaaS) 产品/服务。 可以使用虚拟机来部署可按需缩放的计算资源。 利用虚拟机可以灵活地实现虚拟化，但消除了物理硬件的维护需求。
• Azure 虚拟机规模集提供了一种用于管理一组负载均衡的 VM 方法。 可以根据需求或定义的计划自动增减集中 VM 实例的数目。
• 可用性区域是 Azure 区域中独特的物理位置。 数据中心发生故障时，这些高可用性产品/服务可以保护应用程序和数据。
• 应用程序网关是一种负载均衡器，可用于管理发往 Web 应用程序的流量。
• Monitor 收集和分析有关环境和 Azure 资源的数据。 这些数据包括应用遥测数据，例如性能指标和活动日志。 有关详细信息，请参阅本文后面的监视注意事项。
• Log Analytics 是对 Monitor 日志数据运行查询的 Azure 门户工具。 Log Analytics 还提供了用于制表和统计分析查询结果的功能。
• Azure DevOps Services 提供了用于管理编码项目和部署的服务、工具和环境。
• Key Vault 安全存储并控制对系统机密（例如 API 密钥、密码、证书和加密密钥）的访问。
• Microsoft Entra ID 是一种基于云的标识服务，可控制对 Azure 和其他云应用的访问。

备选方法

• Azure 数据工厂提供此解决方案的替代方法。
• 你可以使用类似的服务来存储系统机密，而不是 Key Vault。
• Apache Airflow。 了解 Airflow 和 NiFi 有何区别。
• 可以使用受支持的企业 NiFi 替代方法，例如 Cloudera Apache NiFi。 Cloudera 产品/服务可通过 Azure 市场获取。

方案详细信息

在这种情况下，NiFi 在规模集中的 跨 Azure 虚拟机的群集配置中运行。 但本文的大部分建议也适用于在单个虚拟机 (VM) 上以单实例模式运行 NiFi 的场景。 本文中的最佳做法展示了可缩放、高可用性的安全部署。

可能的用例

NiFi 非常适用于移动数据和管理数据流：

• 连接云中的解耦系统
• 将数据移入和移出 Azure 存储和其他数据存储
• 将边缘到云和混合云应用程序与 Azure IoT、Azure Stack 和 Azure Kubernetes 服务 (AKS) 集成

因此，此解决方案适用于许多领域：

• 新式数据仓库 (MDW) 将结构化和非结构化数据大规模地整合在一起。 他们收集和存储来自各种源、接收器和格式的数据。 NiFi 擅长将数据引入基于 Azure 的 MDW 中，原因如下：

  • 超过 200 个处理器可用于读取、写入和操作数据。
  • 该系统支持 Azure Blob Storage、Azure Data Lake Storage、Azure 事件中心、Azure 队列存储、Azure Cosmos DB 和 Azure Synapse Analytics 等存储服务。
  • 强大的数据来源功能使其可以实现合规的解决方案。 有关在 Azure Monitor 的 Log Analytics 功能中捕获数据来源的信息，请参阅本文后面的报告注意事项。

• NiFi 可以在小型设备上独立运行。 在这种情况下，NiFi 可以处理边缘数据并将该数据移动到云中较大的 NiFi 实例或群集。 NiFi 可帮助筛选、转换和优先处理移动中的边缘数据，以确保数据流的可靠性和效率。

• 工业 IoT (IIoT) 解决方案管理从边缘到数据中心的数据流。 该流从工业控制系统和设备中的数据采集开始。 然后，数据会转移到数据管理解决方案和 MDW。 NiFi 提供了一些功能，使其非常适用于数据采集和移动：

  • 边缘数据处理功能
  • 支持 IoT 网关和设备使用的协议
  • 与事件中心和存储服务集成

  预测性维护和供应链管理领域的 IoT 应用程序可以利用此功能。

建议

使用此解决方案时，请记住以下几点：

建议的 NiFi 版本

在 Azure 上运行此解决方案时，建议使用 NiFi 1.13.2+ 版本。 可以运行其他版本，但它们可能需要与本指南中的配置不同的配置。

要在 Azure VM 上安装 NiFi，最好从 NiFi 下载页下载便利的二进制文件。 此外，还可以从源代码构建二进制文件。

建议的 ZooKeeper 版本

对于此示例工作负荷，建议使用 ZooKeeper 的 3.5.5 及更高版本或 3.6.x 版本。

可以使用便利的官方二进制文件或源代码在 Azure VM 上安装 ZooKeeper。 两者都可以在 Apache ZooKeeper 发布页面上获取。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

有关配置 NiFi 的信息，请参阅 Apache NiFi 系统管理员指南。 实现此解决方案时，还应记住以下注意事项。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

• 使用 Azure 定价计算器估算此体系结构中的资源成本。
• 有关包含此体系结构中除自定义警报解决方案之外的所有服务的估算值，请参阅此示例成本配置文件。

VM 注意事项

以下部分详细介绍了如何配置 NiFi VM：

VM 大小

此表列出了建议开始使用的 VM 大小。 对于大多数通用数据流，Standard_D16s_v3 是最佳选择。 但是 NiFi 中的每个数据流都有不同的要求。 测试数据流并根据其实际需求调整大小。

考虑在 VM 上启用加速网络以提高网络性能。 有关详细信息，请参阅 Azure 虚拟机规模集的网络。

VM 大小	vCPU	内存（以 GB 为单位）	最大未缓存数据磁盘吞吐量（每秒 I/O 操作次数 (IOPS)/MBps）*	最大网络接口 (NIC) 数/预期网络带宽 (Mbps)
Standard_D8s_v3	8	32	12,800/192	4/4,000
Standard_D16s_v3**	16	64	25,600/384	8/8,000
Standard_D32s_v3	32	128	51,200/768	8/16,000
Standard_M16m	16	437.5	10,000/250	8/4,000

* 针对你在 NiFi 节点上使用的所有数据磁盘禁用数据磁盘写入缓存。

** 建议将此 SKU 用于大多数通用数据流。 具有类似 vCPU 和内存配置的 Azure VM SKU 也应该够用了。

VM 操作系统 (OS)

建议在以下任一来宾操作系统上的 Azure 中运行 NiFi：

• Ubuntu 18.04 LTS 或更高版本
• CentOS 7.9

为了满足数据流的特定要求，请务必调整几个 OS 级别的设置，包括：

• 最大进程分支数。
• 最大文件句柄数。
• 访问时间 atime。

在调整 OS 以适应预期用例后，使用 Azure VM 映像生成器对这些优化后的映像的生成进行编码。 有关特定于 NiFi 的指南，请参阅 Apache NiFi 系统管理员指南中的配置最佳做法。

存储

将各种 NiFi 存储库存储在数据磁盘上而不是 OS 磁盘上，主要原因有以下三个：

• 流通常具有较高的磁盘吞吐量要求，单个磁盘无法满足。
• 最好将 NiFi 磁盘操作与 OS 磁盘操作分开。
• 存储库不应位于临时存储上。

以下部分概述了配置数据磁盘的准则。 这些准则特定于 Azure。 有关配置存储库的详细信息，请参阅 Apache NiFi 系统管理员指南中的状态管理。

数据磁盘类型和大小

为 NiFi 配置数据盘时，请考虑以下因素：

• 磁盘类型
• 磁盘大小
• 磁盘总数

下表显示了 Azure 中当前可用的托管磁盘类型。 可以将 NiFi 与这些磁盘类型中的任意一种一起使用。 但对于高吞吐量数据流，建议使用高级 SSD。

	超级磁盘 (NVMe)	高级 SSD	标准 SSD	标准 HDD
磁盘类型	SSD	SSD	SSD	HDD
最大磁盘大小	65,536 GB	32,767 GB	32,767 GB	32,767 GB
最大吞吐量	2,000 MiB/秒	900 MiB/秒	750 MiB/秒	500 MiB/秒
最大 IOPS	160,000	20,000	6,000	2,000

至少使用三个数据磁盘来增加数据流的吞吐量。 有关在磁盘上配置存储库的最佳做法，请参阅本文后面的存储库配置。

下表列出了各磁盘大小和类型的相关大小和吞吐量数字。

	标准 HDD S15	标准 HDD S20	标准 HDD S30	标准 SSD S15	标准 SSD S20	标准 SSD S30	高级 SSD P15	高级 SSD P20	高级 SSD P30
磁盘大小（以 GB 为单位）	256	512	1,024	256	512	1,024	256	512	1,024
每个磁盘的 IOPS	最多 500	最多 500	最多 500	最多 500	最多 500	最多 500	1,100	2,300	5,000
每个磁盘的吞吐量	最高可达 60 MBps	最高可达 60 MBps	最高可达 60 MBps	最高可达 60 MBps	最高可达 60 MBps	最高可达 60 MBps	125 MBps	150 MBps	200 MBps

如果系统达到 VM 限制，则添加更多磁盘可能无法提高吞吐量：

• IOPS 和吞吐量限制取决于磁盘的大小。
• 选择的 VM 大小会对所有数据磁盘上的 VM 设置 IOPS 和吞吐量限制。

有关 VM 级别的磁盘吞吐量限制，请参阅 Azure 中 Linux 虚拟机的大小。

VM 磁盘缓存

在 Azure VM 上，主机缓存功能管理磁盘写入缓存。 要提高用于存储库的数据磁盘的吞吐量，请通过将主机缓存设置为 None 来关闭磁盘写入缓存。

存储库配置

NiFi 的最佳做法指南是为每个存储库使用一个或多个单独的磁盘：

• 内容
• FlowFile
• 来源

此方法至少需要三个磁盘。

NiFi 还支持应用程序级别条带化。 此功能可增加数据存储库的大小或提高其性能。

以下摘录来自 nifi.properties 配置文件。 此配置跨连接到 VM 的托管磁盘对存储库进行分区和条带化：

nifi.provenance.repository.directory.stripe1=/mnt/disk1/ provenance_repository
nifi.provenance.repository.directory.stripe2=/mnt/disk2/ provenance_repository
nifi.provenance.repository.directory.stripe3=/mnt/disk3/ provenance_repository
nifi.content.repository.directory.stripe1=/mnt/disk4/ content_repository
nifi.content.repository.directory.stripe2=/mnt/disk5/ content_repository
nifi.content.repository.directory.stripe3=/mnt/disk6/ content_repository
nifi.flowfile.repository.directory=/mnt/disk7/ flowfile_repository

有关高性能存储设计的详细信息，请参阅 Azure 高级存储：高性能设计。

报表

NiFi 包括 Log Analytics 功能的来源报告任务。

你可以使用此报告任务将来源事件卸载到具有经济高效且持久的长期存储。 Log Analytics 功能提供了一个查询界面，用于查看各个事件和为其绘图。 有关这些查询的详细信息，请参阅本文后面的 Log Analytics 查询。

你还可以将此任务与易失性内存中来源存储一起使用。 在许多情况下，可以增加吞吐量。 但是，如果需要保留事件数据，则此方法有风险。 确保易失性存储满足你对来源事件的持久性要求。 有关详细信息，请参阅 Apache NiFi 系统管理员指南中的来源存储库。

在使用此过程之前，请在 Azure 订阅中创建日志分析工作区。 最好在工作负荷所在的相同区域中设置工作区。

要配置来源报告任务，请执行以下操作：

1. 在 NiFi 中打开控制器设置。
2. 选择报告任务菜单。
3. 选择“新建报告任务”。
4. 选择“Azure Log Analytics 报告任务”。

以下屏幕截图显示了此报告任务的“属性”菜单：

两个属性都是必需的：

• 日志分析工作区 ID
• 日志分析工作区密钥

可以通过导航到 Log Analytics 工作区在 Azure 门户中找到这些值。

其他选项也可用于自定义和筛选系统发送的来源事件。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。

你可以从身份验证和授权的角度保护 NiFi。 还可以针对所有网络通信保护 NiFi，包括：

• 群集内。
• 群集和 ZooKeeper 之间。

有关打开以下选项的说明，请参阅 Apache NiFi 管理员指南：

• Kerberos
• 轻型目录访问协议 (LDAP)
• 基于证书的身份验证和授权
• 用于群集通信的双向安全套接字层 (SSL)

如果打开 ZooKeeper 安全客户端访问，请通过将相关属性添加到其 bootstrap.conf 配置文件来配置 NiFi。 配置条目示例如下：

java.arg.18=-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
java.arg.19=-Dzookeeper.client.secure=true
java.arg.20=-Dzookeeper.ssl.keyStore.location=/path/to/keystore.jks
java.arg.21=-Dzookeeper.ssl.keyStore.password=[KEYSTORE PASSWORD]
java.arg.22=-Dzookeeper.ssl.trustStore.location=/path/to/truststore.jks
java.arg.23=-Dzookeeper.ssl.trustStore.password=[TRUSTSTORE PASSWORD]

有关一般建议，请参阅 Linux 安全基线。

网络安全

实现此解决方案时，请记住以下网络安全要点：

网络安全组

在 Azure 中，可以使用网络安全组来限制网络流量。

建议使用 jumpbox 连接到 NiFi 群集以执行管理任务。 将此安全强化 VM 与实时 (JIT) 访问或 Azure Bastion 一起使用。 设置网络安全组以控制如何授予对 jumpbox 或 Azure Bastion 的访问权限。 你可以通过在体系结构的各个子网上明智地使用网络安全组来实现网络隔离和控制。

以下屏幕截图显示了典型虚拟网络中的组件。 它包含用于 jumpbox、虚拟机规模集和 ZooKeeper VM 的公共子网。 此简化的网络拓扑将组件分组到一个子网中。 遵循组织的职责分离和网络设计指南。

出站 Internet 访问注意事项

Azure 中的 NiFi 无需访问公共 Internet 即可运行。 如果数据流无需 Internet 访问即可检索数据，请按照以下步骤禁用出站 Internet 访问来提高群集的安全性：

1. 在虚拟网络中创建额外的网络安全组规则。

2. 使用这些设置：

   • 来源：Any
   • 目标：Internet
   • 操作：Deny

使用此规则时，如果在虚拟网络中配置了专用终结点，则仍然可以从数据流访问某些 Azure 服务。 为此，请使用 Azure 专用链接。 此服务可提供一种无需任何其他外部网络访问，即可让流量在 Microsoft 主干网络中传输的方式。 NiFi 目前支持 Blob 存储和 Data Lake Storage 处理器的专用链接。 如果网络时间协议 (NTP) 服务器在专用网络中不可用，请允许对 NTP 的出站访问。 有关详细信息，请参阅 Azure 中 Linux VM 的时间同步。

数据保护

可以在不安全的情况下运行 NiFi，无需有线加密、标识和访问管理 (IAM) 或数据加密。 但最好通过以下方式保护生产和公共云部署：

• 使用传输层安全性 (TLS) 加密通信
• 使用受支持的身份验证和授权机制
• 加密静态数据

Azure 存储提供服务器端透明数据加密。 但从 1.13.2 版本开始，NiFi 默认不配置有线加密或 IAM。 此行为在将来的版本中可能会发生变化。

以下部分显示如何通过下列方式保护部署：

• 使用 TLS 启用有线加密
• 配置基于证书或 Microsoft Entra ID 的身份验证
• 管理 Azure 上的加密存储

磁盘加密

要提高安全性，请使用 Azure 磁盘加密。 有关详细过程，请参阅使用 Azure CLI 对虚拟机规模集中的 OS 和附加数据磁盘进行加密。 该文档还包含有关提供自己的加密密钥的说明。 以下步骤概述了适用于大多数部署的 NiFi 的基本示例：

1. 要在现有 Key Vault 实例中启用磁盘加密，请使用以下 Azure CLI 命令：

   az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
   

2. 使用以下命令打开虚拟机规模集数据磁盘的加密：

   az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
   

3. 可以选择使用密钥加密密钥 (KEK)。 使用以下 Azure CLI 命令通过 KEK 进行加密：

   az vmss encryption enable --resource-group myResourceGroup --name  myScaleSet  \
   --disk-encryption-keyvault myKeyVaultID \
   --key-encryption-keyvault myKeyVaultID \
   --key-encryption-key https://<mykeyvaultname>.vault.azure.net/keys/myKey/<version> \
   --volume-type DATA
   
   

传输中加密

NiFi 支持将 TLS 1.2 用于传输中加密。 该协议为用户访问 UI 提供保护。 通过群集，该协议可保护 NiFi 节点之间的通信。 它还可以保护与 ZooKeeper 的通信。 启用 TLS 时，NiFi 针对以下内容使用相互 TLS (mTLS) 进行相互身份验证：

• 基于证书的客户端身份验证（如果配置了此类身份验证）。
• 所有群集内通信。

要启用 TLS，请执行以下步骤：

1. 针对客户端-服务器和群集内通信和身份验证创建密钥存储和信任存储。

2. 配置 $NIFI_HOME/conf/nifi.properties。 设置以下值：

   • 主机名
   • 端口
   • 密钥存储属性
   • 信任存储属性
   • 群集和 ZooKeeper 安全属性（如果适用）

3. 在 $NIFI_HOME/conf/authorizers.xml 中配置身份验证，通常使用具有基于证书的身份验证或其他选项的初始用户。

4. （可选）在 NiFi 和任何代理、负载均衡器或外部终结点之间配置 mTLS 和代理读取策略。

有关完整的演练，请参阅 Apache 项目文档中的使用 TLS 保护 NiFi。

证书、密钥和密钥存储

要支持 TLS，请生成证书，将它们存储在 Java 密钥存储和信任存储中，然后将它们分发到 NiFi 群集中。 证书有两个常规选项：

• 自签名证书
• 认证机构 (CA) 签名的证书

对于 CA 签名的证书，最好使用中间 CA 为群集中的节点生成证书。

密钥存储和信任存储是 Java 平台中的密钥和证书容器。 密钥存储存储群集中节点的私钥和证书。 信任存储存储以下类型的证书之一：

• 所有受信任的证书，对于密钥存储中的自签名证书
• 来自 CA 的证书，对于密钥存储中的 CA 签名的证书

选择容器时，请记住 NiFi 群集具有可伸缩性。 例如，你将来可能希望增加或减少群集中的节点数量。 在这种情况下，选择密钥存储中的 CA 签名的证书和信任存储中的一个或多个来自 CA 的证书。 使用此选项时，无需更新群集的现有节点中的现有信任存储。 现有的信任存储信任并接受以下类型的节点中的证书：

• 添加到群集的节点
• 替换群集中其他节点的节点

NiFi 配置

要为 NiFi 启用 TLS，请使用 $NIFI_HOME/conf/nifi.properties 配置此表中的属性。 确保以下属性包含你用于访问 NiFi 的主机名：

• nifi.web.https.host 或 nifi.web.proxy.host
• 主机证书的指定名称或使用者可选名称

否则，可能会导致主机名验证失败或 HTTP 主机头验证失败，从而拒绝你的访问。

属性名称	说明	示例值
nifi.web.https.host	用于 UI 和 REST API 的主机名或 IP 地址。 此值应是内部可解析的。 建议不要使用可公开访问的名称。	nifi.internal.cloudapp.net
nifi.web.https.port	用于 UI 和 REST API 的 HTTPS 端口。	9443（默认值）
nifi.web.proxy.host	客户端用于访问 UI 和 REST API 的备用主机名的以逗号分隔的列表。 此列表通常包括在服务器证书中指定为使用者可选名称 (SAN) 的任何主机名。 该列表还可以包括负载均衡器、代理或 Kubernetes 入口控制器使用的任何主机名和端口。	40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore	包含证书私钥的 JKS 或 PKCS12 密钥存储的路径。	./conf/keystore.jks
nifi.security.keystoreType	密钥存储类型。	JKS 或 PKCS12
nifi.security.keystorePasswd	密钥存储密码。	O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd	（可选）私钥的密码。
nifi.security.truststore	JKS 或 PKCS12 信任存储的路径，信任存储包含用于对受信任的用户和群集节点进行身份验证的证书或 CA 证书。	./conf/truststore.jks
nifi.security.truststoreType	信任存储类型。	JKS 或 PKCS12
nifi.security.truststorePasswd	信任存储密码。	RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure	群集内通信的 TLS 状态。 如果 nifi.cluster.is.node 为 true，则将此值设置为 true 以启用群集 TLS。	true
nifi.remote.input.secure	站点到站点通信的 TLS 状态。	true

以下示例显示这些属性在 $NIFI_HOME/conf/nifi.properties 中的显示方式。 请注意，nifi.web.http.host 和 nifi.web.http.port 值为空白。

nifi.remote.input.secure=true
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=nifi.internal.cloudapp.net
nifi.web.https.port=9443
nifi.web.proxy.host=40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore=./conf/keystore.jks 
nifi.security.keystoreType=JKS          
nifi.security.keystorePasswd=O8SitLBYpCz7g/RpsqH+zM                  
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks                                   
nifi.security.truststoreType=JKS
nifi.security.truststorePasswd=RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure=true

ZooKeeper 配置

有关在 Apache ZooKeeper 中启用 TLS 以进行仲裁通信和客户端访问的说明，请参阅 ZooKeeper 管理员指南。 只有 3.5.5 或更高版本支持此功能。

NiFi 使用 ZooKeeper 来实现其零领导者群集和群集协调功能。 从版本 1.13.0 开始，NiFi 支持安全客户端访问启用 TLS 的 ZooKeeper 实例。 ZooKeeper 以纯文本形式存储群集成员身份和群集范围的处理器状态。 因此，请务必使用对 ZooKeeper 的安全客户端访问来验证 ZooKeeper 客户端请求。 此外，还会加密传输中的敏感值。

要为对 ZooKeeper 的 NiFi 客户端访问启用 TLS，请在 $NIFI_HOME/conf/nifi.properties 中设置以下属性。 如果在未配置 nifi.zookeeper.security 属性的情况下设置 nifi.zookeeper.client.securetrue，则 NiFi 会回退到你在 nifi.securityproperties 中指定的密钥存储和信任存储。

属性名称	说明	示例值
nifi.zookeeper.client.secure	连接到 ZooKeeper 时的客户端 TLS 状态。	true
nifi.zookeeper.security.keystore	JKS、PKCS12 或 PEM 密钥存储的路径，密钥存储包含提供给 ZooKeeper 以进行身份验证的证书的私钥。	./conf/zookeeper.keystore.jks
nifi.zookeeper.security.keystoreType	密钥存储类型。	JKS、PKCS12、PEM 或通过扩展自动检测
nifi.zookeeper.security.keystorePasswd	密钥存储密码。	caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd	（可选）私钥的密码。
nifi.zookeeper.security.truststore	JKS、PKCS12 或 PEM 信任存储的路径，信任存储包含用于对 ZooKeeper 进行身份验证的证书或 CA 证书。	./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType	信任存储类型。	JKS、PKCS12、PEM 或通过扩展自动检测
nifi.zookeeper.security.truststorePasswd	信任存储密码。	qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string	ZooKeeper 主机或仲裁的连接字符串。 此字符串是 host:port 值的以逗号分隔的列表。 通常，secureClientPort 值与 clientPort 值不同。 请参阅 ZooKeeper 配置以获取正确的值。	zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281

以下示例显示这些属性在 $NIFI_HOME/conf/nifi.properties 中的显示方式：

nifi.zookeeper.client.secure=true
nifi.zookeeper.security.keystore=./conf/keystore.jks
nifi.zookeeper.security.keystoreType=JKS
nifi.zookeeper.security.keystorePasswd=caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd=
nifi.zookeeper.security.truststore=./conf/truststore.jks
nifi.zookeeper.security.truststoreType=JKS
nifi.zookeeper.security.truststorePasswd=qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string=zookeeper1.internal.cloudapp.net:2281,zookeeper2.internal.cloudapp.net:2281,zookeeper3.internal.cloudapp.net:2281

有关使用 TLS 保护 ZooKeeper 的详细信息，请参阅 Apache NiFi 管理指南。

标识和访问控制

在 NiFi 中，标识和访问控制是通过用户身份验证和授权来实现的。 对于用户身份验证，NiFi 有多个选项可供选择：单用户、LDAP、Kerberos、安全断言标记语言 (SAML) 和 OpenID Connect (OIDC)。 如果未配置选项，NiFi 会使用客户端证书通过 HTTPS 对用户进行身份验证。

如果你正在考虑使用多重身份验证，建议结合使用 Microsoft Entra ID 和 OIDC。 Microsoft Entra ID 支持使用 OIDC 的云原生单一登录 (SSO)。 通过这种组合，用户可以利用许多企业安全功能：

• 记录用户帐户中的可疑活动并发出警报
• 监视尝试访问已停用凭据的行为
• 对异常帐户登录行为发出警报

对于授权，NiFi 会基于用户、组和访问策略强制执行。 NiFi 通过 UserGroupProviders 和 AccessPolicyProviders 来实现此强制执行。 默认情况下，提供程序包括基于文件、LDAP、Shell 和 Azure Graph 的 UserGroupProviders。 使用 AzureGraphUserGroupProvider，你可以通过 Microsoft Entra ID 获取用户组。 然后，可以将策略分配给这些组。 有关配置说明，请参阅 Apache NiFi 管理指南。

基于文件和 Apache Ranger 的 AccessPolicyProviders 当前可用于管理和存储用户和组策略。 有关详细信息，请参阅 Apache NiFi 文档和 Apache Ranger 文档。

应用程序网关

应用程序网关为 NiFi 接口提供托管的第 7 层负载均衡器。 将应用程序网关配置为使用 NiFi 节点的虚拟机规模集作为其后端池。

对于大多数 NiFi 安装，建议使用以下应用程序网关配置：

• “层”：标准
• SKU 大小：中
• 实例计数：两个或更多

使用运行状况探测来监视每个节点上 Web 服务器的运行状况。 从负载均衡器轮换中删除运行不正常的节点。 当整个群集运行不正常时，此方法可以更轻松地查看用户界面。 浏览器仅将你定向到当前运行状况良好并可响应请求的节点。

需要考虑两个关键运行状况探测。 它们共同为群集中每个节点的总体运行状况提供定期检测信号。 将第一个运行状况探测配置为指向路径 /NiFi。 此探测确定每个节点上 NiFi 用户界面的运行状况。 针对路径 /nifi-api/controller/cluster 配置第二个运行状况探测。 此探测指示每个节点当前的运行状况是否正常以及是否已联接到整个群集。

有两个选项可用于配置应用程序网关的前端 IP 地址：

• 使用公共 IP 地址
• 使用专用子网 IP 地址

仅当用户需要通过公共 Internet 访问 UI 时，才包含公共 IP 地址。 如果不需要为用户提供公共 Internet 访问，请从虚拟网络中的 jumpbox 或通过与专用网络的对等互连来访问负载均衡器前端。 如果使用公共 IP 地址配置应用程序网关，建议为 NiFi 启用客户端证书身份验证并为 NiFi UI 启用 TLS。 还可以使用委派的应用程序网关子网中的网络安全组来限制源 IP 地址。

诊断和运行状况监视

在应用程序网关的诊断设置中，有一个用于发送指标和访问日志的配置选项。 通过使用此选项，可以将此信息从负载均衡器发送到各个位置：

• 存储帐户
• 事件中心
• Log Analytics 工作区

对于调试负载均衡问题和深入了解群集节点的运行状况而言，启用此设置非常有用。

以下 Log Analytics 查询从应用程序网关的角度显示了一段时间内群集节点的运行状况。 可以使用类似的查询针对运行不正常的节点生成警报或自动修复操作。

AzureDiagnostics
| summarize UnHealthyNodes = max(unHealthyHostCount_d), HealthyNodes = max(healthyHostCount_d) by bin(TimeGenerated, 5m)
| render timechart

以下查询结果图表显示了群集运行状况的时间视图：

可用性

实现此解决方案时，请记住以下可用性要点：

负载均衡器

为 UI 使用负载均衡器，以在节点故障期间提高 UI 可用性。

单独的 VM

为了提高可用性，请将 ZooKeeper 群集部署在单独的 VM 上，而不是 NiFi 群集中的 VM。 有关配置 ZooKeeper 的详细信息，请参阅 Apache NiFi 系统管理员指南中的状态管理。

可用性区域

在跨区域配置中部署 NiFi 虚拟机规模集和 ZooKeeper 群集，以最大限度地提高可用性。 当群集中节点之间的通信跨可用性区域进行时，会引入少量延迟。 但这种延迟通常对群集吞吐量的总体影响很小。

虚拟机规模集

建议将 NiFi 节点部署到跨可用性区域（如果有）的单个虚拟机规模集中。 有关以此方式使用规模集的详细信息，请参阅创建使用可用性区域的虚拟机规模集。

监视

有多种选项可用于监视 NiFi 群集的运行状况和性能：

• 报告任务。
• MonitoFi，一种独立的 Microsoft 开发的应用程序。 MonitoFi 在外部运行，并使用 NiFi API 监视群集。

基于报告任务的监视

对于监视，可以使用在 NiFi 中配置和运行的报告任务。 如诊断和运行状况监视所述，Log Analytics 在 NiFi Azure 程序包中提供了报告任务。 可以使用该报告任务将使用 Log Analytics 进行监视与现有监视或日志记录系统集成。

Log Analytics 查询

以下部分中的示例查询可帮助你入门。 有关如何查询 Log Analytics 数据的概述，请参阅 Azure Monitor 日志查询。

Monitor 和 Log Analytics 中的日志查询使用某种版本的 Kusto 查询语言。 但日志查询和 Kusto 查询之间存在差异。 有关详细信息，请参阅 Kusto 查询概述。

有关结构化学习的更多信息，请参阅以下教程：

• Azure Monitor 中的日志查询入门
• Azure Monitor 中的 Log Analytics 入门

Log Analytics 报告任务

默认情况下，NiFi 将指标数据发送到 nifimetrics 表。 但可以在报告任务属性中配置不同的目标。 报告任务捕获以下 NiFi 指标：

指标类型	指标名称
NiFi 指标	FlowFilesReceived
NiFi 指标	FlowFilesSent
NiFi 指标	FlowFilesQueued
NiFi 指标	BytesReceived
NiFi 指标	BytesWritten
NiFi 指标	BytesRead
NiFi 指标	BytesSent
NiFi 指标	BytesQueued
端口状态指标	InputCount
端口状态指标	InputBytes
连接状态指标	QueuedCount
连接状态指标	QueuedBytes
端口状态指标	OutputCount
端口状态指标	OutputBytes
JVM 指标	jvm.uptime
JVM 指标	jvm.heap_used
JVM 指标	jvm.heap_usage
JVM 指标	jvm.non_heap_usage
JVM 指标	jvm.thread_states.runnable
JVM 指标	jvm.thread_states.blocked
JVM 指标	jvm.thread_states.timed_waiting
JVM 指标	jvm.thread_states.terminated
JVM 指标	jvm.thread_count
JVM 指标	jvm.daemon_thread_count
JVM 指标	jvm.file_descriptor_usage
JVM 指标	jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation
JVM 指标	jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation
JVM 指标	jvm.buff_pool_direct_capacity
JVM 指标	jvm.buff_pool_direct_count
JVM 指标	jvm.buff_pool_direct_mem_used
JVM 指标	jvm.buff_pool_mapped_capacity
JVM 指标	jvm.buff_pool_mapped_count
JVM 指标	jvm.buff_pool_mapped_mem_used
JVM 指标	jvm.mem_pool_code_cache
JVM 指标	jvm.mem_pool_compressed_class_space
JVM 指标	jvm.mem_pool_g1_eden_space
JVM 指标	jvm.mem_pool_g1_old_gen
JVM 指标	jvm.mem_pool_g1_survivor_space
JVM 指标	jvm.mem_pool_metaspace
JVM 指标	jvm.thread_states.new
JVM 指标	jvm.thread_states.waiting
处理器级别指标	BytesRead
处理器级别指标	BytesWritten
处理器级别指标	FlowFilesReceived
处理器级别指标	FlowFilesSent

下面是针对群集的 BytesQueued 指标的示例查询：

let table_name = nifimetrics_CL;
let metric = "BytesQueued";
table_name
| where Name_s == metric
| where Computer contains {ComputerName}
| project TimeGenerated, Computer, ProcessGroupName_s,  Count_d, Name_s
| summarize sum(Count_d) by bin(TimeGenerated, 1m),  Computer, Name_s
| render timechart 

该查询会生成一个图表，如以下屏幕截图所示：

NiFi 基础结构监视

除了报告任务，还需在 NiFi 和 ZooKeeper 节点上安装 Log Analytics VM 扩展。 此扩展从 ZooKeeper 收集日志、其他 VM 级别指标和指标。

NiFi 应用、用户、启动和 ZooKeeper 的自定义日志

要捕获更多日志，请执行以下步骤：

1. 在 Azure 门户中，选择“Log Analytics 工作区”，然后选择你的工作区。

2. 在“设置”下选择“自定义日志”。

   

3. 选择“添加自定义日志”。

   

4. 使用以下值设置自定义日志：

   • 名称：NiFiAppLogs
   • 路径类型：Linux
   • 路径名称：/opt/nifi/logs/nifi-app.log

   

5. 使用以下值设置自定义日志：

   • 名称：NiFiBootstrapAndUser
   • 第一个路径类型：Linux
   • 第一个路径名称：/opt/nifi/logs/nifi-user.log
   • 第二个路径类型：Linux
   • 第二个路径名称：/opt/nifi/logs/nifi-bootstrap.log

   

6. 使用以下值设置自定义日志：

   • 名称：NiFiZK
   • 路径类型：Linux
   • 路径名称：/opt/zookeeper/logs/*.out

   

下面是第一个示例创建的 NiFiAppLogs 自定义表的示例查询：

NiFiAppLogs_CL
| where TimeGenerated > ago(24h)
| where Computer contains {ComputerName} and RawData contains "error"
| limit 10

该查询生成的结果类似于以下结果：

基础结构日志配置

可以使用 Monitor 来监视和管理 VM 或物理计算机。 这些资源可位于本地数据中心或其他云环境中。 要设置此监视，请部署 Log Analytics 代理。 将该代理配置为向 Log Analytics 工作区报告。 有关详细信息，请参阅 Log Analytics 代理概述。

以下屏幕截图显示了 NiFi VM 的示例代理配置。 Perf 表存储收集的数据。

下面是 NiFi 应用 Perf 日志的示例查询：

let cluster_name = {ComputerName};
// The hourly average of CPU usage across all computers.
Perf
| where Computer contains {ComputerName}
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| where ObjectName == "Processor"
| summarize CPU_Time_Avg = avg(CounterValue) by bin(TimeGenerated, 30m), Computer

该查询会生成一个报表，如以下屏幕截图所示：

警报

使用 Monitor 创建有关 NiFi 群集的运行状况和性能的警报。 示例警报包括：

• 总队列计数已超过阈值。
• BytesWritten 值低于预期阈值。
• FlowFilesReceived 值低于阈值。
• 群集运行不正常。

有关在 Monitor 中设置警报的详细信息，请参阅 Microsoft Azure 中的警报概述。

配置参数

以下部分讨论 NiFi 及其依赖项的建议非默认配置，包括 ZooKeeper 和 Java。 这些设置适用于云中可能存在的群集大小。 在以下配置文件中设置属性：

• $NIFI_HOME/conf/nifi.properties
• $NIFI_HOME/conf/bootstrap.conf
• $ZOOKEEPER_HOME/conf/zoo.cfg
• $ZOOKEEPER_HOME/bin/zkEnv.sh

有关可用配置属性和文件的详细信息，请参阅 Apache NiFi 系统管理员指南和 ZooKeeper 管理员指南。

NiFi

对于 Azure 部署，请考虑调整 $NIFI_HOME/conf/nifi.properties 中的属性。 下表列出了最重要的属性。 有关更多建议和见解，请参阅 Apache NiFi 邮件列表。

参数	描述	默认	建议
nifi.cluster.node.connection.timeout	打开与其他群集节点的连接时的等待时间。	5 秒	60 秒
nifi.cluster.node.read.timeout	向其他群集节点发送请求时等待响应的时间。	5 秒	60 秒
nifi.cluster.protocol.heartbeat.interval	将检测信号发送回群集协调器的频率。	5 秒	60 秒
nifi.cluster.node.max.concurrent.requests	将 HTTP 调用（如 REST API 调用）复制到其他群集节点时要使用的并行级别。	100	500
nifi.cluster.node.protocol.threads	群集间/复制通信的初始线程池大小。	10	50
nifi.cluster.node.protocol.max.threads	用于群集间/复制通信的最大线程数。	50	75
nifi.cluster.flow.election.max.candidates	确定当前流时使用的节点数。 此值将投票削减到指定数量。	empty	75
nifi.cluster.flow.election.max.wait.time	在确定当前流之前等待节点的时间。	5 分钟	5 分钟

群集行为

配置群集时，请记住以下几点。

超时

为了确保群集及其节点的总体运行状况，增加超时可能是有益的。 此做法有助于确保故障不是由瞬态网络问题或高负载导致的。

在分布式系统中，各个系统的性能各不相同。 此变化包括网络通信和延迟，通常会影响节点间、群集间的通信。 网络基础结构或系统本身可能会导致出现此变化。 因此，在大型系统群集中很可能发生变化。 在低负载的 Java 应用程序中，Java 虚拟机 (JVM) 中的垃圾回收 (GC) 暂停也会影响请求响应时间。

使用以下部分中的属性来配置超时，以满足系统需求：

nifi.cluster.node.connection.timeout 和 nifi.cluster.node.read.timeout

nifi.cluster.node.connection.timeout 属性指定打开连接时的等待时间。 nifi.cluster.node.read.timeout 属性指定在请求之间接收数据时要等待的时间。 每个属性的默认值为 5 秒。 这些属性适用于节点到节点的请求。 增加这些值有助于缓解几个相关的问题：

• 由于检测信号中断而被群集协调器断开连接
• 联接群集时，无法从协调器获取流
• 建立站点到站点 (S2S) 和负载均衡通信

除非群集具有非常小型的规模集（例如三个节点或更少），否则请使用大于默认值的值。

nifi.cluster.protocol.heartbeat.interval

作为 NiFi 群集策略的一部分，每个节点都会发出检测信号来传达其运行状况。 默认情况下，节点每五秒发送一次检测信号。 如果群集协调器检测到来自某个节点的连续八个检测信号出现故障，它会断开与该节点的连接。 增加在 nifi.cluster.protocol.heartbeat.interval 属性中设置的时间间隔，以帮助适应慢速检测信号并防止群集在不必要的情况下断开与节点的连接。

并发

使用以下部分中的属性来配置并发设置：

nifi.cluster.node.protocol.threads 和 nifi.cluster.node.protocol.max.threads

nifi.cluster.node.protocol.max.threads 属性指定用于所有群集通信的最大线程数，例如 S2S 负载均衡和 UI 聚合。 此属性的默认值为 50 个线程。 对于大型群集，考虑到这些操作需要的请求更多，请增大此值。

nifi.cluster.node.protocol.threads 属性确定初始线程池大小。 默认值为 10 个线程。 此值为最小值。 它会按需增加，直到达到 nifi.cluster.node.protocol.max.threads 中设置的最大值。 增加在启动时使用大型规模集的群集的 nifi.cluster.node.protocol.threads 值。

nifi.cluster.node.max.concurrent.requests

许多 HTTP 请求（如 REST API 调用和 UI 调用）都需要复制到群集中的其他节点。 随着群集大小的增长，复制的请求越来越多。 nifi.cluster.node.max.concurrent.requests 属性限制未完成请求的数量。 它的值应该超过预期的群集大小。 默认值为 100 个并发请求。 除非你正在运行包含三个或更少节点的小型群集，否则请通过增加此值来防止出现失败的请求。

流选择

使用以下部分中的属性来配置流选择设置：

nifi.cluster.flow.election.max.candidates

NiFi 使用零领导者群集，这意味着没有一个特定的权威节点。 因此，节点会投票决定将哪个流定义视为是正确的。 它们还会投票决定哪些节点会联接群集。

默认情况下，nifi.cluster.flow.election.max.candidates 属性是 nifi.cluster.flow.election.max.wait.time 属性指定的最长等待时间。 如果此值太高，启动可能会很慢。 nifi.cluster.flow.election.max.wait.time 的默认值为 5 分钟。 将最大候选项数设置为非空值（例如 1 或更大的值），以确保等待时间不会超过所需时间。 如果设置了此属性，请为其分配一个值，该值对应于群集大小或预期群集大小的某个多数部分。 对于 10 个或更少节点的小型静态群集，请将此值设置为群集中的节点数。

nifi.cluster.flow.election.max.wait.time

在弹性云环境中，预配主机的时间会影响应用程序的启动时间。 nifi.cluster.flow.election.max.wait.time 属性确定 NiFi 在确定流之前要等待的时间。 使该值与群集在其起始大小时的总体启动时间相符。 在初始测试中，对于所有具有推荐实例类型的 Azure 区域，五分钟已绰绰有余。 但是，如果预配时间频繁超过默认值，则可以增加此值。

Java

建议使用 Java 的 LTS 版本。 在这些版本中，Java 11 略优于 Java 8，因为 Java 11 支持实现更快的垃圾回收。 但是，使用任一版本都可以实现高性能 NiFi 部署。

以下部分介绍了运行 NiFi 时要使用的常用 JVM 配置。 在 $NIFI_HOME/conf/bootstrap.conf 的启动配置文件中设置 JVM 参数。

垃圾回收器

如果运行的是 Java 11，建议在大多数情况下使用 G1 垃圾回收器 (G1GC)。 相较于 ParallelGC，G1GC 提高了性能，因为 G1GC 减少了 GC 暂停的时长。 G1GC 是 Java 11 中的默认设置，但可以通过在 bootstrap.conf 中设置以下值来显式配置它：

java.arg.13=-XX:+UseG1GC

如果运行的是 Java 8，请不要使用 G1GC。 请改用 ParallelGC。 G1GC 的 Java 8 实现存在缺陷，让你无法将其与建议的存储库实现一起使用。 ParallelGC 比 G1GC 慢。 但是使用 ParallelGC，你仍然可以使用 Java 8 实现高性能 NiFi 部署。

堆

bootstrap.conf 文件中的一组属性决定 NiFi JVM 堆的配置。 对于标准流，请使用以下设置配置 32 GB 的堆：

java.arg.3=-Xmx32g
java.arg.2=-Xms32g

要选择适用于 JVM 进程的最佳堆大小，请考虑两个因素：

• 数据流的特征
• NiFi 在处理过程中使用内存的方式

有关详细文档，请参阅 Depth 中的 Apache NiFi。

仅将堆设置为刚好满足处理要求的大小。 从方法可最大限度地减少 GC 暂停的时长。 有关 Java 垃圾回收的一般注意事项，请参阅你的 Java 版本的垃圾回收优化指南。

调整 JVM 内存设置时，请考虑以下重要因素：

• 在给定时间段内处于活动状态的 FlowFile 或 NiFi 数据记录的数目。 此数字包括背压或排队的 FlowFiles。

• FlowFiles 中定义的属性数。

• 处理器处理特定内容所需的内存量。

• 处理器处理数据的方式：

  • 流式处理数据
  • 使用面向记录的处理器
  • 一次将所有数据保存在内存中

这些详细信息很重要。 在处理过程中，NiFi 在内存中保存每个 FlowFile 的引用和属性。 在最高性能时，系统使用的内存量与活动 FlowFiles 及其包含的所有属性的数量成正比。 此数字包括排队的 FlowFiles。 NiFi 可以交换为磁盘。 但请避免使用此选项，因为它会损害性能。

另请注意基本对象的内存使用情况。 具体来说，使堆足够大，以便在内存中保存对象。 考虑以下配置内存设置的提示：

• 从设置 -Xmx4G 开始，然后根据需要保守地增加内存，以使用具有代表性的数据和最小的背压运行流。
• 从设置 -Xmx4G 开始，然后根据需要保守地增加群集，以使用具有代表性的数据和峰值背压运行流。
• 使用 VisualVM 和 YourKit 等工具在流运行时分析应用程序。
• 如果保守地增加堆不能显著提高性能，请考虑重新设计流、处理器和系统的其他方面。

其他 JVM 参数

下表列出了其他 JVM 选项。 它还提供了在初始测试中效果最佳的值。 测试观察到的 GC 活动和内存使用情况，并进行了仔细的分析。

参数	说明	JVM 默认值	建议
InitiatingHeapOccupancyPercent	触发标记循环之前使用的堆的数量。	45	35
ParallelGCThreads	GC 使用的线程数。 此值具有上限，以限制对系统的整体影响。	vCPU 数的 5/8	8
ConcGCThreads	要并行运行的 GC 线程数。 考虑到 ParallelGCThreads 上限，增加此值。	ParallelGCThreads 值的 1/4	4
G1ReservePercent	可用预留内存的百分比。 增加此值以避免空间耗尽，这有助于避免 GC 已满。	10	20
UseStringDeduplication	是否尝试标识和删除对相同字符串的重复引用。 启用此功能可以节省内存。	-	礼物

通过将以下条目添加到 NiFi bootstrap.conf 来配置这些设置：

java.arg.17=-XX:+UseStringDeduplication
java.arg.18=-XX:G1ReservePercent=20
java.arg.19=-XX:ParallelGCThreads=8
java.arg.20=-XX:ConcGCThreads=4
java.arg.21=-XX:InitiatingHeapOccupancyPercent=35

ZooKeeper

为了提高容错能力，请将 ZooKeeper 作为群集运行。 即使大多数 NiFi 部署在 ZooKeeper 上的负载相对较小，也可以采用此方法。 显式启用 ZooKeeper 的群集。 默认情况下，ZooKeeper 以单服务器模式运行。 有关详细信息，请参阅 ZooKeeper 管理员指南中的群集（多服务器）设置。

除群集设置外，请使用 ZooKeeper 配置的默认值。

如果使用大型 NiFi 群集，可能需要使用更多的 ZooKeeper 服务器。 对于较小的群集大小，较小的 VM 大小和标准 SSD 托管磁盘就足够了。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

首席作者：

• Muazma Zahid | 首席项目经理

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

本文档中的材料和建议来自多个源：

• 试验
• Azure 最佳实践
• NiFi 社区知识、最佳做法和文档

有关详细信息，请参阅以下资源：

• Apache NiFi 系统管理员指南
• Apache NiFi 邮件列表
• Cloudera 设置高性能 NiFi 安装的最佳做法
• Azure 高级存储：高性能设计
• 排查 Linux 或 Windows 上的 Azure 虚拟机性能问题

相关资源

• 使用 MonitoFi 进行 Apache NiFi 监视
• Apache NiFi 的基于 Helm 的部署
• Azure 数据资源管理器监视
• [具有 Azure 数据工厂的混合 ETL][具有 Azure 数据工厂 的混合 ETL]
• [新式数据仓库的 DataOps][新式数据仓库的 DataOps]
• 数据仓库和分析