Cube — Semantic & Metrics Layer của DataValue

Sau Airbyte (đưa dữ liệu vào), ClickHouse (lưu & xử lý) và dbt (Trusted Business Data Model), DataValue đã có dữ liệu khá tốt — thay vì bảng kỹ thuật Odoo (sale_order, sale_order_line, res_partner, product_product, account_move), dbt tạo DimCustomer, DimProduct, DimDate, FactSales, FactInvoice, FactInventory. Nhưng vẫn còn một vấn đề: “Revenue là gì? Gross Margin tính thế nào? Active Customer là giao dịch trong 30, 60 hay 90 ngày? một Product thuộc Product Category nào? AI Agent và Power BI có đang hiểu cùng một Revenue không?”. Đây không còn là lưu trữ hay transformation — mà là Business Meaning (ngữ nghĩa kinh doanh). Đó là vai trò của Cube.

Cube là gì?

Cube là một nền tảng Semantic Layer, với Cube Core là phần lõi mã nguồn mở. Semantic Layer nằm giữa Data Platform và những công cụ sử dụng dữ liệu:

flowchart TB
  CH["ClickHouse"] --> DBT["dbt"] --> CUBE["CUBE · Semantic & Metrics Layer"]
  CUBE --> BI["BI"] & AI["AI Agents"] & APP["Apps"]

Cube định nghĩa tập trung: Metrics · Measures · Dimensions · Entities · Relationships · Join Paths · Hierarchies · Access Rules — rồi cung cấp cho tất cả consumer phía trên. Cube mô tả nguyên tắc rõ: định nghĩa metric một lần trong một governed model, sau đó dashboard, embedded application và AI Agent cùng đọc từ model đó. Cô đọng: Cube biến Data Model thành Business Meaning.

Tại sao có dbt rồi vẫn cần Cube?

Câu hỏi quan trọng nhất. dbt và Cube không thay thế nhau — chúng giải hai lớp khác nhau. dbt trả lời “dữ liệu nên được cấu trúc thế nào?” (FactSales, DimCustomer, DimProduct, DimDate). Cube trả lời “dữ liệu đó có ý nghĩa kinh doanh thế nào?” (Revenue, Gross Margin, Average Selling Price, Active Customer, Sales Growth, Customer Lifetime Value). Cube cũng phân biệt rõ: transformation tools như dbt định hình & kiểm thử dữ liệu trong warehouse, còn Semantic Layer định nghĩa metrics/dimensions/joins/access rules trên các model đó.

flowchart LR
  AB["Airbyte"] --> CH["ClickHouse"] --> DBT["dbt · Data Model"] --> CUBE["Cube · Business Meaning"]

Vấn đề lớn nhất: cùng một KPI nhưng nhiều công thức khác nhau

Lấy ví dụ Revenue. Không có Semantic Layer, doanh nghiệp rất dễ rơi vào: Finance Dashboard: Revenue = Invoice Amount; Sales Dashboard: Revenue = Confirmed Sales Order; Management Dashboard: Revenue = Sales − Returns; AI Agent: Revenue = SUM(amount_total); Excel: một công thức khác. Tất cả đều gọi là Revenue nhưng con số khác nhau — một trong những nguyên nhân lớn nhất khiến người dùng mất niềm tin vào Analytics. Cube giải quyết bằng cách đưa định nghĩa Revenue ra khỏi từng dashboard:

flowchart TB
  REV["Revenue · Defined Once · Governed Once"]
  REV --> PBI["Power BI"] & AIA["AI Agent"] & APP["Application"]

💡 Nguyên tắc cốt lõi

Define Once — Use Everywhere. Semantic Layer tồn tại chính để tránh việc mỗi công cụ tự tái tạo cùng một business logic.

Các thành phần của Semantic Model

Cube định nghĩa Measures

Measure là những giá trị doanh nghiệp muốn đo lường. Ví dụ Sales Model có thể định nghĩa: Revenue, Net Revenue, Quantity, Discount, Cost, Gross Margin, Order Count, Customer Count, Average Order Value. Logic được quản lý tập trung: Gross Revenue − Discount − Returns → Net Revenue; Net Revenue − Cost → Gross Margin — thay vì Power BI tự xây Gross Margin và AI Agent lại tự viết SQL tính Gross Margin.

Cube định nghĩa Dimensions

Measure trả lời “Bao nhiêu?”; Dimension trả lời “Theo cái gì?”. Revenue có thể phân tích theo Date, Customer, Product, Region, Salesperson, Channel, Organization. Business hỏi Revenue theo Product? theo Region? theo Customer? theo Month? theo Product × Region × Month?. Cube quản lý các dimension và cách chúng liên hệ với metrics trong Semantic Model.

Cube định nghĩa Relationships và Join Paths

Capability quan trọng hơn nhiều so với chỉ có Metrics Layer. Giả sử có FactSales → {Customer, Product, Organization, Date}. Nếu người dùng hỏi “Revenue của Product Category A theo Customer Region?”, một BI tool hoặc AI Agent không nên tự đoán phải join bảng nào với bảng nào. Cube định nghĩa relationships và join paths từ trước (Sales → {Customer → Region, Product → Category}), nên consumer chỉ cần yêu cầu Measure: Revenue; Dimensions: Product Category, Customer Region — Semantic Layer biết phải truy vấn data model thế nào. Cube gọi tập business entities và relationships này là data graph.

Cube và Hierarchy

Business data thường có cấu trúc phân cấp: Organization (Group → Company → Region → Branch), Product (Category → Subcategory → Product), Time (Year → Quarter → Month → Date), Customer (Segment → Customer Group → Customer). Semantic Layer giúp các công cụ phía trên hiểu những cấu trúc này một cách thống nhất — một lý do Cube có ý nghĩa vượt xa việc chỉ tạo một danh sách KPI.

Ví dụ: Revenue Analytics trong DataValue

Nối toàn bộ pipeline: Odoo (Customer → Sales Order → Invoice → Payment) → Airbyte (Odoo → ClickHouse) → dbt (Raw Sales → Staging → Business Models → FactSales, DimCustomer, DimProduct, DimDate) → Cube định nghĩa MEASURES {Revenue, Net Revenue, Quantity, Cost, Gross Margin, Average Selling Price} và DIMENSIONS {Customer, Product, Region, Salesperson, Channel, Period} → BI (Power BI/Superset yêu cầu Revenue by Month/Margin by Product/Revenue by Customer/Region). Mọi dashboard đều dùng cùng Semantic Model — hành trình Transaction → Data → Model → Meaning → Insight.

Ví dụ: Active Customer — One Business Definition

Ví dụ rất tốt để hiểu giá trị Semantic Layer. “Active Customer” có thể là (A) có ít nhất một Sales Order trong 90 ngày; (B) có Invoice phát sinh trong 90 ngày; (C) có Net Revenue > 0 trong 90 ngày. Nếu mỗi dashboard tự định nghĩa, doanh nghiệp có ba số Active Customer khác nhau. Cube quản trị business definition tập trung (ACTIVE CUSTOMER = Customer with Net Revenue > 0 during last 90 days) → Power BI → 12,450, AI Agent → 12,450, Application → 12,450. Đây chính là One Business Definition.

Ranh giới: Cube không phải database, cũng không phải BI

Cube không phải database

Cube không thay ClickHouse. ClickHouse vẫn là nơi Store & Compute Data; Cube nằm phía trên (ClickHouse → Cube). Khi một consumer hỏi “Revenue by Region?”, Cube hiểu business request, xác định metric/dimension/join path, rồi tạo truy vấn phù hợp xuống analytical database. Semantic Layer không trở thành một Data Warehouse thứ hai — Cube tự mô tả là lớp nằm trên warehouse, không thay thế storage & compute engine bên dưới.

Cube không phải BI

Cube cũng không thay Power BI, Superset hay Tableau. BI chịu trách nhiệm Visualization · Dashboard · Exploration · User Experience; Cube chịu trách nhiệm Business Semantics · Metrics · Relationships · Governance (ClickHouse → dbt → Cube → {Power BI, Superset, Application}). Điểm quan trọng: BI không còn phải sở hữu toàn bộ business logic — BI trở thành consumer của governed business semantics.

Nhiều cách truy cập — Headless / Universal Semantic Layer

Một lợi thế của Universal/Headless Semantic Layer là Semantic Model không bị khóa trong một visualization tool. Cube cung cấp nhiều query interface — SQL · REST · GraphQL · MCP (và các interface khác tùy nền tảng/use case):

flowchart TB
  CUBE["CUBE"]
  CUBE --> SQL["SQL → BI"]
  CUBE --> REST["REST → Apps"]
  CUBE --> GQL["GraphQL → Embedded"]
  CUBE --> MCP["MCP → AI Agent"]

Rất hợp triết lý DataValue — không chỉ phục vụ Dashboard mà cả Applications · APIs · AI Agents · Automation.

Cube đặc biệt quan trọng với AI

Nếu chỉ có BI, metric không thống nhất đã là vấn đề. Với AI, vấn đề còn lớn hơn. Giả sử AI Agent nối trực tiếp vào ClickHouse và được hỏi “Gross Margin tháng này bao nhiêu?” — AI phải tự đoán: Which table? Which joins? Which revenue field? Should returns be excluded? Which cost field? What currency? What date? Which status?. Một prompt khác có thể tạo một SQL khác → cùng câu hỏi ra những con số khác nhau. Kiến trúc tốt hơn: User → AI Agent → Cube → Certified Metric (Gross Margin) → ClickHouse. AI không còn phải phát minh lại business logic — nó lựa chọn metrics/dimensions đã được kiểm soát. Cube nhấn mạnh Semantic Layer cho AI Agents vì agent có thể truy cập certified semantics thay vì tự viết lại logic từ raw tables.

MCP — cầu nối Semantic Layer với AI Agents

Cube hỗ trợ Model Context Protocol — MCP để AI Agent khám phá và sử dụng governed semantic model (AI Agent → MCP → Cube {Revenue, Gross Margin, Customer, Product, Region, Period} → ClickHouse). Agent có thể hiểu: những measures nào tồn tại? dimensions nào được phép dùng? metric này có thể filter theo gì? — chuyển từ AI → Raw Schema → Guess SQL sang AI → Semantic Model → Governed Query. Với DataValue, đây là bước rất quan trọng để tiến tới Trusted AI.

Access Control

Semantic Layer không chỉ định nghĩa metric — nó còn có thể áp dụng các access rules. Ví dụ CEO → All Companies, Company Director → Own Company, Regional Manager → Own Region, Sales Manager → Own Sales Team. Cube hỗ trợ access control ở semantic/query layer (tài liệu mô tả row-level và multi-tenant security là một phần của semantic architecture). Đặc biệt quan trọng khi semantic model được dùng bởi cả BI users + Applications + AI Agents.

Caching & Pre-aggregations

Semantic Layer không chỉ giúp governance — Cube có capability caching và pre-aggregation để tăng hiệu năng analytical queries và giảm tải cho data warehouse. Ví dụ Management Dashboard liên tục hỏi Revenue by Month/Region/Product; thay vì mỗi người dùng scan lượng lớn transactions từ đầu, một số aggregation được chuẩn bị trước (1 Billion Transactions → ClickHouse → Cube Pre-Aggregation → Monthly Revenue by Region/Product → Dashboard). Đặc biệt quan trọng khi số user tăng, số dashboard tăng, embedded analytics phục vụ nhiều khách hàng, hay AI Agent tạo nhiều follow-up query liên tục.

Ví dụ Inventory & Customer 360

Inventory Semantic Model: sau dbt có FactInventoryMovement, FactInventoryBalance, DimProduct, DimWarehouse, DimDate; Cube định nghĩa Inventory On Hand, Inventory Value, Inventory Turnover, Days of Inventory, Stock-out Quantity, Slow-moving Inventory với dimensions Product, Product Category, Warehouse, Organization, Region, Period — Management Dashboard và AI Agent đều hỏi “Inventory Turnover theo Product Category?” hoặc “Warehouse nào Days of Inventory cao bất thường?” trên cùng một Semantic Model. Customer 360: tương lai tích hợp Odoo, CRM, eCommerce, Marketing, Customer Service, Digital Events; dbt tạo DimCustomer, FactSales, FactInteraction, FactService, FactDigitalBehavior; Cube định nghĩa Customer Revenue, Customer Margin, Purchase Frequency, Average Order Value, Last Purchase Date, Active Customer, Customer Lifetime Value → AI Agent hỏi “khách giá trị cao nào đang giảm mua?” → Cube → AI → Recommendation → n8n → CRM Task. Đây là lúc Semantic Layer trở thành một phần trực tiếp của Data-to-Action.

Cube và n8n nằm ở hai vị trí rất khác nhau

Cube giúp hệ thống hiểu dữ liệu; n8n giúp hệ thống thực hiện hành động. Kiến trúc: ClickHouse → dbt → Cube (Understand) → AI (Reason) → n8n (Act). Ngắn gọn: Cube = Understand · AI = Reason · n8n = Act — ba capability rất khác nhau nhưng bổ sung nhau.

Lựa chọn & định vị

Cube giúp DataValue không phụ thuộc một BI Tool

Hôm nay dùng Superset (Cube → Superset); mai khách dùng Power BI (Cube → {Superset, Power BI}); một application cần embedded analytics; rồi AI Agent xuất hiện (Cube → {BI, Applications, AI Agents}). Semantic definitions vẫn nằm ở cùng một nơi — một trong những lợi ích chiến lược lớn nhất của Headless/Universal Semantic Layer.

Cube Core & Open Source

Cube Core hiện là semantic-layer foundation mã nguồn mở theo Apache 2.0, cho phép DataValue xây stack Airbyte → ClickHouse → dbt → Cube Core → Superset/BI/AI mà không mặc định khóa Semantic Layer vào một BI vendor cụ thể. Với enterprise requirement cao hơn có thể đánh giá các deployment/commercial capabilities tương ứng, nhưng capability vẫn giữ nguyên: Semantic & Metrics Layer.

Cube so với Power BI Semantic Model

Nếu doanh nghiệp chỉ dùng Power BI thì câu hỏi hợp lý là “tại sao không để Power BI quản lý Semantic Model luôn?” — hoàn toàn có thể (ClickHouse → Power BI Semantic Model → Power BI), lựa chọn rất tốt nếu Power BI là consumer gần như duy nhất. Cube có ý nghĩa hơn khi kiến trúc là SEMANTIC → {Power BI, Applications, AI Agents} — lúc đó business semantics không nên bị giữ trong riêng một visualization platform. Đây là lý do DataValue chọn Cube cho Open Source Universal Semantic Layer, thay vì coi Cube là sản phẩm bắt buộc trong mọi tình huống.

Cube và AtScale

Trong DataValue portfolio, phân biệt rõ: Cube = Open Source / Headless / Developer-oriented Semantic Layer (hợp Open Source Data Stack, APIs, embedded analytics, AI Agents, architecture cần tính mở); AtScale = Enterprise Universal Semantic Layer (hợp enterprise environment yêu cầu cao về enterprise semantic governance, multi-BI consumption, enterprise scale, Power BI/Excel/BI compatibility, centralized metrics). Cube và AtScale không nhất thiết cùng xuất hiện trong một implementation — chúng là hai lựa chọn cho cùng một architectural capability: Semantic & Metrics Layer.

Giá trị của Cube đối với DataValue

Nếu bỏ Cube, DataValue vẫn chạy (Airbyte → ClickHouse → dbt → BI). Nhưng khi xuất hiện nhiều dashboard + nhiều BI tools + application + AI Agent, business logic rất dễ phân tán (Power BI → Revenue Logic A, Superset → Revenue Logic B, AI → Revenue Logic C, Application → Revenue Logic D). Cube đưa tất cả về REVENUE · One Definition cho BI, AI, Apps, mang lại: Consistency · Reusability · Governance · Performance · AI Readiness.

Cube là lớp chuyển từ Trusted Data sang Trusted Meaning

dbt đã tạo Trusted Data; nhưng DataValue còn cần Trusted Meaning. Một bảng có thể hoàn toàn sạch, đầy đủ, đúng kiểu — nhưng nếu Finance và Sales vẫn hiểu “Revenue” khác nhau thì doanh nghiệp vẫn chưa có One Truth. Do đó: Raw Data → Airbyte; Stored Data → ClickHouse; Trusted Data → dbt; Trusted Meaning → Cube; Insight → BI; Intelligence → AI; Action → n8n — vị trí chiến lược của Semantic Layer.

Cube nằm ở đâu trong DataValue?

flowchart TB
  ODOO["ODOO 19 · Operate"] --> AB["AIRBYTE · Ingest"] --> CH["CLICKHOUSE · Store & Process"]
  CH --> DBT["dbt · Transform · Model · Test"] --> CUBE["CUBE · Semantic · Metrics · Governance"]
  CUBE --> BI["BI AGENTS · Analyze"] & AI["AI · Reason"] & API["APIs"]
  AI --> N8N["n8n · Automate & Act"] --> ACT["Business Action → Outcome & Learning"]

Role map: Odoo Operate · Airbyte Ingest · ClickHouse Store & Process · dbt Transform & Model · Cube — Define & Understand · BI Analyze · AI Reason · n8n Automate & Act.

Kết luận: Từ Data Model đến Business Meaning

Airbyte đưa dữ liệu vào, ClickHouse lưu & xử lý cho analytics, dbt chuẩn hóa thành Trusted Business Data Model, còn Cube biến Data Model thành một ngôn ngữ kinh doanh thống nhất mà con người, BI, applications và AI Agents đều hiểu. Trong thời BI, nó giúp tránh One KPI — Many Numbers; trong thời AI, nó giải một vấn đề còn quan trọng hơn: AI không nên tự đoán ý nghĩa của dữ liệu doanh nghiệp — AI phải được cung cấp trusted business context. Trong DataValue, đó chính là nhiệm vụ của Cube: Data → Trusted Model → Trusted Meaning → Insight → Intelligence → Action → Value — cách Cube giúp DataValue chuyển từ một Data Platform thành một Business Intelligence Foundation phục vụ cả con người và AI.

Ghi chú

Biên soạn & diễn giải tiếng Việt bởi BSD Insight theo tài liệu chính thức của Cube; ví dụ khái quát hóa cho ngăn xếp DataValue, không phải dịch nguyên văn. Đặt tư vấn triển khai.