.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • EAI/ETL系のデータフロー・オーケストレーション・ツール。
  • システム間のデータフロー自動化を行うために構築された。
  • NSA(アメリカ国家安全保障局)で開発されていたものが、
    2014年にオープンソースソフトウェアとして公開された。
  • 2015年7月にApacheのTopレベルプロジェクトになった。

特徴

  • もともと、Niagrafilesという名前だった。
    (ナイアガラの滝のようにドーッと降りてくる大量の水を処理するという発想。)
  • ツールの仕様としては、ETLツールに近い(GUIを使ってデータとプロセスを定義する)。
  • しかし、ETLは本来、バッチ指向なので、イベント指向のEAIに近いと言える。
  • ビッグデータの3Vのコンテキストでは、
    • Apache Storm(リアルタイム分散処理を対象としたストリーム処理を行う)代替のエッジ・コンピューティング・ツール。
    • 「多様性」を重視している(カチッと整形されたデータではなくても様々なデータが処理可能)。

関連PJ

Registry

フロー定義を「as a code」として管理するサブ・プロジェクト

MiNiFi

小さなフットプリントでデータフローを実行できるサブ・プロジェクト

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].)

と書かれている。

EAI/ETL

ツールの仕様としては、どちらにも適合する可能性がある。

ETL

バッチ指向なので適合しない可能性がある(性能検証などが必要)。

EAI

イベント指向なのでこちらのほうが適合し易い。

WebAPI

Remote Process GroupでHTTPなどのEndpointを定義してS2Sが可能。

MiNiFi

以下での利用が想定されている。

  • IoTデバイス
  • エッジ・コンピューティング

用語

FlowFile?

ユーザデータ

  • ユーザが処理および配信のためにもたらすデータ
  • ContentAttributesからなる。

Content

扱うデータの本体(バイナリ形式)

Attirbutes

  • ユーザーデータに関連付けられたKeyValue?のメタ情報。
  • 以下の、3つの主要な利点がある。
    1. Processor毎に独自のAttirbutesを持つ。
      例えば、PutFile? Processorであれば、ディレクトリとファイル名の属性を持つ。
    2. 起源・出所など、データに関する非常に貴重なcontextを提供する。
    3. 属性に基づいてフロー内でFlowFile?のルーティングを決定できる。
  • 共通の属性
    #属性名説明変更可否
    1filenameファイル名
    2pathディレクトリ名
    3fileSizeファイルのバイト数不可
    4uuid他のFlowFiles?FlowFile?を区別する汎用一意識別子不可
    5entryDateFlowFile?が作成された日時(UTC)不可
    6lineageStartDate?先祖の連鎖の最古の日時(UTC)不可
  • 属性の設定
    • 属性を抽出するProcessorがある。
      • 特定のデータフォーマットを理解し、
      • FlowFile?のコンテンツから適切な情報を抽出し、
      • その情報を保持する属性を作成し、
      • データのルーティングや処理方法の決定を行う。
  • ユーザー定義属性をするProcessorがある。
    • フロー内の特定の場所にある各FlowFile?
      独自のユーザー定義属性を追加することも一般的。
    • これには、UpdateAttribute? Processorを使用する。
  • 属性の利用
  • 属性を使用した分岐
    • NiFi?の最も強力な機能の1つに、属性に基づいてFlowFiles?を分岐させる機能がある。
    • これには、RouteOnAttribute? Processorに、Expression Languageの式を設定する。
    • Processorは構成によって、一致と不一致のRelationshipを公開する。
  • Expression Language/プロパティ値での利用
  • 属性値の参照:${ tag and the closing }(${uudi}など)
    次のケースでは、属性名を引用符で囲む必要がある。
    ・必要属性名が文字以外の文字で始まる場合
    ・または数字、文字、ピリオド、アンダースコア以外の文字が含まれている場合
  • 属性に対して多くの機能と比較を実行
    ・ファイル名に大小を区別しない「r」が含まれる。:
    ${filename:toLower():contains('r')}
    ・属性1と2が一致している。:
    ${attr1:equals(${attr2})}

Processor

  • データフローを記述したグラフ(DAG)におけるノード(節点・頂点)に相当する。
  • FlowFileにどんな処理を施すか」を表す、最も重要なビルディング・ブロック。
  • FlowFiles?の作成、送信、受信、変換、ルーティング、分割、マージ、および処理を担当する。
  • 組込Processorに加え、カスタムProcessorを開発して組込むことも可能。

詳細:Apache NiFi - Processor

Connection

データフローを記述したグラフ(DAG)におけるエッジ(枝・辺)の属性に相当する。

Relationship

  • Processorごとにあらかじめ定義されている。
    • original
    • failure
    • , etc.
  • RouteOnAttribute? Processorに、Expression Languageの式を設定すると公開される。
    • 一致
    • 不一致

Selected Prioritizers

キューから取り出す優先順位は、大方、

  • FirstInFirstOutPrioritizer?
  • OldestFlowFileFirstPrioritizer?

などを設定しておけば良いのでは。

アーキテクチャ

ホストOS上のJVM内で実行される。

https://nifi.apache.org/docs/nifi-docs/html/images/zero-master-node.png

引用:nifi.apache.org/docs/nifi-docs/html/images/zero-master-node.png

主要コンポーネント

以下は、JVM上の主なコンポーネント。

Web Server

HTTPベースのコマンドと制御APIをホストする。

Extensions

  • 様々なタイプの拡張がある。
  • JVM内で動作して実行される。

Flow Controller

操作の頭脳

  • Extensions
    • スレッド実行
    • リソース受け取りのスケジューリング
    • Processor間でのコンテキストの共有
      • HTTPContext
      • データストアとの接続

FlowFile Repository

  • 現在アクティブなFlowFileの状態を追跡する場所。
  • リポジトリの実装はプラガブル。
    • デフォルトの場所は、...\nifi-n.n.n\flowfile_repository

Content Repository

  • FlowFileの実際のコンテンツバイトが存在する場所。
  • リポジトリの実装はプラガブル。
    • ファイルシステムにデータのブロックを格納する。
    • 複数のファイルシステム格納場所を指定するできる。
    • デフォルトの場所は、...\nifi-n.n.n\content_repository

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的な

ファースト・ステップ

セカンド・ステップ

ユースケース

考察

flow-based programming (FBP)ツールとしての利用。

データ統合、EAI/ETL

ビッグデータのコンテキスト

  • Apache Storm代替
  • エッジ・コンピューティング
    • データマネージメント
    • データのエンリッチメント

その他の応用

その他、以下のような応用もできそう(私見

  • System Workflow代替
  • WebAPI開発
  • 簡易WebAPI開発
  • 複雑な業務プロセスを開発

参考

参考

Apache Storm

nifi.apache.org

  • Developer

SlideShare?

KojiKawamura?

https://www.slideshare.net/KojiKawamura/presentations

Qiita

kimutansk

https://qiita.com/kimutansk

GitHub?.com

Apache

Hortonworks

step by step的な

nifi.apache.org

hortonworks.com

ijokarumawak/hdf-tutorials-ja

  • HDFハンズオン

Qiita

設計コンセプト

FBP

  • 基本的な設計コンセプトはFlow Based Programming(FBP)と関連が強い。
  • Flow Based Programming(FBP)の用語とのマッピングは下表のようになっている。
#NiFi? 用語FBP 用語Description
1FlowFile?Information Packetシステム間を移動する各オブジェクトのことを示している。
バイナリ形式でKeyValue?の属性文字列を保持している。
2ProcessorInformation PacketEnterprise Integration Patterns(EIP)においてルーティング、変換、システム仲介を行うもの。
与えられたFlowFile?の属性、およびFlowFile?の流れるストリームにアクセスする。
0から任意の数のFlowFile?群を処理単位として認識し、その単位で処理やコミット、ロールバックを可能とする。
3ConnectionBounded BufferProcessor間の実接続を示す。
キューとして動作し、様々な処理を異なるタイミングで差し込むことが可能。
これらのキューは動的な優先度付け機構、バックプレッシャー機構を有する。
4ControllerSchedulerプロセス、スレッドの配置や接続関係について統括している。
Processor間のFlowFile?のやり取りを容易にするBrokerとして動作する。
5Process GroupsubnetプロセスとConnectionの一群を指し、外部からメッセージを受け取るInputPort?や出力するOutputPort?を有する。
これらの組み合わせによってProcess Groupは新たなコンポーネントの生成も可能になっている。

SEDA

  • この設計コンセプトはstaged event-driven architecture(SEDA)とも似ている。
  • staged event-driven architecture(SEDA)から様々な設計アイディアをえている。

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-09-13 (木) 11:15:58 (91d)