今天要介紹的是 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