Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Хм… а у Адама на ноуте, я так понимаю, стоит SSD? Просто обычный HDD никак не может выдать 270 МБ/сек… Ну и применение BigData инструментов для таких маленьких данных… это да, просто смешно.
И (отвечая на не заданный здесь вопрос) я полностью согласен с Девидом Кантором в его утверждении, что BigData начинаются там, где уже невозможно весь набор данных поместить в память сервера. Для текущих конфигураций 2х-сокетных серверов это где-то в районе 3ТБ twitter.com/thekanter/status/559034352474914816
Все что меньше по размеру — «не очень Big Data»
Все что меньше по размеру — «не очень Big Data»
Кстати, если кто не знает Дэвида Кантера — он лучший специалист вне интел по архитектуре процессоров x86. www.realworldtech.com
Даже, работая в Интеле, я предпочитал по его статьям изучать архитектуру Nehalem, даже и имея доступ к HAS/MAS.
Даже, работая в Интеле, я предпочитал по его статьям изучать архитектуру Nehalem, даже и имея доступ к HAS/MAS.
На таком объеме данных, это может быть и HDD, просто на N-ный прогон ядро уже держало все файлы в RAM кэше.
webkumo да, думаю у него был SSD. И да это был не очень большой объем данных, чтобы применять MapReduce и кластеры. О чем собственно вся статья и была написана.
По поводу
[Непонятно, почему он сразу не запускал это как `grep Result *.pgn`?]
Трюк заключается в том, что в некоторых ситуациях cat file | grep работает эпично быстрее на некоторых типах условий, чем просто grep.
По ходу grep таки сначала полностью загружает файл в память и только потом обрабатывает (не для всех условий выборки). Есть другая гипотеза, что grep загружает файл неоптимальными chunk'ами.
Разница в некоторых случаях достигала grep — 3 часа cat | grep — 30 сек. Воспроизвести не смогу за давностью (2 года назад был опыт)
[Непонятно, почему он сразу не запускал это как `grep Result *.pgn`?]
Трюк заключается в том, что в некоторых ситуациях cat file | grep работает эпично быстрее на некоторых типах условий, чем просто grep.
По ходу grep таки сначала полностью загружает файл в память и только потом обрабатывает (не для всех условий выборки). Есть другая гипотеза, что grep загружает файл неоптимальными chunk'ами.
Разница в некоторых случаях достигала grep — 3 часа cat | grep — 30 сек. Воспроизвести не смогу за давностью (2 года назад был опыт)
Хмм, интересно.
С учетом того что загрузка больше одной строки в grep не имеет смысл т.к. все регулярные выражения все равно однострочные, то это поведение не имеет большого смысла. Но объяснило бы результаты. Надо исходники посмотреть…
С учетом того что загрузка больше одной строки в grep не имеет смысл т.к. все регулярные выражения все равно однострочные, то это поведение не имеет большого смысла. Но объяснило бы результаты. Надо исходники посмотреть…
Воспроизвел
fallocate -l 1G test
cat test | grep -E [0-9]
# «прогреваем кэш»
time -p cat test | grep -E [0-9]
real 0.95
user 0.61
sys 0.57
time -p grep -E [0-9] test
real 3.32
user 2.63
sys 0.69
fallocate -l 1G test
cat test | grep -E [0-9]
# «прогреваем кэш»
time -p cat test | grep -E [0-9]
real 0.95
user 0.61
sys 0.57
time -p grep -E [0-9] test
real 3.32
user 2.63
sys 0.69
Интересно, я бы сравнил логи `strace -e trace=open,read` в обоих случаях, перед тем как делать догадки.
grep and awk and sed are for processing files. Obviously processing is going to involve more processing power than not processing the file and only outputting its contents as-is.
Воу-воу, у меня первое отрабатывает секунду, а второе отрабатывало 157 секунд (!!), загружая CPU на 100%, при этом процесс был running и я его не мог убить даже SIGKILL от рута. Такое поведение наблюдается каждый запуск.
strace -p $(pidof grep) просто замораживается после Process … attached, аналогично и gdb.157 секунд, но отработало. У знакомого был пример, когда на macos вообще не отработало за 20 минут.
Ага, это, похоже, был баг в ядре! У меня lseek на 64 КБ вперед делался 2 минуты. После обновления ядра, вроде, нормально.
Отличный багрепорт, спасибо, Влад!
т.е. если, допустим, использовать dd из /dev/zero для создания заполненного фала, а не sparse файла, то будет честнее и ближе к жизни. Так получилось, что в данном случае наткнулись на странный баг в ext4. И пока не знаем почему grep с файлами медленнее. Если это действительно так.
т.е. если, допустим, использовать dd из /dev/zero для создания заполненного фала, а не sparse файла, то будет честнее и ближе к жизни. Так получилось, что в данном случае наткнулись на странный баг в ext4. И пока не знаем почему grep с файлами медленнее. Если это действительно так.
У меня grep с файлами быстрее.
dd if=/dev/zero of=test33 bs=1M count=1024
time grep '1' test33 — меньше 1 секунды (0.929 в среднем)
time cat test33 | grep '1' — больше 1 секунды (1.046 в среднем)
При этом, во время cat слышно очень частую работу оперативки (дроссели шуршат). Да и в valgrind callgrind видно, что при первом варианте происходит около 750 тысяч вызовов функций, а при втором — 5 миллиардов (!!)
dd if=/dev/zero of=test33 bs=1M count=1024
time grep '1' test33 — меньше 1 секунды (0.929 в среднем)
time cat test33 | grep '1' — больше 1 секунды (1.046 в среднем)
При этом, во время cat слышно очень частую работу оперативки (дроссели шуршат). Да и в valgrind callgrind видно, что при первом варианте происходит около 750 тысяч вызовов функций, а при втором — 5 миллиардов (!!)
копирование данных в /dev/null [...] занимает 13 секунд, и для массива 3.46ГБ это означает 272МБ/сек
выполнить обработку за 12 секунд, что составляет 270 МБ/сек
Магия!
Хадуп для того и нужен, что он продолжает работать тогда, когда ресурсов 1-2 машин уже недостаточно.
Ествественно, ценой потери эффективности, вы получаете возможность обработать весь массив данных.
Ествественно, ценой потери эффективности, вы получаете возможность обработать весь массив данных.
А если поменять xargs на parallel, то можно ещё и прозрачно загрузить подсчётами все ядра системы, и получить ещё больший буст.
И даже ядра на удаленных машинах по SSH. parallel — мега-штука.
Спасибо Komzpa за ссылку — не слышал. Посмотрел, и штука дейтсвительно интересная. Если надо удобно параллелить/распределять скрипты между узлами/ядрами. Есть где поиспользовать уже в ближайшее время
Но в данном случае `parallel` думаю не дал бы никакого выигрыша т.к. автор сам распараллеливал на все имеющиегося у него ядра через опцию -P 4 у xargs.
Но в данном случае `parallel` думаю не дал бы никакого выигрыша т.к. автор сам распараллеливал на все имеющиегося у него ядра через опцию -P 4 у xargs.
Если там было 4 ядра, то по сути xargs -P 4 то же самое что и parallel, так что буста не будет.
Это примерно как сранивать сортировку пузырьком и квиксорт на массиве из двух-трёх элементов :)
BigData — это не про размер, а про операбельность. Допустим, возьмем такой же набор данных и следующую задачку. Игровой шахматный сервер и каждому игроку показываеть его место в ранке по количеству побед. Там где для исследователя 12 секунд еще допустимо, для игрока — это отказ в обслуживании по таймауту. Не говоря уже о том, что на самом деле исследователи также подвержены эмоциональной деградации из-за любой операции дольше миллисекунд.
Вы уверены, что правильно выразили свою мысль? Пока больше на бред какой-то смахивает. Тем более, что инструменты BigData слабо приспособлены для выполнения операций не «дольше миллисекунд»… Точнее они просто не про скорость работы.
Не очень хороший пример с пересчетом рейтинга. Как часто у нас в данном примере надо пересчитывать его: при каждом запросе, каждую секунду, каждую минуту, каждый час?
Или только по завершении партии?
(Ответ: Рейтинги надо хранить подсчитанными и пересчитывать их только при изменении данных, которые меняются не чаще чем Н секунд/минут (как функция средней продолжительности партии и среднего количества параллельно активных партий — ср.длина/ср.параллелизм)
Я бы очень не рекомендовал пытаться пересчитывать рейтинг по каждому запросу, обеспечивая «реал-тайм рейтинг». Зря только электроны гонять)
Или только по завершении партии?
(Ответ: Рейтинги надо хранить подсчитанными и пересчитывать их только при изменении данных, которые меняются не чаще чем Н секунд/минут (как функция средней продолжительности партии и среднего количества параллельно активных партий — ср.длина/ср.параллелизм)
Я бы очень не рекомендовал пытаться пересчитывать рейтинг по каждому запросу, обеспечивая «реал-тайм рейтинг». Зря только электроны гонять)
Статья слишком однобокая в том, что не сказано в чем таких задержек на хадупе. И тем более 7 машин — это не тот размер кластера, который был бы подходящим по идеологии. И тем более, не сказано что вместо 7-ми машин можно взять 7 тысяч и изменить этот параметр можно за секунду. А вот с ноутбуком такой фокус проделать нельзя.
А будет ли это эффективно с финансовой точки зрения? Нет, я серьезно. Можно конечно запустить 1000 виртуализированных Sandy Bridge ядер, которые при сравнении лов-в-лоб, конечно, работают в 5 раз медленнее физического Haswell ядра, но навалившись, гуртом и большой компанией дающих выигрыш в 100 раз (при условии бесконечно параллелизуемого алгоритма). Но какой ценой будет это достигнуто? Сколько денег за электричество вы заплатите для обслуживания такой виртуализированной фермы? Будет ли такое решение предоставлять результат быстрее накладных расходов на планировщик и задержек на возврат результата?
Ведь по большому счету вся история про облака и кластеры началась с основной идей — не платить миллионы$ за большой сервер а поставить 100 commodity server-ов и получить решение эффективное с точки зрения стоимости Ватта. Если в вашем Hadoop решении, для того чтобы его сделать в 10 раз, надо заплатить, скажем, в 100 раз больше на инфраструктуру, то может ну его на фиг? Может и по старинке иногда? Задумываясь об алгоритмах и задержках, и не всегда полагаясь на волшебство BigData?
Ведь по большому счету вся история про облака и кластеры началась с основной идей — не платить миллионы$ за большой сервер а поставить 100 commodity server-ов и получить решение эффективное с точки зрения стоимости Ватта. Если в вашем Hadoop решении, для того чтобы его сделать в 10 раз, надо заплатить, скажем, в 100 раз больше на инфраструктуру, то может ну его на фиг? Может и по старинке иногда? Задумываясь об алгоритмах и задержках, и не всегда полагаясь на волшебство BigData?
А если при реальном увеличении объема данных, которые нужно обабатывать взять Joyent Manta, то и конвейеры имеющиеся можно будет использовать.
Спасибо, Борь dolphin278 за ссылку на Манта. Не знал. Сразу не понял каким образом это можно применить к нашему случаю, но там есть хорошие, и я бы даже сказал классические примеры, и стало понятно. Это довольно типичный сервис grid вычислений, с распределенным планировщиком задач, но обернутый в модный JSON.
Очень сильно напомнил мне NetBatch который в Intel-е используют для тестирования в своих серверных фермах (не думаю, что он известен за пределами Intel). Там не было модного JSON, но все остальное как и здесь.
P.S.
Одна проблема с такими грид средами — накладные расхода на формирование контекста, постановку в очередь, разворачивание контекста. запуск, сбор результата, и возврат данных — ООЧЕНЬ большие. Для таких элементарных заданий как описана здесь, когда сам прогон несколько минут, такие накладные расходы на планировщик и инфраструктуру чрезмерны.
Очень сильно напомнил мне NetBatch который в Intel-е используют для тестирования в своих серверных фермах (не думаю, что он известен за пределами Intel). Там не было модного JSON, но все остальное как и здесь.
P.S.
Одна проблема с такими грид средами — накладные расхода на формирование контекста, постановку в очередь, разворачивание контекста. запуск, сбор результата, и возврат данных — ООЧЕНЬ большие. Для таких элементарных заданий как описана здесь, когда сам прогон несколько минут, такие накладные расходы на планировщик и инфраструктуру чрезмерны.
Так тут не в JSON'е дело — ты можешь выполнять операции на кластере используя привычные shell-утилиты и логику работы, т.е. получается тот же способ решения задач, который ты используешь на локальной машине с консольными утилитами может быть перенесен на работу в мантовском гриде.
Что, конечно, имеет смысл делать в том случае, когда данных становится реально много, т.е. исходный тезис статьи.
Что, конечно, имеет смысл делать в том случае, когда данных становится реально много, т.е. исходный тезис статьи.
Да, согласен, это подходит если уже есть распараллеленый алгоритм на утилитах (что у нас было, когда добавляли стадию reduce дополнительным awk-ом) и при дальнейшей необходимости расширять счетные ресурсы вширь, то можно это запустить на Joyen Manta, ранее озвученном GNU parallel или каком другом классическом grid планировщике.
кто попробует то же самое только на Go или python async?:)
Возможно применение ag (silver search) ещё ускорило бы. Это скорее ack чем grep, но для данной задачи бы подошёл идеально.
boyer-moor + fmap() + pcre jit + pthreads.
boyer-moor + fmap() + pcre jit + pthreads.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Утилиты командной строки могут быть в 235-раз быстрее вашего Hadoop кластера