Kho dữ liệu (Data Warehouse) và OLAP

1. Tổng quan

Kho dữ liệu (Data Warehouse, DW) là kho lưu trữ dữ liệu tích hợp được tối ưu cho truy vấn (phân tích) hỗ trợ ra quyết định, bằng cách tích hợp·làm sạch dữ liệu phân tán ở nhiều hệ thống vận hành (OLTP) theo chủ đề (subject), tích lũy theo dòng thời gian và lưu giữ mà không xóa·cập nhật. OLAP (Online Analytical Processing) là công nghệ xử lý phân tích hỗ trợ tổng hợp·khám phá nhanh dữ liệu đã tích lũy như vậy từ góc nhìn đa chiều (multidimensional).

Phần lớn hệ thống thông tin mà doanh nghiệp vận hành được thiết kế cho mục đích OLTP (Online Transaction Processing), xử lý chính xác và nhanh từng giao dịch riêng lẻ như đặt hàng·thanh toán·tồn kho. Cơ sở dữ liệu OLTP được chuẩn hóa nên có lợi cho việc ngăn bất thường cập nhật và xử lý nhiều giao dịch ngắn, nhưng không phù hợp với truy vấn tổng hợp diện rộng kiểu "so sánh xu hướng doanh thu theo khu vực·theo quý trong 3 năm qua theo từng nhóm sản phẩm". Những truy vấn như vậy phải join hàng chục bảng và quét hàng trăm triệu bản ghi nên gây tải cho hệ thống vận hành, và trên hết hệ thống vận hành không lưu giữ lịch sử quá khứ lâu dài. Kho dữ liệu ra đời để lấp khoảng trống này — tích lũy lịch sử trong kho lưu trữ riêng tách khỏi hệ thống vận hành, và tái cấu trúc thành dạng thuận lợi cho phân tích.

Bill Inmon định nghĩa DW là "tập hợp dữ liệu hướng chủ đề (subject-oriented)·tích hợp (integrated)·biến thiên theo thời gian (time-variant)·không biến động (non-volatile)", và bốn đặc tính này trở thành tiêu chí cốt lõi phân biệt DW với DB OLTP. Hướng chủ đề nghĩa là tổ chức dữ liệu theo đơn vị chủ đề nghiệp vụ như 'khách hàng·sản phẩm·doanh thu', tích hợp là chuẩn hóa nhất quán mã·đơn vị·cách biểu diễn của nhiều nguồn, biến thiên theo thời gian là gán mốc thời gian cho snapshot để lưu lịch sử, còn không biến động là về nguyên tắc không cập nhật·xóa sau khi nạp và vận hành theo hướng đọc.

Trong bài luận, điều quan trọng là không thu nhỏ DW thành một "cơ sở dữ liệu lớn" đơn thuần. DW phải được trình bày như một hệ thống kết hợp bốn trục: (1) khác biệt mục đích·cấu trúc so với OLTP, (2) pipeline tích hợp dữ liệu bằng ETL/ELT, (3) kỹ thuật thiết kế là mô hình hóa chiều (lược đồ hình sao/bông tuyết), (4) phân tích đa chiều qua khối OLAP. Gần đây, nếu liên kết thêm quan hệ với data lake·lakehouse, sự trỗi dậy của DW đám mây (MPP) và lưu trữ theo cột thì bài làm sẽ mang tính thời sự.

A. Bối cảnh ra đời và sự cần thiết

Thứ nhất, cần tách biệt hệ thống vận hành và hệ thống phân tích. Nếu ném trực tiếp truy vấn phân tích vào DB vận hành, tranh chấp khóa và quét khối lượng lớn sẽ làm xấu thời gian phản hồi của các giao dịch cốt lõi như đặt hàng·thanh toán. DW cô lập vật lý khối lượng công việc phân tích để bảo vệ hiệu năng hệ thống vận hành, đồng thời cung cấp môi trường riêng được tối ưu cho đọc·tổng hợp.

Thứ hai, đòi hỏi tích hợp dữ liệu và 'nguồn sự thật duy nhất (Single Source of Truth)'. Cùng là 'doanh thu' nhưng nếu định nghĩa và hệ thống mã của các hệ thống kinh doanh·kế toán·logistics khác nhau thì số liệu của mỗi phòng ban sẽ lệch nhau. DW chuẩn hóa mã·đơn vị·tiêu chí trong quá trình ETL để toàn doanh nghiệp diễn giải chỉ số theo cùng một định nghĩa.

Thứ ba, cần tích lũy lịch sử và phân tích xu hướng. Hệ thống vận hành chỉ duy trì trạng thái mới nhất, nhưng quyết định quản trị đòi hỏi phân tích chuỗi thời gian so sánh quá khứ và hiện tại. DW lưu giữ không biến động các snapshot theo thời điểm, cho phép theo dõi xu hướng dài hạn·tính mùa vụ·dấu hiệu bất thường.

2. Cấu trúc tổng thể và luồng dữ liệu

Kho dữ liệu đi qua nhiều tầng từ nguồn tới phân tích cuối cùng. Dữ liệu vận hành·bên ngoài được trích xuất vào vùng staging, qua làm sạch·biến đổi rồi nạp vào DW, được chia thành data mart (Data Mart) phù hợp với từng phòng ban·chủ đề cụ thể và được tiêu thụ bởi công cụ OLAP·BI.

graph LR
    subgraph SRC["Tầng nguồn"]
        A1["DB OLTP (đặt hàng·thanh toán)"]
        A2["ERP/CRM"]
        A3["Dữ liệu bên ngoài/log"]
    end
    subgraph STG["Staging"]
        B["Vùng nạp tạm (bản sao nguồn)"]
    end
    subgraph ETL["ETL/ELT"]
        C["Trích xuất·làm sạch·biến đổi·chuẩn hóa"]
    end
    subgraph DW["Kho dữ liệu"]
        D["Kho tích hợp (mô hình chiều)"]
        E1["Data mart (kinh doanh)"]
        E2["Data mart (tài chính)"]
    end
    subgraph BI["Tầng phân tích·tiêu thụ"]
        F1["Khối OLAP"]
        F2["BI/dashboard"]
        F3["Báo cáo/khai phá dữ liệu"]
    end
    A1 --> B
    A2 --> B
    A3 --> B
    B --> C --> D
    D --> E1
    D --> E2
    E1 --> F1
    E2 --> F1
    F1 --> F2
    D --> F3

Tầng nguồn cung cấp dữ liệu gốc mà DW sẽ tích hợp. Bao gồm không chỉ DB vận hành mà cả các nguồn dị biệt như ERP·CRM, dữ liệu thị trường bên ngoài, web log, mỗi nguồn có lược đồ·hệ thống mã·chu kỳ cập nhật khác nhau. Hấp thụ sự dị biệt này là nhiệm vụ cốt lõi của ETL phía sau.

Vùng staging là vùng đệm chứa tạm dữ liệu gốc trích xuất từ nguồn. Nó tối thiểu hóa thời gian truy cập hệ thống nguồn, và cô lập để dù thất bại giữa lúc biến đổi cũng không ảnh hưởng tới nguồn. Sau khi làm sạch·loại trùng·chuyển kiểu ở staging, dữ liệu mới được chuyển sang DW chính.

Tầng ETL/ELT là trái tim của tích hợp dữ liệu. Trích xuất (Extract) lấy dữ liệu từ nguồn, biến đổi (Transform) thực hiện chuẩn hóa mã·thống nhất đơn vị·xử lý giá trị thiếu·tổng hợp·tạo khóa thay thế (surrogate key), và nạp (Load) đưa kết quả vào DW. ETL truyền thống biến đổi ở engine riêng rồi mới nạp, nhưng khi năng lực tính toán của DW đám mây lớn lên, ELT — nạp trước rồi biến đổi bằng SQL bên trong DW — đã lan rộng.

Tầng DW·data mart lưu dữ liệu đã tích hợp dưới dạng mô hình chiều. Đặt kho tích hợp toàn doanh nghiệp ở trung tâm và phái sinh các data mart — tập con phù hợp với phòng ban·chủ đề cụ thể như kinh doanh·tài chính — để cải thiện hiệu năng truy vấn và kiểm soát truy cập. Triết lý thiết kế tiêu biểu là cách từ trên xuống kiểu Inmon (DW trung tâm→mart) và cách từ dưới lên kiểu Ralph Kimball (tích hợp mart→kiến trúc bus).

3. Mô hình hóa chiều và các phép toán OLAP

Kỹ thuật cốt lõi trong thiết kế DW là mô hình hóa chiều (Dimensional Modeling). Đặt các giá trị đo (doanh thu·số lượng v.v.) là đối tượng phân tích vào bảng sự kiện (Fact Table), tách các góc nhìn phân tích (thời gian·sản phẩm·khu vực·khách hàng v.v.) thành bảng chiều (Dimension Table), tạo thành lược đồ hình sao (Star Schema) trong đó các chiều nối với bảng sự kiện ở trung tâm theo hình ngôi sao. Bảng chiều được cố ý phi chuẩn hóa để giảm số lần join và tăng hiệu năng truy vấn.

graph TD
    F["Sự kiện: Doanh thu<br/>Doanh thu·số lượng·chiết khấu"]
    D1["Chiều: Thời gian (ngày·tháng·quý)"]
    D2["Chiều: Sản phẩm (sản phẩm·danh mục)"]
    D3["Chiều: Khu vực (cửa hàng·thành phố·vùng)"]
    D4["Chiều: Khách hàng (hạng·nhóm tuổi)"]
    D1 --> F
    D2 --> F
    D3 --> F
    D4 --> F
    D2 --> DS["Chuẩn hóa danh mục<br/>(bông tuyết)"]

Nếu chuẩn hóa lại các chiều của lược đồ hình sao và tách các phân cấp thành bảng riêng thì sẽ thành lược đồ bông tuyết (Snowflake Schema). Lược đồ bông tuyết giảm trùng lặp lưu trữ và làm rõ việc quản lý phân cấp, nhưng số join tăng khiến truy vấn phức tạp hơn và hiệu năng có thể giảm. Do đó, thông lệ thực tế là chọn bông tuyết khi hiệu quả lưu trữ và toàn vẹn phân cấp quan trọng, và chọn hình sao khi hiệu năng truy vấn và sự đơn giản được ưu tiên. Kỹ thuật SCD (Slowly Changing Dimension) xử lý khi giá trị chiều thay đổi theo thời gian (ví dụ: thay đổi hạng khách hàng) cũng quan trọng; tiêu biểu là Type 1 ghi đè, Type 2 thêm dòng lịch sử, Type 3 lưu giá trị trước đó thành cột. Ví dụ, trong phân tích marketing, muốn xem "mẫu mua hàng trước và sau khi lên hạng VIP" thì phải dùng Type 2 để lưu lịch sử thay đổi hạng.

Các phép toán OLAP là thao tác chuẩn để khám phá khối (cube) đa chiều được cấu thành như vậy. Người dùng phân tích dữ liệu từ nhiều góc độ bằng các phép toán sau.

Các phép toán này hỗ trợ nguyên vẹn quá trình khám phá tự nhiên mà ban lãnh đạo thu hẹp dần từ "toàn thể → vùng bất thường → nguyên nhân". Ví dụ, khi doanh thu toàn doanh nghiệp giảm, nhận ra bất thường ở mức Roll-up, đào sâu bằng Drill-down xem vùng·sản phẩm nào là nguyên nhân, và dùng Slice/Dice cô lập điều kiện cụ thể để làm rõ nguyên nhân.

4. So sánh các kiểu hiện thực OLAP và khác biệt với OLTP

OLAP được chia thành ba cách tùy theo lưu dữ liệu ở đâu·như thế nào, mỗi cách có đánh đổi khác nhau về hiệu năng·khả năng mở rộng·tính linh hoạt. Cốt lõi của so sánh dưới đây là nguyên lý "tính trước thì nhanh nhưng giảm linh hoạt và khả năng mở rộng, giao cho quan hệ thì linh hoạt và mở rộng được nhưng phản hồi chậm hơn".

MOLAP tính trước các tổng hợp và lưu vào khối nên phản hồi nhanh, nhưng khi số chiều và tổ hợp tăng thì lượng tổng hợp trước tăng vọt — vấn đề 'bùng nổ dữ liệu (data explosion)'. ROLAP đặt dữ liệu dạng lược đồ hình sao trong DB quan hệ và tổng hợp tại thời điểm truy vấn nên mạnh với dữ liệu lớn và truy vấn tùy ý nhưng phản hồi có thể chậm. HOLAP đặt các tóm tắt hay dùng vào khối và chi tiết vào quan hệ để dung hòa hai cách.

Đối chiếu rõ khác biệt giữa DW/OLAP và OLTP sẽ làm rõ căn cứ cho phán đoán thiết kế.

Đặc biệt, khác biệt về cách lưu trữ gắn trực tiếp với hiệu năng. Truy vấn phân tích tổng hợp một vài cột trên khối lượng hàng lớn, nên hướng cột (lưu trữ theo cột) — lưu liên tiếp các giá trị cùng cột — có lợi thế áp đảo về I/O và nén. Việc các DW đám mây như Amazon Redshift, Google BigQuery, Snowflake kết hợp lưu trữ theo cột và MPP (Massively Parallel Processing) để xử lý tổng hợp hàng tỷ dòng trong vài giây chính là sự hiện thực công nghiệp của nguyên lý này.

5. Chuyên sâu — Tiến hóa sang DW đám mây·lakehouse

DW truyền thống được xây dựng on-premise với dung lượng cố định, nên gặp vấn đề hoặc đầu tư quá mức theo tải phân tích đỉnh, hoặc ngược lại thiếu tài nguyên. Từ những năm 2010, kho dữ liệu đám mây đã thay đổi giới hạn này. Snowflake đưa vào tách biệt lưu trữ và tính toán (decoupled storage/compute), cho phép nhiều kho ảo mở rộng·tính phí độc lập trên cùng dữ liệu — nạp khối lượng lớn và phân tích tương tác không can thiệp lẫn nhau, và chỉ trả tiền cho phần đã dùng. BigQuery hỗ trợ truy vấn quy mô petabyte theo kiểu serverless không cần quản lý hạ tầng, còn Redshift tách compute/storage bằng node RA3.

Mặt khác, chỉ với DW có cấu trúc thì khó chứa dữ liệu phi cấu trúc·bán cấu trúc như log·hình ảnh·văn bản, nên data lake (Data Lake) được đưa vào song song, nhưng lake yếu về quản trị·lược đồ·giao dịch nên dễ biến thành 'đầm lầy dữ liệu (swamp)'. Thứ hợp nhất chúng là data lakehouse (Lakehouse), dùng các định dạng bảng mở như Delta Lake·Apache Iceberg·Hudi trên object storage giá rẻ để bổ sung giao dịch ACID·tiến hóa lược đồ·time travel, kết hợp độ tin cậy của DW với tính linh hoạt của lake. Tức là dòng DW→lake→lakehouse có thể được hiểu như sự tiến hóa nhằm gộp "độ tin cậy của phân tích có cấu trúc" và "khả năng tiếp nhận dữ liệu đa dạng" làm một.

Ngoài ra, khi nhu cầu ra quyết định thời gian thực tăng, DW truyền thống lấy batch làm trung tâm đang được kết hợp với nạp streaming (CDC·Kafka) và tổng hợp gần thời gian thực. DW trước đây cập nhật mỗi ngày một lần bằng batch ban đêm, nay đang chuyển sang phản ánh trạng thái mới nhất theo đơn vị vài phút thông qua thu thập dữ liệu thay đổi (CDC).

6. Các điểm cần cân nhắc và hàm ý

• Chọn triết lý mô hình hóa (Inmon vs Kimball): Nếu chuẩn hóa·quản trị toàn doanh nghiệp quan trọng thì cách từ trên xuống (Inmon) dựng DW trung tâm trước có lợi; nếu hiện thực giá trị nhanh quan trọng thì cách từ dưới lên (Kimball) tạo mart phòng ban trước rồi tích hợp bằng kiến trúc bus có lợi. Hai cách không đối lập mà là lựa chọn theo mức trưởng thành và ưu tiên của tổ chức, và thực tế dạng hỗn hợp là phổ biến.
• Đánh đổi giữa hiệu năng và tính linh hoạt: Tổng hợp trước (MOLAP)·bảng tóm tắt·materialized view làm phản hồi nhanh nhưng gây chi phí lưu trữ·cập nhật và bùng nổ khối. Cần thiết kế cân bằng: phân tích mẫu truy vấn, chỉ tính trước có chọn lọc các tổng hợp hay dùng, phần còn lại xử lý bằng lưu trữ theo cột·MPP.
• Chất lượng dữ liệu và nguồn sự thật duy nhất: Giá trị của DW đến từ định nghĩa chỉ số được tích hợp. Cùng với chuẩn hóa·kiểm chứng ở giai đoạn ETL, phải liên kết quản trị dữ liệu·quản lý dữ liệu chủ (MDM)·hợp đồng dữ liệu để bảo đảm có tổ chức tính nhất quán của định nghĩa chỉ số. Xác định rõ chiến lược SCD để bảo đảm cả độ chính xác của lịch sử.
• Chi phí·quản trị·triển vọng: DW đám mây tính phí theo lượng sử dụng nên truy vấn lớn thiếu kiểm soát gây bùng nổ chi phí — cần giám sát khối lượng công việc·tối ưu truy vấn·chính sách vòng đời theo góc nhìn FinOps. Vì lưu giữ lâu dài lịch sử có chứa thông tin cá nhân nên kiểm soát truy cập·che giấu (masking)·quản lý thời hạn lưu giữ cũng là bắt buộc. Trong tương lai, DW được dự báo tiến hóa theo hướng hội tụ vào lakehouse, thời gian thực hóa, AI tạo sinh kết hợp với BI (truy vấn bằng ngôn ngữ tự nhiên), và Kỹ sư chuyên nghiệp (Professional Engineer) phải phán đoán tổng hợp điều này cùng với mức trưởng thành phân tích·quy định·ràng buộc chi phí của tổ chức.

Tài liệu tham khảo

• Kimball Group, "Dimensional Modeling Techniques", https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/
• Snowflake, "What Is a Data Warehouse?", https://www.snowflake.com/guides/what-data-warehouse
• Databricks, "What is a Data Lakehouse?", https://www.databricks.com/glossary/data-lakehouse
• AWS, "What is OLAP?", https://aws.amazon.com/what-is/olap/

Tóm tắt một câu: Kho dữ liệu là kho lưu trữ chuyên dụng cho phân tích, tách khỏi hệ thống vận hành và tích lũy lịch sử theo nguyên tắc hướng chủ đề·tích hợp·biến thiên theo thời gian·không biến động; nó hỗ trợ phân tích đa chiều bằng mô hình hóa chiều (hình sao/bông tuyết) và các phép toán OLAP (roll-up·drill-down·slice·dice·pivot), và gần đây đang tiến hóa thành DW đám mây dựa trên lưu trữ theo cột·MPP và lakehouse.