Đồng bộ và độ trễ

Bối cảnh

Sao Mai là một chuỗi cửa hàng tạp hoá và đồ gia dụng. Chuỗi bắt đầu từ một cửa hàng và đang mở thêm cửa hàng mới. Mỗi cửa hàng bán hàng qua máy tính tiền; dữ liệu bán hàng được gửi về văn phòng để các phòng ban làm báo cáo. Tên chuỗi và mọi số liệu trong bài là giả lập.

Sao Mai cần báo cáo dữ liệu bán ngày 14/09/2026 vào 08:00 ngày 15/09/2026. Hạn nhận dữ liệu là 06:00, nhưng batch của CH03 tới văn phòng lúc 07:10. Đến giờ họp, người quản lý vẫn chưa mở được bản báo cáo mới.

Một đồng nghiệp đề nghị chuyển sang lấy dữ liệu thay đổi để báo cáo cập nhật ngay. Người khác cho rằng cứ chạy streaming (xử lý liên tục) là hết trễ. Hai đề nghị đang nói về những việc khác nhau: cách đưa dữ liệu từ cửa hàng về và nhịp tính kết quả sau khi nhận.

Bài này theo batch CH03 để tìm chỗ chậm, rồi xét cách lấy dữ liệu và nhịp xử lý cho báo cáo mỗi sáng, theo giờ và việc cần phản ứng ngay trong ca bán hàng.

Lấy dữ liệu bằng cách nào

Đồng bộ dữ liệu (data synchronization) là đưa dữ liệu từ nguồn sang nơi dùng tiếp và cập nhật khi nguồn thay đổi. Trong bài này, nơi dùng tiếp là nơi lập báo cáo. Đồng bộ không có nghĩa mọi nơi đều có dữ liệu giống nhau ngay lúc giao dịch xảy ra.

Cách lấy phụ thuộc vào phần dữ liệu báo cáo cần và khả năng của nguồn.

Tệp: nhận một phần dữ liệu đã xuất

Tệp chứa dữ liệu nguồn xuất ra để gửi, chẳng hạn các dòng hàng bán trong ngày. Tuỳ cách đã thống nhất, tệp có thể chứa cả ngày hoặc chỉ phần thay đổi.

Tệp hợp khi nguồn đã xuất được dữ liệu cần dùng và báo cáo có thể chờ lịch gửi. Nếu cần lấy thường xuyên mà việc xuất, gửi tệp tốn công hoặc hay nhầm, có thể xét cách lấy tự động qua giao diện nguồn cung cấp. Chưa cần thay cách gửi tệp nếu nó vẫn đủ dữ liệu, kịp giờ và nhóm kiểm lại được.

Giao diện lập trình: yêu cầu nguồn trả dữ liệu

Giao diện lập trình ứng dụng (Application Programming Interface, API) cho phép phần mềm yêu cầu phần mềm khác trả dữ liệu hoặc thực hiện việc theo quy định sẵn. Chẳng hạn, khâu lập báo cáo gửi yêu cầu và hệ thống bán hàng trả dữ liệu được phép lấy.

Với API, cần kiểm tra có lấy đủ kỳ dữ liệu cần dùng, nhận được phần thay đổi và nhận biết dữ liệu bị xoá hay không. Lấy qua API theo lịch có thể hợp khi nguồn đã hỗ trợ và báo cáo cần cập nhật đều đặn. Nếu tệp vẫn đáp ứng thì chưa cần xây API riêng.

Thu nhận thay đổi: theo phần nguồn đã đổi

Thu nhận thay đổi dữ liệu (Change Data Capture, CDC) là cách nhận biết và lấy những thay đổi ở nguồn, như thêm, sửa hoặc xoá bản ghi, để cập nhật nơi dùng tiếp. Ví dụ, nguồn sửa trạng thái một giao dịch thì bên nhận cần biết đó là sửa giao dịch đã có, không phải thêm một lần bán mới.

CDC có thể đáng xét khi dữ liệu đổi thường xuyên và việc lấy lại toàn bộ gây nhiều công hoặc không đáp ứng nhu cầu. Nhưng cần nguồn hỗ trợ và có người xử lý khi việc nhận bị gián đoạn. Nhóm cũng cần biết cách lấy phần dữ liệu ban đầu, nhận tiếp phần thay đổi và tránh bỏ sót hoặc cộng lặp khi nhận lại.

API trả đủ phần thay đổi hoặc tệp định kỳ vẫn đáp ứng là các phương án thay thế. Chưa cần CDC chỉ vì báo cáo có nhiều người xem. Các cách lấy cũng có thể kết hợp.

Xử lý theo nhịp nào

Sau khi lấy về, dữ liệu còn phải được kiểm, tính và đưa lên báo cáo. Đây là lựa chọn riêng với cách lấy dữ liệu.

• Xử lý theo batch: gom một phần dữ liệu để xử lý cùng một lượt, theo lịch hoặc khi đủ điều kiện chạy. Batch là phần dữ liệu gom cho lượt ấy. Chạy theo batch có thể diễn ra mỗi sáng, mỗi giờ hoặc theo lịch khác phù hợp với nhu cầu.
• Streaming: xử lý dữ liệu tới dần mà không chờ gom cả kỳ như một lượt báo cáo ngày. Dữ liệu vẫn cần thời gian đi qua các bước, nên streaming chưa có nghĩa người dùng thấy thay đổi tức thời.

Hai lựa chọn có thể ghép như sau:

CDC trả lời lấy phần thay đổi bằng cách nào; streaming trả lời xử lý theo nhịp nào. Một nhóm có thể nhận thay đổi qua CDC nhưng chỉ cộng lại tiền hàng theo giờ. Khi ấy, báo cáo vẫn cập nhật theo batch. Muốn xử lý streaming thì cần dữ liệu tới đủ nhanh; những cách lấy khác cũng có thể đưa dữ liệu tới dần.

Xử lý theo batch có thể đủ cho cuộc họp sáng. Xử lý streaming đáng xét khi chờ lượt kế tiếp làm lỡ quyết định trong ca. Trước khi tăng nhịp, cần xét cả nguồn, khâu kiểm và việc cập nhật báo cáo.

Độ trễ phải có mốc đầu và mốc cuối

Độ trễ (latency) là khoảng thời gian giữa hai mốc đang xét. Khi trao đổi, cần nói rõ đo từ đâu tới đâu: từ giao dịch ở nguồn tới báo cáo, từ nhận batch tới tính xong, hay báo cáo ra muộn so với giờ hẹn. Những khoảng này trả lời các câu hỏi khác nhau.

Giờ cập nhật báo cáo khác với dữ liệu đã đủ tới đâu. Dù đã có giao dịch mới nhất của một cửa hàng, báo cáo vẫn có thể thiếu dữ liệu của cửa hàng khác, chẳng hạn CH03.

Với báo cáo dùng thường xuyên, nên ghi kỳ dữ liệu, giờ cập nhật và phần còn thiếu để người xem biết giới hạn. Nếu chỉ gửi tệp cho nhóm nhỏ, lời nhắn kèm các thông tin ấy có thể đủ. Chưa cần màn hình theo dõi riêng khi nhóm vẫn kiểm được phạm vi và các mốc.

Ví dụ giải sẵn

Dòng thời gian của batch CH03 đến muộn

Batch CH03 đang được lấy bằng tệp và xử lý theo batch:

Batch chứa dữ liệu bán ngày 14/09/2026. Các mốc dưới thuộc ngày 15/09/2026, theo giờ Việt Nam, cùng hành trình đã dùng ở bài “Hành trình của dữ liệu”.

Batch sẵn để gửi lúc 05:40 nhưng văn phòng nhận lúc 07:10, sau hạn 06:00. Trong phạm vi A6 có 1 batch tới trễ, chứa 2 dòng hàng. Người phụ trách chọn chờ CH03 và ghi chú lỗi chưa xác nhận. Tới giờ họp 08:00, khâu xử lý vẫn đang chạy; kết quả xong lúc 08:05, báo cáo mở được lúc 08:15. Tính xong không có nghĩa các lỗi chất lượng đã được sửa.

Muốn báo cáo kịp giờ, cần xét từng khoảng thay vì đổi công nghệ cho cả hành trình:

Bảng chưa có giờ gửi thực tế, lý do chờ hay kết quả thử API, CDC, nên cần xác minh và thử cả đường đi trước khi chọn phương án. Nó cũng không có giờ bán từng dòng để đo độ trễ từ từng giao dịch tới báo cáo.

Phiếu chọn cách đồng bộ đã điền

Phiếu dành cho báo cáo sáng của Sao Mai. Nó ghi nhu cầu trước, lựa chọn đang xét sau.

Cùng chuỗi cửa hàng, nhu cầu khác có thể chọn khác

Theo dõi theo giờ có thể dùng API theo lịch hoặc nhận CDC rồi xử lý theo batch. Với việc cần phản ứng trong ca, API cũng đáng xét nếu cung cấp đủ dữ liệu nhanh tới mức cần dùng.

Với nhu cầu “gần như tức thời”, cần hỏi người dùng chờ tới khi nào thì lỡ quyết định. Đó là căn cứ chọn mức trễ cần đáp ứng; chưa cần đổi hệ thống chỉ để báo cáo trông mới hơn.

Khi nào nên làm, khi nào chưa cần

Nên làm: chốt riêng cách lấy và nhịp xử lý khi có nhiều nguồn, báo cáo thường trễ hoặc người dùng cần số liệu trong ca. Viết rõ quyết định nào cần dữ liệu mới, phạm vi nào phải đủ và giờ người dùng phải có kết quả. Nhóm kỹ thuật mới có căn cứ so các phương án.

Có cách khác: nếu người dùng chấp nhận, giữ báo cáo ngày và chỉ cập nhật thường xuyên phần phục vụ quyết định trong ca. Không nhất thiết mọi dữ liệu chạy cùng nhịp. Nếu nguyên nhân là lịch gửi hoặc bàn giao, sửa lịch và cách phối hợp có thể đủ, thay vì đổi cả cách lấy. Nếu bản tạm vẫn dùng được, ghi rõ phần thiếu và hẹn bản bổ sung; việc đó cần người có quyền quyết định báo cáo chấp thuận.

Chưa cần: xử lý streaming khi quyết định chỉ dùng dữ liệu của kỳ đã kết thúc, theo batch vẫn kịp giờ và nhóm kiểm được phần thiếu. CDC cũng chưa cần nếu tệp hoặc API đang đáp ứng mà lấy lại dữ liệu chưa gây trở ngại. Khi việc chậm chưa rõ nguyên nhân, tìm thêm mốc và lý do chờ trước; tăng nhịp không thay được việc hiểu chỗ đang chậm.

Tự làm

Hiểu nhầm thường gặp

“Có CDC là có streaming.” CDC lấy thay đổi ở nguồn. Phần thay đổi đó vẫn có thể được giữ lại rồi xử lý theo batch.

“Chạy streaming thì dữ liệu không trễ.” Nguồn có thể chưa gửi, khâu xử lý có thể chưa theo kịp, và báo cáo còn phải cập nhật. Cần đo tới lúc người dùng có kết quả.

“Báo cáo vừa cập nhật là đã đủ dữ liệu mới.” Giờ cập nhật chỉ nói về bản báo cáo. Vẫn cần biết kỳ dữ liệu và phần còn thiếu; một cửa hàng tới sớm không bù cho cửa hàng chưa gửi.

“Dữ liệu càng mới thì quyết định càng tốt.” Mức mới cần thiết phụ thuộc quyết định. Báo cáo ngày đã kết thúc có thể đủ cho họp sáng; tăng nhịp còn làm tăng công vận hành mà không giải quyết lỗi dữ liệu hoặc cách tính.

Tóm tắt

• Tách cách lấy dữ liệu bằng tệp, API, CDC khỏi nhịp xử lý theo batch hoặc streaming. CDC vẫn có thể đi cùng xử lý theo batch.
• Nói rõ mốc đầu và mốc cuối khi bàn độ trễ. Nhận được dữ liệu, tính xong và mở được bản báo cáo mới là những mốc khác nhau.
• Chốt nhu cầu theo quyết định cần đưa ra, phạm vi cần đủ và giờ cần dùng. Các phần dữ liệu có thể chạy theo nhịp khác nhau.
• Giữ phương án đơn giản khi vẫn đáp ứng. Trước khi đổi, xác nhận khả năng của nguồn, nguyên nhân chậm và thử cả đường đi tới người dùng.

Thuật ngữ trong bài

Mẫu tải về: Phiếu chọn cách đồng bộ (Word). Nội dung giống bảng đã điền ở mục Ví dụ giải sẵn, để trống cho bạn điền.

Bài liên quan: “Hành trình của dữ liệu”, “OLTP và OLAP”, “Tổ chức lớp dữ liệu”, “Chất lượng dữ liệu”.