Самарский портал "Технологии, компьютеры"

О стремительном росте объёмов хранимых, передаваемых и обрабатываемых данных известно всем. Причём рост этот происходит во всех областях ИТ, благо, все устройства от смартфонов до суперкомпьютеров построены по единым принципам. Кстати, это тоже редкость в мире техники: как правило, функционально близкие устройства в разных весовых категориях построены на разных принципах. Не так уж много общего между бензиновым генератором и ГЭС или АЭС.

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

Но количественные показатели – это ещё полбеды. Если бы в каждом случае рос объём классической базы данных, построенной по всем правилам науки и приведённой ко всем нормальным формам по Кодду, то стояли бы задачи оптимизации построения индексов, сокращения количества итераций при навигации по индексам или что-то подобное. Часто Big Data определяется как три V – volume (объём хранимых и обрабатываемых данных), velocity (скорость передачи и обработки данных) и variety (разнообразие типов структурированных и неструктурированных данных).

На последнем термине я споткнулся: если никаким образом нельзя понять структуру хранимых данных, то и добыть их них значимую информацию невозможно. Пример – картинки CAPTCHA, из которых программа распознавания не может вычленить изображённые там символы. То есть, строго говоря, неструктурированные данные – это оксюморон, контент становится данными только после того, как система понимает его структуру.

Также в литературе часто встречается термин «полуструктурированные данные». Считаю его некорректным, ибо данные могут быть либо структурированными, либо нет, а вот чтобы ровно наполовину – так не бывает. Впрочем, если считать термин «неструктурированные данные», оксюмороном, то «структурированные данные» придётся назвать тавтологией.

Итак, первая задача Big Data – выделить из контента данные. Хочу рассмотреть это на понятном для всех ИТ-шников примере: системах поиска ИТ-товаров в магазинах. Как выглядят прайсы торговых точек все, конечно, представляют, однако для наглядности я приведу картинку из недавно презентованной программы оценки ИТ-навыков IT-Fitness. По соображениям неангажированности здесь опущены название производителя и модели, но в данном случае это не имеет значения.

Видно, что в первой модели опущены слова «встроенная графическая плата» и не указана предустановленная ОС (предупреждения об отсутствии ОС тоже нет!), во второй объём оперативной памяти указан в гигабайтах (у остальных в мегабайтах), в четвёртой модели оптический привод назван оптическим диском и т.д.

Создаваемая система поиска товаров должна обладать как минимум следующими качествами:

• Иметь собственную структуру и набор параметров устройств, которым может не соответствовать ни один из прайсов. Например, ещё в то время, когда ни продавцы, ни производители не определяли на своих ресурсах ультрабуки как отдельную категорию устройств, разработчики системы, зная об инициативах Intel, предусмотрительно принимают решение о возможности группирования и фильтрации ноутбуков по этому критерию. Понятно, что извлечь программным путём необходимые данные из прайсов и каталогов не получится – всё исключительно руками.
• Иметь не иерархическую (свойственную большинству прайсов), а реляционную структуру для того, чтобы одно и то же устройство можно было видеть в нескольких разделах прайса. В наше бурное время многофункциональности и неопределённости в классификациях (пока она стабилизируется, происходят новые изменения) зачастую целесообразно определить устройство сразу в несколько разделов – так быстрее найдут.
• Иметь фильтрацию по всем параметрам, которые могут заинтересовать покупателя. При этом некоторых параметров может не быть не только в прайсе продавца, но и в документации производителя. Члены сообщества наверное уже догадались, что в качестве примера я хочу привести Intel WiDi.
• После выбора модели предоставлять информацию о цене и продавцах. Для этого записи об изделии в прайсах требуется соотнести с выбранной пользователем моделью (каноническим именем модели по документации вендора). Сейчас с этим более-менее нормально, а ведь были времена, когда, к примеру, процессоры Intel вообще не имели торговых обозначений – только вот это: Intel® Celeron® processors at 2.40 GHz sSpec Number SL6VU.

Как же сделать такую систему, обрабатывающую информацию, находящуюся на различных независимых ресурсах?

Прежде всего, на основании своих знаний и экспертных оценок построить собственную структуру базы данных (приведённую ко всем нормальным формам по Кодду), в которую будет помещаться вся добытая из внешних источников и сгенерированная внутри системы информация. Разработать экранные формы для администраторов базы (операторов) и посетителей. Затем в поля области базы, отвечающей за выбор модели, вводятся все заранее определённые атрибуты модели: диагональ и интерфейсы для мониторов, модели процессоров для ноутбуков, количество портов для коммутаторов. Важный момент – обозначение модели. Бывает, что даже в разных местах официального сайта изготовителя она записана несколько по-разному, поэтому оператору и здесь придётся принимать собственное решение.

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

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

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

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