Day22 NiFi - 与 GCP PubSub 对接设定

今天要介绍的是 NiFi 如何与 GCP PubSub 的服务对接与设定，很多在 Streaming 的场景，我们都需要透过 Message Queue 来作为 Buffer 或是暂时储存的地方，藉此透过非同步的讯息传递，此外也可根据不同用途来订定 message topic，来利於後续的服务能够稳定的取得资料且操作，而 GCP PubSub 就是一种 Message Queue 的系统。

What is the GCP PubSub?

对於 Message Queue 的系统想必大家都不陌生，其中的架构会分成 Publisher, Subscriber, topic 这几个，最常见的服务有像是 Apache Kafka, Apache Pulsar 或是 AWS Kinesis 等，而在 GCP 这个云端平台上所代表的就是 PubSub 这个服务。

这边带大家来看一下 GCP PubSub 的流程架构：

1. Publisher 会先在 PubSub 建立 topic，并将对应的 message 传递进去。
2. 当 topic 内的 message 没有被接受时，会先被储存於 storage 内 (预设保留7天)。
3. 而 Subscriber 会去注册 Subscription，而其会接收对应 topic 内的 message 就会被送到对应的 Subscriber 做处理。
4. Subscriber 接受到讯息时，会向 PubSub 来发送 ACK。
5. PubSub 接收到 ACK 时，则会把对应的 message 从 storage 做删除。

所以在这样的架构下，我们可想像 NiFi 在整合 PubSub 的时候，依据各个场景他有可能是 Publisher 或是 Subscriber 这两个身份，因此 NiFi 就有提供两个对应的 Processor，分别是 PublishGCPubSub 和 ConsumeGCPubSub。

How to use?

这两个 Processor 的操作设定相对简单，其实都与先前的 GCP 相关的 Processor 都大同小异，我们来看一下：

PublishGCPubSub

• Project ID: GCP 的 Project ID。
• GCP Credentials Provider Service: 选择事先建立好的 GCP Controller Service。
• Topic Name: 指定要 publish message 的 topic name。
• Batch Size: 一次 publish message 的笔数，预设为 15 笔。

ConsumeGCPubSub

• Project ID: GCP 的 Project ID。
• GCP Credentials Provider Service: 选择事先建立好的 GCP Controller Service。
• Subscription: 指定要 publish message 的 subscription name。
• Batch Size: 一次 pull message 的笔数，预设为 15 笔。

相比先前的 GCP 相关的 Processor 的设定，有没有发现 PubSub 的 Processor 来得更容易呢？只要指定好 topic 和 subscription name，就可以轻松地将 FlowFiles 传送到 PubSub，或是从 PubSub 取得 message 转而成 FlowFiles。

小总结

目前已经介绍完 GCP PubSub 的 Processors，也就代表着目前 NiFi 所支援的 GCP 相关 Processors 也都告一个段落了。

我们已经介绍完 AWS, GCP 的服务该如何与 NiFi 设定与整合，明天开始会花个几篇的时间介绍一些 NiFi 常用的延伸应用，这对於各位读者们在建立 Data Pipeline 的时候可做一个更完整的操作应用。

Reference

• 初探 Google Cloud Pub/Sub
• Apache NiFi Document