【问题标题】:DataProc Avro Version Causing Error on Image v1.0.0DataProc Avro 版本导致图像 v1.0.0 错误
【发布时间】:2016-08-08 13:52:31
【问题描述】:

我们正在使用dataproc image 1.0 和spark-redshift 运行一些数据处理作业。

我们有两个集群,这里有一些细节:

  • Cluster A -> 运行 PySpark Streaming 作业,上次创建 2016. Jul 15. 11:27:12 AEST
  • Cluster B -> 运行 PySpark Ba​​tch 作业,每次运行作业时都会创建集群并在之后拆除。
  • A & B 运行相同的代码库,使用相同的初始化脚本,相同的节点类型等。

从上周五的某个时间 (2016-08-05 AEST) 开始,我们的代码停止在集群 B 上运行,并出现以下错误,而集群 A 运行时没有出现问题。

以下代码可以在集群 B(或任何具有映像 v1.0.0 的新集群)上重现该问题,同时它在集群 A 上运行正常。

示例 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上的以下两种情况下都失败,而在A上运行fine。注意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 需要com.databricks.spark-avro:2.0.1,后者需要org.apache.avro:1.7.6。

在检查集群 A 上 org.apache.avro.generic.GenericData 的版本时:

root@foo-bar-m:/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 = org.apache.avro.generic.GenericData@496a514f

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 = org.apache.avro.generic.GenericData@72bec302

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

Screenshot of Env 在集群 B 上。(对所有编辑表示歉意)。 我们已经尝试了here 和here 上描述的方法,但没有任何成功。

这确实令人沮丧,因为 DataProc 更新图像内容没有将发布版本与不可变版本完全相反。现在我们的代码已经损坏,我们无法回滚到以前的版本。

【问题讨论】:

    标签: apache-spark google-cloud-platform google-cloud-dataproc


    【解决方案1】:

    抱歉给您添麻烦了!它当然不是为了在映像版本中发生重大更改。请注意,次要版本是在“幕后”推出的,用于非破坏性错误修复和 Dataproc 特定补丁。

    从命令行部署集群时,只需指定--image-version 1.0.8,即可恢复使用上周之前的 1.0.* 版本:

    gcloud dataproc clusters create --image-version 1.0.8
    

    编辑:为了进一步澄清,我们调查了有问题的 Avro 版本,并验证了 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 是否是一个无缝过渡。

    【讨论】:

    • 谢谢你的详细解释,现在清楚多了。版本 1.0.8 和预览版都经过测试可以正常工作。这个问题可能有点断章取义,关于类路径加载顺序问题,我们尝试了spark.driver.userClassPathFirst 和spark.executor.userClassPathFirst,但它们不起作用。只是想知道你是否对此有任何见解?谢谢。
    • 不幸的是,我没有太多机会玩spark.driver.userClassPathFirst;如果我不得不猜测,我怀疑它主要用于提交直接捆绑精确依赖项的 uber-jars,如果 --packages 中引用的依赖项没有从特殊的类加载器设置中受益,我不会感到惊讶。跨度>
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-01-03
    • 1970-01-01
    • 2022-07-11
    • 1970-01-01
    • 2021-11-11
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多