Comments 26
Прошу не закидывать меня помидорами, но лично мой опыт использования Pig оказался скорее негативным.
1) Он действительно медленный. Это скорее болезнь Hadoop, лежащего в основе. Данные размером в 32Гб обрабатывались 15 минут, причем расход оперативки составил 91Гб? 180 млн записей? Простите, да банальнейший кластер Postgres сделал бы то же самое, да еще и (возможно) быстрее. С Hive та же беда.
2) Подмножество Pig Latin SQL после перехода от «обычного» SQL, используемого в MySQL, Postgres и т.п. RDBMS, скорее мешает, нежели чем помогает. Парадигма Map-reduce не так уж сложна для восприятия, и лично мне намного проще накидать MR-воркер на том же Питоне, чем вникать в ограничения Pig SQL. Даже с Hive это чувствовалось.
3) По деньгам — зачастую краткосрочная аренда мощного SSD сервера и обработка данных там, используя привычный инструментарий, дает бОльший бизнес-профит.
3) На Хабре была уже статья — «у вас нет столько данных». Hadoop очень, очень медленный, сложный и неудобный (кто хоть раз пытался разобраться в exception логах, поймет). Его применения оправдано только в случае действительно больших данных (навскидку, от нескольких терабайт), и зоопарка серверов. Вы не поверите — простейший однопоточный скрипт на Питоне на данных порядка 200Гб оказывался быстрее, чем хваленый Хадуп (сравнивалась single-node инсталляция). Чего уж там говорить про Яву или Го или Си. Хадуп — один из немногих инструментов для обработки действительно больших данных, но на данных средних размеров он бесполезен.
Все, что я написал выше — следствие многомесячных экспериментов в стартапе, у которого обработка данных — основной бизнес-процесс. Перепробовано было множество инструментов, и Хадуп, и Хайв, и Пиг, и Кассандра, и Монго, и Диско, и Постгрес с Мускулем и самописные решения на Питоне. Модные инструменты — не значит эффективные.
P.S. Прошу прощения за кальки с английского — переключать постоянно раскладки слишком уж утомительно.
1) Он действительно медленный. Это скорее болезнь Hadoop, лежащего в основе. Данные размером в 32Гб обрабатывались 15 минут, причем расход оперативки составил 91Гб? 180 млн записей? Простите, да банальнейший кластер Postgres сделал бы то же самое, да еще и (возможно) быстрее. С Hive та же беда.
2) Подмножество Pig Latin SQL после перехода от «обычного» SQL, используемого в MySQL, Postgres и т.п. RDBMS, скорее мешает, нежели чем помогает. Парадигма Map-reduce не так уж сложна для восприятия, и лично мне намного проще накидать MR-воркер на том же Питоне, чем вникать в ограничения Pig SQL. Даже с Hive это чувствовалось.
3) По деньгам — зачастую краткосрочная аренда мощного SSD сервера и обработка данных там, используя привычный инструментарий, дает бОльший бизнес-профит.
3) На Хабре была уже статья — «у вас нет столько данных». Hadoop очень, очень медленный, сложный и неудобный (кто хоть раз пытался разобраться в exception логах, поймет). Его применения оправдано только в случае действительно больших данных (навскидку, от нескольких терабайт), и зоопарка серверов. Вы не поверите — простейший однопоточный скрипт на Питоне на данных порядка 200Гб оказывался быстрее, чем хваленый Хадуп (сравнивалась single-node инсталляция). Чего уж там говорить про Яву или Го или Си. Хадуп — один из немногих инструментов для обработки действительно больших данных, но на данных средних размеров он бесполезен.
Все, что я написал выше — следствие многомесячных экспериментов в стартапе, у которого обработка данных — основной бизнес-процесс. Перепробовано было множество инструментов, и Хадуп, и Хайв, и Пиг, и Кассандра, и Монго, и Диско, и Постгрес с Мускулем и самописные решения на Питоне. Модные инструменты — не значит эффективные.
P.S. Прошу прощения за кальки с английского — переключать постоянно раскладки слишком уж утомительно.
ни в коем случае не опровергая Вами сказанное (сам хотел добавить, что Vectorwise подобные подсчеты на 500 млн строк да еще и с джойном с таблицей из 10 млн строк выдал за 17 секунд в однонодовой конфигурации с 64 гигами и 8 ядрами), однако, в БД данные надо еще и загрузить. Прикинув свои данные, которые я запихиваю в VW при помощи DataStage, у меня получилось, что ETL съедает весь профит дальнейшего быстрого выполнения SQL запросов. Правда, тут все зависит от специфики задач. Все-таки данные загружаются один раз, а обращаться к ним можно вечно.
Ваш 3 пункт всё объясняет. Да, даже 100Гб это не тот объем данных, для кторых стоит использовать Hadoop MR.
Плюс вопрос масштабирования, вы сможете сделать кластер Postgres из 100 нод? Насколько хорошо при этом будет масштабироваться производительность? Hadoop MR масштабируется практически линейно.
Если вы программист, то да, наверное проще написать свое MR приложение. Но если вам требуется делать различные выборки и экспериментировать с поиском, расчетами и алгоритмами, то зачастую проще и эффективне использовать Pig. К тому же он позволяет включатьв код произвольные внешние скрипты хоть на Python, хоть на Bash.
Конечно для каждой задачи необходимо выбирать инструмент по «размеру» =) Эта статья- всего лишь пример для новичков в Hadoop.
Плюс вопрос масштабирования, вы сможете сделать кластер Postgres из 100 нод? Насколько хорошо при этом будет масштабироваться производительность? Hadoop MR масштабируется практически линейно.
Если вы программист, то да, наверное проще написать свое MR приложение. Но если вам требуется делать различные выборки и экспериментировать с поиском, расчетами и алгоритмами, то зачастую проще и эффективне использовать Pig. К тому же он позволяет включатьв код произвольные внешние скрипты хоть на Python, хоть на Bash.
Конечно для каждой задачи необходимо выбирать инструмент по «размеру» =) Эта статья- всего лишь пример для новичков в Hadoop.
Конечно, если нужно 100 нод, то здесь надо брать специализированные решения. Постгрес на 100 нод даже представлять страшно =) С другой стороны, пара-тройка серверов запросто способна обрабатывать те же 100 Гб значительно быстрее, чем за 15 минут. Про выборки и эксперименты… Наверное это дело субъективное, но в общем-то меня действительно сбивает с толку синтаксис Pig, да и отладка всего этого дела довольно мучительна. А Вы не смотрели в сторону других решений? Cassandra, к примеру, тоже использует подмножество SQL, и работать с ней (лично по моим ощущениям) оказалось очень приятно, просто и понятно. Или, к примеру Hive (у него синтаксис, насколько я помню, шире чем у Pig и даже Impala).
Первое правило кластеростроения — тестировать производительность любого кластерного решения только на рельном физическом кластере. Никакие однонодовые инсталляции и всякие виртуализации в рамках одной ноды никогда не дадут вам реальных результатов. Вы не получите производительности больше, чем ее есть у вас физически, при этом, не кластерные продукты в рамках одной ноды, однозначно выиграют, т.к. утилизируют эту производительность эффективнее.
Не совсем понял, зачем здесь строить большие кластеры. Мы же не играем в игру «построй кластер», а решаем вполне конкретную задачу. 32Гб это очень, очень мало. Хватит одного мощного сервера. Да что там, такой объем данных даже в RAM поместиться может. О том и был мой комментарий — Хадуп для действительно больших данных и зоопарков из нод, в случае, если же big data не очень уж «big» — то эффективнее в большинстве случаев использовать что-то другое. Я просто по роду деятельности часто сталкиваюсь с тем, что люди лепят Хадуп где только ни попадя, разворачивая лишние ноды или просто используя single-node инсталляцию (неэффективную, Вы правы). Вот в этом и была основная мысль — летать в соседний магазин на вертолете конечно круто и трендово, но доехать на машине будет проще, быстрее и дешевле.
Это довольно частое заблуждение, что кластеризация нужна только для обработки большого количества данных. Важно не количество данных, а характер выполняемых с ними операций. То, что ваши 32Гб легко влезают в память, не значит что для любой задачи вы сможете быстро, а в общем случае, вообще, обработать эти данные в памяти, или, даже, в рамках всех, включая дисковые, ресурсов одной ноды. Ваши «маленькие» данные могут легко породить декартово произведение фантастических размеров. Например, ваши 32Гб это логи посещений вашего ресурса, а получить вам нужно, скажем, список уникальных IP адресов никогда не загружавших одинаковые страницы в интервале 5 минут ))
Опять соглашусь с Вами и плюсану Ваш комментарий, если хватит кармы. Но есть одно «но» — Hadoop, а тем более Pig, абсолютно не предназначены для быстрой обработки данных. У автора поста на все ушло 15 минут — это довольно много. Тот же Spark, например, гораздо больше подходит для быстрой обработки. Стало даже классикой жанра сравнивать скорость Хадупа и Спарка и показывать, что Спарк может быть быстрее в сотни раз. Или какая-нибудь MemSQL, если данных не очень много. В общем, основная моя мысль — Hadoop это инструмент для обработки огромных объемов данных на сотнях машин, и больше. Задачи меньшего масштаба можно — зачастую — решить более привычными и удобными инструментами за меньшее время и деньги. Не то чтобы Хадуп вообще не подходит для мелких данных — конечно подходит — просто вопрос скорее оптимизации процессов, нежели чем решающего выбора инструмента.
Вы все время делаете отсылки к различным БД, но вся соль Pig и классического Hadoop в обработке очень больших объемов сырых данных (в общем случае просто файлов).
Проверил обработку 300Гб данных, выполнилась за 150 минут, т.е. имеем линейный рост. Если увеличить число нод в 10 раз, то и скорость увеличится в 10 раз. При этом никакой мороки по настройке и оптимизации, так сказать «грубая сила» =)
Если нужна скорость, то тут конечно надо использовать надстройки над HDFS с индексами и прочим, наример, Impala или Hive.
Проверил обработку 300Гб данных, выполнилась за 150 минут, т.е. имеем линейный рост. Если увеличить число нод в 10 раз, то и скорость увеличится в 10 раз. При этом никакой мороки по настройке и оптимизации, так сказать «грубая сила» =)
Если нужна скорость, то тут конечно надо использовать надстройки над HDFS с индексами и прочим, наример, Impala или Hive.
1. Медленный по сравнению с чем? И это не болезнь, это называется batch processing.
2. Это не SQL, Pig latin процедурный, а SQL- декларативный. Вы пытаетесь сравнить теплое со сладким.
3. Если нет SLA и все можно сделать на коленке, то да.
Конечно поверю, потому что Хадуп, это от 5 нод. Странно сравнивать распределенную систему, установленную на одном узле с однопоточной программой. Чего вы пытались добиться этим сравнением?
2. Это не SQL, Pig latin процедурный, а SQL- декларативный. Вы пытаетесь сравнить теплое со сладким.
3. Если нет SLA и все можно сделать на коленке, то да.
Вы не поверите —
Конечно поверю, потому что Хадуп, это от 5 нод. Странно сравнивать распределенную систему, установленную на одном узле с однопоточной программой. Чего вы пытались добиться этим сравнением?
1. Медленный по сравнению с однопоточными скриптами, Spark'ом или хотя бы минимально настроенным Postgres'ом. Это — если мы берем сравнительно небольшие данные (а 32Гб — это небольшой объем).
2. Не так важно, как это называется, как важно то, как это работает. А работает это — лично по моему мнению, да и не только по моему — довольно неудобно.
3. О том и речь — ситуации разные.
Вы наверное не полностью прочитали мой комментарий. Я писал, что Хадуп — это один из немногих инструментов, которые в принципе позволят обработать терабайты данных. Но для небольших объемов данных существует множество других инструментов, которые оказываются зачастую удобнее, проще, быстрее и в итоге дешевле.
2. Не так важно, как это называется, как важно то, как это работает. А работает это — лично по моему мнению, да и не только по моему — довольно неудобно.
3. О том и речь — ситуации разные.
Вы наверное не полностью прочитали мой комментарий. Я писал, что Хадуп — это один из немногих инструментов, которые в принципе позволят обработать терабайты данных. Но для небольших объемов данных существует множество других инструментов, которые оказываются зачастую удобнее, проще, быстрее и в итоге дешевле.
1. Spark идеологически в корне отличается от всего остального Хадупного хозяйства. Между прочим, HDFS caching может вывести pig на скорость, соизмеримую со Спарком. Вы ставите рядом трактор и Феррари, а потом расстраиваетесь, потому что трактор медленно едет, а в Феррари не влезает картошка.
2. Пытаться процедурный data flow язык сравнить с декларативным SQL? Конечно, это не важно. Ваша аргументация меня удивляет. Linkedin, Spotify, Yahoo, Netflix будут расстроены, узнав что pig работает «неудобно».
Я читал ваши комментарии, меня смущает отсутствие объективности при оценке инструментов. Крайне любопытно узнать, что вас привело к такому.
2. Пытаться процедурный data flow язык сравнить с декларативным SQL? Конечно, это не важно. Ваша аргументация меня удивляет. Linkedin, Spotify, Yahoo, Netflix будут расстроены, узнав что pig работает «неудобно».
Я читал ваши комментарии, меня смущает отсутствие объективности при оценке инструментов. Крайне любопытно узнать, что вас привело к такому.
Все как раз наоборот — люди пытаются на Феррари возить картошку, хотя явно дешевле ее загрузить в Жигули. Об этом я написал черным по белому — 32Гб это очень мало, даже single-node инсталляция того же Постгреса обработала бы данные за сравнимое время. Смысл городить Хадуп?
Вы, кстати, употребили слово «идеологически». Видимо Вам очень важна «идеология», раз Вы принципиально «за» одно решение и «против» других? Дело Ваше, мне же гораздо важнее удобство решения и его стоимость для бизнеса. Кстати, посмотрел Ваш профиль — видимо Вы фанат Хадупа, и Вам «из-за леса деревьев не видно».
Я не собираюсь ни с кем спорить и никому ничего доказывать, мой первый комментарий плюсанули 3 человека — следовательно, не я один так думаю. Простите, больше не вижу смысла продолжать дискуссию.
Вы, кстати, употребили слово «идеологически». Видимо Вам очень важна «идеология», раз Вы принципиально «за» одно решение и «против» других? Дело Ваше, мне же гораздо важнее удобство решения и его стоимость для бизнеса. Кстати, посмотрел Ваш профиль — видимо Вы фанат Хадупа, и Вам «из-за леса деревьев не видно».
Я не собираюсь ни с кем спорить и никому ничего доказывать, мой первый комментарий плюсанули 3 человека — следовательно, не я один так думаю. Простите, больше не вижу смысла продолжать дискуссию.
Напишите статью про результаты «многомесячных экспериментов» со сравнением испробованных альтернатив — это будет хит.
Вряд ли это будет хит, у нас всего лишь 2 терабайта данных суммарно и порядка миллиарда «строк» (в терминах SQL) на выходе — поэтому на фоне объемов Google или Facebook не будет ничего интересного. Могу только сообщить, что стоимость разовой обработки таких данных (а там целый конвейер и много архивирования\разархивирования) — порядка 70-100 руб., если посчитать в ценах Digital Ocean или Amazon. Используемые\использовавшиеся инструменты я примерно описал в первом комментарии, если что-то интересно под конкретную задачу — спрашивайте, с удовольствием поделюсь опытом.
Не прибедняйтесь, очень мало у кого есть опыт экспериментов с кучей систем обработки данных, поэтому такое сравнение из первых рук будет крайне ценно. Обычно берут что-то одно, и вперед.
Хабр читают не только (читают ли?) сотрудники Гугла и Фейсбука, многие ребята с сопоставимым или даже меньшим объемом данных, чем у вас, сейчас думают о big data. Я таки думаю, что это будет хит.
Хабр читают не только (читают ли?) сотрудники Гугла и Фейсбука, многие ребята с сопоставимым или даже меньшим объемом данных, чем у вас, сейчас думают о big data. Я таки думаю, что это будет хит.
Кстати, не сочтите за оффтоп, но из всех серьезных MR-фреймворков лучше всего показал себя не особо известный Disco. Устанавливается в разы быстрее Хадупа, на среднего размера данных ведет себя намного быстрее, очень удобный веб-интерфейс, наглядные traceback ошибок, все «для людей». Не тестировал его на терабайтах данных, но по отзывам все должно быть ок. Тот самый случай, когда удобство сочетается с мощностью и производительностью (в отличие от монструозной Хадуп-экосистемы). Disclaimer: я не имею никакого отношения к разработчикам Disco, просто использую этот инструмент.
Используя готовые дистрибутивы можно развернуть Hadoop за 30 минут и получить в комплекте замечательный Web-интерфейс =) habrahabr.ru/company/selectel/blog/198534/
… и муки отладки в довесок =) Нет, правда, мне есть с чем сравнить — стандартные питоновые traceback'и из Disco отличаются невероятной наглядностью и лаконичностью. Установка — дело не 30, а 10 минут. Вот прямо сейчас с ходу могу припомнить, что, к примеру, файловую систему на Disco форматировать не нужно. Это же очевидно — если человек только-только установил DDFS\HDFS, неужели нельзя отформатировать все автоматически? Вот эта избыточность в логах, необходимость лишних действий — это все, по ощущениям, очень близко к Java-way, где любят создавать классы на каждый чих. Только не подумайте, что я холивора ради это написал — нет конечно, на Java написаны многие отличные продукты, да и в целом язык очень хороший даже сегодня, несмотря на появления всяких модных штук типа Go. Просто Хадуп действительно монструозен, просто сравните с Disco ;)
Не бывает map и reduce узлов, бывают map и reduce tasks. И, скорее всего, reduce task будет запущен на том же узле, что и map task, чтобы избежать излишней передачи данных по сети. Data locality, вокруг этого построены все современные фреймворки. Не у всех есть деньги на infiniband.
В результате парсинга скрипта получается DAG, он и исполняется.
Было бы здорово, если бы схема была оформлена в терминологии HDFS+MapReduce; JobTracker, TaskTracker, DataNode.
В результате парсинга скрипта получается DAG, он и исполняется.
Было бы здорово, если бы схема была оформлена в терминологии HDFS+MapReduce; JobTracker, TaskTracker, DataNode.
Поломана ссылка на предыдущую публикацию.
Sign up to leave a comment.
Hadoop, часть 3: Pig, обработка данных