определённое кол-во тасок в клаудере и хдп было 2 и фейлится джоб

про стейджи как раз не слышал

Всем привет! Подскажите, аутсорсеров, фрилансеров или компании кто занимается заказной разработкой на spark и настройки инфраструктуры на облачных мощностях под конкретные задачи? Соответственно с примлемым качеством чтобы не пришлось потом все переписывать, как это бывает.
Задачу скину уже при личном общении.

у нас есть канал обсуждения вакансий, оформи там вопрос / предложение с большими деталями и конкретикой.

Окей, спасибо. Забыл про него

Адрес джобс https://t.me/datajobs если кто не заглядывал давно в описание группы

Всем привет. Снова вопрос по hbase. Не совсем понимаю такую ситуацию. Есть rowkey, он формируется конкатенацией строк, первая подстрока в 6 символов - дата ddmmyy. Поскольку данных очень много создаю таблицу с desired split points в надежде на то, что процесс разлива будет равномерным по регион серверам. Делаю сплит поинты вида '31303131' с переводом в шестнадцатеричную систему строки '1011' (ddmm). И вот распределение черти какое в результате. Делаю split pointы вида   '1011' и все ок. Откуда hbase понимает, что в ключе строка?

Никак

Он вообще типы не понимает

Если вы делали 'конкатенацию', то скорее всего у вас вся строка это и есть ключ

Hbase все воспринимает как byte

Поэтому возможна ситуация:
Вы сделали конкатенацию строк
Перевели всю строку в байтыв лоб

Следом ставите сплит таким же принципом рассчитывая на свой поревод в 16 формат

kamikadze Поэтому когда у меня в ключе была строка, то и сплит задавал именно как строку префикс

Для hbase все есть byte[]

Шестнадцетиричные непечатоемые символы вы как 0x.. Будете видеть :)

Почему тогда Поинты вида '31303131'  не работают?

Подскажите, есть ли способ прочитать оракловые дампы в Hadoop без oracle big data sql?

А почему должны

Вы имеете строку как ключ '1011', задаёте поинт как строку '31303131'

Строки явно разные

Если бы вы задали поинт как строку с символами-байтами 0x31 0x30 0x31 0x31 то тогда опять бы работало :)