Nguyên tắc là không đụng vào tải của DB production, giữ lại bản thô để xử lý lại được, và mỗi bước chạy lại không sinh trùng.
MySQL (read replica)
-> extract (CDC hoặc incremental theo updated_at)
-> raw zone trên S3/GCS, Parquet, chia partition theo ngày
-> transform: dedup, làm sạch, join dimension
-> warehouse: fact_orders, dim_customer, dim_product
-> bảng tổng hợp doanh thu cho dashboard
Airflow điều phối, data quality check giữa các bướcCác quyết định cần nói rõ:
- Cách lấy dữ liệu: query theo updated_at trên read replica là đơn giản nhất, nhưng không bắt được bản ghi bị xoá cứng và phụ thuộc cột này luôn được cập nhật. CDC (Debezium đọc binlog) bắt được cả insert/update/delete, đổi lại phải vận hành thêm Kafka.
- Tần suất: báo cáo theo ngày thì batch mỗi đêm là đủ. Chỉ chuyển sang streaming khi nghiệp vụ thật sự cần số theo phút.
- Chạy lại an toàn: mỗi lần chạy ghi đè đúng partition ngày của nó thay vì append.
- Dữ liệu đến trễ: đơn đổi trạng thái sau vài ngày (hoàn tiền, huỷ) → mỗi lần chạy xử lý lại 2–3 ngày gần nhất.
- Kiểm tra chất lượng: so số dòng nguồn với đích, kiểm tra khoá không null, không trùng; lỗi thì dừng và cảnh báo trước khi dashboard đọc số sai.
Lưu ý: người phỏng vấn thường hỏi tiếp "nếu job hỏng ba ngày thì sao". Câu trả lời tốt là: vì lưu bản thô và ghi theo partition, chỉ cần backfill lại ba ngày đó, không phải dọn dữ liệu bằng tay.