Либо как товарищ притащить зк поновее

не могу поновее, дяденьки-девопсы его поддерживают, не хочу туда соваться

а где это? что-то не нашел сходу

Zookeeper changed the zookeeper.properties file format and as a result NiFi users using an existing embedded zookeeper will need to adjust their existing zookeeper.properties file accordingly.

Как костыль можно запустить с собственным зк найфая

так zookeeper.properties - это же для embedded-зукипера?

то есть проще всего запустить ембеддед?

Да, если бампануть зк нельзя

спасибо огромное! очень выручили!!!

воспользуюсь еще вашими знаниями...
в NiFI еще не появились процессоры под Oracle Logminer?

Коллеги, добрый день, я тут озадачен, скажите пжз, кто из крупных современных проектов, вы используете orm в разработке или голый sql?

Всем привет! Вопрос как мониторить spark 3 на yarn  через prometheus?
Есть spark 3 (в котором заявлена нативная интеграция с prometheus), добавил  metrics.properties, указал все нужные --conf , а вот дальше что делать - не понимаю, что и как надо настроить в prometheus или еще где, что бы эти метрики забирались? А то в докладе (https://databricks.com/session_na20/native-support-of-prometheus-monitoring-in-apache-spark-3-0) и в статье (https://dzlab.github.io/bigdata/2020/07/03/spark3-monitoring-1/) все просто, но я в ops-овских  делах, как свинья в апельсинах?

Привет!
Кто-нибудь подключал к спарку в кубах persistantVolumeClaim?

Я ловлю вот такую ошибку при попытке использовать volume

20/12/09 11:07:13 ERROR Utils: Uncaught exception in thread kubernetes-executor-snapshots-subscribers-1
java.util.NoSuchElementException: key not found: persistentVolumeClaim.sparksubmitvol.options.claimName

конфиг вот такой:

--conf spark.kubernetes.executor.volumes.persistentVolumeClaim.sparksubmitvol.mount.path=/spill_local \
--conf spark.kubernetes.executor.volumes.persistentVolumeClaim.sparksubmitvol.mount.readOnly=false \
--conf spark.kubernetes.driver.volumes.persistentVolumeClaim.sparksubmitvol.mount.path=/spill_local \
--conf spark.kubernetes.driver.volumes.persistentVolumeClaim.sparksubmitvol.options.claimName=sparksubmitvol-claim \

volume read-write-many

20/12/09 11:07:13 ERROR Utils: Uncaught exception in thread kubernetes-executor-snapshots-subscribers-1
java.util.NoSuchElementException: key not found: persistentVolumeClaim.sparksubmitvol.options.claimName

--conf spark.kubernetes.executor.volumes.persistentVolumeClaim.sparksubmitvol.mount.path=/spill_local \
--conf spark.kubernetes.executor.volumes.persistentVolumeClaim.sparksubmitvol.mount.readOnly=false \
--conf spark.kubernetes.driver.volumes.persistentVolumeClaim.sparksubmitvol.mount.path=/spill_local \
--conf spark.kubernetes.driver.volumes.persistentVolumeClaim.sparksubmitvol.options.claimName=sparksubmitvol-claim \

ну вроде ошибку заборол, но пока не понятно, пишутся ли туда промежуточные данные или нет

Народ, посоветуйте или отговорите меня от дистрибутива Hadoop типа plain vanilla hadoop vs  Cloudera Hadoop etc

Мне достался в наследство полуработающий plain vanilla HDFS v 3.1.1, который доставляет очень мало удовольствия. Хотелось бы услышать аргументы в пользу перехода на что то более приятное .

так а какие проблемы? что простой переход позволит улучшить?

Ну например я видел, что в cloudera больше разных примочек типа балансировка дискового пространства или нахождение больших или маленьких файлов