Bài trước chúng ta đã đến đoạn Phát hiện trùng – Duplication detection. Tiếp theo chúng ta cùng tìm hiểu các phương án xử lý sau khi phát hiện trùng.
Ở cấp độ cơ bản, nếu 2 records bị trùng, thì giữ lại 1, và xoá đi 1. That’s it!
Ở cấp độ nâng cao, hệ thống cho phép gộp – merge – các records lại để tạo thành 1 bản ghi tổng hợp dựa trên các luật được định nghĩa sẵn. Ví dụ: ưu tiên dữ liệu mới/cũ hơn, ưu tiên nguồn A hơn nguồn B, ưu tiên dữ liệu dài hơn…
Ở cấp độ vũ trụ, hệ thống quan sát cách xử lý của người dùng rồi đưa ra cách xử lý linh hoạt cho từng trường hợp.
Tất nhiên là phương án nào cũng có sai số, nhưng với tập dữ liệu quá lớn thì phải đánh đổi và chấp nhận một tỉ lệ sai sót nhất định. Tỉ lệ này thường được gọi là các ngưỡng rủi ro- risk thresholds.
Các hệ thống hịn, cho phép linh hoạt cài đặt tỉ lệ này cho cả phần kiểm tra trùng lẫn xử lý gộp. Ví dụ: nếu tỉ lệ trùng trên 80% thì cho phép hệ thống tự lọc trùng và gộp, nếu dưới 80% thì sẽ gởi Mail cho Admin để xử lý bằng cơm.
Sau khi được làm sạch, dữ liệu được đưa về các vùng dữ liệu (datamart), hoặc phân loại, hoặc nằm im chẳng cần phân chia gì…và chờ hệ thống khác tới query.
Tới đây, chúng ta đã điểm qua vài nét chính của xu hướng “Bền vững”, hãy tiến thêm bước nữa tới xu hướng “Linh hoạt”, một xu hướng ngày càng trở nên phổ biến và có nhiều ưu điểm vượt trội.
Xu hướng “Linh hoạt” chính là cơ sở của việc triển khai Micro-service, có 3 trụ cột chính: mapping, phân quyền và trao đổi thông tin.
1. Mapping: Thay vì tập hợp hết dữ liệu lại một chỗ như “Bền vững”, xu hướng “Linh hoạt” không đòi hỏi điều đó. Dữ liệu cứ lưu chỗ nó đang ở, chỉ cần khai báo địa chỉ. Sẽ có một cơ chế mapping dữ liệu với địa chỉ tương ứng để truy xuất khi cần thiết.
Nôm na như sau: thông tin Khách hàng được quy định tên, email và địa chỉ nhà nằm ở ứng dụng eCommerce, số điện thoại thì lấy từ ứng dụng Giao hàng, tài khoản Facebook thì từ ứng dụng chăm sóc khách hàng. Khi bất kỳ hệ thống nào cần truy xuất thông tin khách hàng, hệ thống sẽ tự động truy xuất tới các ứng dụng tương ứng để tổng hợp.
2. Phân quyền: đối với một doanh nghiệp có nhiều ứng dụng, việc quy định tài khoản nào được truy cập dữ liệu/ứng dụng/hệ thống nào với quyền gì (ghi/xoá/đọc/thay đổi) rất phức tạp và thường xuyên thay đổi. Một giải pháp nhạc trưởng điều phối tài nguyên và truy cập sẽ đảm đương việc này. Giải pháp thường được dùng chính là Kubernetes, một ứng dụng mã nguồn mở dùng để quản lý ứng dụng và service.
3. Trao đổi thông tin: Sau khi đã hoàn chỉnh việc phân quyền và mapping, các ứng dụng sẽ bắt đầu truy xuất dữ liệu và cần một cơ chế điều phối để đảm bảo hiệu năng khi lượng dữ liệu lớn và thông tin đáp ứng trên thời gian thực hoặc gần thực. Giải pháp thường được dùng chính là Kafka, nền tảng event streaming mã nguồn mở của Apache.
Bộ đôi Kubernetes và Kafka là một trong những lựa chọn hàng đầu của việc xây dựng hạ tầng kiến trúc của xu hướng linh hoạt trong thời gian gần đây.
Chóng mặt lắm chưa? 
Dừng hén.
Dừng hén.Tới đây vẫn mới là phổ cập kiến thức, bài sau chúng ta sẽ bàn cụ thể hơn về cách ứng dụng các khái niệm đó vào chiến lược của doanh nghiệp (bao gồm cả SME) dưới góc nhìn ít kỹ thuật, nhiều chiến lược kinh doanh hơn.
3 comments
Dorris Johnson
Tháng Một 25, 2018 at 9:32 sáng
Chuỗi bài viết hay, nhiều nội dung đáng học hỏi
Prof. Dan Walker
Tháng Một 25, 2018 at 9:35 sáng
Nhờ các phương pháp trong bài mà hệ thống trong Công ty tôi đã được tối ưu hơn
Kavon King
Tháng Một 25, 2018 at 9:35 sáng
Kiến thức này rất phù hợp trong quá trình tư duy áp dụng chuyển đổi số cho doanh nghiệp