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 層負載平衡。

• 監視及其 Log Analytics 功能會收集、分析及處理來自 NiFi 系統的遙測。 遙測包括 NiFi 系統記錄、系統健康情況計量和效能計量。

• Azure 金鑰保存庫 安全地儲存 NiFi 叢集的憑證和密鑰。

• Microsoft Entra ID 提供單一登錄和多重要素驗證。

元件

• NiFi 提供處理和散發數據的系統。
• ZooKeeper 是一部開放原始碼伺服器，可管理分散式系統。
• 虛擬機器 是基礎結構即服務 （IaaS） 供應專案。 您可以使用 虛擬機器 來部署隨選、可調整的運算資源。 虛擬機器 提供虛擬化的彈性，但可排除實體硬體的維護需求。
• Azure 虛擬機器擴展集 提供一種方式來管理一組負載平衡的 VM。 集合中的 VM 實例數目可以自動增加或減少，以回應需求或定義的排程。
• 可用性區域 是 Azure 區域內的唯一實體位置。 這些高可用性供應項目可保護應用程式和數據免於資料中心失敗。
• 應用程式閘道 是一個負載平衡器，可管理 Web 應用程式的流量。
• 監視 會收集和分析環境和 Azure 資源上的數據。 此數據報括應用程式遙測，例如效能計量和活動記錄。 如需詳細資訊，請參閱 本文稍後的監視考慮 。
• Log Analytics 是 Azure 入口網站 工具，可在監視記錄數據上執行查詢。 Log Analytics 也提供圖表和統計分析查詢結果的功能。
• Azure DevOps Services 提供用於管理程式碼專案和部署的服務、工具和環境。
• 金鑰保存庫 安全地儲存和控制系統秘密的存取權，例如 API 金鑰、密碼、憑證和密碼編譯密鑰。
• Microsoft Entra ID 是雲端式身分識別服務，可控制對 Azure 和其他雲端應用程式的存取。

替代項目

• Azure Data Factory 提供此解決方案的替代方案。
• 您可以使用類似的服務來儲存系統秘密，而不是 金鑰保存庫。
• Apache Airflow。 查看 空氣流量和 NiFi 如何不同。
• 您可以使用支援的企業 NiFi 替代方案，例如 Cloudera Apache NiFi。 Cloudera 供應專案可透過 Azure Marketplace 取得。

案例詳細資料

在此案例中，NiFi 會在擴展集中跨 Azure 虛擬機器 的叢集組態中執行。 但本文的大部分建議也適用於在單一虛擬機上以單一實例模式執行 NiFi 的案例。 本文中的最佳做法示範可調整、高可用性和安全部署。

潛在使用案例

NiFi 適用於行動資料及管理資料串流：

• 連線 雲端中分離的系統
• 將數據移入和移出 Azure 儲存體 和其他數據存放區
• 整合邊緣到雲端和混合式雲端應用程式與 Azure IoT、Azure Stack 和 Azure Kubernetes Service （AKS）

因此，此解決方案適用於許多領域：

• 新式數據倉儲 （MDWs） 會大規模整合結構化和非結構化數據。 他們會從各種來源、接收和格式收集及儲存數據。 NiFi 擅長將數據內嵌至 Azure 型 MDW，原因如下：

  • 超過 200 個處理器可用於讀取、寫入及操作數據。
  • 系統支援 儲存體 服務，例如 Azure Blob 儲存體、Azure Data Lake 儲存體、Azure 事件中樞、Azure 隊列 儲存體、Azure Cosmos DB 和 Azure Synapse Analytics。
  • 健全的數據證明功能可讓您實作相容的解決方案。 如需在 Azure 監視器 Log Analytics 功能中擷取數據來源的相關信息，請參閱 本文稍後的報告考慮 。

• NiFi 可以在小型裝置上獨立執行。 在這種情況下，NiFi 可讓您處理邊緣數據，並將該數據移至雲端中較大的 NiFi 實例或叢集。 NiFi 可協助篩選、轉換及排定動作邊緣數據的優先順序，確保可靠且有效率的數據流。

• 產業 IoT （IIoT） 解決方案可管理從邊緣到資料中心的數據流程。 該流程從從工業控制系統和設備取得數據開始。 然後，數據會移至數據管理解決方案和 MDW。 NiFi 提供適合資料擷取和行動的功能：

  • 邊緣數據處理功能
  • 支援IoT閘道和裝置使用的通訊協定
  • 與事件中樞和 儲存體服務整合

  預測性維護和供應鏈管理領域的IoT應用程式可以使用這項功能。

建議

當您使用此解決方案時，請記住下列幾點：

建議的 NiFi 版本

當您在 Azure 上執行此解決方案時，建議您使用 1.13.2+ 版 NiFi。 您可以執行其他版本，但可能需要與本指南中的版本不同的設定。

若要在 Azure VM 上安裝 NiFi，最好從 NiFi 下載頁面下載便利二進位檔。 您也可以從 原始程式碼建置二進位檔。

ZooKeeper 的建議版本

在此範例工作負載中，我們建議使用 3.5.5 版和更新版本或 3.6.x 版 ZooKeeper。

您可以使用官方便利二進位檔或原始程式碼，在 Azure VM 上安裝 ZooKeeper。 這兩者都可在 Apache ZooKeeper 版本頁面上取得。

考量

這些考量能實作 Azure Well-Architected Framework 的要素，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

如需設定 NiFi 的詳細資訊，請參閱 Apache NiFi 系統 管理員 istrator 指南。 當您實作此解決方案時，也請記住這些考慮。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。

• 使用 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
標準 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 系統 管理員 istrator 指南中的設定最佳做法。

儲存體

將數據磁碟上儲存各種 NiFi 存放庫，而不是儲存在 OS 磁碟上，有三個主要原因：

• 流程通常具有單一磁碟無法滿足的高磁碟輸送量需求。
• 最好將 NiFi 磁碟作業與 OS 磁碟作業分開。
• 存放庫不應該位於暫存記憶體上。

下列各節概述設定數據磁碟的指導方針。 這些指導方針專屬於 Azure。 如需設定存放庫的詳細資訊，請參閱 Apache NiFi 系統 管理員 istrator 指南中的狀態管理。

數據磁碟類型和大小

當您設定 NiFi 的數據磁碟時，請考慮這些因素：

• 磁碟類型
• 磁碟大小
• 磁碟總數

下表顯示 Azure 中目前可用的受控磁碟類型。 您可以使用 NiFi 搭配這些磁碟類型的任何一種。 但針對高輸送量數據流，我們建議 進階版 SSD。

	Ultra 磁碟 （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 的最佳做法指導方針是針對每個存放庫使用不同的磁碟或磁碟：

• Content
• 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 系統 管理員 istrator 指南中的證明存放庫。

使用此程式之前，請先在 Azure 訂用帳戶中建立 Log Analytics 工作區。 最好是在與工作負載相同的區域中設定工作區。

若要設定證明報告工作：

1. 在 NiFi 中開啟控制器設定。
2. 選取 [報告工作] 功能表。
3. 選取 [建立新的報告工作]。
4. 選取 [Azure Log Analytics 報告工作]。

下列螢幕快照顯示此報告工作的屬性選單：

需要兩個屬性：

• Log Analytics 工作區標識符
• Log Analytics 工作區密鑰

您可以流覽至 Log Analytics 工作區，在 Azure 入口網站 中找到這些值。

其他選項也可用於自定義和篩選系統傳送的源頭事件。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性要素的概觀。

您可以從驗證和授權觀點保護 NiFi。 您也可以為所有網路通訊保護 NiFi，包括：

• 在叢集中。
• 叢集與 ZooKeeper 之間。

如需開啟下列選項的指示，請參閱 Apache NiFi 管理員 istrators 指南：

• 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 搭配 Just-In-Time （JIT） 存取 或 Azure Bastion。 設定網路安全組來控制如何授與 Jumpbox 或 Azure Bastion 的存取權。 您可以藉由在架構的各種子網上明智地使用網路安全組來達成網路隔離和控制。

下列螢幕快照顯示一般虛擬網路中的元件。 它包含 Jumpbox、虛擬機擴展集和 ZooKeeper VM 的通用子網。 這個簡化的網路拓撲會將元件群組成一個子網。 遵循貴組織的職責和網路設計區隔指導方針。

輸出因特網存取考慮

Azure 中的 NiFi 不需要存取公用因特網來執行。 如果數據流不需要因特網存取以擷取數據，請遵循下列步驟來改善叢集的安全性，以停用輸出因特網存取：

1. 在虛擬網路中建立額外的網路安全組規則。

2. 使用下列設定：

   • 來源：Any
   • 目的地： Internet
   • 行動： Deny

有了此規則，如果您設定虛擬網路中的私人端點，您仍然可以從數據流存取某些 Azure 服務。 請針對此目的使用 Azure Private Link 。 此服務可讓您的流量在 Microsoft 骨幹網路上移動，而不需要任何其他外部網路存取。 NiFi 目前支援 Blob 儲存體 和 Data Lake 儲存體 處理器的 Private Link。 如果您的專用網中無法使用網路時間通訊協定 （NTP） 伺服器，請允許對 NTP 進行輸出存取。 如需詳細資訊，請參閱 Azure 中 Linux VM 的時間同步處理。

資料保護

不需要連線加密、身分識別和存取管理（IAM）或數據加密，即可操作 NiFi 不安全。 但最好以下列方式保護生產和公用雲端部署：

• 加密與傳輸層安全性的通訊 （TLS）
• 使用支持的驗證和授權機制
• 加密待用資料

Azure 儲存體 提供伺服器端透明數據加密。 但從 1.13.2 版開始，NiFi 預設不會設定有線加密或 IAM。 未來版本可能會變更此行為。

下列各節說明如何透過下列方式保護部署：

• 使用 TLS 啟用連線加密
• 根據憑證或 Microsoft Entra ID 設定驗證
• 管理 Azure 上的加密記憶體

磁碟加密

若要改善安全性，請使用 Azure 磁碟加密。 如需詳細程式，請參閱 使用 Azure CLI 加密虛擬機擴展集中的 OS 和鏈接數據磁碟。 該檔案也包含提供您自己的加密金鑰的指示。 下列步驟概述適用於大部分部署的 NiFi 基本範例：

1. 若要在現有的 金鑰保存庫 實例中開啟磁碟加密，請使用下列 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. 建立金鑰存放區和信任存放區，以用於用戶端-伺服器和 Intracluster 通訊和驗證。

2. 設定 $NIFI_HOME/conf/nifi.properties。 設定下列值：

   • 主機名稱
   • 連接埠
   • 金鑰存放區屬性
   • 信任存放區屬性
   • 如果適用，叢集和 ZooKeeper 安全性屬性

3. 在 中 $NIFI_HOME/conf/authorizers.xml設定驗證，通常是具有憑證式驗證的初始使用者或其他選項。

4. 選擇性地設定 NiFi 與任何 Proxy、負載平衡器或外部端點之間的 mTLS 和 Proxy 讀取原則。

如需完整的逐步解說，請參閱 Apache 項目檔中的使用 TLS 保護 NiFi。

憑證、金鑰和金鑰存放區

若要支援 TLS，請產生憑證、將它們儲存在 Java KeyStore 和 TrustStore 中，並將其散發到 NiFi 叢集。 憑證有兩個一般選項：

• 自我簽署憑證
• 認證授權單位 （CA） 簽署的憑證

使用 CA 簽署的憑證時，最好使用中繼 CA 來產生叢集中節點的憑證。

KeyStore 和 TrustStore 是 Java 平臺中的密鑰和憑證容器。 KeyStore 會將節點的私鑰和憑證儲存在叢集中。 TrustStore 會儲存下列其中一種類型的憑證：

• KeyStore 中自我簽署憑證的所有受信任憑證
• CA 中的憑證，適用於 KeyStore 中 CA 簽署的憑證

當您選擇容器時，請記住 NiFi 叢集的延展性。 例如，您可能想要在未來增加或減少叢集中的節點數目。 在該案例中，請選擇 KeyStore 中的 CA 簽署憑證，以及來自 TrustStore 中 CA 的一或多個憑證。 使用此選項時，不需要在叢集的現有節點中更新現有的 TrustStore。 現有的 TrustStore 信任並接受來自這些節點類型的憑證：

• 您新增至叢集的節點
• 取代叢集中其他節點的節點

NiFi 組態

若要啟用適用於 NiFi 的 TLS，請使用 $NIFI_HOME/conf/nifi.properties 來設定此表格中的屬性。 請確定下列屬性包含您用來存取 NiFi 的主機名稱：

• nifi.web.https.host 或 nifi.web.proxy.host
• 主機憑證的指定名稱或主體別名

否則，主機名驗證失敗或 HTTP HOST 標頭驗證失敗可能會導致拒絕您存取。

屬性名稱	描述	範例值
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） 的任何主機名。 此清單也可以包含負載平衡器、Proxy 或 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 管理員 istrator 指南。 只有 3.5.5 版或更新版本支援此功能。

NiFi 會使用 ZooKeeper 進行零領導者叢集和叢集協調。 從 1.13.0 版開始，NiFi 支援安全用戶端存取已啟用 TLS 的 ZooKeeper 實例。 ZooKeeper 會以純文本儲存叢集成員資格和叢集範圍的處理器狀態。 因此，請務必使用安全的用戶端存取 ZooKeeper 來驗證 ZooKeeper 用戶端要求。 同時加密傳輸中的敏感性值。

若要啟用 Tls for NiFi 用戶端對 ZooKeeper 的存取，請在 中 $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 管理員 istration 指南。

身分識別與存取控制

在 NiFi 中，身分識別和訪問控制是透過使用者驗證和授權來達成。 針對使用者驗證，NiFi 有多個選項可供選擇：單一使用者、LDAP、Kerberos、安全性判斷提示標記語言 （SAML），以及 OpenID 連線 （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 管理員 istration 指南。

以檔案和 Apache Ranger 為基礎的 AccessPolicyProviders 目前可用於管理和儲存使用者和組策略。 如需詳細資訊，請參閱 Apache NiFi 檔和Apache Ranger 檔。

應用程式閘道

應用程式閘道提供 NiFi 介面的受控第 7 層負載平衡器。 將應用程式閘道設定為使用 NiFi 節點的虛擬機擴展集作為其後端集區。

針對大部分的 NiFi 安裝，我們建議使用下列 應用程式閘道 組態：

• 階層：標準
• SKU 大小：中型
• 實例計數：兩個或多個

使用健康情況 探查 來監視每個節點上Web伺服器的健全狀況。 從負載平衡器輪替中移除狀況不良的節點。 當整體叢集狀況不良時，此方法可讓您更輕鬆地檢視使用者介面。 瀏覽器只會將您導向至目前狀況良好且回應要求的節點。

需要考慮兩個關鍵的健康情況探查。 它們會在叢集中每個節點的整體健康情況上提供一般活動訊號。 設定第一個健康情況探查以指向路徑 /NiFi。 此探查會決定每個節點上 NiFi 使用者介面的健康情況。 設定路徑 /nifi-api/controller/cluster的第二個健康情況探查。 此探查指出每個節點目前是否狀況良好且已加入整體叢集。

您有兩個選項可用來設定應用程式閘道的前端 IP 位址：

• 使用公用IP位址
• 使用私人子網IP位址

只有在使用者需要透過公用因特網存取 UI 時，才包含公用 IP 位址。 如果不需要使用者的公用因特網存取，請從虛擬網路中的 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

若要提高可用性，請在與 NiFi 叢集中的 VM 分開部署 ZooKeeper 叢集。 如需設定 ZooKeeper 的詳細資訊，請參閱 Apache NiFi 系統 管理員 istrator 指南中的狀態管理。

可用性區域

在跨區域組態中部署 NiFi 虛擬機擴展集和 ZooKeeper 叢集，以將可用性最大化。 當叢集中節點之間的通訊跨越可用性區域時，它會產生少量的延遲。 但此延遲通常會對叢集的輸送量產生最小整體影響。

虛擬機器擴展集

我們建議將 NiFi 節點部署到跨越可用可用性區域的單一虛擬機擴展集。 如需以這種方式使用擴展集的詳細資訊，請參閱建立使用 可用性區域的虛擬機擴展集。

監視

有多個選項可用來監視 NiFi 叢集的健康情況和效能：

• 報告工作。
• MonitoFi 是個別的 Microsoft 開發應用程式。 MonitoFi 會在外部執行，並使用 NiFi API 監視叢集。

報告以工作為基礎的監視

若要監視，您可以使用您在 NiFi 中設定和執行的報告工作。 當 診斷和健康情況監視 討論時，Log Analytics 會在 NiFi Azure 套件組合中提供報告工作。 您可以使用該報告工作來整合監視與 Log Analytics 和現有的監視或記錄系統。

Log Analytics 查詢

下列各節中的範例查詢可協助您開始使用。 如需如何查詢 Log Analytics 數據的概觀，請參閱 Azure 監視器記錄查詢。

監視器和 Log Analytics 中的記錄查詢會使用 Kusto 查詢語言的版本。 但記錄查詢與 Kusto 查詢之間存在差異。 如需詳細資訊，請參閱 Kusto 查詢概觀。

如需更結構化的學習，請參閱下列教學課程：

• 開始使用 Azure 監視器中的查詢
• 開始使用 Azure 監視器中的 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

該查詢會產生類似下列結果的結果：

基礎結構記錄設定

您可以使用監視器來監視和管理 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

該查詢會產生類似此螢幕快照中的報表：

警示

使用監視器來建立 NiFi 叢集健康情況和效能的警示。 範例警示包括：

• 佇列計數總計已超過閾值。
• 此值 BytesWritten 低於預期的臨界值。
• 此值 FlowFilesReceived 在臨界值下。
• 叢集狀況不良。

如需在監視器中設定警示的詳細資訊，請參閱 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 系統 管理員 istrator 指南和 ZooKeeper 管理員 istrator 指南。

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	將 REST API 呼叫等 HTTP 呼叫複寫至其他叢集節點時要使用的平行處理原則層級。	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 分鐘

叢集行為

當您設定叢集時，請記住下列幾點。

Timeout

若要確保叢集及其節點的整體健康情況，增加逾時可能會很有説明。 這種做法有助於保證失敗不會因為暫時性網路問題或高負載而造成。

在分散式系統中，個別系統的效能會有所不同。 此變化包括網路通訊和延遲，這通常會影響節點間、叢集間通訊。 網路基礎結構或系統本身可能會導致這種變化。 因此，變化的機率很可能在大型系統中。 在載入的 Java 應用程式中，Java 虛擬機 （JVM） 中的垃圾收集 （GC） 暫停也可能會影響要求回應時間。

使用下列各節中的屬性來設定逾時以符合系統需求：

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

屬性 nifi.cluster.node.connection.timeout 會指定開啟連接時要等候的時間長度。 屬性 nifi.cluster.node.read.timeout 會指定在要求之間接收數據時要等候的時間長度。 每個屬性的預設值為五秒。 這些屬性適用於節點對節點要求。 增加這些值有助於緩解數個相關問題：

• 叢集協調器因為活動訊號中斷而中斷連線
• 加入叢集時無法從協調器取得流程
• 建立站對站 （S2S） 和負載平衡通訊

除非您的叢集具有非常小型的擴展集，例如三個節點或更少，否則請使用大於預設值的值。

nifi.cluster.protocol.heartbeat.interval

作為 NiFi 叢集策略的一部分，每個節點都會發出活動訊號來傳達其狀況良好狀態。 根據預設，節點會每隔五秒傳送活動訊號。 如果叢集協調器偵測到節點的數據列中有 8 個活動訊號失敗，則會中斷節點的連線。 增加 屬性中 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 為五分鐘。 將候選項目數目上限設定為非空白值，例如 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）。 G1GC已改善 ParallelGC 的效能，因為 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在其處理中使用記憶體的方式

如需詳細檔，請參閱 深入 Apache NiFi。

請只視需要將堆積設為符合處理需求。 此方法會將 GC 暫停的長度降至最低。 如需 Java 垃圾收集的一般考慮，請參閱 Java 版本的垃圾收集微調指南。

調整 JVM 記憶體設定時，請考慮下列重要因素：

• 在指定期間作用中的 FlowFiles 或 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。	值的 1/4 ParallelGCThreads	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 管理員 istrator 指南中的叢集設定（多伺服器）。

除了叢集設定之外，請使用 ZooKeeper 組態的預設值。

如果您有大型 NiFi 叢集，您可能需要使用較多的 ZooKeeper 伺服器。 對於較小的叢集大小，較小的 VM 大小和標準 SSD 受控磁碟就已足夠。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

• Muazma Zahid |主要 PM 管理員

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

本檔中的材料和建議來自數個來源：

• 測試
• Azure 最佳做法
• NiFi 社群知識、最佳做法和檔

如需詳細資訊，請參閱以下資源：

• Apache NiFi 系統 管理員 istrator 指南
• Apache NiFi 郵件清單
• 設定高效能 NiFi 安裝的 Cloudera 最佳做法
• Azure 進階儲存體：專為高效能而設計
• 針對Linux或 Windows 上的 Azure 虛擬機效能進行疑難解答

相關資源

• 使用MonitoFi進行Apache NiFi監視
• Apache NiFi 的 Helm 型部署
• Azure 數據總管監視
• [搭配 Azure Data Factory 的混合式 ETL][搭配 Azure Data Factory 的混合式 ETL]
• [新式數據倉儲的 DataOps][新式數據倉儲的 DataOps]
• 資料倉儲和分析