Menu

Quy trình kiểm tra hàng loạt nhiều số một lúc

Quy trình kiểm tra hàng loạt gồm bốn giai đoạn: làm sạch dữ liệu, chia luồng theo hệ thống, phân loại kết quả và báo cáo về đúng dòng ban đầu. Bài này nói rõ vì sao bỏ qua giai đoạn đầu sẽ phá hỏng cả quy trình.

Đăng ngày

  • quy trình kiểm tra hàng loạt
  • xử lý dữ liệu
  • dữ liệu thử

Quy trình kiểm tra hàng loạt là bài toán khác về chất so với việc kiểm tra một chuỗi trên biểu mẫu, vì bạn không còn thấy từng trường hợp trước mắt và mọi lỗi sẽ xảy ra ở quy mô của cả tệp dữ liệu. Điểm khác biệt lớn nhất không nằm ở thuật toán chữ số kiểm tra, mà nằm ở thứ tự các bước và ở cách báo cáo kết quả. Đọc hết bài này, bạn sẽ biết bốn giai đoạn của một quy trình đáng tin, vì sao phát hiện trùng lặp quan trọng ngang với phát hiện sai sót, và vì sao báo cáo không trỏ về đúng dòng gốc thì coi như vô dụng.

Vì sao kiểm tra hàng loạt thất bại ở bước đầu tiên?

Vì dữ liệu trong tệp thật hầu như chưa được làm sạch. Một cột số trong bảng tính thường chứa lẫn dấu cách, dấu chấm, dấu gạch nối, chú thích của người nhập, và cả những ô bị trộn kiểu dữ liệu khiến bảng tính tự cắt số 0 ở đầu. Nếu bạn đưa nguyên cột đó vào hàm kiểm tra, tỉ lệ không đạt sẽ rất cao, và phần lớn trong số đó không phải lỗi của con số mà là lỗi của định dạng lưu trữ.

Đây là lý do làm sạch phải là giai đoạn đầu tiên, và phải chạy trước mọi bước khác. Nếu bạn bỏ qua giai đoạn này, bạn sẽ dành thời gian điều tra những lỗi giả, và những lỗi thật sẽ bị chôn lẫn trong đó.

Một cái bẫy nữa ở giai đoạn đầu là việc sửa dữ liệu tự động. Khi gặp một ô không xử lý được, bạn muốn tự động điền thêm cho nó đủ độ dài hoặc cắt bớt cho vừa khuôn. Cách làm này biến một giá trị sai thành một giá trị sai khác trông có vẻ đúng, và sau đó không ai còn truy được giá trị gốc. Nguyên tắc an toàn là không bao giờ sửa giá trị, chỉ chuẩn hóa cách trình bày của nó.

Bốn giai đoạn: làm sạch, chia luồng, phân loại, báo cáo

Giai đoạn Việc phải làm Cái được bảo vệ
Làm sạch Bỏ ký tự ngăn cách, thống nhất dạng chữ, giữ nguyên giá trị gốc Không tạo ra lỗi giả
Chia luồng Xác định độ dài và tập ký tự, rồi chọn bộ quy tắc phù hợp Không áp nhầm thuật toán
Phân loại Gán mỗi dòng vào một trong các trạng thái kết quả Không gộp các loại lỗi khác nhau
Báo cáo Xuất kết quả kèm số dòng và giá trị gốc Có thể sửa được ở nguồn

Bốn giai đoạn này chạy theo thứ tự cố định, và mỗi giai đoạn nên tách thành một bước riêng có thể chạy lại. Khi một bước có thể chạy lại độc lập, bạn có thể sửa bước cuối mà không phải xử lý lại toàn bộ tệp, và bạn có thể lưu kết quả trung gian để đối chiếu giữa hai lần chạy.

Một lợi ích ít được nhắc tới là khả năng đo lường. Khi bốn giai đoạn tách rời, bạn biết được mỗi giai đoạn loại bỏ bao nhiêu dòng và vì lý do gì. Đó là thông tin cần thiết để nói với người cung cấp dữ liệu rằng vấn đề nằm ở khâu nào, thay vì chỉ báo rằng phần lớn tệp không đạt.

Phát hiện trùng lặp và giá trị bất khả xử lý

Trong dữ liệu hàng loạt, một số đúng có thể xuất hiện nhiều lần. Việc kiểm tra chữ số kiểm tra không phát hiện được điều này, vì mỗi dòng đều tự nhất quán. Nếu quy trình của bạn không đếm trùng lặp, bạn sẽ nhận một tệp toàn kết quả đạt và không hề biết rằng mình đang xử lý hai bản ghi cho cùng một đối tượng.

Song song với trùng lặp là nhóm giá trị bất khả xử lý. Đây là những dòng không thể gán vào bất kỳ trạng thái nào: ô trống, ô chỉ chứa ký tự trang trí, hoặc giá trị bị bảng tính chuyển thành dạng số học làm mất những ký tự đầu. Nhóm này không giống nhóm không hợp lệ, vì nó không phải là kết quả của một phép đối chiếu nào.

Cần phân biệt thêm một nhóm thứ ba: những dòng khớp định dạng nhưng không có quy tắc để đối chiếu. Đây là nhóm chỉ định dạng nói ở bài trước, và trong bối cảnh hàng loạt, nhóm này thường là nhóm đông nhất. Nếu bạn gộp nó vào nhóm đạt, báo cáo của bạn sẽ trông đẹp hơn thực tế. Nếu bạn gộp nó vào nhóm không đạt, người dùng sẽ đi sửa những dòng vốn không có lỗi.

Báo cáo phải trỏ về dòng nào và giá trị gốc nào

Yêu cầu tối thiểu của một tệp kết quả là mỗi dòng phải nói được ba thứ: dòng này nằm ở vị trí nào trong tệp nguồn, giá trị gốc đọc vào là gì, và kết luận thuộc loại nào. Thiếu bất kỳ thứ nào trong ba thứ đó, người dùng không thể sửa dữ liệu nguồn mà không mở lại toàn bộ tệp và tự dò.

Vị trí nên được ghi bằng số dòng của tệp nguồn, không phải số thứ tự của dòng đã qua làm sạch. Hai con số này khác nhau ngay khi tệp có dòng bị bỏ qua hoặc dòng tiêu đề. Đây là chi tiết nhỏ nhưng gây ra rất nhiều thời gian mất đi khi đối chiếu thủ công.

Giá trị gốc nên được ghi nguyên văn, kể cả khi nó chứa ký tự ngăn cách hay khoảng trắng thừa. Giá trị đã chuẩn hóa nên được ghi ở một cột bên cạnh, để người dùng thấy được sự khác biệt giữa hai cột khi cần. Nếu chỉ ghi giá trị đã chuẩn hóa, bạn đã xóa mất bằng chứng về cách dữ liệu đã được ghi vào tệp.

Ngoài ba cột bắt buộc, nên có thêm cột nêu lý do cụ thể và cột ghi tên hệ thống đã dùng để đối chiếu. Hai cột này biến tệp kết quả từ một danh sách lỗi thành một tài liệu có thể dùng để trao đổi với bên cung cấp dữ liệu.

Xử lý hàng loạt có được ghi đè dữ liệu gốc không?

Không nên. Việc sửa trực tiếp tệp nguồn sẽ xóa mất trạng thái ban đầu, và khi cần đối chiếu hoặc khi phát hiện quy trình chạy sai, bạn không còn gì để phục hồi. Cách làm an toàn là đọc tệp nguồn ở chế độ chỉ đọc, và ghi kết quả ra một tệp mới.

Cách làm này cũng phù hợp với yêu cầu về dữ liệu nhạy cảm. Trước khi đưa dữ liệu thật vào bất kỳ quy trình nào, hãy tách dữ liệu ra khỏi môi trường phát triển, và với những trường không cần thiết cho việc kiểm tra định dạng, hãy thay bằng giá trị giả trước khi xử lý. Nguyên tắc đơn giản là chỉ mang theo những gì phép kiểm tra thật sự cần.

Trong nhiều quy trình, bước thay thế dữ liệu nhạy cảm nên chạy trước cả bước làm sạch, để dữ liệu thật không bao giờ chạm tới những công cụ chỉ phục vụ việc kiểm tra định dạng. Việc này không làm giảm chất lượng kết quả, vì phép kiểm tra chỉ quan tâm tới cấu trúc chuỗi.

Nếu bạn cần một môi trường để thử toàn bộ quy trình trước khi chạy trên dữ liệu thật, công cụ kiểm tra số của trang này là chỗ phù hợp để thử từng chuỗi riêng lẻ và đối chiếu với kết quả hàng loạt của bạn.

Phần dành cho nhà phát triển: thiết kế tệp kết quả

Tệp kết quả là sản phẩm chính của một quy trình hàng loạt, nên nó đáng được thiết kế trước khi viết mã xử lý. Hãy bắt đầu từ việc người dùng sẽ làm gì với tệp đó, rồi suy ngược ra các cột cần có.

  • Giữ một cột số dòng nguồn ổn định suốt quy trình, và không đánh số lại sau khi lọc. Mọi bước sau đều phải tham chiếu được về con số ban đầu.
  • Đặt tên cho từng trạng thái và dùng đúng tên đó trong tệp kết quả. Trạng thái chỉ định dạng cần có tên riêng, không được gộp vào trạng thái hợp lệ.
  • Xuất cả những dòng đạt, không chỉ những dòng lỗi. Người dùng cần đối chiếu số lượng, và việc thiếu những dòng đạt thường bị hiểu là quy trình đã bỏ sót chúng.
  • Ghi rõ tham số đã dùng cho lần chạy, ví dụ phiên bản bộ quy tắc và thời điểm chạy. Khi chạy lại vào tháng sau, bạn cần biết vì sao kết quả khác đi.
  • Đặt giới hạn kích thước cho tệp kết quả và xử lý theo lô nếu tệp nguồn lớn. Một quy trình đọc toàn bộ dữ liệu vào bộ nhớ sẽ hỏng ở đúng lúc dữ liệu trở nên quan trọng.
  • Ghi lại số lượng theo từng trạng thái ở cuối tệp, để người dùng có bức tranh tổng thể trước khi đi vào chi tiết.
  • Không bao giờ để số thật của khách hàng nằm trong tệp ví dụ, tài liệu kiểm thử hay nhật ký chạy. Dùng giá trị được dựng riêng và ghi rõ đó là giá trị giả.

Một tệp kết quả được thiết kế theo cách này sẽ dùng được cho cả người sửa dữ liệu lẫn người vận hành hệ thống.

Việc nên làm sau bài này

Hãy lấy một tệp dữ liệu mẫu nhỏ, chạy bốn giai đoạn nói trên, và kiểm tra xem tệp kết quả của bạn có cột số dòng nguồn và cột giá trị gốc hay chưa. Nếu thiếu, bạn sẽ phải quay lại sửa quy trình ngay khi tệp lớn hơn vài nghìn dòng. Để hiểu những gì quy trình này đang đối chiếu, bài kiểm tra số: ký tự, độ dài và chữ số kiểm tra mô tả bốn trạng thái kết quả; còn bài kiểm tra tại API: nên chặn ở máy khách hay máy chủ nói về việc phân chia trách nhiệm giữa các tầng khi quy trình này phục vụ một hệ thống đang chạy. Nếu dữ liệu của bạn gắn với địa chỉ và số điện thoại ở nhiều nước, bài kiểm thử địa chỉ và số điện thoại quốc tế có thêm ví dụ cùng chủ đề.

Mọi giá trị số trong bài chỉ nhằm minh họa các bước của một quy trình xử lý; chúng là dữ liệu được dựng riêng cho mục đích trình bày, không phải số của bất kỳ người, doanh nghiệp hay tài khoản nào có thật, và không được dùng để mạo danh hay để khẳng định một con số là dùng được.

Đọc tiếp

Bài viết về Kiểm Tra CCCD