mayton2019

Попробуй сначала подключись через
spark-shell --master ....
Это будет доказательством что порт доступен по сети и ты все правильно сконфигурил.

Тут Spark не имеет никаких преимуществ перед обычным приложением. Скорее всего чтение из json не распараллелится. Такой он вредный json.

Попробуй просто выкачать json через hdfs tools и толкнуть его в кликхаус обычным java или python ротложннием. И jdbc лучше не использовать. Если у кликхауса есть другой API то бери его. Будет быстрее чем jdbc.

Сам себе отвечаю.

collect_list() и explode()

- две функции которые делают нужные преобразования.

Но практически - моя постановка изменилась и сейчас сводится к работе с JSON-arrays которые лежат
в ячейках таблицы. Для них collect/explode мне не подошел. А подошли функции transform и cast.
Часть из них доступны начиная со Spark 3.1.1 и Databricks 9.1.x-LTS Runtime. Поэтому надо модернизироваться срочно.

Я долго подбирал те слова которые ругательные, но которые цензура все таки пропускает. Вобщем выходило очень по старо-словянски. Вобщем лихо. Сиречь молвить совсем тяжко. Бесовщина... Все неправильно.

Во первых для чтения и обработки CSV файла тебе не нужен RDD. Это очень сырой тип данных который щас никто почти не использует. Его почти всегда заменяют на DataFrame/DataSet. Он остался только в легаси коде и в тех кейсах когда нужно обработать текст (natural language).

Во вторых желательно разделить просто Scala-функции и протестировать их отдельно.

В третьих. Тебе надо поработать со Schema и DataFrames. Тебе дано 9 comma-separated файлов. Получи из них сначала 9 датафреймов. При чтении используй следующий шаблон.

val atusact = spark.read.format("csv")
                .option("header","true")
                .option("inferSchema", "true")
                .option("delimiter", ",")
                .load("/data/atusact.csv")

После того как все датафреймы будут загружены - ты работаешь с данными которые имеют схему. (опция infer).
И из каждого датафрейма можешь получить колонки и типы как коллекции объектов.

Ошибки implicite conversions имеют отношение к языку Scala больше чем к Spark. Если перепишешь все на PySpark то ошибка сама собой уйдет. Я не хотел-бы на ней останавливаться. Отдельным топиком задай по Scala.

P.S. Я вообще игнорировал твоё задание. Мне безразлично что там надо сделать. Я просто смотрел по стилю.

P.P.S Не пиши флуд с картинками. Это не помогает в решении вопроса а только запутывает и раздражает читателя.

Для перехода с Log2j на вторую версию есть мигрейшен гайд https://logging.apache.org/log4j/2.x/manual/migrat...

Еще покажите полностью dependency:tree начиная с корня. Старый логгер log4j еще может быть транзитивной зависимостью от тысяч других библиотек (hadoop например) и выкорчевать его из проекта совсем - может быть нетривиальной задачей.

По поводу угроз которые были обнаружены в Log4j я-бы не сильно парился. Для современного биг-дата приложения которое запускается в контейнерах я думаю что угрозы нет. Если инициатива выкорчевывания библиотек исходит не от вас а от других людей - то неплохо-бы от них получить какое-то обоснование зачем все это делать и как много человеко-часов вы согласитесь вообще на это потратить.