а как дальше данные будут по партициям биться?

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

DF.write.format(“orc”).saveAsTable(…)

что-то вроде consistent hashing?

Насколько я понимаю, за счет того что HANA "in memory" она спокойно и быстро отдает данные. Но механику partitionColumn я посмотрю. Это может ускорить выкачивание партиций по 10Gb.

я сейчас проверю, но вообще судя по всему если вы делате только:

df= spark.read.jdbc(…)
df.write.format(“orc”).saveAsTable(…)

И в read.jdbc нет параметров на partitionColumn, то вы все делаете в один поток

df= spark.read.jdbc(…)
df.write.format(“orc”).saveAsTable(…)

да, с этим спору нет.
Вопрос в том что если мы делаем numPartition в N, и N executors, то потом перед тем как склеивать в orc придётся мёрджить данные с N executors

вам нужно распараллелить забор данных, вы полюбому упираетесь в скорость чтений jdbc в 1 поток:
.option("partitionColumn", conf_params("thread_alias"))
                       .option("lowerBound", p_table_params("thread_min"))
                       .option("upperBound", p_table_params("thread_max"))
                       .option("numPartitions", thread_num)
.option("fetchsize",        conf_params("fetchsize").toInt)

это не обязательно помогает. В случае с Oracle, например, это только делает ситуацию хуже

читаю так из оракла и ничего не делает хуже

нужно думать по кому партишен делать

чтоб таблица на той стороне также была партицирована или индексирована

А при распараллеливании чтения вы упрётесь в недовольный отдел эксплуатации системы😆

тут смотря как цель: быстрей скачать или снизить нагрузку

> вот эта история обычно более жизненная 😅

Тру

понятно что в 1 сессию оракл не будет нагружаться, но цель быстрей скачать, придется параллелить, нужно только договориться насколько и по какому полю

=) Да, он там злой))) Но я думаю если забирать в 2-3 потока, это уже лучше чем в 1)

Иногда даже по поводу 1 лучше уточнить, если точно не знаете.)

поле партицирования нужно еще выбирать так, чтобы не было перекосов, а то получится, что 15 потоков давно уже все скачали, а 1 выкачивает оставшиеся 99%

а еще лучше уточнить что с сеткой между БД и кластером.
помнится мне история, когда так же бились над выкачиванием данных из терадаты, с партишенами игрались, а оказалось что сеть была 1ГБ между ДЦ (и та по умолчанию на половину нагруженная)