e
Тут еще риск. С hdfs + spark мы научились готовить. Minio + spark на прерываемых машинках - это новый опыт. Вот захотелось послушать опыт коллег
Size: a a a
2021 March 05
ЕГ
Да, все в одном облаке. Вот думаем еще x слабых машинок поднять или заморочится с прерываемыми + единый сторадж (hgfs, s3)
Смотря сколько объектов в хранилище и насколько они разнообразные - перетаскивать файлы несложно, перетаскивать партицированные таблицы посложнее, так как надо ещё метаданные воссоздавать каким-то образом
ПБ
Евгений Глотов
Смотря сколько объектов в хранилище и насколько они разнообразные - перетаскивать файлы несложно, перетаскивать партицированные таблицы посложнее, так как надо ещё метаданные воссоздавать каким-то образом
Это через спец тулзу делается или самопис. Аля hive заменитель?)
ЕГ
Это через спец тулзу делается или самопис. Аля hive заменитель?)
Тут ещё вопрос, накручивал ли кто-нибудь хайв над s3, или все просто обращаются к ФС
ЕГ
Хайв может экспортировать метаданные, но если таблицы созданы спарком, то есть риск потерять параметры, которые хайв не понимает
ЕГ
А если первый вариант - на отключаемые компьют ноды лучше всё-таки ДФС в принципе не заводить, иначе будут постоянные ненужные восстановления блоков
ПБ
Евгений Глотов
Хайв может экспортировать метаданные, но если таблицы созданы спарком, то есть риск потерять параметры, которые хайв не понимает
https://trino.io/docs/current/connector/hive-s3.html
Можно не экспортировать а просто подключить как external table
Можно не экспортировать а просто подключить как external table
ЕГ
https://trino.io/docs/current/connector/hive-s3.html
Можно не экспортировать а просто подключить как external table
Можно не экспортировать а просто подключить как external table
Тогда при добавлении новых партиций нужен будет процесс добавления метаданных в эти экстернал таблицы
ЕГ
Хотя в принципе не так сложно его вписать везде, где нужно
2021 March 06
K
смысла нет, hdfs не такой быстрый, чтобы ему нужен был ssd
Скорее потому что ориентирован на последовательную запись и чтение , где у ссд уже не такие преимущества
N
Скорее потому что ориентирован на последовательную запись и чтение , где у ссд уже не такие преимущества
Почему ? Ssd и в последовательной записи намного быстрее ,чем hdd. До 4гб /сек могут читать /писать , если NVMe.
N
Это может сам hdfs не умеет это использовать.
DT
если в тачках есть и hdd и ssd, иногда и для некоторых горячих данных оправданно использовать политики типа One_SSD или даже All_SSD, если они прям действительно горячие
e
https://habr.com/ru/company/otus/blog/529684/
—
Существует распространенное мнение, что в процессах обработки больших данных есть два основных узких места, влияющих на производительность:
перетасовка данных, поскольку для ее выполнения требуется отправлять данные по сети;
дисковый ввод-вывод, поскольку доступ к данным на диске всегда намного медленнее, чем доступ к данным в ОЗУ.
....
В 2015 году в исследовании Кей Остерхаут (Kay Ousterhout) и др.¹ были проанализированы узкие места в заданиях Spark, и в результате выяснилось, что скорость их выполнения в большей степени определяется операциями, загружающими ЦП, а не вводом-выводом и передачей данных по сети
—
—
Существует распространенное мнение, что в процессах обработки больших данных есть два основных узких места, влияющих на производительность:
перетасовка данных, поскольку для ее выполнения требуется отправлять данные по сети;
дисковый ввод-вывод, поскольку доступ к данным на диске всегда намного медленнее, чем доступ к данным в ОЗУ.
....
В 2015 году в исследовании Кей Остерхаут (Kay Ousterhout) и др.¹ были проанализированы узкие места в заданиях Spark, и в результате выяснилось, что скорость их выполнения в большей степени определяется операциями, загружающими ЦП, а не вводом-выводом и передачей данных по сети
—
K
https://habr.com/ru/company/otus/blog/529684/
—
Существует распространенное мнение, что в процессах обработки больших данных есть два основных узких места, влияющих на производительность:
перетасовка данных, поскольку для ее выполнения требуется отправлять данные по сети;
дисковый ввод-вывод, поскольку доступ к данным на диске всегда намного медленнее, чем доступ к данным в ОЗУ.
....
В 2015 году в исследовании Кей Остерхаут (Kay Ousterhout) и др.¹ были проанализированы узкие места в заданиях Spark, и в результате выяснилось, что скорость их выполнения в большей степени определяется операциями, загружающими ЦП, а не вводом-выводом и передачей данных по сети
—
—
Существует распространенное мнение, что в процессах обработки больших данных есть два основных узких места, влияющих на производительность:
перетасовка данных, поскольку для ее выполнения требуется отправлять данные по сети;
дисковый ввод-вывод, поскольку доступ к данным на диске всегда намного медленнее, чем доступ к данным в ОЗУ.
....
В 2015 году в исследовании Кей Остерхаут (Kay Ousterhout) и др.¹ были проанализированы узкие места в заданиях Spark, и в результате выяснилось, что скорость их выполнения в большей степени определяется операциями, загружающими ЦП, а не вводом-выводом и передачей данных по сети
—
в 2020 уже может быть другое
A
В тот момент насколько помню тангстена и кодогенерации ещё толком не было, только только подвозили
A
Project Tungsten: Bringing Apache Spark Closer to Bare Metal
A
Апрель 2015, то есть в проде почти у никого
ЕГ
чем с помощью ограниченного языка Spark SQL
ЕГ
