Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Можно было сформулировать какие-либо практические выводы в конце статьи. Сейчас сплошные сырые данные без анализа.
Для того, чтобы написать эту статью, мы:
— развернули кластер
— сделали 1,000,000 GET запросов
— проанализировали 785,169 документов
— выделили и обсчитали 588,086,318 n-грамм
— сгенерировали 769,459 документов для каждого домена из списка
— подняли интерфейс, настроили веб-сервис
— показали как работает анализ по n-граммам на примере новостного сайта, объяснили как смотреть по домену
— вывели средний показатель дуплицированности главных страниц всех самых популярных сайтов мира
и вы пишете первым комментарием к статье:
У вас совесть есть?
— развернули кластер
— сделали 1,000,000 GET запросов
— проанализировали 785,169 документов
— выделили и обсчитали 588,086,318 n-грамм
— сгенерировали 769,459 документов для каждого домена из списка
— подняли интерфейс, настроили веб-сервис
— показали как работает анализ по n-граммам на примере новостного сайта, объяснили как смотреть по домену
— вывели средний показатель дуплицированности главных страниц всех самых популярных сайтов мира
и вы пишете первым комментарием к статье:
Можно было сформулировать какие-либо практические выводы в конце статьи. Сейчас сплошные сырые данные без анализа.
У вас совесть есть?
При чём тут совесть? У вас действительно сырые данные без анализа. Это же классическая проблема, например, дипломных работ на слабых кафедрах. Мы измерили экспрессию того и этого в разных условиях, мы молодцы. Молодцы, конечно, методы у вас вроде крутые, но анализ данных не самоцель. Зачем он проводился? Какие из полученных данных следуют выводы? На хабре могла бы проканать статья в стиле «Парсим и анализируем много страниц средствами такого-то фреймворка на таком-то кластере», но и используемые технологии не описаны.
И обо всем этом вы почему-то пишите только в комментарии.
Не совсем понятно про парсинг. Вы получили контент с 785 169 сайтов за 1 час 10 минут? Или только url получили для парсинга?
Как рассчитать нормальную скорость парсинга для разных доменов? Например, я обрабатываю 250 тысяч доменов в сутки, из них 70 тысяч не отвечают совсем (грязная база). Это нормально на 1 компьютере с интернетом в 30 мб/с или мало?
Как рассчитать нормальную скорость парсинга для разных доменов? Например, я обрабатываю 250 тысяч доменов в сутки, из них 70 тысяч не отвечают совсем (грязная база). Это нормально на 1 компьютере с интернетом в 30 мб/с или мало?
За 1 час 10 минут был получен контент всех адекватно ответивших серверов до второго редиректа в состоянии n-грамм.
Рассчитывать скорость собственной системы имеет смысл отталкиваясь от количества данных, которые она генерирует. Я не знаю, что вы парсите и сколько пишете. Мы генерируем данных больше, чем скачиваем, по железу упираемся в скорость записи хардов. Чем резолвить — тоже важно.
Рассчитывать скорость собственной системы имеет смысл отталкиваясь от количества данных, которые она генерирует. Я не знаю, что вы парсите и сколько пишете. Мы генерируем данных больше, чем скачиваем, по железу упираемся в скорость записи хардов. Чем резолвить — тоже важно.
За 1 час 10 минут был получен контент всех адекватно ответивших серверов до второго редиректа в состоянии n-грамм.
всё таки мне этот момент не очень понятен. Раз 1 000 000 вы делаете за 70 минут, то в минуту вы делаете 14285 доменов. Допустим, 1 миллиард доменов, тогда ((1 000 000 000/14285)/60)/24 приблизительно за 49 часов вы спарсите все главные в интернете? Или «в состоянии n-грамм» не подразумевает получение всей страницы?
Также у вас мельком указано «извлекаем текст». Был извлечен текст, который просто вне тегов разметки внутри body?
скажите, пожалуйста, что именно вам кажется невозможным в задаче «спарсить миллиард главных за 50 часов»?
извините, ошибся в расчетах. Точно 49 суток!!! Тогда нормально.
А в каком виде вы сохраняли результаты парсинга? В текстовых файлах или какое-то хранилище?
Также, для меня очень сложный вопрос, как вы решаете проблему с кодировками? Например, некоторые японские и арабские сайты никак не записываются в поля utf8 (стандартной БД). У меня не записываются. Приходится их править перед записью. Удалять недопустимые коды для utf8. У вас такая проблема была?
ps
очень интересны технические подробности.
А в каком виде вы сохраняли результаты парсинга? В текстовых файлах или какое-то хранилище?
Также, для меня очень сложный вопрос, как вы решаете проблему с кодировками? Например, некоторые японские и арабские сайты никак не записываются в поля utf8 (стандартной БД). У меня не записываются. Приходится их править перед записью. Удалять недопустимые коды для utf8. У вас такая проблема была?
ps
очень интересны технические подробности.
Влезу в тред. У меня была разок очень весела проблема. Страница в 1251 c utf-ым BOM.
Касательно приведенной теме лично я делаю конвертацию в utf-8 (нужны были бы япоцы или арабы, то использовал бы что-то в духе utf-16) + храню исходный код как бинарную строку (больше для дебага). Конвертация позволяет отделить подсистему загрузку страниц от парсинга при котором действует правило «все находится в utf и только в нем». Недопустимые последовательности либо конвертируются, если могут, либо просто игнорируются (т.к. это 100% какой либо мусор не именующий отношения к нужным данным).
Касательно приведенной теме лично я делаю конвертацию в utf-8 (нужны были бы япоцы или арабы, то использовал бы что-то в духе utf-16) + храню исходный код как бинарную строку (больше для дебага). Конвертация позволяет отделить подсистему загрузку страниц от парсинга при котором действует правило «все находится в utf и только в нем». Недопустимые последовательности либо конвертируются, если могут, либо просто игнорируются (т.к. это 100% какой либо мусор не именующий отношения к нужным данным).
> если могут, либо просто игнорируются (т.к. это 100% какой либо мусор не именующий отношения к нужным данным).
я временно также игнорирую недопустимые последовательности, тем не менее — это не мусор. Это данные, просто написаны на ихних языках.
Разницу между utf 8 — 16 -32 кроме размера я не понимаю. Они вроде как одинаковые, нет?
я временно также игнорирую недопустимые последовательности, тем не менее — это не мусор. Это данные, просто написаны на ихних языках.
Разницу между utf 8 — 16 -32 кроме размера я не понимаю. Они вроде как одинаковые, нет?
Деталей с ходу не помню. Но вроде как да в контексте парсинга да, можно считать одинаковыми. И для международного парсинга использовать utf-32.
Если это не мусор, то через iconv конвертируется в корректные последовательности вполне нормально. При условии конечно правильного указания входной кодировки. Все остальное это будет уже либо мусор, либо ошибки (как приведенный мною пример с BOM).
Если это не мусор, то через iconv конвертируется в корректные последовательности вполне нормально. При условии конечно правильного указания входной кодировки. Все остальное это будет уже либо мусор, либо ошибки (как приведенный мною пример с BOM).
Данные пишутся в HDFS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пересечение морд доменов топ 1,000,000 по N-граммам