Актуальность Big Data
Хороший разработчик на проседание по зарплате не пойдёт.
А вот понизить планку ЗП за счёт булщит словечек — это ок!
А вот понизить планку ЗП за счёт булщит словечек — это ок!
А вы наблюдаете большую вострбованность?Да, ажиотаж есть.
Но такого как ты пишешь - нет и не будет имхо. Потому как от BigData ожидают некоторой магии, как и от мобильных приложений когда-то. Люди не знают что им надо, не понимают как быстро это можно сделать, как дорого стоит разработка и какие риски есть.
Двусторонний риск - нарваться на то, что инвесторы начнут зажимать бабло. Как и на то, что нанятый разработчик будет парить мозг вместо того, чтобы продукт делать.
Зачем куда-то идти с проседанием по зарплате. Если есть желание - ботай тему, бери каггл да участвуй в нем. ну или вот
http://special.habrahabr.ru/beeline/
Идти в эту тему стоит, если тебе в ней комфортно. Т.к. многим подобный род деятельностив в принципе не очень по душе.
Под проседанием имею в виду следующее - выбираю новый проект, в проекте c big data меньше прибавка к зп(возможно даже 0). Вот и вопрос, насколько реальный опыт с hadoop, spark является ценной инвестицией.
Про понизить планку не совсем тебя понял.
Про понизить планку не совсем тебя понял.
BigData - это очередной buzzword, типа как Grid в своё время. В России big data вообще практически не существует, разве что у крупняка типа Яндекс, Mail.ru или рекламщиков.
Такого специфического скилла как "работа с Big Data" тоже не существует. Обрабатывать Big Data вполне успешно можно, зная лишь grep, sed, wc, sort. Помнится, даже видел доклад на эту тему.
Такого специфического скилла как "работа с Big Data" тоже не существует. Обрабатывать Big Data вполне успешно можно, зная лишь grep, sed, wc, sort. Помнится, даже видел доклад на эту тему.
типа Яндекс, Mail.ru или рекламщиков.причем для BigData у них свои инструменты...
Имхо, в России пока нет восстребованости big data, из-за отсутствия больших собираемых массивов данных.
Российские средние компании до сих пор слабо автоматизированы, что не даёт большого потока данных.
Российские средние компании до сих пор слабо автоматизированы, что не даёт большого потока данных.
Обрабатывать Big Data вполне успешно можно, зная лишь grep, sed, wc, sort. Помнится, даже видел доклад на эту тему.Как я понимаю, Big Data - это то, что не лезет в обычный настольный комп. C помощью grep ты такое не обработаешь эффективно, так как это большой объём данных, а процессоры в настольных компах примерно такие же быстрые, как в лучших молотилках - то есть тут мощное железо не даст преимуществ в скорости перед обычным компом. Как минимум, grep придётся распределять по кластеру - а это уже скилл.
Вроде в телекоме довольно много данных? Да и в ритейле тоже...
Хочу узнать мнение форумчан про эту область разработкиhadoop ваш тормозное говно.
Как минимум, grep придётся распределять по кластеру - а это уже скилл.
for server in list; do
ssh server "grep BIGFILE zzz" &
done
wait
echo finished
Это покрывает 99% сценариев, за исключением ситуации, когда ты работаешь в Mail.ru или Яндекс.
map/grep/reduce/wc
В России big data вообще практически не существует, разве что у крупняка типа Яндекс, Mail.ru или рекламщиков.?
любая крупная компания работающая с массовым клиентом (услуги, магазины, популярный софт) - уже собирают или могут начать собирать большие объемы пользовательской информации.
плюс иностранные заказчики
отдельно - банки и прочее
любая крупная компания работающая с массовым клиентом (услуги, магазины, популярный софт) - уже собирают или могут начать собирать большие объемы пользовательской информации.Не, ну серьезно. Ну какие там объемы у них? Миллиончик транзакций в день хотя бы наберут?
любая крупная компания работающая с массовым клиентом (услуги, магазины, популярный софт) - уже собирают или могут начать собирать большие объемы пользовательской информации.ну например магазины
1000 магазинов (крупная сеть) на каждом 5 касс, на каждой 8 часов каждый день обслуживают по 1 покупателю в минуту, у покупателя в чеке в среднем 10 позиций, на каждую позицию по 100 байт
за 20 лет работы собирается менее 20 Тбайт - это доступно для настольного компа
а в 1% я использую parallel-ssh
20 Тбайт - это доступно для настольного компаДоступно для хранения, или для обработки?
Начиная со 100ГБ уже сильно приятнее работать в кластере.
ну вот тут и вопрос: что за обработка
BigData это, например, данные с большого адронного коллайдера, метео спутников, астрономические наблюдения...
Но их станут анализировать только в различных НИИ, а там кроме MPI ничего использовать не будут. (имхо)
Но их станут анализировать только в различных НИИ, а там кроме MPI ничего использовать не будут. (имхо)
5 миллиардов записей в одну таблицу и 500 миллионов в другую в месяц - это биг дата?
5 миллиардов записей в одну таблицу и 500 миллионов в другую в месяц - это биг дата?это нормально для мелкосервера, какая ещё бигдата
а если анализировать как-то хитро и одновременно быстро эти данные за много лет - то наверное таки да
5 миллиардов записей в одну таблицу и 500 миллионов в другую в месяц - это биг дата?Смотря для кого. Для меня 500 миллионов в месяц - это не особо биг дата.
Но в плане маркетинга фраза "500 миллионов записей в месяц" на интервью может хорошо подействовать на каких-нибудь олухов, которые бигдату в своей жизни не видели ни разу.
баян по теме
Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it...
На какой-то конференции техдир юлмарта полчаса мне втирал что бигдата это персонализированные рекомендации покупок в реальном времени 
нотсоубигдата
man grep мб сначала почитать?
Зато хотел купить такую систему за пару лямов зелени
вот докладик: http://www.highload.ru/2007/abstracts/1030.html
К сожалению, все пиратские видео выпилили.
К сожалению, все пиратские видео выпилили.
ну вот тут и вопрос: что за обработкаПоиск и агрегация.
некоторые виды этих операций выполняются вполне эффективно
это нормально для мелкосервера, какая ещё бигдатавы придираетесь к словам. это ничуть не лучше, чем угорать по модному слову бигдата.
суть стека технологий не в петабайтах, а в том, что стек бесплатный и масштабируемый.
надо тебе 1 млн обработать - херачишь на одной машинке. появилось данных сильно больше - взял и расширился.
> появилось данных сильно больше - взял и расширился.
более продуктивно оптимизировать для наиболее вероятного случая - никогда не появится
а если у тебя внезапно стало сильно больше данных - это означает сильно больше денег - тогда и разберёшься как правильно обработать данные, наймёшь знатоков хадупа
более продуктивно оптимизировать для наиболее вероятного случая - никогда не появится
а если у тебя внезапно стало сильно больше данных - это означает сильно больше денег - тогда и разберёшься как правильно обработать данные, наймёшь знатоков хадупа
надо тебе 1 млн обработать - херачишь на одной машинке. появилось данных сильно больше - взял и расширился.Чтобы появилось данных сильно больше нужно денег сильно больше. А когда деньги есть, можно на том же хадупе написать интерпретаторы для баш скриптов.
Вроде в телекоме довольно много данных?У нас платформа в мтсе генерирует и агрегирует террабайт зипнутых транзакций в сутки. Ну и поток транзакций непосредственно связанных с чаржингом раз в 20 меньше. общий объем хранилища террабайт 6.
более продуктивно оптимизировать для наиболее вероятного случая - никогда не появитсяс одной стороны ты пытаешься внести какую-то объективность ("продуктивно оптимизировать"), с другой стороны и в модели которую описываешь ты сходу возникают субъективные решениия ("сильно больше денег")
а если у тебя внезапно стало сильно больше данных - это означает сильно больше денег - тогда и разберёшься как правильно обработать данные, наймёшь знатоков хадупа
почему ты думаешь, что заказчики не думают, что у них уже "сильно больше денег"? или "сильно больше данных". тем более, если критерий "ааа, мы не влезаем в один сервер, а нам нужно 5", то такое будет встречаться очень часто как минимум из-за того, что не всё делается продуктивно или оптимизировано
и почему дешевле оптимизировать, чем сразу разрабатывать под масштабируемую архитектуру - тоже непонятно
ЗЫ
в итоге любые подобные решения будут приниматься чисто субъективно и на основе "а есть ли у нас бабло на разработку" и "верим ли мы что это что-то даст"
Первый интервал — от 0 до 10^9.
Второй интервал — от 10^9 до 10^15.
Третий интервал — от 10^15 до 10^n.
На каком интервале бОльшая часть денег?
Гипотиреоза о том, что бОльшая часть денег на втором интервале выглядит аномальной. Требуется объяснение этой аномалии.
Предположение о том, что деньги в основном на первом интервале выглядит не так удивительно.
Второй интервал — от 10^9 до 10^15.
Третий интервал — от 10^15 до 10^n.
На каком интервале бОльшая часть денег?
Гипотиреоза о том, что бОльшая часть денег на втором интервале выглядит аномальной. Требуется объяснение этой аномалии.
Предположение о том, что деньги в основном на первом интервале выглядит не так удивительно.
с другой стороны и в модели которую описываешь ты сходу возникают субъективные решениия ("сильно больше денег")для кучи серверов объективно нужно много денег, сильно больше чем для одного или пяти
много-много транзакций тоже как правило у тех, у кого много денег (это объективный факт, хотя не строгий)
сразу разрабатывать под масштабируемую архитектуру - тоже непонятноты считаешь, что если первые NN месяцев/лет гоняешь свой код на 5 серверах, потом получишь сразу масштабирование на 10000 серверов, просто потому что используешь map/reduce или ещё что-то модное из бигдаты?
сразу масштабирование на 10000 серверовэто частый кейс по-твоему?
кажется ты по-прежнему отталкиваешься, что BigData - должны быть такие объемы, чтобы посмотреть и офигеть
я периодически хожу проведать как там на рынке труда и могу сказать, что в стек технлогий, который зовется bigdata лезут уже те кто с 2-х серверов на 10 переходят. То есть у них там hadoop, scala, прочее. Самое большое, что я видел - обещали десятки петабайт.
держать связный кластер в 10000 серверов - на сколько я знаю тот же hadoop не расчитан на такое, а внезапно к такому не прийти, тот же яндекс постепенно шел в течении лет 10, при этом понадобилось дофига специалистов и дошли до того, что сами стали их обучать.
а ты говоришь "как появятся - наймут"
То есть у них там hadoop, scala, прочее.почему ты записал scala (язык общего назначения) в один класс с hadoop?
2-х серверов на 10 переходятна 10 серверах hadoop всего лишь в несколько раз медленнее awk?
суть стека технологий не в петабайтах, а в том, что стек бесплатный и масштабируемый.Эээ ... какой стек бесплатный и масштабируемый? Неограниченно масштабируемых решений вообще не бывает. Более того, существуют обширные классы задач, которые никак не ложатся на Map-Reduce. (Неоднократно приходилось это объяснять упоротым любителям Hadoop-ов)
Поэтому да, сделать быстрое решение на Small Data очень часто в разы выгоднее, чем ковыряться в BigData/Hadoop и прочих.
Неограниченноне очень понимаю к чему эти рассуждени про неограниченность и прочие 10К серверов
изначальный вопрос про реальную жизнь и про то - популярна ли bigdata
я вам рассказал о том, что вижу сейчас - какая потребность и в чем есть.
потребность обрабатывать от нескольких десятков террабайт, до нескольких десятков петабайт.
хадуп и всё что около вполне подходит и покроет потребности массового потребителя на годы вперед.
чтобы херачить в нем не надо никаких способностей помимо отсутствия лени, если сравнивать с тем же проганьем на grep и awk
дальнейшие вопросы пожалуй не ко мне надо адресовывать, а к "заказчикам", которые не понимают гениальной идеи написать всю аналитику на авке и грепе, а так же вручную (ой, нет, писать свой транспортный уровень поверх ssh) обмениваться данными между 10 серверами.
да полно заказчиков которые выбирают непригодный инструмент по велению левой пятки
стандартная ситуация - никто никогда не слышит про эту компанию, кроме сотрудников - так как продукта не получается
стандартная ситуация - никто никогда не слышит про эту компанию, кроме сотрудников - так как продукта не получается
ты про стратапы что-ли?
у всех компаний в которых я бывал уже есть продукт
а то, что не услышат - это судьба 99.9% компаний вообще, даже тех, что логи авком грепают
у всех компаний в которых я бывал уже есть продукт
а то, что не услышат - это судьба 99.9% компаний вообще, даже тех, что логи авком грепают
у всех компаний в которых я бывал уже есть продуктя тоже был в компании, где был продукт и игрались с хадупом на 5 серверах - вдруг будет много-много данных
данные не появились, хадуп забросили
(ну там только старт jvm идёт дольше, чем эквивалентный запрос на питоне c orm, что в итоге и использовалось)
чтобы херачить в нем не надо никаких способностей помимо отсутствия лени, если сравнивать с тем же проганьем на grep и awkИз этой я фразы я понял только, что ты искренне любишь Хадуп и поэтому пытаешься его впихнуть везде.
хадуп и всё что около вполне подходит и покроет потребности массового потребителя на годы вперед.
Попробуй сделать JOIN на Хадупе.
скорее я не тащусь от авка и прочего, т.к. довольно много на этом писал, да и сейчас использую.
для больших не write-only проектов это всё мало подходит
? даже стажеры за пол дня справляются написать свою реализацию джойна.
но правда не хадуп а местный мапредьюс - как раз с башем и авком.
для больших не write-only проектов это всё мало подходит
Попробуй сделать JOIN на Хадупе.
? даже стажеры за пол дня справляются написать свою реализацию джойна.
но правда не хадуп а местный мапредьюс - как раз с башем и авком.
а почему не так делали?
http://www.oraclealchemist.com/news/tf-idf-hadoop-streaming-...
http://www.oraclealchemist.com/news/tf-idf-hadoop-streaming-...
я тоже был в компании, где был продукт и игрались с хадупом на 5 серверах - вдруг будет много-много данныхв целом не вижу ничего плохого том, что забросили это дело
данные не появились, хадуп забросили
(ну там только старт jvm идёт дольше, чем эквивалентный запрос на питоне c orm, что в итоге и использовалось)
а почему не так делали?общая проблема малого бизнеса, который никогда не станет крупным: некий директор говорит "делай так" вплоть до мелочей, а потом ругается, что все сотрудники тупые ленивые засранцы, которые без команды ничего не делают
общая проблема малого бизнеса, который никогда не станет крупным: некий директор говорит "делай так" вплоть до мелочей, а потом ругается, что все сотрудники тупые ленивые засранцы, которые без команды ничего не делаютда вроде в крупном те же принципы выносить мозг сотрудникам.
только разве что добавляется умение еще и переложить ответственность на подчиненных.
в крупном бизнесе ни у какого директора не хватит времени даже попытаться контролировать работу всех подчинённых, обязательно есть делегирование ответственности, иначе бизнес не может быть крупным
Так не у директора, а у начальника начальника, например.
Отличие только в том, что директор рискует своими деньгами, а начальники - положением, поэтому должны подстраховываться.
Отличие только в том, что директор рискует своими деньгами, а начальники - положением, поэтому должны подстраховываться.
? даже стажеры за пол дня справляются написать свою реализацию джойна.Ох ты ж какие быстрые, а у самого Hadoop чето не получается никак.
для больших не write-only проектов это всё мало подходит
Просто большинство проектов не являются "большими". Хотя разработчики всегда уверены, что "завтра трафик возрастет в 10 раз", этого не отнять.
скорее я не тащусь от авка и прочего, т.к. довольно много на этом писал, да и сейчас использую.ну ладно awk
для больших не write-only проектов это всё мало подходит
а что-нибудь более модное и современное, типа питона?
Outer и cross - нет.
А если связь многие к одному и левый/правый - то можно.
А если связь многие к одному и левый/правый - то можно.
а что-нибудь более модное и современное, типа питона?по мне так в самый раз.
Почему нет? Зависит от данных, задачи и вообще ожиданий получить профит. Если взрыва нет, то получится заджойнить как угодно.
Только для cross надо чтобы в память помещалось (меньшая таблица)*(кол-во воркеров на машинке), тогда в один проход можно.
Только для cross надо чтобы в память помещалось (меньшая таблица)*(кол-во воркеров на машинке), тогда в один проход можно.
Почему нет?Big Data подразумевает, что у тебя на сервере в кластере только часть всех данных.
Big Data подразумевает, что у тебя на сервере в кластере только часть всех данных.Ага. В сложных случаях JOIN даёт N^2 трансферов между нодами. Именно так делает Apache Hive, который обожают хадуподрочеры.
Ага. В сложных случаях JOIN даёт N^2 трансферов между нодами.а линуксовый join джойнит за ~O(N). магия!
либо у тебя при джойне должно получиться данных больше, чем ты сможешь хранить (тогда спрашивается нафига вообще хотеть джойнить), либо спасет сортировка + джойн мапом.
у хадупа есть стриминг, то есть даже на баше с авком можно джойн написать.
В сложных случаях JOIN даёт N^2 трансферов между нодами.
В сложных случаях JOIN даёт N-1 трансферов на агрегирующую ноду.
Так не у директора, а у начальника начальника, например.в большой компании мелкий начальник, который не умеет делегировать, никогда не станет более крупным начальником (а могут вообще сместить из-за низких показателей) - поэтому они учатся делегировать (могут быть даже курсы и тренинги)
в мелкой компании начальник (он же и мелкий и крупный и единственный) может заниматься микроменеджментом пока компания жива
по мне так в самый разну вот короче если бигдаты нет, а есть нотсоубигдата, то масштабируется легко - зеркалируются данные на новый сервер (затраты минимальны) и пускай там сколько хочешь аналитических расчётов - никакой хадуп не нужен
В смысле зеркалируешь? Данные же разные. Надо взаимодействие и балансировку нагрузки самому обеспечивать. между серверами самому обеспечивать. Или ты имеешь ввиду реляционную базу поднять над этим всем?
тоже самое можно сформулировать и наоборот.
директор мелкой компании, который не умеет делегировать, никогда не сможет увеличить свою компанию, а может вообще раззориться из-за неэффективного расхода времени
а мелкий начальник в крупной компании может заниматься микроменеджментом пока работа выполняется
> В смысле зеркалируешь? Данные же разные.
откуда разные?
откуда разные?
> директор мелкой компании, который не умеет делегировать, никогда не сможет увеличить свою компанию
согласен
> мелкий начальник в крупной компании может заниматься микроменеджментом пока работа выполняется
тоже может быть, но он опять же не сможет увеличить свой отдел
и проиграет внутреннюю конкуренцию, если она есть
согласен
> мелкий начальник в крупной компании может заниматься микроменеджментом пока работа выполняется
тоже может быть, но он опять же не сможет увеличить свой отдел
и проиграет внутреннюю конкуренцию, если она есть
откуда разные?на один сервер не влезают, например.
если зеркалировать ради скорости - придется же дофига синхронизировать по сети.
тоже может быть, но он опять же не сможет увеличить свой отделвсё так, а директор - внешнюю конкуренцию проиграет.
и проиграет внутреннюю конкуренцию, если она есть
мне просто всегда казалось что внешняя конкуренция всегда жестче, т.к. компании занимаются одним и тем же
а внутренняя слабее, т.к. изначально отделы разным занимаются и чтобы задавить соседа надо существенные усилия прилагать.
при том, что когда ты увеличишь долю рынка в два раза, то и доход может в два раза вырасти, а когда становишься начальником в два раза большего количества народа доход растет не так сильно.
на один сервер не влезают, например.тогда это настоящая бигдата
а мы как раз говорим про случай, когда данных не так много, как обычно и бывает
если зеркалировать ради скорости - придется же дофига синхронизировать по сетисколько дофига? миллион транзакций в сутки - это ниочём вообще
а внутренняя слабее, т.к. изначально отделы разным занимаются и чтобы задавить соседа надо существенные усилия прилагатьпросто не увеличат финансирование и не дадут новых задач, если отдел едва справляется с имеющимися
если в большой компании новых задач и так нет, значит она стагнирует, и работают там только грибы - этот случай рассматривать неинтересно
сколько дофига? миллион транзакций в сутки - это ниочём вообщеА почему в транзакциях? Если ты за одну операцию генерируешь 100гб данных и у тебя 10 зеркал, придется передать по сети 1ТБ.
Если ты за одну операцию генерируешь 100гб данных итак про то и речь с самого начала треда, что очень мало компаний, где есть что-то подобное
так про то и речь с самого начала треда, что очень мало компаний, где есть что-то подобноея имел ввиду, что разработчик из 30 ТБ логов (или сколько там помещается в одну машинку) в одну операцию делает 100ГБ дополнительных данных, а не то, что 100ГБ логов за день приходит
тогда не очень понимаю
в общем он берёт узел, на котором лежат терабайты логов, и пусть хоть что угодно с ними делает там
если есть другие операции с логами, то на другом узле те же самые терабайты тоже лежат - первая операция не мешает второй - в этом масштабируемость, про которую я пишу
если зачем-то надо результат в 100Г скопировать на другие узлы, не вижу в этом особых проблем: скорость сети сравнима со скоростью дисков
(хадуп кстати скорость пониже показывал, чем простые методы копирования - hdfs работал довольно печально, ну может это мы не умели его готовить - никого сверхопытного в этом деле не было)
в общем он берёт узел, на котором лежат терабайты логов, и пусть хоть что угодно с ними делает там
если есть другие операции с логами, то на другом узле те же самые терабайты тоже лежат - первая операция не мешает второй - в этом масштабируемость, про которую я пишу
если зачем-то надо результат в 100Г скопировать на другие узлы, не вижу в этом особых проблем: скорость сети сравнима со скоростью дисков
(хадуп кстати скорость пониже показывал, чем простые методы копирования - hdfs работал довольно печально, ну может это мы не умели его готовить - никого сверхопытного в этом деле не было)
сейчас приведу пример, но возможно он покажется специфичным (хотя у меня наверное такое самое частое)
Когда задача выглядит, как вычисление результата функции A(B(C(D(E(F(X)))))для каждой строки таблицы Х. При этом каждая функция тяжелая и должна вычисляться отдельно. Тогда варианта три:
1. синхронизировать всё что зазеркалено после каждого этапа вычисления (и это же не просто передача по сети будет, а передача 100гб* ln(кол-во нод) в лучшем случае, и 100гб*кол-во ноод если зеркаление не оптимизировано)
2. забивать на парралальность, всё считать на одной ноде.
3. забить на целостность базы, вручную побить базу на куски и после подсчета вручную их объединять.
Хадуп у тебя считай сам раскидывает данные по нодам и когда их можно просто мапить ты получаешь, что на диск пишется 20гб на каждой ноде, вычислительно загружены все мощности, целостность обеспечена
То есть проигрыш будет:
случай 1) N*log(N) по сети-диску
случай 2) в N раз по процессору.
случай 3) по скорости разработки
но если задача вида
A(B(X) +C(X) + D(X) + E(X) + F(X))
то да, можно вручную запускать куски, а потом сливать - проигрыша не будет, может и правда даже выигрыш из-за накладных расходов.
Про то, на сколько hdfs медленнее других методов - хз, я в этом совсем не спец.
Когда задача выглядит, как вычисление результата функции A(B(C(D(E(F(X)))))для каждой строки таблицы Х. При этом каждая функция тяжелая и должна вычисляться отдельно. Тогда варианта три:
1. синхронизировать всё что зазеркалено после каждого этапа вычисления (и это же не просто передача по сети будет, а передача 100гб* ln(кол-во нод) в лучшем случае, и 100гб*кол-во ноод если зеркаление не оптимизировано)
2. забивать на парралальность, всё считать на одной ноде.
3. забить на целостность базы, вручную побить базу на куски и после подсчета вручную их объединять.
Хадуп у тебя считай сам раскидывает данные по нодам и когда их можно просто мапить ты получаешь, что на диск пишется 20гб на каждой ноде, вычислительно загружены все мощности, целостность обеспечена
То есть проигрыш будет:
случай 1) N*log(N) по сети-диску
случай 2) в N раз по процессору.
случай 3) по скорости разработки
но если задача вида
A(B(X) +C(X) + D(X) + E(X) + F(X))
то да, можно вручную запускать куски, а потом сливать - проигрыша не будет, может и правда даже выигрыш из-за накладных расходов.
Про то, на сколько hdfs медленнее других методов - хз, я в этом совсем не спец.
вычисление результата функции A(B(C(D(E(F(X)))))для каждой строки таблицы Хчто-то не понял
1) на каком этапе нужно писать на диск?
2) это же просто конвейер?
Да, конвеер, разбивать приходится по разным причинам:
- операции много памяти жрут и их нельзя объединить,
- промежуточные данные хочется переиспользовать в других задачах
- сегментация долго выполняющихся тасков для удобства разработки
- операции много памяти жрут и их нельзя объединить,
- промежуточные данные хочется переиспользовать в других задачах
- сегментация долго выполняющихся тасков для удобства разработки
По-моему ты что-то недоговариваешь, но пока по твоему описанию это задача для обычного, старорежимного, до-бигдатного, до-облачного и даже до-гридового кластера. То есть способов придумано за последние десятилетия дофигища.
Можешь дать определения следующим терминам? "бигдата", "облачный", "грид". А то, кажись, все тут их по-разному понимают.
бигдата - это когда нет никакой возможности обработать данные на одном компе. Алгоритмы, которые умеют в параллельность лучше асимптотически, но имеют гораздо худший коэфициент. В результате на графики масштабирования образуется яма - когда классический подход уже не может, а параллельный ещё катастрофически не эффективен.
Облачный - это когда параллельные вычисления записываются и выполняются в абстракциях, где нет место понятия машины-хоста. Не путать с виртуальными или клонированными серверами, которые предоставляются амазонам. Они были и раньше и назывались просто data center. Первый облачный хостинг - это гугл app engine, которые позволяет запускать приложения полностью оторванными от нижележащих абстракций. Не знаю, есть ли ещё другой.
грид - это система распределения ресурсов со множеством провайдеров и множеством потребителей. Реализует логику распределения аналогичную классическим электросетям, от которых и позаимствовало название. Простое распределённое вычисление гридом не является.
Распределённые вычисления, датацентры общего пользования, приватные датацентры, клиент-серверная архитектура и терминалы существовали задолго до того, как стали актуальны облака и гриды. И не надо их путать, как бы противного не желали маркетологи, желающие к старом товару приделать новый фантик
Облачный - это когда параллельные вычисления записываются и выполняются в абстракциях, где нет место понятия машины-хоста. Не путать с виртуальными или клонированными серверами, которые предоставляются амазонам. Они были и раньше и назывались просто data center. Первый облачный хостинг - это гугл app engine, которые позволяет запускать приложения полностью оторванными от нижележащих абстракций. Не знаю, есть ли ещё другой.
грид - это система распределения ресурсов со множеством провайдеров и множеством потребителей. Реализует логику распределения аналогичную классическим электросетям, от которых и позаимствовало название. Простое распределённое вычисление гридом не является.
Распределённые вычисления, датацентры общего пользования, приватные датацентры, клиент-серверная архитектура и терминалы существовали задолго до того, как стали актуальны облака и гриды. И не надо их путать, как бы противного не желали маркетологи, желающие к старом товару приделать новый фантик
бигдата - это когда нет никакой возможности обработать данные на одном компе.что такое один комп? есть же Mesos, например
медианный сервер в коммерческом сегменте.
Теперь никак не могу понять разницу между "параллельными вычислениями", "распределенными вычислениями" и bigdata. Вот эти кейсы — это что?
Кейс По большому хадуп-кластеру размазаны 10 млрд. фотографий. Мы запускаем MapReduce джобу (де факто только map, без reduce), где для каждой фотографии незасимо считается f(x). f(x) может быть, к примеру, детектить и выдавать координаты лиц, строить перцептуальный хэш и т.п.
Кейс По большому хадуп кластеру размазано 10 млрд. записей рекламной статистики (user_id, ad_id, is_clicked:bool). Мы запускаем MapReduce джобу, которая группирует записи по ad_id и для каждой такой ad_id считает CTR: количество кликов на этот ad_id / общее число показов этого ad_id.
Кейс Пациенту делают рентген коленного сустава. Чтобы определить степерь артроза по рентгенограмме (1GB), запускаем на MPI-кластере из 128 нод джобу, которая занимается перемножением каких-то матриц и делает это за несколько минут. Когда раньше считали на одном сервере, то пациенту приходилось приходить на еще один прием за результатами. Сейчас он получает их прямо на месте.
Как минимум, я хочу понять фразу "нет никакой возможности обработать данные на одном компе".
Кейс По большому хадуп-кластеру размазаны 10 млрд. фотографий. Мы запускаем MapReduce джобу (де факто только map, без reduce), где для каждой фотографии незасимо считается f(x). f(x) может быть, к примеру, детектить и выдавать координаты лиц, строить перцептуальный хэш и т.п.
Кейс По большому хадуп кластеру размазано 10 млрд. записей рекламной статистики (user_id, ad_id, is_clicked:bool). Мы запускаем MapReduce джобу, которая группирует записи по ad_id и для каждой такой ad_id считает CTR: количество кликов на этот ad_id / общее число показов этого ad_id.
Кейс Пациенту делают рентген коленного сустава. Чтобы определить степерь артроза по рентгенограмме (1GB), запускаем на MPI-кластере из 128 нод джобу, которая занимается перемножением каких-то матриц и делает это за несколько минут. Когда раньше считали на одном сервере, то пациенту приходилось приходить на еще один прием за результатами. Сейчас он получает их прямо на месте.
Как минимум, я хочу понять фразу "нет никакой возможности обработать данные на одном компе".
Теперь никак не могу понять разницу между "параллельными вычислениями", "распределенными вычислениями" и bigdata. Вот эти кейсы — это что?bigdata - это размер задачи, а не способ решения задачи.
Распределённые вычисления - это подвид параллельных, которые размазаны между несколькими хостами. Я не всегда указывал это явно, каюсь. Распределённые вычисления адресуют несколько разных проблем классических вычислений - когда не хватает мощности вычислителя (последний случай) или когда не хватает памяти вычислителя (случай бигдаты)
распределённые вычисления - разные части задачи выполняются на физически разных узлах, соединённых в сеть
распределённые вычисления - часто параллельные, но не всегда: например, проведение интернет-платежа через сайт продавца с перенаправлением на сайт банка - это распределённая операция, но не параллельная - в каждый момент работу делает только один узел, а остальные ждут результата
и наоборот: параллельные вычисления - часто распределённые, но не всегда, например многопоточная программа на smp-системе с общей памятью - точно параллельная, но не распределённая
бигдата - согласен с айвенго, но я бы брал обычный настольный комп, а не "медианный сервер"
что в настольный комп не влезает - то бигдата
распределённые вычисления - часто параллельные, но не всегда: например, проведение интернет-платежа через сайт продавца с перенаправлением на сайт банка - это распределённая операция, но не параллельная - в каждый момент работу делает только один узел, а остальные ждут результата
и наоборот: параллельные вычисления - часто распределённые, но не всегда, например многопоточная программа на smp-системе с общей памятью - точно параллельная, но не распределённая
бигдата - согласен с айвенго, но я бы брал обычный настольный комп, а не "медианный сервер"
что в настольный комп не влезает - то бигдата
например, проведение интернет-платежа через сайт продавца с перенаправлением на сайт банка - это распределённая операция, но не параллельная - в каждый момент работу делает только один узел, а остальные ждут результатафрод-мониторинг работает асинхронно, в большинстве случаев
а транзакция - синхронный
Оставить комментарий
stm7563014
Хочу узнать мнение форумчан про эту область разработки. Речь больше об обычных инженерных задачах, чем о machine learning. Например, ETL на hadoop или spark.Уже несколько лет эта область на слуху, типа в тренде. Но я (java-разработчик) на рынке труда не наблюдаю большой востребованности, ажиотажа. Ажиотаж, на мой взгляд, это когда "Пишешь на java/python? Знаешь, что такое map-reduce? Иди к нам на хорошие деньги, по ходу всё изучишь". А вы наблюдаете большую вострбованность?
Стали бы вы втягиваться в эту область с проседанием по зарплате, но с какой-либо перспективой (развиться и получать больше, чем просто разработчик на java/python, решать интересные задачи)?