Apache NiFiとStreamSetsの違い
私はクラスプロジェクトを行うことを計画しており、システム間のデータの流れを自動化または設定できるいくつかの技術を試していましたが、それらがいくつかあることがわかりました（Apache NiFiとStreamSets（私の知る限り））。私が理解できなかったのは、それらとそれらを使用できるユースケースの違いですか？私はこれに新しいです、そして、誰かが私に少し説明することができれば非常に高く評価されるでしょう。ありがとう
スラジ、
いい質問ですね。
私の回答は、オープンソースのApache NiFiプロジェクト管理委員会のメンバーとして、またデータフロー管理ドメインに熱心な人としてです。
2006年のNiFiプロジェクトの開始以来、私はNiFiプロジェクトに参加しています。Streamsetsについての私の知識は比較的限られているため、彼らに話させてもらいます。
理解すべき重要なことは、NiFiが1つの非常に重要なことを本当にうまく行うために構築されたものであり、それが「データフロー管理」であることです。このデザインは、Flow Based Programmingというコンセプトに基づいています。このコンセプトは、プロジェクトについて読み、参照することができます ' https://en.wikipedia.org/wiki/Flow-based_programming '
センサーなどのデータを生成するシステムはすでに多くあります。 Apache Storm、Spark、Flinkなどのようなデータ処理に焦点を当てた多くのシステムがあります。そして最後に、HDFS、リレーショナルデータベースなどのデータを保存する多くのシステムがあります。 NiFiは、これらのシステムを接続し、そのために必要なユーザーエクスペリエンスとコア機能を提供するタスクにのみ焦点を当てています。
それらを効果的にするために行われたこれらの主要な機能と設計上の選択のいくつかは何ですか：
1）インタラクティブなコマンドと制御
システムを接続しようとする人の仕事は、見ているデータの絶え間ないストリームと迅速かつ効率的にやり取りできるようにすることです。 NiFiのUIを使用すると、データの流れに合わせて機能を追加したり、データのコピーを分岐して新しいアプローチを試したり、現在の設定を調整したり、最近および過去の統計を確認したり、役立つインラインドキュメントを表示したりできます。比較すると、他のほとんどすべてのシステムには、設計および展開指向のモデルがあります。つまり、一連の変更を行ってから展開します。そのモデルは素晴らしく直感的ですが、データフロー管理ジョブでは、新しいフローをすばやく構築したり、既存のデータストリームの処理を安全かつ効率的に修正または改善したりするために非常に重要な変更フィードバックによるインタラクティブな変更を取得しないことを意味します。
2）データの出所
NiFiの非常にユニークな機能は、データの送信元、処理内容、送信先、フローで実行されるタイミングについて、きめ細かく強力なトレーサビリティ詳細を生成する機能です。これはいくつかの理由で効果的なデータフロー管理に不可欠ですが、初期の調査段階やプロジェクトの作業をしている人にとって、これが提供する最も重要なことは素晴らしいデバッグの柔軟性です。フローを設定し、物事を実行してから、来歴を使用して、実際に希望どおりに実行されたことを実際に証明できます。予期したとおりに何も起こらなかった場合は、フローを修正してオブジェクトを再生し、繰り返します。本当に助かりました。
3）専用のデータリポジトリ
NiFiのすぐに使えるエクスペリエンスは、本当に控えめなハードウェアまたは仮想環境でも非常に強力なパフォーマンスを提供します。これは、フローファイルとコンテンツリポジトリの設計により、パフォーマンスが向上しますが、データがフローを通過するときに必要なトランザクションセマンティクスが必要になるためです。フローファイルリポジトリは単純な先読みログの実装であり、コンテンツリポジトリは不変のバージョン管理されたコンテンツストアを提供します。つまり、新しいポインターを追加するだけで（実際にバイトをコピーするのではなく）データを「コピー」できること、または元のデータを読み取って新しいバージョンを書き込むだけでデータを変換できることを意味します。再び非常に効率的です。それを、さっき言った由来のものと組み合わせれば、本当に強力なプラットフォームを提供するだけです。ここで理解すべきもう1つの重要なことは、システムを接続するビジネスでは、関連するデータのサイズなどを常に指示するわけではないということです。 NiFi APIはその事実を尊重するように構築されているため、APIを使用すると、プロセッサはメモリ内のオブジェクト全体を読み込むことなく、データの受信、変換、送信などを実行できます。また、これらのリポジトリは、ほとんどのフローで、大半のプロセッサがコンテンツにまったく触れないことも意味します。ただし、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メーリングリストがお手伝いします。
ありがとうジョー
Apache NiFiとStreamSets Data Collectorは、どちらもApacheライセンスのオープンソースツールです。
Hortonworksには、Hortonworks DataFlow（HDF）と呼ばれる商業的にサポートされているバリアントがあります。
両方ともWebベースのUIなど多くの類似点がありますが、どちらもデータの取り込みに使用されますが、いくつかの重要な違いがあります。また、両方とも、変換、シリアル化などを実行するために相互にリンクされたプロセッサで構成されます。
NiFiプロセッサは、ファイル指向でスキーマレスです。これは、データの一部がFlowFileによって表されることを意味します（これは、ディスク上の実際のファイル、または他の場所で取得されたデータの一部です）。各プロセッサは、データを操作するためにデータの内容を理解する責任があります。したがって、1つのプロセッサがフォーマットAを理解し、別のプロセッサがフォーマットBのみを理解する場合、これら2つのプロセッサ間でデータフォーマット変換を実行する必要があります。
NiFiは、スタンドアロンで実行することも、独自の組み込みクラスタリングシステムを使用してクラスターとして実行することもできます。
ただし、StreamSets Data Collector（SDC）はレコードベースのアプローチを採用しています。これは、データがパイプラインに入ると（JSON、CSVなど）データが共通の形式に解析されるため、データ形式を理解する責任が個々のプロセッサに課せられず、どのプロセッサも接続できることです。他のプロセッサに。
SDCもスタンドアロンモードとクラスターモードで実行されますが、YARN/Mesosでは代わりにSparkを実行し、既存のクラスターリソースを活用します。
NiFiは約10年前から存在します（ただし、オープンソースコミュニティでは2年未満です）。
StreamSetsは2015年の少し後にオープンソースコミュニティにリリースされました。ベンダーに依存せず、Hadoopに関してはHortonworks、Cloudera、MapRがすべてサポートされています。
完全な開示：私はStreamSetで作業するエンジニアです。
データ取り込みシナリオでは非常によく似ています。 Apache NIFI（HDP）はより成熟しており、StreamSetsはより軽量です。どちらも使いやすく、強力な機能を備えています。また、StreamSetsには、HortonworksとClouderaという企業が簡単にできます。
もちろん、NIFIにはStreamSetsよりも多くの貢献者がいます。もちろん、NIFIには実稼働環境でより多くのエンタープライズ展開があります。
2つのIMHOの主な差別化要因の2つがあります。
Apache NiFiはトップレベルのApacheプロジェクトです。つまり、ここで説明されているインキュベーションプロセス http://incubator.Apache.org/policy/process.html を経て、周りの開発者からの貢献を受け入れることができます。ソフトウェアの品質を保証する標準のApacheプロセスに従う世界。 StreamSetsはApache LICENSEDです。つまり、誰でもコードなどを再利用できます。しかし、プロジェクトはApacheプロジェクトとして管理されていません。実際、Streamsetsに貢献するためにも、契約書に署名する必要があります。 https://streamsets.com/contributing/ これとは対照的に、Apache NiFi寄稿者ガイドは、弁護士によって書かれたものではありません。 https://cwiki.Apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-HowtocontributetoApacheNiFi
StreamSetsは「Spark YARN/Mesosの代わりに実行され、既存のクラスターリソースを活用します。」）データフローをさらにエッジに向けて展開する場合は、少し制限を課します。 NiFiのサブプロジェクトであるApache MiniFiは、単一のRaspberry Piで実行できますが、YARNまたはMesosはRaspberry Piが提供するよりも多くのリソースを必要とするため、StreamSetsは実行できないと確信しています。
開示：私はHortonworksの従業員です