Иван Бегтин

В Arstechnica появилась хорошая статья про SPDY^eng – протокол ускорения загрузки веб-страниц который предлагают иccледователи из Google.

SPDY – это протокол расширяющий и дополняющий HTTP таким образом чтобы убрать из него все неоднозначности, вроде того что статус в ответе описан иначе чем остальные поля и сжатие запросов и ответов и так далее.  Подробнее можно прочитать здесь – http://dev.chromium.org/spdy

При том что действительно, тема интересная важная и так далее, а Google при его массе и скорости может эту идею даже протолкнуть, на самом деле всё несколько сложнее. Собственно в статье в Arstecnica это изложено:

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

2. Протокол SCTP который там уже упоминается всё ещё в весьма зачаточном состоянии, примерно как IPv6, но IPv6 всё таки активно продвигается на страхе что адреса IPv4 скоро закончатся, а вот для SCTP такой мотивации нет, а изменений потребуется не меньше. В то же время без SCTP эффект от SPDY поверх TCP будет невелик.

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

На мой взгляд подход должен быть иным – не подмена протокола, а организаций кеширования, prefetching и реорганизация контента под блочное кеширование.

А то есть менять надо не транспортный протокол который затронет операционные системы, сетевое оборудование, IDS системы, фаерволы, антивирусы и прочая, прочая.

Вместо этого можно поступить так:

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

2.  Из SPDY взять те идеи которые не слишком меняют текущий HTTP протокол, например, сжатие заголовков HTTP, запрет на дублирование заголовков и так далее, а также добавить веб-сайтам способность идентифицировать что протокол поддерживается и предоставлять доступ к нему по определённому урлу.

3. Предложить механизмы, программы, продукты и так далее кеширования отдельных участков веб страниц и интегрировать эту информацию на уровне HTTP протокола. То есть создать возможность при запросе веб-страницы или любого иного документа с комплексным содержимым возвращать не один ETag код, а несколько хэшей/идентификаторов блоков, но не более 20 блоков. Далее с помощью расширения к HTTP запрашивать о том не изменились ли отдельные или все блоки и в результате получать не всю страницу или подтверждения что она не менялась, а статус частично изменено и данные только изменившихся блоков склейка которых происходит уже на клиенте.

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

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

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

Только что вернулись с iCamp Russia 2009 – впечатлений и общения было очень много, постараюсь рассказать о самом интересном.

В первый день в Нижнем Новгороде меня более всего впечатлили 3 доклада:

• Анатолий Левенчук  (ailev) рассказывал про килопроекты и системную инженерию (system engineering) – тема очень интересная и актуальная. Жаль что у нас в стране проектов примеры которых он приводит очень и очень мало. Если вообще есть в последние годы
• Дмитрий Песков (sartac) говорил про Метавер и образование которое вкорне отличается от принятых ныне подходов к обучению. По классификации ЛЕСа на iCamp – это чистой воды «эльфийская» тема, нацеленная на социальное переустройство, а не на прибыль и тем более эта тема интересна. Очень надеюсь что она приобретёт своё развитие.
• Гаррет Джонсон из МТС буквально зажигал на сцене рассказывая про мобильные устройства. То о чем он говорил запоминалось с трудом, но драйву и движухи в его выступлении было очень много.

Далее 4 дня на теплоходе – небольшие секции, выступления и доклады на уже куда меньшую аудиторию.

Лично я успел рассказать 4 секции:

• Государственный интернет
• Автоматическая геоклассификация веб-сайтов
• OpenGovData.ru: приглашение к проекту
• Государственные закупки. Стоит ли участвовать?

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

Тема госзакупок заинтересовала очень многих – однако лично я отметил что немногие на самом деле знают как устроено наше государство изнутри. Реально не хватает книг – «Госуправление за 24 часа» и «Государство для чайников» где всё было бы описано просто и доходчиво.

В ближайшее время постараюсь выложить свои презентации в сети и они появятся в блоге.

Какие выступления понравились более всего:

• «Ответственный пациент» Бориса Зингермана. Понятно и очень доходчиво про электронную историю болезни и то как гражданин/пациент может сам управлять своей информацией.
• Несколько выступлений Олега Кудрявцева про привлечение инвестиций и то как нужно презентовать свои проекты инвесторов. Много реальных примеров и описание логики и стиля мышления инвесторов. При том что в основном речь шла об инвесторах стратегических, а не венчурных, было интересно.

Что также хочу отметить – так выступления про облачные вычисления Андрея Артищева из Оверсан Скалакси. Тема интересная, видно что у создателей есть понимание того что они хотят сделать, но лично мне интересно в какую форму они облекут услуги и какие будут цены по сравнению с тем же Amazon AWS. В любом случае – пусть растет сто цветов и чем больше провайдеров облачного хостинга, тем больше конкуренция, качество услуг и так далее.

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

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

Цифры

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

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

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

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

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

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

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

Развитие

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

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

Для начала приведу цифры по преобразованию документов в случае OpenXML – в одном из следующих постов попробую описать ту же процедуру для OpenDocument. Попробую, поскольку создание стенда для OpenDocument сложнее, но возможно.

Для начала как и что проверялось.

Проверялись 4 датасета документов из архива Енота Поискуна:

• 318 документов OpenDocument (.odt) – 14 482 368 байт
• 620 документов OOXML (.docx и .xlsx) – 24 451 860 байт
• 419 документов MS Office 2000/XP/2003 (.doc, .xls) – 58 669 568 байт
• 39 документов MS Powerpoint  2000/XP/2003 (.ppt) – 74 423 296 байт

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

Причем с датасетами проверялось следующее:

• для документов OOXML и OpenDocument проверялась пригодность для «дожатия» документов. Техника которую я ранее описывал в заметке практическое сжатие электронных документов.
• для документов MS Office проверялось их сжатие после преобразование в OpenXML с последующим «дожатием».

Проверка «дожатия» документов

Дожатие документов проводилось по принципу пережатия ZIP контейнера улучшенным deflate алгоритмом (см. статью выше) и пережатием изображений в документах алгоритмами без потери качества.

Для датасета документов OpenDocument документы были дожаты до совокупного объёма в 12 364 803 байт или, иначе, до 85,37% от начального объёма.

Для датасета документов OOXML документы были дожаты до совокупного объёма в 17 113 886 байт или, иначе, до 70% от начального объёма.

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

Для датасета OpenDocument средний размер документа  равен: 14 482 368 / 318 = 45 562 байт до дожатия и 12 364 803 / 318 =38 883 байт после дожатия.

Для датасета OOXML средний размер документа дожатия равен: 24 451 860 / 620 = 39 438 байт до дожатия и 17 113 886 /620 = 27 603 байт после дожатия.

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

В чем особенность, например, формата OpenDocument и работы OpenOffice?

Если распаковать любой ODT документ и заглянуть в его внутренности то там можно обнаружить:

• папку Thumbnails содержащую файл thumbnail.png размером от 900 байт до 10 000 байт, в среднем же около 5400 байт
• папку Configurations2 содержащую ряд (обычно) пустых поддиректорий и конфигурацию OpenOffice
• файл двоичный файл layout-cache размером от 18 до 881 байта (по тем данным что есть) или, в среднем, 121 байт
• а также перечисление всех этих файлов в файле META-INF/manifest.xml

Обо всей этой информации можно сказать с уверенностью лишь одно – к содержанию документа она отношения не имеет. Это «полезный мусор» и некоторые удобства при работе в виде thumbnail’а, но не более.

Проверять вычистку ODT документов автоматически задача довольно трудоёмкая, поэтому произвольным образом была сделана проверка «дожатия» на примере одного документа размером в 30 836 байт в оригинальном виде и в 30 328 байт в «дожатом виде» (пережат контейнер и картинки). В итоге после удаления Thumbnails, Configurations2, layout-cache и чистки манифеста файла, и последующего сжатия в контейнер размер документа составил 18 007 байт, или 58% от оригинального файла. Что гораздо лучше чем просто сжатие документов OpenDocument и лучше даже чем сжатие OOXML. Итого, за счёт ряда ухищрений и доработки OpenOffice, в том что касается долгосрочного хранения докуменов и небольшого их объёма OpenDocument не уступит OOXML.

Сжатие докуметов MS Office преобразованием в OpenXML

Впрочем задача дожимать документы возникает сравнительно редко, чаще возникает вопрос выигрыша при переводе документов из устаревших форматов в новые. Но инструментов преобразования документов немного – фактически для перевода офисных документов в OpenDocument мало вариантов кроме как воспользоваться API OpenOffice, а для перевода документов в OOXML есть варианты в виде API MS Office и B2XTranslator (http://b2xtranslator.sourceforge.net/) – бесплатный движок на работающий на .NET и Mono.

В данном случае тестирование проводилось именно с помощью B2xtranslator которые более чем другие способы заточен под потоковое преобразование документов.

С его помощью два датасета – датасет документов MS Office (.doc, .xls) и датасет презентаций MS Powerpoint были преобразованы в формат OpenXML, а далее уже имеющимся у меня движком «дожаты» в части ZIP контейнера и изображений.

В итоге получились следующие результаты.

Преобразованием в OpenXML датасет документов MS Office (.doc, .xls) был уменьшен до 16,78% от начального объёма (от 58 669 568 байт до 9 848 436 байт), а то есть в 6 раз.

После дожатия документов их объём составил 9 401 414 байт или 16,02%. Можно обратить внимание что дожатие документов принесло всего около 0,76% выигрыша объёма и связано это с несколькими факторами:

• файлы .doc и .xls из выборки почти не содержали изображений
• b2xtranslator использует более эффективный Deflate алгоритм для создания ZIP файлов и дожатие помогает несильно.

Преобразованием в OpenXML датасет презентаций MS Powerpoint был уменьшен до 84% от начального объёма (от 74 423 296 байт до 62 634 326 байт), а то есть на 15%.

После дожатия документов их объём составил 55 137 124 байт или 74%.

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

При этом, сжатие презентаций может быть существенно улучшено при использовании дожатия с потерями, например, преобразованием векторной графики и внедренных OLE объектов картинок Adobe Photoshop и Corel Draw в растровые изображения.

Неохваченное и нюансы

1. Неохваченным осталось преобразование документов из форматов MS Office в OpenDocument, но для того чтобы его организовать на поток надо соответствующим образом собирать стенд с OpenOffice’ом. Если кто-нибудь хочет это проделать самостоятельно – могу передать все вышеперечисленные датасеты для экспериментов.

2. b2xtranslator всё ещё ОЧЕНЬ сырой продукт. Несмотря на то что разработчики в нём очень оперативно реагируют на каждый отправленный им баг (а я им отправил уже с 5 штук), тем не менее в некоторых случаях он производит нечитаемые OpenXML документы, а в некоторых просто виснет.

3. Преобразование документов, разумеется, фатально с точки зрения эталонности документов, наличия у них ЭЦП и так далее. Преобразованный документ по объёму существенно отличается от оригинала.

Зачем всё это нужно?

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

В моём случае вопрос упирается в то что документов накопилось уже несколько сотен тысяч и в общей совокупности это более 48 гигабайт.

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

Ранее я упоминал про недавнее исследование из Яндекса – Автоматическая классификация веб сайтов (в PDF) и что лично я несогласен с подходом использующим классификацию по ключевым словам.  Главное – это то что у Яндекса как и других поисковых систем, на самом деле, куда больше информации о сайтах, пользователях и их взаимодействии чем просто страницы и ключевые слова. Этой информации столь много – что принцип «больше данных, проще алгоритмы» должен подходить здесь на 100% и я опишу несколько вариантов классификации сайтов построенных именно на таких данных.

1. Классификация по аудитории

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

В случае Яндекса задача сбора информации об аудитории сложной быть не должна поскольку в качестве эталонной выборки сайтов могут использоваться сайты внесённые в Яндекс.Каталог, а для определения посетителя показы рекламы в Директе.

Таким образом как раз у Яндекса есть возможность определения тематики сайта по аудитории.

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

2. Классификация по карте объектов сайта

Карта объектов – это совокупность смысловых и структурных объектов (обладающих собственным значением или связанными со смысловыми понятиями элементов сайта).

Приведу несколько примеров элементов объектной разметки:

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

- табличные данные

- навигационное меню сайта

- счетчики

- рекламные блоки

плюс множество других объектов.

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

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

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

Лично я считаю именно этот подход наиболее переспективным.

3. Классификация по входящим и исходящим ссылкам

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

4. Классификация по интересам владельцев сайтов

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

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

5. Классификация по социальным закладкам

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

Захожу я сегодня на новый сайт Министерства Энергетики, а поскольку я обычно просматриваю интересные сайты полностью хотя бы уровня до второго – вдруг что интересное, то и тут посмотрел внимательнее.

Про 8-ФЗ на этот раз не буду, они там даже ссылку на него разместили и это правильно.

Я на сей раз о другом, простом, но режущем глаза наблюдении.

В нескольких (не менее 3-х разделах) там ничто иное как типовые картинки из банков фотографий. Может быть не самых популярных банков изображений, но тем не менее факт имеет место быть.

Приведу конкретные примеры:

• Раздел «Международное сотрудничество» - http://minenergo.gov.ru/activity/co-operation/ смотрим картинку в TinEye -http://tineye.com/search/0b80287006d978035ebaf71ec3adc76464dc5f94
• Раздел «Задачи» - http://minenergo.gov.ru/activity/zadachi/ смотрим картинку в TinEye - http://tineye.com/search/ead5d98f33aa35b7ede2fb0e3d36946c3fa1643a
• Раздел «Возобнавляемые источники энергии» - http://minenergo.gov.ru/activity/vie/ смотрим картинку в TinEye - http://tineye.com/search/e7a769e917402598062a000a3a275fe2e1ff9309 (неужели в России вообще нет ветровых турбин????)

Наверное где-то и в других разделах есть.

Проверял я понятное дело не сайт МинЭнерго, а TinEye. Всё подыскивал под него какой-либо новый сайт где гарантированно контент был бы «новым».

Лично меня работа их алгоритма впечатлила – находятся даже изменённые изображения в разных форматах и размерах.

Такие дела.

На Амазоне вышла книжка Semantic Web for Dummies написанная Jeffry Pollock автором Adaptive Information (Адаптивная информация)  которая меня лично подвигла ко многим размышлениям на тему природы и свойств информации, равно как и её самоценности. Я лично пока полистал то что можно посмотреть в открытом доступе и, хотя книжка для «Dummies», интересного там должно быть много.

Кстати, Adaptive Information доступна и в книжках Google, хотя и не полностью, но достаточно для ознакомления.

Жаль в России книг по природе информации (не по алгоритмам или управлению знаниями), но именно по информации очень мало.

А эти книжки я лично добавил в свой список заказов на Amazon’е.

• Microsoft инциировали Open Government Data Initiative http://www.microsoft.com/industry/government/opengovdata/default.aspx где они собирают открытые данные, пока исключительно из США, на своей платформе. Инициатива интересная, жаль лишь что охватывает только GSA (General Services Administration) и Округ Колумбия.
• Data Catalog Distict of Columbia (http://data.octo.dc.gov/) открытые данные публикуемые округом Колумбия. Я упоминал их и и ранее и этот проект достоин внимания.
• Открытые данные сената штата New York - http://www.nysenate.gov/open-data

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

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

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

Спецификации

Итак, спецификация раскрытия данных, состоит из 3-х XSD схем:

• opendata.xsd (http:/schema.opengovdata.ru/0.1/opendata.xsd) - спецификация с полным описанием источника данных и структуры массива данных
• opendataxml.xsd (http://schema.opengovdata.ru/0.1/opendataxml.xsd) – XML спецификация табличных данных.
• opendataindex.xsd (http://schema.opengovdata.ru/0.1/opendataindex.xsd)  - спецификация файла индекса используемого для обнаружения спецификаций.

И, для каждой из схем, доступна автоматически созданная документация:

• opendata.xsd - http://schema.opengovdata.ru/0.1/docs/opendata/opendata.html
• opendataxml.xsd - http://schema.opengovdata.ru/0.1/docs/opendataxml/opendataxml.html
• opendataindex.xsd - http://schema.opengovdata.ru/0.1/docs/opendataindex/opendataindex.html

Процесс импорта и экспорта данных

Теперь подробнее о том как с этими спецификациями будет происходить работа.

Фактически, вариантов работы с информацией два:

1. Данные подготовленные и загруженные на сайт opengovdata.ru

2. Общедоступные данные публикуемые на внешних ресурсах.

Continue reading «OpenGovData. Спецификации раскрытия данных»

В Guardian, британской газете, анонсировали открытую онлайновую платформу через которую можно получить доступ к их материалам - http://www.guardian.co.uk/open-platform 

Посредством API они отдают данные и дают доступ в некоторые из своих медиа-массивов, с примерами доступа на Python, Ruby, PHP, Java. 

Фактически, что я лично наблюдаю, Guardian идёт тем же путём что и New York Times которые о своих API пишут уже давно http://open.blogs.nytimes.com/tag/api/

и Thompson Reuters которые поддерживают OpenCalais - http://www.opencalais.com/

Так же стоит отметить BBC API - http://www0.rdthdo.bbc.co.uk/services/api/  не столь интересное как остальные, но имеющееся как факт (появилось оно, кстати, в 2005 году, 3.5 года назад).

А вот наши новостные агенства с такими сервисами совершенно не спешат.