両方に取り組む機会を得た人はいますか？データを移動するためのフレームワークをセットアップする必要があります。基本的に、クリックストリーム データはテキスト ファイルとして入ってきます。このデータは、アプリ サーバーから HDFS に移動し、アーカイブ後に S3 に移動する必要があります。
Flume と Scribe のどちらを選択するかについてサポートが必要です。管理性、セットアップの点で優れているのはどれで、カスタマイズしやすいのはどれですか?
3399 次
1 に答える
2
ここに投稿された回答を見る
私は答えを引用します：
Flumeを使用すると、すべてのマシンにSSHで接続したり、構成変数を更新したり、デーモンを1つまたは2つ再起動したりすることなく、Flumeインストールを中央から構成できます。Flume jarを使用して、ネットワーク内の任意のコマンドラインから、Flumeを実行している任意のマシン上の論理ノードを開始、停止、作成、削除、および再構成できます。
Flumeには、一元化されたライブネス監視もあります。Scribeプロセスが静かに失敗するという話をいくつか聞いたことがありますが、Scribeの残りのインストールが増加した負荷の下できしむまで、何日も発見されずに横たわっていました。Flumeを使用すると、すべての論理ノードの状態を1か所で確認できます（これはマシンの活性監視とは異なることに注意してください。多くの場合、プロセスが失敗する可能性がある間、マシンは稼働したままです）。
Flumeは、3つの異なるタイプの信頼性保証をサポートしており、リソースの使用量と信頼性の間でトレードオフを行うことができます。特に、Flumeは完全にACKされた信頼性をサポートし、すべてのイベントが最終的にイベントフローを通過することを保証します。
Flumeも非常に拡張性があります。独自のソースまたはシンクを作成し、ほとんどすべてのシステムをFlumeと統合するのは非常に簡単です。独自のローリングが実用的でない場合、Flumeが理解できる形式でアプリケーションにイベントを出力させるのは非常に簡単です（たとえば、FlumeはUnixプロセスを実行できるため、シェルスクリプトを使用してデータを取得できれば、ゴールデン）。
これは、Flumeを使用する利点の完全なリストではありません-軽量変換またはメタデータ抽出、構成言語、単一のFlumeプロセスで複数の論理ノードを実行する機能、自動バケット化およびローリングのためのデコレーターの使用については触れていません。 HDFSのログファイル...Flumeについては、皆さんと共有することを楽しみにしています。
私との主な違いは、ClouderaがFlumeを積極的にサポートしていることです。私は一般的にFacebookが素晴らしいオープンソースプロジェクトを維持することを信頼していますが、Clouderaのビジネスはこのようなツールのサポートを提供することを中心に構築されているため、Flumeは長期的にはより適切にサポートされると確信しています。この特定の問題について考えなければならない時間を最小限に抑えたいと思います。とは言うものの、これまでのところ、1.0より前のテクノロジーから予想されるように、Flumeの抽象化が少し複雑であるか、実装がバグであるという厄介な問題がたくさんありました。Asanaがまだベータ版でなかったら、私はおそらくScribeを選んだでしょう
于 2011-09-24T19:05:54.827 に答える