問題タブ [hdfs]

HDFS に保存された lucene インデックス ディレクトリを読み取る方法、つまり、HDFS に保存されたインデックスの IndexReader を取得する方法。IndexReader はマップ タスクで開かれます。

次のようなもの: IndexReader リーダー = IndexReader.open("hdfs/path/to/index/directory");

ありがとう、アキル

Amazon EC2 でクラスターを実行しています。Hadoop のセットアップに cloudera スクリプトを使用しています。マスターノードで、以下のサービスを開始します。

スレーブ マシンでは、以下のサービスを実行します。

私たちが直面している主な問題は、hdfs セーフモードの回復に 1 時間以上かかることであり、これが原因でジョブの完了が遅れています。

以下は、主なログ メッセージです。

ジョブ トラッカーが開始されていないため、タスク トラッカー ログに最初のメッセージがスローされます。hdfs セーフモード リカバリのため、ジョブ トラッカーが起動しませんでした。

2 番目のメッセージは、回復プロセス中にスローされます。

私が間違っていることはありますか？通常の hdfs セーフモード リカバリにはどのくらいの時間がかかりますか? ジョブ トラッカーが開始されるまでタスク トラッカーを開始しないことで、スピードアップはありますか? Amazon クラスターに既知の Hadoop の問題はありますか?

ご協力いただきありがとうございます。

これは、Hadoop/HDFS に関する概念的な質問です。10 億行を含むファイルがあるとします。簡単にするために、各行は、<k,v>k が先頭からの行のオフセットであり、値が行の内容である形式であると考えてみましょう。

さて、N 個の map タスクを実行したいと言った場合、フレームワークは入力ファイルを N 個の分割に分割し、その分割で各 map タスクを実行しますか? または、N 個の分割を行い、生成された分割で各マップ タスクを実行するパーティショニング関数を作成する必要がありますか?

私が知りたいのは、分割が内部で行われるのか、それともデータを手動で分割する必要があるのか​​ということだけです.

より具体的には、 map() 関数が呼び出されるたびに、そのKey key and Value valパラメーターは何ですか?

ありがとう、ディーパック

「Vector」などの Java シリアル化オブジェクトを含むファイルがあります。このファイルを Hadoop Distributed File System (HDFS) に保存しました。ここで、map タスクの 1 つでこのファイルを (メソッド readObject を使用して) 読み取るつもりです。私は考えます

ファイルは HDFS 経由で保存されるため、機能しません。そこで、org.apache.hadoop.fs.FileSystem クラスを使用することを考えました。残念ながら、FileInputStream を返すメソッドはありません。それが持っているのは FSDataInputStream を返すメソッドだけですが、FSDataInputStream が行うプリミティブ データ型だけでなく、ベクトルなどのシリアル化された Java オブジェクトをファイルから読み取ることができる入力ストリームが必要です。

助けてください！

Amazon EC2 で 5 つのノードを含む Hadoop クラスターをセットアップしました。ここで、マスター ノードにログインして次のコマンドを送信すると、

次のエラーがスローされます (同時にではありません)。最初のエラーはスラッシュを '%2F' に置き換えないとスローされ、2 番目のエラーはスラッシュを '%2F' に置き換えたときにスローされます。

ノート：

1）マスターで実行されているタスクを確認するために jps を送信したところ、表示されました

DataNode と TaskTracker を残します。

2) 私の秘密鍵には 2 つの「/」(スラッシュ) が含まれています。そして、S3 URI でそれらを「%2F」に置き換えます。

PS: 単一ノードで実行すると、プログラムは EC2 で正常に実行されます。クラスターを起動したときにのみ、HDFS との間で S3 との間でデータをコピーすることに関連する問題が発生します。そして、distcp は何をしますか? S3 から HDFS にデータをコピーした後でも、データを配布する必要がありますか? (HDFS が内部で処理すると思っていました)

Amazon EC2/S3 を使用して Hadoop クラスターで Map/reduce プログラムを実行する方法を説明するリンクに誘導していただければ幸いです。それは素晴らしいことです。

よろしく、

ディーパック。

コンピューティング グリッド内の多数のサーバーからログを集約するために、Splunk に似たものを構築するために使用できる最適なコンポーネントを見つけようとしています。また、毎日大量のログがあり、単一のマシンにログを保存できないため、分散する必要があります。

私は特に、Ruby で動作し、Windows と最新の Solaris で動作するものに興味があります (ええ、私は動物園を持っています)。

私はアーキテクチャを次のように考えています。

• ログクローラー (Ruby スクリプト)。
• 分散ログ ストレージ。
• 分散検索エンジン。
• 軽量フロントエンド。

ログ クローラーと分散検索エンジンは問題外です。ログは Ruby スクリプトによって解析され、ElasticSearch はログ メッセージのインデックス作成に使用されます。フロントエンドもとても選びやすい - Sinatra。

私の主な問題は分散ログ ストレージです。MongoDB、CouchDB、HDFS、Cassandra、HBase について調べました。

• MongoDB は、Solaris で動作しないため拒否されました。
• CouchDB はシャーディングをサポートしていません (それを機能させるにはスマートプロキシが必要ですが、これは試したくありません)。
• Cassandra はうまく機能しますが、ディスク容量を大量に消費するだけであり、Cassandra ノード間で負荷を分散するために毎日オートバランスを実行する必要があります。
• HDFS は有望に見えましたが、FileSystem API は Java のみで、JRuby は苦労しました。
• HBase は最善のソリューションのように見えましたが、デプロイと監視は単なる災害です。HBase を開始するには、最初に HDFS を開始し、問題なく開始されたことを確認し、次に HBase を開始してそれも確認し、REST サービスを開始して、も確認してください。

だから私は立ち往生しています。HDFS または HBase がログ ストレージとして使用するのに最適であると言う人もいますが、HDFS は Java でのみスムーズに動作し、HBase は展開/監視の悪夢に過ぎません。

上記のコンポーネントを使用して、またはまったく異なるものを使用して同様のシステムを構築した経験や考えを共有できる人はいますか?

Windows をサポートする DFS を見つけたいと思っています。そのような DFS は Hadoop HDFS だけですが、Cygwin + SSH が必要なため、他の多数の Windows マシンに展開するのは非常に困難です。

ほとんどすべての DFS システムは Linux でのみ動作し、1 つ (HDFS) のみが Windows で動作します。

誰かが Windows をサポートする他の DFS を教えてくれたらとてもありがたいです。

DFS から、DFS ノード間でファイルの負荷を分散する機能、圧縮、および DFS を操作するための多言語 API が必要です (DFS をマウントする必要はありません)。

Ruby を使用して HDFS Api を操作する方法はありますか? 私が理解できるように、多言語ファイル Api はなく、唯一の方法はネイティブ Java Api を使用することです。JRuby を使用してみましたが、この解決策は不安定でネイティブではありません。また、HDFS Thrift Api も調べましたが、完全ではなく、多くの機能 (インデックス付きファイルへの書き込みなど) も不足しています。

JRuby または Thrift Api を使用する以外に、Ruby を使用して HDFS を操作する方法はありますか?

Avro を使用して Hadoop HDFS からファイルを保存および読み取ることに興味があり、Avro のサポートの実装に関する Hadoop の問題トラッカーでいくつかの Jira を見ましたが、Hadoop で Avro サポートを有効にする方法の例はありませんでした。また、一部の Jira は 0.21 でクローズされたため、現在の 0.20 が Avro をサポートしているかどうかは完全にはわかりません。最新の 0.21 を入手してなんとか終了して Avro をオンにして使用することは可能でしょうか?

ローカルシステムでHadoopアプリケーションを実行するためのオプションを検討しています。

多くのアプリケーションと同様に、利用可能なすべてのCPUコアを使用できる限り、最初のいくつかのリリースは単一ノードで実行できるはずです（はい、これはこの質問に関連しています）。現在の制限は、本番システムにはJava 1.5があるため、最新リリースとしてHadoop 0.18.3にバインドされていることです（この質問を参照してください）。そのため、残念ながら、この新機能はまだ使用できません。

最初のオプションは、単純にhadoopを疑似分散モードで実行することです。基本的に：すべてが正確に1つのノードで実行されている完全なHadoopクラスターを作成します。

このフォームの「欠点」は、本格的なHDFSも使用することです。これは、入力データを処理するために、これを最初にローカルに保存されているDFS...に「アップロード」する必要があることを意味します。したがって、これには入力データと出力データの両方の追加の転送時間がかかり、追加のディスク領域が使用されます。単一ノード構成のままでいる間は、これらの両方を避けたいと思います。

だから私は考えていました：「fs.hdfs.impl」設定をオーバーライドして、「org.apache.hadoop.dfs.DistributedFileSystem」から（たとえば）「org.apache.hadoop.fs.LocalFileSystem」に変更することは可能ですか？ ？

これが機能する場合、「ローカル」Hadoopクラスター（1つのノードのみで構成できます）は、追加のストレージ要件なしで既存のファイルを使用でき、ファイルをアップロードする必要がないため、より迅速に起動できます。私はまだジョブとタスクトラッカー、そしておそらく全体を制御するためのネームノードを持っていることを期待しています。

誰かがこれを以前に試したことがありますか？それは機能しますか、それともこのアイデアは意図された用途から大きく外れていますか？

または、同じ効果を得るより良い方法があります：HDFSなしの疑似分散操作？

あなたの洞察に感謝します。

編集2：

これは、bajafresh4lifeによって提供された回答を使用してhadoop 0.18.3 conf/hadoop-site.xml用に作成した構成です。