(python) Spark .textFile (s3: // ...) Accès refusé 403 avec des informations d'identification valides

Question

Pour accéder à mon seau S3 j'ai exporté mes creds

export AWS_SECRET_ACCESS_KEY= 
export AWS_ACCESSS_ACCESS_KEY= 

je peux vérifier que tout fonctionne par faire

aws s3 ls mybucket 

Je peux aussi vérifier avec boto3 que cela fonctionne en python

resource = boto3.resource("s3", region_name="us-east-1") 
resource.Object("mybucket", "text/text.py") \ 
      .put(Body=open("text.py", "rb"),ContentType="text/x-py") 

Cela fonctionne et je peux voir la fi le dans le seau.

Cependant quand je fais cela avec étincelle:

spark_context = SparkContext() 
sql_context = SQLContext(spark_context) 
spark_context.textFile("s3://mybucket/my/path/*) 

je reçois une belle

> Caused by: org.jets3t.service.S3ServiceException: Service Error 
> Message. -- ResponseCode: 403, ResponseStatus: Forbidden, XML Error 
> Message: <?xml version="1.0" 
> encoding="UTF-8"?><Error><Code>InvalidAccessKeyId</Code><Message>The 
> AWS Access Key Id you provided does not exist in our 
> records.</Message><AWSAccessKeyId>[MY_ACCESS_KEY]</AWSAccessKeyId><RequestId>XXXXX</RequestId><HostId>xxxxxxx</HostId></Error> 

est ce que je soumets le travail localement

étincelle soumettre

--packages com. amazonaws: aws-java-sdk-pom: 1.11.98, org.apache.hadoop: hadoop-aws: 2.7.3 test.py

Pourquoi ça marche? s avec la ligne de commande + boto3 mais l'étincelle est choquante?

EDIT:

Même problème en utilisant s3a: // avec

hadoopConf = spark_context._jsc.hadoopConfiguration() 
hadoopConf.set("fs.s3a.access.key", "xxxx") 
hadoopConf.set("fs.s3a.secret.key", "xxxxxxx") 
hadoopConf.set("fs.s3a.impl", "org.apache.hadoop.fs.s3a.S3AFileSystem") 

et même problème en utilisant aws-sdk 1.7.4 et 2.7.2 Hadoop

Answer 1

Spark copie automatiquement vos AWS Credentials aux secrets s3n et s3a. Les versions d'Apache Spark ne touchent pas les URL s3: //, comme dans Apache Hadoop, le schéma s3: // est associé au client s3, désormais obsolète, incompatible avec tout le reste.

Sur Amazon EMR, s3: // est lié à Amazon EMR S3; EC2 VMs fournira les secrets pour les exécuteurs automatiquement. Donc, je ne pense pas que cela dérange avec le mécanisme de propagation env var. Il se peut aussi que la configuration de la chaîne d'authentification ne permette pas de surcharger les données EC2/IAM.

Si vous essayez de parler à S3 et vous ne fonctionne pas dans un DME VM, alors il est probable que vous utilisez Apache Spark avec Apache Hadoop, JARs pas les versions DME. Dans ce monde, utilisez les URL avec s3a: // pour obtenir la dernière bibliothèque client S3

Si cela ne fonctionne pas, consultez la section de dépannage de the apache docs. Il y a une section sur "403" là, y compris les étapes recommandées pour le dépannage. Cela peut être dû à des problèmes de version de chemin de classe/JVM, ainsi qu'à des problèmes d'informations d'identification, même un décalage d'horloge entre le client et AWS.