нет. это sql query, как я понимаю в sql repartition и не скажешь

Было бы желание:
SET spark.sql.shuffle.partitions = 2
SELECT * FROM df DISTRIBUTE BY key

коллеги! скажите, используете ли вы Dimensional Modeling в своих DataLake/LakeHouse-ах?
если да, то храните ли Dimension'ы во внешних RDBMS (особенно часто мутирующие измерения вида SCD2) или с появлением ACID-форматов хранения (таких как Delta, Hudi, Iceberg, Hive ACID) все справочники тоже держите в DataLake?

и еще: может кто-то изучал вопрос Star Schema Transformation для последних версий Spark? вроде в Databricks она уже работает

и до ACID прослоек хранили все только в самих даталейках (пересчитывали справочники целиком), потом что федеративные запросы это еще хуже

не все так поступали, много где как раз использовали внешние MySQL/PG-базы. особенно в случае huge dims

а как витрины выставлены пользователям?

а чем федеративные запросы хуже? если измерения достаточно маленькие и поддаются кешированию/броадкасту? тем что нужно самим управлять политикой актуализации кеша?

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

какой порядок пользователей у таких витрин, десятки-сотни-тысячи?

пока до сотни

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

через BI-систему для большинства бизнес-пользователей (JDBC до Spark Thrift Server),
через SparkSQL для дата-сотонистов

а как справочники из БД выставлены, как hive external table / JdbcStorageHandler ?

hive external table

а как у JdbcStorageHandler c PDO, если у меня какие-то джоины между справочниками - он сможет спушить все в PG, или через JDBC вытаскивает на Spark  всю таблицу и там джоинит?

(у нас контора обратную тему развивает, когда справочники и часть данных в базе, а не очень нужные/старые - в объектном сторадже, так я вижу даже по планам запросов что оптимизатору приходится так себе)

PDO = push down predicate optimization?
когда я это смотрел, пробрасывались на сторону Postgres только какие-то очевидные литеральные предикаты.

и это было на прошлой работе. сейчас как раз рассматриваем вариант Star Schema Model со всеми сущностями - facts, dims - как Databricks Delta-таблицами. то бишь на золотом слое DataLakeHouse не куча широких витрин в MPP-базе, а классические звездчатые структуры.
и вот интересно не приходит ли индустрия к этому же?

Databricks совершенно очевидно движется к этому, они пишут свою витринную СУБД ровно для того чтобы звездатые структуры нормально отдавать клиентам

в самом способе хранения тут проблем особых нет, люди и на обычном HDFS c импалой жили хорошо, проблема в самом спарке, он тормозит, для этого они переписывают его

концепция lakehouse, если я правильно понимаю маркетинг databricks: на одном ACID-compliant storage предоставить возможность гонять не только широкие но тормозные Spark джобы, но и другие виды нагрузки (low latency, ANSI SQL, какие-то около OLTP фичи)