• Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –32
    Guard деинсталлируется через удаление программ, стандартным образом.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –29
    Обновление скайпа не было с нашей подписью.
    С нашей подписью был загрузчик.

    Но по существу — а предложения обновить браузер с подписями других порталов вы видели?
    Установку тулбаров и прописывание домашних страниц при установке какого-нибудь ПО — видели?

    И, повторю, конкретно этот сайт, по способу распространения, я тоже считаю вредным.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –44
    Чувствую.
    Но вот только не наблюдаю этого в природе — можете привести примеры этой разницы?
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –24
    Нет.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –16
    Вы сильно преувеличиваете (или преуменьшаете).
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –57
    Guard — не Malaware.

    Задача его именно в защите настроек, если вы что-то поменяете и скажете в диалоговом окне Guard'а чтобы он их принял, он будет защищать ваши новые настройки, чтобы там ни было (хоть Яндекс, хоть Google).

    Нужен он для противодействия смене настроек без ведома пользователей.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –59
    Интерфейс отличается как минимум блоком с галочками — они явно видны и занимают треть от диалога.

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

    И Guard — не Malaware.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –8
    От Mail.Ru — загрузчик.
    Следующая программа будет со своим сертификатом, про неё пользователя спросят ещё раз.

    Мы выборочно проверяем, что загружается через загрузчик.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –76
    Это не отмазка, это ремарка о состоянии дел.
    Я имел в виду, что тулбары и браузеры распространяют почти все крупные интернет-порталы.

    Троянов мы не пишем и никогда писать не будем.

  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –47
    Тулбары и браузеры распространяют практически все интернет-порталы, остальной перечисленной вами деятельностью никакая интернет-компания не занимается.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –19
    Мы об это место при создании Загрузчика споткнулись, как раз были такие претензии со стороны антивирусных компаний.
    В WinAPI есть возможность запустить программу так, чтобы разрешения не наследовались, мы запускаем стороннюю программу именно так.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –54
    Я не PR-щик, я вообще не вижу смысла в том, чтобы на Хабре, т.е. в профессиональной тусовке, отвечал бы специалист по PR или SMM. Это просто глупо. Просто я, в частности, занимаюсь созданием Загрузчика, и поэтому на Хабре мне за него и отдуваться.

    В заголовке этой статьи написана неправда — нет никакого трояна с цифровой подписью Mail.Ru, замаскированного под обновления популярных программ. Это, действительно, не вопрос, а утверждение — но это всё равно неправда, поэтому мне пришлось ответить.

    Я могу ещё раз повторить то, что написано выше — софт (Загрузчик) сделан нами, поэтому он подписан нашей подписью.

    Анализ деятельности в системе приведён в статье, там есть скриншот network activity. Посмотрите на него:
    • скачивается файл, который хотел скачать пользователь (на который, если бы не было загрузчика, была бы прямая ссылка). В скриншоте это тот же домен, между прочим, на который пользователь попал. Если бы даунлоадера не было, то он бы качал эту прямую ссылку точно так же, как и через даунлоадер, ничего бы не поменялось.
    • сообщается нам (на сайт *.mail.ru) о том, что Загрузчик качал такой-то файл. Это анонимно, нам нужен только урл, чтобы делать проверку качаемого через загрузчик — что там нет вирусов или ещё какого-нибудь терша, мы выборочно проверяем этот контент на вирусы


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

    Т.е., если бы здесь не было загрузчика, то пользователь всё равно скачал бы указанный файл.

    Ещё раз повторю — я считаю, что реклама этого сайта через запугивание пользователя и принудительный запуск загрузчика по любому действию пользователя, это недопустимо.
    Но фактически там не было вирусов, там лежал обычный, чистый дистрибутив Скайпа.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –95
    Не мы первые это начали.
    Вот в этой статье я немного написал про историю дистрибуции: habrahabr.ru/company/mailru/blog/150303/
    Ну и в комментах там тоже много чего обсудили.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –66
    Работа такая, да.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –62
    Честно говоря, я не думаю что вирусным аналитикам это мешает — любая программа откуда-то качается или чем-то запускается.
  • Новый троян с валидной цифровой подписью LLC Mail.Ru маскируется под обновления популярных программ
    –195
    Здравствуйте.

    Mail.Ru не распространяет вирусы, троянские кони или malaware.

    Тем не менее, есть одна программа, которая делается нами — Mail.Ru Downloader — и которая определяется некоторыми антивирусами следующим образом (я перечисляю названия из ссылок на virustotal, которые приведены в статье):
    • not-a-virus:HEUR:Downloader.Win32.LMN.a
    • Win32:Downloader-SPV [PUP]
    • Adware.Downware.915
    • Adware.Downloader.MR


    Эта программа позволяет владельцу сайта, на котором можно что-то скачать (музыку, файлы, торренты) реализовать это скачивание через данную программу. В процессе скачивания она предлагает пользователю параллельно поставить ещё и Спутник или браузер, установить домашнюю страницу и поиск по умолчанию на Mail.Ru, а владелец сайта получает некоторый доход за новых пользователей, которых он таким образом привёл.

    Пользователю от всего этого можно отказаться, все галочки работоспособны. Больше программа ничего не делает — она качает указанный файл и может, при наличии проставленных галочек, установить весь дополнительный набор программ и опций. И она не вирус. Выглядит она так:



    Точно так же она не даёт никаких преимуществ программам, которые качаются через downloader — цифровой подписью подписан только Downloader, а всё что будет запускать пользователь потом — подписью Mail.Ru не подписывается и не может быть подписано, проверяется антивирусами отдельно и так отдельно Windows спрашивает пользователя на предмет того, доверяет он или не доверяет автору той программы.

    В этом смысле, несмотря на то, что скриншоты в статье правильные, сайт этот существовал (и был заблокирован), но выводы — неверные.

    Какие сайты ставят себе Downloader?

    Есть большие, крупные порталы, с которыми мы работаем напрямую.
    Есть «партнёрки», наподобие того же Политрафа, которые объединяют под собой мелкие сайты. Мы работаем с владельцами партнёрок, они уже дальше со своими партнёрами.

    Своих непосредственных партнёров мы контроллируем сами. Партнёров партнёрок контроллировать должны владельцы партнёрок, но мы тоже периодически проверяем сайты, с которых идёт скачивание, проверяем контент, который качается через downloader. Конкретно этот сайт вирусов не распространял — но он реализовал совершенно дикую рекламу (пугал пользователей) и не давал возможности уйти с сайта не скачивая downloader. Это мы тоже не приветствуем, сайт был заблокирован, причём именно даунлоадером.

    Почему её определяют антивирус, да ещё под такими странными названиями?

    Ну, названия такие потому что это всё-таки не вирус. Но это downloader, это adware — в этом смысле всё честно.
    Определяют потому, что иногда всё-таки какой-то сайт прорывается через проверки (или сначала ведёт себя чисто, а потом уже начинает бедокурить) и начинает распространять либо платные архивы, либо всё-таки вирусы — даунлоадер попадает под горячую руку и антивирусы блокируют заодно и еrо.

  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    0
    Спасибо, исправил.

    Cassandra создана не по подобию BigTable, а по white-paper от Amazon о Dynamo DB.

    Да, совершенно верно, но по-моему Dynamo можно считать родственником BigTable — а уж оттуда и родственность Кассандры. Там много отличий, но в целом для наших нужд теоретически подходили все такие решения, поэтому я их и упомянул вместе.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    0
    Вообще, мне тоже временами казалось, что активные участники этого треда имеют какое-то отношение к Яндексу.

    Но это не так. Вот NFM, к примеру, судя по всему был организатором своих партнёрских программ: forum.searchengines.ru/showthread.php?p=5490475#post5490475
    forum.searchengines.ru/showthread.php?p=6149319#post6149319
    Ну, т.е., скорее всего, конкурент той партнёрки, на сайты которой он жаловался.
    А сейчас занимается, сложно в это поверить, распространением своего тулбара: forum.searchengines.ru/showthread.php?t=658686
    (nicetest — название старой партнёрки)

    Тот ещё серпентарий, в общем.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    0
    У нас есть требования к партнёрам, если они их не выполняют — мы с ними прекращаем работать. Партнёрскую сеть мы проверяем, а так же разбираемся по жалобам.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +1
    Выход, судя по всему, не за горами.

    Во-первых, меняются платформы. PC с Windows в его текущем виде это, всё же, профессиональный инструмент. Пользователю, которому нужно ограниченное количество программ он в таком виде не требуется, смартфоны и планшеты с централизированным способом установки стороннего ПО уже удовлетворяют нужды обычных пользователей.

    А в этих платформах всё значительно жёстче, там уже не производитель браузера, а производитель платформы контроллирует поставщика поиска. В iOS в Safari поиск может быть любым, если это Google, Yahoo или Bing. То есть, новая версия Windows, новый способ установки ПО — и всё, все сидят на Bing'е (но это я утрирую, как раз Microsoft'у могут такого и не позволить сделать, монополист, «империя зла» и т.п.).

    Во-вторых, меняется интерфейс поиска. Если посмотреть на тот же Siri, то можно заметить, что это, хоть и пока что не очень функциональный, но прототип «поиска будущего». Ты ему вопрос, а он тебе — ответ. И тогда уже само мобильное устройство превращается в поисковую систему, а что там внутри, в какой реальный поиск оно транслирует запрос, может быть и не очень важно, поисковик (в современном виде) превращаются в какую-то малопонятную деталь под капотом смартфона, куда никто не добирается.

    И тогда «браузерные войны» превратятся уже в «войны платформ».
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    0
    Я ссылки передал, спасибо.
  • Поиск@Mail.Ru. Часть первая
    +1
    Спасибо :)
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +6
    А у нас есть: go.mail.ru/
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +2
    Интересно, как майл ру всегда в подобного рода вопросах переводит стрелки на конкурентов :)

    Конкуренты сами пришли. :)

    Разница видна невооруженным глазом.

    Ну, обычно оно всё-таки иначе выглядит, как-то так: s2.ipicture.ru/uploads/20120828/9ND7mR32.png

    По кликам идентично, два клика у нас, два клика у Яндекса.
    По составу, наш вариант на этом скриншоте, более сильный, да. Мы конечно будем дальше экспериментировать, чтобы он устанавливался более целенаправленно.

    PS. Про автоматическое открытие браузера — это не мы, это у Вас кто-то другой его открывает.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +4
    Я Вас понимаю.

    Но дело в том, что качеством продукта новых пользователей привлечь нельзя. Качество — это то, что оставляет пользователей у сервиса. То есть, сервис хороший, пользователю понравился, он остался на нём. Сервис не понравился, не привычен — пользователь сбежал.

    Но для того, чтобы этот процесс запустить, пользователь должен увидеть сервис. И вот эта задача для поисковиков и порталов решается, к сожалению, тулбарами и браузерами. Почему так получилось, я написал в статье.

    Для Mail.Ru же здесь довольно интересно — нас не воспринимают (не воспринимали?) как поиск. Средний пользователь РуНета пользуется почтой Mail.Ru и поиском Яндекса. Но люди банально не видят у нас поисковой строчки, не замечают её. Хотя по суммарной аудитории Mail.Ru и Яндекс примерно одинаковы. Как дать людям возможность понять, что у нас есть поиск тогда?
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +1
    Не понятно почему вы сделали вывод, что этого нельзя сделать в Lucene. Вообще, возможности кастомизации анализа текста в Lucene очень гибкие (как компоновкой существующих tokenizer/tokenfilter так и написанием своих компонент).

    Я же написал — сильная сторона Lucene это API. Сделать через него можно многое, но меня же интересовала конечная архитектура, а не конструктор. Вот реализации того, что я сказал, там же нет? То есть, если я знаю как, я могу это сделать в Lucene. Но знакомятся с чужими проектами для того, чтобы найти новые идеи, посмотреть, как это делается.

    Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.

    Алексей, заметьте, это вы написали про GC впервые, а не я. Я же как раз и сказал, что это не так критично, но C/C++ мне кажется в этом месте логичнее.

    На fetcher кластере все равно нужно
    а) сохранять скачанное (в hdfs/hbase?)
    b) как-то помечать что скачано/что нет (в hbase?)

    Нет, это как раз уже вычислительные задачи в моём понимании, т.е. это не «фетчер-кластер», а обычный HBase.

    Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа.

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

    А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).

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

    Мы используем HBase и там, да, мы и обсуждаем, и патчим. Вот пример самого эпического патча, повышающего скорость сканов с фильтрами и «перекошенными» по составу колонками в 10-20 раз: issues.apache.org/jira/browse/HBASE-5416. Это полгода тестирования, между прочим, хождения по самым разным граблям. Но это действительно полезный патч, на мой взгляд.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +1
    Вот пример неправды, кстати: nero-free.ru/ — инсталл за смс, даже в случае отмены установки без предупреждения устанавливает полный набор от мейл.ру. Очевидно, вам невыгодно отстреливать таких замечательных партнеров :) Или вот: icqskype.com/8-skajp-skachat.html И таких — тьма. Если мы вам пришлем списочек таких сайтов — откажетесь от их услуг?

    Присылай, конкретика меня интересует. Проверим, а там либо предупредим, либо откажемся. Моя почта у тебя есть, но всё равно: kalinin@corp.mail.ru

    Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.

    Смотри, устроить этическую истерику можно по любому поводу. Например.
    Вот вы ставите тулбар с uTorrent'ом. Для чего используется uTorrent? Что через него качают? Вы, значит, поддерживаете пиратов, крекеров и далее по списку того, что там лежит?
    И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?

    Ну это я так, без надрыва — просто наметил, прошёлся по твоему списку.

    Но факт остаётся фактом, лидер занимает самые лучшие места, потому что пришёл первым. В России лучшие места заняты Яндексом, а в мире, между прочим, Гуглом. И Волож, к примеру, утверждает, что это недобросовестная конкуренция со стороны Гугла, не пускать туда никого, кроме себя.

    А работа мне моя нравится, тут интересно.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +1
    О, Яндекс.
    Понимаю.

    Сергей, привет!

    Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.

    Неправда.

    Остальной плач Ярославны я комментировать не хочу, этическая истерика она такая, бороться с ней себе дороже. Ну что мне сказать тебе, что за партнёрами следят, их отстреливают, и что нам тоже это не надо, боремся с этим?

    Или что каналы дистрибуции не резиновые, и если что-то занял Яндекс или Гугл, то никому туда больше не попасть?

    Но ты же ведь уже вывод сделал:

    Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?

    И вот только Яндекс, весь в белом…

    Сергей, в общем, не хочу я устраивать тут срач между двумя компаниями. Вам всё мешает: Гугл мешает (см. интервью, которое я процитировал выше), Mail.Ru мешает, вы этими двумя компаниями недовольны. Ну и хорошо, лично я бы очень сильно бы напрягся, если бы ты нас похвалил.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +3
    Я описал причины существования и распространения Спутника в начале статьи.
    Он нужен как минимум в виде ответа на тулбары других компаний.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +1
    Пришлите, пожалуйста, на kalinin@corp.mail.ru примеры таких архивов.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    0
    Это наша большая головная боль.

    Дело в том, что этот файл, на котором срабатывают некоторые антивирусы — это наш загрузчик, он и подписан нашей цифровой подписью. И вирусов там нет.

    Вы посмотрите, что они там детектят, это всё эвристики проактивной защиты. Например, McAfee определяет его как Artemis с какой-то контрольной суммой, т.е. это срабатывание эвристики + контрольная сумма файла, на котором она сработала, вот тут у них больше полутысячи жалоб на неё: community.mcafee.com/community/security/malware_discussion/artemis?view=discussions

    Некоторые пишут что это Downloader — это, в общем, справедливо; он действительно дальше скачивает тот файл, который нужно загрузить. Но это не вирус, не троянский конь.

    С антивирусными компаниями мы общаемся, с некоторыми всё удачно проходит, а некоторые демонстрируют тут какую-то отмороженность, заявляя просто что они нас не любят и поэтому будут срабатывать и дальше. В некотором смысле, это всё те же элементы браузерных войн.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +5
    Там в начале ссылка на предыдущий пост, где написано про то, как и когда у нас появился поиск.
    Поиск от Яндекса был до 1-го января 2010-го года.
    Потом был наш поиск.
    Потом комбинация нашего поиска и поиска от Google.

    В общем, мы всех запутали, но поиск у нас есть, о нём и рассказываю.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +2
    Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные.

    Да, я примерно это и имел в виду. При этом Вы справедливо напоминаете про Solr Cloud — про него я забыл, там действительно есть интересные фишки.

    Рассказали бы про ваше хитрое решение — очень интересно.

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

    Вы правильно рассуждаете, про N-граммы. Но ведь просто взять и построить N-граммы для всего потока — это увеличить объём индекса как минимум вдвое (это если индекс не сжатый и если хранить слова и биграммы), а скорее и втрое-вчетверо (но реальное увеличение нужно проверять, индекс биграмм по-моему должен хуже сжиматься, чем индекс слов), а словарь — так на порядок. Поэтому индексировать все N-граммы только для того, чтобы при необходимости представить запрос в виде N-грамм довольно дорого (индекс же кладётся в память; если на диск — то без разницы, но поиск медленный получается).

    Поэтому все N-граммы строить нельзя, надо отбирать нужные. Нужны, очевидно, N-граммы со стоп-словами. Допустим, всё-таки, речь идёт о биграммах, тогда на каждое стоп-слово есть две биграммы (для последовательностей слов A S B, где S — стоп-слово, получается две биграммы, AS и SB). Проблема в том, что если сохранять в индексе обе, то они тоже будут занимать значительное место, 30-50% от объёма индекса. Поэтому нужно отбирать по одной биграмме. Как отбирать — просто так не понять, в каких-то случаях нужны одни биграммы, в других — иные (а неправильно выделенные биграммы начинают мешаться). Например, для запроса [что было бы если футурама], где «что было бы если» это название серии, а «футурама» — название сериала, биграмма «если-футурама» будет вредна и не нужна, т.к. цитатность здесь важна только в первой части запроса, а футурама может болтаться в документе где угодно.

    Поэтому отбор биграмм становится тесно связан с сегментацией запроса на части, выделением объектов из запросов и текстов и т.п.

    Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.

    Нет-нет, это мнение, на мой взгляд, совершенно неправильное и вредное.
    Неполные результаты поиска это очевидное зло, нельзя на него полагаться как на штатную ситуацию. Могу, кстати, сказать, что мы, с 2010-го года, сократили количество неполных результатов в потоке порядка на три, каждый раз считая что вот теперь-то у нас наконец-то стабильный поиск. А когда привыкаешь к низким числам в этой статистике, оглядываешься на старые показатели и думаешь, «вот ужас-то был».

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

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

    Но насколько я знаю, если такие вещи пишут на Java, то вообще пытаются не полагаться на собственный аллокатор, чтобы не бороться с GC. Выделяют памяти от пуза и уже работают с ней самостоятельно. Но я тут как раз перестаю понимать, зачем пользоваться Java, когда C/C++ есть :)

    Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?

    Да мы Nutch не использовали, мы своё писали. И у нас была такая мысль, сделать выкачку на том же кластере, что и всё остальное, «раз платформа есть». Но я просто считаю, что если задача хорошо и просто отделяется, отличается от остальных задач, то её нужно отделять. Выкачка, как я написал выше, очень специфична, ей требуются другие ресурсы. И, в общем, ни разу об этом решении не пожалели.

    А то ведь и сёрчеры тоже можно как-нибудь на Hadoop'е запустить, в принципе.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +2
    Конечно, нет.
    Пришлите мне, пожалуйста, на kalinin@corp.mail.ru, откуда Вы скачали наши продукты с вирусами.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +1
    Не дописал до конца, продолжаю.

    Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?

    Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.

    Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?

    Медленные сайты нельзя не качать, теряется полнота поиска.
    Поэтому, «решили тратить ресурсы другого кластера» :) Но он специфический, не такой, какой требуется для вычислительных задач.

    Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Он требует сетевых ресурсов, диска и, по сути, больше ничего. Hadoop для этого не нужен. Можно очень просто сделать процесс, который качает список урлов в 10000 потоков и сохраняет на локальный диск, сервера под это нужны не очень мощные. Hadoop нужен, чтобы готовить списки документов на выкачку (приоритезация, подавление дублей и т.п.), для сохранения результатов и их последующей обработки.

    В принципе, можно такой же процесс, асинхронно и во много потоков качающий сайты, реализовать и в виде редьюсера. Но, с другой стороны, мне очень не нравится идея запускать «вдруг» процесс, который может съесть значительное количество открытых файловых дескрипторов на сервере. Причём, на случайно выбранном сервере из кластера. А там и так могут быть проблемы с этими дескрипторами, потому что их довольно много требуется для работы регионсерверов HBase.

    То есть, если пойти на принцип, «делаем всё в Hadoop'е», то можно реализовать. Но проще вынести.
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +3
    А чего не хватает если по существу? Или просто «Java/gc тормозит»?

    Я лично не считаю Java безусловным недостатком, но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.

    По существу же ответ тут будет пространный, это же ведь и не недостаток, в общем-то, это просто разные задачи. Lucene — это универсальный движок, а веб-поиск заточен под конкретное применение и в нём, во-первых, много конкретных оптимизаций, сделанных под имеющиеся данные и важные для производительности (реализация эшелонирования как самый простой пример) и, во-вторых, сам движок невелик по отношению ко всякой обвязке, вокруг него накрученной. Тут и организация апдейтов, и failover и т.п. Про это редко рассказывают и, на мой взгляд, это самое интересное.

    В качестве иллюстрации вещей, специфичных для индекса, приведу первое, что приходит в голову — стоп-слова. Как решена проблема стоп-слов в Lucene? Они выкидываются. Но если их выкидывать, то становится сложнее искать цитатные запросы, т.е. выкидывать нельзя (а то [что где когда] не найдётся). А что делать, если не выкидывать? Относиться к ним как к обычным словам нельзя, они же большие, просто так ходить по их координатным блокам — мучение. Вот это уже интересный вопрос, решение которого требует некоторой смекалки и изворотливости.
    (Я, конечно, может и ошибаюсь, я Lucene сильно не изучал, может там всё иначе. )

    Сильная сторона Lucene — API, настройка на разные языки. Возможность внедрить к себе и не задумываться о том, что внутри поиска происходит. Часто именно это и нужно, но в веб-поиске движок дотачивается под поиск.

    И, повторю, из Lucene, наоборот, очень много чего интересного отпочковалось — Hadoop, HBase.

    Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.

    Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?

    В некотором смысле, «решили тратить ресурсы другого кластера» :)
    Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Соответственно процессы, обкачиваю
  • Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем
    +2
    Вы правы в количественном отношении.
    Я это показывал в выступлении на РИФе, тут есть слайд под номером 5 с иллюстрацией: go.mail.ru/blog/2012/04/27/pochemu-lyudi-menyayut-poiskovik/

    Было 70 тысяч переходов, вместо этого 20-25 тысяч ушли к конкурентам.

    Но в качественном отношении — это же очень много! Когда почта лежит, такого не случается.
    Кроме того, после восстановления работоспособности сервиса, кто-то всё-равно остаётся на новом поисковике.

    Понятно, задачи есть разные, что-то нужно искать прямо сейчас, а что-то и потерпит. Но поведение людей отличается.
  • Поиск@Mail.Ru. Часть первая
    +1
    Привет, Костя!

    1) Чем вы склеиваете Hadoop'овские таски в pipeline? Есть ли там вообще для этого механизм?
    Там есть такой механизм, называется chained reducers, по-моему. Но мы им не пользуемся.
    Ещё есть в Oozie организация запуска задач друг за другом — этим пользуемся.

    2) В Hadoop'е используете native API (Java) или стриминг в C++/Perl/Python whatever?
    Оба, но больше Java.
    Мы используем HBase, там нет удобных биндингов к другим языкам, да и для самого Hadoop'а в Java-интерфейсах есть много преимуществ перед стримингом. Поэтому стараемся использовать Java, а C++ код подключаем через JNI.
  • Поиск@Mail.Ru. Часть первая
    +1
    Пришлите мне, пожалуйста, адрес сайта на kalinin@corp.mail.ru — посмотрим, поправим.
  • Поиск@Mail.Ru. Часть первая
    +1
    Очевидно, да, и пример Яндекса с Гуглом это показывает :)

    Если серьёзно, то тут два вопроса, про собственный поиск и конкуренцию с Яндексом и Гуглом, и они, на самом деле, друг с другом не связаны. Поиск монетизируется за счёт рекламы, причём, наверное, это лучший способ рекламы в интернете, пользователь видит релевантные его запросу предложения. Соответственно, вне зависимости от того, какой используется движок, портал с поиском заинтересован в увеличении количества запросов. Тем самым, конкурировать с Яндексом и Гуглом на поисковом рынке нам придётся даже в том случае, если у нас будет какой-то чужой, лицензированный движок. И тут получается довольно странная ситуация, потому что с одной стороны, поиск можно взять только у них (ну ещё у Бинга), а с другой стороны они являются нашими конкурентами. Тем самым, если есть серьёзные амбиции, то разработка собственного поискового движка оправдана.