Day28 NiFi 案例分享 - Renault

今天这篇来分享一个我觉得在介绍 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 来做介绍，对於後续要导入的流程是十分重要的议题。

Flow Development

这边讲者有提到对於 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 和同步。

Flow Monitoring

除了有介绍 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 做进一步地浏览。

Reference

• Best practices and lessons learnt from Running Apache NiFi at Renault
• Best practices and lessons learnt from Running Apache NiFi at Renault on Youtube