2017-10-09 1 views
0

J'ai écrit un programme Java qui est inclus dans le workflow oozie qui place les fichiers de HDFS dans le compartiment S3. Cependant, je reçois l'erreur suivanteAccès refusé lors de la mise en fichier de HDFS dans le compartiment S3

com.amazonaws.services.s3.model.AmazonS3Exception: Accès refusé (Service: Amazon S3; Code d'état: 403; Code d'erreur: AccessDenied; Demande ID: 310F08CD4FF8B5D9), S3 Demande prolongée ID: fAysD1vgtriV8x + sf1zqHk58eAT89Y6HD + ziEokaPvFPKwaPrHDxt5yygsiA1ktNVsyj + GTmbQ0 =

Je crée le chemin de clé dans le seau S3 dynamiquement dans le workflow de oozie.
Pour exemple: Si mon nom de fichier est abc_20171009.tsv.gz alors ce fichier doit être transféré au seau dans le chemin suivant

tsvFile/year=2017/month=10/day=09/abc_20171009.tsv.gz 

Dans la même manière d'autres fichiers de jour doivent être téléchargés en fonction de la date.
Ma question est de savoir si le chemin clé doit préexister dans le compartiment avant de télécharger les fichiers ou il peut être créé dynamiquement?

// Request server-side encryption.   

      BasicAWSCredentials awsCredentials = new BasicAWSCredentials(awsAccessKeyId, awsSecretKey); 
      AmazonS3Client s3Client = new AmazonS3Client(awsCredentials); 
      PutObjectRequest request = new PutObjectRequest("bucket_name", "key_name",""); 

      ObjectMetadata objectMetadata = new ObjectMetadata(); 
      objectMetadata.setSSEAlgorithm(ObjectMetadata.AES_256_SERVER_SIDE_ENCRYPTION); 

      request.setMetadata(objectMetadata); 

      PutObjectResult response = s3Client.putObject(request); 

      LOGGER.info("Server Side Encryption successful" +response.getSSEAlgorithm()); 

Note: Je suis en mesure de mettre manuellement le fichier et se connecter au seau S3 par AWS CLI.

Répondre

0

le serive S3 amazone ont une liste de caractères sûrs qui pourraient être utilisés pour S3 objet clé

caractères Safe Les jeux de caractères suivants sont généralement sans danger pour dans les noms clés: • Les caractères alphanumériques [0 -9a-zA-Z] • caractères spéciaux, -., _,, *, », (et)

cependant ce que je peux voir, vous utilisez =, qui d'autre part est un caractère spécial nécessitant une manipulation

caractères qui requièrent un traitement spécial Les caractères suivants dans un nom de clé peut nécessiter un traitement de code supplémentaire et auront probablement besoin URL encodé ou référencé HEX. Certains d'entre eux sont des caractères non-imprimables et votre navigateur ne peut les manipuler, ce qui également nécessiter un traitement spécial

et l'un de ces personnages est =

peut-être, lorsque vous téléchargez le fichier manuellement, le = est automatiquement codé. Donc, vous avez des options, supprimer les signes = ou les encoder (je voudrais aller avec les premières options)

+0

Pouvez-vous également confirmer si la clé de la clé (tsvFile/année = 2017/mois = 10/jour = 09 /) a besoin préexister avant de télécharger le fichier ou il peut être créé dynamiquement? – Shash

+0

lorsque vous téléchargez un fichier sur S3, vous ne créez aucun répertoire, ce que vous voyez sur l'interface Web est simplement une interprétation des clés d'objet (donc le fichier a/b/c.txt est juste un fichier sur le S3 , mais sur l'interface web, il est interprété comme des répertoires imbriqués). Revenons à votre question comme pour chaque fichier dans votre "répertoire" tsvFile/year = 2017/month = 10/day = 09/aura besoin d'avoir des signes "=", car il n'y a pas de répertoire "préexistant" – pezetem

+0

est le problème auquel je suis actuellement confronté - Causé par: com.amazonaws.services.s3.model.AmazonS3Exception: l'en-tête de chiffrement x-amz-server-side n'est pas pris en charge pour cette opération. (Service: Amazon S3, Code d'état: 400, Code d'erreur: InvalidArgument, ID de demande: A4563A21BFA23BCE), S3 ID de demande étendue: HoAo1ia5jOO3zuNsBzOspmB5b + ZG9YQHgCuFvJnrd0iGEGegCpUoqMf7VWybOj0Np0KVjk5ovm8 = – Shash