Scrapyとは何ですか？

Scrapeless Universal Scraping APIは、抽出前に取得またはレンダリングされたコンテンツが必要なScrapyワークフローのための取得ソースとして機能します。

Scrapy はクローリングフレームワークです

Scrapyは、ページを取得し、構造化されたフィールドを抽出し、リンクをたどり、アイテムを処理し、結果をエクスポートするためのオープンソースのPythonフレームワークです。これは、HTMLパーサーよりも大きく、HTTPクライアントをループするよりも整理されています。このフレームワークは、プロジェクトに多くのページ、継続ルール、共有リクエストポリシー、再利用可能なアイテムロジック、またはスケジュールされた実行があるときに便利になります。

The 公式Scrapyドキュメント クモ、セレクタ、リクエストとレスポンス、アイテムパイプライン、フィードエクスポート、ミドルウェア、拡張、スケジューリング、展開プラクティスについて説明します。プロジェクトは最初は小さなサブセットのみを使用し、繰り返されるロジックが現れたときにコンポーネントを追加できます。

良いScrapyプロジェクトは、スパイダーにソース知識を保持し、再利用可能なポリシーを他の場所に置きます。スパイダーはどのページから開始するか、そしてそれらをどのように解釈するかを知っています。ダウンローダーミドルウェアは、横断的なリクエストとレスポンスの挙動を処理します。アイテムパイプラインは、出力をクリーンアップ、検証、重複排除、または保存します。

Scrapyデータがシステムを通過する方法

Scrapyの実行エンジンがフローを調整します。 アーキテクチャの概要 リクエストがクモからスケジューラに移動し、ダウンローダーミドルウェアを通ってダウンローダーに移動し、レスポンスがミドルウェアを通ってクモに戻る様子を示します。その後、アイテムはアイテムパイプラインに渡され、新たに発見されたリクエストはスケジューラに戻ります。

境界は、すべてのスパイダーが輸送、重複排除、および出力を再発明するのを防ぎます。また、失敗を特定しやすくします。ダウンロードの問題は、スパイダーコールバックの前に属します。欠落しているタイトルは、解析または検証に属します。データベースエラーは、項目がすでに構造化された後に属します。

Scrapyスパイダーの役割

クモは、どのリクエストを送信し、それに対する応答をどのように処理するかを定義するPythonクラスです。 公式スパイダーガイド リクエストとコールバックのサイクルを説明します：最初のリクエストがダウンロードされ、コールバックがレスポンスを解析し、コールバックがアイテムまたはさらにリクエストを返します。

以下のブロックは、現在のワークスペースにScrapyがインストールされていないため、ローカルランタイムの前提条件です。その構造は文書化されたスパイダーAPIに従っています。専用の環境で実行し、収集を許可する条件を持つ公開ターゲットを使用してください。

import scrapy

class ExampleSpider(scrapy.Spider):
    name = "example_page"
    allowed_domains = ["example.com"]
    start_urls = ["https://example.com/"]

    def parse(self, response):
        title = response.css("h1::text").get()
        href = response.css("a::attr(href)").get()

        if not title or not href:
            raise ValueError("expected page identity is missing")

        yield {
            "title": title.strip(),
            "url": response.urljoin(href),
            "source_url": response.url,
        }

スパイダーは、アイテムを返す前にその識別子フィールドを検証します。 response.urljoin リンクを実際のレスポンスURLに対して解決します。カタログでは、コールバックはレコードコンテナをループ処理し、各コンテナに対して子セレクタを実行する必要があります。

セレクタ、アイテム、パイプラインは別々の役割を持っています。

セレクタはレスポンスからフィールドを読み取ります。アイテムまたはプレーン辞書は抽出されたデータを表します。パイプラインは、抽出後に動作します。これらの役割を分けておくことで、プロジェクトは保存されたレスポンスに対してセレクタをテストし、プレーンなPythonの値で正規化をテストできます。

CSSを使用して簡潔な構造的クエリを作成し、フィールドが系譜、兄弟、またはテキスト関係に依存する場合はXPathを使用してください。必須フィールドを明示的に保ちなさい。安定したIDや正準URLが欠落している場合はアイテムを拒否すべきです；オプションの字幕はnullのままでかまいません。パイプラインは、スパイダーが観察したことのない欠落しているソース値を推測してはいけません。

• スパイダーはページ固有の知識を持っています。 URL、セレクタ、および継続ルールはソースの近くに属します。
• ミドルウェアは繰り返し輸送動作を所有します。 ポリシーが本当に共有されている場合にのみ、スパイダー全体に適用してください。
• パイプラインはレコードポリシーを所有します。 抽出後に検証、正規化、重複排除、永続化します。
• フィードエクスポートはシンプルなストレージをカバーします。 明確な必要がない限り、カスタム持続層を書く前に組み込みのJSONまたはCSV出力を使用してください。

Scrapyが適切なサイズであることを知ってください。

Scrapyは、タスクに多くのページ、複数のスパイダー、共有ポリシー、パイプライン、可観測性、または繰り返し実行がある場合にその構造を獲得します。一ページの抽出は、リクエストとパーサーの組み合わせとしてより明確かもしれません。小さく始めることは失敗ではありません；調整が主な問題になると、フレームワークに移行するのが有用です。

デフォルトではScrapyはブラウザではありません。必要な値がレスポンスボディに欠落し、ページスクリプトが実行された後にのみ表示される場合、セレクタはそれらを回復できません。レンダリングされたHTMLを返すダウンローダー統合、認可された構造化ソース、または相互作用がタスクの一部である場合にはブラウザワークフローを使用してください。

クロール範囲と継続を制御します。

allowed_domains は便利なガードですが、プロジェクトの範囲も許可されたスキーム、パスパターン、クエリ動作、およびページ予算を定義するべきです。重複排除の前にURLを正規化して、トラッキングパラメータや代替形式がキューを増やさないようにします。

継続は、確認された次のリンクまたはカーソルに従うべきです。ソースがその信号を削除した場合、スパイダーは停止できます。空のアイテムだけでは完了の証拠にはなりません。誤ったページ、セレクタの変更、またはクライアントによってレンダリングされたシェルも何も生じない可能性があります。

クロールをエクスポートし、観察します。

フィードエクスポートは、標準フォーマットでアイテム出力を書く最も簡単な方法です。レコードの検証、重複排除、データベースへの書き込み、またはソース固有の変換が必要な場合、パイプラインが適切です。拒否されたアイテムの理由とネットワーク診断はビジネスレコードから分離するべきです。

リクエスト、レスポンスクラス、ページ識別失敗、セレクタのミス、返されたアイテム、拒否されたアイテム、キューの深さを追跡します。 HTTPセマンティクス仕様 はレスポンスステータスを明確にしますが、成功したレスポンスであっても無関係な文書である可能性があるため、ページ識別チェックは依然として必要です。

共有ポリシーのためにのみミドルウェアと拡張機能を追加します。

ダウンローダーミドルウェアは、複数のスパイダーが同じリクエストまたはレスポンス動作を必要とする場合に適切です。スパイダーミドルウェアはスパイダーの入力と出力の周囲に存在します。拡張機能はフレームワークの信号を観察し、メトリクスや運用限界などのプロジェクト間の動作を実装します。一度限りのセレクター修正は、これらのグローバルレイヤーのいずれにも所属しません。

ルールを所有する最小のコンポーネントから始めます。一つのスパイダーがヘッダーまたはパースブランチを必要とする場合、動作が繰り返され同じ意味を持つまでそこに保ちなさい。早まったグローバルフックは、リクエストがそれを作成したスパイダーから遠く離れて変わる可能性があるため、プロジェクトを推論しづらくします。

複数のミドルウェアクラスが有効になっている場合のドキュメントの順序。各フックは一つの責任を持ち、次の段階が期待するフレームワークのタイプを返すべきです。テストは、最終的にエクスポートされた行だけでなく、コンポーネント境界でリクエストまたはレスポンスを主張する必要があります。

アイテム処理を通じて由来を保存します。

アイテムは、パイプラインに入る前にその正準ソースURLと安定したソース識別子を持っているべきです。パイプラインは取得時間、パーサーのバージョン、バッチ識別を追加でき、それから一意性またはストレージポリシーを強制します。それらのフィールドは、下流のユーザーが実際のソース変更をスパイダーの展開と区別するのを可能にします。

正規化によって意味が失われる可能性がある場合は、生の値を保持します。通貨、ローカライズされた数字、人間の日付、可用性ラベルは、ソースを意識した変換を必要とします。正規化された値を十分な元の文脈と共に保存し、その決定を監査して、宣言されたスキーマを侵害する組み合わせを拒否します。

結論

Scrapyは、単なるパーサーではなく、クローラーを調整するためのフレームワークです。そのエンジン、スケジューラ、ダウンローダー、ミドルウェア、スパイダー、パイプライン、エクスポートは、それぞれの懸念に明確な拠点を提供します。キューイングと再現性が重要な場合にその構造を使用し、ページ固有のセレクタをスパイダーに保持し、アイテムを返す前に識別を検証し、ソースが要求する場所にのみレンダリングされた取得を追加します。