Apache NiFi 2.0のリリースゴール概要
下記はNiFi 2.0のJIRAからの抜粋:
- セキュリティの向上や複雑さの軽減、新機能のための安定した基盤を提供するために、NiFi 2.0は主に技術的負債の削減に注力すべきです。
- 新機能の追加を排除するわけではありませんが、既存環境からのシンプルなアップグレードパスを確保しつつ、技術的負債の削減を優先するべきです。
ゴールの詳細
Primary Goals:
- Remove Java 8 support and require Java 11
- Remove deprecated components
- Remove deprecated component properties
- Remove components integrating with unmaintained services
- Remove compatibility classes and methods
- Remove flow.xml.gz in favor of flow.json.gz
- Remove duplicative features
- Upgrade internal Java API references
- Reorganize standard components
- Implement migration tools for upgrading flows
NiFi 2の主な変更点
新機能
- Python Integration
- Parameters
- JDK 21+
- JSON Flow Serialization
- Rules Engine for Development Assistance
- Run Process Group as Stateless
- ListenOTLP (monitoring with OpenTelemetry)
- Updated Graphical User Interface (GUI)
Deprecatedになる機能一覧
- Deprecate Lua and Ruby Script Engines
- Deprecate ECMAScript Script Engine
- Deprecate the Ambari Reporting Task
- Deprecate Kafka 1.x components and 2.0 components
- XML Templates
- Variables
1) Python Integration:NiFi 2.0でのPythonプロセッサーの利用例
NiFi 2.0では、Pythonによるカスタムプロセッサーの作成がサポートされるようになりました。
従来のNiFi 1.xではJavaでのプロセッサー開発が必要でしたが、新バージョンである2.0からはPythonプロセッサーも容易に作成・利用できるようになり、開発の柔軟性が大幅に向上しました。
ソースコード例:
下記画像はPythonプロセッサーのソースコード例です。
このコードでは入力データを処理するためのロジックをPythonで記述しています。
NiFiのプロセッサーとして機能するPythonスクリプトは、例えば自然言語処理(NLP)や機械学習モデルを適用する際に非常に有用です。
利用環境:
このPythonプロセッサーをNiFi 2.0で動作させるためには、以下の環境かライブラリーが必要です:
- Python 3.10+
- HuggingFace, NLP, SpaCY, PyTorch
これらのライブラリを使うことで、入力データに対する高度なテキスト解析や、事前学習モデルの推論処理などがNiFi内で可能になります。
NiFi 2.0での実行イメージ
以下は上記PythonプロセッサーがNiFi 2.0内でどのように実行されるかを示したイメージです。
プロセッサーとして設定されたPythonスクリプトが入力データを処理し、結果を出力するフローを構成しています。
NiFi 2.0でのPythonサポートの利点
このようにして、NiFi 2.0ではJava以外にもPythonを使用してプロセッサーを作成できるようになったため、いくつかメリットがあります:
• 開発の簡単さ:PythonはJavaに比べてシンプルな記述でデータ処理が可能なため、コーディング量が削減され、開発がより迅速に進むことが可能です。
• 豊富なライブラリ:NLPや機械学習に強いPythonのライブラリ(HuggingFace、SpaCy、PyTorchなど)を活用できるため、NiFi上で高度なデータ処理やモデル推論が可能になります。
• 既存システムとの統合:Pythonスクリプトを使うことで、既存のPythonシステムや機械学習パイプラインと容易に統合でき、データフローの一環として機能させることができます。
2) Parameters: Variables ⇒ Parameter
NiFi 2.0では、従来の「変数(Variables)」や「変数レジストリ」が廃止(Deprecated)され、代わりに「パラメータ(Parameter)」の使用が推奨されています。
変数からパラメータへ移行することで、機密値の管理が改善され、プロパティ設定の柔軟性やセキュリティ面でも大きな利点があります。
以下は、VariablesとParametersの違いや、パラメータコンテキストの詳細、パラメータへの移行の重要性について詳しく解説します。
Variables の課題と限界
NiFi 1.xでは、データフロー内で動的に値を使用するために変数(Variables)が活用されてきました。しかし、変数の使用にはいくつかの制限や課題が存在しました:
- Expression Language のサポート制限
NiFiで変数をプロパティに参照する際には、NiFiのExpression Languageが必要でした。これは、式の書き方が複雑になることがあり、特に初学者には学習コストが高い。 - セキュリティ上の制約
変数には機密情報を安全に保存する方法がなく、パスワードやAPIキーのような機密値を直接変数で扱うことにはリスクがありました。 - 一貫性と管理性の問題
変数はデータフロー全体で共通の値を設定するために使われますが、変更や管理が煩雑になりやすいのも課題でした。
これらの制約を解決するため、NiFiでは「パラメータコンテキスト(Parameter Context)」が導入され、NiFi 2.0では変数が完全に廃止されることとなりました。
パラメータコンテキストの活用とベストプラクティス
パラメータコンテキスト(Parameter Context)は、NiFiフロー全体で統一した設定を適用するためのコンテナとして機能します。
パラメータへの移行を行う際には、以下の点に留意すると効率的に活用できます:
- パラメータの分割:データフローのユースケースに応じてパラメータを複数のコンテキストに分割することが推奨されます。例えば、開発環境と本番環境で異なるパラメータ値が必要な場合、それぞれに別のパラメータコンテキストを作成することで、より適切な設定が可能になります。
- コンテキストの継承:NiFi 2.0では、パラメータコンテキスト間で継承関係を設定できるようになりました。これにより、同じパラメータを複数のユースケースで共有しながら、各ユースケース固有の値を上書きする構成が可能になります。たとえば、開発環境用と本番環境用のコンテキストを作成し、本番環境特有の設定のみを上位のコンテキストで上書きすることで、変更管理が容易になります。
パラメータコンテキストはしばらく前から存在し、過去数年間で改善されてきました。例えば、最近では外部ストア(HashiCorpやクラウドプロバイダーのVaultなど)からパラメータの値を取得する「Parameter Context Provider」の方法を追加しました。
変数からパラメータへの移行には時間をかけて考えたほうが良いと思います。
例えば複数のパラメータコンテキストにパラメータを分割し、複数のユースケースで同じパラメータを共有したい場合にコンテキスト間で継承を使用する適切なアプローチについて考えても良いです。
3) JDK 21+NiFi 2.0 は Java 21のみサポート
NiFi 2.0 はJava 21のみサポートする予定です。
同時に、Java 8 Support を外しました。
詳細はこちら:Jira Epic NIFI-10147
この変更はいくつか理由があります。
- Multiple important project dependencies have deprecated or removed support for Java 8.
- Jetty 10 requires Java 11 and Jetty 9 reached end of community support in May 2022
- OpenSAML 4 requires Java 11 and OpenSAML 3 reached end of life in May 2021
- Kafka 3 deprecated support for Java 8 in September 2021
- Spring 6 removed support for Java 8 and Java 11 in November 2022
ということで、新しいJDKにしていきましょう。
4) JSON Flow Serialization
NiFi 2.0になると、テンプレートはXMLからJSONになります。
XMLテンプレートは、NiFiのメモリ内および永続化されたフロー定義(flow.xml.gzおよびflow.json.gzファイル)に保存されていましたが、何千ものコンポーネントを持つ大規模なテンプレートが数十または数百ある最大のNiFiユーザーの間で多くの問題を引き起こしました。これらをすべて削除することで、NiFiの安定性が大幅に向上し、メモリ使用効率が改善されます。
テンプレートをお持ちの場合、これらのテンプレートをJSON定義としてエクスポートするか、NiFiレジストリでテンプレートバージョンを管理することをお勧めします。
バージョン管理、フロー定義の共有・再利用に関しては、NiFiとNiFiレジストリを組み合わせて使用するのが最善の方法です。
5) 開発効率を上げるためのRules Engine
Rules Engine はフロー開発者にベスト・プラクティスを提供し、コンポーネント設定関する推奨事項を提供します。
詳細情報は今後展開します。
6) Statelessの状態でプロセッサーグループを実行
NiFi Statelessを使用してプロセッサーグループを実行することができるようになります。
NiFi Statelessは、Apache NiFiの軽量版で、特定のデータフローをステートレス(状態を持たない)モードで実行するための機能です。通常のNiFiは、状態を保持するためのリポジトリを持ち、長期間にわたるデータフローの実行や複雑な状態管理を行うのに適しています。一方、NiFi Statelessは一時的なデータ処理やトランザクション処理に特化しています。
https://github.com/apache/nifi/blob/rel/nifi-1.15.0/nifi-stateless/nifi-stateless-assembly/README.md
NiFi Statelessはかなり前から存在していましたが、NiFi 2.0までは使いにくかったです。
NiFi 2.0ではプロセッサーグループレベルで有効にすることができます。これにより、データフローをトランザクションとして扱うべき重要なユースケース(例えば、CDCなど)でNiFiを使用出番が増えます。
7) Updated Graphical User Interface (GUI)
まとめ
- Python Integration
- Parameters
- JDK 21+
- JSON Flow Serialization
- Rules Engine for Development Assistance
- Run Process Group as Stateless
Apache NiFiコミュニティではv2.0 が既にリリースされています。
https://github.com/apache/nifi/tree/rel/nifi-2.0.0
とりあえず、Dockerでローカルに入れて、試すこともできます。