Безопасно ли использовать гибрид стабильных узлов с упреждающими узлами для снижения затрат?
Это абсолютно нормально.Мы использовали это на кластерах с 300+ узлами, только проблемы были с длительно работающими кластерами, когда узлы становились приоритетными, а задания не были оптимизированы для учета восстановления узлов (без репликации RDD, огромных длительных DAG).Кроме того, Tez не любит, когда вытесняемые узлы возвращаются.
Применимо ли это к кластеру dataroc или требуется что-то еще?
Исправить.Однако драйвер Google Storage имеет разные характеристики, когда речь идет о задержке работы (например, FileOutputCommitter может занять огромное количество времени при попытке сделать рекурсивное перемещение или удаление с перерезанным выводом) и использование памяти (буфер записи составляет 64 МБ против 4 КБ наHDFS).
Какой тип экземпляра лучше всего подходит для кластера dataproc, когда мы обрабатываем данные в формате avro размером около 150 ГБ.
В этом могут помочь только тесты производительности.
Я попытался кэшировать / сохранить данные на фрейме spark для оптимизации времени.Но это было не так полезно.Есть ли способ указать искре, что все ресурсы (память, вычислительная мощность) принадлежат этой работе, чтобы она могла обрабатывать ее быстрее?
Убедитесь, что используется динамическое распределение, и размер кластера соответствует вашимнагрузка.Вкладка «Планирование» в пользовательском интерфейсе YARN должна отображать коэффициент использования, близкий к 100% (в противном случае ваш кластер слишком велик для работы или у вас недостаточно разделов).В пользовательском интерфейсе Spark лучше, чтобы число выполняемых задач было близко к числу ядер (в противном случае может быть недостаточно разделов или кластер увеличен).
Выполняет чтение и запись в корзину GCSесть успех производительности?Если да, есть ли способ оптимизировать его?
С точки зрения пропускной способности, GCS неплохо, но гораздо хуже в случае большого количества маленьких файлов, как от чтения (при расчете разбиения), так и отзапись (когда FileOutputCommitter) перспектива.Также много параллельных записей могут привести к OOM из-за большего размера буфера записи.