Що таке Web Crawling та Web Scraping

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Я впевнений що у кожного питали про його експіріенси в роботі, про цікаві проєкти, нестандартні кейси і т.п., і здебільшого вдається пояснити у декількох реченнях, що і до чого. Але варто згадати Web Crawling чи Web Scraping, як одразу з’являються питання: «А що це взагалі? Як воно працює? Навіщо це потрібно?». Тому я вирішив пояснити простими словами. Сподіваюся, це стане в пригоді тим, хто хоче в цьому розібратися.

Що таке Web Data Mining — це автоматичний збір інформації з веб-сайтів. Уявіть собі робота, який «ходить» по сайтах за посиланнями, переглядає сторінки та зберігає потрібні дані, наприклад, текст, зображення чи ціни товарів. Мета полягає в тому, щоб проаналізувати та видобути дані з цих ресурсів, щоб виявити приховані закономірності, тенденції та зв’язки, які можуть надати цінну бізнес-аналітику або підтримувати процеси прийняття рішень.

Виглядає просто, правда? Але в цьому є купа нюансів. Давайте розберемося, навіщо це взагалі потрібно.

Навіщо це?

  1. Аналіз конкурентів
  2. Уявіть, що ви власник інтернет-магазину. Хочете знати, які ціни на товари у ваших конкурентів, як часто вони оновлюють асортимент, чи є у них акції. Робот швидко збере ці дані, і вам не потрібно вручну перевіряти кожну сторінку.
  3. Моніторинг ринку
  4. Це вже про бізнес у ширшому сенсі. Наприклад, можна відстежувати, як змінюються тренди, що популярне зараз, і на основі цього приймати рішення.
  5. Збирання даних для досліджень
  6. Для аналітики, статистики чи навіть створення моделей штучного інтелекту часто потрібна велика кількість даних. І тут Web Scraping — просто знахідка.
  7. Автоматизація рутини
  8. Хочете зберігати останні новини з улюблених сайтів або автоматично отримувати дані про погоду? Робот все зробить за вас.

Різниця між Web Crawling та Web Scraping

У більш досвідчених розробників може виникнути питання, яка різниця між Web Crawling та Web Scraping та яке воно має відношення до Web Data Mining, тож ми це трохи розберемо.

Web Crawling і Web Scraping є частиною ширшої концепції, яка називається Web Data Mining:

  • Web Data Mining — це процес отримання корисної інформації з веб-даних (текстів, структур, поведінки користувачів тощо).
  • Web Crawling і Web Scraping — це інструменти, які допомагають отримати ці дані з веб-сайтів для подальшого аналізу.

Crawler — збирає URL-адреси, аналізує їх, та зберігає у БД.

image

Scraper — витягує конкретні дані зі сторінок, аналізує їх, та зберігає у БД.

image

Чи можна сказати що Scraping є невід’ємною частиною Crawling?

Це не зовсім так. Web Scraping і Web Crawling тісно пов’язані, але один не завжди є частиною іншого.

  • Web Crawling може виконуватись без Scraping. Наприклад, бот переглядає сайти, але не збирає конкретні дані, лише індексує сторінки, збирає URLs, тощо.
  • Web Scraping на кожній сторінці витягуємо конкретну інформацію, наприклад, ціну або опис продукту, але часто потребує допомогу Crawling. Щоб зібрати дані з багатьох сторінок, потрібно спочатку «пройтися» по всіх посиланнях (це і є Crawling).

Отже, Scraping можна назвати частиною Crawling лише тоді, коли потрібно обробляти сторінки під час їх перегляду. Але Crawling сам по собі може існувати без Scraping. Так само и навпаки, Scraping може працювати самостійно.

Чи законно це в Україні, США або країнах ЕС?

Легальність збору даних з веб ресурсів залежить від дотримання правил конкретного сайту (наприклад, robots.txt — developers.google.com/...​ing-indexing/robots/intro) та законодавства країни, у якій ви знаходитеся. Тут я не буду давати якісь поради чи казати як треба робити або не треба, додам загальну інформацію по основним напрямкам:

1. В Україні законодавство прямо не регулює збір даних з веб ресурсів, що означає, що ця практика не заборонена. Проте є кілька важливих аспектів:

  • Повага до авторських прав.
  • Захист персональних даних: Дані, що містять особисту інформацію, підпадають під дію Закону України «Про захист персональних даних». Забір та використання таких даних без дозволу може порушувати закон.
  • robots.txt: Хоча файл robots.txt юридично не обов’язковий, його ігнорування може бути визнане недобросовісною практикою.

2. У США збір даних з веб ресурсів загалом вважається легальним, але існують нюанси:

  • Відомий випадок LinkedIn проти hiQ Labs: Суд дозволив hiQ Labs використовувати публічні дані LinkedIn для аналітики, оскільки ці дані були відкритими. Проте це рішення було предметом тривалих юридичних спорів. Посилання для ознайомлення — www.linkedin.com/...​q-labs-naman-gupta-5ypff.
  • Авторське право.
  • CFAA (Computer Fraud and Abuse Act): Порушення технічних заходів захисту (наприклад, обходження CAPTCHA) може розглядатися як нелегальний доступ до системи.

3. У ЄС діють суворі правила щодо захисту персональних даних:

  • GDPR (Загальний регламент захисту даних): Якщо web scraping включає збір особистих даних, це може порушувати GDPR.
  • Авторські права.
  • robots.txt чи застосування агресивного scraping.

Власний досвід

Які були мої перші враження?

Я був вражений. Здебільшого тому, що на той час був ще не надто досвідченим розробником. Але ще більше вразив сам масштаб автоматизованої системи для збору, обробки, аналізу та зберігання даних. Це була майже монолітна архітектура, яку напевно, краще було б реалізувати щось схоже на мікросервісну структуру. Проте навколо цієї ідеї точилися гарячі дискусії, адже підтримка такої «махіни» була справжнім викликом.

Більшу частину часу займав сапорт запущених скреперів, і це зовсім не перебільшення. Власники вебзастосунків вкладають величезні зусилля в захист своїх продуктів, і працювати з цим захистом це ще там задача.

Якби я зараз швидкоруч змалював архітектуру такої системи, вона виглядала б приблизно так:

image

Що варто знати новачкам?

Якщо ви тільки починаєте працювати у цій сфері, є кілька базових правил, які точно треба тримати в голові:

  • Не займайтесь DDoS. Це навіть не обговорюється.
  • Імітуйте поведінку звичайного користувача. Попрацюйте з http request, додавайте паузи між запитами, поводьтеся «людяно».
  • Використовуйте проксі. На щастя, знайти Free Proxy не так уже й складно. Якщо ж сайт блокує навіть це, завжди є варіант через Tor.
  • Автоматизуйте процес. Від запуску скреперів до вирішення задач з захисту — усе це має працювати без вашого втручання.

Доступ до даних — це завжди виклик, і кожен сайт має свої нюанси. Один із найцікавіших випадків у моїй практиці — це знайомство з Browser Fingerprint. На той момент я ще нічого про нього не знав, тож довелося витратити чимало часу, щоб зрозуміти, як це працює, обійти цей блокер і ще й автоматизувати рішення. Дуже рекомендую ознайомитися з цією темою як розробникам вебзастосунків, так і тим, хто займається збором даних.

Інструменти парсингу даних

Пам’ятаю, як колега розповідав, що колись вони парсили сторінки Regex. То був якийсь жах!) Я не кажу, що XPath — це панацея, але виглядає значно більш адекватно й універсально:

  var url = "https://example.com/sample.xml"; 
  // Step 1: Get XML content from the URL
  string xmlContent = GetXmlFromUrl(url);
  // Step 2: Load XML content into an XmlDocument
  XmlDocument xmlDoc = new XmlDocument();
  xmlDoc.LoadXml(xmlContent);
  // Step 3: Use XPath to select nodes or values
  XmlNodeList items = xmlDoc.SelectNodes("//item");
  foreach (XmlNode item in items)
  {
     // Example: Retrieve specific values from child nodes
     var title = item.SelectSingleNode("title")?.InnerText ?? empty.String;
     var author = item.SelectSingleNode("author")?.InnerText ?? empty.String";
  }

Якщо казати про JPath, то це більш зручний спосіб витягнути дані:

   var url = "https://example.com/sample.json";
   // Step 1: Get JSON content from the URL
   string jsonContent = GetJsonFromUrl(url);
   // Step 2: Parse JSON content
   JObject jsonObject = JObject.Parse(jsonContent);
   // Step 3: Use JSONPath to extract data
   var items = jsonObject.SelectTokens("$.catalog.item");
   foreach (var item in items)
   {
      // Extract values using JSONPath
      var title = item.SelectToken("title")?.ToString() ?? "No title";
      var author = item.SelectToken("author")?.ToString() ?? "No author";
   }

Чому JSON краще за XML?

Робота з JSON дійсно є набагато зручнішою та надійнішою порівняно з XML, і ось чому:

  1. Простота структури і синтаксису. JSON набагато легший для читання та розуміння, оскільки має більш просту структуру.
  2. Інтеграція з веб-технологіями і базами даних. JSON чудово підходить для сучасних веб-технологій і є найбільш зручним форматом для баз даних, таких як MongoDB, оскільки ця база даних безпосередньо працює з JSON-документами.
  3. Ефективність передачі даних. JSON займає менше місця при передачі, оскільки його синтаксис більш компактний у порівнянні з XML.

Ще одним важливим аспектом є те, що при роботі з JSON ми маємо значно кращу підтримку типів даних і зручне перетворення в об’єкти в мовах програмування. Це особливо важливо при роботі з великими наборами даних, де важлива не тільки швидкість обробки, а й зручність маніпулювання даними.

Порівняння MongoDB і MS SQL для зберігання даних

Після роботи з MongoDB і MS SQL для зберігання даних після Web Scraping, можу зробити такий висновок:

  • MongoDB — ідеальний вибір для роботи з великими обсягами неструктурованих ****даних, що часто змінюються. Завдяки гнучкості зберігання документів у форматі JSON і можливості легко масштабувати базу, MongoDB дозволяє швидко адаптуватися до змін.
  • MS SQL — найкраще підходить для структурованих даних, що потребують складної аналітики, надійності транзакцій і інтеграції в корпоративне середовище. Це чудовий вибір для тих випадків, коли потрібно мати чітку структуру даних і забезпечити високу надійність.

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

Мій рейтинг країн за захистом веб-сайтів від зовнішнього втручання:

  1. США — тут використовують суворі технології для виявлення ботів та застосовують капчі.
  2. Франція — подвійне шифрування даних, що значно ускладнює доступ до інформації.
  3. Австралія — прогресивні захисні механізми, що забезпечують високий рівень безпеки.
👍ПодобаєтьсяСподобалось5
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якщо проекту 10+ років то це нормальна практика)

Короч, леготня ці вебкравлери, з точки зору розробки, головне щоб потім по судах не затягали...

Я завжди знав що в нас дуже талановиті інженери)

Я 3 роки його писав...
І воно непогано працювало.

Доступ до даних — це завжди виклик, і кожен сайт має свої нюанси. Один із найцікавіших випадків у моїй практиці — це знайомство з Browser Fingerprint. На той момент я ще нічого про нього не знав, тож довелося витратити чимало часу, щоб зрозуміти, як це працює, обійти цей блокер і ще й автоматизувати рішення.

А-а-а...Навіщо? Чим погано просто запустити браузер, та нехай він сам вирішує ці питання.

JS зробить унікальний ваш відбиток і він буде незмінний, тож необхідно його постійно модифікувати та підкладати у реквести.

То нехай браузер це і робить, навіщо мені паритися? Скрипт запустив браузер, перейшов на сторінку, забрав звідти дані.

Это очень плохо масштабируется, а если есть ресурс масштабировать — менее гибкое при попытках обойти fingerprinting.

Ну... окрім fingerprints є cloudflare, є JavaScript (буде дивно, якщо не генерується mousemove), є капчі, частина інформації, яка нас цікавлять, може бути графікою, інколи нам треба ще таймінги змін на сайті, ... Тому є завжди ймовірність, що fingerprints то буде перший крок.

То це є комплексна робота та індивідуальний підхід до кожного веб застосунку. А уся система по збору даних має бути самостійною та автоматизованою. Можна працювати з будь яким сервісом, таким як Cloudflare, каптчі і тп. Це був цікавий кейс для мене з fingerprints та вибудови додаткових реквестів, бо навіть через браузер не можна було зайти на сайт та побачити інфу на ньому.

ну я согласен, но headless и прочие штуки они же отлично работают с «графикой». Графика это же только репрезентация чего-то в формате который можно посмотреть глазами.

Смотрите, я не спорю, что браузер будет работать и закроет много того, что придется думать как-то автоматизировать.

Згоден, що браузер може бути універсальним вирішенням майже всіх проблем з доступом до ресурсу, особливо якщо використовувати Puppeteer. Але з свого досвіду можу сказати, що це не найоптимальніший варіант. У випадку невеликого об’єму данних які потрібно зібрати за невизначений час це доволі непогана альтернатива, але частіше за все час обмеженний і данні набагато цінніші в «динаміці» плюсом до цього кількість риквестів може досягати декількох мільйонів на добу. Тож при вирішенні питання збору данних краще почати з комбінації Http request + Proxy + CurlThin(якщо є проблеми з шифрами). І далі працюємо або з JSon або з HTML. До того ж такий процес набагато легше паралелити і він буде набагато дешевшим як по ресурсах так і по трафіку.

особливо якщо використовувати Puppeteer.

Ну... особливо, якщо запускати його на віртуальній машині, та оперувати з браузером шляхом посилання руху миші та натискання на кнопки.

З плюсів, що не треба заморачуватися з DOM, просто знайшов текст, клацнув по ньому, знайшов капчу, відправив в телеграм-бот, прочитав відповідь, ...

Я не противник використання браузера як інструменту, але я в своїй практиці використовую його лише в крайніх хвипадках, коли вже нічого не допомагає. На рахунок рухів миші і введення тексту з клавіатури — якщо веб ресурс і використовує телеметрію с своєму аналізаторі, то дуже складно прописати рандомізацію. На рахунок DOM — я б посперечався з стабільністю і якістю данних при такому підході — навіть з ідеальними регулярками і XPath мейнтейнити потрібно буде дуже часто. Набагато простіше риквестити апіші урли і працювати з JSon(десеріалізація + можна засейвити результат для репарса якщо буде потреба).
Основний мінус браузера — перформанс і ресурси, побрібно сотні віртуалок з Puppeteer що б покрити те що можна зробити однією з HttpClient. В моїй практиці час виконання одного циклу — критичний, а об’єм данних великий. Приклад з недавнього: 3 мільйона запитів, що приблизно по наповненю відповідає 16к продуктів в 1.2к локаціях виконуються за 4 години. Для браузера — анріл в такий термін.

то дуже складно прописати рандомізацію

А що там складного? Рахуєш шлях, потім посилаєш

def mouse_click(self, rect):
    start_x, start_y = self.mouse_pos
    finish_x, finish_y = get_gauss_random_point_in_rect(rect)
    for x, y in human.calc_path(start_x, start_y, finish_x, finish_y):
        self.mouse.put_mouse_event_absolute(x, y, 0, 0, 0x00)
        gauss_rnd_wait(MOVE_DELTA_TIME)
    self.mouse.put_mouse_event_absolute(finish_x, finish_y, 0, 0, 0x01)
    gauss_rnd_wait(CLICK_DOWN_BUTTON_TIME)
    self.mouse.put_mouse_event_absolute(finish_x, finish_y, 0, 0, 0x00)
    self.mouse_pos = (finish_x, finish_y)
В Україні законодавство прямо не регулює збір даних з веб ресурсів, що означає, що ця практика не заборонена

Наприклад у правилах користування вебсайтом ДОУ є пункт:

Ви зобов’язуєтеся здійснювати доступ до Вебсайту виключно через користувацький інтерфейс. Зокрема, Ви зобов’язуєтеся не здійснювати доступ до Вебсайту через автоматизовані програмні засоби з метою, з-поміж усього іншого, автоматичного збирання розміщеної на сайті інформації без згоди Адміністрації.

Законодавство не регулює, а власник сайта заборонив. Чи є тут юристи, хто може розтлумачити?

Інформація, розміщена на сайті, може бути об’єктом авторського права, тож це регулюється чинним законодавством.
Але згоден, тут має бути пояснення від юриста)

Виходячи з логіки policy в цьому кейсі, усі пошукові та архівні системи, арх які заходять до них — порушують ПВ. З цього можна зробити висновок, що такий текст не буде мати юридичної сили.
Взагалі, любий шкед може на своєму сайті написати що йому заманеться, хоч прочитати Отче Наш 13 разів. Це не означає, що той текст буде мати хоч якусь юридичну силу. Точніше я б сказав так: юридичну силу він може й матиме, але на рішення яке на законодавчому рівні розбивається в пісок на старті — просто викинуті бабки на юриста.
Я не юрист, якщо що.

а так переконливо, наче юрист))

Ну, по-перше, пошукові системи виконують правила з dou.ua/robots.txt, а там багато ботів заборонено.

По-друге, у DOU з пошуковими ботами можуть бути інші стосунки, ніж зі звичайними користувачами.

По-друге, у DOU з пошуковими ботами можуть бути інші стосунки, ніж зі звичайними користувачами.

В контексті саме документу ДОУ — згоден на 100%, бо там конкретно вказано користувача.

Підписатись на коментарі