Lưu trữ theo cột (Columnar Storage)
1. Tổng quan
A. Định nghĩa
Lưu trữ theo cột (columnar storage, lưu trữ định hướng cột) là một mô hình lưu trữ (DSM, Decomposition Storage Model) bố trí vật lý một bảng theo đơn vị cột chứ không theo đơn vị hàng, gom các giá trị của cùng một thuộc tính lại với nhau để lưu, nén và quét như một đơn vị. Nó tương phản với lưu trữ định hướng hàng (NSM, N-ary Storage Model) truyền thống vốn lưu liền kề tất cả thuộc tính của một hàng, và là cấu trúc được tối ưu cho khối lượng công việc OLAP, phân tích vốn chỉ tổng hợp và phân tích một số ít cột trên khối lượng dữ liệu lớn.
B. Bối cảnh ra đời và sự cần thiết
Các DBMS quan hệ truyền thống được thiết kế trên tiền đề xử lý giao dịch trực tuyến (OLTP). Với các nghiệp vụ như chèn một đơn hàng hay truy vấn toàn bộ bản ghi của một khách hàng cụ thể, cách định hướng hàng — đặt liền kề tất cả các cột của một hàng tại một vị trí trên đĩa — là có lợi, vì một lần đọc trang cho ra toàn bộ bản ghi cần thiết. Tuy nhiên, từ sau những năm 2000, khi kho dữ liệu và trí tuệ doanh nghiệp (BI) lan rộng, tính chất của khối lượng công việc đã thay đổi căn bản. Các truy vấn phân tích như "tổng doanh số theo khu vực trong ba năm qua" — vốn quét hàng trăm triệu hàng nhưng thực sự chỉ dùng hai ba cột — đã trở nên chiếm ưu thế.
Xử lý các truy vấn như vậy trên lưu trữ định hướng hàng gây lãng phí nghiêm trọng. Dù chỉ cần một cột doanh số, đĩa vẫn được đọc theo đơn vị trang, nên tất cả các cột không cần thiết chứa chung trong trang đó — tên khách hàng, địa chỉ, mô tả sản phẩm, v.v. — đều phải được kéo lên thành I/O. Với một truy vấn chỉ dùng 3 cột trên một bảng 100 cột, về lý thuyết 97% I/O là lãng phí. Trong phân tích quy mô lớn nơi băng thông đĩa và bus bộ nhớ là nút thắt cổ chai, sự lãng phí này chuyển hóa trực tiếp thành thời gian phản hồi và chi phí.
Lưu trữ theo cột giải quyết trực diện vấn đề này. Bằng cách chỉ đọc có chọn lọc các cột xuất hiện trong truy vấn (projection pushdown) nó giảm thiểu I/O; vì các giá trị cùng miền, cùng kiểu nằm kề nhau về mặt vật lý nên tỷ lệ nén tăng vọt; và bằng thực thi vector hóa (vectorized), SIMD xử lý cả mảng giá trị cùng lúc nó còn nâng cao hiệu quả cache CPU. Nhờ đó, hiệu năng truy vấn phân tích cải thiện vài đến hàng chục lần trên cùng phần cứng, và ngày nay hầu như mọi engine phân tích (Redshift, BigQuery, Snowflake, ClickHouse, DuckDB) đều áp dụng lưu trữ theo cột.
Bản thân ý tưởng này không mới. Trong giới học thuật, nó khởi nguồn từ nghiên cứu mô hình lưu trữ phân rã (DSM) những năm 1980, và đầu những năm 2000 MonetDB của CWI (Hà Lan) cùng C-Store của nhóm Michael Stonebraker (về sau phát triển thành sản phẩm thương mại Vertica) đã chứng minh tiềm năng hiệu năng của lưu trữ theo cột, thúc đẩy nó lan rộng thực sự vào công nghiệp. Nói cách khác, lưu trữ theo cột không phải một trào lưu mới mà gần với trường hợp thành quả nghiên cứu lâu năm tái nổi lên thành công nghệ chủ đạo khi khối lượng công việc dịch chuyển từ giao dịch sang phân tích.
C. Đặc điểm
- Đọc cột có chọn lọc (giảm I/O): chỉ đọc từ đĩa các cột mà truy vấn tham chiếu, loại bỏ việc truyền dữ liệu không cần thiết.
- Tỷ lệ nén cao: vì giá trị cùng kiểu, tương tự nằm kề nhau nên mã hóa từ điển (dictionary), RLE, delta khớp tốt, thường nén 2–10 lần so với lưu trữ theo hàng.
- Thân thiện vector hóa/SIMD: vì các giá trị của một cột tạo thành mảng liên tục, các phép lặp được xử lý theo đơn vị vector, dùng pipeline và cache CPU hiệu quả.
- Tối ưu tổng hợp: mạnh ở quét và tổng hợp toàn cột như SUM, AVG, COUNT, nhưng yếu ở chèn/cập nhật/xóa từng hàng (OLTP).
- Bỏ qua dựa trên thống kê: lưu kèm thống kê như min/max theo từng chunk cột, nên các khối dữ liệu không khớp điều kiện được bỏ qua mà không cần đọc.
2. Cấu trúc tổng thể: định hướng hàng vs định hướng cột
Sự khác biệt giữa định hướng hàng và định hướng cột nằm ở "cách trải cùng một bảng logic ra trên đĩa". Bảng logic là như nhau, nhưng khi bố trí vật lý thay đổi thì các đặc tính I/O, nén, tính toán phân hóa hoàn toàn. Sơ đồ cấu trúc dưới đây cho thấy một bảng có bốn cột được tuần tự hóa như thế nào trong mỗi mô hình.
flowchart TB
T["Bảng logic(hàng R1~R3 × cột A~D)"]
T --> NSM["Định hướng hàng(NSM)"]
T --> DSM["Định hướng cột(DSM)"]
subgraph NSM_L["Bố trí vật lý định hướng hàng"]
N1["Khối: (R1.A R1.B R1.C R1.D)"]
N2["Khối: (R2.A R2.B R2.C R2.D)"]
N3["Khối: (R3.A R3.B R3.C R3.D)"]
end
subgraph DSM_L["Bố trí vật lý định hướng cột"]
D1["Cột A: (A1 A2 A3)"]
D2["Cột B: (B1 B2 B3)"]
D3["Cột C: (C1 C2 C3)"]
D4["Cột D: (D1 D2 D3)"]
end
NSM --> NSM_L
DSM --> DSM_L
Trong hình trên, định hướng hàng giữ A~D của một hàng liền nhau trong một khối, nên mạnh với yêu cầu "hãy cho toàn bộ R2". Ngược lại, định hướng cột gom riêng chỉ các giá trị của cột A, nên hoàn tất yêu cầu "cộng A trên tất cả các hàng" bằng một lần quét tuần tự. Chính sự khác biệt bố trí này quyết định mức phù hợp với khối lượng công việc.
Đi sâu hơn vào từng thành phần: một chunk cột (column chunk) là đơn vị vật lý gom các giá trị của một cột, và mã hóa, nén được áp dụng lên nó. Ngoài bản thân giá trị, còn quản lý kèm mức định nghĩa (definition level), bitmap NULL chỉ ra hàng nào là NULL, và thông tin vị trí thứ tự (ordinal position) để truy ngược mỗi giá trị thuộc về hàng logic nào. Vì định hướng cột không lưu nguyên hàng, nên cần riêng tái dựng bộ (tuple reconstruction) — kết hợp nhiều cột để khôi phục hàng gốc — và cách giảm thiểu chi phí này trở thành thách thức cốt lõi của thiết kế engine cột.
Hãy minh họa bằng con số thực tế xem sự khác biệt bố trí vật lý này biểu hiện ra sao. Giả sử ta tính "tổng của cột doanh số (8 byte)" trên một bảng một tỷ hàng với 50 cột và trung bình 500 byte mỗi hàng (khoảng 500GB). Định hướng hàng về nguyên tắc phải quét toàn bộ 500GB, nhưng định hướng cột chỉ đọc cột doanh số nên chỉ cần truy cập khoảng 8GB (trước khi nén), mà mã hóa từ điển và delta giảm còn khoảng 2GB. Dữ liệu phải đọc ở cùng băng thông đĩa giảm hai bậc độ lớn, và đây là lý do căn bản khiến lưu trữ theo cột có ưu thế áp đảo trong truy vấn phân tích.
Định hướng cột cũng linh hoạt với tiến hóa lược đồ (schema evolution). Vì các cột được lưu độc lập, thêm một cột mới chỉ cần bổ sung một tệp cột mới mà không ghi lại dữ liệu hiện có, và cũng có thể tối ưu cục bộ như ghi lại chỉ một cột cụ thể bằng mã hóa khác. Ngược lại, định hướng hàng tương đối nặng vì thêm hoặc đổi một cột ảnh hưởng đến toàn bộ cấu trúc bản ghi hàng. Như vậy, một lựa chọn bố trí vật lý duy nhất kéo theo dây chuyền không chỉ I/O, nén, tính toán mà cả cách vận hành lược đồ.
| Phân loại | Định hướng hàng (NSM) | Định hướng cột (DSM) |
|---|---|---|
| Bố trí vật lý | mọi cột của một hàng liên tục | mọi giá trị của một cột liên tục |
| Truy vấn có lợi | truy vấn/chèn từng bản ghi (OLTP) | quét/tổng hợp khối lớn (OLAP) |
| Tỷ lệ nén | thấp (trộn kiểu khác nhau) | cao (giá trị cùng loại kề nhau) |
| Chi phí cập nhật | thấp | cao (chạm nhiều tệp cột) |
| Hệ thống tiêu biểu | MySQL, PostgreSQL, Oracle | Redshift, ClickHouse, DuckDB |
3. Kỹ thuật cốt lõi: mã hóa, nén và thực thi
Hiệu năng của lưu trữ theo cột không đơn thuần đến từ việc "gom các cột lại", mà được hoàn thiện bởi mã hóa nhẹ (lightweight encoding) và thực thi vector hóa xếp chồng bên trên. Sơ đồ chi tiết dưới đây biểu diễn quy trình trong đó giá trị cột thô được lưu sau khi qua mã hóa và nén, rồi được xử lý lúc truy vấn qua bỏ qua dữ liệu và tái dựng trễ.
flowchart LR
RAW["Giá trị cột thô"] --> ENC["Mã hóa nhẹ(từ điển·RLE·delta)"]
ENC --> CMP["Nén tổng quát(LZ4·Zstd)"]
CMP --> STORE[("Lưu chunk cột(+ zone map)")]
Q["Truy vấn phân tích"] --> SKIP["Bỏ qua dữ liệu(min/max zone map)"]
STORE --> SKIP
SKIP --> SCAN["Quét vector hóa(SIMD)"]
SCAN --> LATE["Tái dựng trễ(late materialization)"]
LATE --> RESULT["Tổng hợp kết quả"]
A. Mã hóa nhẹ. Lý do đầu tiên khiến lưu trữ theo cột đạt tỷ lệ nén cao là tính đồng nhất của giá trị. Mã hóa từ điển (dictionary encoding) thay các giá trị chuỗi hay phân loại lặp lại bằng mã số nguyên, giảm kích thước lưu trữ và hạ tải CPU bằng cách cho phép lọc chỉ bằng so sánh số nguyên. RLE (Run-Length Encoding) nén các cột được sắp xếp hoặc lặp nhiều dưới dạng "giá trị + số lần lặp", còn mã hóa delta (delta encoding) chỉ lưu chênh lệch so với giá trị trước ở các cột có xu hướng tăng rõ như dấu thời gian, số thứ tự. Kết hợp thêm đóng gói bit (bit-packing) thì chỉ dùng số bit tối thiểu khớp với dải giá trị thực tế. Chẳng hạn, một cột mã quốc gia (hàng trăm giá trị phân biệt) giảm xuống dưới 10% bản gốc nhờ mã hóa từ điển, còn dấu thời gian log tăng theo giây được nén mạnh bằng delta cộng đóng gói bit.
Kỹ thuật mã hóa được chọn để khớp với đặc tính dữ liệu của cột. Bảng dưới đây tóm tắt các mã hóa tiêu biểu, loại cột chúng khớp tốt, và hiệu quả kỳ vọng. Các engine thực tế nhìn thống kê theo từng cột để chọn mã hóa tự động (ví dụ: mã hóa từ điển khi cardinality thấp) hoặc kết hợp nhiều kỹ thuật theo tầng.
| Mã hóa | Cột phù hợp | Nguyên lý | Hiệu quả kỳ vọng |
|---|---|---|---|
| Từ điển (Dictionary) | phân loại/chuỗi cardinality thấp | thay giá trị→mã số nguyên | giảm kích thước + lọc bằng so sánh số nguyên |
| RLE | cột sắp xếp/lặp nhiều | biểu diễn bằng giá trị + số lần lặp | nén cực mạnh các đoạn lặp |
| Delta | số/dấu thời gian dạng tăng | chỉ lưu chênh lệch so với giá trị trước | thu về dải giá trị hẹp |
| Đóng gói bit | số nguyên dải giá trị hẹp | chỉ dùng số bit tối thiểu cần | lưu số nguyên hiệu quả |
B. Kết hợp với nén tổng quát. Áp thêm nén tổng quát như LZ4, Snappy, Zstandard lên luồng byte đã được mã hóa nhẹ chỉnh trang lần đầu sẽ nâng tỷ lệ nén thêm một bậc. Trong thực tế, tùy theo đánh đổi giữa "chi phí giải nén lúc truy vấn" và "tiết kiệm lưu trữ, truyền tải", các đội phân tầng codec — LZ4/Snappy giải nén nhanh cho dữ liệu nóng (hot) và Zstd tỷ lệ cao cho kho lạnh (cold). Nén giảm không chỉ chi phí lưu trữ mà cả chính lượng I/O đĩa và mạng, nên thường có lãi ròng ngay cả sau khi bù trừ CPU tốn cho giải nén.
C. Bỏ qua dữ liệu (zone map). Bằng cách lưu kèm zone map và thống kê theo từng chunk cột như giá trị nhỏ nhất/lớn nhất, số NULL, một bộ lọc như WHERE doanh_số > 100 triệu có thể bỏ qua mà không đọc toàn bộ các chunk có giá trị lớn nhất từ 100 triệu trở xuống. Predicate pushdown và bỏ qua dữ liệu này nhân đôi mức tiết kiệm I/O của lưu trữ theo cột, và hiệu quả càng lớn khi dữ liệu được sắp xếp, phân cụm theo cột liên quan.
D. Thực thi vector hóa và tái dựng trễ. Vì các giá trị cột tạo thành mảng liên tục, engine xử lý hàng nghìn giá trị theo lô (batch) thay vì từng hàng một. Mô hình vector hóa này phân tán chi phí gọi hàm và song song hóa tính toán bằng lệnh SIMD để nâng hiệu quả CPU. Nếu thực thi dựa trên hàng truyền thống là "mô hình lặp Volcano" gọi một toán tử cho mỗi bộ, thì vector hóa giảm lời gọi đó xuống một lần mỗi lô, phân bổ chi phí trình thông dịch. Ngoài ra, tái dựng trễ (late materialization) xử lý trước chỉ các cột cần cho lọc và tổng hợp, và hoãn càng lâu càng tốt việc tái dựng bộ để đưa về dạng hàng gốc, tránh các phép nối dữ liệu không cần thiết. Ngược lại, tái dựng sớm (early materialization) khôi phục hàng ngay đầu truy vấn thì đơn giản để cài đặt nhưng chịu thiệt trong quét khối lớn. Độ chọn lọc (selectivity) của bộ lọc càng thấp — tức càng nhiều hàng bị loại — thì lợi ích của tái dựng trễ càng lớn.
E. Giới hạn và khối lượng công việc không phù hợp. Ngược lại, rõ ràng có những trường hợp lưu trữ theo cột bất lợi. Các truy vấn đòi hỏi mọi cột như SELECT * phải lắp ráp lại các tệp cột thành hàng nên thực ra là thiệt; OLTP với chèn/sửa từng hàng thường xuyên, hay truy vấn điểm tìm chính xác một số ít hàng theo khóa rồi lấy toàn bộ thuộc tính, cũng đều có lợi cho lưu trữ định hướng hàng và chỉ mục B+Tree. Do đó nên hiểu lưu trữ theo cột không phải "vật thay thế vạn năng" mà là công cụ chuyên biệt cho khối lượng công việc phân tích, và quan điểm thiết kế đúng đắn là bố trí nó theo sự phân chia vai trò với các hệ thống giao dịch.
4. So sánh và trường hợp áp dụng
Định hướng hàng và định hướng cột không phải chuyện hơn kém mà là chuyện sự phù hợp với khối lượng công việc. Nguyên nhân căn bản của sự khác biệt nằm ở "tỷ lệ dữ liệu đọc trong một lần I/O mà truy vấn thực sự tiêu thụ". OLTP thường xử lý toàn bộ các hàng cụ thể nên định hướng hàng nâng tỷ lệ đó, còn OLAP quét một số ít cột trên toàn dải nên định hướng cột nâng tỷ lệ đó. Đặc tính cập nhật cũng phân hóa. Cập nhật một hàng trong định hướng cột đòi hỏi chạm tất cả các tệp cột nằm rải rác, nên hầu hết hệ thống cột, thay cho từng lệnh UPDATE, chọn cách bổ sung (append) một phiên bản mới vào các tệp bất biến (immutable) và hợp nhất (compaction).
Nhìn kỹ hơn cách xử lý cập nhật, nhiều engine cột hấp thụ ghi bằng ý tưởng tương tự [[lsm-tree]]. Các hàng mới đến trước tiên được gom vào một bộ đệm bộ nhớ/hàng nhỏ (hoặc các tệp nhỏ), và khi đạt một ngưỡng nhất định chúng được xả xuống các tệp bất biến ở dạng cột, với nhiều mảnh được hợp nhất (compaction) thành một ở nền. Xóa và cập nhật, thay vì loại bỏ hàng ngay, được ghi thành dấu xóa (tombstone) hoặc phiên bản mới, rồi được lọc lúc đọc (merge-on-read) hoặc áp dụng lúc hợp nhất (merge-on-write). Nhờ cấu trúc này, thông lượng nạp khối lớn cao, nhưng nếu hợp nhất bị chậm thì các tệp nhỏ chất đống và hiệu năng quét giảm, nên quản lý chính sách hợp nhất trở thành cốt lõi của vận hành.
Vì đánh đổi này, các hệ thống hiện đại kết hợp cả hai mô hình. Tiêu biểu là cách tiếp cận HTAP lai, một cấu trúc trong đó dữ liệu gần đây được nhận ở lưu trữ hàng (chèn nhanh) và dữ liệu cũ được chuyển sang lưu trữ cột (phân tích nhanh). Ví dụ, ClickHouse xử lý tổng hợp hàng chục tỷ hàng mỗi giây trên nền lưu trữ theo cột và được dùng cho phân tích log, sự kiện quy mô lớn; Amazon Redshift kết hợp lưu trữ theo cột với zone map và khóa sắp xếp để vận hành kho quy mô petabyte; và Google BigQuery cung cấp phân tích serverless với định dạng cột Capacitor và engine thực thi Dremel. Trong phân tích nhúng, DuckDB chạy như một tệp đơn ngày càng thực hiện phân tích CSV, Parquet dung lượng lớn trong vài giây ngay cả trong môi trường notebook nhờ engine cột, vector hóa.
Một trường hợp áp dụng cụ thể là phân tích log khả quan sát (Observability). Trong môi trường nơi hàng nghìn máy chủ tuôn ra hàng triệu log, số đo mỗi giây, đưa chúng vào một RDBMS định hướng hàng và chạy "tổng hợp tỷ lệ lỗi theo dịch vụ trong một giờ qua" khiến phản hồi vượt hàng chục giây vì gánh nặng quét toàn bộ. Nạp cùng dữ liệu vào một engine cột như ClickHouse hay Druid và sắp xếp theo cột thời gian, dịch vụ thì xử lý cùng truy vấn trong dưới một giây nhờ bỏ qua bằng zone map và tổng hợp vector hóa. Một trường hợp khác, trong phân tích bản ghi chi tiết cuộc gọi, cước (CDR) của nhà mạng, chỉ vài cột liên quan cước trong hàng trăm cột được tổng hợp lặp lại, nên sau khi chuyển sang lưu trữ theo cột, chi phí lưu trữ giảm vài lần nhờ nén và thời gian batch quyết toán cuối tháng được báo cáo là rút ngắn đáng kể. Như vậy, mẫu hình càng là "tổng hợp lặp lại một số ít cột trên dữ liệu rộng (nhiều cột), sâu (nhiều hàng)" thì lợi ích của lưu trữ theo cột càng lớn.
| Góc nhìn | Định hướng hàng (OLTP) | Định hướng cột (OLAP) |
|---|---|---|
| Truy vấn tiêu biểu | SELECT * WHERE id=? |
SELECT SUM(x) GROUP BY y |
| Chèn/cập nhật | nhanh | chậm (append·compaction) |
| Quét/tổng hợp | chậm | nhanh |
| Nén | hạn chế | xuất sắc |
| Phụ thuộc chỉ mục | cao (B+Tree) | thấp (quét + bỏ qua) |
Tóm lại, tiêu chí chọn giữa hai mô hình hội tụ về một câu hỏi duy nhất: "truy vấn thiên hàng hay thiên cột?". Nếu nó xử lý một số ít hàng trên nhiều cột thì lưu trữ hàng là đáp án; nếu nó tổng hợp nhiều hàng trên một số ít cột thì lưu trữ cột là đáp án. Các hệ thống thực tế, thay vì hợp nhất cả hai vào một kho duy nhất, thường có lợi hơn — cả về tổng chi phí sở hữu (TCO) lẫn hiệu năng — khi cấu thành các tầng lưu trữ phân chia vai trò và nối chúng bằng đường ống dữ liệu.
5. Chuyên sâu: chuẩn hóa định dạng lưu trữ và lakehouse
Lưu trữ theo cột khởi nguồn từ công nghệ nội bộ của engine cơ sở dữ liệu, nhưng xu hướng ngày nay là chuẩn hóa thành định dạng tệp mở (open format). Lưu trữ cột thuần túy (tách hoàn toàn mọi giá trị thành các tệp theo cột) có điểm yếu là chi phí tái dựng bộ cao, nên hầu hết định dạng thực tế chọn kiểu lai theo dòng PAX (Partition Attributes Across). Tức là, bảng trước tiên được chia thành các nhóm hàng (row group) cỡ hàng chục đến hàng trăm nghìn hàng, và giá trị chỉ được gom theo cột trong mỗi nhóm hàng. Cách này giữ được lợi ích của quét cột trong khi cho phép tái dựng cục bộ các cột liên quan trong một nhóm hàng, cải thiện tính cục bộ I/O.
Các định dạng tiêu biểu chuẩn hóa thiết kế lai này là Apache Parquet và Apache ORC. Parquet được tổ chức theo phân cấp nhóm hàng → chunk cột → trang và áp dụng mô hình Dremel biểu diễn dữ liệu lồng (nested) bằng mức định nghĩa và mức lặp; nó được dùng như định dạng chuẩn trên thực tế của hệ sinh thái dữ liệu lớn bao gồm Spark. ORC được dùng rộng rãi trong dòng Hive với cấu trúc theo đơn vị stripe và chỉ mục, thống kê tích hợp. Trong miền bộ nhớ, Apache Arrow đã tự khẳng định là chuẩn cột trong bộ nhớ để trao đổi dữ liệu giữa các ngôn ngữ và engine mà không sao chép hay tuần tự hóa, hạ chi phí trao đổi dữ liệu giữa các hệ thống không đồng nhất.
Các kho dữ liệu đám mây thương mại cũng đã đưa cùng nguyên lý vào bên trong. Snowflake chia dữ liệu thành các micro-partition bất biến cỡ hàng chục đến hàng trăm MB và lưu, nén theo cột bên trong chúng, giữ siêu dữ liệu như min/max, số distinct theo từng phân vùng để cắt tỉa (pruning). Đây là hiện thực hóa ở quy mô thương mại của kiểu lai PAX và bỏ qua bằng zone map đã thấy ở trên. Tóm lại, lưu trữ theo cột — vốn khởi đầu từ các khái niệm học thuật (C-Store, PAX) — chạy như một dòng dõi duy nhất qua các định dạng tệp mở (Parquet, ORC), một chuẩn trong bộ nhớ (Arrow), và các engine thương mại (Snowflake, BigQuery, Redshift), thấm khắp hạ tầng phân tích ngày nay.
Xu hướng gần đây nhất là lakehouse. Trên các tệp Parquet, ORC tích lũy trong lưu trữ đối tượng (như S3), các định dạng bảng như Delta Lake, Apache Iceberg, Apache Hudi xếp chồng nhật ký giao dịch, tiến hóa lược đồ, truy vấn thời điểm (time travel) và ACID, kết hợp độ tin cậy của kho dữ liệu với một hồ dữ liệu rẻ. Ở đây các tệp cột (Parquet) đảm nhận tầng vật lý chứa dữ liệu, còn định dạng bảng đảm nhận tầng siêu dữ liệu mô tả những tệp nào cấu thành bảng tại một thời điểm nhất định. Nhờ sự tách biệt này, batch, streaming, BI và ML có thể đồng thời truy cập một bản sao dữ liệu bằng các engine khác nhau mà vẫn giữ nhất quán. Nhờ đó, lưu trữ được thống nhất thành một định dạng cột mở duy nhất, và trên nền đó kiến trúc tách lưu trữ - tính toán (decoupled storage-compute) — nơi nhiều engine truy vấn (Spark, Trino, Snowflake, DuckDB) truy cập riêng — đang định hình thành chuẩn. Các khái niệm liên quan, khi hiểu cùng [[data-warehouse-olap]] và [[btree-bplus-index]], sẽ cho thấy bức tranh toàn cảnh về lưu trữ, lập chỉ mục và phân tích.
6. Cân nhắc và hàm ý
Lưu trữ theo cột không phải một tính năng của một sản phẩm cụ thể mà là lựa chọn tạo nên nền tảng của kiến trúc dữ liệu, nên trước khi áp dụng phải cân nhắc đặc tính khối lượng công việc cùng với gánh nặng vận hành dài hạn.
Đặc biệt trong bài thi của Kỹ sư chuyên nghiệp, nên đề cập cân bằng năm trục sau — phân tách khối lượng công việc, đánh đổi nén, ứng phó cập nhật/quy định, định dạng mở, vận hành/giám sát — bàn cả chiến lược áp dụng cùng với đánh đổi, triển vọng và công nghệ liên đới.
- Chiến lược phân tách khối lượng công việc (HTAP): thay vì gượng ép hợp nhất giao dịch và phân tích vào một mô hình lưu trữ, một kiểu lai phân tầng lưu trữ hàng (OLTP) + lưu trữ cột (OLAP) và đồng bộ qua CDC (Change Data Capture) và ETL/ELT là thực tế. Các engine HTAP gần đây tiến hóa theo hướng duy trì cả hai biểu diễn ở bên trong trong khi quản lý nhất quán và độ trễ.
- Đánh đổi nén/hiệu năng: tỷ lệ nén cao giảm lưu trữ và I/O nhưng đòi hỏi CPU giải nén lúc truy vấn. Áp dụng codec mã hóa/nén và khóa sắp xếp một cách phân biệt theo nhiệt độ dữ liệu (nóng/lạnh), và thiết kế vật lý để sắp xếp, phân cụm dữ liệu theo các cột thường bị lọc nhằm phát huy hiệu ứng zone map, quyết định hiệu năng.
- Cập nhật/xóa và ứng phó quy định: cấu trúc cột, tệp bất biến khiến việc xóa từng phần khó khăn. Ứng phó quyền được xóa theo GDPR và luật bảo vệ thông tin cá nhân, cùng vấn đề bùng nổ tệp nhỏ (small file) do cập nhật nhỏ thường xuyên, phải được quản lý bằng hợp nhất (compaction) định kỳ, thiết kế phân vùng và chiến lược merge-on-read/write.
- Định dạng mở và tránh khóa cứng: áp dụng các định dạng mở và định dạng bảng như Parquet, Iceberg giảm phụ thuộc (lock-in) vào engine của một nhà cung cấp cụ thể, và việc tách lưu trữ - tính toán bảo đảm sự linh hoạt để thay và chạy song song các engine. Đây cũng là tiêu chí lựa chọn quan trọng dưới góc nhìn đa đám mây và tối ưu chi phí (FinOps).
- Góc nhìn vận hành/giám sát: vì hiệu năng của một hệ thống lưu trữ theo cột chịu ảnh hưởng lớn bởi thiết kế phân vùng, khóa sắp xếp và nhịp hợp nhất, nó đòi hỏi năng lực vận hành để liên tục quan sát các chỉ số như số tệp nhỏ, độ trễ hợp nhất, hiệu suất bỏ qua (tỷ lệ chunk thực sự đọc so với quét) và tinh chỉnh lặp lại thiết kế vật lý.
- Triển vọng: phạm vi áp dụng của lưu trữ theo cột đang mở rộng sang xử lý vector dựa trên GPU, tích hợp streaming thời gian thực với batch, và các nền tảng phân tích chứa cả embedding vector ([[vector-database]]) và khối lượng công việc AI. Cuộc cạnh tranh chuẩn giữa các định dạng bảng mở (xu hướng hội tụ quanh Iceberg) cũng được dự báo sẽ là biến số cốt lõi trong lựa chọn kiến trúc dữ liệu tương lai.
Tài liệu tham khảo
- Apache Parquet, "File Format", https://parquet.apache.org/docs/file-format/
- Apache ORC, "ORC Specification", https://orc.apache.org/specification/
- Stonebraker et al., "C-Store: A Column-oriented DBMS", VLDB 2005, https://www.vldb.org/archives/website/2005/program/paper/thu/p553-stonebraker.pdf
- Ailamaki et al., "Weaving Relations for Cache Performance (PAX)", VLDB 2001, https://www.vldb.org/conf/2001/P169.pdf
- Apache Arrow, "Format", https://arrow.apache.org/docs/format/Columnar.html
Tóm tắt một câu: Lưu trữ theo cột là mô hình lưu trữ tối ưu cho phân tích (OLAP) gom dữ liệu theo cột để hiện thực đọc chọn lọc, nén cao và thực thi vector hóa, và thông qua các định dạng lai mở như Parquet, ORC cùng lakehouse, nó đã trở thành nền tảng chuẩn của hạ tầng phân tích dữ liệu ngày nay.