次の方法で共有

HDInsight における Apache Spark クラスターの既知の問題

  • [アーティクル]

このドキュメントでは、HDInsight Spark パブリック プレビューのすべての既知の問題を追跡します。

Apache Livy が対話型セッションをリークする

対話型セッションがまだ有効な状態で Apache Livy が再起動されると (Apache Ambari から、またはヘッドノード 0 仮想マシンの再起動のため)、対話型ジョブ セッションがリークされます。 その結果、新しいジョブは、承諾済み状態で停止されます。

対応策:

この問題を回避するには、以下の手順を実行します。

  1. ヘッドノードに Ssh します。 詳細については、HDInsight での SSH の使用に関するページを参照してください。

  2. 次のコマンドを実行して、Livy を通じて開始された対話型ジョブのアプリケーション ID を調べます。

    yarn application –list

    明示的な名前が指定されていない Livy 対話型セッションでジョブが開始された場合、既定のジョブ名は Livy になります。 Jupyter Notebook によって開始された Livy セッションの場合、ジョブ名は remotesparkmagics_* で始まります。

  3. 次のコマンドを実行して、これらのジョブを強制終了します。

    yarn application –kill <Application ID>

新しいジョブの実行が開始されます。

Spark History Server が開始されない

クラスターの作成後、Spark History Server は自動的には開始されません。

対応策:

Ambari から履歴サーバーを手動で開始します。

Spark ログ ディレクトリでアクセス許可の問題が発生する

spark-submit を使用してジョブを送信するとき、hdiuser は次のエラーを取得します。

java.io.FileNotFoundException: /var/log/spark/sparkdriver_hdiuser.log (Permission denied)

また、ドライバー ログは書き込まれません。

対応策:

  1. hdiuser を Hadoop グループに追加します。
  2. クラスターの作成後、/var/log/spark に 777 アクセス許可を指定します。
  3. Ambari を使用して、Spark ログの場所を、777 アクセス許可を持つディレクトリに変更します。
  4. sudo として spark-submit を実行します。

Spark-Phoenix コネクタがサポートされない

HDInsight Spark クラスターは、Spark-Phoenix コネクターをサポートしていません。

対応策:

代わりに、Spark-HBase コネクタを使用する必要があります。 手順については、Spark-HBase コネクタの使用方法に関するページをご覧ください。

Jupyter Notebook に関連する既知の問題を以下に示します。

ファイル名での非 ASCII 文字の使用

Jupyter Notebook のファイル名に ASCII 以外の文字を使用しないでください。 ファイル名に ASCII 以外を含むファイルのアップロードを Jupyter UI 経由で試行すると、エラー メッセージが表示されないまま、エラーになります。 Jupyter を使ってファイルをアップロードすることはできませんが、表示可能なエラーもスローされません。

大きなサイズの Notebook の読み込み中のエラー

大きなサイズの Notebook の読み込み中にエラー Error loading notebook が発生する場合があります。

対応策:

このエラーが発生した場合、データが壊れたり失われたりしているわけではありません。 Notebook はディスク上の /var/lib/jupyterに残っているため、クラスターに SSH 接続し、Notebook にアクセスすることができます。 詳細については、HDInsight での SSH の使用に関するページを参照してください。

SSH を使用してクラスターに接続したら、バックアップとしてクラスターの Notebook をローカル コンピューター (SCP または WinSCP を使用) にコピーすることで、Notebook 内の重要なデータが失われるのを防ぐことができます。 ポート 8001 のヘッドノードへの SSH トンネルを使用すると、ゲートウェイを経由せずに Jupyter にアクセスできます。 そこでは、Notebook の出力をクリアしてからもう一度保存して、Notebook のサイズを最小限に縮小できます。

今後このエラーが発生しないようにするには、次のベスト プラクティスを実行する必要があります。

  • Notebook のサイズを小さく保つことが重要です。 Jupyter に返送される、Spark ジョブからの出力は Notebook に保持されます。 Jupyter でのベスト プラクティスは一般に次のとおりです。大規模な RDD またはデータフレームに対して .collect() を実行することは避けます。RDD の内容を参照する場合は、出力が大きくなりすぎないように .take() または .sample() の実行を検討します。
  • また、Notebook を保存する場合は、出力セルをすべてクリアしてサイズを縮小します。

Notebook の初期スタートアップに予想より時間がかかる

Spark マジックを使用した Jupyter Notebook の最初のコード ステートメントには、1 分以上かかる場合があります。

説明:

これは、最初のコード セルが実行されるタイミングのために発生します。 バック グラウンドで、これにより、セッション構成が開始され、Spark、SQL、および Hive コンテキストが設定されます。 これらのコンテキストが設定された後に、最初のステートメントが実行されるので、ステートメントの完了までに時間がかかるような印象を受けます。

Jupyter Notebook がセッションの作成中にタイムアウトする

Spark クラスターがリソース不足になると、Jupyter Notebook の Spark カーネルと PySpark カーネルは、セッションを作成する試行をタイムアウトにします。

対応策:

  1. 以下の方法で、Spark クラスターのリソースを解放します。

    • [閉じて停止] メニューに移動するか、Notebook エクスプローラーで [シャットダウン] をクリックして、他の Spark Notebook を停止する。
    • YARN から他の Spark アプリケーションを停止する。

  2. スタートアップしようとしていた Notebook を再起動します。 今度は、セッションを作成するために十分なリソースが使用可能になっている必要があります。

関連項目

シナリオ

アプリケーションの作成と実行

ツールと拡張機能

リソースの管理