Phoenix — Tinder's Testing Platform, Part III (Metrics System)

Tinder · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 3/3 của series Phoenix (bài trong sheet). Phần 1: Tinder 2019; phần 2: Tinder 2019. Đọc qua trình duyệt, raw/ chỉ là placeholder.

Bối cảnh

• Sản phẩm rộng và đổi nhanh, mỗi thành phần hành xử khác nhau theo vùng; muốn biết "sức khoẻ" cần nhiều chiều metric, và muốn tiến hoá nhanh thì phải thử nhiều và nhanh.
• Công cụ phân tích thí nghiệm quen dùng là Redshift.

Thay đổi chính

• Hạ rào thêm metric: metric mới chỉ cần là một rollup viết bằng truy vấn Redshift theo hợp đồng cơ bản; pipeline tự đưa nó tới trang kết quả.
• Chống hệ quả của nhiều metric: nhiều metric dẫn tới chọn lọc kết quả theo định kiến; xử lý bằng hiệu chỉnh so sánh bội trong hệ thống cộng với hướng dẫn quy trình (khai báo trước 2–3 metric thành công trong giả thuyết).
• Thông lượng thí nghiệm: experiment family cho user ở nhiều thí nghiệm song song; phía tính toán gom các metric giống nhau về ngữ nghĩa để xử lý theo lô metric (thay vì theo từng thí nghiệm hay từng metric).
• Pipeline batch Spark hằng ngày trên EMR on-demand, chia ba khối để dễ checkpoint và bảo trì: gán thí nghiệm (giải các loại định danh), metric (từ S3 và Redshift), tổng hợp/thống kê. Hơn 80 job Spark trong DAG; riêng khối gán thí nghiệm tăng từ 2 lên 25 job vì phải hỗ trợ pre-auth/post-auth và loại bot (bản đầu không có).
• Lưu trữ chính trên S3, nhập metric từ Redshift sang S3; kết quả xuất sang RDS để phục vụ UI. Điều phối bằng Fireflow (Airflow + lớp service tích hợp EMR, S3, MySQL, Redshift). Theo dõi phân bổ realtime bằng Grafana.
• Kết quả: chuỗi thời gian (xu hướng dài như holdout), thống kê phân bổ (bắt lỗi cấu hình sớm), thống kê tổng hợp (lift, mean, ý nghĩa thống kê so với biến thể tham chiếu chọn được, lọc và chia theo nhóm để thấy hiệu ứng không đồng nhất).
• Bất biến nhúng vào hệ thống so với quy trình: chỉ tô màu ý nghĩa thống kê sau 2 tuần kể từ khi bắt đầu (chống "nhìn trộm" và hiệu ứng mới lạ); số metric thành công thì để ở quy trình vì có thí nghiệm chỉ để học.

Vì sao

• Theo Tinder: làm cho dễ dùng đúng và khó dùng sai; bất biến nào rẻ thì nhúng vào hệ thống, bất biến đắt (hiệu chỉnh peeking đầy đủ) thì tạm để quy trình lo.
• Ví dụ của Kohavi (quảng cáo Bing có CTR khác nhau theo hệ điều hành hoá ra do cách đo click khác nhau) cho thấy phải đo theo nhóm trước khi kể chuyện.

Bài học cho SWE

• Pipeline dữ liệu phục vụ ra quyết định cần cả bất biến kỹ thuật (hợp đồng metric, kiểm phân bổ realtime) lẫn bất biến thống kê (thời gian tối thiểu, hiệu chỉnh so sánh bội).
• Thành phần "định danh và phân bổ" là nơi độ phức tạp tích tụ theo thời gian (2 → 25 job); tách khối riêng để checkpoint.

Liên quan

• Thử nghiệm A/B và nền tảng experimentation
• Tinder 2019 · Tinder 2019 · Shopify 2022 · Twitter 2022
• Pipeline dữ liệu và analytics