Kiểm tra rộng với chi phí thấp, rồi tìm hiểu kỹ số ít trường hợp cần thiết

Xét một lô minh họa gồm 10.000 cập nhật liên hệ. Có thể đưa từng bản ghi qua mô hình để phán đoán mới về các trường. Như vậy một quyết định ánh xạ biến thành 10.000 quyết định lặp lại.

Hãy bắt đầu bằng câu hỏi rẻ hơn: bản ghi này có khớp các điều kiện đã biết của ánh xạ được duyệt không? Kiểm tra trường có mặt, kiểu dữ liệu, phiên bản lược đồ và yêu cầu đồng ý rõ ràng bằng mã. Chuyển những bản ghi không đạt hoặc còn mơ hồ sang bước xem xét hẹp hơn.

Đây là thiết kế minh họa, không phải chuẩn hiệu năng Tajo. Con số đáng quan tâm không phải lượt đầu cho qua bao nhiêu bản ghi. Đó là nó cho qua nhầm bao nhiêu lỗi quan trọng.

Quy trình chuyên môn trong cuộc nói chuyện này bắt đầu bằng phân loại rộng bình thường hay bất thường, sau đó phân tích thêm các trường hợp được đánh dấu. Lĩnh vực đó có hệ quả và bằng chứng khác dữ liệu marketing. Nguồn chứng minh cách ra quyết định theo giai đoạn, không chứng minh chi phí hay tính xác định của thuật toán đầu. Trong tích hợp, kiểm tra rẻ và xác định có thể xử lý điều kiện đã biết trước khi những trường hợp bất định được xem kỹ.

Lượt đầu nên giải quyết trường hợp thông thường

Lượt đầu tốt đặt câu hỏi mà mã có thể trả lời từ bằng chứng sẵn có. “Trường nguồn có mặt không?” là một. “Giá trị có hợp kiểu dữ liệu đích khai báo không?” là một câu khác. “Đây có phải phiên bản lược đồ mà ánh xạ được duyệt không?” là câu thứ ba.

Quy tắc chạy trên mọi hàng mà không sáng tạo cách hiểu mới cho từng hàng. Nó cũng giải thích được kết quả. Một hàng bị giữ có thể nói trường birthday ở hệ thống đích cần ngày, còn nguồn gửi văn bản tự do. Điều đó hữu ích hơn “mức độ chắc chắn của mô hình thấp”.

Hướng dẫn bộ kết nối Brevo của Tajo giải thích vì sao định nghĩa thuộc tính ở đích quan trọng. Bộ kết nối có thể gửi yêu cầu HTTP trong khi hệ thống nhận bỏ qua thuộc tính chưa khai báo. Kiểm tra trước khi ghi đối với trường đã khai báo bắt một loại lỗi. Đọc lại sau ghi bắt loại khác. Đừng nhầm cả hai với ý kiến mô hình rằng liên hệ “có vẻ ổn”.

Mục tiêu không phải xóa bỏ phán đoán. Mục tiêu là dành nó cho câu hỏi thật sự cần phán đoán.

1. Lô đồng bộ mới

2. TRƯỚC

   Kiểm tra quy tắc đã biết

   • Định danh, kiểu trường và phạm vi tài khoản
3. SAU ĐÓ

   Xử lý kết quả rõ ràng

   • Cho qua bản ghi thường; giữ lỗi đã biết
4. CHỈ KHI CẦN

   Xem trường hợp chưa giải quyết

   • Xem bằng chứng quy tắc chưa kết luận được

5. Kết quả đã kiểm tra hoặc trạng thái giữ rõ ràng

Lượt tốn kém cần đúng trường hợp

Giả sử 9.800 trong 10.000 bản ghi minh họa qua kiểm tra đầu. 200 bản ghi còn lại được xem kỹ. Nghe hiệu quả, nhưng chưa nói gì về độ đúng cho tới khi có người lấy mẫu trong 9.800 và kiểm tra kết quả của 200.

Lượt đầu có hai loại sai. Nó có thể đánh dấu trường hợp bình thường, tốn thời gian xem xét không cần thiết. Nghiêm trọng hơn, nó có thể cho qua trường hợp đáng lẽ phải dừng. Lỗi nào đắt hơn tùy quy trình. Thiếu nhãn tùy chọn và thiếu quyền gửi email marketing không nên dùng cùng ngưỡng.

Phản biện hợp lý là: “Nếu mô hình hiểu từng bản ghi, sao tin quy tắc cứng?” Vì hỏi mô hình lần nữa không tự động làm bản ghi thường đúng hơn. Điểm yếu của quy tắc nhìn thấy được: khi hợp đồng nguồn hoặc đích đổi, giả định có thể lỗi thời. Đó là lý do theo dõi hợp đồng và lấy mẫu những trường hợp đã qua, không phải lý do thay mọi kiểm tra ổn định bằng phán đoán không giới hạn.

Bước chuyển tiếp cũng có thể hẹp hơn việc người xem toàn bộ. Lỗi nhà cung cấp đã biết có thể chỉ cần sửa theo tài liệu. Ý nghĩa trường hoàn toàn mới có thể cần tác nhân đề xuất ánh xạ. Sự mơ hồ về đồng ý có thể cần người chịu trách nhiệm. Lượt đầu nên định tuyến từng trường hợp tới cấp nhỏ nhất có quyền và khả năng giải quyết.

Hướng dẫn tích hợp nhiều công cụ kinh doanh mô tả cách chọn nguồn dữ liệu chuẩn và sự kiện kích hoạt trước khi chọn công cụ. Những quyết định đó xác định ngoại lệ nào cần chú ý. Trường không ai dùng phía sau bị lệch có thể chờ. Trường quyết định đối tượng chiến dịch bị lệch thì không.

Đo tỷ lệ lỗi lọt qua, không chỉ tiền tiết kiệm

Hệ thống theo giai đoạn có thể tạo đồ thị hấp dẫn: nhiều trường hợp xử lý rẻ, ít trường hợp chuyển tiếp. Đồ thị đó chưa đủ. Thêm thước đo thứ hai: trong số trường hợp lượt đầu cho qua, bao nhiêu trường hợp thất bại ở phép kiểm tra đích sau đó hoặc đợt xem mẫu độc lập?

Phép đo phải gắn với công việc. Nếu mục tiêu là giữ liên hệ khớp nhau, kiểm tra trạng thái liên hệ ở đích. Nếu là duy trì đối tượng, kiểm tra ai được đưa vào và ai bị loại. Con số lỗi không có mẫu số và hệ quả về sau dễ được ăn mừng nhưng khó tin.

Một thử nghiệm thực tế có thể bắt đầu nhỏ. Lưu tập bản ghi thường và ngoại lệ đã được xem. Chạy quy tắc rẻ trên đó. Kiểm tra mọi ngoại lệ bị bỏ sót. Sau đó chạy song song trên lưu lượng thật nhưng chưa cho phép nó phê duyệt hành vi mới. Chỉ khi hiểu các lỗi bỏ sót mới để quy tắc quyết định trường hợp nào bỏ qua xem xét sâu.

Hướng dẫn reverse ETL giải thích việc di chuyển dữ liệu lặp lại phía sau loại công việc này. Câu hỏi phân luồng đi cùng đường ống ấy: quan sát nào báo quy tắc ổn định không còn ổn định?

Hãy dành lượt xem kỹ cho nơi lượt rộng không thể biết.