Как с помощью веб-скрапинг и Puppeteer проанализировать аукционы Christie’s, Sotheby’s и Phillips. Кейс от Lansoft

    Как Web Scraping помог собрать нам данные по официальным коллекциям как у Белгазпромбанка.

    Web Scraping — один из самых популярных методов считывания различных данных, расположенных на веб-страницах, для их систематизации и дальнейшего анализа. По сути, это можно назвать “парсингом сайтов”, где информация собирается и экспортируется более удобный для пользователя формат будь то таблица или API.

    Инструменты Web Scraping позволяют не только вручную, но и автоматически получать новые или обновленные данные для успешной реализации поставленных целей.

    Для чего используется Web Scraping?

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

    Команда Lansoft достаточно успешно освоила данный метод. Поэтому хотим поделиться с вами одним из кейсов по сбору данных для анализа датасэтов предметов искусства для нью-йоркской компании Pryph.

    Pryph анализируют знаменитые аукционные дома такие как Christie’s, Sotheby’s и Phillips и резюмируют выводы о популярности различных авторов.

    Кстати на этих аукционах были куплены несколько картин в нашумевшем деле Белгазпромбанка и Виктора Бабарико. По нашему мнению эти сделки никак нельзя назвать незаконными (ссылка news.tut.by/culture/349226.html)

    Для работы мы выбрали инструмент — Puppeteer. Это JavaScript библиотека для Node.js, которая управляет браузером Chrome без пользовательского интерфейса.

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

    На самом деле есть более оптимальные способы скрапинга сайтов средствами node.js
    (описаны тут — habr.com/ru/post/301426).

    Причины выбора Puppeteer в нашем случае были:

    • анализ всего 3 сайтов с понятными разделами и структурой;
    • активное продвижение данного инструмента компанией Google;
    • эмуляция работы реальных пользователя на UI без риска попасть в бан, как потенциальные DDOS атаки.

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

    Для примера мы вставили кусок кода, написанного на Puppeteer для извлечения ссылок картинок лотов с аукционного дома Phillips:

    image

    В подобном ключе команде Lansoft для каждого лота нужно было найти имя автора, описание работы, цену, детали о продаже и ссылку на предметы искусства.

    image

    Примеры ссылок на лоты:

    www.phillips.com/detail/takashi-murakami/HK010120/110

    www.sothebys.com/en/buy/auction/2020/contemporary-art-evening-auction/lynette-yiadom-boayke-cloister?locale=en

    Например, на картинке выше мы видим имя автора TAKASHI MURAKAMI, название картины “Blue Flower Painting B” и данные по цене в $231,000-359,000. Все необходимые поля мы собирали и записывали в csv файлы, разбитые по годам.

    Выглядело это так:

    image

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

    Результаты работы можно найти на сайте pryph.org/insights

    Но в работе с Puppeteer есть некоторые нюансы:

    1. некоторые ресурсы могут блокировать доступ при обнаружении непонятной активности;
    2. эффективность Puppeteer не высока, ее можно повысить за счет троттлинга анимации, ограничения сетевых вызовов и т. д.;
    3. необходимо завершать сеанс, используя экземпляр браузера;
    4. контекст страницы/браузера отличается от контекста ноды, в которой работает приложение;
    5. использовать браузер, даже в Headless режиме не так эффективно и быстро по времени для больших анализов данных.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 45

      0

      А скажите, с помощью папетира получается хорошо прикидываться настоящим человеком с браузером? Ну там user agent правильный выдаётся и прочее?

        0
        User agent можно указать любой желаемый.
          0
          да, имитация браузера, только в Headless режиме
            0

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

            0

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

              0

              Интересно. А на что намекаете? Что надо обычный браузер и через chromedriver управлять/использовать расширения? Или что расковырять апи, и прямымм запросами к данным по хардкору? Или ещё что-то?

                0

                Может в комментарии ошибка? Не наибольшего, а как раз наименьшего сопротивления? Современные страницы активно JS используют и построить парсер на базе headless выходит дешево по скорости реализации и последующего поддержвания, но дорого по скорости работы и потребляемым ресурсам.

                  0
                  Так и не понял где тут у них путь наибольшего соправтивления. Можешь расскрыть?
                    0

                    В плане простоты исполнения — наименьшее. В плане ресурсоемкости и скорости работы — наибольшее. Но как уже отписал ниже автор поста существующее решение покрыло его потребности

                    0
                    можно я вместо bungu отвечу?:
                    algotrader2013 проще вообще без браузера. любой ЯП, провильные заголовки + прокси — это то, чего хватит в 99%
                    alekciy, Kubig всё правильно написано. если страница на JS, то проще json расковырять, чем браузеры городить
                      0

                      Не все сайты работают через получение JSON данных с бека по AJAX. При этом очень часто на эти endpoint ставят разного рода проверки которые требуют передачи разного рода токенов которые создаются в рантайме в процессе работы JS. И тут как раз связка webdriver + XPath с исполнением через headless дает очень быстрый результат в плане запуска парсинга. И не нужно ни какой json при это расковыривать. Но цена за короткое время запуска работы парсера — высокие накладные расходы в виде браузера. А уже потом, когда ясно, что нужна либо быстрая скорость обхода либо экономия ресурсов, уже потом можно и в json поковыряться. Вплоть до того, что исполнять JS источника в VM (SpiderMonkey/V8), получать токены и слать запросы уже через curl.

                        0
                        я с вами полностью согласен — иногда приходиться заморачиваться. но в большинстве случаев можно обойтись просто python/requests :)
                        0
                        А json'ы откуда беруться?
                          0

                          Если сайт сделан с поддержкой RESTApi то приходящие/уходящие запросы можно просто посмотреть через панель разработчика в Chrome. В противном случае необходимо парсить непосредственно html код через XPATH или CSS-селекторы

                            0
                            А много таких сайтов (субъективно)? Я просто не особо на это внимание обращал.
                              0

                              Хватает. Да и есть явная тенденция с усилением защиты.

                        +1
                        Совершенно согласен. Даже в самой статье было упоминание, что в масштабном и постоянном использовании лучше пойти другими способами и инструментами. Но для нас Puppeteer как раз и был Наименьшим сопротивлением.
                        Ведь тут была разовая задача. И скорость выполнения и потребление ресурсов были небольшие. По сути это поднять один экземпляр браузера и в течении нескольких часов просмотреть все страницы за год. Даже при нескольких экземплярах браузера это не будет «атакой»
                          –1

                          Наименьшее сопротивление, в таком случае, бангладешец за 100 баксов. Соберет все руками за месяц. Скорость выполнения и потребление ресурсов соответствующие. И даже при нескольких экземплярах не будет атаки. Ждем статью.

                            0
                            Хотел бы я посмотреть как бангладешец за 100 уе собирает файлы по 6к-10к строк :) И причем далеко не одну штуку и далеко не с одной колонкой)) Жду референса на подобного экземпляра!
                        0
                        эмуляция работы реальных пользователя на UI без риска попасть в бан, как потенциальные DDOS атаки

                        Не вводите в заблуждение. Бан, UI и DDoS тут совершенно не связаны между собой. Бан можно получить при парсинге на любой клиенте (curl/guzzle/headless) и это зависит от схемы противодействия на ресурсе-источнике. Можно и при использовании клиента-парсера с UI попасть в бан если на источнике отслеживают движение мыши, а вы у себя этого не предусмотрели.


                        А DDoS предполагает парсинг с большого количества хостов. При этом в целом какой при этом клиент-парсер (GUI / CLI) не важно.


                        Так же не понятно, за счет чего повышается эффективность парсинга через Puppeteer при ограничении сетевых вызовов. В смысле, не грузить картинки? Но тогда стоило бы указать, каким образом это делается.

                          0
                          Согласен. Тоже не совсем понял причём тут DDoS. Можно притвориться браузером и скачивать страничку за страничкой, а можно так же притвориться браузером, скачивать страничку за страничкой в 100500 потоков и тогда конечно риск что сервер выдаст бан возрастает.
                            0
                            Интересно как запустить puppeteer в 100500 потоков) У нас было куча проектов с использованием Selenium ( что в целом весьма подобное решение как Puppeteer ) и вот даже 50 потоков, ну это прям супер крутая и долгосрочная автоматизация с очень серьезной инфраструктурой.
                            Но замечание дельное, как я понимаю смысл один и тот же. И с браузером и без браузера можно попасть в бан. Просто без браузера делать много потоков значительно проще и в разы менее ресурсозатратно, поэтому риск попасть в бан в разы повышается
                              0
                              На что вообще надо обращать внимание кроме UA и таймаутов, прикидываясь человеком?
                                0

                                Мышь. Поведенческие факторы.

                                0
                                Интересно как запустить puppeteer в 100500 потоков)

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

                                  0
                                  Солидный такой кластер. Не знаю делал ли кто либо до этого подобные вещи
                                    0

                                    За puppeteer не скажу. Я когда активно пилил парсеры его по сути небыло. Но вот на базе PhantomJS делал кластер и в принципе это не очень сложно. Просто через cli запускаешь пачку PhantomJS с прослушкой каждый на своем порту по webdriver протоколу. Проблема возникла ровно одна — он не мог слушать на заданном IP и запускался небезопасно, чем тут же пользовались взломщики. Поэтому вопрос решался на уровне iptables.

                                      0
                                      а какой был порядок цифр инстансов PhantomJs браузера в кластере?
                                        0

                                        Что-то около 50, но то было ограничение по железу. Схема легко масштабирцуется на порядки. При расчете за исходные данные берем, что один инстанс ~500-700 Мб резидентной ОЗУ с пиком до 1Гб, потекщие инстансы тушим при 2Гб ОЗУ, время на полную обработку одного запроса на парсинг 5-60 секунд.
                                        Да, что еще вспомнил. При запуске можно указать, какой прокси использовать. Поэтому в системе был автоматический перезапуск инстанса прокси которого забанили (управлять выбором используемой прокси по webdriver не удалось, поэтому фиксировалось статически в момент запуска).

                                  0
                                  Я с puppeteer не работал, только читал. Но первое что приходит в голову, это просто докеры.
                              0
                              Полноценный парсинг больших ресурсов возможен при использовании распределенных прокси на тысячи — миллионы уникальных ip-адресов. Хорошо себя зарекомендовал израильский Luminati.
                                0
                                Он хорош, но ну очень уж он дорог. Знакомый из фирмы, которая парсит на заказ в промышленных масштабах, говорил, что у них есть большая красная кнопка, при которой траф перенаправляется через Luminati (ее жмут, когда побанили все, что можно, и надо спасать жопу, ведь можно лишиться контракта с клиентом, ибо себестоимость парсинга в таком случае выходит дороже конечной стоимости услуг).

                                Также как-то я сам просчитывал стоимость одного проекта с парсингом динамического контента в реальном времени. И выходило, что со стоимостью в $10/GB+ это тоже убивало всю экономику.

                                Может, разве что, если исключительно прямыми АПИ запросами кидать, то может быть выгодно, — хз
                                  0
                                  А какие есть аналоги Luminati?
                                    0

                                    А чем хорош? Чем он так отличается/выделяется от прочих площадок продающих прокси?

                                      0
                                      Не знаю, как сейчас, а года 3 назад прикол был в том, что много хомячков поставило себе бесплатное расширение Hola. Прям ну очень много хомячков. И они давали возможность через них ходить в инет. Поэтому, прикол был в том, что можно ходить через ip адреса реальных людей. Конкуренты, в основном, продавали датацентровые прокси, которые условным максмайндом палятся.

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

                                        Есть такие, называются — сюрприз — Люминати.


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

                                          0

                                          Это то, что они называют DCA?

                                      0

                                      Люминаты раздают шаред-прокси по 50 центов за гигабайт. Дальше — умение их готовить. Современные WAFы это давно уже не "у вас подозрительный ASIN, давайте играть в рекапчу". То есть такое тоже есть, конечно, но от этого отходят, потому что тупо.

                                        0

                                        Пардон, не ASIN, а ASN конечно, с амазоном переигрался.

                                          0
                                          "у вас подозрительный ASN"

                                          Хорошая фича для любого ML, разве нет?

                                      0
                                      Скрейпинг — давняя тема, и сам даже занимался ей когда-то, и заказов на апворке на эту тему немало видел. А как обстоят дела с анти-скрейпингом? Каждый сайт/приложение свой колхоз городит или есть какие-то популярные решения против скрейпинга?
                                        0

                                        Ну можно колхозить на уровне Яндекс.Метрики и Гугл.Анаталитикс подобно этому: Как мы отфильтровали ботов и понизили показатель отказов с 90% до 42%. Срабатывает в любом проекте.

                                          0
                                          А нет каких-то готовых решений для анти-скрейпинга? Просто странно в век автоматизации, что каждый сам себе велосипед изобретает и одинаковые шишки набивает.
                                            0

                                            Есть. API называется. В последние годы, вижу, что многие стали лучше осознавать, что парсинг не остановить и это процесс который обходится для авторов парсера очень дешево. Сильно дешевле, чем оборонные меры. Поэтому приходилось слышать от коллег, что сайт источник задетектив бота подсовываем ему большую надпись "у нас есть API, оно тут!" и просьбу для получения данных использовать его. Но все истории пока про запад.

                                              0
                                              Datadome

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое