Kho dữ liệu (data warehouse) là một cơ sở dữ liệu được thiết kế riêng cho phân tích: nó lấy dữ liệu từ nhiều hệ thống nghiệp vụ (ERP, phần mềm bán hàng, kế toán, CRM, kho vận), làm sạch, thống nhất định nghĩa, lưu cả lịch sử, rồi phục vụ báo cáo và truy vấn mà không làm chậm các hệ thống đang chạy. Định nghĩa kinh điển của Bill Inmon trong cuốn Building the Data Warehouse (1992) gồm bốn tính chất: hướng chủ đề, tích hợp, gắn với thời gian và không biến đổi.
Doanh nghiệp cần kho dữ liệu khi câu hỏi quản trị bắt đầu cắt ngang nhiều hệ thống: "biên lợi nhuận theo từng khách hàng sau chiết khấu và chi phí giao hàng", "tồn kho trung bình ba năm qua theo mùa". Nếu mỗi lần trả lời phải xuất năm tệp Excel rồi ghép tay, và hai phòng ban đưa ra hai con số doanh thu khác nhau, thì vấn đề không còn là công cụ báo cáo mà là thiếu một nơi lưu dữ liệu đã thống nhất.
Bốn tính chất trong định nghĩa của Inmon và ý nghĩa thực tế
Hướng chủ đề (subject-oriented). Hệ thống nghiệp vụ được tổ chức theo quy trình: phân hệ bán hàng, phân hệ mua hàng, phân hệ lương. Kho dữ liệu tổ chức lại theo đối tượng mà lãnh đạo hỏi: khách hàng, sản phẩm, nhà cung cấp, nhân viên. Một khách hàng xuất hiện trong ba phân hệ sẽ được nhìn như một thực thể duy nhất.
Tích hợp (integrated). Mã sản phẩm trong phần mềm kho là "SP-001", trong sàn thương mại điện tử là một mã SKU khác, trong kế toán lại theo mã vật tư. Kho dữ liệu phải ánh xạ chúng về một khoá chung, thống nhất đơn vị tính, tiền tệ, cách viết tên tỉnh thành (sau sáp nhập còn 34 tỉnh thành, dữ liệu cũ vẫn mang tên tỉnh cũ). Đây là phần tốn công nhất và cũng là giá trị lớn nhất.
Gắn với thời gian (time-variant). Hệ thống nghiệp vụ thường chỉ giữ trạng thái hiện tại: khách hàng đổi địa chỉ thì địa chỉ cũ mất. Kho dữ liệu giữ dấu thời gian để trả lời "doanh thu quý 2 năm ngoái theo cơ cấu vùng lúc đó", không phải theo cơ cấu hôm nay.
Không biến đổi (non-volatile). Dữ liệu đã nạp vào kho không bị sửa xoá theo giao dịch hằng ngày; nó được bổ sung theo lô. Nhờ vậy, báo cáo chạy hôm nay và chạy lại tuần sau cho cùng một kỳ sẽ ra cùng một số, điều kiện tối thiểu để lãnh đạo tin vào số liệu.
Kiến trúc nhiều tầng: dữ liệu đi qua những chặng nào
Dù xây trên máy chủ riêng hay trên đám mây, phần lớn kho dữ liệu hiện đại có cùng một luồng logic. Tên gọi mỗi tầng khác nhau giữa các nhóm (có nơi gọi đồng, bạc, vàng), nhưng chức năng tương tự:
- Nguồn (source): ERP, POS, CRM, tệp Excel của phòng tài chính, dữ liệu sàn thương mại điện tử, API của đơn vị vận chuyển. Kho không sửa gì ở đây, chỉ đọc.
- Tầng tiếp nhận (staging/raw): bản sao gần như nguyên trạng của dữ liệu nguồn, có thêm thời điểm nạp. Giữ tầng này để khi logic sai có thể tính lại mà không phải kéo lại từ nguồn.
- Tầng tích hợp (integration/core): nơi làm sạch, khử trùng lặp, ánh xạ mã, áp quy tắc nghiệp vụ. Trong trường phái Inmon, đây là kho doanh nghiệp chuẩn hoá cao; trong trường phái Kimball, đây là các bảng fact và dimension dùng chung.
- Tầng phục vụ (data mart/presentation): các bảng gọn, đặt tên dễ hiểu, phục vụ từng nhóm người dùng: tài chính, bán hàng, chuỗi cung ứng.
- Tầng sử dụng: công cụ BI, bảng tính kết nối trực tiếp, mô hình dự báo, hoặc dữ liệu đẩy ngược về CRM.
Hai điểm hay bị bỏ qua khi vẽ sơ đồ: siêu dữ liệu (ai sở hữu bảng nào, cột nào tính ra sao, nạp lúc mấy giờ) và điều phối (thứ tự chạy các bước, xử lý khi một nguồn trễ). Thiếu hai thứ này, kho vẫn chạy được vài tháng rồi trở thành mớ bảng không ai dám xoá.
Inmon hay Kimball: hai trường phái thiết kế
Cuộc tranh luận giữa Bill Inmon (thiết kế từ trên xuống) và Ralph Kimball (The Data Warehouse Toolkit, 1996, thiết kế từ dưới lên) kéo dài suốt thập niên 1990–2000. Ngày nay đa số nhóm dùng lai, nhưng hiểu hai cực giúp bạn đọc được đề xuất của nhà tư vấn.
| Tiêu chí | Inmon (Corporate Information Factory) | Kimball (Dimensional Bus) |
|---|---|---|
| Điểm xuất phát | Mô hình dữ liệu toàn doanh nghiệp chuẩn hoá trước | Từng quy trình nghiệp vụ, mô hình chiều |
| Cấu trúc lõi | Kho chuẩn hoá dạng 3NF, data mart sinh ra từ đó | Bảng fact và dimension dùng chung (conformed) |
| Thời gian ra kết quả đầu | Dài, cần thiết kế tổng thể | Ngắn, làm từng mảng |
| Rủi ro chính | Dự án kéo dài, mất hậu thuẫn lãnh đạo | Các mart lệch nhau nếu không giữ kỷ luật dimension chung |
| Phù hợp | Tập đoàn nhiều hệ thống, yêu cầu kiểm toán chặt | Doanh nghiệp vừa, cần thấy giá trị sớm |
Với doanh nghiệp Việt Nam quy mô vừa, cách thực dụng thường là: bắt đầu theo Kimball với một quy trình có giá trị rõ (bán hàng hoặc công nợ), nhưng ngay từ đầu định nghĩa chung các dimension khách hàng, sản phẩm, thời gian, chi nhánh để mảng thứ hai, thứ ba ghép vào không phải làm lại.
Vì sao không chạy báo cáo thẳng trên phần mềm nghiệp vụ
Câu hỏi đầu tiên của nhiều chủ doanh nghiệp là: phần mềm ERP đã có báo cáo, sao phải xây thêm? Có ba lý do kỹ thuật và một lý do quản trị. Thứ nhất, cơ sở dữ liệu nghiệp vụ được tối ưu cho hàng nghìn giao dịch nhỏ mỗi giây; một truy vấn quét ba năm hoá đơn có thể khoá bảng và làm quầy thu ngân chậm lại. Thứ hai, phần mềm nghiệp vụ thường không giữ lịch sử thay đổi của danh mục. Thứ ba, mỗi phần mềm chỉ thấy dữ liệu của chính nó, trong khi câu hỏi giá trị nhất luôn cắt ngang: lợi nhuận theo kênh cần cả doanh thu từ POS, chi phí quảng cáo từ nền tảng số và chi phí giao hàng từ đơn vị vận chuyển.
Lý do quản trị là định nghĩa. "Doanh thu" của phòng kinh doanh tính theo đơn đã chốt, của kế toán tính theo hoá đơn đã xuất, của kho tính theo hàng đã giao. Cả ba đúng trong ngữ cảnh của mình. Kho dữ liệu buộc doanh nghiệp viết ra định nghĩa nào dùng cho báo cáo nào, và tính một lần ở một chỗ. Đây là lý do một dự án kho dữ liệu thành công thường được nhớ đến vì chấm dứt các cuộc họp cãi nhau về số, hơn là vì một biểu đồ đẹp.
Dấu hiệu doanh nghiệp đã cần, và chưa cần, kho dữ liệu
Kho dữ liệu không phải bước bắt buộc của chuyển đổi số. Bảng dưới giúp bạn tự đánh giá trước khi nghe báo giá.
| Dấu hiệu | Chưa cần | Đã cần |
|---|---|---|
| Số hệ thống nguồn | Một phần mềm quản lý gần như mọi thứ | Từ ba hệ thống trở lên phải ghép số |
| Thời gian làm báo cáo tháng | Vài giờ | Nhiều ngày, phụ thuộc một hai người |
| Tranh cãi số liệu | Hiếm | Họp giao ban thường mở đầu bằng "số này lấy ở đâu" |
| Nhu cầu lịch sử | Chỉ cần tháng này so tháng trước | Cần xu hướng nhiều năm, so sánh theo cơ cấu cũ |
| Khối lượng | Bảng tính còn mở được | Tệp Excel vượt giới hạn dòng, Power Query chạy hàng giờ |
Nếu phần lớn câu trả lời rơi vào cột giữa, một công cụ BI đọc thẳng từ phần mềm hiện có, cộng một bảng định nghĩa chỉ số viết tay, thường đủ trong một hai năm. Xây kho quá sớm là trả chi phí bảo trì cho một hệ thống chưa có câu hỏi để trả lời.
Chi phí thật và những sai lầm làm dự án kho dữ liệu thất bại
Chi phí lớn nhất là con người, không phải hạ tầng. Kho trên đám mây có thể bắt đầu với chi phí lưu trữ và tính toán khá thấp; phần tốn là kỹ sư dữ liệu viết và bảo trì luồng nạp, cùng thời gian của người nghiệp vụ để chốt định nghĩa. Dự toán chỉ tính bản quyền phần mềm là dự toán thiếu.
Sai lầm 1: nạp mọi thứ trước, hỏi câu hỏi sau. Kéo toàn bộ bảng từ mọi hệ thống về với hy vọng "sau này sẽ dùng" tạo ra kho đầy dữ liệu mà không ai biết bảng nào đáng tin. Hãy bắt đầu từ năm đến mười câu hỏi quản trị cụ thể và chỉ nạp dữ liệu phục vụ chúng.
Sai lầm 2: giao trọn cho phòng CNTT. Quy tắc nghiệp vụ (trả hàng trừ vào kỳ nào, khuyến mãi phân bổ thế nào) phải do người làm nghiệp vụ quyết. Phòng CNTT thiếu thẩm quyền chốt, nên dự án trôi.
Sai lầm 3: không có người sở hữu sau khi bàn giao. Nguồn dữ liệu thay đổi liên tục: ERP nâng cấp, thêm kênh bán mới, đổi bảng mã. Không có người chịu trách nhiệm cập nhật, chỉ sau vài tháng số liệu lệch và người dùng quay về Excel.
Sai lầm 4: đo thành công bằng số dashboard. Thước đo đúng là số quyết định được ra dựa trên kho, thời gian đóng báo cáo tháng giảm bao nhiêu, và số lần hai phòng ban còn cãi nhau về một con số.
Kho trên đám mây hay tại chỗ: đánh đổi cần biết
Mười năm trước, xây kho dữ liệu đồng nghĩa với mua máy chủ, mua bản quyền cơ sở dữ liệu phân tích và thuê người quản trị. Kho dữ liệu đám mây đổi mô hình chi phí từ đầu tư một lần sang trả theo mức dùng, và tách lưu trữ khỏi tính toán: dữ liệu nằm yên với chi phí thấp, chỉ khi chạy truy vấn mới phát sinh tiền tính toán. Với doanh nghiệp vừa, điều này hạ rào cản khởi đầu đáng kể và bỏ được phần việc vá lỗi, sao lưu, nâng cấp phần cứng.
Đổi lại có ba điểm cần cân nhắc. Một là chi phí khó dự báo: một báo cáo viết kém, tự làm mới mỗi năm phút và quét toàn bộ bảng có thể đốt ngân sách cả tháng trong vài ngày; cần đặt hạn mức và theo dõi chi phí theo người dùng, theo báo cáo. Hai là nơi lưu dữ liệu: một số loại dữ liệu có yêu cầu riêng về lưu trữ trong nước hoặc chuyển ra nước ngoài, cần đối chiếu quy định hiện hành về dữ liệu và bảo vệ dữ liệu cá nhân trước khi chọn vùng. Ba là đường truyền: nếu nguồn là máy chủ ERP đặt tại văn phòng, luồng nạp hằng đêm phụ thuộc kết nối internet của văn phòng đó.
Kho tại chỗ vẫn hợp lý khi doanh nghiệp đã có hạ tầng và đội vận hành tốt, khối lượng ổn định, hoặc có ràng buộc pháp lý chặt. Điều không nên làm là chọn theo cảm giác "đám mây hiện đại hơn" hay "tại chỗ an toàn hơn". An toàn phụ thuộc vào cấu hình phân quyền và quy trình nhiều hơn là vị trí đặt máy.
Câu hỏi thường gặp
Kho dữ liệu khác cơ sở dữ liệu thông thường thế nào?
Về công nghệ, kho dữ liệu cũng là một cơ sở dữ liệu. Khác biệt nằm ở mục đích và thiết kế: cơ sở dữ liệu nghiệp vụ tối ưu cho ghi và sửa từng giao dịch, còn kho tối ưu cho đọc và tổng hợp khối lượng lớn, thường lưu theo cột, giữ lịch sử và tích hợp nhiều nguồn.
Data mart là gì, có thay được kho dữ liệu không?
Data mart là một phần kho phục vụ một nhóm người dùng, ví dụ mart tài chính. Có thể bắt đầu bằng một mart, nhưng nếu mỗi phòng tự xây mart riêng với định nghĩa khách hàng, sản phẩm riêng, bạn sẽ có nhiều nguồn sự thật mâu thuẫn, đúng vấn đề kho dữ liệu sinh ra để giải quyết.
Doanh nghiệp nhỏ có nên xây kho dữ liệu trên đám mây ngay từ đầu không?
Đám mây giảm rào cản hạ tầng, nhưng không giảm việc thống nhất định nghĩa và bảo trì luồng nạp. Nếu chưa có người phụ trách dữ liệu và câu hỏi quản trị rõ ràng, một mô hình BI gọn đọc thẳng nguồn thường hiệu quả hơn về chi phí trong giai đoạn đầu.
Kho dữ liệu nên cập nhật bao lâu một lần?
Tuỳ quyết định mà nó phục vụ. Báo cáo tài chính và chiến lược thường chỉ cần cập nhật hằng đêm. Điều phối giao hàng hay tồn kho bán lẻ có thể cần cập nhật theo giờ hoặc gần thời gian thực, với chi phí kỹ thuật cao hơn đáng kể. Hỏi "quyết định nào thay đổi nếu số mới hơn" trước khi đòi thời gian thực.
Ai nên sở hữu kho dữ liệu trong tổ chức?
Hạ tầng thường do nhóm dữ liệu hoặc CNTT vận hành, nhưng từng mảng dữ liệu phải có chủ sở hữu nghiệp vụ: giám đốc tài chính chịu trách nhiệm định nghĩa doanh thu, giám đốc kinh doanh chịu trách nhiệm danh mục khách hàng. Mô hình chia đôi trách nhiệm này giúp kho không thành dự án riêng của phòng kỹ thuật.
Dữ liệu cá nhân của khách hàng trong kho cần lưu ý gì?
Kho tập trung dữ liệu nên rủi ro rò rỉ cũng tập trung. Cần phân quyền theo vai trò, che hoặc mã hoá trường nhạy cảm, ghi nhật ký truy cập và chỉ giữ dữ liệu cá nhân khi có mục đích rõ. Các nghĩa vụ cụ thể cần đối chiếu quy định bảo vệ dữ liệu cá nhân hiện hành của Việt Nam.