Case study kiến trúc

Mục lục

• Bối cảnh
• Chốt nhu cầu trước khi ghép các mảnh
• Những khái niệm dùng trong thiết kế
• Ví dụ giải sẵn
• Tự làm
• Hiểu nhầm thường gặp
• Tóm tắt

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 một phương án kiến trúc cho chuỗi 50 cửa hàng. Phòng Kinh doanh muốn xem tiền hàng bán ra; phòng Kế toán cần báo cáo theo lúc ghi sổ. Các cửa hàng gửi dữ liệu về văn phòng để lập báo cáo sáng. Nhưng dữ liệu có lúc tới muộn, có giao dịch thiếu mã cửa hàng, và có batch (lô dữ liệu) được gửi lại sau khi sửa.

Nhóm cần chốt nơi lưu, bản dùng cho báo cáo, ý nghĩa từng dòng và cách xử lý gửi lại. Các lựa chọn phải khớp nhau để không cộng lặp hay bỏ qua phần thiếu.

Bài này ghép các bài trước về kiến trúc thành một phương án giả lập để trao đổi. Các bảng giao dịch là lát cắt minh hoạ, không dùng để tính doanh thu hay chứng minh khả năng xử lý của toàn chuỗi.

Chốt nhu cầu trước khi ghép các mảnh

Nhu cầu chính là báo cáo định kỳ từ dữ liệu bán hàng dạng bảng. Phương án giả định nhóm có người tổ chức bảng và vận hành nhận, xử lý dữ liệu; năng lực thực tế cần xác nhận. Bài chưa chọn sản phẩm hay dự toán đầu tư.

Nhận đúng hạn còn phải qua kiểm, tính và cập nhật báo cáo mới tới người dùng. Cần thử cả đường đi trước khi chốt lịch.

Những khái niệm dùng trong thiết kế

• Xử lý giao dịch trực tuyến (Online Transaction Processing, OLTP) phục vụ việc ghi và tra từng giao dịch, như lưu hoá đơn tại quầy.
• Xử lý phân tích trực tuyến (Online Analytical Processing, OLAP) phục vụ tổng hợp và so sánh, như xem bán hàng theo cửa hàng và ngày.
• Data warehouse (kho dữ liệu) tập hợp và tổ chức dữ liệu để dùng lại cho báo cáo, phân tích.
• Mức chi tiết (grain) nói mỗi dòng đại diện cho việc gì.
• Khoá nhận diện (key) là cột hoặc nhóm cột phân biệt từng dòng, vẫn nhận ra cùng sự kiện khi nguồn gửi lại.
• Bronze (lớp dữ liệu thô) giữ nội dung từng lần nhận.
• Silver (lớp dữ liệu đã kiểm) giữ phần đạt quy tắc đang áp dụng.
• Gold (lớp dữ liệu phục vụ báo cáo) tính kết quả theo mục đích báo cáo.

Các lớp phân biệt công việc và bản dữ liệu, không đòi mỗi lớp có một hệ thống riêng.

Ví dụ giải sẵn

Đường đi của phương án kiến trúc

1. Nguồn: máy bán hàng ghi dòng hàng, hoá đơn và thanh toán tại cửa hàng.
2. Thu nạp: nhận tệp ngày, ghi cửa hàng, kỳ, mã batch, mã lần nhận và lúc nhận; bản gửi lại có lần nhận riêng.
3. Lưu trữ: giữ bản gốc để đối chiếu; tổ chức bảng phân tích trong data warehouse.
4. Xử lý: kiểm, tách phần chờ, xử lý gửi lại theo khoá đã xác nhận. Giữ riêng dòng hàng và thanh toán; tính báo cáo từ phần được phép dùng theo định nghĩa, kỳ của từng phòng.
5. Phục vụ: báo cáo đọc phần đã chuẩn bị, hiện định nghĩa, kỳ, giờ cập nhật và phần thiếu hoặc chờ xác nhận.

Việc xuất dữ liệu vẫn có thể dùng tài nguyên bán hàng nên cần thử ảnh hưởng tới quầy.

Bản ghi quyết định: nơi chạy báo cáo

Bộ dữ liệu không có phép đo tải; bằng chứng về ảnh hưởng tới quầy cần lấy khi thử phương án.

Bản ghi quyết định: kiểu nền tảng

Data lake (hồ dữ liệu) giữ nhiều dạng dữ liệu để các nhóm xử lý theo nhu cầu. Data lakehouse (nền tảng kết hợp hồ và kho) tổ chức bảng phân tích trên nơi lưu trữ của data lake, cùng cách quản lý đọc và cập nhật bảng. Chỉ giữ tệp gốc chưa làm phương án thành data lake hay data lakehouse; cần xét cách tổ chức và dùng dữ liệu.

Bản ghi quyết định: mức chi tiết và cách ghép

Fact (bảng sự kiện) ghi sự kiện hoặc kết quả đo ở mức chi tiết đã chọn. Dimension (bảng chiều) cung cấp mô tả để đọc, lọc và gom nhóm, như tên cửa hàng.

HD3001 trong bài “Grain, fact và dimension” có nhiều dòng hàng và nhiều lần trả tiền. Ghép trực tiếp theo mã hoá đơn làm dòng hàng lặp theo từng lần trả. Khi ghép tên cửa hàng, mỗi mã cũng phải khớp đúng một bản mô tả phù hợp với thời điểm hoặc mục đích báo cáo.

L01 trong bài “Tổ chức lớp dữ liệu” ghi tổng từng giao dịch, khác mức dòng hàng của HD3001. Hai ví dụ không thể cộng chung để ra doanh thu.

Bản ghi quyết định: giữ các lớp dữ liệu

Vùng cách ly (quarantine) giữ riêng hoặc đánh dấu phần chưa đạt để không đi vào bảng dùng tiếp.

L01 minh hoạ quy tắc thiếu mã cửa hàng; báo cáo thực tế còn cần kiểm các lỗi khác ảnh hưởng mục đích dùng. Giữ bản gốc để đối chiếu không đặt ra thời hạn lưu chung.

Bản ghi quyết định: nhận lại và tính lại

Trong L01, GD1 và GD2 giữ nguyên; GD3 được dùng sau khi CH01 xác nhận mã cửa hàng. Mã lần nhận phân biệt bản gửi, không phải giao dịch. Bỏ cả batch từng nhận sẽ làm mất bản sửa; cùng khoá nhưng nội dung khác thì phải xác minh trước khi thay.

Nếu sửa giao dịch chuyển sang cửa hàng khác, phải tính lại cả tổng của cửa hàng cũ và mới, cùng các báo cáo bị ảnh hưởng.

Bản ghi quyết định: cách lấy và nhịp xử lý

Giao diện lập trình ứng dụng (Application Programming Interface, API) cho phần mềm yêu cầu nguồn trả dữ liệu theo quy định sẵn. Thu nhận thay đổi dữ liệu (Change Data Capture, CDC) lấy phần thêm, sửa hoặc xoá ở nguồn để cập nhật nơi dùng tiếp.

Xử lý theo batch gom một phần dữ liệu để xử lý cùng lượt; batch là phần dữ liệu của lượt ấy. Streaming (xử lý liên tục) xử lý dữ liệu tới dần mà không chờ gom cả kỳ. Độ trễ (latency) là thời gian giữa các mốc đã chỉ rõ, như từ lúc nhận batch tới lúc mở được bản mới.

Nếu có nhu cầu theo giờ, có thể tăng nhịp cho phần đó và giữ báo cáo ngày. Chỉ xét streaming khi quyết định không thể chờ lượt kế tiếp và nguồn, đội ngũ đáp ứng. Đổi cách lấy dữ liệu vẫn cần kiểm thời gian chờ ở các khâu sau.

Bản ghi quyết định: báo cáo khi còn thiếu

Hai mục đích có thể cần hai metric (chỉ số), dù dùng chung nơi phân tích. Báo cáo cần ghi tên và cách tính; người có quyền chốt việc dùng phần còn lỗi hoặc thiếu theo mục đích báo cáo.

Dùng lần trễ của CH03 để thử thiết kế

Ngày 15/09/2026, nguồn sẵn để gửi lúc 05:40 nhưng chưa có giờ gửi thực tế. Hạn nhận là 06:00; giờ dùng báo cáo là 08:00.

Thu nạp là chặng đầu tiên quá mốc: nhận lúc 07:10. Bảng kết quả sẵn lúc 08:05 và bản mới mở được lúc 08:15, nên lần này không kịp giờ báo cáo 08:00.

Để tìm nguyên nhân, cần biết giờ gửi, thời gian và lý do chờ ở từng khâu. Giữ bản thô, ngăn cộng lặp và tách tải không làm đầu vào tới sớm hơn.

Danh sách tự soát đã điền

Thử các tình huống trên để kiểm kết quả và giờ mở báo cáo. Bài “Case study tích hợp” bổ sung trách nhiệm, quy tắc chất lượng và kiểm soát truy cập.

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

Nên làm: ghi từng quyết định khi nhiều nhóm cùng đưa dữ liệu tới báo cáo, sắp đầu tư nơi phân tích chung, hoặc lỗi gửi lại, thiếu dữ liệu và trễ báo cáo lặp lại. Lý do và điều kiện xét lại giúp người sau biết khi nào cần đổi.

Có cách khác: khi nhu cầu nhỏ, bắt đầu với một báo cáo, giữ tệp gốc và bảng đã kiểm, thử nhận lại để tìm vấn đề ở nguồn, cách ghép, lịch chạy hay nơi phân tích rồi ghi phần cần tách.

Chưa cần làm: thiết kế cả data warehouse khi chỉ phân tích một lần, nguồn đáp ứng và đối chiếu bằng tệp được. Báo cáo dùng đều đặn để quyết định thì cần rõ nguồn, cách tính, phần thiếu; đầu tư theo nhu cầu và bằng chứng đã thử.

Tự làm

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

“Đủ các thành phần là kiến trúc đã tốt.” Data warehouse, lớp và CDC chỉ có ích khi nối được với nhau để đáp ứng nhu cầu, tránh báo cáo trễ hoặc cộng lặp.

“Có data warehouse dùng chung thì chỉ có một số doanh thu.” Hai mục đích có thể cần hai metric, với tên, cách tính và định nghĩa riêng.

“Giữ riêng các lớp thì dữ liệu đã đúng.” Độ đúng còn phụ thuộc nguồn, quy tắc, cách ghép và xác nhận phần có vấn đề.

“Thiết kế cho toàn chuỗi là đã có dữ liệu toàn chuỗi.” Phạm vi thiết kế, mẫu minh hoạ và phần đã nhận đủ là những phạm vi khác nhau.

Tóm tắt

• Bắt đầu từ quyết định người dùng cần đưa ra, phạm vi, định nghĩa và giờ phải có báo cáo. Sau đó mới ghép nơi phân tích, mức chi tiết, lớp dữ liệu và cách đồng bộ.
• Giữ riêng việc chọn nền tảng, cách lấy và nhịp xử lý. Data warehouse không tự sửa dữ liệu; CDC không đồng nghĩa streaming.
• Bản nhận khác sự kiện bán hàng. Khoá ổn định, xác nhận bản sửa và tính lại đúng phạm vi giúp nhận lại mà không cộng lặp; cách ghép cũng cần giữ đúng mức chi tiết.
• Mỗi lựa chọn có phần phải đánh đổi và điều kiện xét lại. Trước khi chốt, cần thử với batch đúng hạn, batch trễ và bản gửi lại.

Thuật ngữ trong bài

Mẫu tải về: Bản ghi quyết định và danh sách tự soát (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”, “Grain, fact và dimension”, “Chọn kiểu nền tảng dữ liệu”, “Tổ chức lớp dữ liệu”, “Đồng bộ và độ trễ”, “Case study tích hợp”.