Nhiều xưởng sản xuất chạy ERP đều gặp cùng một hiện tượng vào cuối tháng: kế toán mở báo cáo doanh số, và ngay sau đó việc nhập đơn hàng ở xưởng sản xuất bỗng chậm hẳn đi. Phản xạ tự nhiên là đổ lỗi cho server yếu, mạng chậm, hoặc "phần mềm dở". Nhưng nguyên nhân thường đơn giản hơn nhiều: một cơ sở dữ liệu đang phải làm hai việc rất khác nhau cùng lúc, và hai việc đó giẫm chân lên nhau.
Hai công việc khác nhau, một cơ sở dữ liệu
Phần lõi vận hành của ERP — chỗ tạo đơn bán hàng, ghi nhận nhập kho, cập nhật tồn kho — được xây theo mô hình OLTP (Online Transaction Processing). Hệ thống này được tối ưu cho số lượng lớn giao dịch đọc/ghi ngắn và thường xuyên: mỗi giao dịch chỉ đụng vài dòng dữ liệu, commit nhanh, rồi nhường chỗ cho giao dịch tiếp theo. Đây chính là điều giúp ERP chạy mượt trong một ngày làm việc bình thường.
Báo cáo cuối tháng — ví dụ:
- tổng doanh số theo khu vực theo quý
- biến động tồn kho cả năm
- biên lợi nhuận theo dòng sản phẩm
— lại là một loại truy vấn hoàn toàn khác. Nó nặng về đọc dữ liệu, quét qua khối lượng lịch sử lớn, và có thể mất vài phút thay vì vài mili-giây. Nếu chạy trực tiếp truy vấn đó trên chính những bảng mà xưởng sản xuất đang dùng để tạo đơn hàng, hai luồng công việc sẽ tranh nhau cùng một khóa (lock) và cùng tài nguyên hệ thống. Đó chính là toàn bộ câu chuyện đằng sau việc "sao hễ kế toán chạy báo cáo là hệ thống chậm hẳn" — không phải lỗi phần mềm, mà là hai loại tải không tương thích đang dùng chung một hệ thống.
Vì sao tách riêng một Data Warehouse lại giải quyết được vấn đề
Đây chính là lý do data warehouse (DW) tồn tại như một khái niệm tách biệt khỏi cơ sở dữ liệu vận hành. Data warehouse là một kho dữ liệu tích hợp, được xây riêng cho OLAP (Online Analytical Processing) — tức các truy vấn phân tích lớn, phức tạp — và tách biệt hoàn toàn khỏi hệ thống OLTP đang xử lý giao dịch sống. Dữ liệu được chuyển từ hệ thống vận hành sang kho theo lịch định kỳ, để các truy vấn phân tích nặng không bao giờ chạm vào những bảng mà bộ phận bán hàng phụ thuộc vào từng phút. Hệ thống đơn hàng vẫn nhanh vì nó không còn phải phục vụ hai chủ cùng lúc.
Dữ liệu phân tích được tổ chức thế nào: khối dữ liệu và mô hình hình sao
Sau khi tách riêng, dữ liệu phân tích cũng được tổ chức theo cách khác. Dữ liệu phân tích thường được mô hình hóa như một khối dữ liệu đa chiều (hypercube) — một khối n chiều cho phép cắt lát doanh số, ví dụ, đồng thời theo:
- thời gian
- khách hàng
- sản phẩm
- khu vực
Về mặt vật lý, mô hình này được triển khai dưới dạng mô hình hình sao (star schema, equivalent to the Kimball dimensional model): một bảng sự kiện (fact table) trung tâm chứa các số liệu cần cộng dồn — doanh số, số lượng — được bao quanh bởi các bảng chiều (dimension table) như thời gian, khách hàng, sản phẩm, giúp những con số đó có ngữ cảnh.
Khi kho dữ liệu lớn dần, người ta thường tách ra một data mart — một phần nhỏ hơn, chuyên biệt theo chủ đề, ví dụ chỉ chứa dữ liệu bán hàng của một bộ phận — để những ai chỉ cần một góc nhìn cụ thể không phải lục lọi toàn bộ cấu trúc.
Ý nghĩa thực tế cho một xưởng sản xuất không phải là "quý tới phải làm ngay một dự án data warehouse". Mà là: nếu ERP của xưởng sản xuất chậm hẳn đi mỗi khi ai đó chạy số liệu cuối tháng, giải pháp không nằm ở việc mua server mạnh hơn — mà ở việc nhận ra rằng công việc giao dịch và công việc phân tích không nên dùng chung một bộ bảng. Chỉ cần một bản sao báo cáo khiêm tốn, được làm mới định kỳ từ dữ liệu đơn hàng và tồn kho, tổ chức theo đúng những gì cần đo lường, cũng sẽ giúp ích cho cả tốc độ lẫn độ chính xác báo cáo nhiều hơn là đổ tiền nâng cấp phần cứng cho hệ thống đang chạy sống.
Nguyễn Hải Minh
Tôi làm việc trong ngành CNTT tại Đức — trực tiếp viết phần mềm và xử lý dữ liệu hệ thống ERP (như INFOR) cho các nhà máy sản xuất của Đức. Về học vấn, tôi có bằng Cử nhân Kỹ thuật CNTT và bằng Kỹ thuật viên Điện tử Thông tin cấp nhà nước tại Đức. Tất cả những nền tảng đó giúp tôi rèn luyện một tư duy hệ thống vững vàng để làm tự động hóa và tối ưu vận hành chuẩn chỉ.
Tìm hiểu thêm về tác giả →