ага, спасибо; видимо там проблема в старой версии спарка, и надо подсолить самим

Вопрос про работу со стороны spark с hive таблицей которая external hbase, может кто сталкивался с подобным.

Создаю external таблицу в hive (2.3.8) на hbase (2.2.2) таблицу, запрос типа:

select * from KeysToHuman where keystohuman.hmn='031958c575f5e6d2f02c9eb3c01b3021';  

проходит быстро, явно используются pushdown predicate,
но когда подобный запрос стартую со стороны спарка (2.4.7):

sql("select * from KeysToHuman where keystohuman.hmn='031958c575f5e6d2f02c9eb3c01b3021'").show

то и по времени и по запросу понятно что он выкачивает все таблицу из hbase и потом фильтрует.
Как заставить спарк использовать pushdown predicate в этом случае?

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

но тут в хайве реализовано, можно как-то заставить спарк транслировать запрос в хайв, а там он сам разберется?

Тут не могу сказать, у меня была связка через феникс без хайва, и в итоге я использовал jdbc он прямо быстрее работал.

спасибо, тоже думал про это.
натолкнулся на хорошую подборку статей про спарк sql, может еще кому-то поможет
https://www.waitingforcode.com/apache-spark-sql/predicate-pushdown-spark-sql/read

видимо так и есть, слезы навернулись на глаза, этот блокер уже полтора года там висит, уже и PR был, но воз и ныне там
https://issues.apache.org/jira/projects/HBASE/issues/HBASE-22769?filter=allopenissues

Использовать hbase-spark connector

Без hive

выше сообщение, что там тоже это не работает

Подборка действительно хорошая, парень немало написал про расширения spark, а остальное я ещё не читал

Нет, это скорее естественный data skew. Обычно у клиента около 100-1000 девайсов и это легко помещается в существующие ресурсы, тем более, что я обрабатываю по одному клиенту на запрос в спарк кластере. Однако у некоторых клиентов свыше миллиона девайсов и при поступлении этих данных, процесс обработки просто вылетает по таймауту, даже если прибавить количество воркеров. Коллега также говорит, что тормоза могут быть с partition by device_id при сохранении в S3.

А, ну блин, это везде проблемы, в DFS миллион партиций сохранить)

Что в s3, что в hdfs, что в wasb)

Хэш по модулю (например 1000) от device_id поможет)

Спасибо, то есть всё таки хэшинг. Кстати там device_id alphanumeric.

Тут скорее вопрос, как дальше будет использоваться - для выборок по device_id? Тогда в запросах фильтр придётся усложнить, типа where device_id == 10101 and id_hash_1000 == 101

OMG, это очень неудачное решение, совершенно точно не стоит по такому большому количеству значений партицировать, у вас и partition lookup потом тормозить будет, сжатие пострадает..

Норм варик бакетирование по device_id - но как его на стриминге обеспечить?

Ну либо не на стриминге, но на том, где часто накидываются данные батчами