NoSuchMethodError StorageObject.getTimeCreated laufender Job in Dataproc

Question

Ich versuche, einen Spark-Job auszuführen, der in lokalen funktioniert. Es nutzt Google Storage. Ich erhalte diese Fehlermeldung:

Exception in thread "main" java.lang.NoSuchMethodError: com.google.api.services.storage.model.StorageObject.getTimeCreated()Lcom/google/api/client/util/DateTime; 
    at com.google.cloud.storage.BlobInfo.fromPb(BlobInfo.java:798) 
    at com.google.cloud.storage.Blob.fromPb(Blob.java:641) 
    at com.google.cloud.storage.StorageImpl.create(StorageImpl.java:139) 
    at com.google.cloud.storage.StorageImpl.create(StorageImpl.java:132) 
... 

Dataproc Job ist gcloud-java-storage-0.2.8.jar verwenden, und ich habe beide google-api-services-storage-v1-rev62-1.21.0.jar und google-api-services-storage-v1-rev83-1.22.0.jar ohne Erfolg versucht, auch wenn das Verfahren definiert ist. Es sieht so aus, als ob es nicht die richtige Version von Google-API-Services-Speicher verwendet, aber ich weiß nicht, was ich über das Hochladen und Spezifizieren des Jar hinaus tun kann.

Gibt es etwas, das ich vermisse?

Answer 1

Es sieht aus wie das Problem ist, dass der GCS-Stecker in Dataproc derzeit compiles against an oldergoogle-api-services-storage-v1 Version eingebaut ist. Die Methode com.google.api.services.storage.model.StorageObject.getTimeCreated() wurde erst in einer späteren Version hinzugefügt. Wenn die ältere Version im Klassenpfad gewinnt, wird der Fehler angezeigt. Wir werden die Version in naher Zukunft wahrscheinlich aktualisieren, nachdem wir die vollständige Abwärtskompatibilität überprüft haben.

In der Zwischenzeit können Sie entweder versuchen, die com.google.api.services.storage.* Pakete mit der Schatten-Plugin in Ihrem eigenen fatjar, auf die gleiche Weise des GCS-Anschluss verursacht Kollisionen Classpath repackages com.google.common.* zu vermeiden, neu zu verpacken mit Benutzern, ihre eigenen Guava Versionen zu bringen, oder Sie können versuchen, die GCS Stecker selbst neu zu kompilieren und es in Ihren Dataproc Cluster tauscht eine init-Aktion mit (Sie im Grunde/alles kopieren einfügen wörtlich hier außer der ersten Zeile, wo Sie brauchen einen GCS Eimer liefern):

export GCS_BUCKET=[SOME BUCKET YOU OWN HERE WITHOUT gs:// PREFIX] 


# Clone the code, update the dependency, build it 
git clone https://github.com/GoogleCloudPlatform/bigdata-interop.git 
cd bigdata-interop 
sed -i "s/v1-rev35/v1-rev83/" pom.xml 
mvn -P hadoop2 package 


# Upload the new GCS connector to GCS 
gsutil cp gcs/target/gcs-connector-1.5.3-hadoop2-SNAPSHOT-shaded.jar gs://${GCS_BUCKET}/gcs-connector-1.5.3-hadoop2-SNAPSHOT-shaded.jar 


# Create a quick init action 
cat <<EOF> install_new_gcs.sh 

#!/bin/bash 
rm /usr/lib/hadoop/lib/gcs-connector-*.jar 
gsutil cp gs://${GCS_BUCKET}/gcs-connector-1.5.3-hadoop2-SNAPSHOT-shaded.jar \ 
    /usr/lib/hadoop/lib/ 
chmod 644 /usr/lib/hadoop/lib/gcs-connector-*.jar 

EOF 
gsutil cp install_new_gcs.sh gs://${GCS_BUCKET}/install_new_gcs.sh 


# Create your dataproc cluster 
gcloud dataproc clusters create ${USER}-new-connector \ 
    --initialization-actions gs://${GCS_BUCKET}/install_new_gcs.sh 

übrigens Da die Ursache hier eine Kollision zwischen dem automatisch installierten GCS-Connector für Hadoop und Ihren eigenen GCS-Bibliotheken ist, können Sie w Am besten verwenden Sie Hadoop FileSystem Schnittstellen in Ihrem Code stattdessen; In Dataproc wird dies so konfiguriert, dass überall wo Sie eine Path übergeben, Sie einen Pfad des Formulars gs://bucket/foo/bar verwenden können, und es wird automatisch die GCS-Connector-Bibliotheken laden, um einfach zu funktionieren. Ihr Code würde etwa so aussehen:

Answer 2

Ich lief das gleiche Problem mit 1.0 Image-Version von Dataproc. Ich löste es durch die folgenden in meinem Cluster init Aktion hinzufügen:

#!/bin/bash 

rm /usr/lib/hadoop/lib/bigquery-connector-0.10.1-hadoop2.jar 
rm /usr/lib/hadoop/lib/gcs-connector-1.6.0-hadoop2.jar 

rm /usr/lib/hadoop/lib/guava-11.0.2.jar 
gsutil cp gs://my-bucket/jars/guava-18.0.jar /usr/lib/hadoop/lib/ 

Außerdem habe ich meine Spark-Anwendung Glas als Fett Glas gebaut, mit der folgenden Maven-Konfiguration:

<dependency> 
     <groupId>com.google.apis</groupId> 
     <artifactId>google-api-services-storage</artifactId> 
     <version>v1-rev97-1.22.0</version> 
    </dependency> 
    <dependency> 
     <groupId>com.google.cloud.bigdataoss</groupId> 
     <artifactId>gcs-connector</artifactId> 
     <version>1.6.0-hadoop2</version> 
    </dependency>