Comments 26
Отличная статья, спасибо! Можно еще добавить, что у Cloudera, Hortonworks и IBM есть готовые образы виртуальных машин с установленной в них инфраструктурой Hadoop, на которой можно все посмотреть, поиграться и пройти туториалы (что сильно снижает порог вхождения)
Еще есть много онлайн курсов на сайте bigdatauniversity.com/
Еще есть много онлайн курсов на сайте bigdatauniversity.com/
Хрюшка (Apache Pig) предана забвению?
Ах, а ведь крутилась же в голове!
Но, честно говоря, я ни разу не слышал, чтобы её использовали на практике. Возможно, вы можете поделиться success story?
Но, честно говоря, я ни разу не слышал, чтобы её использовали на практике. Возможно, вы можете поделиться success story?
Мы активно использовали Pig для обработки 10М+ данных (из нескольких коллекций, которые нужно было объединять). Справлялся он на ура, хоть и слегка сложен в освоении за счет собственного синтаксиса запросов.
А можно узнать, когда почему Pig, а не тот же Hive, например? Какие именно свойства «хрюши» стали решающими?
Честно говоря, я на тот момент занимался веб разработкой, и на пиге писал всего-лишь пару скриптов, этим занимался другой отдел. По этому всех тонкостей я не знаю. Но насколько я помню, Hive с необходимыми коллекциями и объемами данных работал значительно медленней, чем Pig.
Насчет последнего согласен — производительность PIG-скриптов зачастую более предсказуема, чем на Hive. Заранее знаешь, сколько примерно будут выполняться какие конструкции. Плюс благодаря более низкоуровневому подходу можно более гибко управлять обработкой данных.
У нас был такой случай — один клиент дал нам доступ к логам своей системы, мы на своей стороне реализовали обработку на PIG. Скрипт работал что-то около часа на 4 машинах.
Когда клиент узнал, сколько занимает у нас обработка его данных, у него отпала челюсть. Оказалось, что они сами обрабатывали логи своего сервера с помощью Hive. Обычный дневной процессинг у них занимал что-то около 6 часов на кластере из десятка машин. Подозреваю, что их программисты получили втык за перерасход вычислительных ресурсов :-)
Позже они показывали нам свои Hive-запросы. Оптимизировать там мне ничего не удалось — по сути, и оптимизировать-то было нечего, пара фильтров, группировки, сортировки, снова группировки. Честно говоря, я так и не понял, что же они делали не так, но факт остается фактом — тормозило оно безбожно.
У нас был такой случай — один клиент дал нам доступ к логам своей системы, мы на своей стороне реализовали обработку на PIG. Скрипт работал что-то около часа на 4 машинах.
Когда клиент узнал, сколько занимает у нас обработка его данных, у него отпала челюсть. Оказалось, что они сами обрабатывали логи своего сервера с помощью Hive. Обычный дневной процессинг у них занимал что-то около 6 часов на кластере из десятка машин. Подозреваю, что их программисты получили втык за перерасход вычислительных ресурсов :-)
Позже они показывали нам свои Hive-запросы. Оптимизировать там мне ничего не удалось — по сути, и оптимизировать-то было нечего, пара фильтров, группировки, сортировки, снова группировки. Честно говоря, я так и не понял, что же они делали не так, но факт остается фактом — тормозило оно безбожно.
Например, потому, что именно она используется в лабах на самом популярном курсе Coursera про Big Data. Ну и затем люди переносят её на реальные проекты
Рановато скидываете его со счетов! Удобнейшая вещь.
Мы используем PIG для парсинга логов сторонних систем, с которыми мы интегрированы. Объем логов — от 10М до 500М записей в день.
Из этих логов извлекаем довольно нетривиальную статистику (пример: сколько в среднем времени прошло между совершением пользователем двух действий? как это время меняется в зависимости от некоторых параметров пользователя? часто разные действия пишутся в разных логах, поэтому надо их матчить между собой).
pig незаменим, когда нужно много работать с текстом. Например, из URL выдернуть все параметры, отфильтровать их, по каждому параметру собрать статистику по встречаемости значений по отдельности, плюс посчитать ковариации разных значений для пар параметров. С трудом представляю, как это сделать в SQL, а на свинье пишется в пару строк.
Свой «птичий язык» свинтуса сначала не внушает доверия, но со временем привыкаешь. ИМХО сложные скрипты на нем выглядят более читабельно, чем на SQL засчет того, что вместо двух сложнейших запросов на PIG как правило пишут 10 коротких и простых выражений.
Увы, для аналитики pig latin мало пригоден по причине наличия этого своего нестандартного языка (аналитикам его учить сложно, императивные языки для них в новинку, а SQL привычен), своей низкой интерактивности и некоторой задумчивости. Даже на наборах данных в пару тысяч строк и простых скриптах (фильтр-группировка-фильтр-сортировка) может генерироваться по несколько MR-задач.
Мы используем PIG для парсинга логов сторонних систем, с которыми мы интегрированы. Объем логов — от 10М до 500М записей в день.
Из этих логов извлекаем довольно нетривиальную статистику (пример: сколько в среднем времени прошло между совершением пользователем двух действий? как это время меняется в зависимости от некоторых параметров пользователя? часто разные действия пишутся в разных логах, поэтому надо их матчить между собой).
pig незаменим, когда нужно много работать с текстом. Например, из URL выдернуть все параметры, отфильтровать их, по каждому параметру собрать статистику по встречаемости значений по отдельности, плюс посчитать ковариации разных значений для пар параметров. С трудом представляю, как это сделать в SQL, а на свинье пишется в пару строк.
Свой «птичий язык» свинтуса сначала не внушает доверия, но со временем привыкаешь. ИМХО сложные скрипты на нем выглядят более читабельно, чем на SQL засчет того, что вместо двух сложнейших запросов на PIG как правило пишут 10 коротких и простых выражений.
Увы, для аналитики pig latin мало пригоден по причине наличия этого своего нестандартного языка (аналитикам его учить сложно, императивные языки для них в новинку, а SQL привычен), своей низкой интерактивности и некоторой задумчивости. Даже на наборах данных в пару тысяч строк и простых скриптах (фильтр-группировка-фильтр-сортировка) может генерироваться по несколько MR-задач.
Это имеет смысл, спасибо!
Тогда вопрос в другую степь: а вы не сравнивали его с тем же Spark-ом, например? Лично я в своё время остался очень доволен обработкой как раз текстовых логов с помощью PySpark, и тогда я уж точно не мог подумать, что Pig для этого тоже годится.
Тогда вопрос в другую степь: а вы не сравнивали его с тем же Spark-ом, например? Лично я в своё время остался очень доволен обработкой как раз текстовых логов с помощью PySpark, и тогда я уж точно не мог подумать, что Pig для этого тоже годится.
Насколько понимаю, основное преимущество Spark — выполнение запросов прямо в памяти. Но это похоже на наш случай: наборы данных у нас бывают довольно большие, 2-10 терабайт, а обработка логов производится раз в день, т.ч. время отклика критичным не является, а по общей длительности обработки PIG вполне устраивает — поэтому замены ему не ищем.
Готовая статистика имеет небольшой объем, и заливается либо в SQL-базу, либо в Hive (в зависимости от объема и потребности в интерактивной аналитике). И вот тут мы посматриваем в сторону Impala и Spark SQL как интерактивной замены/дополнения Hive.
С Impala был прототип, но она оказалась менее функциональна, чем Hive. Например, та версия, что мы пробовали, при сохранении результатов запроса в файл не умела их сжимать. Получение больших кусков данных через JDBC в Impala (да и в Hive) довольно медленное, порой прочитать результат занимает дольше, чем сам запрос, поэтому вместо ResultSet-а мы сохраняли результат запроса в CSV, и загружали через HDFS готовый файл. В результате с Hive получался выигрыш в 5-10 раз, что довольно критично. А из-за отсутствия сжатия в Impala преимущество было куда как скромнее. Есть конечно workaround-ы, но как-то Impal-ой мы не прониклись.
Готовая статистика имеет небольшой объем, и заливается либо в SQL-базу, либо в Hive (в зависимости от объема и потребности в интерактивной аналитике). И вот тут мы посматриваем в сторону Impala и Spark SQL как интерактивной замены/дополнения Hive.
С Impala был прототип, но она оказалась менее функциональна, чем Hive. Например, та версия, что мы пробовали, при сохранении результатов запроса в файл не умела их сжимать. Получение больших кусков данных через JDBC в Impala (да и в Hive) довольно медленное, порой прочитать результат занимает дольше, чем сам запрос, поэтому вместо ResultSet-а мы сохраняли результат запроса в CSV, и загружали через HDFS готовый файл. В результате с Hive получался выигрыш в 5-10 раз, что довольно критично. А из-за отсутствия сжатия в Impala преимущество было куда как скромнее. Есть конечно workaround-ы, но как-то Impal-ой мы не прониклись.
Я бы сказал, что Spark — это как раз такой «низкоуровневый» фреймворк, который даёт большой уровень контроля над распределённым набором данных, поэтому в голову и пришло сравнение с Pig.
Что касается Impala, а не помните, какая это была версия? Сейчас Impala по умолчанию использует Parquet + сжатие Snappy — в итоге в среднем получается в 7-10 раз меньше, чем CSV, так что по идее должно было бы получиться не хуже, чем с Hive.
Что касается Impala, а не помните, какая это была версия? Сейчас Impala по умолчанию использует Parquet + сжатие Snappy — в итоге в среднем получается в 7-10 раз меньше, чем CSV, так что по идее должно было бы получиться не хуже, чем с Hive.
Статья хорошая, хотелось бы еще статей с примерами использования технологий.
На самом деле Oozie как служба весьма надежен и он единственный из подобных имеет годный UI.
Вот написать стабильный workflow под него — действительно непросто. И функционально слабоват — костылить приходится.
Вот написать стабильный workflow под него — действительно непросто. И функционально слабоват — костылить приходится.
Вот написать стабильный workflow под него — действительно непросто
Примерно это я и имел ввиду :) Oozie имеет очень много зависимостей, и не всегда «правильных». Например, если заглянуть внутрь Hive action, оказывается, что запросы вызываются через консольный клиент под своим пользователем и в своём окружении. Добавьте к этому кучу генерируемых временных файлов (извлечь которые, естественно, довольно сложно) и невнятные логи, и отладка превращается в сплошное «удовольствие».
Насчёт UI, мне не понравилось, что вокрфловы и координаторы, созданные через API, не отображаются в веб-интерфейсе. Т.е. список запущенных и отработавших работ есть, но открыть и, например, отредактировать конкретный воркфлоу уже нельзя.
Складывается ощущение, что автор нахватался чего-то по верхам и сделал поверхностный обзор на основе своего небольшого опыта.
Про flume, sqoop, oozie написан бред.
Основные преимущества TEZ, которые можно использовать прямо сейчас, это checkpointing и MRR jobs, когда reduce-фаза пишет локально, а не в HDFS, экономя кучу времени. Можно изменять алгоритм сортировки. Судя по диз. доку, TEZ всего лишь устраняет ограничения MR фреймфорка, в которые уперлись разработчики спустя годы после первого релиза. Все таки в 2007 году сложно было представить, что захотят юзеры в 2012
Хорошая оценочка пигу.
Чуваки типа по фану срелизили 0.13.0 версию, другие чуваки от безделия добавили pig-action в oozie, а третьи лежебоки добавили интерактивную веб-консоль в hue.
На каких фактах вы строите свои предположения и делаете выводы?
Про flume, sqoop, oozie написан бред.
Основные преимущества TEZ, которые можно использовать прямо сейчас, это checkpointing и MRR jobs, когда reduce-фаза пишет локально, а не в HDFS, экономя кучу времени. Можно изменять алгоритм сортировки. Судя по диз. доку, TEZ всего лишь устраняет ограничения MR фреймфорка, в которые уперлись разработчики спустя годы после первого релиза. Все таки в 2007 году сложно было представить, что захотят юзеры в 2012
Хорошая оценочка пигу.
Но, честно говоря, я ни разу не слышал, чтобы её использовали на практике.
Чуваки типа по фану срелизили 0.13.0 версию, другие чуваки от безделия добавили pig-action в oozie, а третьи лежебоки добавили интерактивную веб-консоль в hue.
На каких фактах вы строите свои предположения и делаете выводы?
На каких фактах вы строите свои предположения и делаете выводы?
Выводы о чём? О том, что я никогда не слышал, как Pig используют на практике? Нуу, на том, что я об этом никогда не слышал. Никаких выводов относительно того, нужен ли он, полезен ли он и если да, то в каких ситуациях, я как бы и не делал. Наоборот, мне интересна его роль в экосистеме Hadoop и преимущества перед Hive, Impala, R байндингами, Python/Pandas/Spark/Impyla и т.д. Если у вас есть примеры его использования, так поделитесь.
Складывается ощущение, что автор нахватался чего-то по верхам и сделал поверхностный обзор на основе своего небольшого опыта.
Про flume, sqoop, oozie написан бред.
Давайте конкретней. Я всегда готов обсудить, как Oozie прекрасно подхватывает oozie.libpath, и почему «sharelib» не имеет никакого отношения к общим пользовательским библиотекам. Или как в нём передать нестроковые параметры между экшенами без использования HDFS. Или как настроить HDFS sink во Flume, чтобы он распределял файлы по директориям на основе кастомного атрибута данных. Ну и если у вас есть удачный опыт использования Sqoop, опишите, не стесняйтесь. У нас с ним не сложилось, о чём в статье вполне чётко написано.
Ну и да, естетсвенно, обзор поверхностный. Про любую из этих технологий можно написать отдельную статью, и не одну. Только это уже не будет обзором, и цели у такого подробного описания будут совсем другие. А так, конечно, я готов побеседовать про любой из вышеперечисленных инструментов, причём как рассказать, так и послушать.
Отличительной чертой Cloudera также является стремление первыми предоставлять на рынке новые фичи
Вранье. HDP пушит самый свежаок, клоудера крайне консервативна. Я >2 лет сижу на клоудере. Единственное, что сделала нового клоудера, так это втащила спарк, который ставится при помощи человеко-машинного комплекса. Позже, эта проблема была устранена.
Hive — самая первая и до сих пор одна из самых популярных СУБД на этой платформе. В качестве языка запросов использует HiveQL — урезанный диалект SQL,
Бред, это не СУБД. Это транслятор SQL в каскад MR job. Про диалект так же спорно, он не ANSI compliant, это да. По сути, это клиентская тула. Просто посмотрите код, как он устроен. Где-то год назад в джире читал, что девелоперы озаботились о том, чтобы распилить хайв на модули. Потому что вместе с артефактом-jdbc хайва, вы еще получаете метастор и кучу всего, не относящегося к «дровам». Почитайте Programming hive, он по версии 0.8, но даст вам понять, почему это не СУБД.
HBase — это распределённая версионированная нереляционная СУБДэто не бд, это hashmap of hashmaps с рядом интересных свойств. Почитайте HBase definitive guide. Даже это вам даст понимание того, насколько hbase далек от СУБД.
Oozieодно из самых вменяемых решений. Для отладки есть dryrun и e2e тесты. Для hive/impala и т.д. есть java action. Что у вас там за проблемы с либами, я вообще не понял. Что за пользовательские библиотеки? Делайте бандл и все что нужно коориднатору, воркфле кладите в lib каталог «приложения». Ози сам зацепит ресурсы в classpath. Не превращайте окружение в помойку джарников, и все будет хорошо.
Hue — Работает плохо, с ошибками и по настроению.
По настроению, ок, исчерпывающее описание.
Sqoop — на практике Sqoop 1 оказался, по сути, однопоточным и медленным
Бред, до 3-5 млн строк в минуту без каких-либо ухищрений/костылей, терадат и экзадат. Обычное загруженное хранилище оралка.
JDBC интерфейс в виде HiveServer2 работает откровенно плохо, а бросаемые ошибки мало связаны с настоящей причиной проблемы.cool story. Откровенно плохо, это как, как это проявляется? Бросаемые ошибки связаны со спецификой инструмента. попробуйте beeswax интерфейс, тогда поймете, что значит плохо — DoS зукиперов и т.д.
Бред, это не СУБД. Это транслятор SQL в каскад MR job
We built NoSQL so you don't need to learn SQL, then we added SQL so you can use NoSQL. © не помню кто.
Скажете неправда? :-)
И цитата из классика twitter.com/DEVOPS_BORAT
Attention devops: «learn NoSQL» is not same as «learn no SQL»!
Is no such thing as Big Data. Is only data you not sampled sufficient yet so it fit in RAM and it process with SQLite.
И вот в последней много мудрости. То что не интерактивно (не в RAM) не подходит для интенсивного анализа. А то, что должно быть обработано все и по отдельности — не требует интенсивного анализа и обычно по природе своей параллельно.
Вранье. HDP пушит самый свежаок, клоудера крайне консервативна. Я >2 лет сижу на клоудере. Единственное, что сделала нового клоудера, так это втащила спарк, который ставится при помощи человеко-машинного комплекса. Позже, эта проблема была устранена.
За 2 последних года весь Hadoop сильно изменился, и Cloudera сейчас поддерживает эти изменения. Поэтому говорить, что Клаудера ничего нового не втянула, мягко говоря, не корректно. Дальше вспоминаем Impala: когда там Hortonworks разогнал Hive до реал тайма? Impala к этому времени уже отлично отвечала на быстрые интерактивные запросы. Spark дошёл до версии 1.0 что-то около полугода назад, но Cloudera уже пытается перевести Hive на него, Hortonworks, судя по всему, даже не собирается в это соваться. Примеров много. Конечно, у вас могут другие примеры, где Hortonworks окажется новатором, но это уже называется «обмен мнениями», хотя вы почему-то назвали это «враньём».
Бред, это не СУБД. Это транслятор SQL в каскад MR job.
Да ладно, а метаданные Hive не хранит? А форматами данных не управляет? А пользовательский и программный интерфейс не предоставляет? А если так, то чем он не СУБД?
Вообще, если посмотреть определения понятий «база данных» и «СУБД» в словарях (ну или той же Википедии), то вдруг оказывается, что БД и СУБД — это очень общие понятия. Что, например, Lucene-овский индекс — это вполне себе база данных, а сам Lucene — СУБД. Что property файл на диске — это база данных, а программа, которая его формирует и парсит — это СУБД. Hive на этом фоне — гораздо более классическая СУБД, и уж точно не просто транслятор из SQL в MR.
это не бд, это hashmap of hashmaps с рядом интересных свойств. Почитайте HBase definitive guide. Даже это вам даст понимание того, насколько hbase далек от СУБД.
Аналогично.
Бред, до 3-5 млн строк в минуту без каких-либо ухищрений/костылей, терадат и экзадат. Обычное загруженное хранилище оралка.
3-5 миллионов в минуту — это как раз и есть один поток, верно? Смысл был в том, чтобы всасывать данные в параллели, как это делает, например, Vertica с их адаптером (или по крайней мере они это обещают). В любом случае, здорово, что у вас получилось, у нас опыт получился совсем иным.
По настроению, ок, исчерпывающее описание.
Нет, стоп. Вы определитесь, вы хотите сказать, что автор мудак, или что в статье мало деталей? Если первое, то так и говорите: автор врёт, Hue — хорошая программа, никогда не даёт сбоев и проверенно работает в любых условиях. Если второе, то да, очевидно, что многие детали опущены, и о них автора можно спросить отдельно.
На всех 4-х кластерах, которые у меня сейчас под рукой:
1. Hue работает медленно. Сам интерфейс, будучи довольно простым, заставляет ждать.
2. Hue падает с эксепшенами на простейших действиях. Можно просто перейти по совершенно законной, активной и незаэкспайреной ссылке и увидеть страницу со стектрейсом. А через минуту перезагрузить страницу и увидеть нормальный результат.
3. Логи ошибок практически бесполезны. Либо стектрейс ведёт вглубь самого Hue, либо отображается только общая ошибка вроде «server error», и никаких намёков, чем она вызвана.
cool story. Откровенно плохо, это как, как это проявляется?
Откровенно плохо — это когда сервер падает с OOM из-за утечки памяти. Возможно, утечка справоцирована внешними факторами (например, как-то мы отловили незакрытые соедниения), но если серверная программа не имеет защиты от таких банальных проблем, то я её считаю нестабильной. Именно «я считаю» — это моё мнение, и мой личный опыт, поэтому вся эта «cool story» и вынесена в спойлер с соответсвующей пометкой.
В общем, давайте так. Если видите техническую ошибку — говорите, исправлю. Если у вас другая точка зрения — тоже говорите, обсудим: область узкая, и услышать мнение другого человека всегда интересно. Но просто сказать «автор мудак, это же очевидно!» — не прокатит.
Плюс ставить поздно посту, напишу просто спасибо.
Sign up to leave a comment.
Hadoop: что, где и зачем