В эпоху больших данных и машинного обучения все большую значимость приобретают методы сбора данных. Сегодня я хочу поговорить про один из них – парсинг.
Парсинг, происходит от английского глагола “to parse” - проводить грамматический разбор предложения и описывать синтаксические роли частей. В программировании парсить значит автоматизировать сбор данных из разных источников, обрабатывать их и собирать в общей базе данных.
С помощью парсинга можно провести глубокий анализ аудитории, которая посещает сайт, проанализировать конкурентов, собрать любые данные, необходимые для вашей эффективной работы. Например, в сфере недвижимости, чтобы правильно оценить тот или иной объект важно собрать данные по аналогичным помещениям, чтобы с их помощью отслеживать динамику цен по рынку, или в сфере продаж, для сбора списка цен и наименований товара.
Когда у нас стали появляться задачи по парсингу, у нас было несколько путей. Можно было искать фрилансеров, спросить у знакомых, но мы решили вырастить грамотного мастера в составе свой команды. И ни разу не разочаровались в этом решении.
В этой статье мы выделим ряд проблем, с которыми мы встречались при работе над парсингом сайтов и которые являются довольно типичными, рассмотрим их и расскажем, как мы их решали.
И проблема, с которой мы начнем обсуждение, это целостность данных.
1) Целостность данных.
Первичный ключ.
Самая типичная ошибка, с которой может встретиться новичок в парсинге, это проблемы с целостностью данных. Под этим обычно понимают следующие две вещи. Целостность данных с точки зрения сущности заключается в том, что любое отношение должно обладать первичным ключом, то есть для каждого объекта существует свой собственный уникальный номер.
CASE 1:
В начале нашей работы в FinCase, мне и моему коллеге была дана задача сложной обработки данных для последующего использования в каком-то аналитическом алгоритме. Мы несколько дней занимались очисткой данных и приведением к некому общему виду, подходящему для последующей работы. Мы были очень рады, когда наконец закончили, до тех пор, пока не пришло время залить эти данные в базу. Внезапно оказалось, что в процессе обработки мы умудрились потерять id записей. И хотя мы и потратили еще немало времени, прописывая обратные действия для восстановления id, эта история научила нас очень важной вещи:
ВСЕГДА сохраняй первичный ключ записи.
Тип данных.
Вторая важная вещь: при считывании данных были получены необходимые данные и они помещены в соответствующие поля отдельной записи.
CASE 2:
Однажды, когда мы работали с данными по недвижимости и пытались закладывать какие-то логические модели в них, мы столкнулись с тем, что записи были часто сильно смещены. Странно было то, что смещения были совершенно различны по количеству ячеек и в принципе, не подчинялись какой-то очевидной логике. Например, ближайшее метро могло прийти в поле про этажность здания или год постройки. Самые глубокие смещения были вообще на 6-7 ячеек. Мало того, что данные не приходили на свое место и их нельзя было адекватно учесть, так они еще и влияли на наши алгоритмы, которые, например, не ждали слово на месте цифр. Мы обратились к парсеру и в какой-то момент обнаружили ошибку. Дело было в том, что в тексте описания, которое выкачивалось вместе со всеми данными часто приходили разделители “\t”, которые мы использовали при обработке перед тем, как залить в базу данных. Мы сделали для себя на будущее два вывода:
Проверяй тип данных приходящих в конкретное поле и не забывай проверять данные на специальные значения.
2) Плохая заполненность
Еще одна типичная история связана с недостаточной заполненностью данных. Нередко бывает, что при выгрузке данных вдруг оказывается, что половина необходимых полей заполнена кое-как, и этого недостаточно для адекватной работы.
CASE 3:
Работая с базой объявлений по недвижимости, мы столкнулись с очень плохой заполненностью по году постройки и этажности зданий. Этажность была заполнена едва ли у трети объявлений, а год еще меньше. Устроив мозговой штурм и посидев над задачей с отделом дата сайенса, мы пришли к следующим двум идеям. Во-первых, мы решили набрать данные на сайтах посвященных просто домам, не связанных с объявлениями. Во-вторых, мы решили пересечь данные сами с собой, в надежде на то, что часть объявлений будет дана по одинаковым адресам. В результате, именно второй ход привел нас к успеху, и даже по году было заполнено около 78%.
Мы решили, что в этой истории важно:
Используй разные источники информации и объединяй данные из них.
3) Актуальность данных.
Также важно следить, чтобы данные не устаревали. Нередко складывается ситуация, что база данных большая, но построить адекватный прогноз или анализ по ней не выходит. Зачастую, вопрос именно в устаревших данных.
CASE 4:
В какой-то момент, мы захотели сделать некий анализ происходящего на основе большой базы данных, которая у нас копилась долгое время. Данных действительно было много, у нас получилась большая выборка и этого вполне хватало для анализа. Но неожиданно, анализ плохо подтверждался действительностью. Мы просматривали алгоритм, искали ошибки в логике, но не могли понять в чем дело, пока кто-то не предположил, что дело в нерелевантных данных. И действительно, когда мы проверили, оказалось, что миллионы записей уже устарели, а поток который предоставляет парсер, слишком мал для оценки. Когда мы исправили парсер, ситуация улучшилась, а мы теперь всегда пользуемся следующим правилом:
Следи за актуальностью данных.
4) Защита от роботов.
Что такое капча знает практически любой современный человек. Сайты, а нередко и сами браузеры следят за действиями пользователей в попытках отделить реальный трафик от автоматического. В этом разделе мы рассмотрим какие-то решения, которые могут помочь для автоматизации процессов.
CASE 5:
В одном из проектов, нам нужно было написать небольшого робота в помощь администраторам группы в одной известной социальной сети. Но когда мы брались за это, мы и представить себе не могли, насколько жестко контролируется работа роботов в ней. Сперва нам стали предлагать пройти различные проверки, а потом и вовсе заблокировали аккаунт. А когда кто-то из нас попытался выйти с рабочего аккаунта из другой страны, доступ опять был заблокирован до выяснения обстоятельств. Самое забавное в этой истории было то, что никто от этого не проигрывал, робот был призван осуществлять часть работы модераторов и принимать заявки на вступление в группу, если человек соответствовал определенным условиям. Покумекав с этой историей некоторое время, мы поняли, что есть несколько важных вещей, на которые смотрит сайт при взаимодействии с ним.
Сервера.
Неожиданным для нас ходом оказалось, что линуксовые юзеры по умолчанию имеют меньше доверия. Связано это, скорее всего, с тем, что сервера под линуксом дешевле чем виндоус или мак, соответственно, логично, что если некий робот и будет использовать сайт, то он будет использовать именно линукс. Соответственно, разумно будет запускать сервера с других ОС или поставить себе расширение браузера, которое подменяем для сайта данные о системе, например UserAgent Switcher.
Антитрекинг.
В попытках понять, почему нас продолжают блокировать, мы узнали, что почти все сайты используют трекеры для отслеживания сессий пользователей. Даже на странице авторизации на пользователя вешалось штук пять трекеров, которые следили за всеми действиями. Здесь может помочь антитрекинг, например, в хроме есть расширения Ghostery и Privacy Badger.
VPN.
Поскольку наши заказчики работали не в России, то, чтобы избавиться от геопривязок и блокировке из-за несоответствия региону мы воспользовались VPN. В нашем случае применялось Hola VPN.
В конечном итоге, наш проект увенчался успехом, оставив нас со следующими выводами по работе с защитой от роботов:
Покажи сайту, что используемая ОС не линукс.
При возможности, избавься от трекеров. Используй VPN.
Смена IP.
И последняя история на сегодня, связана с сменой ip.
CASE 6:
Была ситуация, когда нам потребовалось срочно выгрузить большой объем данных с сайта. Мы написали парсер, но вот беда, у него стояло ограничение по времени и при превышении количества запросов в секунду он блокировал доступ. Мы пробовали выгружать с разных компьютеров, но у нас была одна локальная ip, и сайту этого было достаточно. У нас не было времени выкачивать все постепенно, но мы нашли решение. Мы взяли набор из нескольких десятков vpn и стали заходить с них по очереди. Все vpn имели разные ip, и в результате скорость выгрузки каждого ip была в десятки раз меньше.
Сменяя ip, можно обойти запрос на количество запросов в промежуток времени.
Заключение.
В заключение, хочу отметить, что автоматизация процессов очень полезна и позволяет высвободить множество человеческих ресурсов. Каждый раз делая робота для парсинга или просто автоматическим запросом, вы сберегаете кому-то множество часов, а то и дней жизни. Пишите код и автоматизируйте правильно!
Дмитрий Цыплаков, CEO/ Product Manager компании Fincase - лидера PropTech сектора в России.