新しい歴史

Web スクレイピングの最適化: より高速でスマートなスクレイパーのためのヒント

に Bright Data8m2024/11/15

長すぎる; 読むには

Web スクレイパーを最適化するには、より効率的なデータ抽出のための高度なテクニックを実装する必要があります。重要なヒントとしては、接続の問題やページ障害を管理するためのエラー処理の実装、サーバーの過負荷を回避するための指数バックオフによる再試行の利用、ページ構造の変更による破損を防ぐための柔軟な CSS または XPath セレクターの記述などがあります。スクレイピングを高速化するには、lxml などの高速 HTML パーサーを使用し、HTTP/2 を活用して単一の接続で複数のリクエストを送信することでレイテンシを削減します。これらのテクニックは、スクレイパーを効果的に拡張するのに役立ち、大規模な操作の速度と回復力の両方を強化します。

featured image - Web スクレイピングの最適化: より高速でスマートなスクレイパーのためのヒント

❗免責事項: これは、高度な Web スクレイピングに関する 6 部構成のシリーズのパート 3 です。このシリーズは初めてですか?パート 1 から最初から読んでください。

高度な Web スクレイピングシリーズのパート 2 では、 SPA、PWA、AI を利用したサイトからデータをスクレイピングする方法を学びました。これで、ほとんどの最新の Web サイトで機能するスクレイパーを構築するために必要な知識がすべて身についたはずです。

次は何ですか? プロのスクレイピングのヒントとコツを使ってスクレイパーを最適化しましょう。

Web スクレイピングが簡単になる — 本当にそうでしょうか?

Web スクレイパーを構築しますか? すべてはスクリプト次第です。👨‍💻

正直に言うと、コードを書いたことがある人なら、スクリプトはほとんどの場合それほど難しくないことが分かるでしょう。ここに数行、そこにfor書くだけで、プロのようにデータをスクレイピングできます。簡単そうですよね? 😄

しかし、ここに問題があります。小さなスクレーパーを書くのは簡単だからといって、安心しきれないかもしれません。誰でも読めるコードが 12 行しかないのに、適切なコメント、エラー処理、ログ、あるいはきちんとしたインデントなど気にする必要はないのです。

わかります。必要のないものを過剰に設計する理由は何でしょうか? 過剰設計は進歩の敵です。しかし、スクレーパーを複数のページ、さらにはサイト全体に拡張する必要がある場合はどうなるでしょうか? 🤔

その時、あなたの手抜きのスパゲッティコードスクレーパーは壊れてしまいます！🍝

高度な Web スクレイピングのヒントが必要な理由は次のとおりです。

Web スクレイピングの最適化: トップ 7 のヒントとコツ

重要なデータを含むページを優先する、リクエストをランダム化するなど、一般的な Web スクレイピングのヒントはすでに聞いたことがあるはずです。素晴らしいアドバイスですが、正直に言うと、これらのトリックは古いものです。📰

より高度なシナリオを扱う場合、これらの基本だけでは不十分な場合があります。スクレイピングのレベルを本当に上げたい場合は、次のレベルのテクニックを探求する必要があります。

準備はいいですか？シートベルトを締めて、Web スクレイピングスキルを次のレベルに引き上げましょう。💪

⚠️警告:いくつかのヒントが既知だと感じても心配しないでください。そのまま読み進めてください。さらに深く掘り下げていくと、興味深い洞察がたくさんあります。🤿

エラー処理を実装する

Web スクレイピングで最もよくある間違いの 1 つは、インターネットが魔法のような絶対確実なテクノロジーではないことを忘れてしまうことです。サイトにリクエストを送信すると、さまざまな問題が発生する可能性があります (そして、ある時点で問題が発生します)。❌

一般的なシナリオをいくつか見てみましょう。

Wi-Fiまたは接続が一時的に途切れる場合があります
ウェブサイトをホストしているサーバーが利用できない可能性があります
探しているページはもう存在しない可能性があります
対象サイトで一時的な速度低下が発生し、タイムアウトエラーが発生している可能性があります。

ここで、データの解析、前処理、データベースへのエクスポートを組み合わせると、完璧なカオスのレシピが完成します。💥

では、解決策は何でしょうか?エラー処理です! 🛡️

エラー処理は、Web スクレイピングの最大の味方です。スクリプトは数十 (または数千) のページを処理する可能性があり、1 つのエラーで操作全体がクラッシュすることはあってはなりません。

try ... catchブロックはあなたの味方であることを覚えておいてください。これを使用して、リクエストと処理ロジックをラップします。また、ほとんどの HTTP ライブラリは、不正な HTTP 応答 ( 404や500など) に対して例外を発生させないことにも注意してください。😲

HTTP ステータスコードについて詳しくない場合は、以下のビデオをご覧ください。

たとえば、 Python のリクエストライブラリでは、次のように応答ステータスコードを手動で確認する必要があります。

 import requests response = requests.get("https://example.com") if response.status_code == 200: # handle the successful response... else: # handle the error response...

または、同等に、 raise_for_status()メソッドを使用します。

 import requests try: response = requests.get("https://example.com") # raises an HTTPError for bad responses (4xx or 5xx) response.raise_for_status() # handle the successful response... except requests.exceptions.HTTPError as http_err: # handle an HTTP error... except requests.exceptions.RequestException as req_err: # handle a request error...

リクエストの再試行による障害回復

高度な Web スクレイピングスクリプトは、エラーを処理できるだけでなく、エラーから回復できる必要があります。Web スクレイピングに関連するエラーのほとんどは Web リクエストの作成に関連しているため、再試行可能なリクエストを実装することでスクレイパーの有効性を大幅に向上できます。

コンセプトはシンプルです。リクエストが失敗した場合は、成功するまで 1 回、2 回、3 回、またはそれ以上再試行します。🔄

しかし、ここに落とし穴があります。リクエストが失敗する最も一般的な理由の 1 つは、ターゲットサーバーが一時的にダウンしているか遅いことであるため、短期間に同じリクエストを繰り返し送信してサーバーに過負荷をかけないようにする必要があります。

今リクエストが失敗すると、すぐにまた失敗する可能性が高くなります。そこで指数バックオフが役立ちます。

この手法では、即座に再試行するのではなく、再試行の間隔を徐々に長くして、ターゲットサーバーに回復する時間を与えることで成功の可能性を高めます。⏳

カスタムコードを使用して単純な再試行戦略を手動で実装することもできますが、多くの HTTP クライアントには再試行を自動的に処理するための組み込みユーティリティまたはライブラリが付属しています。たとえば、Axios はaxios-retryライブラリを提供しており、次のように使用できます。

 const axios = require("axios"); const axiosRetry = require("axios-retry"); axiosRetry(axios, { retries: 3, retryDelay: axiosRetry.exponentialDelay }); axios.get('https://example.com') .then(response => console.log(response.data)) .catch(error => console.log("Request failed:", error));

同様に、Python のurllib3パッケージには、ほとんどの Python HTTP クライアントとシームレスに統合されるRetryクラスが付属しています。

汎用セレクターを書く

DevTools で要素を検査するときに、右クリックして「セレクターをコピー」オプションを選択したくなるかもしれません。

ただし、結果は次のようになる可能性があるので注意してください。

 #__next > div > main > div.sc-d7dc08c8-0.fGqCtJ > div.sc-93e186d7-0.eROqxA > h1

それは確かにウェブスクレイピングには理想的ではありません…。

問題は、このような過度に具体的なセレクターは、ページ構造が変更されると簡単に壊れてしまうことです。セレクターが詳細になるほど、壊れやすくなります。

ウェブスクレイピングの耐性を高めるには、セレクターを柔軟に保つ必要があります。スタイル関連のクラス（常に変更される）に頼るのではなく、 id 、 data- 、 aria-など、変更される可能性が低い属性に焦点を当てます。これらの属性のほとんどはテストとアクセシビリティを目的としているため、時間の経過とともに一貫性が保たれる傾向があります。💡

CSS セレクターは読みやすく理解しやすいですが、 XPathの方が強力です。しかし心配しないでください。多くの場合、シンプルな CSS セレクターで同じ結果を達成できるため、複雑な XPath コードを必要とせずに済みます。😌

詳細については、 XPath と CSS セレクターに関するガイドをご覧ください。

高速な HTML パーサーを優先する

HTML ページの解析には、特に大規模でネストされた DOM を扱う場合には、時間とリソースがかかります。スクレイパーが数ページのみを解析する場合、それほど大きな問題にはなりません。

さて、スクレイピング操作が拡大し、何百万ページものデータを取得する必要がある場合はどうなるでしょうか? この小さなオーバーヘッドによって、サーバーのリソースがすぐに消耗し、スクレイピングの合計時間が数時間も長くなる可能性があります。⏳

より深く理解するには、次のリソースを参照してください。

完全な比較をお探しですか? 最高の HTML パーサーに関する記事をお読みください。

良いニュースは？あるパーサーから別のパーサーに切り替えるのはそれほど難しくないということです。たとえば、 BeautifulSoupでは、単純なパラメータの変更だけです。

 from bs4 import BeautifulSoup # or using html.parser soup = BeautifulSoup(html_content, "html.parser") # or using lxml parser soup = BeautifulSoup(html_content, "lxml")

Chrome などのブラウザに組み込まれている HTML パーサーはどうでしょうか?🤔

詳細については、以下のビデオをご覧ください。