ImageV1.0.0でDataProc Avroバージョンの原因となるエラー

dataproc image 1.0とspark-redshiftのdataprocジョブを実行しています。ImageV1.0.0でDataProc Avroバージョンの原因となるエラー

ここでは、二つのクラスタを持っているいくつかの詳細は、次のとおりです。

クラスタA - 最後2016. Jul 15. 11:27:12 AEST
クラスタB作成>がPySparkストリーミングジョブを実行し、 - > PySparkのバッチジョブを実行し、クラスタが毎回作成されますジョブは実行され、後でティアダウンされます。
& Bは同じコードベース、使用するのと同じのinitスクリプト、同じノードの種類などを実行しますいつか先週の金曜日（2016-08-05 AEST）、我々のコードは次のようにクラスタBに動作を停止するので

クラスタAは問題なく実行されています。それは、クラスタAの細かいを実行している間

次のコードでは、クラスタB上の問題（または画像v1.0.0デベロッパーとの任意の新しいクラスタ）を再生することができます

サンプルPySparkコード：

from pyspark import SparkContext, SQLContext 
sc = SparkContext() 
sql_context = SQLContext(sc) 

rdd = sc.parallelize([{'user_id': 'test'}]) 
df = rdd.toDF() 

sc._jsc.hadoopConfiguration().set("fs.s3n.awsAccessKeyId", "FOO") 
sc._jsc.hadoopConfiguration().set("fs.s3n.awsSecretAccessKey", "BAR") 

df\ 
    .write\ 
    .format("com.databricks.spark.redshift") \ 
    .option("url", "jdbc:redshift://foo.ap-southeast-2.redshift.amazonaws.com/bar") \ 
    .option("dbtable", 'foo') \ 
    .option("tempdir", "s3n://bar") \ 
    .option("extracopyoptions", "TRUNCATECOLUMNS") \ 
    .mode("append") \ 
    .save()

上記のコードは、クラスタBで、をで実行している間、次の両方の状況で失敗します。RedshiftJDBC41-1.1.10.1010.jarはクラスタ初期化スクリプトを使用して作成されています。

マスターノード上で対話モードで実行：

PYSPARK_DRIVER_PYTHON=ipython pyspark \ 
    --verbose \ 
    --master "local[*]"\ 
    --jars /usr/lib/hadoop/lib/RedshiftJDBC41-1.1.10.1010.jar \ 
    --packages com.databricks:spark-redshift_2.10:1.0.0

がgcloud dataproc

gcloud --project foo \ 
    dataproc jobs submit pyspark \ 
    --cluster bar \ 
    --properties ^#^spark.jars.packages=com.databricks:spark-redshift_2.10:1.0.0#spark.jars=/usr/lib/hadoop/lib/RedshiftJDBC41-1.1.10.1010.jar \ 
    foo.bar.py

それが生成するエラー（Trace）を経由してジョブをサブミットします：を

2016-08-08 06:12:23 WARN TaskSetManager:70 - Lost task 6.0 in stage 45.0 (TID 121275, foo.bar.internal): 
    java.lang.NoSuchMethodError: org.apache.avro.generic.GenericData.createDatumWriter(Lorg/apache/avro/Schema;)Lorg/apache/avro/io/DatumWriter; 
    at org.apache.avro.mapreduce.AvroKeyRecordWriter.<init>(AvroKeyRecordWriter.java:55) 
    at org.apache.avro.mapreduce.AvroKeyOutputFormat$RecordWriterFactory.create(AvroKeyOutputFormat.java:79) 
    at org.apache.avro.mapreduce.AvroKeyOutputFormat.getRecordWriter(AvroKeyOutputFormat.java:105) 
    at com.databricks.spark.avro.AvroOutputWriter.<init>(AvroOutputWriter.scala:82) 
    at com.databricks.spark.avro.AvroOutputWriterFactory.newInstance(AvroOutputWriterFactory.scala:31) 
    at org.apache.spark.sql.execution.datasources.BaseWriterContainer.newOutputWriter(WriterContainer.scala:129) 
    at org.apache.spark.sql.execution.datasources.DefaultWriterContainer.writeRows(WriterContainer.scala:255) 
    at org.apache.spark.sql.execution.datasources.InsertIntoHadoopFsRelation$$anonfun$run$1$$anonfun$apply$mcV$sp$3.apply(InsertIntoHadoopFsRelation.scala:148) 
    at org.apache.spark.sql.execution.datasources.InsertIntoHadoopFsRelation$$anonfun$run$1$$anonfun$apply$mcV$sp$3.apply(InsertIntoHadoopFsRelation.scala:148) 
    at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66) 
    at org.apache.spark.scheduler.Task.run(Task.scala:89) 
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:227) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
    at java.lang.Thread.run(Thread.java:745) 

2016-08-08 06:12:24 ERROR YarnScheduler:74 - Lost executor 63 on kinesis-ma-sw-o7he.c.bupa-ma.internal: Container marked as failed: container_1470632577663_0003_01_000065 on host: kinesis-ma-sw-o7he.c.bupa-ma.internal. Exit status: 50. Diagnostics: Exception from container-launch. 
Container id: container_1470632577663_0003_01_000065 
Exit code: 50 
Stack trace: ExitCodeException exitCode=50: 
    at org.apache.hadoop.util.Shell.runCommand(Shell.java:545) 
    at org.apache.hadoop.util.Shell.run(Shell.java:456) 
    at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:722) 
    at org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.launchContainer(DefaultContainerExecutor.java:212) 
    at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:302) 
    at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:82) 
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
    at java.lang.Thread.run(Thread.java:745)

SparkRedshift：1.0.0 org.apache.avro:1.7.6を必要とする、com.databricks.spark-avro:2.0.1が必要です。クラスタAにorg.apache.avro.generic.GenericDataのバージョンを確認すると

：

[email protected]:/home/foo# spark-shell \ 
>  --verbose \ 
>  --master "local[*]" \ 
>  --deploy-mode client \ 
>  --packages com.databricks:spark-redshift_2.10:1.0.0 \ 
>  --jars "/usr/lib/hadoop/lib/RedshiftJDBC41-1.1.10.1010.jar"

それは（Trace）生成：

scala> import org.apache.avro.generic._ 
import org.apache.avro.generic._ 

scala> val c = GenericData.get() 
c: org.apache.avro.generic.GenericData = [email protected] 

scala> c.getClass.getProtectionDomain().getCodeSource() 
res0: java.security.CodeSource = (file:/usr/lib/hadoop/lib/bigquery-connector-0.7.5-hadoop2.jar <no signer certificates>)

クラスタBに同じコマンドを実行中：

scala> import org.apache.avro.generic._ 
import org.apache.avro.generic._ 

scala> val c = GenericData.get() 
c: org.apache.avro.generic.GenericData = [email protected] 

scala> c.getClass.getProtectionDomain().getCodeSource() 
res0: java.security.CodeSource = (file:/usr/lib/hadoop/lib/bigquery-connector-0.7.7-hadoop2.jar <no signer certificates>)

012クラスタB上の Screenshot of Env（すべての改ざんの謝罪）。 hereと hereに記載されている方法を試しましたが、何の成功もありませんでした。

DataProcが画像コンテンツをの不変のリリースと完全に反対にすることなく更新するので、これは本当に不愉快です。今度はコードが壊れてしまい、以前のバージョンに戻すことはできません。

出典

2016-08-08 Paul Liang

申し訳ありません！それは確かにイメージバージョン内で発生する変更を破るためのものではありません。 Subminorのバージョンは、「徹底的に」展開され、バグのないバグやDataproc固有のパッチがあることに注意してください。

あなたが1.0を使用してに戻すことができます*コマンドラインからのクラスタ展開する際に、単に--image-version 1.0.8を指定することで、先週の前からバージョン：

gcloud dataproc clusters create --image-version 1.0.8

編集：追加の明確化のために、私たちが調査してきたアブロをAvroのバージョン番号が実際にではないことを確認しました。最新のDataprocリリースではに変更されていません。コアとなる問題は、Hadoop自身がHadoop自身でavro-1.7.4を/usr/lib/hadoop/lib/の下にもたらし、Sparkがavro-1.7.7を使用する潜在的なバグがあることです。偶然にも、Googleのbigquery接続もavro-1.7.7を使用していますが、これは既知のSpark/Hadoop problem with 1.7.4 vs 1.7.7と直交することが判明しています。最近の画像の更新は、バージョンが実際には変更されていないため、改訂されていませんでしたが、クラスローディングの順序は、Hadoopの悪いavroバージョンがSparkジョブから隠されていて、。

Dataprocのpreviewイメージには現在、Hadoopレイヤのavroバージョンの修正が含まれています。これは、将来のDataproc 1.1バージョンになるはずです。 previewバージョンを試して、Spark 2.0がシームレスに移行しているかどうかを確認することをおすすめします。

出典

2016-08-08 15:24:21

詳細な説明をお寄せいただきありがとうございます。バージョン1.0.8とプレビューの両方が正常に動作することがテストされています。この質問は、クラスパスのロードオーダーの問題に関して、文脈から少し外れている可能性があります。私たちは 'spark.driver.userClassPathFirst'と' spark.executor.userClassPathFirst'で試してみたところ、動作しませんでした。あなたはそれについて洞察を持っているかどうか疑問に思いますか？ありがとう。 –

残念ながら、私は 'spark.driver.userClassPathFirst'で遊ぶ機会があまりありませんでした。もし私が推測しなければならないのは、主に厳密な依存関係を直接束ねるuber-jarを提出することであると思われます。 '--packages'で参照されている依存関係が特殊なクラスローダ設定の恩恵を受けていない場合は驚きません。 –

ありがとうございます。今ははるかに明確です。 –

ImageV1.0.0でDataProc Avroバージョンの原因となるエラー

答えて

関連する問題