Day3 Pipeline 如何做版本控制 - NiFi Registry

前面已经大概介绍了一下 NiFi 的用途还有特性，那今天就来讲在 NiFi 中，其实是可以对一组 Data Pipieline 来做一个『版本控制』，就类似於 git 一样，git 可以将每次修改好的版本 commit 出去且 push 到 Github 或 Gitlab 平台上对应的 respository。那 NiFi 是如何做到的呢？答案是今天的主角 - NiFi Registry。

为什麽要版本控制？

在开始讲 NiFi Registry 之前，先来简单探讨一下为什麽 NiFi 需要做版本控制？原因有几点:

1. 假如是一个 team，在前一篇有提到很多时候会透过 Process Group 来作为分 team 的依据，而底下会有很多隶属於该 team 的 project，若太多 members 在上面做修改的话，会导致 Pipiline 变得一团糟，所以就可以透过版控的方式来确定稳定且最新的版本，好让 members 在每次修改或开发 project 时是一致的版本。
2. 搭配 Staging 和 Production 的环境来做 CI/CD，很多时候我们会到一定的版本时就会 deploy 到 Staging 或 Production 做测试及应用，这时候版控也可以让我们清楚知道目前环境的版本，同时也使我们容易整合 CI/CD 的来做到deployment。

NiFi Registry

NiFi Registry 是一个额外独立的服务，他同时也是 NiFi 的 sub-project。其中他有几个地方需要留意：

1. 是一个独立 Service, 最小版控单位是 Processor Group

NiFi Registry Sturcture

首先先看我设计的架构图:

从图上我们可以看到在 NiFi Registry 建立於 Bucket，而Bucket底下可以有很多 Flow(也就是 Processor Group 为单位)，再针对 Flow 来做版控。

这样讲可能读者们还是有点不清楚，没关系，我们来套用一个常见的例子:
举例来说，现在有一间公司有两个部门会用到 NiFi 来做 Data Pipeline，此时我们可以在 NiFi Registry 建立两个 Bucket，用来个别隶属於两个部门，而每个部门底下有自己的Data Pipeline Project，就可以在 Bucket 底下针对每一个 Project(也就是 Flow) 来做版本控制了。

当然读者们也可以依据自己所属的环境与场景来做对应的拆分，所以 Bucket 和 Flow 也就会有不同的意涵，这边我就提一个常用的案例来让大家理解。

为什麽是 Processor Group?

为什麽必须要以 Processor Group 为单位呢？其实不难想像，Processor Group 除了做 Module 之外，同时也作为分 Team 和分 Project 为使用，所以底下就会由一连串的 Processors 所组合而成的。所以以这个作为版控单位，才能将完整的 Data Pipeline 去做到一个控管。

还有一点是如果站在 Module 去思考，正常来说我们再引用 Module 时本来就会指定好我们可以使用的版本，所以从这个角度去想确实采用 Processor Group 作为版控单位是比较合理的选择。

2. 与 NiFi 搭配的架构

NiFi Registry 在与 Nifi 搭配应用的架构，主要会分成两种：

one Registry to rule them all

这个架构是 Dev, Staging 和 Production 共用同一个 NiFi Registry，虽然维护成本比较少，因为只要维护一台 NiFi Registry，但其实依据我使用的经验，这个架构其实不太好:

1. NiFi Registry 没有 tag 或 branch 的概念，所以今天在 NiFi Registry 代管版本时，会无法确定到目前的版本该以谁为主，以至於管理会变得很复杂。
2. 有时候我们在 Dev 交付的版本不一定就要上 Staging 或 Production，所以在此架构上也会容易造成环境之间的模糊地带。

one Registry per environment

这个架构是 Dev, Staging 和 Production 个别维运 NiFi Registry，接着透过 nifi-toolkit 或 NiPyAPI 来做 Registry 之间的同步。我觉得这个架构是比较好的:

1. 各自环境各自作版控，环境上的切分也比较乾净。
2. 使用者可以指定『需要』上 Staging 或 Production 的版本即可，而不用全部在 Dev 的版本都去做 synch。
3. 需要额外透过 api 的方式来做 synch，架构实作上会稍微复杂一点。
4. 但维护成本就会高一点，因为会多两个服务去维运。

个人还是建议采用第二种架构，好好地将环境切割清楚，只 synch 需要 synch 的版本，这样一方面可读性好，另一方面假设有问题时也比较好去追踪。

小总结

今天提完了这个 NiFi Registry 的用途，以及如何搭配 NiFi 的架构，明天我就会让读者们可以在自己的机器或笔电上启动这两个服务，接下来的文章都会以 1个 NiFi 搭配 1个 NiFi Registry 去做介绍，想要更复杂一点的，未来我会再提供一些资源给各位。

Reference

• Automate workflow deployment in Apache NiFi with the NiFi Registry