Вопросы Теги

S3 параллельное чтение и запись производительности?

Это WORKS ..

Помните, что в первый раз, когда вы напечатаете передаваемое значение, вы получите нуль, вы можете использовать его после загрузки Windows, то же самое для всего, что вы хотите кодировать для любого другого компонента.

Первый контроллер 

try {
                                Stage st = new Stage();
                                 FXMLLoader loader = new FXMLLoader(getClass().getResource("/com/inty360/free/form/MainOnline.fxml"));

                                Parent sceneMain = loader.load();

                                MainOnlineController controller = loader.<MainOnlineController>getController();
                                controller.initVariable(99L);

                                Scene scene = new Scene(sceneMain);
                                st.setScene(scene);
                                st.setMaximized(true);
                                st.setTitle("My App");
                                st.show();
                            } catch (IOException ex) {
                                Logger.getLogger(LoginController.class.getName()).log(Level.SEVERE, null, ex);
                            }

Другой контроллер 

public void initVariable(Long id_usuario){
        this.id_usuario = id_usuario;
        label_usuario_nombre.setText(id_usuario.toString());

    }
2
задан rogue-one 15 January 2019 в 19:02
поделиться

1 ответ

Да, S3 медленнее, чем HDFS. но интересно посмотреть, почему и как перенести воздействие. Ключевой момент: если вы читаете намного больше данных, чем пишете, тогда производительность чтения имеет решающее значение; разъем S3A в Hadoop 2.8+ действительно помогает, так как он был настроен для чтения файлов Parquet / ORC на основе следов реальных тестов. Производительность записи также страдает, и чем больше данных вы генерируете, тем хуже становится. Люди жалуются на это, когда им действительно нужно беспокоиться о том, что без особых усилий вы можете на самом деле получить неверный результат. Как правило, это более важная проблема - просто менее очевидная.

Производительность чтения

Чтение с S3 страдает из-за

  • пропускной способности между S3 и вашей виртуальной машиной. Чем больше вы платите за виртуальную машину EC2, тем большую пропускную способность сети вы получаете, тем лучше
  • задержка запросов HEAD / GET / LIST, особенно все те, которые используются в работе, чтобы хранилище объектов выглядело как файловая система с каталоги. Это может особенно повредить фазе разделения запроса, когда перечислены все исходные файлы и идентифицированы те, которые нужно прочитать на самом деле.
  • Стоимость seek() ужасна, если HTTP-соединение для чтения прервано, а новое перезаключено. Без разъема, который оптимизировал поиск () для этого, ввод ORC и Parquet сильно страдает. разъем s3a в Hadoop 2.8+ делает именно это, если вы установите fs.s3a.experimental.fadvise в random.

Spark разделит работу над файлом, если формат разделяемый, и любой формат сжатия также можно разделить (gz нет, snappy есть). Это будет сделано с размером блока, который вы можете настроить / настроить для конкретной работы (fs.s3a.block.size). Если> 1 клиент читает тот же файл, то да, вы получаете некоторую перегрузку дискового ввода-вывода в этот файл, но обычно его минор по сравнению с остальными. Один маленький секрет: для загружаемых файлов, состоящих из нескольких частей, чтение отдельных частей, по-видимому, этого не позволяет, поэтому загружайте и скачивайте с тем же настроенным размером блока.

Производительность записи

Производительность записи страдает от

  • кэширования некоторых / многих МБ данных в блоках перед загрузкой, при этом загрузка не начинается, пока запись не будет завершена. S3A для hadoop 2.8+: установлено fs.s3a.fast.upload = true.
  • Пропускная способность загрузки по сети, опять же, функция типа виртуальной машины, за которую вы платите.

Фиксация производительности и правильности

Когда вывод фиксируется с помощью rename () файлов, записанных во временную папку, время для копирования каждого объекта в его окончательный путь составляет 6-10 МБ / с. .

Еще большая проблема заключается в том, что он очень плохо справляется с непоследовательными списками каталогов или сбоями задач в процессе фиксации. Вы не можете безопасно использовать S3 как прямое назначение работы с обычным алгоритмом переименования при фиксации без чего-либо, что могло бы дать вам согласованное представление о хранилище (согласие emrfs, s3mper, s3guard).

Для максимальной производительности и безопасного совершения работы вам необходим выходной коммиттер, оптимизированный для S3. У блоков данных есть свои особенности, в Apache Hadoop 3.1 добавлен «коммиттер вывода S3A». У EMR теперь, видимо, тоже кое-что есть.

Подробнее об этой проблеме см. Коммиттер с нулевым переименованием . После этого, надеюсь, вы либо перейдете к безопасному механизму фиксации, либо будете использовать HDFS в качестве места назначения работы.

0
ответ дан Steve Loughran 15 January 2019 в 19:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: