Giám sát người theo dõi Twitter/X ở quy mô lớn

Thách thức

Theo dõi số người theo dõi hằng ngày của 30.000 hồ sơ Twitter/X, trên một nền tảng thường khóa tài khoản, dựng CAPTCHA và giới hạn tần suất đọc tự động.

Bối cảnh

Số người theo dõi là thông tin công khai nhưng chỉ xem được từng hồ sơ một, và nền tảng chặn việc đọc tự động bằng cách khóa tài khoản, dựng CAPTCHA và giới hạn tần suất. Theo dõi 30.000 hồ sơ mỗi ngày nghĩa là bộ thu thập phải tiếp tục chạy qua cả ba trở ngại đó.

Chúng tôi đã xây gì

Multiprocessing của Python chia danh sách hồ sơ cho các tài khoản đã xác thực. Sau khi thiết lập, mỗi tài khoản tái sử dụng cookie đã lưu, và phiên đăng nhập được kiểm tra trước khi dùng. Các worker đọc số người theo dõi từ JSON-LD của từng hồ sơ, ghi nhật ký kiểm tra cho mỗi phiên của từng tài khoản và tự phục hồi khi bị khóa, bị giới hạn tần suất hay gặp CAPTCHA; thư viện schedule chạy job mỗi ngày và các bản chụp được hợp nhất ở cuối. Mỗi lượt chạy được chia thành 43 shard chạy song song, có thể chạy tiếp.

Điều gì thay đổi

Khách hàng nhận bản chụp hằng ngày của hơn 30.000 hồ sơ, kèm nhật ký kiểm tra cho từng tài khoản và từng phiên. Khi Van Data Team dựng dashboard trên trang này từ các file đã bàn giao, các shard chứa 1.275.858 dòng thô, loại trùng còn 39.168 hồ sơ riêng biệt; 19.949 hồ sơ trong số đó (51%) trả về số liệu thực, cộng lại được 2,28 tỷ người theo dõi, với tài khoản trung vị có 334 người theo dõi.

Ràng buộc và quyết định

Hai quy tắc giữ cho số liệu trung thực. Các shard chạy lặp lại cùng một khoảng ID thay vì chia nhỏ khoảng đó, nên con số được nêu là con số sau khi loại trùng, không bao giờ là số dòng thô. 19.219 hồ sơ không trả về gì (đã xóa, bị khóa hoặc riêng tư lúc thu thập) vẫn được tính, không bị loại bỏ. Mức phân tán cũng cho thấy vì sao phải dùng trung vị: hệ số Gini 0,993, 1% tài khoản đứng đầu nắm 96% tổng số người theo dõi, nên giá trị trung bình sẽ phóng đại tài khoản điển hình lên 343 lần.

Nền tảng công nghệ

PythonmultiprocessingSeleniumscheduleJSON-LD