Для коннектора S3A Hadoop 3.4.2 через HTTP-прокси добавьте эти записи в конфигурацию Hadoop операции, обычно в соответствующий core-site.xml:

<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>

Для отдельно разрешённой проверки публично доступной конечной точки S3 без учётных данных прокси список HTTP-прокси предлагает варианты значений для имени хоста и явного порта. fs.s3a.proxy.ssl.enabled=false выбирает обычное HTTP-соединение с этим прокси; он не отключает TLS между S3A и S3. Используйте значение, соответствующее фактическому слушателю прокси.

Проверьте обоих потребителей. Клиент, выполняющий отправку, может успешно вывести список S3, тогда как контейнеры map-задач DistCp не могут достучаться до прокси или загрузить ту же конфигурацию файловой системы. Именно эти задачи выполняют передачу.

Для неудачной задачи сохраните хост выполнения, действующую конфигурацию и выбранную конечную точку вместе с ошибкой. Окружение оболочки отправки не является достаточным доказательством для рабочего узла.

Эти параметры управляют s3a://. Старые рецепты коннектора Jets3t настраивают другую реализацию и не заменяют параметры S3A, используемые этой задачей.

Похожие статьи