Local[*]

Похоже на проблемы с сериализацией вашей функции. Вы вашу юдф как создаёте?

Я ее регистрирую как выше показал и использую в селекте вот так: df.select(“deserialize(value)”)

А попробуйте что-нибудь такое:

val deserialise = udf((e:Array[Byte]) => ...)
df.select(deserialise(col(“value”)))

Хм, не пробовал так, сейчас попробую и отпишусь, спасибо :)

непомогло (

а в прекрасной скале будущего рефлексия порицается?

Смотря для чего думаю, в скале рефлексия в целом не приветствуется т.к. ведёт к ошибкам которые сложно либо даже невозможно отловить на этапе компиляции

а в каком языке поощрается? рефлексия в целом штука которую надо избегать

как говорит мой батя военный - "если долго в себе копать, можно такого накопать..."

)))

Ну в жабке(извините) сплошь и рядом. Всегда есть проблема динамического кода. Как ее грамотно решать, паттерн матчингом?

конкретный пример лучше показать

вдруг и правда тебе нужен рефлекшн

У меня есть процедура. Она вмердживает некий/любой dataframe в hudi формат. У неё стандартный контракт-что куда на каких условиях. Про структуру дф она ничего не знает, он имплисит. При этом дф может быть сколько угодно много всяких разных.
Я делаю универсальную аппликуху, которая должна в зависимости от входных параметров слепить дф и скормить его универсальной процедуре.

Поэтому мне надо проанализировать параметры, что за дф хочет приготовить вызывающий. И вызвать нечто,что приготовит мне нужный df. И я тут вижу либо рефлексию, либо паттерн матчинг. Возможно, мне просто не хватает мозгов правильно выстроить приложение.

Если я правильно понимаю:
Вам нужно создать приложение, которое будет принимать набор параметров определяющих конфигурацию источников данных и набор трансформаций. Собственно сами трансформации будут описаны как df, который потом будет передан процедуре, вычислен, а его результат вмерджен в соответвующую таблицу в hudi.

Для чего вы хотите использовать рефлексию/паттерн матчинг?
- маппинг переданных параметров в объекты конфигурации
- конструирование df для последующей передачи в процедуру
- что то ещё (уточните пожалуйста)

Добрый день, коллеги! У меня такой вопрос если при перезаписи таблицы hive в spark вместо insertInto использовать save, будут ли проблемы? И был ли кого такой кейс когда одно spark приложение перезаписывало таблицу, а другое производило вставку данных в эту же таблицу? Какие проблему могут вытечь при такой параллельной работе?

При замене insertInto на save при перезаписи может начать падать из за того что Спарк плохо понимает форматы файлов.
Одновременная запись в одну таблицу возможна только если запись идёт в разные партиции. Если как вы описали, одна таска полностью перезаписывает таблицу, а вторая дозаписывает то одна из них упадёт

Спасибо, а если save указывать формат записи он все равно может упасть?