Гпу инстансы вообще грабеж среди бела дня

Если речь идёт о надёжности - да

Ну при хранении данных нам надежность не очень нужна, я тут согласен

Я тут недавно как раз считал с3 против онпремиса локального на пятилетку. Мне сказали цену похожего размера хранения, там чото было около 15-20к зелёных в месяц

Серьезно если то мы бывает поднимаем копию куда то в хдфс на эфемералах, но мастер всегда в S3

Я тут недавно как раз считал с3 против онпремиса локального на пятилетку. Мне сказали цену похожего размера хранения, там чото было около 15-20к зелёных в месяц

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

Я тут недавно как раз считал с3 против онпремиса локального на пятилетку. Мне сказали цену похожего размера хранения, там чото было около 15-20к зелёных в месяц

А сколько цодов в вашей конфе?

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

Нужно бы конфу какую собрать )

А сколько цодов в вашей конфе?

Так про то и речь. Амазон даёт большую стоимость, но и девяток там конечно больше как по доступности, так и по надёжности. Этим он выигрывает. Но в рамках даталейка...

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

хех, лол

Так про то и речь. Амазон даёт большую стоимость, но и девяток там конечно больше как по доступности, так и по надёжности. Этим он выигрывает. Но в рамках даталейка...

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

Все остальное можно пересчитать из даталейк

Но счёт на 10-15к за хранение это область 500+ терабайт

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

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

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

Уххх. Ребята из сапа, оракл и всяких АСУ ТП и ис ТП не согласны )

Но счёт на 10-15к за хранение это область 500+ терабайт

Почти на порядок меньше

Он премис 500 тб это будет 1.5 пб после реплики, и с пустым местом это кластер на 2+ пб, это уже ОЧЕНЬ большие CAPEX инвестиции

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

Они будут очень надежными, но историю обычно удаляют ;)

Плюс логи, которые сейчас бОльшая часть даталейка, а источники вообще не хранят

Почти на порядок меньше

Вы тогда чего-то не то сказали, может это цена не только ща хранение?

Уххх. Ребята из сапа, оракл и всяких АСУ ТП и ис ТП не согласны )

Судя по этим аббревиатурам мы могли с вами встречаться))

Вы тогда чего-то не то сказали, может это цена не только ща хранение?

Да, слегка по объемам ошибся. Поднял переписку, 50 тбайт - 6к баксов. Суммарно за все они платили 20к. То есть 150-180тб

Да, слегка по объемам ошибся. Поднял переписку, 50 тбайт - 6к баксов. Суммарно за все они платили 20к. То есть 150-180тб

хм, просто за хранение даже где-то во франкфурте нужно будет отдать 2.5к за 50 ТБ, а в штатах 1.5К, видимо это за что-то еще

есть кто живой?

+

уже разобрался, спасибо

В одной екомерс компании мне утверждали, что hyperthreading плохо сказывается на рилтайм компьютинг в hadoop и они его принудительно отключали. Это действительно так или это мамкины погромисты?

В одной екомерс компании мне утверждали, что hyperthreading плохо сказывается на рилтайм компьютинг в hadoop и они его принудительно отключали. Это действительно так или это мамкины погромисты?

не знаю про хадуп, но HT может реально ударить по производительности, если нагрузка очень IO bound

и добавляет он, в лучшем случае процентов 20-30, а не 100 как нам всем хотелось бы.

В одной екомерс компании мне утверждали, что hyperthreading плохо сказывается на рилтайм компьютинг в hadoop и они его принудительно отключали. Это действительно так или это мамкины погромисты?

Технология hyper-threading позволяет задействовать вычислительные блоки, которые простаивают внутри физического ядра. Ну или распараллелить ожидание данных из памяти. В реальности в большинстве случаев это может давать повышение производительности по throughput +30-40%, но, из-за большего contention на вычислительные блоки будет может давать +30-40% latency на сами операции внутри процессора. И дальше надо выбирать, что вам важнее, latency и near real-time или throughput и batch processing. Для hadoop верно второе. Выключать стоит только если вы реально понимаете что делаете, сделали сравнительные тесты, и, нарпример, понимание что из-за hyper-threading и бегущей аналитики с hbase / ignite / flink бегущими рядом получаете серьёзную просадку. Рулить hyper-threading считается bad practice, но, как мы видим, в новых процессорах от intel стали чаще его не делать:)

"только если вы реально понимаете, что делаете".

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

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

лучше бы всего человечества

не знаю про хадуп, но HT может реально ударить по производительности, если нагрузка очень IO bound

Как HT связан с IO?

Как HT связан с IO?

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

слишком косвенно

слишком косвенно

ну я например на постгресе замечал, что без ht он даже лучше работает

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

Да, но можно сделать наоборот. Если 4 ядра, включить HT, будет 8 ядер. Делаем 4 потока с дисками, и даже если они ушли в D-state и мучают ядра, то остальные 4 ht свободны по всем вычислительным блокам, и дают 100% производительности

Да, но можно сделать наоборот. Если 4 ядра, включить HT, будет 8 ядер. Делаем 4 потока с дисками, и даже если они ушли в D-state и мучают ядра, то остальные 4 ht свободны по всем вычислительным блокам, и дают 100% производительности

госпади, кто ж так программы пишет new FixedThreadPool(1000)

пока один поток стоит, другой работает профит! дедова техника работает

госпади, кто ж так программы пишет new FixedThreadPool(1000)

согласен, кто такие маленькие пулы выделяет

пока один поток стоит, другой работает профит! дедова техника работает

это работает для interruptible states (сеть, некоторые примитивы синхронизации), при блокирующей работе с дисками это плохая практика.

это работает для interruptible states (сеть, некоторые примитивы синхронизации), при блокирующей работе с дисками это плохая практика.

прост у твоей стойки кэш маленький, не энтерпрайзно

энтерпрайзно это сделать FixedThreadPool(1000) и надеяться на кеш дисковой полки?:)

энтерпрайзно это сделать FixedThreadPool(1000) и надеяться на кеш дисковой полки?:)

да, но! важно тесты гонять на правильном объеме перед внедрением, а то кэша может не хватить где нить

да, но! важно тесты гонять на правильном объеме перед внедрением, а то кэша может не хватить где нить

Интересный у вас подход, а когда данных станет много и не влезают, что делать будем?:)

энтерпрайзно это сделать FixedThreadPool(1000) и надеяться на кеш дисковой полки?:)

прост ты рано свалил с аутсорса (я тупо завидую)

Еще полочек закажем?:)

прост ты рано свалил с аутсорса (я тупо завидую)

ну так вали, кто держит:)

Интересный у вас подход, а когда данных станет много и не влезают, что делать будем?:)

/pyatnitsa

ну так вали, кто держит:)

давно, но шрамы остались

/pyatnitsa

/pyatnitsa

/pyatnitsa

/pyatnitsa

Пятничная перепись населения, не нажимайте на ссылку.

/pyatnitsa

Пятничная перепись населения, не нажимайте на ссылку.

why so serious?!

why so serious?!

Тесты не проходят:(

/pyatnitsa

/pyatnitsa

/pyatnitsa

всем привет и хорошей пятницы! расскажите пожалуйста, а как настроить опцию spark --packages смотреть на локальный maven репо? что-то не могу найти гайдов.

вроде как только через http урлы к нему явно указывать

Да, но можно сделать наоборот. Если 4 ядра, включить HT, будет 8 ядер. Делаем 4 потока с дисками, и даже если они ушли в D-state и мучают ядра, то остальные 4 ht свободны по всем вычислительным блокам, и дают 100% производительности

я немного не так написал. когда IO bound и есть много IOwait то HT поможет, потенциально. То есть когда на хосте есть узкое место которое приводит к потенциальным iowait - диски, сеть. Когда iowait низкий, HT не пможет, а из-за дополнительных задержек на ротацию очередей, даже ухудшит производительность. Где то на сайте red hat должен быть подробный отчет на эту тему касательно производительности КVM с и без HT, я его писал в 2010-2011 где-то

я немного не так написал. когда IO bound и есть много IOwait то HT поможет, потенциально. То есть когда на хосте есть узкое место которое приводит к потенциальным iowait - диски, сеть. Когда iowait низкий, HT не пможет, а из-за дополнительных задержек на ротацию очередей, даже ухудшит производительность. Где то на сайте red hat должен быть подробный отчет на эту тему касательно производительности КVM с и без HT, я его писал в 2010-2011 где-то

что за ротация очередей? Если iowait низкий — проц свободный, ht должен помочь на batch processing

что за ротация очередей? Если iowait низкий — проц свободный, ht должен помочь на batch processing

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

>"Когда iowait низкий, HT не пможет, а из-за дополнительных задержек на ротацию очередей, даже ухудшит производительность. " Если iowait низкий, то задачи выполнять может любое число свободных ядер.

Если у нас 56 ядерная машина и одно ядро съело диск в полку, то iowait ~2%.

Остальные 55 ядер свободные, cpu bound может спокойно работать

iobound могут так же спокойно работать, если с другими дисками.

вот касса в банк, к ней выстроилась толпа. Кто то просит что то быстрое, и получает услугу, уходит. Кто то внезапно чтоб птветить на вопрос кассира начинает лезть в телефон или ковыряться в сумке, в поисках бумаг например. HT это вторая очередь к тому же кассиру, и если кто то задерживается, кассир принимает другого из второй очереди чтоб не ждать. Чтоб было честно кассир принимает при все равны условиях людей из двух очередй поочередно. Если все с быстрыми запросами, двойная очередь только задержит исполнение. Если у многих тормоза с доставанием бумаг из сумок - вторая очередь помогает скорить общий процесс приема всей толпы

кассиров от этого больше не стало