Việc chọn crawler mã nguồn mở sẽ dễ hơn khi tách hệ thống thành bốn vai trò: crawling tổng quát, tự động hóa trình duyệt, lập lịch và hàng đợi, cùng phân tích và lưu trữ. Bài viết giải thích từng vai trò, lỗi tích hợp thường gặp và bốn tiêu chí thực tế.
Tìm crawler trên GitHub có thể cho ra hàng trăm, thậm chí hàng nghìn kho mã. Nhiều người chọn dự án bằng cách nhìn số sao rồi dùng ngay dự án phổ biến nhất.
Độ phổ biến và mức độ phù hợp với nhu cầu là hai chuyện khác nhau. Một dự án dù rất nổi tiếng vẫn có thể khiến công việc nặng hơn nếu mục tiêu của nó không khớp với tình huống thực tế. Cách bắt đầu đơn giản hơn là tách rõ trách nhiệm: một hệ thống thu thập dữ liệu cần chạy ổn định lâu dài vốn thường được ghép từ nhiều thành phần có nhiệm vụ khác nhau. Khi hiểu từng phần làm gì, việc so sánh các triển khai cụ thể sẽ dễ hơn nhiều.
Framework crawler tổng quát: dành cho trang có cấu trúc ổn định
Loại framework này quản lý lịch gửi yêu cầu, thu thập đồng thời và pipeline dữ liệu. Đầu vào là một tập URL, đầu ra là kết quả có cấu trúc. Hệ sinh thái trưởng thành và cơ chế middleware cho phép chèn logic riêng, đồng thời hỗ trợ các tác vụ quy mô lớn chạy lâu dài.
Chúng không tự xử lý được những trang chỉ xuất hiện nội dung sau khi JavaScript render. Trong trường hợp đó, phản hồi ban đầu chỉ là một vỏ rỗng và cần gắn thêm engine render. Chúng phù hợp với các mục tiêu có cấu trúc ổn định như trang danh sách, trang chi tiết và API mở.
Tự động hóa trình duyệt: dành cho render và tương tác
Những trang cần render thực, cần trạng thái đã đăng nhập hoặc phải bấm vài lần mới hiện nội dung nên được giao cho tự động hóa trình duyệt. Các công cụ này có thể chạy trên nhiều engine, có cơ chế chờ khá hoàn thiện và cho phép trực tiếp kiểm soát request cũng như response của trang.
Đổi lại, mức tiêu thụ tài nguyên cao hơn nhiều so với yêu cầu HTTP thuần. Giới hạn đồng thời chủ yếu phụ thuộc vào bộ nhớ và CPU của máy. Tự động hóa cũng để lại các đặc trưng có thể nhận biết, nên những trang kiểm tra nghiêm ngặt có thể phát hiện.
Lập lịch và hàng đợi: cần khi số lượng tác vụ tăng
Nếu chỉ có ít mục tiêu, một vòng lặp có thể đủ. Khi tác vụ lên đến hàng nghìn và còn phải kiểm soát tần suất lẫn retry, cần một lớp lập lịch riêng: xếp hàng thế nào, cho phép bao nhiêu tác vụ chạy đồng thời, sau lỗi thì đợi bao lâu trước khi thử lại, và tác vụ nào nên bỏ. Nhét toàn bộ logic này vào framework crawler sẽ khiến mã ngày càng khó bảo trì.
Một lỗi phổ biến khi tự xây lớp này là dùng hàng đợi chỉ nằm trong bộ nhớ tiến trình. Khi tiến trình khởi động lại, mọi tác vụ đang chờ sẽ biến mất. Tối thiểu hàng đợi phải bền vững và cho phép tra cứu trạng thái.
Phân tích và lưu trữ: quyết định dữ liệu có dùng ngay được hay không
Thứ lấy về là HTML, nhưng thứ cần dùng là các trường dữ liệu. Lớp phân tích phải quản lý quy tắc trích xuất, xác thực trường, loại trùng lặp và ghi vào kho lưu trữ. Với những site thường xuyên đổi cấu trúc, có thể xem xét cách trích xuất thích nghi dựa trên đặc điểm trang thay vì selector cố định để giảm công bảo trì.
Ở phía lưu trữ, cần chú ý tính idempotent. Retry là chuyện bình thường, vì vậy dữ liệu ghi vào phải được khử trùng theo định danh duy nhất; nếu không, bản ghi trùng sẽ làm sai lệch phân tích phía sau.
Những vấn đề thường xuất hiện sau khi ghép các phần lại
Mỗi thành phần riêng lẻ không quá khó. Vấn đề thường nằm ở chỗ nối giữa chúng.
- Lớp lập lịch retry nhưng lớp phân tích không khử trùng, tạo ra các dòng lặp
- Lớp trình duyệt không có giới hạn đồng thời, dùng cạn tài nguyên máy và làm cả lô tác vụ cùng lỗi
- Quy tắc phân tích bị viết cứng trong mã, nên mỗi lần site thay đổi lại phải phát hành phiên bản mới
- Các thành phần không dùng cùng một định danh cho tác vụ, trạng thái không khớp và không thể tiếp tục từ checkpoint
Bốn tiêu chí đánh giá
Sau khi xác định loại công cụ cần thiết, hãy dùng bốn tiêu chí này để lọc dự án cụ thể.
Với mức độ bảo trì, hãy xem tần suất commit và tốc độ phản hồi issue trong vài tháng gần đây thay vì tổng số sao. Một dự án đã ngừng bảo trì có thể mất tác dụng ngay khi site mục tiêu thay đổi.
Tài liệu và ví dụ quyết định chi phí làm quen. Nếu tài liệu mơ hồ hoặc chỉ có ví dụ đơn giản nhất, thời gian học thường vượt quá dự kiến.
Với khả năng mở rộng, hãy xem dự án để lại những điểm tích hợp nào: có thể thay proxy, nối engine render riêng hoặc thay lớp lưu trữ không? Dự án có điểm mở rộng rõ ràng sẽ dễ sửa đổi về sau mà không cần đụng vào mã nguồn.
Rủi ro về giấy phép và tuân thủ rất dễ bị bỏ qua. Trước khi dùng thương mại, hãy xác nhận loại giấy phép và tránh giấy phép không phù hợp với mục đích sử dụng. Đồng thời cần đánh giá phạm vi thu thập, tần suất yêu cầu và điều khoản của site mục tiêu; các vấn đề này độc lập với chất lượng kỹ thuật của framework.
Lớp môi trường là một cấp độ khác
Framework giải quyết cách thu thập dữ liệu, không giải quyết danh tính và quy mô. Khi tác vụ cần đăng nhập, tách theo khu vực hoặc chạy nhiều tài khoản song song, việc dùng chung một môi trường trình duyệt gây ra hai vấn đề: các phiên làm việc ảnh hưởng lẫn nhau vì cookie và local storage chồng chéo; site mục tiêu cũng có thể coi những tác vụ không liên quan là cùng một nhóm truy cập.
Cách làm trưởng thành hơn là biến môi trường trình duyệt thành một lớp tài nguyên độc lập. Tác vụ xin một môi trường từ pool và trả lại sau khi dùng. Trong kiểu kiến trúc này, PurpleMark đảm nhiệm lớp đó, cung cấp tài nguyên môi trường có thể tạo hàng loạt, gắn với lối ra mạng độc lập và tra cứu trạng thái.
Ranh giới tuân thủ
Hãy tuân thủ quy tắc robots và điều khoản dịch vụ của site mục tiêu, không thu thập thông tin cá nhân, không vượt qua biện pháp bảo vệ kỹ thuật và kiểm soát tần suất yêu cầu để không ảnh hưởng hoạt động bình thường của dịch vụ. Chọn dự án giải quyết bài toán hiệu quả; những đánh giá này quyết định việc thu thập có nên được thực hiện hay không.
