честно сказать понятнее не стало от 2 ссылки. Понял, что zorder позволяет делать фильтрацию по нескольким колонкам, но тоже самое могут и блум фильтры. Делается ли repartition и сортировка при вызове zorder?

Всем привет) очееееень нужно узнать, сколько у вас занимает zookeeper места на HDD?

метров 40

Snapshot ? У нас 3gb

Логи и данные в zookeeper

Знаю, вопрос не по теме, но подскажите пожалуйста, кто-нибудь занимался пробросом портов???
ser2net
com0com
com2tcp

И ещё вопросик: я сейчас собираю кластер Hadoop , нужно определиться с местом на namenode. Какой объём и сколько дисков? Что порекомендуете?

получалось у кого нибудь заставить работать

"spark.sql.sources.partitionOverwriteMode", "dynamic"

на spark2.4 / hadoop3.1 (CDP7.1.4)?
там что то изменилось в commitProtocolClass (по сравнению с CDH5.16) и теперь оно сломано

java.io.IOException: PathOutputCommitProtocol does not support dynamicPartitionOverwrite

Можете нашими рекомендациями воспользоваться:

https://docs.arenadata.io/adh/install/planning.html#id8

Если bare metal то лучше использовать одинаковую конфигурацию с воркерами, жизнь будет проще

Антон и Антон, спасибо))

"Четыре или более 2-3 ТБ RAID 10 with spares для rm" ? куда там столько места? :)

Сильно зависит что за пользователи и что они делают, а также размера кластеров; для интерактивных пользователей я обычно рекомендую начать с трёх фиксированных наборов настроек (число и размер экзекьюторов, настройки dynamic allocation) условно S/M/L и давать пользователям их выбирать, дальше смотреть как кто использует

а есть какие-нибудь методики по расчету на условные S/M/L ?
Параметров то много

"spark.sql.sources.partitionOverwriteMode", "dynamic"

java.io.IOException: PathOutputCommitProtocol does not support dynamicPartitionOverwrite

если вдруг кто то будет искать в чатике, то решилось так

spark.conf.set("spark.sql.sources.commitProtocolClass", "org.apache.spark.internal.io.HadoopMapReduceCommitProtocol")

или

 
spark.conf.set("spark.sql.sources.commitProtocolClass", "org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol")

не разбирался в чем отличие между ними, но работает. и по умолчанию в CDH5.16 + spark2.4 используется второй

опять все зависит от того что за пользователи и что они делают; обычно логика такого рода: у нас есть 10 пользователей и ресурсов запустить 100 экзекьюторов для этой группы, нужно чтобы в пределе каждый мог запустить хотя бы 1 контекст, поэтому S мы поставим 1-10 экзекьюторов, L поставим 10-50 экзекьюторов чтобы один контекст L оставлял ресурсы для работы, M поставим 3-30 например; иногда видел что делают размер XS еще, из одного самого маленького экзекьютора

а помимо кол-ва эксезуторов, есть же еще ряд парамертров, такие как ядро на драйвер, память на драйвер, ядро/память на экзекутор, мемори оверхед и тд

как вот такими вещами грамотно распорядится так, чтобы при полной нагрузке задействовалось 100% кластера

это хадуп, 100% даже не мечтайте, только при диком оверкоммите по процессору)