Комментарии 52
Надо больше смешных картинок.
Как обрабатывать терабайты данных в 1000 потоков на PHP — Hadoop/MapReduce
Т.е. бросаем PHP и берём Java?:)
Зачем? Все делаем на PHP/bash/Python — и подключаем лишь библиотечку, которая может нашу логику раскидать на 5-500 серверов, прогнать по данным и вернуть ответ :-)
На самом деле на жаве мап/редьюс джобы написать проще и работало бы быстрей.
Жаву не очень любят в мире быстрых вычислений, unix и C ;-) Она медленная, жирная, много требует и при этом постоянно подвисает на сборках мусора. А пригрузив готовый софт на java задачками, написанными на perl/bash или просто вызвав юниксовую команду типа sort/grep — почему бы и нет? :-)
Т.е. PHP любят в мире быстрых вычислений, а Java — нет? о_О
Ну. PHP это язык-сборщик, выполняет типа роль клея для состыковки возможностей многочисленных библиотек, часто активно обитающих в unix. Бизнесовая технология — соединил высокопроизводительные библиотеки и запустил в сжатые сроки.
А java претендует на роль «безалкогольного» С++/C, оперирует почти примитивными типами данных и как-бы предназначена для написания компонентов для PHP. Но проблема в том, что компоненты на java почти не используют ни в PHP, ни в python — предпочитая использовать быстрые C-библиотеки.
И получается что стек: C/C++/unix/PHP — дает быстрый результат в ожидаемые сроки, а java + java — это дольше, тяжелее, и библиотек под нее значительно, в разы меньше, чем можно взять в opensource и вызывать через механизм плагинов PHP.
А java претендует на роль «безалкогольного» С++/C, оперирует почти примитивными типами данных и как-бы предназначена для написания компонентов для PHP. Но проблема в том, что компоненты на java почти не используют ни в PHP, ни в python — предпочитая использовать быстрые C-библиотеки.
И получается что стек: C/C++/unix/PHP — дает быстрый результат в ожидаемые сроки, а java + java — это дольше, тяжелее, и библиотек под нее значительно, в разы меньше, чем можно взять в opensource и вызывать через механизм плагинов PHP.
Я о том, что у java своя очень специфическая ниша, т.к. ей не получилось гармонично встроится в стек C/C++/unix/PHP/Python/Perl — а попытки сделать это не прекращаются и поныне.
Именно поэтому нет особого смысла вместо PHP использовать Java, ну только в ряде исключительных случаев где нужен JIT и более совершенная сборка мусора :-)
Именно поэтому нет особого смысла вместо PHP использовать Java, ну только в ряде исключительных случаев где нужен JIT и более совершенная сборка мусора :-)
Так и скажите, что вам Java не нравится ;-)
Очень нравится! Особенно тщательность проектирования API, продуманное использование паттернов проектирования — этого так не хватает скриптовым языкам типа знаете каких. Java учит мыслить системно, объектно. Да и сколько бизнесового софта, полезного, тот же Amazon Web Services частями на ней написаны :-)
Это заблуждения, то что она медленная
Лично проверял, в т.ч. на проектах с активным использованием JBoss :-) Проблема java — увлечение ООП и плохо предсказуемый сборщик мусора. В результате дикие требования к железу и памяти. JIT по идее должен ее ускорить и он делает это иногда, но до сих пор неумело и не очень уместно. А GUI на java — просто подвисающий ад какой-то: от NetBeans до Eclipe и JDeveloper.
Не верю, что появится технология с автоматическим управлением памятью с высокой скоростью работы, близкой к C. Если только если процессоры под ООП заточат, но тоже сомнительно.
Не верю, что появится технология с автоматическим управлением памятью с высокой скоростью работы, близкой к C. Если только если процессоры под ООП заточат, но тоже сомнительно.
Лично проверял, в т.ч. на проектах с активным использованием JBoss :-)
Это как измерять максимальную скорость, доступную автомобилям, при помощи самосвала КРАЗ.
Сравните код на С с аналогичным на Java — разница налицо. Объект на объекте и объектом погоняет пока не доберется до системного вызова read и прочитает 1 байт ;-)
Я 15 лет пишу на C высокоэффективные приложения, и около 10 — на Java. Java может быть очень быстрой, медленнее C, но всё равно очень быстрой. С Java проблемы возникают не из-за технологии, а из-за непонимания разработчиками того, что они делают и во что это выльется в реальности.
Согласен, она может быть очень быстрой когда сработает JIT через определенное время в серверном режиме виртуальной машины. Но она живет в собственном виртуальном мире, которому требуется виртуальная машина с кучей потрохов и скорость запуска этого мира…
Конкретный практический пример. Амазон кстати сначала сделал консольные утилиты работы с их API на java, но через определенное время переписал их на python.
Мы из bash первое время дергали маскирующиеся под unix-команды вызовы API с java и под нагрузкой машина просто начинала сходить с ума, падало ядро linux с ожиданиями блокировок или CPU уходило под 100%.
Пришлось вырезать java вызовы из bash-автоматики и переходить на более легкие интерфейсы к API Амазона на PHP/python. Нагрузка уменьшилась в разы.
Конкретный практический пример. Амазон кстати сначала сделал консольные утилиты работы с их API на java, но через определенное время переписал их на python.
Мы из bash первое время дергали маскирующиеся под unix-команды вызовы API с java и под нагрузкой машина просто начинала сходить с ума, падало ядро linux с ожиданиями блокировок или CPU уходило под 100%.
Пришлось вырезать java вызовы из bash-автоматики и переходить на более легкие интерфейсы к API Амазона на PHP/python. Нагрузка уменьшилась в разы.
Мы из bash первое время дергали маскирующиеся под unix-команды вызовы API с java и под нагрузкой машина просто начинала сходить с ума, падало ядро linux с ожиданиями блокировок или CPU уходило под 100%.
Ну всё абсолютно логично, потому что у Java большие издержки за запуск VM. Вы привели как раз пример непонимания того, как надо готовить
Одно время назад реализовал на PHP сервер, использующий мультиплексор сокетов в одном процессе через select. Тут наверно java бы лучше подошла с ее качественно иной сборкой мусора и JIT и работала бы побыстрее ;-)
Люблю азиаток :) А еще «мастер-мастер-кластер» — забавно звучит.
Поправил на «мульти-мастер кластер», но они его сами так называют смешно сейчас :-)
www.mysql.com/products/cluster/scalability.html
www.mysql.com/products/cluster/scalability.html
Я вроде отписывался от блога Битрикса, а оно в ленте…
Статья, если честно, пустая, но за ссылочки спасибо, буду знать куда смотреть, если что.
И мне кажется, или самолетами по данным с аварийных самописцев не управляют?
Статья, если честно, пустая, но за ссылочки спасибо, буду знать куда смотреть, если что.
И мне кажется, или самолетами по данным с аварийных самописцев не управляют?
А вы хотели подробности по Map/Reduce изнутри? Но кому это интересно будет.
терабайты данных, 1000 потоков и PHP?
ну или хотя бы что-нибудь наглядное, на вашем же примере с битриксом и описание задачи, которая у вас занимала столько времени и была прекрасно решена с помощью MR?
почему
ну или хотя бы что-нибудь наглядное, на вашем же примере с битриксом и описание задачи, которая у вас занимала столько времени и была прекрасно решена с помощью MR?
почему
$ar_reduce = array();
Я понял, смотрите пример. Есть задача сжать, зашифровать и перенести 10 млн. файлов из бакета1 s3 в бакет2 s3.
Если делать средствами PHP на сервере, то можно форкануть максимум ну 20-30 потоков PHP, которые будут каждый выполняться в своем процессе. И это займет несколько недель. А объем данных растет и нужно системное решение.
Если то же самое делать средствами Hadoop, то задачу можно выполнить за час, но на большом количестве железок. Если выбрать разумное число железок с 15 потоками на каждой — то можно уложиться в 2 дня.
Т.е. если через полгода число файлов для обработки вырастит с 10 млн. до 50 млн., нужно будет поменять лишь одну циферку в конфиге запуска кластера Hadoop, увеличив число железок лишь.
Красиво же получается и просто. Разве не так?
Если делать средствами PHP на сервере, то можно форкануть максимум ну 20-30 потоков PHP, которые будут каждый выполняться в своем процессе. И это займет несколько недель. А объем данных растет и нужно системное решение.
Если то же самое делать средствами Hadoop, то задачу можно выполнить за час, но на большом количестве железок. Если выбрать разумное число железок с 15 потоками на каждой — то можно уложиться в 2 дня.
Т.е. если через полгода число файлов для обработки вырастит с 10 млн. до 50 млн., нужно будет поменять лишь одну циферку в конфиге запуска кластера Hadoop, увеличив число железок лишь.
Красиво же получается и просто. Разве не так?
Зачем нужен MR и Hadoop я более или менее представляю. И примеров его использования я также могу придумать много. Просто в таком случае я не представляю какой смысл в этой статье, поскольку вряд ли здесь описано что-то совершенно новое (или у вас задача и была только лишь в том, чтобы перенести 10 млн файлов?) и, наверное, у самого амазона есть туториалы как все это у них завести на PHP.
Вопрос только лишь в том, действительно ли это задача для PHP или же нет.
Возможно, я ошибаюсь.
Вопрос только лишь в том, действительно ли это задача для PHP или же нет.
Возможно, я ошибаюсь.
Смысл в том, что готовых примеров боевого использования PHP + Hadoop я как не искал — не нашел. Было немного воды по Hadoop + Python. Пришлось весь путь преодолевать пробивая головой стены и ловя подводные камни. Зато результат превзошел все ожидания. Теперь делюсь с коллегами опытом :-)
А на java, которую я хорошо знаю и люблю — примеров полно, но разбираются в java — очень ограниченное число людей. И еще одной целью была принести полезные решения из этой области в мир веб-разработчиков на PHP ;-)
А, забыл, на входе у вас список названий файлов из 10 млн. позиций.
Убрал лишний массив, опечатка, спасибо.
Вы правы! Самолетами не управляют с аварийных самописцев, выделю жирным и подчеркну :-)
На Storm не смотрели?
Если кластер — мульти-мастер
Никакой он Вам не кластер
Он уже тупящий сид
Если вдруг позволит GID
Прочитай про map-reduce
Форкни и забудь про fuse
Файлы полетят в Hadoop
Вроде ты уже не нуб!
Больше скриптов-канапэ
Ты пиши на ПохАпэ
Девок фотки изучай
На спартанцев — не кончай!
Новый бизнес-инструмент
Развернешь теперь в момент
Весь поток в S3 летит
Ну и менеджер хвалит
Число серверов растет
Прибыль наша вверх идет
Обработку сократили
Всех с bigdat'ой победили!
Никакой он Вам не кластер
Он уже тупящий сид
Если вдруг позволит GID
Прочитай про map-reduce
Форкни и забудь про fuse
Файлы полетят в Hadoop
Вроде ты уже не нуб!
Больше скриптов-канапэ
Ты пиши на ПохАпэ
Девок фотки изучай
На спартанцев — не кончай!
Новый бизнес-инструмент
Развернешь теперь в момент
Весь поток в S3 летит
Ну и менеджер хвалит
Число серверов растет
Прибыль наша вверх идет
Обработку сократили
Всех с bigdat'ой победили!
Замечательно передали суть поста, допишу музыку и на ютуб! :-)
BigData рэп?)
Если серьезно, то толковой документации по Hadoop Streaming для использования его сисадмином, знающим bash/perl — практически нет. Немного воды лишь про его использование с python где-то в сети валяется. Особенно это касается конфигурации streaming под нагрузку, обработки ошибок, перезапуска заданий и т.п. Однако инструмент то полезный и нужный в быту, сами хорошо знаете.
Амазон имхо молодцы, что собрали из этого конструктора работающее решение из коробки, которое теперь сможет освоить даже сисадмин и маппить файлы на bash или дергая утилиты unix прямо из маппера.
А после поста — это сделает даже веб-разработчик на PHP :-)
Амазон имхо молодцы, что собрали из этого конструктора работающее решение из коробки, которое теперь сможет освоить даже сисадмин и маппить файлы на bash или дергая утилиты unix прямо из маппера.
А после поста — это сделает даже веб-разработчик на PHP :-)
>> Как бы мы не доверяли облаку, нужно эти файлы периодически выгружать в другое облако/серверы
Сказали они и выгрузили из S3 в S3.
А если серьёзно, нужно иметь хотябы насколько аккаунтов AWS на разных юрлиц. Или вообще хранить самую резрвную копию в другом облаке.
Сколько бы контейнеров в AWS не было, есть главный риск — амазон административно, извините, пукнет отказом в обслуживании в вашу сторону по любой причине.
От административных отказов, к сожалению, никто не застрахован.
Сказали они и выгрузили из S3 в S3.
А если серьёзно, нужно иметь хотябы насколько аккаунтов AWS на разных юрлиц. Или вообще хранить самую резрвную копию в другом облаке.
Сколько бы контейнеров в AWS не было, есть главный риск — амазон административно, извините, пукнет отказом в обслуживании в вашу сторону по любой причине.
От административных отказов, к сожалению, никто не застрахован.
Абсолютно верно. Поэтому мы используем как минимум 2 конфигурации hadoop-кластеров. Один для копирования ( s3 условный COPY) из s3 в s3 — достаточно несколько машин, а другой, значительно более мощный — именно для выгрузки файлов на сторонние мощности за пределами Амазона — и только в этом случае, как я писал выше, файлы скачиваются в общую файловую систему Hadoop (HDFS), шифруются, подписываются и копируются из облачного провайдера.
Мапредьюз можно писать на чем угодно Тьюринг-полном, только вопрос — зачем?
Все, что было спроектировано после Хадупа, уже позволяет писать задачи не на языке реализации, как в вашем случае, без стольких лишних телодвижений.
Все, что было спроектировано после Хадупа, уже позволяет писать задачи не на языке реализации, как в вашем случае, без стольких лишних телодвижений.
MR пакетный. Когда появляется задача «надо много и на потоке», то MR уже не кажется таким прекрасным
Организовать сбор статистики по производительности веб-приложения в браузере его клиентов на основании js Navigation Timing API — делается в 2 файла на PHP на 30 строк.
А можно примеров рабочих увидеть? В сети такой информации не нашел. Нужно системно собрать статистики на несколько тысяч сайтов по списку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как обрабатывать терабайты данных в 1000 потоков на PHP — Hadoop/MapReduce