コマンドが内部バックエンドh2o.H2OFrame([1,2,3])
の h2o 内でフレームを作成しているが、外部バックエンドでは作成していないという問題が発生しています。代わりに、接続は終了していません (フレームは作成されていますが、プロセスはハングします)。
への投稿/3/ParseSetup
が返されていないurllib3
ように見えます (行き詰まっているようです)。より具体的には、外部バックエンドへの接続の h2o ログから、これの例を示します (ここでは日付と IP を短縮しています)。
* 10.*.*.15:56565 8120 #7003-141 INFO: Reading byte InputStream into Frame:
* 10.*.*.15:56565 8120 #7003-141 INFO: frameKey: upload_8a440dcf457c1e5deacf76a7ac1a4955
* 10.*.*.15:56565 8120 #7003-141 DEBUG: write-lock upload_8a440dcf457c1e5deacf76a7ac1a4955 by job null
* 10.*.*.15:56565 8120 #7003-141 INFO: totalChunks: 1
* 10.*.*.15:56565 8120 #7003-141 INFO: totalBytes: 21
* 10.*.*.15:56565 8120 #7003-141 DEBUG: unlock upload_8a440dcf457c1e5deacf76a7ac1a4955 by job null
* 10.*.*.15:56565 8120 #7003-141 INFO: Success.
* 10.*.*.15:56565 8120 #7003-135 INFO: POST /3/ParseSetup, parms: {source_frames=["upload_8a440dcf457c1e5deacf76a7ac1a4955"], check_header=1, separator=44}
比較すると、内部バックエンドはその呼び出しを完了し、ログ ファイルには次のものが含まれます。
** 10.*.*.15:54444 2421 #0581-148 INFO: totalBytes: 21
** 10.*.*.15:54444 2421 #0581-148 INFO: Success.
** 10.*.*.15:54444 2421 #0581-149 INFO: POST /3/ParseSetup, parms: {source_frames=["upload_b985730020211f576ef75143ce0e43f2"], check_header=1, separator=44}
** 10.*.*.15:54444 2421 #0581-150 INFO: POST /3/Parse, parms: {number_columns=1, source_frames=["upload_b985730020211f576ef75143ce0e43f2"], column_types=["Numeric"], single_quotes=False, parse_type=CSV, destination_frame=Key_Frame__upload_b985730020211f576ef75143ce0e43f2.hex, column_names=["C1"], delete_on_done=True, check_header=1, separator=44, blocking=False, chunk_size=4194304}
...
発生するロックに違いはありby job null
ますが解除されているので、致命的な問題ではないと思います。私は両方のバックエンドでそのエンドポイントのカールに失敗しました。原因を特定するためにソース コードを確認しています。
h2o.ls()
プロセスがハングアップしているにもかかわらず、アップロードされたフレームが実行されていることを確認できh2o.get_frame(frame_id="myframe_id")
、外部バックエンドを使用してフレームを取得できます。
私は次のことを試しました/確認しました:
- Spark のバージョンに対してスパークリング ウォーターのバージョンが正しいことを確認しました (つまり、h2o_pysparkling_2.3 - Spark 2.3.xの場合、 docs.h2o.aiに記載されています--- 私の場合、スパークリング ウォーター 2.3.12 - Spark 2.3. 0.cloudera2);
- クラスターに安定したスパークリングウォーターをダウンロードして実行し
./get-extended-h2o.sh cdh5.14
、h2odriver-sw2.3.0-cdh5.14-extended.jar
jar を取得しました。 - map reduce ジョブのパラメーターのさまざまな順列。興味深いことに、私たちのクラスターは非常にビジーであり、安定性のためにベース ポートの設定が不可欠でした。また、私たちのサブネットは、マルチキャストを台無しにするスイッチにまたがっています。最終的に、次の引数は必ずバックエンドを起動しました:
hadoop jar h2odriver-sw2.3.0-cdh5.14-extended.jar -Dmapreduce.job.queuename=root.users.myuser -jobname extback -baseport 56565 -nodes 10 -mapperXmx 10g -network 10.*.*.0/24
- 動作しているため、バックエンドにクエリを実行できることを確認しました
h2o.ls()
。 - プレーン リストの代わりに Spark データフレームをアップロードしました (同じ問題):
sdf = session.createDataFrame([
('a', 1, 1.0), ('b', 2, 2.0)],
schema=StructType([StructField("string", StringType()),
StructField("int", IntegerType()),
StructField("float", FloatType())]))
hc.as_h2o_frame(sdf)
YARN の観点から、単純なテスト アプリのクライアント モードとクラスター モードの送信を試みました。
spark2-submit --master yarn --deploy-mode cluster --queue root.users.myuser --conf 'spark.ext.h2o.client.port.base=65656' extreboot.py
デフォルトのクライアント モードの場合--master yarn
となしの場合があります。--deploy-mode cluster
最後に、extreboot.py
コードは次のとおりです。
from pyspark.conf import SparkConf
from pyspark.sql import SparkSession
from pysparkling import *
import h2o
conf = SparkConf().setAll([
('spark.ext.h2o.client.verbose', True),
('spark.ext.h2o.client.log.level', 'DEBUG'),
('spark.ext.h2o.node.log.level', 'DEBUG'),
('spark.ext.h2o.client.port.base', '56565'),
('spark.driver.memory','8g'),
('spark.ext.h2o.backend.cluster.mode', 'external')])
session = SparkSession.builder.config(conf=conf).getOrCreate()
ip_addr='10.10.10.10'
port=56565
conf = H2OConf(session).set_external_cluster_mode().use_manual_cluster_start().set_h2o_cluster(ip_addr, port).set_cloud_name("extback")
hc = H2OContext.getOrCreate(session, conf)
print(h2o.ls())
h2o.H2OFrame([1,2,3])
print('DONE')
(内部バックエンドと比較して)ハングしている可能性がある理由、私が間違っていること、またはこれをより適切にデバッグするためにどの手順を実行できるかを誰かが知っていますか? ありがとう!