クロール vs スクレイピング: 違いは何ですか?
Scrapeless Crawlはページ発見を扱い、Scrapeless Scraping APIとScraping Browserは、統合されたパブリックウェブデータワークフロー内での抽出をサポートします。
要点
- クロールはページを発見し、スクレイピングはデータを抽出します。 クローラーはURLセットを拡張し、スクレイパーは選択したコンテンツをレコードに変換します。
- 出力は異なる質問に答えます。 クロールはマップやページコレクションを作成し、スクレイピングはタイトル、価格、または日付などのフィールドを生成します。
- 多くのシステムは順番に両方を使用します。 関連するページを特定するためにクロールし、次にデータセットスキーマに一致するページのみをスクレイピングします。
- どちらの用語も許可を定義しません。 アクセスルール、サイトの条件、プライバシー、およびデータ使用義務は、実際のワークフローに適用されます。
クロールとスクレイピングは同じパイプラインで頻繁に表示されますが、異なる問題を解決します。クロールは「システムが訪れるべきページはどれか?」に答え、スクレイピングは「このページからシステムが抽出すべき値はどれか?」に答えます。
クロールとスクレイピングの主な違いは何ですか?
主な違いは目的です:クロールはURLの発見と移動で、スクレイピングはフィールドの抽出です。
| 次元 | クロール | スクレイピング |
|---|---|---|
| 主な目的 | リソースを見つけて訪問する | 特定の値を収集する |
| 典型的な入力 | シードURL、サイトマップ、フィード | ページコンテンツまたは構造化されたレスポンス |
| 典型的な出力 | URLグラフ、ページアーカイブ、クロールメタデータ | JSON、CSV、データベースレコード |
| 範囲 | しばしば多くのリンクされたページ | 1ページタイプまたは既知のURLセット |
| コアロジック | フロンティア、スケジューリング、重複排除 | パース、セレクタ、クリーニング、検証 |
| 主な失敗 | 見逃した、重複した、または無限のURLパス | 欠損した、不正確な、または古いフィールド |
クロールの仕組み
クロールはシードURLから始まり、承認されたフロンティアを繰り返し拡張します。
クローラーはページを取得し、ナビゲート可能なリンクを抽出し、各URLを正規化し、既知の重複を削除し、スコープルールを適用し、適格なURLをスケジューリングします。検索クローラーは、レンダリング後にリンクをキューに戻すこともあります; GoogleのJavaScript処理の説明 は、レンダリング後にリンク発見が続く可能性があることを示しています。
Googleのクロールとインデックスの概要 は、ロボット制御、正規化、リダイレクト、JavaScript、クロール管理をページの発見と処理の明確な部分としてグループ化します。
スクレイピングの仕組み
スクレイピングは、データセットが必要とする値を示すコンテンツとスキーマから始まります。
スクレイパーはHTMLをパースするか、構造化されたレスポンスを読み込み、セレクタやパスでフィールドを特定し、値をクリーニングし、型と必須フィールドをチェックし、その後レコードを保存します。スクレイピングは、新しいページを発見せずに、1つの既知のURLで機能することができます。
いつ両方が必要ですか?
ターゲットレコードが変化するページコレクション全体にあるときは、両方が必要です。
製品カタログ
クローラーはカテゴリおよび製品のURLを見つけ、スクレーパーは対象となる詳細ページから製品フィールドを抽出します。
ドキュメント検索
クローラーは記事とバージョンをマッピングし、スクレイパーは見出し、本文、そして標準メタデータを抽出します。
プロパティモニタリング
クローラーはリストページを発見し、スクレイパーは価格、場所、ステータス、および物件属性を記録します。
ニュース収集
クロールはセクションおよび記事のリンクに従い、スクレイパーは見出し、著者、出版データ、および本文をキャプチャします。
どれを選ぶべきですか?
既知のページのスクレイピング、発見のためのクローリング、変更されるマルチページデータセットのためには両方を選択してください。
- スクレイピングのみを使用してください。 選択したフィールドのみが必要です。
- クロールのみを使用してください。 目的はサイトマップ、リンク監査、アーカイブ、またはインデックス可能なページコレクションです。
- 両方を使用してください。 関連するURLは、レコードを抽出する前に発見されなければなりません。
- ルール: 1. 翻訳したテキストのみを出力 — 説明や余分なコードのフェンスは不要です。 2. Markdown/HTML構造 (見出し、リスト、リンク、テーブル) を正確に保持します。 3. @@CODEBLOCK_0@@ や @@INLINECODE_0@@ などのプレースホルダー トークンはそのまま EXACTLY として保持します; 決して翻訳、再配置、統合、または再フォーマットしないでください。 4. ``` コードのフェンスを追加したり削除したりせず、通常のテキストをコードブロックにラップしないでください。 自動的に使用しないでください。 サポートされたエクスポートまたはファーストパーティAPIは、必要なフィールドを提供する場合、明確なデータソースである可能性があります。
共有運用およびコンプライアンス規則
クローリングとスクレイピングは、定義された公開範囲、合理的なリクエストレート、アクセスチェック、データ最小化、明確な停止条件を使用するべきです。
The ロボット排除プロトコル クローラーの動作に適用される一方、条件、プライバシー、および適用法は、データの完全な収集と使用にわたって見直しを必要とします。
アーキテクチャにおいてクロールとスクレイピングはどのように分離されるべきか?
明示的な契約を通じてクローリングとスクレイピングを分離します。クローラーは、正規化されたURL、発見ソース、ページタイプのヒント、および取得メタデータを持つページ候補を出力します。スクレイパーは、適格なページまたはレスポンスを受け入れ、スキーマに準拠したレコードを出力します。いずれのコンポーネントも、他方が内部状態をどのように保存しているかを知る必要はありません。
この分離により、失敗処理が正確になります。URLが発見されていない場合、クローリングルールに注意が必要です。ページが取得されたが必要なフィールドが欠けている場合、抽出マッピングまたはページ分類が間違っている可能性があります。正しいレコードがストレージに到達しない場合、その問題はダウンストリームパイプラインにあります。これらの三つを一つの不透明なジョブにまとめると、すべてのインシデントが「スクレイパーが壊れた」というように見えてしまいます。
キューまたは耐久性のあるハンドオフは、クローラーのボリュームと抽出コストが異なる場合に便利です。ブラウザーでレンダリングされたページが小さなワーカープールによって処理されている間、発見は続けることができます。ハンドオフには、同じURLが理由なしに繰り返し抽出されないように、重複排除キーとスキーマバージョン情報を含める必要があります。
各レイヤーはどの状態を所有していますか?
クローラーはURLの状態を所有しています:未表示、キュー、取得、リダイレクト、除外、または後の訪問のためにスケジュールされています。また、どのページがURLを発見したか、どの正規化されたURLが同等のアドレスを表しているかといったグラフの関係も所有しています。
スクレイパーはレコード状態を所有します:ページタイプ、スキーマバージョン、フィールド値、欠落フィールドの診断、正規化結果、およびソースの由来。スクレイパーは、有効なページからレコードを生成しない場合があります。これは、ページが空の結果であるか、ナビゲーションサーフィスであるか、またはサポートされていないテンプレートであるためです。その結果は、ネットワークの障害と見なされるのではなく、明示的であるべきです。
共有メタデータは、可能な限り不変であるべきです。要求されたURL、最終URL、取得時刻、応答識別子、およびコンテンツハッシュは、チームがそれを生成したページキャプチャにレコードを接続できるようにします。これにより、セレクタやスキーマが変更されても、監査やデバッグが可能になります。
結合パイプラインはどのようにページネーションを処理しますか?
ページネーションは、発見と抽出の境界に位置しています。クローラーは、別の結果ページが存在するかどうか、そしてそれが範囲内に属しているかどうかを判断します。スクレイパーは、現在のページからレコードを抽出します。これらの責任を分けておくことで、フィールドセレクター内でのURL生成の隠蔽を避けることができます。
一部のサイトは明示的な次のリンクや番号付きページを公開しています。他のサイトは構造化されたレスポンスのカーソル値を使用したり、インタラクションを通じてさらに多くのレコードをロードしたりします。クローラーは発見された状態として継続トークンまたは次ページのURLを保存する必要があります。スクレイパーは、各ページが期待されるレコードタイプを返すことを検証し、ページ間でエンティティ識別子を重複しないようにする必要があります。
停止条件は不可欠です。新しいレコードキーが生成されなくなるか、承認された範囲が完了するまで、シーケンスを終了してください。空のビジュアルモジュールが常に終了を意味するとは限りません。これは、領域、セッション、またはレンダリングの不一致を示すこともあります。
二つのレイヤーをどのようにテストしますか?
クローラーのテストはグラフの振る舞いに焦点を当てています。既知のリンクを持つページが与えられた場合、クローラーは許可されたURLを受け入れ、除外されたURLを拒否し、一貫してバリアントを正規化し、発見の関係を保持すべきです。テストにはリダイレクト、相対リンク、フラグメント、クエリパラメータ、カノニカル、リンクトラップを含むページテンプレートが含まれている必要があります。
スクレイパーテストはスキーマの動作に焦点を当てています。代表的なコンテンツが与えられた場合、スクレイパーは正しいレコードコンテナを選択し、意図されたフィールドを抽出し、値を正規化し、オプションまたは無効なフィールドを明確に報告する必要があります。無関係なナビゲーションテキストに依存したり、推薦モジュールからレコードを一致させたりしてはいけません。
エンドツーエンドテストは、接合部をカバーします。小さな承認されたシードセットから始め、どのURLが抽出に達するかを確認し、生成されたレコードを可視ソースと比較します。パイプラインはユニットスイートの両方を通過することができますが、ページタイプのヒント、コンテンツ形式、またはスキーマバージョンが不一致の場合、接合部で失敗することがあります。
チームはどのように運営の所有権を選択するか?
所有権は障害ドメインに従うべきです。プラットフォームチームは、取得、キュー、ホスト制限、およびブラウザ容量を運用することができます。データチームは、ページ分類、フィールドマッピング、正規化、および品質ルールを所有することがあります。コンプライアンスとセキュリティレビューは、ソーススコープとデータ使用がエンドツーエンドの懸念事項であるため、両者に跨ります。
サービスレベルの目標は異なるべきです。クロール目標は、発見の新鮮さ、フロンティアの年齢、および承認されたパスのカバレッジを説明できます。スクレイピング目標は、有効レコード率、必要フィールドの完全性、およびスキーマの整合性を説明できます。1つの統合成功率は、システムがページを見つけているのか、正しく解釈しているのかを隠します。
プロジェクトが小さい場合でも、1つのコードベースはモジュールと別々の状態を通じてこれらの境界を維持できます。目標は組織の複雑さではなく、各決定を行ったステージと欠陥を修正すべき場所を示す設計です。
結論
クロールはページセットを構築し、スクレイピングはデータセットを構築します。これらの責任を分けておくことで、発見、抽出、テスト、およびメンテナンスを理解しやすくなります。たとえ両方が1つのサービス内で実行されていても。
あなたのウェブデータワークフローを構築する準備はできていますか?
Scrapelessを使用して公的なウェブコンテンツを取得し、その後、あなたのデータセットに適した発見と抽出のパターンを適用してください。
無料で開始 →よくある質問
スクレイピングはクロールなしで行われることがありますか?
はい。スクレイパーは、追加のURLを発見することなく、1つの既知のページまたは提供されたURLリストを処理できます。
クロールはスクレイピングなしで行われることがありますか?
はい。クローラーは、ビジネスフィールドを抽出することなく、URLグラフを構築したり、ページをアーカイブしたりできます。
どのプロセスがCSSセレクターまたはXPathを使用しますか?
スクレイピングはフィールド抽出のためにCSSセレクターまたはXPathを使用します。クローラーもリンク、カノニカルタグ、またはページタイプを特定するためにそれらを使用することがあります。
検索エンジンのクローラーはスクレイパーでもありますか?
検索エンジンのクローラーは、インデックス作成のためにページコンテンツを収集および処理するため、システムには抽出の動作が含まれる可能性がありますが、その定義されたタスクは発見とインデックス作成です。