3

REST API 呼び出しを使用してエンドポイントからデータを取り込み、そのデータを HDFS に保存する予定です。REST 呼び出しは定期的に (毎日または場合によっては 1 時間ごとに) 行われます。

私はすでに Flume を使用して Twitter の取り込みを行っていますが、Flume を使用することは私の現在のユースケースには適さないと思います。なぜなら、私は Twitter でこのような継続的なデータ ファイアホースを使用しておらず、個別の定期的な時間制限のある呼び出しを使用しているためです。

私が今考えているアイデアは、REST API 呼び出しを処理して HDFS に保存するカスタム Java を使用し、その Java jar で Oozie コーディネーターを使用することです。

設計と、このユースケースに使用する Hadoop ベースのコンポーネントについて、提案/代替案 (現在考えているものよりも簡単な場合) を聞きたいです。私が Flume に固執できると思われる場合は、その方法も教えてください。

4

1 に答える 1

3

Apache Flume Web で述べられているように:

Apache Flume は、多数の異なるソースから大量のログ データを効率的に収集、集約、および集中化されたデータ ストアに移動するための、信頼性と可用性に優れた分散型システムです。

ご覧のとおり、Flume に起因する機能の 1 つにデータの収集があります。「プッシュ状またはエミット状」のデータ ソースはHttpSource、AvroSurce、ThriftSource、 などのおかげで簡単に統合できます。データを http ベースのサービスから「積極的にプル」する必要がある場合、統合はそれほど明白ではありません。 、しかし、行うことができます。たとえばExecSource、データを取得して Flume エージェントにプッシュするスクリプトを実行する を使用します。

データのプルと HDFS への書き込みを担当する独自のコードを使用する場合、そのような設計は問題ありませんが、いくつかの興味深い組み込み Flume 特性が失われます (おそらく自分で実装する必要があります)。

  • 信頼性。Flume には、データが実際に最終ストレージに保持されるようにするメカニズムがあり、効果的に書き込まれるまで再試行します。これは、入力 (負荷のピークを取り込む) と出力 (効果的に永続化されるまでデータを保持する) の両方でデータをバッファリングする内部チャネルの使用と、トランザクションの概念によって実現されます。
  • パフォーマンス。トランザクションの使用と、複数の並列シンク (データ プロセッサ) を構成する可能性により、デプロイで 1 秒あたりに生成される非常に大量のデータを処理できるようになります。
  • 使いやすさ。Flume を使用すると、ストレージの詳細 (HDFS API など) を処理する必要がなくなります。最終ストレージを変更することにした場合でも、新しい関連シンクを使用するために Flume エージェントを再構成するだけで済みます。
于 2015-11-11T09:07:53.663 に答える