Иван Бегтин

В последнее время всё больше появляется сервисов по извлечению информации из веб-сайтов. Например, сравнительно давно существует BuiltWith и недавно появился W3Tech.com.

Оба позволяют увидеть о сайте много всего интересного типа какие счетчики используются, какие технологии используются и какая CMS применяется.

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

Правда эти сервисы позволяют анализировать тренды в технологиях, их распространённость и так далее.

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

Например, данные о сайте Российской Газеты в обоих сервисах – http://w3techs.com/sites/info/rg.ru и http://builtwith.com/rg.ru. BuiltWith подробнее, но вообще Российской специфики маловато.

Или вот посмотрим Roem.ru – http://builtwith.com/roem.ru и http://w3techs.com/sites/info/roem.ru. Тут информации побольше, но, опять же Российской специфики мало.

Я, честно говоря, в своё время тоже интересовался этой же темой. Однако у меня цели были несколько иные – набивка базы массой вспомогательных метрик для улучшения различных алгоритмов обработки веб-страниц. Но промежуточный результат примерно такой же как в сервисах выше – извлечение массы признаков по группе правил, всего этих правил около 500. Этот механизм уже 1.5 года существует как веб-сервис и этот сервис использовался в ГосСети (www.govweb.ru) для сбора технологий на сайтах.

Сейчас у него есть простенький веб-интерфейс, http://data.skyur.ru в котором можно посмотреть как это работает на практике. Тем кому интересно могут посмотреть там те же сайты http://data.skyur.ru/?host=www.rg.ru и http://data.skyur.ru/?host=www.roem.ru или вот http://data.skyur.ru/?host=www.opennet.ru.

Но, в общем-то, это демка. Так что визуально всё без изысков. А вот стоит ли делать доступным веб-сервис пока не решил.

Оказывается на http://shootout.alioth.debian.org/ публикуют метрики большинства современных языков программирования из тех что можно запустить на Ubuntu, а то есть практически всех.

Из особенно интересного там есть метрики применения регулярных выражений – http://shootout.alioth.debian.org/u32q/benchmark.php?test=regexdna&lang=all&box=1 на Intel QuadCore Q6600.

Кстати, там много и других интересных сравнений реализаций алгоритмов.

Ну а для регулярных выражений, судя по тестам, там лидирует V8 JavaScript engine из Chromium. Ещё в феврале этого года они писали про движок Irregexp у себя в блоге и то что там реализовали компиляцию регулярных выражений в промежуточный автомат.  Что и говорить, результаты впечатляющие, обгоняют даже C++ реализацию на Boost, а мой любимый язык разработки Python так вообще отстаёт в 6 раз.

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

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

P.S. Кстати, бегло посмотрев код могу констатировать тот факт что в другие языки irregexp вполне можно перенести и вся реализация там укладывается в 700 строк, и, конечно, важно проверить его работу на живых, а не синтетических примерах дабы понять производительность на не-ASCII символах.

Как многие заметили в последнее время Скиур не распознавал многие из новостных страниц.
Основной проблемой этого являлась нарастающая нагрузка на и увеличивающееся число страниц для распознавания что и приводило к таймаутам и т.д. до ненахождения информации.

Чтобы решить эту проблему Скиур был довольно серьёзно изменён внутри:
- заменён парсер на более быстрый
- оптимизированы алгоритмы работы с регулярными выражениями
- анализ страниц выделен в отдельный сервис и теперь происходит асинхронно отображением.
- страницы проверяются на обновление раз в сутки.
- улучшено распознавание кодировок

Визуально практически ничего не изменилось, за исключением того что теперь при запросе ссылки на распознавание установлен таймаут в 7 секунд.

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

Если вкратце, то основной постулат такой – подавляющее число маркирующих кодов и уникальных идентификаторов создаются по ограниченному числу правил и подлежат разложению на ряд признаков позволяющих связывать эти коды с другими информационными массивами и справочниками, а также на их основе извлекать больше информации об исследуемых/анализируемых объектах.

Но, вернёмся к кодам – что это такое и как они есть. Буду приводить примеры:

• 049205770 – пример кода БИК – банковского идентификационного кода
• 02.03.1989 – пример записи даты в формате dd.mm.yyyy, где dd – день, mm – месяц, yyyy – год от рождества Христова
• ru.wikipedia.org – пример кодирования адреса в виде домена
• 09808117 – пример кода ОКПО,  общероссийского классификатора предприятий и организаций
• 5460000016 – пример кода ИНН. Идентификационного номера налогоплательщика
• 65.12, 65.22.5 - примеры кодов ОКВЭД
• 30401810701200001022 – пример кода корреспондентского счета банка в ЦБ РФ
• ALMZRU8Y – пример кода S.W.I.F.T используемого банковскими организациями
• ГОСТ Р 52980-2008 – пример кода в виде документа ГОСТ
• 454091 – российский почтовый индекс
• 359 – код по общероссийскому классификатору единиц измерения (ОКЕИ) означающий «сутки».
• NO93 8601 1117 947 – международный номер банковского счета, в примере номер счета в банке Норвегии
• 13001 – код правительства Российской Федерации по справочнику ОКОГУ
• 1021600000256 – пример общероссийского государственного регистрационного номера, ОГРН, присваеваемого юридическим лицам.
• ГС-1-50-02-26-0-7709342342-013097-1 – пример номера лицензии на проектирование зданий и сооружений
• 08050 – код улицы «Зелёный проспект» по общемосковскому классификатору улиц

плюс сюда же можно добавить такие коды как: номера банковских карт, автомобильные коды VIN, телефонные номера, коды ISBN, MAC адреса сетевых карт, IP адреса, коды EAN-8, EAN-13, GS-128, DUNS номера организаций в США и многие и многие другие.

Суть же всегда одна – кодирование информации об объектах, это способ решения следующих задач:

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

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

Continue reading «Онтология и примеры анализа кодов и идентификаторов»

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

В результате посмотрел на LangId.net и AlchemyAPI и там и там одна и та же ерунда – до половины всех русскоязычных документов определяются как вьетнамские.

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

Понятное дело что сервисных и утилитарных API для Рунета и русского языка в частности практически нет. Разьве что вот Яндекс стал предоставлять http://api.yandex.ru/speller/, но это капля в море.

А кто знает какие-либо полезные онлайн API, применимые к Рунету, русскому языку и распознаванию текста?

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

Текущая же проблема оказалась не столь очевидной, но не менее актуальной. К великому моему сожалению и удивлению Python не умеет сериализовывать скомпилированные регулярные выражения. Вернее он метит такие объекты как unmashalled и, в итоге, несмотря на наличие кода который подгружал базу регулярных выражений из кэша, на самом деле оказывалось что для каждой сессии, при подгрузке базы выражений из кеша, происходила полная их перекомпиляция, а это до нескольких секунд в зависимости от общей нагрузки на сервер.

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

В то же время есть варианты:

- либо компилировать выражения в C или Python код и подключить как уже готовые модули

- либо разрабатывать специальный сериализатор для регулярных выражений для Python ибо готовых нет

- либо выносить всю логику распознавания в отдельный сервер/сервис и обрабатывать все страницы в несколько потоков где выражения предварительно подгружены (самый простой способ)

- либо использовать для разбора веб-страниц не Python, а язык умеющий регулярные выражения сериализовывать

- либо отказаться от регулярных выражений и использовать иные правила анализа текстов.

Часть решений сугубо технические, часть алгоритмические. Какой подход проще уже понятно, непонятно какой лучше.

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

Хотя и может показаться обратное, но я не забыл про эту тему, хотя и она сейчас мне уже менее интересна чем ранее.

Сейчас моя книга «подвисла» посередине – готово 30 страниц, плюс несколько десятков разрозненных заметок и исследований которые надо сводить вместе.

Особенность в том что я не описываю алгоритмы, их нет вообще – я описываю со всеми подробностями правила и классификационные признаки которые по совокупности уже можно классифицировать с помощью SVM, Decision Trees или прочих алгоритмов.

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

По каждому правилу приводятся статистика и примеры, в некоторые случаях подробные, в некоторых случаях как «допущение».

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

Как бы то ни было, книга будет, в том или ином виде – когда точно я ещё отпишу, пока же с желающими можно будет обсудить эту тему на iCamp Russia.

Плюс появилось интересное чтение  в виде описания алгоритма Яндекса - http://helpcontext.ru/?p=507 по выявлению платных ссылок.

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

Цифры

Пока же приведу некоторые цифры:

- всего из активно используемых веб страниц имеется 2441 страница в RSS каталоге

- из этих страниц извлечено 123 640 новостных записей (регулярной очистки устаревших) и около 1 миллиона записей если устаревшие записи не вычищать.

- посещаемость у сайта весьма скромная, около 300 уникальных посетителей в сутки что, прямо скажем немного, но для некоммерческого сервиса вполне нормально

- а вот посещаемость RSS лент достигает 2500 уникальных посетителей в сутки.

Текущее состояние

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

Развитие

Проект я изначально задумывал как некоммерческим и он таким продолжает оставаться. Признаться я пока не окончательно решил в какую сторону его развивать – улучшения инструментариев для работы с RSS или сделать частью движка распознавания типовых форм данных (чем он и является внутри).  Пока же буду рад обсудить эту тему на iCamp Russia со всеми желающими. Хотя этот доклад и отсутствует в программе – презентация у меня будет с собой.

Пособирав в последнее время  все имеющиеся материалы прихожу к выводу что на пару книг у меня их хватит. А если писать активно, а не как сейчас – 2-3 страницы в день, то и на большее число. 

Тем, в принципе много, но конкретно сейчас есть желание завершить книгу которую я начал ещё в середине 2008 года по тематике АнтиСЕО – название будет несколько отличаться, но смысл именно таков. 

Основные способы и последствия продвижения сайтов с точки зрения выявления SEO активностей и платных/SEO ссылок поисковыми системами. 

Что в книге будет:

• информация необходимая для обнаружения платных ссылок;
• более 50 правила обнаружения;
• не менее одного примера по каждому правилу;

Чего в книге не будет:

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

Главная особенность книги в том что сам я лично не отношусь ни к SEO сообществу, ни к компаниям разработчикам поисковых машин. В противном случае в мне было писать её невыгодно или невозможно в виду NDA. 

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

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

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

—

Примерное содержания (не окончательное):

1. Вступление.

2. Введение

2.1. Зачем это нужно?

2.2. Мотивация участников рынка

2.3. Текущая ситуация

3. Основные определения

4. Необходимая информация для анализа

5. Правила анализа ссылок

5.1. Инструкции поисковым роботам

5.2. Происхождение и направление ссылки

5.3. Анализ структуры веб-страницы

5.4. Анализ текста ссылки и страницы

5.5. Анализ меток отношений и структуры веб сайтов

6. Технологии и практика

—-

Соответственно вопросы:

1. Интересна ли тема?

2. Знает ли кто-нибудь издательство которому было бы интересно такую книгу опубликовать?

3. Какие темы из перечисленных в содержании интересуют более всего?

Скиур, экспериментальный проект по извлечению новостей из HTML обновился. Основные изменения были внутренними, но кое что будет заметно и пользователям сервиса:

• вместо Couchdb теперь используется связка Couchdb + MySQL. Couchdb, конечно, прекрасный продукт, но производительность его пока оставляет желать лучшего. Поэтому иерархические данные, такие как веб страницы краулера хрянятся в Couchdb, а записи и ленты в MySQL;
• теперь доступен каталог RSS лент – перечень текущих успешно распознаваемых Скиуром лент;
• небольшие улучшения производительности;
• добавлена поддержка формата даты «dd.mm» без указания года, при этом год автоматически проставляется текущий.

И существующие баги/особенности:

• выявилось что в некоторых случаях Скиур не определяет автоматически структуру веб страницы даже когда распознаёт даты. Например, так не распознаются даты на странице Росгидромета - http://www.meteorf.ru/default.aspx. Причина пока неясна, но обязательно выяснится. 
• пока не решена окончательно задача по распознаванию всех возможных видов дат;
• примерно в 3% случаех кодировка веб страницы не распознаётся.