Комментарии 20
очень позновательно, спасибо
возможно что-то пригодится и в наших проектах.
давно хотел покрутить Hdp
возможно что-то пригодится и в наших проектах.
давно хотел покрутить Hdp
Я тоже мало что понял, только общий смысл уловил(наверное, как и те люди, которые поставили плюсик, но не оставили комментарий). Но все равно, очень интересно.
Вы не рассматривали возможность использования Hive? Выглядит довольно соблазнительно использование «почти SQL», автоматически транслируемого в Map-Reduce.
Нет, не рассматривали. Для своих задач мы не смогли найти такого примера, который бы показал явное преимущество Hive над классическим Java Map-Reduce.
Но Вы правы — он выглядит соблазнительно. Особенно для задач статистики: логи, клики и т.п. Но даже наш отдел статистики, насколько мне известно, его не использует.
Но Вы правы — он выглядит соблазнительно. Особенно для задач статистики: логи, клики и т.п. Но даже наш отдел статистики, насколько мне известно, его не использует.
Спасибо за отличную статью!!!
Интересно было что изменилось в Hadoop c 2008. Тогда на стартапе поиска изображений по визуальному образцу мы использовали его. Hadoop в версии 0.17 представлял из себя жалкое зрелище. Разработчики hadoop похоже не думали о thread safe HDFS клиента вообще. Клиент для доступа к его распределенной файловой системы (HDFS) пришлось сильно патчить. В качестве спайдера использовал кластер из heritrix 2. Был написан собственный контроллер кластера, только в качестве хранилища URL для каждого домена использовалась berkeley db java edition, а очередь сайтов по доменам для закачки хранилась в PostgreSQL. Мной была написана инфраструктура по мониторингу кластера спайдеров и сбору статискики по задачам и отображения в интерфейсе. В heretrix дописал поддержку sitemap.
Вобщем все бы было не плохо, но стабильность работы HDFS оставляла желать лучшего. Однажды из-за сетевых проблем в датацентре name node потерял связь с частью data node, а после подключения их обратно он автоматически так восстановил метаданные, что сотни гигабайт данных оказались в неконсистентном состоянии. По умолчанию использовалось 3 реплики для данных, что вообще в той ситуации никак не спасло. Часть данных из неконсистентных файлов удалось спасти с помощью самописной распределенной программы. После этого случая, совместно с коллегой пробовали kosmosfs, но с ним было еще меньше надежд на надежность хранения данных. Тогда решение о применении hadoop было принято руководством. А разработчики, как мыши: плакали, кололись, но продолжали есть кактус/использовать hadoop.
Вы рассматривали в качестве распределенной файловой системы GlusterFS? В отличии от HDFS она не содержит централизованный сервер метаданных, написана на C++(никаких пауз GC), содержит адаптер для работы в Hadoop Map-Reduce. Это в теории… Вопрос опять же в надежности такого решения, т.к. я давно занимаюсь другими работами в компаниях, задачи в которых не связанны с Internet. Насколько развиты средства восстановления данных и мониторинга для такого решения?
Интересно было что изменилось в Hadoop c 2008. Тогда на стартапе поиска изображений по визуальному образцу мы использовали его. Hadoop в версии 0.17 представлял из себя жалкое зрелище. Разработчики hadoop похоже не думали о thread safe HDFS клиента вообще. Клиент для доступа к его распределенной файловой системы (HDFS) пришлось сильно патчить. В качестве спайдера использовал кластер из heritrix 2. Был написан собственный контроллер кластера, только в качестве хранилища URL для каждого домена использовалась berkeley db java edition, а очередь сайтов по доменам для закачки хранилась в PostgreSQL. Мной была написана инфраструктура по мониторингу кластера спайдеров и сбору статискики по задачам и отображения в интерфейсе. В heretrix дописал поддержку sitemap.
Вобщем все бы было не плохо, но стабильность работы HDFS оставляла желать лучшего. Однажды из-за сетевых проблем в датацентре name node потерял связь с частью data node, а после подключения их обратно он автоматически так восстановил метаданные, что сотни гигабайт данных оказались в неконсистентном состоянии. По умолчанию использовалось 3 реплики для данных, что вообще в той ситуации никак не спасло. Часть данных из неконсистентных файлов удалось спасти с помощью самописной распределенной программы. После этого случая, совместно с коллегой пробовали kosmosfs, но с ним было еще меньше надежд на надежность хранения данных. Тогда решение о применении hadoop было принято руководством. А разработчики, как мыши: плакали, кололись, но продолжали есть кактус/использовать hadoop.
Вы рассматривали в качестве распределенной файловой системы GlusterFS? В отличии от HDFS она не содержит централизованный сервер метаданных, написана на C++(никаких пауз GC), содержит адаптер для работы в Hadoop Map-Reduce. Это в теории… Вопрос опять же в надежности такого решения, т.к. я давно занимаюсь другими работами в компаниях, задачи в которых не связанны с Internet. Насколько развиты средства восстановления данных и мониторинга для такого решения?
Мы лишь пару раз испытывали проблемы с GC — это было на Name-Node (NN). И, если я правильно помню, это был один из немногих случаев где нам помог суппорт от Cloudera. Если кратко, то надо следить за тем, какое кол-во записей (файлов) обслуживает NN. Если это количество растет, то необходимо NN выносить на отдельный сервер или паковать мелкие файлы в hadoop archive.
В то время когда мы занялись Hadoop (2011), он был уже (приемлемо) стабилен. Чего нельзя было сказать про HBase. От тех кто работал с Hadoop'ом на заре его появления я часто слышал что «HBase сегодня такой же как когда-то Hadoop», так что охотно Вам верю.
Что касается мониторинга, то мы используем nagios для отдельных машин и ganglia для кластера в целом. Это помимо стандартных средств hadoop, само-собой. Также несколько самописных скриптов — больше для мониторинга HBase.
В то время когда мы занялись Hadoop (2011), он был уже (приемлемо) стабилен. Чего нельзя было сказать про HBase. От тех кто работал с Hadoop'ом на заре его появления я часто слышал что «HBase сегодня такой же как когда-то Hadoop», так что охотно Вам верю.
Что касается мониторинга, то мы используем nagios для отдельных машин и ganglia для кластера в целом. Это помимо стандартных средств hadoop, само-собой. Также несколько самописных скриптов — больше для мониторинга HBase.
Про куда движется Hadoop уже было вкратце написано тут
Да, nagios или zabbix/ganglia отличные решения! По поводу Name-Node и HDFS, не является ли эта подсистема ограничивающей масштабируемость? И по вашим словам вам пришлось делать лишние манипуляции с мелкими файлами. Проводили ли вы тесты по использованию других файловых систем вместо HDFS?
Насколько мне известно, в Hadoop 2.0 реализована поддержка нескольких Name-Node. Мы же сейчас используем Secondary Name-Node.
Про альтернативные распределенные ФС — сперва пробовали. Как упомянуто в статье, в компании тестировался Sector/Sphere. Но на тот момент она была совсем сырой.
Hadoop, как целая система, притягивал тем, что там все вокруг парадигмы MapReduce. Особых требований к ФС у нас не было. Такие вещи как быстрый поиск файлов, потребление CPU при множестве параллельных запросов и пр. показатели файловых систем общего назначения здесь не очень интересны.
MapReduce по своей природе склоняет к большим файлам. HBase, если его правильно использовать, — тем более. А скорость работы в основном определяется локальностью данных и архиватором.
Про альтернативные распределенные ФС — сперва пробовали. Как упомянуто в статье, в компании тестировался Sector/Sphere. Но на тот момент она была совсем сырой.
Hadoop, как целая система, притягивал тем, что там все вокруг парадигмы MapReduce. Особых требований к ФС у нас не было. Такие вещи как быстрый поиск файлов, потребление CPU при множестве параллельных запросов и пр. показатели файловых систем общего назначения здесь не очень интересны.
MapReduce по своей природе склоняет к большим файлам. HBase, если его правильно использовать, — тем более. А скорость работы в основном определяется локальностью данных и архиватором.
А какой архиватор? В ElasticSearch как-то была экспериментальная поддержка Snappy, но потом от нее отказались так как оказалась хуже lzf по размеру.
Сперва мы комбинировали LZO и gzip. LZO там где важна скорость, gzip — для тех частей (column-family) Hbase'а, к которым мы обращаемся редко. Например, содержимое страниц.
Чуть позже, для скорости, мы все перевели на Snappy.
А относительно недавно — на LZ4. Решительно все, в том числе и промежуточные данные map-reduce. Как ни странно, он оказался эффективней как по скорости так и по сжатию.
Чуть позже, для скорости, мы все перевели на Snappy.
А относительно недавно — на LZ4. Решительно все, в том числе и промежуточные данные map-reduce. Как ни странно, он оказался эффективней как по скорости так и по сжатию.
> но так как патч затрагивает много корневых элементов HBase, он до сих пор не был интегрирован в общий код
Так вроде бы ваш патч приняли пятнадцатого января в 0.94?
Ещё небольшой баг с поиском по китайским сайтам. Простой пример: go.mail.ru/search?mailru=1&q=Baidu (промотайте на вторую половину страницы).
Так вроде бы ваш патч приняли пятнадцатого января в 0.94?
Ещё небольшой баг с поиском по китайским сайтам. Простой пример: go.mail.ru/search?mailru=1&q=Baidu (промотайте на вторую половину страницы).
> после того, как мы пересели на Hadoop, многие из наших программистов познакомились с Java
Это был обмен опытом между отделами/подразделениями, или массовое переобучение имеющихся специалистов? Если второе — было бы интересно почитать про такой опыт.
Это был обмен опытом между отделами/подразделениями, или массовое переобучение имеющихся специалистов? Если второе — было бы интересно почитать про такой опыт.
Ни то ни другое. Программированием на Java занялись программисты прежде писавшие на C++. IMHO, для MapReduce это вполне допустимо — он не требует каких-то особых знаний, ведь многое там просто не нужно: многопоточность, GUI само-собой, знание тонкостей GC — от этих вещей парадигма избавляет.
В случаях же, когда нам требуется «совсем серьезный» код, мы используем JNI. Просто потому, что дублировать наработки с плюсов на Java видится нецелесообразным.
В случаях же, когда нам требуется «совсем серьезный» код, мы используем JNI. Просто потому, что дублировать наработки с плюсов на Java видится нецелесообразным.
Спасибо за статью, очень интересно было почитать. В отличии от многих статей связаных с big-data, здесь всё на живых примерах и конкретике, а не о подсчётах количеств вхождения слова «error» в лог файле :) Скажите, если ли у вас информация о том, за последние пол года с момента написания статья, насколько улучшилась (у улучшилась ли вообще) как-то стабильность продукта HBase в её оригинальной поставке без ваших доработок? И / или, возможно, ваши доработки были приняты в основную версию?
Спасибо! Статья и впрямь получилась практическая. Нам самим даже казалось что слишком :-)
Что касается улучшений в Hadoop/HBase, то изменилось, скорее, с нашей стороны. Мы избавились от основной своей проблемы — несбалансированных регионов. А также от небольших докучающих ошибок JobTracker'а.
Новую версию Hadoop также думаем накатывать. Из основного что хотим:
— символические ссылки в HDFS (удобство)
— работа RegionServer-а с локальными данными минуя DataNode (скорость)
— возможность компактить отдельные ColumnFamily (гибкость)
— динамическое распределение Mappers/Reducers
Как минимум, вот настолько улучшилась оригинальная поставка.
Что касается улучшений в Hadoop/HBase, то изменилось, скорее, с нашей стороны. Мы избавились от основной своей проблемы — несбалансированных регионов. А также от небольших докучающих ошибок JobTracker'а.
Новую версию Hadoop также думаем накатывать. Из основного что хотим:
— символические ссылки в HDFS (удобство)
— работа RegionServer-а с локальными данными минуя DataNode (скорость)
— возможность компактить отдельные ColumnFamily (гибкость)
— динамическое распределение Mappers/Reducers
Как минимум, вот настолько улучшилась оригинальная поставка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шаг за шагом, или Как мы строили свой поиск