Пересечение морд доменов топ 1,000,000 по N-граммам

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



    Запускаем краулер









    Извлекаем текст, удаляем мусор, генерируем пятисловные шинглы





    На ответивших контентом страницах найдено 588,086,318 шинглов.

    Складываем каждый шингл с дополнительной информацией в датасет top1m_shingles:

    shingle,domain,position,count_on_page


    Рассчитываем n-граммы


    SELECT
      shingle,
      COUNT(shingle) cnt
    FROM
      top1m_shingles
    GROUP BY
      shingle
    


    На выходе имеем таблицу shingle_w из 476,380,752 уникальных n-грамм с весами.

    Дописываем вес шингла в рамках базы к исходному датасету:

    SELECT
      shingle,
      domain,
      position,
      count_on_page,
      b.cnt count_on_base
    FROM
      top1m_shingles AS a
    JOIN
      shingles_w AS b
    ON
      a.shingle = b.shingle
    


    Если получившийся датасет сгруппировать по документам (доменам) и сконкатить значения n-грамм и позиций, получим развесованную табличку для каждого домена.

    Обогащаем on_page показателями, средними, рассчитываем UNIQ RATIO для каждого документа (как соотношение количества уникальных шинглов в рамках базы к не уникальным), выводим n-граммы, генерируем страничку:





    Отчёт доступен по адресу: data.statoperator.com/report/habrahabr.ru и содержит полную таблицу с текстами шиглов и их значениями. Шинглы изначально не отсортированы. Если хочется просмотреть их в том порядке, в котором они шли в документе — сортните таблицу по позиции. Или по частоте в базе, как на изображении:



    Меняем домен в урле или вводим в форме поиска и смотрим отчёт по любому домену из списка Alexa top 1M.

    Интересно взглянуть на новостные сайты: data.statoperator.com/report/lenta.ru




    Средний показатель уникальности страниц: 82.2%



    Сбор данных: 2016-07-21
    Дата генерации отчёта: 2016-07-27
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 16

      +5

      Можно было сформулировать какие-либо практические выводы в конце статьи. Сейчас сплошные сырые данные без анализа.

        +1
        Для того, чтобы написать эту статью, мы:

        — развернули кластер
        — сделали 1,000,000 GET запросов
        — проанализировали 785,169 документов
        — выделили и обсчитали 588,086,318 n-грамм
        — сгенерировали 769,459 документов для каждого домена из списка
        — подняли интерфейс, настроили веб-сервис
        — показали как работает анализ по n-граммам на примере новостного сайта, объяснили как смотреть по домену
        — вывели средний показатель дуплицированности главных страниц всех самых популярных сайтов мира

        и вы пишете первым комментарием к статье:

        Можно было сформулировать какие-либо практические выводы в конце статьи. Сейчас сплошные сырые данные без анализа.

        У вас совесть есть?
          +5
          При чём тут совесть? У вас действительно сырые данные без анализа. Это же классическая проблема, например, дипломных работ на слабых кафедрах. Мы измерили экспрессию того и этого в разных условиях, мы молодцы. Молодцы, конечно, методы у вас вроде крутые, но анализ данных не самоцель. Зачем он проводился? Какие из полученных данных следуют выводы? На хабре могла бы проканать статья в стиле «Парсим и анализируем много страниц средствами такого-то фреймворка на таком-то кластере», но и используемые технологии не описаны.
            –1
            И обо всем этом вы почему-то пишите только в комментарии.
          +2
          Не совсем понятно про парсинг. Вы получили контент с 785 169 сайтов за 1 час 10 минут? Или только url получили для парсинга?
          Как рассчитать нормальную скорость парсинга для разных доменов? Например, я обрабатываю 250 тысяч доменов в сутки, из них 70 тысяч не отвечают совсем (грязная база). Это нормально на 1 компьютере с интернетом в 30 мб/с или мало?
            0
            За 1 час 10 минут был получен контент всех адекватно ответивших серверов до второго редиректа в состоянии n-грамм.

            Рассчитывать скорость собственной системы имеет смысл отталкиваясь от количества данных, которые она генерирует. Я не знаю, что вы парсите и сколько пишете. Мы генерируем данных больше, чем скачиваем, по железу упираемся в скорость записи хардов. Чем резолвить — тоже важно.
              +5
              не важно какую работу вы проделали, если объяснить не можете. Я вообще ничего не пойму из статьи.
              Во что превратился Хабр.
              0
              За 1 час 10 минут был получен контент всех адекватно ответивших серверов до второго редиректа в состоянии n-грамм.

              всё таки мне этот момент не очень понятен. Раз 1 000 000 вы делаете за 70 минут, то в минуту вы делаете 14285 доменов. Допустим, 1 миллиард доменов, тогда ((1 000 000 000/14285)/60)/24 приблизительно за 49 часов вы спарсите все главные в интернете? Или «в состоянии n-грамм» не подразумевает получение всей страницы?
              Также у вас мельком указано «извлекаем текст». Был извлечен текст, который просто вне тегов разметки внутри body?
                0
                скажите, пожалуйста, что именно вам кажется невозможным в задаче «спарсить миллиард главных за 50 часов»?
                  0
                  собственно, при 0.1 сек на получение и 0.1 сек на обработку данных (цифры из головы и, возможно, даже завышены), задача решается выполнением процесса уже всего лишь на 56 нодах =)
                  0
                  У вас ошибка в расчёте. Но в целом всё примерно так, ~ 49 суток одна нода будет выкачивать миллиард. Проблемы быстро накачать нет.

                  После получения html страницы текст извлекается вот так
                  Очищается и разбивается на n-граммы.
                    +2
                    извините, ошибся в расчетах. Точно 49 суток!!! Тогда нормально.
                    А в каком виде вы сохраняли результаты парсинга? В текстовых файлах или какое-то хранилище?
                    Также, для меня очень сложный вопрос, как вы решаете проблему с кодировками? Например, некоторые японские и арабские сайты никак не записываются в поля utf8 (стандартной БД). У меня не записываются. Приходится их править перед записью. Удалять недопустимые коды для utf8. У вас такая проблема была?
                    ps
                    очень интересны технические подробности.
                      0
                      Влезу в тред. У меня была разок очень весела проблема. Страница в 1251 c utf-ым BOM.
                      Касательно приведенной теме лично я делаю конвертацию в utf-8 (нужны были бы япоцы или арабы, то использовал бы что-то в духе utf-16) + храню исходный код как бинарную строку (больше для дебага). Конвертация позволяет отделить подсистему загрузку страниц от парсинга при котором действует правило «все находится в utf и только в нем». Недопустимые последовательности либо конвертируются, если могут, либо просто игнорируются (т.к. это 100% какой либо мусор не именующий отношения к нужным данным).
                        0
                        > если могут, либо просто игнорируются (т.к. это 100% какой либо мусор не именующий отношения к нужным данным).
                        я временно также игнорирую недопустимые последовательности, тем не менее — это не мусор. Это данные, просто написаны на ихних языках.
                        Разницу между utf 8 — 16 -32 кроме размера я не понимаю. Они вроде как одинаковые, нет?
                          0
                          Деталей с ходу не помню. Но вроде как да в контексте парсинга да, можно считать одинаковыми. И для международного парсинга использовать utf-32.
                          Если это не мусор, то через iconv конвертируется в корректные последовательности вполне нормально. При условии конечно правильного указания входной кодировки. Все остальное это будет уже либо мусор, либо ошибки (как приведенный мною пример с BOM).
                        0
                        Данные пишутся в HDFS

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое