>для в задачах поиска
fixit

Hadoop запущен на около 40000 узлов (более 300 тысяч процессорных ядер)

Энтерпрайзненько однако...

Типа, «Ваше java приложение уже не запускается на необычном сервере, давайте запустим его на кластере» :)

на каком сервере вы будете обрабатывать пару петабайт данных?

лучше дать ссылку на видео с Hadoop World 2010 - там много интересного, включая use cases в конкретных компаниях

>уже не запускается на необычном сервере
300000/40000=7.5 ядер - вполне себе сервер, даже нищебродским не назовёшь.

Я не открывал ссылки, мне просто интересно: есть ли у Майкрософта и их партнеров такая система, и ликвидировали ли из Yahoo открытые компоненты после начала их сотрудничества?

Может что-то для своего Azure и придумали. Ну БД поверх Azure уже давно гоняется.

очередное не нужное лютое java ынтерпрайз bloatware...

>В дата центрах Hadoop запущен на около 40000 узлов
Parser panic

А память оно кушает как джава или всё-таки меньше?

Последний раз когда тестил hive(год назад) он лагал так что ппц. Скорость выборки была около 127строк(в среднем) в секунду на кластере из трёх виртуалок с подвисонами секунд по 5 на исполнение запроса.

Они что-нить в этом направлении сделали? :)

> Они что-нить в этом направлении сделали? :)

Оптимизировали hadoop для безглючной работы на трёх виртуалках? :) Вряд ли.

>> В дата центрах Hadoop запущен на около 40000 узлов

А память оно кушает как джава или всё-таки меньше?

При таких объемах память - не самое ценное. Такие объемы переваривают либо проприетарные системы или OpenSource на java. Выбор или пользоваться java или писать с нуля самому. Вряд ли получится на С или С++ написать быстрее, чем на Java SE. При сравнительной скорости работы.

> Последний раз когда тестил hive(год назад) он лагал так что ппц. Скорость выборки была около 127строк(в среднем) в секунду на кластере из трёх виртуалок с подвисонами секунд по 5 на исполнение запроса.

Hive как и Hadoop заточены под максимальную пропускную способность, а не минимальную задержку. Хотим минимум задержки - пихаем данные в кэш прямо на хосте. И никакого геморра, если данные влезли в память.

Hadoop для тех данных, которые не влезают ни в оперативку ни в винты одного даже очень большого серванта.

Hadoop для тех данных

Я не про хадуп, я про hive. Ты почитай, оно, походу, до сих пор неюзабельно вообще: http://www.mail-archive.com/hive-user@hadoop.apache.org/msg03921.html

Оптимизировали hadoop для безглючной работы на трёх виртуалках?

сам хадуп работал нормально, речь про hive.

> Я не про хадуп, я про hive. Ты почитай, оно, походу, до сих пор неюзабельно вообще: http://www.mail-archive.com/hive-user@hadoop.apache.org/msg03921.html

не ЛОР-стиль, но я прочитал =)))

так и написали, что Hive нужен если данных совсем много. Если кол-во данных не такое большое и влезает в одну машину, то РСУБД порвет Hive в клочья.

Hive это не распределенная РСУБД, это доп-движок которые пытается преобразовать SQL запрос в MapReduce и прогнать по кластеру Hadoop.

Есть большая вероятность, что «few million rows every day into a database» это довольно таки мало для современного железа. И размазывать обработку по многим нодам просто не эффективно - технические затраты MapReduce перекрывают преимущества по параллельной обработке. Особенно когда обработка ведется на одном сервере.

PS это как ставить Oracle ERP для написания Hello world. Вроде можно, но смысле ноль.

так и написали, что Hive нужен если данных совсем много

Ты это в продакшене видел? :). А вот Hello world на ERP будет прекрасно работать.

Спасибо, статья небольшая, но нужная

>> так и написали, что Hive нужен если данных совсем много

Ты это в продакшене видел? :). А вот Hello world на ERP будет прекрасно работать.

конкретно Hive - нет. видел другие технологии которые казались полным бредом... и вправду им являются пока сложность задач не выростает до определенного предела. Тогда и INNER JOIN начинаешь переписывать на WHERE IN и другие приколы.

Hello World на ERP могут себе позволить только дети «новых русских». Для остальных заплатить несколько десятков зеленых енотов слишком дорого за среду запуска HW.

А в чём новость то?

В чем новость? Об этом самом я слышал еще на Яндексовской Yet Another Conference. А те кто в теме и работают с этим, наверняка, вообще недоумевают зачем это

Логотип

С чем связана звезда Давида на логотипе? Разработчикам нееврейсой национальносте будет позволено использовать технологию?

Тогда и INNER JOIN начинаешь переписывать на WHERE IN и другие приколы.

Это всё понятно, но я не это хочу сказать. Я хочу сказать что есть подозрение что не существует таких задач где бы hive был эффективен.

Скорее всего да. Hive это типа SQL поверх MapReduce. Если нужна эффективность MR, то нужно писать в терминах MR. А если SQL, то вероятнее РСУБД будет эффективнее.

Я хочу сказать что есть подозрение что не существует таких задач где бы hive был эффективен.

у вас от серверов приходит свыше 40Гб логов в день, нужно прогнать запрос на статистику и т.д. Имеется 2 пути решения задачи:

1. писать собственный map-reduce job, который пройдёт по всем этим логам и обработает
2. использовать hive, который предоставляет возможность использовать sql-подобный синтаксис, а уже внутренний разбор берёт на себя.

а теперь добавим сюда условие, что запросов не 1 и не 2, причём они регулярно меняются, формат логов редко, но тоже меняется.

p.s. размер данных и задачаа реальны, всё гоняется уже в проде

[qoute]Скорее всего да. Hive это типа SQL поверх MapReduce. Если нужна эффективность MR, то нужно писать в терминах MR. А если SQL, то вероятнее РСУБД будет эффективнее. [qoute]

помимо простого map-reduce hive позволяет производить достаточно легко то же партицирование данных, которое в какой-то мере выступает в роли индексов. Конечно всё это можно сделать и вручную разнеся данные по нужным папкам, но опять же это дополнительная трата сил на разработку джобов и последующую их поддержку в актуальном состоянии.

>Имеется 2 пути решения задачи:

Есть еще третий:) Логи - это сигнал. Применяешь сжатие сигнала с потерями - получаешь сжатый сигнал. По сжатому сигналу статистика +/- погрешность считается очень быстро.

точнее масштабирование

а если тебе нужно много срезов по данным ?

ведь нельзя по краткому пересказу судить о произведении и уточнять моменты, согласен, что после первичной обработки данные храняться уже достаточно отфильтрованными и размеры их уменьшаются, но первичные срезы всё равно проходят по свежим логам.

>а если тебе нужно много срезов по данным ?

Несколько обработанных сигналов. Компрессия происходит один вход -0 несколько выходов.

ведь нельзя по краткому пересказу судить о произведении и уточнять моменты,

Зато можно по маленькой фотографии судить о том что изображено на большой, если точность устраивает....;)

Если получается построить модель при которой сжатие сигнала определенным образом будет выдавать одни и те же ответы - то это очень хорошая альтернатива кластерам колбасящим терабайты логов.

всё гоняется уже в проде

сколько строк в секунду оно просматривает?

>Если получается построить модель при которой сжатие сигнала определенным образом будет выдавать одни и те же ответы - то это очень хорошая альтернатива кластерам колбасящим терабайты логов.

1. логи банерных сетей, и если для таргетинга ещё с моделью куда не шло, то вот счета рекламодатели просят выставлять точными 2. сервисы-счётчики и сбора статистики по посещениям сайта (гео, откуда и т.д.), тоже предпочитают получать данные в числовом эквиваленте.

>то вот счета рекламодатели просят выставлять точными

допустим 1000 показов - 1USD. точность 1:10 ни на что не влияет.

сервисы-счётчики

вообще одну цифру хотят:)

тестовый кластерок для проверки алгоритмов (1 неймнода с 1гб оперативы и 2 датаноды с 2гб на каждом, на всех 32битныее целерончики по 2.53ГГц), обычный plain файл на 700Мб с 1.3млн записями перемалывается в зависимости от сложности запроса от 2х до 6 минут. Правда собран из ветки 0.6, которую не зарелизили, хотя усиленно уже пилят 0.7

если использовать не просто plain, а рекомендованные для частых выборок rcfile, то результаты получше, так как plain ещё и парсить каждый раз приходится.

в виртуалках можно только проверить как настраивать кластер, от того что запустишь 3-4 на одной физ машине выгоды не будет, так как на виртуализацию пенальти больше получишь.

А вообще до тех пор пока у тебя не миллионы данных смысла от хадупа нету, так как запуск джоба достаточно долгая операция.

hive подходит когда нужно обработать много данных и скорость получения результата не критичка, главное результат чтобы выдал, данные изменяются редко (добавление у hive не предусмотрено, только объединение ух выборок с перезаписью результата куда надо)

Когда нужно получить более быстрый ответ, а не заниматься аналитикой, и данные меняются часто, то тут лучше hbase.

причём тоже желательно собирать самому, так как такое чувство что разработчики выпускают релиз а дальше хоть трава не рости, все оптимизации и патчи пихаются в следующую версию, причём очень активно, а для текущей заплатки и то самому приходится накладывать

ты бы хотел если бы за твои разговоры по мобилке оператор взял для примера 3 дня случайных и выставил счёт тебе за месяц? Когда дело доходит до денег, все хотят точные цифры, а «не было где-то столько.....»

на счётчик можно повесить обработку откуда к тебе пришли, как уже выше писалось гео, распределение по браузерам, ос и т.д. Для тех кому достаточно одной цифры думаю хватит простейшего php скрипта

Типа, ваше хелло-джава-приложение не влезает в пару петабайт, давайте запустим его на кластере?

от того что запустишь 3-4 на одной физ машине выгоды не будет

ай, забыл сказать, виртуалки на разных физмашинах была. паралельно ещё ксен тестился. Конечно не на одной тачке вертелось, мы типа облако собирали. Правда, сеть была 100мбит, грешу на неё.

обычный plain файл на 700Мб с 1.3млн записями перемалывается в зависимости от сложности запроса от 2х до 6 минут

писец. Ну я так и думал. Сколько же оно у вас многотеррабайтные логи обрабатывает тогда??

Вот честно, может для программистов это и удобный вариант, но ппц тормозной даже на примитивных задачах. А с учётом сырцов этого самого хадупа(приходилось править скрипты его под наши задачи, в саму яву не лез) я до упячки радовался когда задачу с меня сняли. Там был грязнейший быдлокод по принципу «хоть бы оно у нас запустилось».

по воводу скриптов запуска согласен, во многих местах сделано для запуска хомячками, причём явно не в виде сервисов, а ручками скрипт запустил, оно как-то стартануло и радуйся.

в ява части тоже хватает веселья, особенно в работе с диском, именно поэтому для запуска его под виндой нужен цигвин, ну или патчить самому, в jira патчи на включение висят на использование jni

до обработки терабайтов за раз ещё не дорасли, хотя на hdfs уже давно храниться больше, но и машинок там не 2, и не целероны одноядерные. К тому же уже там не plain-text, а rcfile, в общем не просто закинули и давайте гонять, а дополнительно настраивалось.

свыше 3.5-10.8т строк/с, на «кластере» из 2х ядер (максимум 3 для тестов если неймноду ещё подключить, но там только гиг памяти, есть риск провалиться в своп, а дождаться завершения явы работающей со свопом это надо быть истинным буддистом), то думаю терпимо, имея в запасе практически линейную маштабируемость с ростом узлов.

уже писалось что это одноядерные целероны на 2.5ГГц, 32бита, 2Гб памяти, 100 мбит сетевухи, сейчас не то что сервер, десктоп с такой конфигурацией сложно найти.

если можете предложить какую другую технологию буду ОЧЕНЬ РАД выслушать, так как на данный момент лично я не вижу альтернативы для таких числодробилок.

p.s. больше похоже что виртуалки всё-таки дали такой бешенный пенальти, так как прогонялись тесты на одном мощном сервере под freebsd: завести несколько джейлов и внутрь их ставить хадупы, в итоге сумарная скорость обработки этих нескольких узлов оказывалась меньше, чем если на машине один джейл и все ресурсы занимает один инстанс хадупа, и это в условиях когда во фряхе вообще никак не лимитируются ресурсы между джейлами.

А разве яху сейчас не использует bing от M$?

может перестанешь фантазировать и начнёшь думать?

> >Имеется 2 пути решения задачи:

Есть еще третий:) Логи - это сигнал. Применяешь сжатие сигнала с потерями - получаешь сжатый сигнал. По сжатому сигналу статистика +/- погрешность считается очень быстро.

Предложи данную схему вашему главбуху для обработки отчётности. lmao

> С чем связана звезда Давида на логотипе?

По субботам не работает - шабаш. :p

хотя на hdfs уже давно храниться больше

А в итоге hive используется в продакшение? :)

если можете предложить какую другую технологию

Увы, нет, я переключился на другие вещи.

от тебя-то я такого не ожидал - это же уровень анонимусов из средних классов школы

> от тебя-то я такого не ожидал - это же уровень анонимусов из средних классов школы

А разве он не школьник (студень в лучшем случае)?

вас от серверов приходит свыше 40Гб логов в день, нужно прогнать запрос на статистику и т.д.

>вас от серверов приходит свыше 40Гб логов в день, нужно прогнать запрос на статистику и т.д.

Привет, есть ли у тебя реальный позитивный опыт работы с Hive?

Лично мне пока удобнее под Hadoop писать свои map/reduce задачи
и результаты складывать в обычную базу.

Логов в день правда всего 15GB но мы ростём ;-)

мне казалось что нет, но сейчас я не уверен

в конце концов это всё и складывается в обычную базу, откуда её и забирают клиенты.

опыт имеется, суть в том что обработка по хадупу это все лишь одна из частей достаточно долгого процесса. Хайв был выбран за то что имеенся jdbc драйвер который нормально подхватывается из Pentaho, следовательно изменения вносить значительно проще.

но там уже всё настроено и потиху работает. ещё одна причина выбора хайва заключается в том что для написания задач ручками нужно опыта побольше, чтобы не получить быдлокод, а когда пользователей несколько, то проще дать им стандартный sql доступ, чем следить какой код они навают. Про просадку по производительности знаю.

из последнего занимался тестированием под нагрузкой hbase и cassandra, если опыт работы с данными технологиями, то был бы рад выслушать, потому что ощущения от них спорные: у cassandra после compaction хз как ограничить макс размер файла который непрерывно растёт и судя по жире и документации они только обрумывают как это делать, а также балансировка данных (в теории раскидывать по хешам хорошо, на практике как-то бывает не очень), но там очень хороший jmx интерфейс, с другой стороны hbase, jmx и гибкость намного меньше, скорость также меньше, но и непонятки с кешированием присутвсуют, так как кешируют челиком блоки, а не отдельные инстансы, в результате на рандомном чтении мы оказываемся в большой опе.

пока остановились на hbase, потому что у него присутвует связка hbase-hive. результаты работы в связке пока не могу сказать, этим сейчас и занимаюсь.

p.s. если не секрет на какой ос работаете (лин, фряха) и какой хадуп сипользуете (апах, яхо, клоудера) ?