Apache NIFI入門(讀完即入門)
編輯人(全網同名)：酷酷的誠 郵箱：[email protected]
我將在本文中介紹：
- 什麼是ApacheNIFI，應在什麼情況下使用它，理解在NIFI中的關鍵概念。
我不會介紹的內容：
-NIFI集羣的安裝，部署，監視，安全性和管理。
什麼是ApacheNIFI？
在ApacheNIFI項目的官網上，可以找到以下定義：
一個易於使用，功能強大且可靠處理和分發數據的系統。
接下來我們分析一下關鍵字。
NIFI定義
處理和分發數據
這是NIFI的要旨。它可以在系統中移動數據，併爲你提供處理該數據的工具。
NIFI可以處理各種各樣的數據源和不同格式的數據。你可以從一個源中獲取數據，對其進行轉換，然後將其推送到另一個目標存儲地。
易於使用
Processors-boxes-通過連接器鏈接-箭頭創建流程。NIFI提供了一個基於流的編程體驗。
NIFI讓我們一眼就能理解一組數據流操作，而這或許將需要數百行源代碼來實現。
考慮下面的pipeline：
如果要在NIFI中實現轉換上述的數據流，只需在NIFI圖形用戶界面，將三個組件拖放到畫布中，然後連接做配置。也就需要個兩分鐘。
而如果你編寫代碼來執行相同的操作，則可能需要數百行才能達到相似的結果。
NIFI在構建數據pipeline方面更具表現力，我們不需要寫代碼，而NIFI就是爲此而設計的。
強大
NIFI提供了許多開箱即用的處理器。使用者其實是站在巨人的肩膀上。這些標準處理器可以處理你可能遇到的絕大多數需求。
NIFI是高度併發的，但其內部封裝了相關的複雜性。我們看到的處理器是一個高級抽象，它掩蓋了並行編程固有的複雜性。我們可以多個處理器一起運行，一個處理器也可以有多個線程運行。
併發是你不希望打開的計算型Pandora盒。NIFI使得pipeline構建器免受併發複雜性的影響。
可靠
NIFI的設計實現具有紮實的理論基礎。與SEDA之類的模型相似(SEDA全稱是：stage event driver architecture，中文直譯爲“分階段的事件驅動架構”，它旨在結合事件驅動和多線程模式兩者的優點，從而做到易擴展，解耦合，高併發。各個stage之間的通信由event來傳遞，event的處理由stage的線程池異步處理。)。
對於數據流系統，要解決的主要問題之一就是可靠性。你想確保發送到某處的數據得到了有效接收。
NIFI通過多種機制在任何時間點跟蹤系統狀態，從而實現了高度的可靠性。這些機制是可配置的，因此你可以在延遲和應用程序所需的吞吐量之間進行適當的權衡。
NIFI利用lineage和provenance特徵來跟蹤每條數據的歷史記錄。它使得知道每條信息發生了什麼轉變。
Apache NIFI提出的數據血緣解決方案被證明是審覈數據pipeline的出色工具。在諸如歐盟這樣的跨國參與者提出支持準確數據處理的準則的背景下，數據血緣功能對於增強人們對大數據和AI系統的信心至關重要。
爲什麼要使用NIFI？
在確定解決方案時，請記住大數據的四個特點。
- Volume — 你有多少數據？在數量級上，你接近幾GB還是幾百個PB？
- Variety — 你有多少個數據源？你的數據是否結構化？如果是，結構是否經常變化？
- Velocity — 你需要處理的頻率是多少？是信用卡付款嗎？它是物聯網設備發送的每日性能報告嗎？
- Veracity — 你可以信任數據嗎？另外，在操作之前是否需要進行多次清潔操作？
NIFI無縫地從多個數據源提取數據，並提供了處理數據中不同模式的機制。因此，當數據種類繁多時，它就非常適用了。
如果數據準確性不高，則NIFI尤其有價值。NIFI提供了多個處理器來清理和格式化數據。
通過其配置選項，NIFI可以解決各種 volume/velocity 場景問題。
數據路由解決方案的應用程序列表越來越多
物聯網的興起及其生成的數據流都強調了諸如Apache NIFI之類的工具的重要性。
- 微服務是新潮。在那些鬆耦合的服務中，數據是服務之間的契約。NIFI是在這些服務之間路由數據的可靠方法。
- 物聯網將大量數據帶到雲中。對從邊緣到雲的數據的採集和驗證帶來了許多新挑戰，NIFI可以有效應對這些挑戰（主要是通過MiNIFI，針對邊緣設備的NIFI項目）
- 制定了新的準則和法規以重新調整大數據經濟。在日益增加的監視範圍內，對於企業來說，至關重要的是清楚地瞭解其數據pipeline。例如，NIFI數據血緣可能會有助於你遵守法規。
彌合大數據專家與其他專家之間的鴻溝
從用戶界面可以看到，用NIFI表示的數據流非常適合與你的數據pipeline進行通信。它可以幫助你的組織成員更加了解數據pipeline中發生的事情。
- 分析師正在尋求有關爲什麼這些數據以這種方式到達此處的見解？坐在一起，並在流程中漫步。在五分鐘內，你將對提取轉換和加載-ETL-pipeline有深入的瞭解。
- 你是否需要同行的反饋，以幫助你創建新的錯誤處理流程？NIFI決定將錯誤路徑視爲有效結果，這是一項設計決策。期望流程審查比傳統的代碼審查要短。
你應該使用它嗎？或許吧
NIFI本身就易於使用。儘管如此，它還是一個企業數據流平臺。它提供了一套完整的功能，你可能只需要其中的一部分即可。
如果你是從頭開始並管理來自受信任數據源的一些數據，那麼最好設置ETL pipeline。你可能只需要從數據庫中捕獲更改數據和一些數據準備腳本即可。
另一方面，如果你在使用現有大數據解決方案（用於存儲，處理或消息傳遞）的環境中工作，則NIFI可以很好地與它們集成，並且很可能會很快獲勝。你可以利用現成的連接器連接其他大數據解決方案。
既然我們已經看到了Apache NIFI的優點，現在我們來看看它的關鍵概念並剖析其內部結構。
我們已經理解了“NiFi is boxes and arrow programming”。但是，如果你必須使用NIFI，則可能需要更多地瞭解其工作原理。
在第二部分中，我將說明Apache NIFI的關鍵概念。
剖析Apache NIFI
啓動NIFI時，你會進入其Web界面。 Web UI是設計和控制數據pipeline的藍圖。
在NIFI中，處理器通過connections連接在一起。在前面介紹的示例數據流中，有三個處理器。
理解NIFI術語
要使用NIFI表示數據流，你必須首先掌握其語言。不用擔心，只需幾個術語就足以掌握其背後的概念。
那些一個個黑匣子稱爲處理器，它們通過稱爲connections的隊列交換名爲FlowFiles的信息塊。最後，FlowFile Controller負責管理這些組件之間的資源。
讓我們看看它是如何工作的。
FlowFile
在NIFI中，FlowFile是在pipeline處理器中移動的信息包。
FlowFile分爲兩個部分：
- Attributes，即鍵/值對。例如，文件名，文件路徑和唯一標識符是標準屬性。
- Content，對字節流的引用構成了FlowFile內容。
FlowFile不包含數據本身，否則會嚴重限制pipeline的吞吐量。相反，FlowFile保留的是一個指針，該指針引用存儲在本地存儲中某個位置的數據。這個地方稱爲內容存儲庫(Content Repository)。
爲了訪問內容，FlowFile從內容存儲庫中聲明資源(claims),然後將跟蹤內容所在位置的確切磁盤偏移，並將其返回FlowFile。
並非所有處理器都需要訪問FlowFile的內容來執行其操作-例如，聚合兩個FlowFiles的內容不需要將其內容加載到內存中。
當處理器修改FlowFile的內容時，將保留先前的數據。NIFI的copies-on-write機制會在將內容複製到新位置時對其進行修改。原始信息保留在內容存儲庫中。
Example
比如一個壓縮FlowFile內容的處理器。原始內容會保留在內容存儲庫中，NIFI併爲壓縮內容創建一個新條目。
內容存儲庫最終將返回對壓縮內容的引用。 FlowFile裏指向內容的指針被更新爲指向壓縮數據。
下圖總結了帶有壓縮FlowFiles內容的處理器的示例。
Reliability
NIFI聲稱是可靠的，實際上如何？當前使用的所有FlowFiles的屬性以及對其內容的引用都存儲在FlowFile Repository中。
在pipeline的每個步驟中，在對流文件進行修改之前，首先將其以預寫日誌的方式(write-ahead log)記錄在FlowFile Repository中。
對於系統中當前存在的每個FlowFile，FlowFile Repository存儲：
- FlowFile屬性
- 指向FlowFile內容的指針
- FlowFile的狀態。例如：Flowfile在此瞬間屬於哪個隊列。
FlowFile Repository爲我們提供了流程的最新狀態；因此，它是從中斷中恢復的強大工具。
NIFI提供了另一個工具來跟蹤流程中所有FlowFiles的完整歷史記錄：Provenance Repository。
Reliability
NIFI聲稱是可靠的，實際上如何？當前使用的所有FlowFiles的屬性以及對其內容的引用都存儲在FlowFile Repository中。
在pipeline的每個步驟中，在對流文件進行修改之前，首先將其以預寫日誌的方式(write-ahead log)記錄在FlowFile Repository中。
對於系統中當前存在的每個FlowFile，FlowFile Repository存儲：
- FlowFile屬性
- 指向FlowFile內容的指針
- FlowFile的狀態。例如：Flowfile在此瞬間屬於哪個隊列。
FlowFile Repository爲我們提供了流程的最新狀態；因此，它是從中斷中恢復的強大工具。
NIFI提供了另一個工具來跟蹤流程中所有FlowFiles的完整歷史記錄：Provenance Repository。
Provenance Repository
每次修改FlowFile時，NIFI都會獲取FlowFile及其上下文的快照。NIFI中此快照的名稱是Provenance Event。Provenance Repository記錄Provenance Events。
Provenance使我們能夠追溯數據血緣關係併爲在NIFI中處理的每條信息建立完整的監管鏈。
除了提供完整的數據血緣之外，Provenance Repository還提供從任何時間點重播數據的功能。
等等，FlowFile Repository和Provenance Repository有什麼區別？
FlowFile Repository和Provenance Repository背後的想法非常相似，但是它們解決的是不同的問題。
FlowFile Repository是一個日誌，僅包含系統中正在使用的FlowFiles的最新狀態。這是flow的最新情況，可以快速從中斷中恢復。Provenance Repository更爲詳盡，因爲它可以跟蹤流中每個FlowFile的完整生命週期。
可以這麼理解，FlowFile Repository裏面保存的是你此時某個動作的照片，Provenance Repository保存的是你這個動作的視頻。你可以倒退到過去的任何時刻，研究數據，並從給定的時間重放操作。它提供了數據的完整血緣關係。
Processor
處理器是執行操作的黑匣子。處理器可以訪問FlowFile的屬性和內容來執行所有類型的操作。它們使你能夠在數據輸入，標準數據轉換/驗證任務中執行許多操作，並將這些數據保存到各種數據接收器。
NIFI在安裝時會附帶許多處理器。如果你找不到適合自己的用例的處理器，可以構建自己的處理器。
處理器是完成一項任務的高級抽象。這種抽象非常方便，因爲它使pipeline的構建免受併發編程和錯誤處理機制的困擾。
處理器提供了多個配置設置的界面以微調其行爲。
這些處理器的屬性是NIFI與你的應用程序需求之間的最後聯繫。細節很重要，所以pipeline建設者會花費大部分時間來微調這些屬性以匹配預期的行爲。
Scaling
對於每個處理器，你可以指定要同時運行的併發任務數。這樣，流控制器將更多資源分配給該處理器，從而提高其吞吐量。處理器共享線程。如果一個處理器請求更多的線程，則其他處理器的可用線程就會少了。
橫向擴展：擴展的另一種方法是增加NIFI羣集中的節點數。
Process Group
現在，我們已經瞭解了什麼是處理器，這很簡單。
一堆處理器及其連接可以組成一個Process Group。你添加了一個Input Port和一個Output Port，以便Process Group可以接收和發送數據。
Connections
Connections是處理器之間的隊列。這些隊列允許處理器以不同的速率進行交互。就像存在不同尺寸的水管Connections可以具有不同的容量。
由於處理器根據它們執行的操作以不同的速率消耗和產生數據，因此Connections充當FlowFiles的緩衝區。
Connections中可以有多少數據是有限制的。同樣，當水管已滿時，你將無法再加水，否則水會溢出。
在NIFI中，你可以限制FlowFile的數量及其通過Connections的聚合內容的大小。
當你發送的數據超出Connections的處理能力會發生什麼？
如果FlowFiles的數量或數據量超過定義的閾值，則將觸發背壓機制(backpressure)。在隊列中沒有空間之前，Flow Controller不會安排Connections上游的處理器再次運行。
假設你在兩個處理器之間最多只能有10000個FlowFile。在某個時候，連接中有7000個元素。因爲限制爲10000。P1仍然可以通過Connections發送數據到P2。
現在，假設處理器一下子向該Connections發送了4000個新的FlowFiles。
7000 + 4000 = 11000→我們超過了10000個FlowFiles的連接閾值。
這個限制是軟限制，表示可以超出限制，但是Flow Controller不會調度處理器P1，直到Connections恢復到其閾值（10000個FlowFiles）以下。
你想要設置適合於要處理的數據量和速度的Connections閾值，要始終考慮四個V(大數據的四個特點)。
超出限制的想法聽起來很奇怪,當FlowFiles或關聯數據的數量超過閾值時，將觸發交換機制(swap mechanism)。
優先處理FlowFiles
NIFI中的Connections是高度可配置的。你可以選擇如何在隊列中確定FlowFiles的優先級，以確定接下來要處理的文件。
在可用的配置中，例如，先進先出-FIFO。但是，你甚至可以通過FlowFile中的屬性來優先處理傳入數據包。
Flow Controller
Flow Controller是將一切融合在一起的粘合劑。它爲處理器分配和管理線程。這就是執行數據流的方式。
此外，Flow Controller還可以添加Controller Services。
這些服務有助於管理共享資源，例如數據庫連接或雲服務提供商憑據。Controller Services是守護進程(daemons)。它們在後臺運行，並提供配置，資源和參數供處理器執行。
例如，你可以使用AWS憑證提供程序服務使你的服務與S3存儲桶進行交互，而不必擔心處理器級別的憑證。
與處理器一樣，開箱即用的控制器服務也很多。
總結
如果你詳細的閱讀了這篇文章每一行內容，那麼我相信，你已經是一個合格的NIFI設計者了，接下來你只需要考慮你的需求需要用到哪些組件，去配置那些組件就OK了。
公衆號
關注公衆號 得到第一手文章/文檔更新推送。
