там чуть хитрее логика подразумевается - этих выходных топиков в PubSub будет не один десяток, и создаваться они будут в процессе работы стриминговой джобы.
но гарантируется условие, что сначала будет создан output-топик, а потом в едином input-топике появится соответствующее сообщение, результат обработки которого должен быть записан в этот созданный output-топик.

нагуглил совет "An alternative is to just write a ParDo that uses the Pubsub API directly and writes to your topic of interest".
пока копаю в этом направлении.

вариант с клауд функциями тоже рассмотрю, спасибо за идею!

Is there a translation bot in this group?

Коллеги, те кто знаком с iceberg, нужна ваша помощь. Поборол ошибку с java.lang.IllegalStateException: Already closed files for partition на дневных партициях для Insert overwrite через установку конфигурации 'write.distribution-mode'='range' и последующий ALTER TABLE ... WRITE ORDERED BY ....
Так вот, при попытке сделать MergeInto снова нарвался на эту ошибку, похоже дело в параллельной записи нескольких тредов в одну партицию. Порылся в тестах проекта, там нет сценариев MergeInto для множества партиций с кол-вом строк в рамках одной партиции больше чем 1.
Подскажи, пожалуйста, в чем проблема и куда смотреть, перерыл почти все доки.

Мб кому интересно, решил проблему через изменением SortOrder и добавление колонок партициониования перед колонками сортировки.

Nop, but there are lots of people who can answer you in English, so feel free to ask your question in English

Интересно как этот бот должен работать, спамить переводом на каждое сообщение?

Посмотрите в багтрекере, что-то было такое

👍

Есть бот, который переводит с неканонических языков нас заданный канонический

Крипта закончилась что ли?

у Маска

@krivdathetriewe @pomadchin

Тут продают, вы давно искали помню

Так это же ужасно

Это спорный вопрос

Смотрите как круто:

Яцек:
Hi,

Found this new spark.sql.adaptive.coalescePartitions.parallelismFirst config property [1] with the default value true but the descriptions says the opposite:

> It's recommended to set this config to false

Is this OK and I'm misreading it?

[1] https://github.com/apache/spark/blob/54cca7f82ecf23e062bb4f6d68697abec2dbcc5b/sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala#L519-L530

Wenchen:
This is correct. It's true by default so that AQE doesn't have performance regression. If you run a benchmark, larger parallelism usually means better performance. However, it's recommended to set it to false, so that AQE can give better resource utilization, which is good for a busy Spark cluster.

То есть конфиг Спарка по умолчанию настроен не для продакшена

это стандартная практика для кучи софта, ASF/open source и даж проприетарного - по-умолчанию нужно чтобы софт просто поднялся и хоть как-то работал, в самых плохих условиях