Hiểu rõ các mô hình dữ liệu trong Apache Doris
Apache Doris hỗ trợ ba mô hình dữ liệu chính, mỗi mô hình phục vụ một trường hợp sử dụng cụ thể trong phân tích dữ liệu dạng cột (Columnar).
Unique Key Model: Mô hình này sử dụng một hoặc nhiều cột làm khóa chính. Khi dữ liệu mới được nhập vào, nếu khóa trùng với dữ liệu cũ, bản ghi mới sẽ ghi đè lên bản ghi cũ. Đây là mô hình tối ưu cho các tác vụ Upsert và phân tích dữ liệu cần tính duy nhất.
Aggregate Key Model: Mô hình này cho phép bạn định nghĩa các hàm tổng hợp (như SUM, MAX, MIN) cho các cột giá trị. Khi dữ liệu trùng khóa được nhập vào, Doris sẽ tự động thực hiện phép tính tổng hợp thay vì ghi đè. Phù hợp cho các bảng tích lũy số liệu theo thời gian thực.
Duplicate Key Model: Đây là mô hình lưu trữ toàn bộ các cột mà không có bất kỳ ràng buộc khóa nào. Tất cả dữ liệu được giữ nguyên, kể cả các bản ghi trùng lặp. Mô hình này phù hợp nhất cho việc lưu trữ log hoặc dữ liệu cần phân tích toàn bộ mà không cần gộp nhóm.
Đối với bài thực hành này, chúng ta sẽ sử dụng Unique Key vì nó cân bằng tốt nhất giữa khả năng lưu trữ và hiệu suất truy vấn cho các bài toán phân tích dữ liệu có tính chất thay đổi trạng thái.
Kết quả mong đợi: Bạn đã hiểu rõ sự khác biệt giữa ba mô hình và xác định được Unique Key là lựa chọn phù hợp cho bước tiếp theo.
Thiết lập Database và Table mẫu với Unique Key
Bước đầu tiên là kết nối đến Frontend (FE) của Apache Doris thông qua MySQL Client để thực thi các lệnh SQL tạo schema.
Chúng ta sẽ tạo một database tên là analytics_db và một bảng mẫu user_events để lưu trữ sự kiện người dùng, sử dụng mô hình Unique Key với các cột làm khóa duy nhất.
mysql -h 127.0.0.1 -P 9030 -u root -p
Khi được hỏi mật khẩu, hãy nhập mật khẩu bạn đã cấu hình ở Phần 2 (mặc định là rỗng nếu không đổi). Kết quả mong đợi là bạn thấy prompt mysql> hiện ra, báo hiệu kết nối thành công.
Tiếp theo, thực thi lệnh tạo database để phân vùng dữ liệu quản trị.
CREATE DATABASE IF NOT EXISTS analytics_db;
Kết quả mong đợi: Dòng thông báo Query OK, 1 row affected và không có lỗi.
Sau đó, chuyển đến database vừa tạo.
USE analytics_db;
Kết quả mong đợi: Thông báo Database changed.
Giờ chúng ta sẽ tạo bảng user_events với mô hình Unique Key. Bảng này bao gồm các cột: user_id và event_date làm khóa duy nhất (Unique Key), cùng các cột giá trị như click_count và last_login_time.
CREATE TABLE user_events (
user_id BIGINT,
event_date DATE,
click_count INT,
last_login_time DATETIME,
device_type STRING
) UNIQUE KEY(user_id, event_date)
DISTRIBUTED BY HASH(user_id) BUCKETS 32
PROPERTIES (
"replication_num" = "3",
"storage_medium" = "SSD",
"compression" = "ZSTD"
);
Giải thích cấu trúc: UNIQUE KEY xác định các cột làm khóa. DISTRIBUTED BY HASH xác định cách dữ liệu được phân tán (Sharding) vào các Bucket. BUCKETS 32 chia dữ liệu thành 32 phần để tăng song song xử lý. replication_num đảm bảo 3 bản sao dữ liệu cho độ tin cậy.
Kết quả mong đợi: Dòng thông báo Query OK, 0 rows affected xác nhận bảng đã được tạo thành công với cấu hình sharding và replica mong muốn.
Để verify, thực thi lệnh mô tả bảng để kiểm tra thuộc tính.
DESCRIBE user_events;
Kết quả mong đợi: Một bảng hiển thị các cột, kiểu dữ liệu, và dòng KEY chỉ ra user_id và event_date là khóa chính. Dòng Partition Key và Distribute Key sẽ hiển thị cấu hình sharding.
Cấu hình Sharding và Replica cho dữ liệu lớn
Khi làm việc với dữ liệu lớn (Big Data), việc cấu hình chính xác số lượng Bucket và Replica là yếu tố sống còn cho hiệu năng và độ tin cậy.
Sharding (Phân tán dữ liệu): Trong lệnh DISTRIBUTED BY HASH(column_name) BUCKETS N, tham số N xác định số lượng đơn vị dữ liệu nhỏ nhất (Bucket) mà một bảng sẽ được chia thành. Dữ liệu sẽ được phân bổ đều vào các Bucket này dựa trên giá trị của cột hash.
Quy tắc vàng: Số lượng Bucket nên được tính toán dựa trên tổng kích thước dữ liệu dự kiến và dung lượng của mỗi Backend Node. Một Bucket không nên vượt quá 5GB - 10GB để đảm bảo hiệu suất truy vấn và cân bằng tải. Nếu dữ liệu dự kiến 100TB và mỗi BE có 5TB, bạn cần ít nhất 200 Bucket (với 3 replica).
Replica (Bản sao): Tham số replication_num trong PROPERTIES xác định số lượng bản sao của mỗi Bucket được lưu trên các Backend Node khác nhau. Giá trị mặc định là 3, đây là tiêu chuẩn để đảm bảo tính sẵn sàng cao (High Availability). Nếu một node bị lỗi, dữ liệu vẫn còn trên 2 node khác.
Đối với bảng user_events trong ví dụ, chúng ta đã đặt 32 Bucket. Điều này phù hợp cho môi trường thử nghiệm hoặc dữ liệu trung bình. Nếu bạn mở rộng quy mô, hãy tăng số này lên 128 hoặc 256 tùy theo lượng dữ liệu tăng trưởng.
Để kiểm tra trạng thái sharding và replica trên hệ thống, hãy truy vấn catalog nội bộ.
SHOW CREATE TABLE user_events;
Kết quả mong đợi: Lệnh này sẽ trả về toàn bộ script tạo bảng, bao gồm các thông số BUCKETS 32 và "replication_num" = "3" để bạn xác nhận lại cấu hình đã áp dụng đúng.
Thêm vào đó, để xem dữ liệu đang được phân bổ như thế nào vào các Backend Node, bạn có thể chạy lệnh sau.
SELECT table_name, partition_name, bucket_id, replica_id, status, location FROM __all__ WHERE table_id = (SELECT table_id FROM information_schema.tables WHERE table_schema = 'analytics_db' AND table_name = 'user_events');
Kết quả mong đợi: Một danh sách các bản ghi hiển thị vị trí vật lý của các bucket và replica trên các node khác nhau, với trạng thái HEALTHY hoặc COMPLETE.
Cơ chế lưu trữ Columnar trong Apache Doris
Khác với các hệ quản trị cơ sở dữ liệu truyền thống lưu trữ theo hàng (Row-based), Apache Doris sử dụng mô hình lưu trữ theo cột (Columnar) cho các bảng phân tích.
Cơ chế hoạt động: Dữ liệu trong mỗi cột được lưu trữ liên tiếp nhau trên đĩa. Ví dụ, tất cả các giá trị của cột click_count được lưu thành một khối riêng biệt, tách biệt hoàn toàn với cột user_id hoặc device_type.
Lợi ích chính là Column Pruning (Cắt tỉa cột). Khi bạn thực hiện truy vấn SELECT click_count FROM user_events WHERE user_id = 123, Doris chỉ đọc các khối dữ liệu liên quan đến cột click_count và user_id (để lọc), mà bỏ qua hoàn toàn việc đọc các cột last_login_time hay device_type. Điều này giảm đáng kể lượng I/O đĩa và bộ nhớ cần xử lý.
Nén dữ liệu (Compression): Do dữ liệu trong một cột thường có tính chất giống nhau (ví dụ: các giá trị số liên tiếp hoặc chuỗi trùng lặp), các thuật toán nén như ZSTD (đã cấu hình ở trên) đạt được tỷ lệ nén rất cao, lên đến 5-10 lần so với lưu trữ theo hàng.
Vectorized Execution (Thực thi vectơ): Doris sử dụng CPU để xử lý dữ liệu theo từng khối (batch) thay vì từng hàng một. Với dữ liệu dạng cột, CPU có thể thực hiện các phép toán trên toàn bộ cột cùng lúc (SIMD), tăng tốc độ tính toán lên hàng chục lần.
Để minh họa cơ chế này, hãy nhập một lượng nhỏ dữ liệu mẫu vào bảng user_events và quan sát cách Doris xử lý.
INSERT INTO analytics_db.user_events VALUES (1, '2023-10-01', 10, '2023-10-01 10:00:00', 'Mobile');
INSERT INTO analytics_db.user_events VALUES (2, '2023-10-01', 5, '2023-10-01 11:00:00', 'Desktop');
INSERT INTO analytics_db.user_events VALUES (1, '2023-10-02', 15, '2023-10-02 09:00:00', 'Mobile');
Lệnh thứ ba sẽ kích hoạt cơ chế Unique Key: Dữ liệu cho user_id = 1 và event_date = '2023-10-01' sẽ bị ghi đè (hoặc cập nhật) bởi dữ liệu mới nếu logic là upsert, nhưng vì ngày khác nhau nên đây là bản ghi mới. Nếu bạn chạy lại lệnh thứ nhất với cùng ngày, nó sẽ ghi đè.
Thực hiện truy vấn chỉ chọn một cột để thấy lợi ích của Columnar.
SELECT SUM(click_count) FROM analytics_db.user_events;
Kết quả mong đợi: Truy vấn trả về tổng số clicks (30) gần như tức thì. Dưới lớp, Doris chỉ đọc khối dữ liệu của cột click_count đã được nén, bỏ qua các cột khác, chứng minh hiệu quả của mô hình Columnar.
Kiểm tra kích thước lưu trữ thực tế so với kích thước logic bằng cách truy vấn thông tin bảng.
SELECT table_name, row_count, data_size FROM information_schema.tables WHERE table_schema = 'analytics_db';
Kết quả mong đợi: Bạn sẽ thấy row_count là 3, nhưng data_size sẽ rất nhỏ (vài KB), phản ánh hiệu quả nén mạnh mẽ của định dạng Columnar ngay cả với dữ liệu ít.
Điều hướng series:
Mục lục: Series: Triển khai Database Columnar với Apache Doris trên Ubuntu 24.04
« Phần 3: Cấu hình quản trị viên và kết nối Web UI của Apache Doris
Phần 5: Nhập dữ liệu vào Apache Doris từ nhiều nguồn khác nhau »