私はクラスプロジェクトを計画しており、システム間のデータフローを自動化または設定できるいくつかのテクノロジを実行していたところ、Apache NiFiとStreamSetsがいくつかあることがわかりました(私の知る限り)。私が理解できなかったのは、それらとそれらを使用できるユースケースの違いです。私はこれに慣れていないので、誰かが私に少し説明することができれば非常に感謝します。ありがとう
スラジュ、
すばらしい質問です。
私の回答は、オープンソースのApache NiFiプロジェクト管理委員会のメンバーとして、およびデータフロー管理ドメインに情熱を傾けている人としてです。
私はNiFiプロジェクトに2006年の開始以来携わってきました。Streamsetsに関する私の知識は比較的限られているので、現状のまま話してもらいます。
理解しておくべき重要なことは、NiFiは1つの非常に重要なことを非常にうまく行うように構築されていること、そしてそれは「データフロー管理」です。その設計は、プロジェクトの「https://en.wikipedia.org/wiki/Flow-based_programming」について読んだり参照したりできるフローベースのプログラミングと呼ばれる概念に基づいています。
センサーなどのデータを生成するシステムはすでにたくさんあります。Apache Storm、Spark、Flinkなどのデータ処理に重点を置いたシステムは数多くあります。そして最後に、HDFSやリレーショナルデータベースなどのデータを保存する多くのシステムがあります。NiFiは、これらのシステムを接続し、それを適切に行うために必要なユーザーエクスペリエンスとコア機能を提供するタスクに純粋に焦点を当てています。
それを効果的にするために行われたそれらの主要な機能と設計の選択のいくつかは何ですか?
1)インタラクティブなコマンドと制御
システムを接続しようとする誰かの仕事は、彼らが見るデータの一定のストリームと迅速かつ効率的に対話できるようにすることです。NiFiのUIを使用すると、データが流れているときに、データを操作する機能を追加したり、データのコピーをフォークして新しいアプローチを試したり、現在の設定を調整したり、最近および過去の統計を確認したり、役立つインラインドキュメントを表示したりできます。比較すると、他のほとんどすべてのシステムには、設計と配置指向のモデルがあります。つまり、一連の変更を行ってから配置します。そのモデルは適切で直感的ですが、データフロー管理ジョブの場合、新しいフローをすばやく構築したり、既存のデータストリームの処理を安全かつ効率的に修正または改善するために非常に重要な変更フィードバックによってインタラクティブな変更を取得できないことを意味します。
2)データ来歴
NiFiの非常にユニークな機能は、データがどこから来たのか、何が行われたのか、どこに送信されたのか、いつフローで行われたのかについて、きめ細かく強力なトレーサビリティの詳細を生成する機能です。これは多くの理由で効果的なデータフロー管理に不可欠ですが、初期の調査段階でプロジェクトを作業している人にとって、これが与える最も重要なことは素晴らしいデバッグの柔軟性です。フローを設定し、物事を実行させてから、来歴を使用して、目的どおりに実行されたことを実際に証明できます。予期したとおりに何かが発生しなかった場合は、フローを修正してオブジェクトを再生してから繰り返すことができます。本当に役に立ちました。
3)専用のデータリポジトリ
NiFiの独創的なエクスペリエンスは、非常に控えめなハードウェアまたは仮想環境でも非常に強力なパフォーマンスを提供します。これは、フローファイルとコンテンツリポジトリの設計によるものです。これにより、データがフローを介して機能するときに必要な高性能でトランザクションセマンティクスが得られます。flowfileリポジトリは、単純な先書きログ実装であり、コンテンツリポジトリは、不変のバージョン管理されたコンテンツストアを提供します。つまり、新しいポインタを追加するだけで(実際にはバイトをコピーするのではなく)データを「コピー」できるか、元のデータを読み取って新しいバージョンを書き込むだけでデータを変換できます。再び非常に効率的です。それを先ほど述べた来歴の要素と組み合わせると、本当に強力なプラットフォームを提供するだけです。ここで理解しておくべきもう1つの本当に重要なことは、システムを接続するビジネスでは、関係するデータのサイズなどを常に指示できるとは限らないことです。NiFi APIはその事実を尊重するために構築されたので、APIを使用すると、プロセッサはデータを受信、変換、送信することなどができ、メモリにオブジェクト全体をロードする必要がありません。これらのリポジトリは、ほとんどのフローで、大多数のプロセッサがコンテンツにまったく触れていないことも意味します。ただし、NiFi UIから実際に読み取られているバイト数または書き込まれているバイト数を簡単に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。関係するデータのサイズなどを常に指示する必要があります。NiFi APIはその事実を尊重するために構築されたので、APIを使用すると、プロセッサはデータを受信、変換、送信することなどができ、メモリにオブジェクト全体をロードする必要がありません。これらのリポジトリは、ほとんどのフローで、大多数のプロセッサがコンテンツにまったく触れていないことも意味します。ただし、NiFi UIから実際に読み取られているバイト数または書き込まれているバイト数を簡単に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。関係するデータのサイズなどを常に指示する必要があります。NiFi APIはその事実を尊重するために構築されたので、APIを使用すると、プロセッサはデータを受信、変換、送信することなどができ、メモリにオブジェクト全体をロードする必要がありません。これらのリポジトリは、ほとんどのフローで、大多数のプロセッサがコンテンツにまったく触れていないことも意味します。ただし、NiFi UIから実際に読み取られているバイト数または書き込まれているバイト数を簡単に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。完全なオブジェクトをメモリにロードしなくてもデータを送信できます。これらのリポジトリは、ほとんどのフローで、大多数のプロセッサがコンテンツにまったく触れていないことも意味します。ただし、NiFi UIから実際に読み取られているバイト数または書き込まれているバイト数を簡単に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。完全なオブジェクトをメモリにロードしなくてもデータを送信できます。これらのリポジトリは、ほとんどのフローで、大多数のプロセッサがコンテンツにまったく触れていないことも意味します。ただし、NiFi UIから実際に読み取られているバイト数または書き込まれているバイト数を簡単に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。実際に読み書きされているバイト数をNiFi UIから簡単に正確に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。実際に読み書きされているバイト数をNiFi UIから簡単に正確に確認できるため、フローの確立と監視に役立つ情報が得られます。この設計は、NiFiがバックプレッシャーとプレッシャーリリースを自然にサポートできることも意味し、これらはデータフロー管理システムにとって非常に重要な機能です。
以前にStreamsets社の人々がNiFiはファイル指向であると述べました。一般的な用語でファイル、レコード、タプル、オブジェクト、メッセージの違いがよくわかりませんが、実際には、データがフロー内にある場合、それは「管理する必要があるものであり、配信されました。それがNiFiの機能です。非常に高速な小さなものがたくさんあるか、大きなものがあるか、インターネットからのライブオーディオストリームからのものか、ハードドライブにあるファイルからのものかは問題ではありません。フローに入ったら、それを管理して配信する時間です。それがNiFiの機能です。
Streamsetsの会社から、NiFiはスキーマレスであるとも言われていました。NiFiがデータを元々ある特別なNiFi形式に変換することを強制せず、後続の配信のためにデータを何らかの形式に再変換する必要もないことは正確です。これが意味することは、最も些細なケースでもパフォーマンスに問題があり、NiFiには問題がないということです。さらに、そのルートをたどると、メディア(画像、ビデオ、オーディオなど)のような多様なデータセットの処理が困難になることを意味しますが、私たちは正しい方向に進んでおり、NiFiは常にそのようなことに使用されています。
最後に、プロジェクトを続行していて、改善してほしい点や、コードを寄稿したい点がある場合は、ぜひご協力ください。https://nifi.apache.orgから、チケットの提出、パッチの提出、メーリングリストへのメール送信などの方法に関する情報をすばやく見つけることができます。
チェックアウトする楽しい最近のNiFiプロジェクトをいくつか示します 。https://www.linkedin.com/pulse/nifi-ocr-using-apache-read-childrens-books-jeremy-dyer https://twitter.com/KayLerch / status / 721455415456882689
クラスプロジェクトで頑張ってください!ご不明な点がございましたら、users @ nifi.apache.orgメーリングリストをご利用ください。
ありがとうジョー
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加