Спасибо! Статья и впрямь получилась практическая. Нам самим даже казалось что слишком :-)
Что касается улучшений в Hadoop/HBase, то изменилось, скорее, с нашей стороны. Мы избавились от основной своей проблемы — несбалансированных регионов. А также от небольших докучающих ошибок JobTracker'а.
Новую версию Hadoop также думаем накатывать. Из основного что хотим:
— символические ссылки в HDFS (удобство)
— работа RegionServer-а с локальными данными минуя DataNode (скорость)
— возможность компактить отдельные ColumnFamily (гибкость)
— динамическое распределение Mappers/Reducers
Как минимум, вот настолько улучшилась оригинальная поставка.
Видимо, тем что его на виндах нету.
Но застав однажды такое вольное решение как svn.boost.org/trac/boost/ticket/850, сам предпочитаю getopt_long на *nix. (поясню — в версии 1.41 они _по-умолчанию_ стали вырезать кавычки из аргументов).
А можно уточнение по картинке — 10^12 и 10^8 это какие документы имеются ввиду: известные URL'ы / скаченные / заиндексированные / потенциально искомые или еще что-то?
Да, про vtune я как-то совсем забыл. Из Intel'овских средств под linux лишь icc юзал.
Он, конечно, на lightweight не претендует, но описание просто шикарное! Надо будет его попробовать.
Он же как отдельные модули ядра работает, а значит root-only.
В любом случае, можно пример как на нем собирать иерархический профайл пользовательской программы?
Сперва мы комбинировали LZO и gzip. LZO там где важна скорость, gzip — для тех частей (column-family) Hbase'а, к которым мы обращаемся редко. Например, содержимое страниц.
Чуть позже, для скорости, мы все перевели на Snappy.
А относительно недавно — на LZ4. Решительно все, в том числе и промежуточные данные map-reduce. Как ни странно, он оказался эффективней как по скорости так и по сжатию.
Насколько мне известно, в Hadoop 2.0 реализована поддержка нескольких Name-Node. Мы же сейчас используем Secondary Name-Node.
Про альтернативные распределенные ФС — сперва пробовали. Как упомянуто в статье, в компании тестировался Sector/Sphere. Но на тот момент она была совсем сырой.
Hadoop, как целая система, притягивал тем, что там все вокруг парадигмы MapReduce. Особых требований к ФС у нас не было. Такие вещи как быстрый поиск файлов, потребление CPU при множестве параллельных запросов и пр. показатели файловых систем общего назначения здесь не очень интересны.
MapReduce по своей природе склоняет к большим файлам. HBase, если его правильно использовать, — тем более. А скорость работы в основном определяется локальностью данных и архиватором.
Ни то ни другое. Программированием на Java занялись программисты прежде писавшие на C++. IMHO, для MapReduce это вполне допустимо — он не требует каких-то особых знаний, ведь многое там просто не нужно: многопоточность, GUI само-собой, знание тонкостей GC — от этих вещей парадигма избавляет.
В случаях же, когда нам требуется «совсем серьезный» код, мы используем JNI. Просто потому, что дублировать наработки с плюсов на Java видится нецелесообразным.
Мы лишь пару раз испытывали проблемы с GC — это было на Name-Node (NN). И, если я правильно помню, это был один из немногих случаев где нам помог суппорт от Cloudera. Если кратко, то надо следить за тем, какое кол-во записей (файлов) обслуживает NN. Если это количество растет, то необходимо NN выносить на отдельный сервер или паковать мелкие файлы в hadoop archive.
В то время когда мы занялись Hadoop (2011), он был уже (приемлемо) стабилен. Чего нельзя было сказать про HBase. От тех кто работал с Hadoop'ом на заре его появления я часто слышал что «HBase сегодня такой же как когда-то Hadoop», так что охотно Вам верю.
Что касается мониторинга, то мы используем nagios для отдельных машин и ganglia для кластера в целом. Это помимо стандартных средств hadoop, само-собой. Также несколько самописных скриптов — больше для мониторинга HBase.
Нет, не рассматривали. Для своих задач мы не смогли найти такого примера, который бы показал явное преимущество Hive над классическим Java Map-Reduce.
Но Вы правы — он выглядит соблазнительно. Особенно для задач статистики: логи, клики и т.п. Но даже наш отдел статистики, насколько мне известно, его не использует.
Имеется дамп, скажем, от нескольких часов назад. Чем он хуже если дает все тот же hitrate?
Есть много задач где это подойдет, например, кэш поисковика.
Проект не поддерживается с 2008 года.
Кроме того, вот эти цитаты не могли не смутить: «It is NOT a cache solution» и "*NO* expiration. For memcache protocol compatible, still reserved, but we do nothing".
Собственно, последняя цитата из офф. документации «Totally for persistent. Transaction, replication, we do our best to achieve persistent» характеризует большинство альтернативных memcached-у решений: они не про простой и эффективный кэш, они про СУБД и гарантии записи. Про типизацию данных и оптимизацию последовательных чтений. Про внутренние скрипты и прочие вкусности. При более близком знакомстве вы понимаете что они не так просто эксплуатируются и вставляются в проект как memcache.
Сейчас, глядя на него, не могу вспомнить почему пропустил. Видимо, сыграло именно желание «покодить».
Собственно, да — это бывший membase, казалось бы — те же корни что и у memcached.
Спасибо что напомнили!
Тут много «если» появляется. Есть у Вас 10 серверов с 64Gb на каждом под кэш.
Что если они в одном датацентре и там что-то произошло с питанием?
Приходим к тому что надо разделять/реплицировать и т.д. и т.п. Между тем, дешевые диски простаивают.
Redis, tarantool и т. п. решения отлично подходят когда необходимы гарантии. По-умолчанию же эти решения, насколько мне известно, не содержат (или отключают) вытеснение ключей, а наоборот (для обеспечения этих самых гарантий) — хранят все до последнего, пишут write-ahead-log'и и просто плохо ведут себя при заполнении всей ОЗУ. Да, есть патчи к tarantool и, наверняка, есть настройки к Redis'у, что легко гуглится. (кстати, уже тот факт что оно гуглится говорит что проблема есть). Кстати, не знаю как ведет себя Redis, но tarantool при восстановлении данных опирается на абсолютный TTL, что скорее мешало в моем случае.
Memcached, напротив, — простой кэш. Вытесняет по LRU, четко соблюдает объемы памяти, ничего лишнего не пишет и вдобавок, обладает отличной производительностью.
Мне показалось что когда есть такое зарекомендовавшее себя средство, то проще потратить день на его допиливание. Зато клиентскую стророну, протестированную на тот момент, менять не пришлось.
Что касается улучшений в Hadoop/HBase, то изменилось, скорее, с нашей стороны. Мы избавились от основной своей проблемы — несбалансированных регионов. А также от небольших докучающих ошибок JobTracker'а.
Новую версию Hadoop также думаем накатывать. Из основного что хотим:
— символические ссылки в HDFS (удобство)
— работа RegionServer-а с локальными данными минуя DataNode (скорость)
— возможность компактить отдельные ColumnFamily (гибкость)
— динамическое распределение Mappers/Reducers
Как минимум, вот настолько улучшилась оригинальная поставка.
Но застав однажды такое вольное решение как svn.boost.org/trac/boost/ticket/850, сам предпочитаю getopt_long на *nix. (поясню — в версии 1.41 они _по-умолчанию_ стали вырезать кавычки из аргументов).
Он, конечно, на lightweight не претендует, но описание просто шикарное! Надо будет его попробовать.
В любом случае, можно пример как на нем собирать иерархический профайл пользовательской программы?
Чуть позже, для скорости, мы все перевели на Snappy.
А относительно недавно — на LZ4. Решительно все, в том числе и промежуточные данные map-reduce. Как ни странно, он оказался эффективней как по скорости так и по сжатию.
Про альтернативные распределенные ФС — сперва пробовали. Как упомянуто в статье, в компании тестировался Sector/Sphere. Но на тот момент она была совсем сырой.
Hadoop, как целая система, притягивал тем, что там все вокруг парадигмы MapReduce. Особых требований к ФС у нас не было. Такие вещи как быстрый поиск файлов, потребление CPU при множестве параллельных запросов и пр. показатели файловых систем общего назначения здесь не очень интересны.
MapReduce по своей природе склоняет к большим файлам. HBase, если его правильно использовать, — тем более. А скорость работы в основном определяется локальностью данных и архиватором.
Про вопиющий пример с выдачей — спасибо! Будем исправлять.
В случаях же, когда нам требуется «совсем серьезный» код, мы используем JNI. Просто потому, что дублировать наработки с плюсов на Java видится нецелесообразным.
В то время когда мы занялись Hadoop (2011), он был уже (приемлемо) стабилен. Чего нельзя было сказать про HBase. От тех кто работал с Hadoop'ом на заре его появления я часто слышал что «HBase сегодня такой же как когда-то Hadoop», так что охотно Вам верю.
Что касается мониторинга, то мы используем nagios для отдельных машин и ganglia для кластера в целом. Это помимо стандартных средств hadoop, само-собой. Также несколько самописных скриптов — больше для мониторинга HBase.
Но Вы правы — он выглядит соблазнительно. Особенно для задач статистики: логи, клики и т.п. Но даже наш отдел статистики, насколько мне известно, его не использует.
Есть много задач где это подойдет, например, кэш поисковика.
Кроме того, вот эти цитаты не могли не смутить: «It is NOT a cache solution» и "*NO* expiration. For memcache protocol compatible, still reserved, but we do nothing".
Собственно, последняя цитата из офф. документации «Totally for persistent. Transaction, replication, we do our best to achieve persistent» характеризует большинство альтернативных memcached-у решений: они не про простой и эффективный кэш, они про СУБД и гарантии записи. Про типизацию данных и оптимизацию последовательных чтений. Про внутренние скрипты и прочие вкусности. При более близком знакомстве вы понимаете что они не так просто эксплуатируются и вставляются в проект как memcache.
Собственно, да — это бывший membase, казалось бы — те же корни что и у memcached.
Спасибо что напомнили!
Что если они в одном датацентре и там что-то произошло с питанием?
Приходим к тому что надо разделять/реплицировать и т.д. и т.п. Между тем, дешевые диски простаивают.
Постараюсь сегодня это и сделать.
Memcached, напротив, — простой кэш. Вытесняет по LRU, четко соблюдает объемы памяти, ничего лишнего не пишет и вдобавок, обладает отличной производительностью.
Мне показалось что когда есть такое зарекомендовавшее себя средство, то проще потратить день на его допиливание. Зато клиентскую стророну, протестированную на тот момент, менять не пришлось.