Thiết kế một Quy trình Dữ liệu Tìm kiếm Google với Kiểm tra Chất lượng

TL;DR:

• Một đường ống dữ liệu tìm kiếm Google cần có hồ sơ về lần chạy cũng như kết quả của nó. Các quan sát trống, đang chờ xử lý, thất bại và không xác định đều có thể không có hàng hữu cơ dự kiến.
• Bảo toàn các bản ghi âm thô trước khi áp dụng các quy tắc phân tích. Các bảng được dẫn xuất và báo cáo chất lượng có thể được xây dựng lại; bằng chứng gốc nên giữ nguyên không thay đổi.
• Các quy tắc chất lượng phải khớp với báo cáo. Một bộ phản hồi có thể sử dụng không đảm bảo vị trí hợp lệ hoặc bối cảnh tìm kiếm có thể so sánh được.

Một đường ống tìm kiếm có thể viết thành công một tệp và vẫn sản xuất phân tích gây hiểu lầm. Phản hồi có thể đang chờ xử lý, một bộ định dạng có thể loại bỏ các hàng không hợp lệ, hoặc một báo cáo có thể kết hợp các thị trường khác nhau dưới cùng một từ khóa. Chỉ việc lưu trữ thành công không xác lập rằng các quan sát kết quả trả lời câu hỏi dự kiến.

Scrapeless Google Search API cung cấp dữ liệu thu thập. Đường ống dữ liệu tìm kiếm Google được mô tả ở đây thêm lưu trữ thuộc về ứng dụng, xác thực và báo cáo xung quanh nó. Lịch trình, bảo quản lịch sử, cơ sở dữ liệu và kiểm tra chất lượng là trách nhiệm của đường ống, không phải là dịch vụ tích hợp sẵn được tuyên bố của API tìm kiếm.

Pipeline at a Glance

Đường ống di chuyển qua lập kế hoạch yêu cầu, thu thập, lưu trữ thô, dự đoán, xem xét chất lượng và báo cáo. Giữ một tham chiếu ổn định giữa những giai đoạn đó để một nhà phân tích có thể theo dõi một biểu đồ trở lại yêu cầu và phản hồi chính xác.

Một công việc đã được lập kế hoạch tồn tại trước khi phản hồi đến. Kết quả thu thập của nó sau đó trở thành bằng chứng cho hồ sơ cuộc chạy, ngay cả khi không có mục hữu cơ nào có thể được dự đoán. Lưu trữ các bản ghi âm thô tách biệt với các hàng kết quả được dẫn xuất và bảo tồn các quyết định chất lượng đã được sử dụng để chấp nhận các bản ghi vào một báo cáo.

Chương trình địa phương bên dưới kiểm tra các bản ghi âm đã lưu và in ra một báo cáo chất lượng. Nó không thu thập dữ liệu, lập lịch công việc, tạo kho hàng, hoặc sửa đổi giá trị nguồn. Trách nhiệm hạn chế đó làm cho đầu ra của nó dễ kiểm tra và thay thế hơn.

Stage 1 — Define the Request and Comparison Scope

Yêu cầu xác định bối cảnh quan sát. Bảo vệ truy vấn, quốc gia, ngôn ngữ, vị trí, chế độ đầu vào và độ lệch trang mỗi khi cung cấp. Các thông số của Google Search giải thích lý do tại sao một từ khóa đơn lẻ là không đủ để xác định các quan sát có thể so sánh.

Một yêu cầu đã được tuần tự chính xác là một khóa so sánh bảo thủ. Thay đổi độ lệch thay đổi mảnh thu thập; thay đổi quốc gia hoặc cách diễn đạt thay đổi bối cảnh nghiên cứu. Nếu đường ống sau đó nhóm các cấu hình trông tương đương, hãy tài liệu hóa quy tắc chuẩn hóa và giữ nguyên yêu cầu ban đầu.

Lập kế hoạch cách mà các định danh cuộc chạy, công việc đã lập lịch và các quan sát hoàn thành liên quan. Một lần thu thập đã lập kế hoạch nhưng bị bỏ lỡ nên vẫn được nhìn thấy trong phủ sóng hoạt động ngay cả khi nó không có phản hồi API. Trình kiểm tra địa phương không thể phát hiện các công việc mà nó không bao giờ được giao; một lập trình viên hoặc sổ cái công việc phải cung cấp danh sách đó.

Stage 2 — Capture the Outcome Before Projecting Rows

Quy trình làm việc Google Search request workflow gửi actor scraper.google.search đến POST https://api.scrapeless.com/api/v1/scraper/request với một khóa API trong x-api-token. HTTP 200 mang dữ liệu nhiệm vụ, trong khi HTTP 201 chỉ ra một nhiệm vụ đang chờ xử lý. Bảo tồn sự phân biệt đó trước khi đọc mảng hữu cơ.

Sử dụng một phong bì ghi lại chứa yêu cầu đã gửi, phản hồi gốc, trạng thái HTTP đã ghi, định danh cuộc chạy và thời gian biên nhận của khách hàng. Giữ các tiêu đề xác thực ra khỏi các tệp bằng chứng được chia sẻ. Phong bì là hợp đồng lưu trữ của ứng dụng của bạn, không phải là một tuyên bố về bao bọc phản hồi gốc của dịch vụ.

Một khóa tài khoản là cần thiết cho việc thu thập trực tiếp, điều này không được thực hiện cho bài viết này. Việc hoàn thành nhiệm vụ đang chờ cũng cần một quy trình làm việc được xác minh riêng. Trình kiểm tra địa phương chạy mà không cần thông tin xác thực trên các bản ghi đã lưu, với các đầu vào tổng hợp được sử dụng để kiểm tra các quy tắc của nó.

Stage 3 — Preserve History and Build Derived Tables

Các bản chụp thô nên giữ nguyên sau khi được chấp nhận vào kho lưu trữ. Một phản hồi sau đó hoặc một trình phân tích đã chỉnh sửa nên tạo ra một bản ghi hoặc phiên bản dự đoán mới thay vì ghi đè lên bằng chứng đứng sau một báo cáo trước đó.

Một mô hình quan hệ có thể sử dụng một bảng chạy cộng với các hàng kết quả hữu cơ con được khóa bằng định danh cuộc chạy và thứ tự nguồn. Vị trí được trả về vẫn là một thuộc tính riêng biệt. Các quy tắc khóa ngoại của SQLite mô tả cách mà các bản ghi liên quan có thể bị ràng buộc khi tùy chọn lưu trữ đó được sử dụng.
Gắn bó một lần thực hiện và các hàng được derivated của nó khi mô hình cơ sở dữ liệu yêu cầu chúng phải giữ nguyên tính nhất quán. Mô hình giao dịch cung cấp hành vi cơ sở dữ liệu liên quan. Ứng dụng thu thập của bạn vẫn phải định nghĩa cách xử lý xung đột, cấu hình kết nối và ranh giới của từng giao dịch.

Giữ giá trị kết quả khác thường trong JSON gốc ngay cả khi một cột tiện ích không thể đại diện cho chúng. Điều đó cho phép một trình ánh xạ tương lai khôi phục chi tiết mà không cần phải thu thập lại một tìm kiếm mà đầu ra của nó có thể đã thay đổi.

Bắt đầu thu thập với Scrapeless

Nâng cao quy trình thu thập và tự động hóa của bạn với Scrapeless!
Đăng ký ngay hôm nay và nhận 5 đô la tín dụng miễn phí — không cần thẻ tín dụng.

Nhận tín dụng miễn phí của bạn ngay bây giờ trong Bảng điều khiển Scrapeless.

Giai đoạn 4 — Áp dụng Hợp đồng Chất lượng Rõ ràng

Các kiểm tra chất lượng nên trả lời một câu hỏi cụ thể cho báo cáo. Ví dụ kiểm tra xem một bản thu thập có phù hợp cho một báo cáo vị trí bảo thủ hay không: xác định lần chạy, cấu trúc yêu cầu, sự hiện diện của thời gian nhận, hình dạng thùng chứa hữu cơ, chuỗi liên kết, vị trí số nguyên dương, và liên kết trùng lặp chính xác.

Trình kiểm tra ghi lại trạng thái thu thập độc lập với ghi chú. Một mảng hữu cơ hiện tại có thể ở observed trong khi không đủ điều kiện báo cáo vị trí vì một vị trí đang thiếu. Điều này tách biệt những gì đã được thu thập khỏi những gì một báo cáo cụ thể có thể sử dụng một cách an toàn.

Các dấu thời gian bị thiếu được đánh dấu, nhưng mã không xác thực cú pháp hoặc độ gần gũi của dấu thời gian. Các kiểm tra liên kết thiết lập chuỗi không rỗng, không có điểm đến có thể tới được hoặc đáng tin cậy. Sự tương đương ngữ cảnh, độ phủ phạm vi ngày tháng, và tính duy nhất của ID lần chạy giữa các tệp cũng cần các kiểm tra riêng trong quy trình xung quanh.

Mô hình giá trị JSON là nền tảng cho sự phân biệt giữa các mảng, đối tượng, null và giản đồ. Đừng ép một container không được hỗ trợ thành một mảng rỗng chỉ để làm cho báo cáo chất lượng thành công.

Giai đoạn 5 — Chạy Trình Kiểm Tra Thu Thập Địa Phương

Lưu chương trình này dưới dạng quality_check.py. Nó chỉ cần Python và các tệp thu thập. Chạy python3 quality_check.py capture-a.json capture-b.json với tên tệp đã lưu thực tế; chương trình in JSON ra đầu ra tiêu chuẩn và không thay đổi đầu vào của nó.

import argparse
import json
from collections import Counter
from pathlib import Path


def inspect(record):
    notes = []
    if not isinstance(record, dict):
        return {'state': 'invalid_capture', 'notes': ['capture_not_object'], 'rows': None, 'eligible_for_position_report': False}
    request = record.get('request')
    if not isinstance(record.get('run_id'), str) or not record['run_id'].strip():
        notes.append('run_id_missing')
    if (not isinstance(request, dict) or request.get('actor') != 'scraper.google.search'
            or not isinstance(request.get('input'), dict)):
        notes.append('request_contract_invalid')
    if not isinstance(record.get('received_at'), str) or not record['received_at'].strip():
        notes.append('receipt_time_missing')
    status, payload = record.get('http_status'), record.get('response')
    rows = payload.get('organic_results') if isinstance(payload, dict) else None
    count = None
    if status == 201:
        state = 'pending'
        if not isinstance(payload, dict) or not isinstance(payload.get('taskId'), str) or not payload['taskId'].strip():
            notes.append('task_id_missing')
    elif status is None:
        state = 'transport_error'
    elif status != 200:
        state = 'http_error'
    elif not isinstance(rows, list) or any(not isinstance(row, dict) for row in rows):
        state = 'unmapped'
    else:
        state, count = ('observed' if rows else 'empty'), len(rows)
        links = []
        for ordinal, row in enumerate(rows):
            link, position = row.get('link'), row.get('position')
            if not isinstance(link, str) or not link.strip():
                notes.append(f'row_{ordinal}_link_missing_or_invalid')
            else:
                links.append(link)
            if type(position) is not int or position < 1:
                notes.append(f'row_{ordinal}_position_missing_or_invalid')
        if len(links) != len(set(links)):
            notes.append('duplicate_exact_links')
    return {'run_id': record.get('run_id'), 'state': state, 'rows': count,
            'notes': notes, 'eligible_for_position_report': state in ('observed', 'empty') and not notes}


if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('captures', nargs='+')
    args = parser.parse_args()
    reports = []
    for filename in args.captures:
        try:
            report = inspect(json.loads(Path(filename).read_text(encoding='utf-8')))
        except (OSError, json.JSONDecodeError, UnicodeError) as error:
            report = {'state': 'unreadable_capture', 'rows': None, 'notes': [type(error).__name__],
                      'eligible_for_position_report': False}
        reports.append(dict(report, source=filename))
    print(json.dumps({'captures': reports, 'states': dict(Counter(x['state'] for x in reports))},
                     ensure_ascii=False, indent=2))

Cờ eligible_for_position_report là một quyết định ứng dụng. Các bản thu thập đang chờ xử lý hoặc không thành công vẫn nằm trong báo cáo với số hàng không xác định; các mảng rỗng hiện tại có thể đủ điều kiện nếu siêu dữ liệu thu thập của chúng vượt qua các kiểm tra. Một bản thu thập bị lỗi hoặc không thể đọc vẫn là một kết quả chất lượng rõ ràng.

Một danh sách notes rỗng không xác lập chất lượng dữ liệu toàn cầu. Nó có nghĩa là tập kiểm tra cụ thể này không tìm thấy vấn đề nào. Giữ phiên bản trình kiểm tra cùng với đầu ra của nó và duy trì các bài kiểm tra rộng hơn mà báo cáo tiêu thụ yêu cầu.

Giai đoạn 6 — Tách Biệt Phạm Vi Từ Kết Quả Tìm Kiếm

Phạm vi hoạt động nên so sánh các công việc dự kiến với kết quả của chúng. Phân tích tìm kiếm chỉ nên sử dụng các bản ghi đáp ứng các điều kiện đủ điều kiện của chính nó. Một bảng kết quả đơn thuần không thể tiết lộ các công việc đã được lên kế hoạch mà chưa bao giờ tạo ra phản hồi sử dụng được.

Đếm trạng thái báo cáo trước khi diễn giải các thay đổi trong vị trí hoặc sự hiện diện của miền. Các lần chạy đang chờ xử lý và chưa được ánh xạ cần sự chú ý từ chủ sở hữu thu thập hoặc ánh xạ. Chúng không nên xuất hiện như sự biến mất đột ngột của mọi miền trong một thị trường.

Một đánh giá dữ liệu có thể dẫn đến một trình ánh xạ đã được sửa, một phạm vi báo cáo hẹp hơn, hoặc một quan sát chưa được giải quyết. Bảo tồn quyết định đó với bằng chứng và phiên bản đã tạo ra nó. Mô hình nguồn gốc giúp phân biệt hoạt động thu thập, biến đổi và xem xét.

Kết luận

Xây dựng quy trình xung quanh các quan sát có thể theo dõi. Giữ công việc đã lên kế hoạch, phản hồi gốc, các hàng derivated và quyết định chất lượng có kết nối trong khi vẫn bảo tồn các vai trò khác nhau của chúng. Một báo cáo sau đó có thể giải thích cả những gì mẫu tìm kiếm đã cho thấy và những bộ phận nào của việc thu thập đã được lên kế hoạch mà không có sẵn.

Kỷ luật bằng chứng được sử dụng trong khám phá nguồn AI cũng rất hữu ích khi một quy trình cung cấp cho trợ lý nghiên cứu: một quá trình biến đổi dữ liệu thành công không thay thế việc xem xét nguồn.

Xây dựng Quan sát Tìm Kiếm Tiếp theo của Bạn

Sử dụng Scrapeless Google Search API cho dữ liệu tìm kiếm trong quy trình này. Xem xét Scrapeless pricing khi lên kế hoạch thu thập, và giữ các Google Search parameters bên cạnh cấu hình của bạn.

Thảo luận về việc thực hiện của bạn với cộng đồng trên Discord hoặc Telegram.

FAQ

Q: Google Search API có cung cấp lưu trữ và lập lịch như được hiển thị ở đây không?

Không. Bài viết này mô tả các thành phần ứng dụng xung quanh API. Bạn thực hiện lập lịch, lưu trữ và báo cáo chất lượng cho quy trình của riêng bạn.

Q: Tại sao phải lưu một lần chạy mà không có hàng kết quả?

Trạng thái của nó giải thích liệu phản hồi có trống, đang chờ, thất bại, hoặc không ánh xạ. Việc bỏ qua lần chạy sẽ che giấu phạm vi thu thập.

Q: Một bản ghi đủ điều kiện có đảm bảo thứ hạng chính xác không?

Không. Sự đủ điều kiện có nghĩa là các kiểm tra báo cáo vị trí địa phương đã vượt qua. Sự so sánh, phạm vi, độ tươi mới và cách diễn giải cần có sự xem xét thêm.

Q: Có nên ghi đè lịch sử thô với một bộ phân tích đã thay đổi không?

Không. Giữ lại các bản ghi thô và tạo một hình chiếu có phiên bản để các kết luận trước đó vẫn có thể theo dõi.

Q: Kiểm tra có xác thực từng URL và dấu thời gian không?

Không. Nó kiểm tra các giá trị không trống và các loại đã chọn. Kiểm tra điểm đến, phân tích dấu thời gian và phân tích phạm vi thuộc về các quy tắc đường ống bổ sung.