「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- NSA（アメリカ国家安全保障局）で開発されていたものが、
2014年にオープンソースソフトウェアとして公開された。
- 2015年7月にApacheのTopレベルプロジェクトになった。
- ツールの仕様としては、ETLツールに近い。
（GUIを使ってデータとプロセスを定義する。）
- しかし、ETLは本来、バッチ指向なので、イベント指向のEAIに近いと言える。
- システム間のデータフロー自動化を行うために構築された。
特徴 †
- もともと、Niagrafilesという名前だった。
（ナイアガラの滝のようにドーッと降りてくる大量の水を処理するという発想。）
- 3Vの中で多様性を重視している。
（カチッと整形されたデータではなくても様々なデータが処理可能）
関連プロジェクト †
Registry †
フロー定義を「as a code」として管理するサブ・プロジェクト
小さなフットプリントでデータフローを実行できるサブ・プロジェクト
Apache Atlas †
大量のデータがどこから来てどこに行くのか、コンプライアンスの観点で追跡するプロジェクト
ユースケース †
公式文書に、
SOA、APIベースのシステム結合、IoT、BigData?、あとはMicroServices?
(These include things like; Service Oriented Architecture [soa],
the rise of the API [api][api2], Internet of Things [iot], and Big Data [bigdata].)
と書かれている。
ツールの仕様としては、どちらにも適合する可能性がある。
バッチ指向なので適合しない可能性がある（性能検証などが必要）。
イベント指向なのでこちらのほうが適合し易い。
WebAPI †
Remote Process GroupでHTTPなどのEndpointを定義してS2Sが可能。
以下での利用が想定されている。
用語 †
FlowFile? †
ユーザデータ
Content †
扱うデータの本体（バイナリ形式）
Attirbutes †
- ユーザーデータに関連付けられたKeyValue?のメタ情報。
- 以下の、3つの主要な利点がある。
- Processor毎に独自のAttirbutesを持つ。
例えば、PutFile? Processorであれば、ディレクトリとファイル名の属性を持つ。
- 起源・出所など、データに関する非常に貴重なcontextを提供する。
- 属性に基づいてフロー内でFlowFile?のルーティングを決定できる。
- 共通の属性
| # | 属性名 | 説明 | 変更可否 |
| 1 | filename | ファイル名 | |
| 2 | path | ディレクトリ名 | |
| 3 | fileSize | ファイルのバイト数 | 不可 |
| 4 | uuid | 他のFlowFiles?とFlowFile?を区別する汎用一意識別子 | 不可 |
| 5 | entryDate | FlowFile?が作成された日時（UTC） | 不可 |
| 6 | lineageStartDate? | 先祖の連鎖の最古の日時（UTC） | 不可 |
- 属性の設定
- 属性を抽出するProcessorがある。
- 特定のデータフォーマットを理解し、
- FlowFile?のコンテンツから適切な情報を抽出し、
- その情報を保持する属性を作成し、
- データのルーティングや処理方法の決定を行う。
- ユーザー定義属性をするProcessorがある。
- フロー内の特定の場所にある各FlowFile?に
独自のユーザー定義属性を追加することも一般的。
- これには、UpdateAttribute? Processorを使用する。
- 属性を使用した分岐
- NiFi?の最も強力な機能の1つに、属性に基づいてFlowFiles?を分岐させる機能がある。
- これには、RouteOnAttribute? Processorに、Expression Languageの式を設定する。
- Processorは構成によって、一致と不一致のRelationshipを公開する。
- Expression Language/プロパティ値での利用
- 属性値の参照：${ tag and the closing }（${uudi}など）
次のケースでは、属性名を引用符で囲む必要がある。
・必要属性名が文字以外の文字で始まる場合
・または数字、文字、ピリオド、アンダースコア以外の文字が含まれている場合
Processor †
- データフローを記述したグラフ（DAG）におけるノード（節点・頂点）に相当する。
- 「FlowFileにどんな処理を施すか」を表す、最も重要なビルディングブロック。
- FlowFiles?の作成、送信、受信、変換、ルーティング、分割、マージ、および処理を担当する。
- 組込Processorに加え、カスタムProcessorを開発して組込むことも可能。
利用可能なProcessor †
- 色々なProcessorが用意されており、様々なシステムのデータを
する機能を提供する。
- なお、Webサービスを作成する場合は、
HandleHttpRequest?/HandleHttpResponse?
を使用することができる。
Processorのタイプ †
以下は、Processorのタイプ。
具体的なProcessorは下記「参考」のURLを参照。
- 接続
- Routing and Mediation（分岐と速度調整）
- Splitting and Aggregation（分割・集約）
- データの配信
Data Egress / Sending Data
- 取込・配信
- System Interaction（OSコマンドの実行）
- Database Access（SQLの実行）
- HTTP（HTTSクライアント or サーバの実行）
- Amazon Web Services（サービスへのI/Oの実行）
Connection †
データフローを記述したグラフ（DAG）におけるエッジ（枝・辺）の属性に相当する。
Relationship †
- RouteOnAttribute? Processorに、Expression Languageの式を設定すると公開される。
アーキテクチャ †
ホストOS上のJVM内で実行される。
引用：nifi.apache.org/docs/nifi-docs/html/images/zero-master-node.png
主要コンポーネント †
以下は、JVM上の主なコンポーネント。
Web Server †
HTTPベースのコマンドと制御APIをホストする。
Flow Controller †
操作の頭脳
Extensions †
- 様々なタイプの拡張がある。
- JVM内で動作して実行される。
- 現在アクティブなFlowFileの状態を追跡する場所。
- リポジトリの実装はプラガブル。
Content Repository †
- FlowFileの実際のコンテンツバイトが存在する場所。
- リポジトリの実装はプラガブル。
- ファイルシステムにデータのブロックを格納する。
- デフォルトの場所は・・・
- 複数のファイルシステム格納場所を指定するできる。
Provenance Repository †
- すべてのProvenance イベント・データが格納される場所。
- リポジトリの構成はプラガブル。
- デフォルトの構成では、1つ以上の物理ディスク・ボリュームを使用
- 各ロケーション内でイベントデータが索引付けされ、検索可能。
クラスタリング †
- 1.0以降、Apache ZooKeeper?のクラスタ内で動作できる。
- 各ノードは、データに対して同じタスクを実行する。
- しかし、それぞれ異なるデータセットで動作する。
ZooKeeper? †
- コーディネータとして単一のノードを選択
- プライマリノードとして単一のノードを選択
コーディネータ †
- フェイルオーバーはZooKeeper?によって自動的に処理される。
- すべてのノードは、ハートビートとステータス情報をコーディネータに報告。
- コーディネータはノードの切断と接続を行う。
プライマリノード †
- DataFlow?マネージャとして、UIを介してクラスタとやりとりできる。
- 変更は、クラスタ内のすべてのノードに複製され、複数のエントリポイントが可能になる。
その他 †
カスタム・プロパティ †
- 属性の使用に加えて、
nifi.propertiesファイルのnifi.variable.registry.propertiesフィールドで
Expression Languageで使用するカスタムプロパティを定義することもできる。
- 接続プロパティ
- サーバープロパティ
- およびサービスプロパティ
Template †
- Processorを組み合わせをフローのビルディング・ブロックとして再利用できる。
- 作成には、複数のコンポーネントを選択し、Operatorから[Create Template]ボタンを選択。
監視 †
Status Bar †
Component Statistics †
Bulletins †
データの起源・出所 †
イベントの詳細 †
リネージュ・グラフ †
step by step的な †
参考 †
nifi.apache.org †
hortonworks.com †
ijokarumawak/hdf-tutorials-ja †
Qiita †
参考 †
設計コンセプト †
FBP †
- 基本的な設計コンセプトはFlow Based Programming(FBP)と関連が強い。
- Flow Based Programming(FBP)の用語とのマッピングは下表のようになっている。
| # | NiFi? 用語 | FBP 用語 | Description |
| 1 | FlowFile? | Information Packet | システム間を移動する各オブジェクトのことを示している。
バイナリ形式でKeyValue?の属性文字列を保持している。 |
| 2 | Processor | Information Packet | Enterprise Integration Patterns(EIP)においてルーティング、変換、システム仲介を行うもの。
与えられたFlowFile?の属性、およびFlowFile?の流れるストリームにアクセスする。
0から任意の数のFlowFile?群を処理単位として認識し、その単位で処理やコミット、ロールバックを可能とする。 |
| 3 | Connection | Bounded Buffer | Processor間の実接続を示す。
キューとして動作し、様々な処理を異なるタイミングで差し込むことが可能。
これらのキューは動的な優先度付け機構、バックプレッシャー機構を有する。 |
| 4 | Controller | Scheduler | プロセス、スレッドの配置や接続関係について統括している。
Processor間のFlowFile?のやり取りを容易にするBrokerとして動作する。 |
| 5 | Process Group | subnet | プロセスとConnectionの一群を指し、外部からメッセージを受け取るInputPort?や出力するOutputPort?を有する。
これらの組み合わせによってProcess Groupは新たなコンポーネントの生成も可能になっている。 |
SEDA †
- この設計コンセプトはstaged event-driven architecture(SEDA)とも似ている。
- staged event-driven architecture(SEDA)から様々な設計アイディアをえている。
SlideShare? †
KojiKawamura? †
https://www.slideshare.net/KojiKawamura/presentations
Qiita †
kimutansk †
https://qiita.com/kimutansk
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
