今天這篇來分享一個我覺得在介紹 Apache NiFi 的時候很典型的一個企業案例 - Renault。在最後面的 Reference 我有列出一些關於他的 slide 和 youtube video，有興趣的讀者們可以在去閱讀瀏覽，這邊我就擷取我覺得是重點的地方給各位知道。
Renault 是一家法國的汽車製造商，它涵蓋了車子的中上下游零組件的製造，然而隨著科技的發展，也在近幾年有發展自己的一套 IoT 的系統，因此除了生產線之外，他們本身也有許多相關的資料來源需要做整合與分析。
其中他們的 IT Team 就是透過 Apache NiFi 來做到 多資料整合分析 (建立於 HDP 上)，除了對接內部已經落地的 datasource 之外，他們也有 API 來持續寄發資料的 NiFi 來做分析。此外，最讓我覺得受益良多的是他們的 Apache NiFi 開發流程與設計理念，因為在當時使用 Apache NiFi 的企業並不多，所以當他們分享出來時，其實對於 Apache NiFi 的操作有了一個很大的推進。
這邊會針對 Development Lifecycle 和 Monitoring 來做介紹，對於後續要導入的流程是十分重要的議題。
這邊講者有提到對於 Data Flow Development 的設計原則如同 Software Development 的設計原則，會先經過設計、coding、測試、Deploy、Monitoring、Evolve等動作，這裏講者也有分析對於 Programing language 以及 Apache NiFi 在設計要注意的原則與 Component。
像對於 Programing language 我們會注意 Algorithm, function, lib 等原則; 而 NiFi 就是要注意 Flowfiles, Processors等元件，這些 Componenet 的介紹在該系列文的前半部都有完整的說明，要複習的讀者都可以再回去複習。
這邊講者主要想要表達的是對於一個 Tool 的掌握，其實就是要從他的基礎和元件開始理解，至於設計理念等等都可以抽象成像我們在做程式開發會注意的事項，這些都可以套用到 Apache NiFi。
接著講者就有簡單說明一般在開發時要注意的原則，例如環境的拆分、透過 Processor Group 來作為 Project 或 Team 的拆分管理、以及其他在 NiFi 的 Flow 原則，然後這些都會帶來很大的好處，像是 performance 與管理的效益、版本控制與測試的效益等，所以若能將這些原則套用到我們在 NiFi 的操作原則上，一方面除了能讓我們設計出來的 Data Pipeline 簡潔清楚之外，對於安全性或是效能、管理上都能有很大的幫助。
接著講者有分享他們在內部如何做到 Organization 與專案管理，原則上都是透過 Processor Group 來做到階層式劃分，如果大家還記得的話，PG 除了能將重複的 Flow 包裝成類似於 lib 可以重複利用之外，同時也可以透過 PG 來做 Project 或是部門、Team 的劃分，這樣就做到互相獨立的效果，這邊就是要表達這樣的意思。
講者這邊也有分享他們是如何對 NiFi 做到 CI/CD，簡單來說他們採用的 Dev, Tests(Staging) 和 Production 都是相互獨立一座的 NiFi Cluster。並且每一座都有獨立的 NiFi Registry 來做 Flow 版控，這中間會透過 Jenkins 或是 NiFi CLI 來做到彼此環境的同步，接著他們會對於每個環境給予不同的權限設定，如此一來就能將環境做拆分，也能將已完成的 NiFi Flow 透過第三方的方式來做 Deploy 和同步。
除了有介紹 NiFi 的 Development Cycle 介紹之外，這邊講者也有介紹 Monitoring 的分享，有分成 Service Monitoring 和 Applications Monitoring:
Service Monitoring
這部分主要是針對 NiFi 本身的服務監控，像是 disk 用量、JVM 的使用狀況，用來觀察 NiFi 是否還正常運作的監控指標。可透過 Reporting tasks，或是對接 Ambari, Grafana 來做監控。
Application(Flow) Monitoring
這部分主要是用來監控 Flow 是否有正常順利執行等狀況，所以可能要是要看像是 FlowFiles、back pressure等指標，一樣可透過 Reporting Task 等方式來做呈現，或是當 Failed 時可以 alerting information。
上面這張簡報圖是講者用來介紹一些 NiFi UI 可以看的一些 Metrics，像是 Processor 或是 Data Provenance 等介面的重要之資訊。
這邊作者有再整理一些可用的 NiFi Service Monitoring 之方法，常見的像是透過 API 將資訊打到第三方服務，或是透過 ReportingTask 來做監控資料的整合與分析報表等多種方式，我們可以依照使用場景來選擇適當的方式來執行監控機制。
講者這邊有提到 Renault 是透過 Elasticsearch 作為 NiFi 的 Log 搜集系統，接著透過 Kibana 來作為分析報表工具，如果真的 Flow 產生問題時，再透過 API 將資訊送到 Message Queue，最後來做到 Alerting 的效果。
除了 Elasticsearch + kibana 的組合之外，以 HDP 為例其實是採用 Apache Druid + Apache Superset 來作為監控的平台，或是採用 MongoDB 等工具來實作，一樣是依據場景與需求來決定即可。
今天這篇的分享案例，其實我並沒有太說明這間企業的背景與行業，因為我自己也沒有很熟悉。所以我才只挑出他們的建置流程、以及一些建議的原則、還有監控的流程，這對於 Developer 的角色來說，這是十分重要的環節與細節，若想再更深入了解的讀者們，可以點選下面的 Reference 做進一步地瀏覽。
iThome鐵人賽
看影片追技術