Crawlee là gì?

Scrapeless Agent Browser cung cấp môi trường thực thi trình duyệt được quản lý cho các khách hàng tự động hóa cần render và tương tác với các trang web động.

Crawlee là một framework mã nguồn mở cho web crawling và scraping với các bản triển khai bằng JavaScript và Python. Crawlee tổ chức công việc xoay quanh các yêu cầu (request), handler của crawler, tài nguyên thực thi và lưu trữ kết quả. Một framework điều phối trang nào được xử lý và cách lưu bản ghi; nó khác với engine trình duyệt dùng để render trang hoặc dịch vụ lưu trữ trình duyệt.

Sự phân biệt đó trở nên giá trị khi một script một trang phát triển thành một quá trình thu thập. Thách thức không còn chỉ là đọc một phần tử. Bạn cần một danh sách công việc có giới hạn, cách để khám phá URL bổ sung, quy tắc rõ ràng cho các yêu cầu trùng lặp, và một định dạng bản ghi vẫn hữu ích sau khi trình duyệt đóng lại. Crawlee cung cấp các thành phần cho những công việc đó, trong khi ứng dụng của bạn định nghĩa mục đích thu thập và kết quả chấp nhận được.

Những gì Crawlee bổ sung cho một script trang

Crawlee bổ sung lớp điều phối xung quanh mã dùng để lấy trang và trích xuất dữ liệu. Framework Crawlee crawling framework phơi bày khả năng thu thập HTTP và trình duyệt, lưu trữ request, lưu trữ kết quả, thực thi theo tài nguyên, và tùy biến vòng đời.

Một script trang thông thường bắt đầu với một URL và kết thúc với vài quan sát. Một crawler còn cần theo dõi frontier của nó: phần công việc đã được khám phá nhưng chưa hoàn thành. Frontier đó có thể mở rộng khi một handler tìm thấy các trang danh mục, trang chi tiết hoặc liên kết phân trang. Một hàng đợi yêu cầu bền vững khiến công việc trở nên hiển thị thay vì ẩn trong một tập hợp tab trình duyệt ngày càng tăng.

Các handler vẫn là mã ứng dụng. Một framework không thể quyết định liệu một mức giá đã bao gồm thuế hay chưa, liệu một tiêu đề thuộc về sản phẩm hiện tại hay không, hoặc liệu một danh sách trống nghĩa là “không có kết quả”. Hãy định nghĩa rõ những phân biệt đó. Một crawler xử lý mọi URL trong hàng đợi vẫn có thể tạo ra tập dữ liệu không dùng được nếu các handler của nó chấp nhận bản ghi không đầy đủ hoặc không khớp.

Crawler HTTP và crawler trình duyệt giải quyết những vấn đề khác nhau

Một crawler HTTP lấy các phản hồi để phân tích cú pháp, trong khi một crawler trình duyệt có thể thực thi script trên trang và tương tác với tài liệu đã render. Lựa chọn phù hợp phụ thuộc vào thời điểm nội dung cần thiết trở nên sẵn có.

Nếu văn bản của một bài viết công khai đã có trong HTML được tải xuống, phân tích phản hồi đó có thể là đủ. Khởi chạy một trình duyệt đầy đủ sẽ thêm chi phí thời gian chạy mà không nhất thiết thêm thông tin. Nếu một trang xây dựng nội dung hữu ích sau khi thực thi JavaScript, có thể cần dùng đường đi qua trình duyệt. Một bộ lọc tương tác hoặc điều khiển phân trang phía client có thể khiến sự khác biệt đó trở nên rõ ràng.

Đừng chỉ quyết định từ giao diện của trang. Một trang có giao diện phức tạp có thể đã bao gồm bản ghi trong phản hồi ban đầu, trong khi một giao diện đơn giản có thể nạp mọi thứ về sau. Hãy kiểm tra phản hồi thực tế và trạng thái đã render cho các trường mà tác vụ yêu cầu.

Một trình duyệt cũng thay đổi cách địa chỉ hóa tài liệu. Một widget giá bên trong một frame nhúng không chỉ là một node sâu hơn trong tài liệu cha. Mô hình tài liệu HTML và bối cảnh duyệt giải thích lý do tại sao crawler phải xác định tài liệu chứa mục tiêu của nó trước khi trích xuất từ đó.

Danh tính của request quyết định những gì được xử lý

Danh tính của request quyết định liệu hai liên kết được phát hiện có đại diện cho cùng một đơn vị công việc thu thập hay không. Khử trùng lặp URL chỉ hữu ích khi quy tắc nhận dạng phù hợp với ứng dụng.

Một tham số tracking có thể không làm thay đổi trang sản phẩm, trong khi tham số ngôn ngữ hoặc phân trang có thể chọn nội dung khác. Xóa mọi query string có thể làm gộp các kết quả riêng biệt. Giữ mọi tham số có thể tạo ra công việc lặp lại. Hãy định nghĩa những thành phần URL nào mang ý nghĩa đối với mục tiêu, và kiểm thử quy tắc đó với các liên kết tiêu biểu.

Danh tính của request cũng khác với danh tính của bản ghi. Một trang danh mục có thể chứa nhiều sản phẩm; một sản phẩm có thể xuất hiện trên nhiều trang danh mục. Khử trùng lặp các request trang tự nó không thể đảm bảo tập dữ liệu chỉ có một bản ghi mỗi sản phẩm.

Hãy giữ lại một định danh bản ghi ổn định khi nguồn cung cấp, cùng với URL nguồn và ngữ cảnh thu thập liên quan. Nếu nguồn thiếu một định danh đáng tin cậy, hãy ghi lại quy tắc so khớp được dùng ở các bước xử lý sau. Một quy tắc bình đẳng được đoán có thể âm thầm gộp các biến thể khác nhau hoặc các sản phẩm khác nhau có tiêu đề giống nhau.

Một ví dụ thiết kế thu thập danh mục có giới hạn

Một quá trình thu thập danh mục có giới hạn bắt đầu với các URL hạt giống đã được phê duyệt và chỉ chấp nhận các liên kết thuộc về danh mục dự định. Đây là một ví dụ thiết kế mang tính khái niệm, không phải một lần thực thi được báo cáo hay công thức mã cụ thể cho một package.

Bắt đầu bằng cách tách trang khám phá khỏi trang chi tiết. Một handler danh mục xác định các liên kết chi tiết đủ điều kiện và đường phân trang. Một handler chi tiết trích xuất các trường thuộc về một mục. Sự tách biệt đó khiến phạm vi và mức độ hoàn thành dễ kiểm tra hơn so với một handler duy nhất coi mọi trang đều như nhau.

Hãy chỉ định các quy tắc host và path trước khi thêm các liên kết được phát hiện vào hàng đợi. Một menu điều hướng có thể chứa các trang tài khoản, quảng cáo bên ngoài, và các phần không liên quan. Đi theo mọi thẻ anchor sẽ thay đổi phạm vi công việc mà không có quyết định tương ứng từ người vận hành.

Hãy định nghĩa hoàn thành theo góc nhìn tập dữ liệu. Một bản ghi sản phẩm có thể yêu cầu một định danh ổn định và tiêu đề, với một trường trạng thái sẵn có có thể để rỗng. Thiếu các trường bắt buộc nên tạo ra một kết quả không hoàn chỉnh riêng biệt. Một danh mục trống có thể là hợp lệ, nhưng chỉ khi trang thực sự đại diện cho danh mục dự định và hiển thị trạng thái trống đã hoàn tất.

Lưu trữ phải phù hợp với cấu trúc của kết quả

Crawlee phân biệt công việc trong hàng đợi với đầu ra đã lưu trữ, vì vậy một lần crawl có thể tổ chức việc thực thi và kết quả một cách độc lập. Hãy chọn kiểu lưu trữ dựa trên cách ứng dụng phía sau sẽ đọc dữ liệu.

Dataset phù hợp với một tập hợp bản ghi. Key-value store phù hợp với các giá trị hoặc artifact có tên. Việc chọn kiểu lưu trữ không xác định tính đúng đắn của một bản ghi. Hãy thiết lập một schema bao gồm tên trường, giá trị có thể rỗng, chuẩn hóa văn bản và ngữ cảnh nguồn cần thiết để diễn giải kết quả.

Ví dụ, một giá hiển thị không kèm đơn vị tiền tệ có thể gây mơ hồ. Trạng thái tồn kho không gắn với một vị trí cụ thể có thể gây hiểu lầm. Một bản ghi có thể là JSON hợp lệ về mặt cấu trúc nhưng vẫn thiếu ngữ cảnh cần thiết cho quyết định kinh doanh. Hãy giữ lại các đầu vào đó thay vì cố gắng tái dựng chúng sau này.

Hãy xử lý artifact tách biệt với các bản ghi thông thường. Ảnh chụp màn hình có thể giải thích một trường bị thiếu, nhưng chúng cũng có thể ghi lại thông tin trang không liên quan. Chỉ lưu trữ khi cần, bảo vệ quyền truy cập và sử dụng chính sách lưu giữ phù hợp với nhiệm vụ. Một artifact chẩn đoán nên có mối quan hệ rõ ràng với yêu cầu hoặc bản ghi mà nó giải thích.

Phiên (session) là một đầu vào của lần crawl

Session ảnh hưởng đến những gì crawler nhìn thấy, ngay cả khi URL mục tiêu không đổi. Cookie, trạng thái tài khoản, tùy chọn ngôn ngữ và bộ nhớ trình duyệt có thể thay đổi trang trả về hoặc ứng dụng được render.

Cơ chế HTTP cookie giải thích một cách mà máy chủ liên kết các request với trạng thái trình duyệt đã lưu. Bộ nhớ trình duyệt có thêm các quy tắc khác: Sự cô lập và vòng đời của Web Storage phân biệt dữ liệu theo origin với session storage gắn với tab.

Hãy dùng trạng thái sạch cho các quy trình làm việc cần độc lập. Chỉ tái sử dụng trạng thái đã được cấp quyền khi tính liên tục là một yêu cầu được nêu rõ. Việc chia sẻ một hồ sơ trình duyệt có thể thay đổi giữa các công việc không liên quan có thể khiến đầu ra của một tác vụ phụ thuộc vào việc một tác vụ khác đã nhấp vào gì trước đó.

Các chức năng session của framework, context của trình duyệt, session của website và việc cấp phát trình duyệt từ xa không nên bị coi là có thể hoán đổi cho nhau. Hãy mô tả thành phần nào sở hữu mỗi ranh giới. Điều đó giúp xác định xem một lỗi liên quan đến xử lý hàng đợi, khả dụng của trình duyệt, xác thực website hay trạng thái trang đã thay đổi.

Cách đánh giá một dự án Crawlee

Hãy đánh giá Crawlee bằng khối lượng công việc nó tổ chức và bằng bằng chứng trong dataset kết quả. Một lần crawl mẫu nhỏ nhưng đại diện hữu ích hơn là chỉ đếm có bao nhiêu URL được đưa vào hàng đợi.

Ngoài ra hãy kiểm thử một trang thiếu dữ liệu tùy chọn và một trang nằm ngoài phạm vi đã chấp nhận. Các trường hợp này cho thấy handler có đang thực thi đúng chính sách dự định hay không. Giữ cho các kết quả lỗi hiển thị trong tóm tắt job thay vì coi việc không có bản ghi là bằng chứng rằng không tìm thấy gì.

Vị trí của Scrapeless trong kiến trúc này

Scrapeless Agent Browser thuộc lớp thực thi trình duyệt, trong khi Crawlee thuộc phần điều phối crawl. Kết nối Agent Browser Puppeteer mô tả một bề mặt client được hỗ trợ; nó không nên được hiểu là bằng chứng rằng mọi cấu hình browser-pool tùy ý của Crawlee đều hoạt động mà không cần thay đổi.

Nền tảng Agent Browser có liên quan khi một quy trình làm việc cần thực thi trang động được quản lý. Một thảo luận liên quan về Crawlee cho Python và thiết kế crawl có thể giúp định hình các lựa chọn điều phối. Hãy kiểm tra tài liệu theo ngôn ngữ trước khi chuyển các khái niệm thành method hoặc cấu hình.

Hãy đánh giá giá của Scrapeless so với khối lượng công việc trình duyệt còn lại sau khi đã chọn con đường truy xuất đơn giản nhưng đủ dùng. Định nghĩa này không khẳng định rằng một tích hợp Crawlee–Scrapeless đã được thực hiện hoặc benchmark.

Kết luận

Crawlee biến một tập các thao tác trên trang thành một lần crawl có tổ chức. Hãy bắt đầu với phạm vi request, chọn thực thi HTTP hay trình duyệt xoay quanh nội dung cần thiết, và định nghĩa bản ghi tách biệt với các request trang. Một lần crawl hữu ích kết thúc với dữ liệu có thể giải thích được và các kết quả chưa hoàn chỉnh có thể nhìn thấy, thay vì chỉ là một hàng đợi đã cạn kiệt.