Scrapyとは?
Scrapeless Web Unlockerは、管理されたアクセス処理と任意のJavaScriptレンダリングを伴って公のウェブコンテンツを取得します。
Scrapyは、ウェブサイトをクローリングし、構造化データを抽出するためのオープンソースのPythonフレームワークです。Scrapyプロジェクトは、訪問するURL、各レスポンスを解釈する方法、生成するレコードを定義します。このフレームワークは、これらのルールに基づいてリクエストを調整するため、各ウェブサイトのために別々のキューやダウンローダーを書くことなくクローリングを構築できます。
重要な違いは、仕事の範囲です。1つの文書を取得することはHTTPクライアントのタスクです。カテゴリリンクを追跡し、詳細ページを処理し、一貫したレコードをエクスポートすることは、クローリングタスクです。Scrapyは後者に適合します。それは、あなたが変更し、個別にテストできる名付けられたコンポーネントを提供します。
TL;DR
- Scrapyは、スパイダーを中心にマルチページ抽出を整理します。 スパイダーは、クローリングの動作を指定し、ダウンロードしたレスポンスを解釈します。
- ScrapyはURLの発見をアイテム処理から分離します。 スケジューリングとパイプラインはワークフローの異なる部分を処理します。
- ScrapyはページのJavaScriptを自動的に実行しません。 取得経路を選択する前に、必要なデータが実際に表示される場所を確認してください。
- 完了したクローリングでもレコードの検証が必要です。 成功したダウンロードは、必要なフィールドが抽出されたことを証明するものではありません。
Scrapyに何が含まれていますか?
Scrapyには、リクエストのスケジュール、レスポンスのダウンロード、スパイダーコールバックの呼び出し、および抽出したアイテムの処理に必要な機械が含まれています。 Scrapyフレームワークの概要 は、リンクを追従し、訪問したページから構造化されたレコードを排出できるクローラーについて説明します。
スパイダーはプロジェクト特有の部分です。公的カタログの場合、スパイダーはカテゴリーページを認識し、製品リンクを見つけ、各詳細ページから製品識別子とタイトルを抽出するかもしれません。ダウンローダーは文書を取得します。アイテムパイプラインは、必須フィールドのチェックや受け入れたアイテムをストレージに書き込むなど、抽出されたレコードにルールを適用します。
この分割により、成長するクローラーの維持が容易になります。新しい出力先はストレージ段階に属します。変更された製品セレクターは抽出段階に属します。異なるネットワーク経路は取得設定に属します。それらの決定を分離することにより、ウェブサイトまたはデプロイメントの1つの部分が変更されたときに必要な無関係な変更の数が減ります。
リクエストがScrapyを通じて移動する方法
Scrapyのエンジンは、スケジューラー、ダウンローダー、スパイダー、およびアイテムパイプラインを通じてリクエストを調整します。 Scrapyアーキテクチャ は、これらのコンポーネント間の関係とその周囲のミドルウェアフックについて説明します。
スケジューラーは保留中の作業を保持します。エンジンがリクエストを配信すると、ダウンローダーはレスポンスを取得します。エンジンはそのレスポンスを関連するスパイダーコールバックに渡します。コールバックはアイテムを生成する、追加のリクエストを生成する、またはその両方を行うことができます。抽出されたアイテムはパイプラインに移動し、発見されたリクエストはスケジューリングに戻ります。
製品ページと次のカテゴリーページへのリンクを持つカタログカテゴリを考えてみてください。そのコールバックは詳細ページリクエストとページネーションリクエストを生成します。詳細コールバックは製品レコードを発信します。したがって、クローリングは一貫したレコードスキーマが有効なままサイトを通じて分岐します。これは、取得、解析、およびファイル書き込みが入れ子になったループ内で混在している長いスクリプトよりも管理しやすいです。
リクエスト重複排除とレコード重複排除は異なる質問に対処します。繰り返されるURLは望ましくない作業かもしれませんが、異なる2つのURLが同じ製品を説明するかもしれません。レコードキーをフレームワークのリクエストフィルタリングから独立して計画してください。
スパイダーがウェブサイトについて知っておくべきこと
スパイダーはサイトの発見可能な構造とそのレコードの意味をエンコードするべきです。ビジネス質問に答えるための最小限の許可されたクローリング範囲を特定することから始めてください:カテゴリ、サイトマップのサブセット、または提供された公の詳細ページのリストです。
発見を拡張する前に出力を定義してください。価格監視レコードには、製品識別子、タイトル、表示価格、通貨、ソースURL、収集時間が必要な場合があります。ウェブサイトがそれを一貫して公開しない場合、可用性はnullableである可能性があります。必須の識別子が欠落している場合、完全に見える行よりも拒否されたり隔離されたレコードにつながるべきです。
ページネーションにも明示的な停止ルールが必要です。サイトの次ページリンクが存在する場合はそれに従い、発見されたURLを意図したドメインやパスの範囲内に保ち、ページが次のリンクを提供しない場合は停止します。広範なリンク追従ルールは、サポートページ、トラッキングURL、または重複したナビゲーションパスに漂う可能性があります。より多くの発見されたURLは、必ずしもより有用なレコードを意味するわけではありません。
Scrapyがフィールドを抽出する方法
Scrapyは、レスポンスコンテンツに適用されたセレクターを使用してフィールドを抽出します。 ScrapyのCSSおよびXPathセレクター は、HTMLまたはXMLから要素、属性、およびテキストを選択する方法を提供します。
まずレコードコンテナへのアンカー抽出を行います。カテゴリページにいくつかの製品が含まれている場合は、各製品ブロックを選択し、そのブロック内のタイトルと価格を選択します。独立したページ全体のタイトルと価格リストは、1つの製品が価格を欠いている場合やページにプロモーショナルカードが含まれている場合に整合しなくなることがあります。
構造や意味を表現するセレクターを選択します。安定した製品属性は、生成されたクラス名よりも有用である可能性があります。オプショナルな要素を明示的に検査し、欠落フィールドと空文字列の違いを保持します。チャレンジページでタイトルを返さないセレクターは、静かに通常の製品レコードを生成すべきではありません。
抽出テストは、保存された許可された応答サンプルから利益を得ます。完全なアイテム、オプションフィールドの欠落、および変更されたレイアウトの代表的なケースを保持します。少数の意味のある例は、サイトの変更を、意図したコンテンツを含まなかったネットワークの応答と区別するのに役立ちます。
アイテムパイプラインがデータ品質を向上させる場所
アイテムパイプラインは、スパイダーがレコードを抽出した後にそれを処理します。 Scrapy アイテムパイプラインモデル 連続処理コンポーネントをサポートし、検証、クリーンアップ、および永続化を含みます。
元の価格値を失うことなく正規化する際は、生のソース値を保持してください。表示される価格は通貨記号、割引修飾子、または単位を含む場合があります。解析された金額と別途特定された通貨と共に、元の文字列を保存してください。ロケールを理解する前に句読点を削除すると、有効な価格が間違った値に変わることがあります。
安定したビジネスキーをストレージに使用してください。ソースURLは有用な出所ですが、リダイレクトや別の製品パスによって変更される可能性があります。ソース識別子と収集コンテキストの組み合わせが、より良いキーとなる場合があります。後の観測が現在の状態を置き換えるのか、履歴テーブルに追加されるのかを決定してください。これらの選択肢は、異なる下流の質問に対する答えとなります。
報告された拒否されたアイテムを理由とともに別個にカウントしてください。計画されたすべてのページをダウンロードするクローラーがほとんどのレコードを落とす場合、抽出またはスキーマの問題があります。ダウンロードカウントを成功の指標として扱うと、その失敗がデータセットを消費する人々から隠されてしまいます。
Scrapy、Requests、パーサー、およびブラウザ
Scrapyはクローリングフレームワークですが、HTTPクライアント、HTMLパーサー、ブラウザランタイムは、より狭いまたは異なるタスクを解決します。 Pythonクローラーとブラウザランタイムの比較 これらの層が責任によって評価されるべき理由を説明します。
| ツールレイヤー | 主な責任 | 選んでください、それが必要な時に |
|---|---|---|
| HTTP クライアント | リクエストを送信し、レスポンスを受信する | URLセットは小さく、アプリケーションコードがスケジューリングを所有しています。 |
| HTML パーサー | 提供されたマークアップからフィールドを抽出する | 申し訳ありませんが、特定のリクエストに従うことができません。 |
| Scrapy | リクエストの調整、発見、および記録処理 | ジョブはリンクされたページと繰り返しのクローリング実行にまたがります |
| ブラウザのランタイム | JavaScriptを実行し、ページと対話する | 必要なコンテンツは、レンダリングまたはユーザーの操作に依存します。 |
フレームワークの選択は、検索の選択を決定するものではありません。Scrapyは作業を整理できますが、対象は依然としてどの文書または応答がデータを含むかを決定します。アーキテクチャにブラウザを追加する前に、最初の応答を検査してください。
ダイナミックページでのScrapyの停止位置
Scrapyの通常のダウンローダーは、HTMLを受信した後にブラウザが実行するJavaScriptを実行しません。 動的コンテンツ選択アプローチ 実際のデータソースを見つけることから始まります。それは文書に埋め込まれている場合や、別の許可されたリクエストによって返される場合があります。
初期のHTMLにおける空の製品グリッドは、選択子の問題ではなく手がかりです。ダウンロードされた応答をブラウザに表示されている内容と比較してください。フィールドが公開された構造化エンドポイントから取得される場合は、アクセスが許可されているときに、その文書化されたまたは観察されたソースを使用してください。ワークフローがレンダリングされたコンテンツを必要とする場合は、レンダリングを実行する取得レイヤーを選択してください。
スクレイプレスウェブアンロッカー サプライ管理されたコンテンツ取得は、サポートされたアクセス処理とJavaScriptレンダリングオプションを備えています。 Web Unlocker 取得モデル アプリケーションがターゲットを提出し、返されたコンテンツを処理できるようにします。これはアーキテクチャのオプションです;製品名を追加しても、検証済みのScrapy統合が作成されるわけではなく、アプリケーション自身のパースルールが変更されるわけでもありません。
レビュー スクレイプレス価格設定 クローラー設計とは別に、クローリングに必要な取得作業を見積もってください。次に、展開アプローチを比較する際には、解析、ストレージ、および検証コストを含めます。
Scrapyプロジェクトで測定すること
Scrapyプロジェクトは、リクエストアクティビティと共に、使用可能なレコードとクロールカバレッジを測定するべきです。役立つカバレッジは、意図したURLの範囲から始まり、出力契約を通過するレコードで終わります。
発見された詳細URL、受け入れられたレコード、欠落している必須フィールド、重複したビジネスキー、およびレスポンスタイプの分布を追跡します。後でコンテンツの差異を調査できるように、各レコードに最終URLとコレクションコンテキストを保持します。リクエストがログインページまたはチャレンジを返した場合、有効な空のカテゴリとは別にレスポンスを分類します。
ターゲットとタスクでクローリングを制限します。リクエストの予算と慎重なペースを設定し、ソースのアクセス要件を尊重します。ページ構造を理解する前に同時実行を拡大すると、誤ったクローラーがより速く誤ったデータを生成する可能性があります。ワークロードを増やす前に、セレクタのカバレッジとスキーマの品質を改善します。
結論
Scrapyは、独立したダウンロードのコレクションではなく、メンテナンスされたクローリングが必要な場合に適しています。一つの許可されたカテゴリから始め、レコードスキーマを定義し、発見、抽出、検証、ストレージを通じてリクエストをトレースします。それらの段階が信頼できるレコードを生成したら、同じ明示的なルールで範囲を拡大します。
保守可能なPythonクローリングを構築する
管理されたコンテンツ取得を評価する際に、クローリングのスケジューリング、取得、レコード検証を別々に保ちます。
今日サインアップして $5の無料クレジットを手に入れよう — クレジットカードは必要ありません.
$5のクレジットを請求する →FAQ
Q: Scrapyはライブラリですか、それともフレームワークですか?
Scrapyは、ウェブサイトをクロールし、構造化データを抽出するためのアプリケーションフレームワークです。スパイダーと処理ルールを提供し、フレームワークがリクエストとアイテムのライフサイクルを調整します。より大きなアプリケーションの内部で使用できますが、その範囲は単一のリクエスト機能やパーサーを超えています。
Q: ScrapyはJavaScriptをレンダリングしますか?
Scrapyの標準ダウンローダーはページのJavaScriptをレンダリングしません。埋め込まれたデータや許可された構造化ソースのレスポンスを確認し、必要なフィールドがブラウザの実行に依存する場合はレンダリングレイヤーを選択してください。異なるセレクタは、レスポンスに到着しなかったテキストを抽出することはできません。
Q: ScrapyはRequestsとどう違いますか?
Scrapyはクローリングを管理し、RequestsはHTTPリクエストを送信します。Requestsは、既知のURLリストを持つ小さなスクリプトに適しています。Scrapyは、リンクされたページを発見および処理するプロジェクトのために、スケジューリング、コールバック、ミドルウェア、およびアイテムパイプラインを提供します。
Q: Scrapyプロジェクトは常にプロキシが必要ですか?
Scrapyプロジェクトは常にプロキシが必要というわけではありません。ターゲットの許可されたアクセスパス、場所の要件、およびネットワークポリシーによって、プロキシが有用かどうかが決まります。プロキシはルーティングを変更しますが、欠落したセレクタを修正したり、レコードを検証したり、制限されたコンテンツへのアクセスを許可したりすることはありません。
Q: 最初に役立つScrapyプロジェクトは何ですか?
役立つ最初のScrapyプロジェクトは、小さな許可されたページセットをクローリングし、定義されたレコードスキーマを生成します。ページネーションの境界、安定したレコードキー、および欠落したフィールドの検証を含めます。プロジェクトをスケジュールされたまたはより大きなクローリングにする前に、抽出されたレコードを確認します。