Как стать автором
Обновить

Комментарии 9

Не люблю Грету, один пиар. И у нас не жаркая Швеция, а холодная Россия (незаметно прибавляет еще ядер в настройки своих spark-приложений :).

Так же по этой оптимизации был сделан PR [HDFS-15202], который был вмержен и данный функционал будет доступен в следующих релизах.


А Cloudera 5.x пропатчат? Хотя бы гипотетически.

5.х — Он же EOS в декабре. Мы так же на пятерке сидим :(

Я про EOS догадываюсь. Можем сформулировать вопрос так — а какие версии гипотетически возможно?
Интересная идея. Только как-то не по себе от того, что у вас рандом решает, что кэшировать, а что нет. Обычно предлагают решать «клиенту» ( например, setCacheBlocks(false) для больших сканов).

Еще было бы интересно посмотреть, как себя ведет себя BucketCache, где нет оверхеда, связанного с GC.

Спасибо за интересный комментарий. То что касается рандомной операции пропуска и представления клиенту, это хороший вариант, когда клиенты могут "договориться" между собой. Но представьте себе случай, когда один потребитель (физически это может быть сотня потоков), запрашивает данные. Он же не знает, есть ли другие потребители сейчас. Если есть, то в общих интересах было бы не просить все кешировать (чтобы избежать GC). А если других читателей нет, то можно кешировать все (допустим потому, что все поместится в кеш). Таким образом это не получится отдавать чисто на откуп клиенту, все равно придется задействовать RS для обмена информацией и ещё надеяться, что клиенты захотят делиться кешем с другими клиентами, что и сложнее чисто технически и не всегда возможно так сказать "политически".


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


Насчёт скорости чистого BlockCache без оверхеда. Если совсем без обращений к файловой системе более миллиона записей в секунду, я писал про такие тесты тут: https://habr.com/ru/company/sberbank/blog/484096/


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

А мы поступили проще — на некоторые таблицы вообще отключили BlockCache )

Кстати, а какие цифры на вашем профиле данных вы получили бы если бы включили SNAPPY/LZO/ZSTD и хранение в кеше сжатых данных hbase.block.data.cachecompressed issues.apache.org/jira/browse/HBASE-11331?

Не пробовали Кеш на SSD?

Насчет сжатия — мы тестили на YCSB, которая делает чистый рандом и тут смысла жать не имело.

Насчет более реальных данных… Я помню как-то делал короткий тест и первое впечатление было такое что не понравилось и я отложил, но не исключаю что нужно было проделать все более тщательно.

SSD к нам приедут примерно в августе и это будет интересно)
> Мы высадили два RS на одну ноду

А, вижу тоже замучилась тред-пулы подкручивать что бы выжать максимум с железа и всё равно этого не хватает и проще поднять еще RS на сервере 8)
Есть такое, мы даже на некоторых кластерах по 3 RS поставили)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий