Сбор данных из разных источников. Методы сбора и обработки данных

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

Основные сложности здесь заключаются в следующем:

• Откуда взять данные (не всегда есть возможность получить доступ к хорошим данным через API).
• Как связать разнородные источники в единую систему данных.

В этой статье мы разберем как собрать информацию из разных источников, и что с ней дальше делать.

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

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

Через программный интерфейс вы получаете данные и начинаете с ними работать в своей информационной системе. API может быть бесплатным, может быть платным. На API также могут быть наложены некоторые лимиты по использованию (квоты).

Как выяснить есть ли API у источника данных? Идем на их сайт или в поисковик и ищем по ключевым словам "API, интеграция".

У вас могут быть некоторые выгрузки, которые вы где-то получили, и их можно залить в свою систему для дальнейшей обработки. Например, можно брать выгрузки из некоторых платных сервисов типа https://export-base.ru/ (платные базы предприятий).

Файл должен иметь строго определенный формат, который затем можно обработать. Не подойдут файлы PDF в неформатированном виде.

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

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

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

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

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

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

Нужно очень хорошо замотивировать поставщика данных, чтобы он потратил время в вашем личном кабинете.

Допустим, нашли мы источники, получили доступ к нужным данным, что с ними дальше делать? Их нужно сохранить где-то у себя в первичном виде для последующей обработки.

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

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

Зачем нужны промежуточные таблицы? Почему бы не сохранить все сразу в бизнес-таблицы?

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

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

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

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

• храним все сущности и все их поля (как отдельная таблица примерно с такой структурой id, prop, value, itemID).
• учитываем сессию загрузки, дату и какой был источник (сайт-донор или файл).

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

Таблицы должны быть оптимизированы, иметь все необходимые внешние ключи, а также иметь правильно настроенные индексы.

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

Что важно в бизнес-таблицах? Иметь максимально возможную структурированную информацию. Не просто название, описание и картинка, а множество параметров. Чем больше параметров есть, тем больше фильтров можно реализовать на поиске.

Как мы можем дальше использовать полученные данные?

Можно создать некий публичный каталог для поиска подходящих объектов. Пример - Cian.ru или Яндекс Маркет, где собирается множество предложений по недвижимости или товарам от разных поставщиков.

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

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

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

Здесь невозможно создать одну большую кнопку, по нажатию которой данные обрабатывались бы из любых источников. Под каждый источник необходимо делать либо свою обработку (затраты на программистов), либо приводить данные из источника к единому формату (затраты на ручной труд множества операторов).

Если вы планируете создавать подобную систему, то начните с этого:

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

Источник: