Создание парсера интернет магазинов

Я примерно представляю, сколько это кодить, при условии если магазины сопротивляются парсингу. Эта распространенная вообще-то ситуация, и магазины постоянно парсят друг-друга для целей автоматического мониторинга цен. Ну и естественно сопротивляются тому, чтобы их парсили конкуренты. Вот сколько трудозатрат программистов в таком случае - я представляю. И все равно эта задача решаема на практике. А сколько если не сопротивляются - я себе не так четко представляю. Но по сравнению с предыдущим вариантом - "очень-очень мало".

---------- Добавлено 11.06.2018 в 08:25 ----------

P.S. И мне реально кажется что вы напрасно сфокусировались именно на парсинге. Главный вопрос "что потом"? Например, если у вас там есть задача, "найти все магазины в которых есть товар A" - то вот это уже очень сложно.

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

---------- Добавлено 11.06.2018 в 10:48 ----------

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

---------- Добавлено 11.06.2018 в 11:07 ----------

Вот примерно то, что вы описали и есть этот парсер. и наполнение идет ежедневно годами. Только человек, который наполняет не думаю, что больше 30 000 руб. получает. Ему разработали все и он уже мелкие задачи решает.

Мне именно разработка интересна. Потом я сам добавляльщика за указанную сумму и найду. Но разработка должна быть грамотной. Мало того что хорошо все делаться должно, еще и "добавляльщик" должен быть за 30 тыс, а не за 300. Так как если добавлять сможет только сам разработчик, то он плохой разработчик.

vl12, я думаю, что подробной

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

Представьте, что нужные вам данные в HTML коде источника вообще могут быть НИКАК не размечены, эти данные могут присутствовать в десятках разных вариантах написания, могут быть написаны с ошибками и опечатками. Вычленять такие данные - весьма нетривиальная задача, доступная лишь спецу высокого уровня.

Короче, если вы реально затеяли что-то замутить с такими парсерами, советую:

1) Подумать, надо ли оно вам? Ибо скорей всего всё будет не так просто, как кажется.

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

3) Исходя из п.1 и п.2 максимально всё упрощайте, все сложные/неоднозначные варианты смело исключайте, и пишите четкое детальное ТЗ.

----

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

в отрыве от всего контекста, а как отсутствие класса или id у элемента(не размечен) или его родителя может помешать его парсингу? по дереву можно дойти до элемента нужного даже в том случае, если в элементах вообще нет ни одного тега и класса в принципе, хотя такого не бывает, даже если элемент сам не имеет классов/айди, имеют его родители, да и вообще xPath есть

по теме. ок, что-то парсит, создать универсальный пасрер тоже нет проблем, каждый новый сайт можно добавлять путем простого добавления xPath/css/id нужных элементов.

Допустим есть пасрер который забирает title, desc, price, img , создавая настройки с нужными данными(пути до нужных элементов) этот парсер спокойно расширяется, добавление 1-го сайта занимает минимум времени и делается даже не программистом а просто человеком который сможет определить xPath тот же у элементов через вебмастер консоль браузера.

я создавал парсеры, которые парсят N сайтов, каждый новый сайт добавлялся грубо говоря за 30 мин. Первое это стартовый урл для обхода, там где паджтнация ставил {N} , то есть если обходить нужно так http://site.com/page=1,2,3, в настройки пишем http://site.com/page={n}, лимит страниц, шаблон ссылки на страницу, и шаблоны для вычленение нужных данных, типа //*[@id="fo_boardpanel"]/table/tbody/tr[1]/td[1]/img и все в принципе, энергозатраты на добавление поддержки нового сайта минимальны, ученность особая не нужна

ТС интуитивно чувствует что ничего сверсложного и правильно делает, не надо его разводить и кошмарить суммами в 100к usd

Как вы дойдете до нужного элемента с помощью xPath, если у элемента нет никакой тэговой разметки? Например, есть несколько абзацев, размеченных не тэгами <p>, а разделенных двумя <br>, да пусть и тэгами <p> (голыми) - без разницы. И вам надо вычленить из текста имена людей, которые могут быть записаны в любом формате, и по контексту установить связи между ними. Или пример проще: в неразмеченной простыне текста вычленить брэндовые товары и цены и связать их однозначно друг с другом. Никакой xPath вам не поможет.

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

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

НУ, сами то вы за сколько бы взялись за разработку системы парсинга (которой мог бы управлять "чайник") из десятков тысяч произвольных источников? И сколько бы взяли за ее поддержку?

---------- Добавлено 11.06.2018 в 12:36 ----------

И еще момент. Просто скриптом парсить не получится. На каждый урл будет уходить по 2-5 секунд. А в магазинах обычтно страниц много - тысячи, десятки и сотни тысяч. Да и самих сайтов десятки тысяч. Так что простой скрипт - это не вариант. Необходимо разделить процессы загрузки и обработки, а также в обязательном порядке их распараллелить - в рамках одной машины и в рамках кластера машин. Также система должна быть устойчивой к обрывам соединений и пр. Эти моменты сильно усложнят систему. На ПХП я бы такое точно не писал, скорее на питоне. Да, на первый взгляд все выглядит просто, но в реальности...

во первых, источники не произвольные, они более-менее унифицированы, это интернет магазины, у 99% структура одна /category/subcategory/itempage, у 99% нужные элементы(title,price,desc,img) будут обрамлены тегами. "проанализировать структуру данных и разметку источника" - это что, сложно? я за 5 мин вычленю все нужные xpath со страницы, никакой сверхмагии тут нет. я бы ни за сколько не взялся, мне такое не особо интересно, а вообще, 5-10к usd вполне реальный бюджет, и ТС может найти исполнителя/команду за такую сумму

---------- Добавлено 11.06.2018 в 12:44 ----------

что это за бред? ты хоть один парсер писал на практике? на каждый урл по 2-5 секунд? 🤣 хочешь подарю парсер votpusk , запустишь и посмотришь сколько времени уходит на парсинг ВСЕХ статей ( 10к+ ) 😎

в остальном, зачем писать очевидные вещи? ясно что парсить 10к сайтов не 1им скриптиком, а как минимум армией воркеров которые из очереди задания берут.

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

А как сделать сложно и дорого, думаю все знают. Студий много, которые помогут легко освоить любой бюджет.

А теперь умножьте это время на 5000 сайтов в примере и оцените свою работу пожалуйста, чтобы уже закрыть эту нелепую тему 🍿

Прям тянет меня сюда что-то, непонятно почему )))...

Тоже думаю примерно о такой сумме.

Но пока смотрю:

1. можно ли сильно дешевле

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

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

---------- Добавлено 11.06.2018 в 13:58 ----------

Очень легко. зарплата добавляльщика 30 тыс в месяц. 1500 в день Чуть меньше сотки за сайт выйдет. Чего сложного?

Если вы не понимаете откуда идет финансирование добавления и т.п., это не значит, что тема нелепая. Нелепые тут в основном ответы. Хотя на всех форумах одно и тоже, из 10 ответов 1 в тему, это форумы.