Hadoop DistCp: konfigurimi i përfaqësuesit S3A në detyrat e punëtorëve

Për lidhësin S3A të Hadoop 3.4.2 përmes një përfaqësuesi HTTP, bashkoni këto zëra në konfigurimin Hadoop të operacionit, zakonisht core-site.xml përkatës:

<property>
  <name>fs.s3a.proxy.host</name>
  <value>gateway.example</value>
</property>
<property>
  <name>fs.s3a.proxy.port</name>
  <value>8080</value>
</property>
<property>
  <name>fs.s3a.proxy.ssl.enabled</name>
  <value>false</value>
</property>

Për një provë të autorizuar në mënyrë të pavarur kundër një pikëmbërritjeje S3 të aksesueshme publikisht pa kredenciale përfaqësuesi, lista e përfaqësuesve HTTP ofron vlera kandidate për emrin e pritësit dhe portën eksplicite. fs.s3a.proxy.ssl.enabled=false zgjedh një lidhje të thjeshtë HTTP me këtë përfaqësues; ai nuk çaktivizon TLS nga S3A në S3. Përdorni vlerën që përputhet me dëgjuesin real të përfaqësuesit.

Kontrolloni të dy konsumatorët. Klienti që dërgon mund të listojë S3 me sukses, ndërsa kontejnerët e detyrave map të DistCp nuk arrijnë dot përfaqësuesin ose nuk ngarkojnë të njëjtin konfigurim të sistemit të skedarëve. Janë pikërisht ato detyra që kryejnë transferimet.

Për një detyrë të dështuar, ruani pritësin e ekzekutimit, konfigurimin efektiv dhe pikëmbërritjen e zgjedhur së bashku me gabimin. Mjedisi i shell-it të dërgimit nuk është provë e mjaftueshme për një punëtor.

Këto cilësime rregullojnë s3a://. Recetat e vjetra të lidhësit Jets3t konfigurojnë një implementim tjetër dhe nuk zëvendësojnë opsionet S3A që përdor kjo punë.