問題タブ [google-cloud-dataproc]

一般に、Dataproc インスタンスまたはGoogle Cloud PlatformでPrestoを実行したいと考えています。特に Hive で Presto を簡単にセットアップしてインストールするにはどうすればよいですか?

Hive と MySQL の両方を ( Google Cloud SQL経由で) 使用しており、 Prestoを使用して両方に簡単に接続したいと考えています。Cloud Dataproc 用のPresto 初期化アクションがあることを確認しましたが、そのままでは Cloud SQL では機能しません。Presto で Hive/Spark と Cloud SQL の両方を使用できるように、その初期化アクションを Cloud SQL で動作させるにはどうすればよいですか?

パッケージ化する必要があるすべての依存関係を含む .jar ファイルを実行しています。この依存関係の 1 つは、com.google.common.util.concurrent.RateLimiterクラス ファイルがこの .jar ファイルにあることを既に確認しています。

残念ながら、Google の dataproc-cluster インスタンスのマスター ノードで spark-submit コマンドを実行すると、次のエラーが発生します。

私の依存関係を上書きするという意味で何かが起こったようです。Stopwatch.classこの .jar からファイルを既に逆コンパイルし、そのメソッドがそこにあることを確認しました。それは、その google dataproc インスタンスで実行したときに起こりました。をgrep実行しているプロセスで行ったところ、次のようなspark-submitフラグが表示されました。-cp

この問題を解決するためにできることはありますか?

ありがとうございました。

私が実行しているいくつかの Spark LDA トピック モデリング (主に一見ランダムな間隔での関連付け解除エラー) でさまざまな問題が発生しています。これは、問題のある自動クラスター構成に関連しているようです。私の最新の試みでは、マスター ノードとワーカー ノードの両方に n1-standard-8 マシン (8 コア、30 GB RAM) を使用します (6 ワーカー、合計 48 コア)。

しかし、私が見ると、/etc/spark/conf/spark-defaults.confこれがわかります：

しかし、これらの値はあまり意味がありません。なぜ 4/8 executor コアのみを使用するのですか? 9.3 / 30GB RAM しかありませんか? 私の印象では、この構成はすべて自動的に処理されるはずでしたが、手動で調整しようとしてもうまくいきません。

たとえば、次のコマンドでシェルを起動しようとしました。

しかし、これは失敗しました

で関連する値を変更しようとしましたが/etc/hadoop/conf/yarn-site.xml、効果がありませんでした。別のクラスター セットアップを試しても (たとえば、60 GB 以上の RAM を持つエグゼキューターを使用)、同じ問題が発生します。何らかの理由で、最大しきい値が 22528MB のままです。

ここで間違っていることがありますか、それとも Google の自動構成の問題ですか?

私は (Scala API を介して) Spark で LDA モデルを実装し、さまざまな数のトピックでモデルをテストしています。一般的には問題なく動作しているように見えますが、メモリの問題に関連していると確信している断続的なタスク エラーが発生します。私の現在のコードの関連部分は以下の通りです。

各ドキュメントがスパース mllib ベクトルである RDD のテキスト ダンプからデータをロードしていることに注意してください。したがって、私のファイルの例の行はLDA_vectors次のようになります。

これは標準の mllib スパース形式であり、次のように読むことができます。

したがって、parse関数はそれを RDD に読み込む処理を行います。

そして、さまざまな数のトピックでループを実行します。Word ドキュメント マトリックスをファイルに保存するためのコード ブロックは、ここで説明する方法に従っていることに注意してください。

Ok。したがって、これはすべて正常に機能しますが、前述したように、タスクの失敗に遭遇し始め、トピックの数を増やす可能性が徐々に高くなりました. そして、これらはメモリの問題が原因であると思われるため、spark で LDA のパフォーマンスを調整するにはどうすればよいか疑問に思います。

私は Google Cloud Dataproc で実行しているため、リソースは柔軟ですが、ここでパフォーマンスを最適化する最善の方法を知るには、Spark の LDA の内部を十分に理解していないことに気付きました。

これまでの私の試みは、次の行で行うことです。

ここでは、ドキュメントの RDD を 192 個のパーティションに再分割し (この例では、48 個のコアで spark を実行していたので、4*n_cores の経験則を使用しました)、それをキャッシュします。これは、たとえば、RDD でマップを繰り返し実行していた場合には妥当ですが、ここでのパフォーマンスに役立つかどうか、またはどのように役立つかはわかりません。ここで他に何ができますか？

回答を容易にするために、ここに私のコーパスの要約統計を示します。

• ドキュメント: 166,784
• 語彙数（固有用語数）：112,312
• 総トークン数: 4,430,237,213

おそらく、トークンの数が多いことがここでの主な問題であり、タスクごとのメモリを増やす必要があるだけです。つまり、使用可能なメモリを増やしてエグゼキュータの数を減らすことです。しかしもちろん、これは、Spark LDA が内部でどの程度正確に機能しているかによって異なります。たとえば、私の以前の質問hereを参照してください。

Cloud Dataproc API に対してプログラムでビルドしたいのですが、検出サービスが見つかりません。どこで見つけることができますか？

Dataproc Spark ジョブからの出力を Google Cloud ロギングに送信する方法はありますか? Dataproc ドキュメントで説明されているように、ジョブ ドライバ（Spark ジョブのマスター）からの出力は、コンソールの [Dataproc] -> [Jobs] で利用できます。Cloud Logging にもログが必要な理由は 2 つあります。

1. エグゼキューターからのログを見たいのですが。多くの場合、マスター ログには「エグゼキューターが失われました」と表示されますが、それ以上の詳細はありません。エグゼキューターが何をしようとしているのかについて、さらに情報があれば非常に便利です。
2. Cloud Logging は優れたフィルタリングと検索機能を備えています

現在、Cloud Logging に表示される Dataproc からの唯一の出力は、yarn-yarn-nodemanager-* と container_*.stderr からのログ項目です。私のアプリケーション コードからの出力は Dataproc -> Jobs に表示されますが、Cloud Logging には表示されません。これはエグゼキューターではなく、Spark マスターからの出力のみです。