у меня опять флэшбэк от py4j где сериализация чисел идет в строки (ну тоже байты)

Решаемой задачей хранить миллиард миллиардов объектов :)

пробовали в hbase хранить объекты размером в несколько метров и более?

пробовали в hbase хранить объекты размером в несколько метров и более?

пробовали нарезать и хранить чанками, а поверх длеать объектный сторадж

такое себе удовольствие:)

ну вот я и намекаю Станиславу, что это специфичная задача)

Нет, да и не соберусь его так использовать. Вечный упор в ио заставляет скорее наоборот клеить объекты, чем создавать миллиарды их

пробовали в hbase хранить объекты размером в несколько метров и более?

я пробовал

нормальная тема

нормальная тема

а кейс какой по обращениям?

только лексиграфические запросы

рендж / по ключу

ну и она норм работала; никаких специфическиъ настроек не хотела

большой объем был?

да

ну как

не очень

пара тб

я че т не очень верю, что оно с кучей регионов будет вести себя хорошо

но это диванное размышление

нормально вела; к слову оно все заработало и тесты прогнало и показало хороший резльутат

но ты верно говоришь, для больших ячеек есть accumulo

там прост на страничке иъ говроится что ячейка до экзобайта => подразумевает что ты там можешь хранить блокчейн

пробовали нарезать и хранить чанками, а поверх длеать объектный сторадж

Кассандра лучше подходит для этого

Кассандра лучше подходит для этого

Её мы тоже пробовали, да, подходила лучше:)

Её мы тоже пробовали, да, подходила лучше:)

и как вам она?

Кассандра лучше подходит для этого

oO

Кассандра лучше подходит для этого

как всегда бесподобно конкретен

да на самом деле кассандра тож норм с большими блобами живет

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

эт да, но есть еще тарантул и оранго

и как вам она?

Ну в итоге просто написали свой object storage поверх самописного key-value storage, работает лучше всего:)

Вы не из Сбертеха?

Вы не из Сбертеха?

Вовсе нет

Больше на яндекс похоже)

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

Я думал ВК и одноклассники

Там всё ещё списки сами пишут, не доверяют java.util)

Это что. В одном зеленом учреждении своя сборка хадупа.

Это что. В одном зеленом учреждении своя сборка хадупа.

Так и Мейл вроде тоже об этом говорил гордо

вы так говорите, как будто это плохо

Ничего такого я не имел ввиду.

Интересно, а кто-то использует хадуп на чем-то отличном от линукса ?

Интересно, а кто-то использует хадуп на чем-то отличном от линукса ?

используют, но к слову даже hdinsight ажуры на линухах

Можно вроде как и на винде, только в 2 раза дороже)

Можно вроде как и на винде, только в 2 раза дороже)

Ну, винда сама по себе не бесплатная

мне было бы инетерсно послшуать о юзейсе хадупов под виндой

Прост не очень понятно, зачем платить за лицензию, если можно не платить и абсолютно ничего не потерять

Интересно, а кто-то использует хадуп на чем-то отличном от линукса ?

Чет большие сомнения. Он же много возможностей ОС использует.

Удобство винды в хорошем графическом интерфейсе, но на 50 нод всё равно через rdp не залезешь)

Чет большие сомнения. Он же много возможностей ОС использует.

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

Прост не очень понятно, зачем платить за лицензию, если можно не платить и абсолютно ничего не потерять

Например "исторически так сложилось". Примерно как у нас с хадупом под фрёй.

вы так говорите, как будто это плохо

Не подходит для enterprise в большинстве случаев (лучше стабильная коробка и поддержка), но ничего плохого в этом нет.

Интересно, а кто-то использует хадуп на чем-то отличном от линукса ?

У Рамблера на фрибсд был

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

Ага, не стоит использовать одновременно машины с разной ОС.

У Рамблера на фрибсд был

.. и есть

может они по ZFS угорели

может они по ZFS угорели

Кстати много кто таким образом бекапы делает:)

Привет! Такой вопрос) а хайв отдельно от хадупа можно поставить?

Привет! Такой вопрос) а хайв отдельно от хадупа можно поставить?

и по какой бд он будет запросы делать?

по воображаемой?

ну не, на диске будут лежать файлики parquet, где-то будет его PG с метаданными

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

Привет всем, ни у кого не было такой странности: спарк джоба (одна и та же) с разной нагрузкой в EMR порождает разный объем трафика между драйвером и экзекьютором, проблема в том что этот трафик остается даже когда джобу прибиваешь

как то так это выглядит

первый небольшой пик это та же джоба на меньшем количестве данных

потом все плато это запущенная джоба, и расти трафик начал уже после того как я ее кильнул

я не очень понимаю куда копать можно

и по какой бд он будет запросы делать?

Бд как раз тут не при чем, метастор стоит отдельно. Вопрос хранения данных - орки на хдфс. Скорее интересно, зачем так делать?

Ну если нужен только хайв, нафига весь хадуп?

Напихал найфаем паркетов на локальный диск и сидишь селектишь.

Я так понял.

И чем тогда постгре плох?

так и хайв тогда зачем и паркет?

а что тогда от hive остается? по умолчанию там движок Tez, он без yarn жить умеет?

можно конечно извратиться, сделать hive on spark, такая связка чисто теретически может прожить без hadoop, но боюсь там гвозди есть... даже не сотка )

а что тогда от hive остается? по умолчанию там движок Tez, он без yarn жить умеет?

Cbo, metastore, hiveserver2, hcat

Ну всем говорить бигдата мол у меня, 500 Мб распарсил.

ну тогда spark в local mode + sparj thrift server )

Так что, никто не гонял 3 хадуп на 11 рэках с новым кодированием?)

можно конечно извратиться, сделать hive on spark, такая связка чисто теретически может прожить без hadoop, но боюсь там гвозди есть... даже не сотка )

Хайв на спарке гораздо хуже самого спарка

?

Они даже сами от его поддержки отказались в какой-то момент)

предложим, я в hbase храню методанные большие, на hdfs сами данные, а ignite краткие методанные с ключевыми. как мне понять, сколько нужно будет времени, чтобы достать все данные, и сделать полный олап

и как обьяснить, что там никаких потоковых данных не будет

Бд как раз тут не при чем, метастор стоит отдельно. Вопрос хранения данных - орки на хдфс. Скорее интересно, зачем так делать?

пока предполагается объем где-то до 50ТБ (с учетом х3 репликации). На этом хочется использовать spark ML. Есть предположение, что для чего-нибудь понадобится hive или что-то типа того) Хадуп ради пары десятков ТБ разворачивать странно. Плюс hdfs медленный будет. Надежность данных не так важна, ибо там будет лежать не сырье а только предобработанные данные. Само сырье будет тянуться из хадупа (он уже есть, с ним все хорошо). Почему не делать это на уже существующем хадупе? Нужно полностью изолировать ресурсы на эти задачи. Он и так сильно нагружен + эксперементы с оптимизацией и отсутствие тестового стенда делают его потенциально (и не только, хехе) не очень надежным в плане готовности данных к определенному времени.

пока предполагается объем где-то до 50ТБ (с учетом х3 репликации). На этом хочется использовать spark ML. Есть предположение, что для чего-нибудь понадобится hive или что-то типа того) Хадуп ради пары десятков ТБ разворачивать странно. Плюс hdfs медленный будет. Надежность данных не так важна, ибо там будет лежать не сырье а только предобработанные данные. Само сырье будет тянуться из хадупа (он уже есть, с ним все хорошо). Почему не делать это на уже существующем хадупе? Нужно полностью изолировать ресурсы на эти задачи. Он и так сильно нагружен + эксперементы с оптимизацией и отсутствие тестового стенда делают его потенциально (и не только, хехе) не очень надежным в плане готовности данных к определенному времени.

Надёжность не важна, но репликация х3. Данных 15 ТБ в каком виде то? А то может хайв нужен будет, а может нет. Втф? И хдфс достаточно быстрая штука, все зависит от нагрузки. Как раз в таком виде развернуть рядом кластер хадупа и бросать данные между ними с репликой х1 вообще легко. Даже проще

> Данных 15 ТБ в каком виде то? parquet, в каком-нибудь bzip или snappy Тут еще проблема в том, что разворачиванием кластера буду заниматься не я, а админ. И он что-то не горит желанием поддерживать 2 кластера хадупа. Четко обосновать, что нужен именно второй хадуп, а не какой-нибудь месос со спарком я не могу, ибо сам сомневаюсь, что хадуп нужен)

Пока видится, что поставить какой-нибудь кластер на месос, цеф, кубернетнес (или как там пишется) и туда закинуть либы спарка гораздо проще, чем рядом разворачивать, настраивать и поддерживать еще один хадуп.

хм. мне казалось, с точки зрения админа чем однороднее ландшафт, тем лучше ) на прод тоже двумя отдельными наборами сред покатите?

Пока видится, что поставить какой-нибудь кластер на месос, цеф, кубернетнес (или как там пишется) и туда закинуть либы спарка гораздо проще, чем рядом разворачивать, настраивать и поддерживать еще один хадуп.

15 тб в кубере?о боже

Вот мне кажется, что поддержка одного только к8с/цеф в разы более трудоёмка, нежели хадуп, с которого только пылинки сдувай раз в квартал, да тряпочкой протирай. Но вам виднее.

Вот мне кажется, что поддержка одного только к8с/цеф в разы более трудоёмка, нежели хадуп, с которого только пылинки сдувай раз в квартал, да тряпочкой протирай. Но вам виднее.

с моим кейсом я чтот советов не увидел

Вот мне кажется, что поддержка одного только к8с/цеф в разы более трудоёмка, нежели хадуп, с которого только пылинки сдувай раз в квартал, да тряпочкой протирай. Но вам виднее.

вот как раз таки не виднее) несколько дней назад я задавался вопросом, а какой тогда ресурс менеджер использовать и не нашел и тут как-то тоже не подсказали. Поэтому тут не понятно. Спарк отдельно от хадупа я еще не юзал, поэтому не представляю, с какими проблемами можно столкнуться)