Architecture & Internals: bên trong Cube có gì?
Bốn thành phần lõi của Cube, và đường đi của một truy vấn từ client tới data warehouse và trở về.
Mục lục chương
Kiến trúc tổng thể
Ba lớp tách riêng: data warehouse, semantic layer, consumption layer.
Cube tách data warehouse, semantic layer và consumption layer thành ba tầng. Nhờ đó data warehouse không phải xử lý lặp lại cùng một truy vấn từ dashboard hay AI Agent, và quy tắc bảo mật được áp dụng trước khi dữ liệu ra khỏi hệ thống.
Tầng giữa là semantic layer, gồm bốn khối xếp chồng. Chọn từng khối trong sơ đồ để xem chi tiết.
Bốn thành phần lõi
Biên dịch, điều phối, aggregate awareness, và caching.
Schema Compiler đọc model. Query Orchestrator quản lý query queue và cache. Aggregate Awareness xác định truy vấn có dùng được pre-aggregation hay không. Cube Store lưu các bảng pre-aggregation. Chọn từng thành phần để xem chức năng và tác động.
Đọc sâuCube Store được dựng từ gì
Cube Store dùng Apache Arrow DataFusion làm engine truy vấn SQL dạng cột, RocksDB để lưu metadata và index dạng key-value, và định dạng Parquet để lưu dữ liệu theo cột. Vì dữ liệu được tổ chức theo cột, phép gom nhóm thực hiện trực tiếp trên các cột cần dùng mà không phải giải mã từng dòng.
Handbook nêu mục tiêu P95 dưới 250ms cho truy vấn vào Cube Store trên hạ tầng quy mô vừa. Đây là số liệu từ handbook, không phải cam kết chung; độ trễ thực tế phụ thuộc kích thước rollup và cấu hình cụm.
Vòng đời một truy vấn
Sáu bước; chỉ bước 5 rẽ nhánh theo cache hit hoặc cache miss.
Mọi truy vấn đều đi qua cùng một thứ tự: tiếp nhận yêu cầu, xác thực, biên dịch, kiểm tra pre-aggregation, thực thi, trả kết quả. Chuyển công tắc để so sánh hai nhánh của bước thực thi.
Bước 2 và bước 3 quan trọng nhất. Ở bước 2, Cube giải mã JWT thành securityContext, sau đó áp Row-Level Security để thêm điều kiện lọc, qua access policy trong data model hoặc hàm query_rewrite. Ở bước 3, Schema Compiler chuyển các measure và dimension được truy vấn thành Semantic SQL.
Từ request tới response
Cùng một truy vấn có hai đường đi: qua data warehouse hoặc chỉ qua Cube Store.
Ví dụ: client truy vấn orders.total_amount theo tháng. Nếu không có pre-aggregation khớp, Cube gửi SQL xuống data warehouse. Nếu có bảng orders_monthly_rollup trong Cube Store, data warehouse không nhận câu lệnh nào.
Đọc sâuThay đổi từ v0.28: đánh giá partition
Từ v0.28, Query Orchestrator đảm nhận phần đánh giá partition thay cho Schema Compiler. Theo handbook, nhờ thay đổi này Cube xử lý được truy vấn thời gian trên partitioned rollup nằm ngoài build range ban đầu mà không báo lỗi, và mở đường cho rolling window rollup.
Nguồn dữ liệu và thực thi truy vấn
Cube đọc dữ liệu từ data warehouse, đồng thời hạn chế thao tác ghi và các truy vấn thừa xuống nguồn.
Cube kết nối được Snowflake, BigQuery, Databricks, Redshift, ClickHouse và Postgres, kể cả Postgres trên cloud. Với ElasticSearch, MySQL và Postgres, handbook cho biết Cube tự bật chế độ read-only driver (readOnly: true). Khi đó Cube không tạo bảng tạm hay ghi bất kỳ dữ liệu nào lên CSDL nguồn; pre-aggregation được lưu ở Cube Store.
Vấn đề thứ hai liên quan đến refresh_key. Trước v0.28, Cube thường gửi câu SQL kiểm tra refresh_key xuống CSDL nguồn, làm đầy log và tốn tài nguyên. Từ v0.28, Cube Store tự chạy bộ đếm thời gian cho refresh key, nên CSDL nguồn không còn nhận các câu kiểm tra lặp lại này.
Sơ đồ kiến trúc khi chạy local
Một Cube Core, một Postgres, một Cube Store và các ứng dụng gọi qua REST.
Chương 03 triển khai cấu hình này. Client gọi endpoint /cubejs-api/v1/load kèm JWT. Schema Compiler biên dịch orders.yml, Query Orchestrator thêm điều kiện RLS và kiểm tra cache, sau đó chọn Postgres hoặc Cube Store. Chuyển công tắc và chọn từng khối để xem chi tiết.