Case Study: Thiết kế Data Warehouse chuẩn Kimball và tự động hóa Pipeline cho chuỗi bán lẻ đa kênh

vn Cole

56 phút trước

4 phút đọc

Một trong những bài toán kinh điển nhất mà một Data Engineer phải đối mặt khi gia nhập doanh nghiệp là: Xây dựng một hệ thống dữ liệu tập trung cho mô hình bán lẻ đa kênh (Omnichannel Retail) với hàng triệu đơn hàng mỗi tháng.

Bài viết này chia sẻ chi tiết case study thực tế: Từ việc tiếp nhận hiện trạng phân mảnh, xác định mô hình dữ liệu, xây dựng đường ống tự động hóa, cho đến việc phục vụ trực quan hóa dữ liệu theo thời gian thực.

KIẾN TRÚC HỆ THỐNG GIẢI PHÁP:

[Nguồn: Web / POS / CRM]
           │
           ▼
[Airflow Ingestion Pipeline]
           │
           ▼
[Google Cloud Storage (Data Lake - Parquet)]
           │
           ▼
[BigQuery: Staging Tables]
           │
     (dbt Modeling)
           │
           ├─► Dim_Customer (SCD Type 2)
           ├─► Dim_Product
           ├─► Dim_Store
           └─► Fact_Sales_Transactions
           │
           ▼
[Power BI Dashboard: Báo cáo Doanh thu & Tồn kho]

1. Đề bài và hiện trạng ban đầu

Doanh nghiệp có chuỗi 50 cửa hàng vật lý và hệ thống bán hàng trực tuyến qua Website, TikTok Shop và Shopee.

Dữ liệu phân mảnh:
- Đơn hàng tại cửa hàng lưu trữ tại cơ sở dữ liệu PostgreSQL (hệ thống POS).
- Đơn hàng trực tuyến lưu tại MySQL.
- Thông tin khách hàng và khiếu nại nằm rải rác trên HubSpot CRM và các file Google Sheets nội bộ.
Hậu quả: Bộ phận phân tích mất 3 ngày vào mỗi đầu tuần để ghép nối dữ liệu thủ công. Báo cáo tồn kho sai lệch liên tục dẫn đến tình trạng hàng hóa nơi thừa nơi thiếu.

2. Thiết kế kiến trúc Data Warehouse theo mô hình Ralph Kimball

Để giải quyết bài toán trên, đội ngũ kỹ thuật quyết định xây dựng kho dữ liệu tập trung với mô hình Star Schema (Lược đồ hình sao) gồm 1 bảng Fact trung tâm và 4 bảng Dimension liên kết.

1. Bảng Fact chính: Fact_Sales

Lưu trữ từng dòng sản phẩm được bán ra trong mỗi giao dịch (Transaction Grain):

Khóa ngoại: date_key, customer_key, product_key, store_key.
Chỉ số đo lường (Metrics): quantity_sold, unit_price, discount_amount, tax_amount, total_revenue, net_profit.

2. Xử lý bảng Dimension biến đổi chậm: Dim_Customer với SCD Type 2

Khách hàng thường xuyên thay đổi số điện thoại, địa chỉ giao hàng hoặc thứ hạng thành viên (Tier). Để phục vụ phân tích chính xác lịch sử mua hàng theo từng giai đoạn, kỹ thuật Slowly Changing Dimension Type 2 được áp dụng:

-- Cấu trúc bảng Dim_Customer hỗ trợ SCD Type 2
CREATE TABLE dim_customer (
    customer_surrogate_key INT64,    -- Khóa thay thế duy nhất
    customer_id STRING,              -- Khóa nghiệp vụ từ hệ thống gốc
    customer_name STRING,
    phone_number STRING,
    loyalty_tier STRING,             -- Hạng thành viên (Silver, Gold, Platinum)
    city STRING,
    effective_start_date TIMESTAMP,  -- Thời điểm bản ghi bắt đầu có hiệu lực
    effective_end_date TIMESTAMP,    -- Thời điểm bản ghi hết hiệu lực
    is_current BOOLEAN               -- Đánh dấu bản ghi mới nhất (TRUE/FALSE)
);

3. Xây dựng Pipeline tự động hóa với Airflow và dbt

Quy trình vận hành dữ liệu được lập trình tự động hóa hoàn toàn theo các bước:

Extract & Load: Một DAG trong Apache Airflow chạy định kỳ lúc 01:00 AM mỗi ngày, trích xuất toàn bộ dữ liệu thay đổi (Change Data Capture - CDC) từ các cơ sở dữ liệu POS và MySQL, đóng gói dưới dạng tệp nén Apache Parquet và đẩy lên Cloud Storage.
Transform với dbt: Airflow kích hoạt lệnh dbt run:
- Chạy các mô hình biến đổi SQL để làm sạch, khử trùng lặp dữ liệu thô.
- Cập nhật các bảng Fact và Dimension trên Google BigQuery.
- Kích hoạt dbt test để tự động kiểm tra tính duy nhất (uniqueness), kiểm tra giá trị null (not_null) và tính toàn vẹn tham chiếu (referential integrity).
Phục vụ trực quan hóa (Data Visualization):
- Kết nối BigQuery với Power BI thông qua chế độ kết hợp (Dual / DirectQuery cho bảng Fact lớn và Import cho các bảng Dimension).
- Xây dựng các báo cáo quản trị trực quan: Phân tích giỏ hàng (Market Basket Analysis), Tỷ lệ rời bỏ của khách hàng (Churn Rate) và Tối ưu hóa vòng quay hàng tồn kho theo từng chi nhánh.

4. Kết quả đạt được

Thời gian tạo báo cáo kinh doanh được rút ngắn từ 3 ngày xuống còn 0 phút (hệ thống tự động sẵn sàng vào 06:00 sáng mỗi ngày).
Độ chính xác của số liệu tồn kho đạt 99.8%, giúp giảm 20% chi phí lưu kho dư thừa.
Đội ngũ BI có thể tự do kéo thả các chiều phân tích mới chỉ trong vài phút thay vì phải gửi yêu cầu chờ đội IT viết script trích xuất dữ liệu.

5. Bài học rút ra cho kỹ sư dữ liệu

Thành công của dự án trên cho thấy: Năng lực cốt lõi tạo nên giá trị của một Data Engineer không nằm ở việc sử dụng các thuật toán quá phức tạp, mà nằm ở tư duy tổ chức cấu trúc dữ liệu khoa học, am hiểu bài toán kho dữ liệu (Data Warehouse) và khả năng trực quan hóa dữ liệu chuẩn xác phục vụ người dùng cuối.

Những kỹ năng thiết kế kiến trúc thực tế này chính là trọng tâm đào tạo xuyên suốt tại khóa học Data Engineer - Data Warehouse and Data Visualization tại Cole. Khóa học mang đến cho học viên trải nghiệm xây dựng đồ án thực chiến từ số 0 đến một hệ thống Data Warehouse hoàn chỉnh, trang bị nền tảng vững vàng để giải quyết mọi bài toán kỹ thuật dữ liệu phức tạp trong doanh nghiệp.

Xem thêm: https://notes.io/eXrk8