Tái định nghĩa OLAP: Sự phân tán năm 2026
- năm trước, OLAP đồng nghĩa với các cụm phân tán quy mô lớn tập trung như Vertica, Redshift, Snowflake. Bức tranh năm 2026 đã thay đổi hoàn toàn. ClickHouse Cloud serverless hiện thực quy mô theo giây, trong khi DuckDB xử lý hàng trăm GB trong một tiến trình đơn, và cấu hình truy vấn trực tiếp Parquet trên S3 từ frontend qua DuckDB chạy trong WASM trên trình duyệt đã trở thành hiện thực.
Trong 23 tư vấn hạ tầng phân tích mà KGA nhận được trong Q1 năm 2026, chỉ 9 dự án ban đầu áp dụng cấu hình truyền thống "tập trung tất cả vào Snowflake/BigQuery". 14 dự án còn lại chọn cấu hình hybrid "phân chia vai trò giữa data warehouse trung tâm (Snowflake hoặc BigQuery) và OLAP nhẹ tại chỗ (ClickHouse/DuckDB)". Thực tế, nhiều trường hợp tiết kiệm 30~50% tổng chi phí bằng cách phân chia mục đích sử dụng.
Vị thế của ClickHouse Cloud năm 2026
ClickHouse Cloud đã đạt đến mức cao nhất về cân bằng giữa dễ vận hành và hiệu suất với hỗ trợ serverless năm 2024, SharedMergeTree (tách hoàn toàn compute và storage) năm 2025, và tự động hóa Query Condition Cache và Parallel Replica năm 2026. Với khách hàng quảng cáo của KGA, chúng tôi có thể xử lý 2 triệu sự kiện nhập mỗi giây và truy vấn dashboard phản hồi trong một giây với chi phí thấp hơn 40% so với trước đây.
ClickHouse mạnh vượt trội trong các workload có đủ các đặc điểm sau.
- Time series/event log với append-only: Impression quảng cáo, sự kiện game, IoT telemetry, APM trace, web analytics.
- Truy vấn tổng hợp chủ yếu trên một/vài bảng: GROUP BY, SUM, COUNT, PERCENTILE.
- Dashboard tương tác với độ trễ thấp: Ứng dụng yêu cầu phản hồi P95 dưới 500ms.
- Tổng hợp theo chiều có cardinality cao: Phân tích theo trục user_id, session_id, trace_id.
Ngược lại, Snowflake/BigQuery phù hợp hơn với workload có nhiều join đa bảng, update/delete thường xuyên và chủ yếu là ad-hoc discovery. Năm 2026, ClickHouse đã cải thiện đáng kể khả năng chịu đựng join với Parallel Hash Join và Grace Hash Join thuần thục, nhưng với star schema hơn 10 bảng, các MPP khác vẫn ổn định hơn.
Sức ảnh hưởng của DuckDB 1.2
DuckDB là "cơ sở dữ liệu OLAP in-process" có thể tích hợp vào ứng dụng dưới dạng thư viện. Có ba điểm tiến hóa quan trọng trong phiên bản 1.2.
Chế độ HTTP server: DuckDB, vốn chỉ là library, nay có thể khởi động như một HTTP server. Cấu hình gửi truy vấn qua HTTP từ Python/Go/TypeScript và nhận kết quả dạng JSON/Arrow IPC đã ổn định. Việc xây dựng như backend của API dữ liệu nhẹ nhanh hơn ClickHouse.
Đọc/ghi Iceberg/Delta: Đọc Iceberg được triển khai từ 1.1, và ghi Iceberg được triển khai trong 1.2. Có thể đọc/ghi trực tiếp bảng Iceberg trên S3 từ DuckDB, và truy cập nhẹ vào lakehouse trở nên khả thi.
Hiệu suất WASM: DuckDB-WASM chạy trong trình duyệt có thể đạt 60~70% hiệu suất của phiên bản desktop nhờ tối ưu hóa SIMD và hỗ trợ parallel Worker. Các công cụ BI như Observable, Evidence.dev, Perspective được xây dựng trên nền này, và "phân tích 100GB Parquet chỉ trong trình duyệt" hoàn toàn trong browser.
Với khách hàng là cơ quan chính quyền địa phương của KGA, chúng tôi đã triển khai dashboard trực quan hóa dữ liệu mở bằng DuckDB-WASM. Parquet công khai trên S3 được trình duyệt đọc trực tiếp, và toàn bộ tổng hợp và trực quan hóa được xử lý phía client. Tài nguyên tính toán phía server bằng không, và chi phí scale thực tế cũng bằng không. Đã vượt qua bài kiểm tra tải đến 1 triệu người dùng.
MotherDuck ổn định thương mại
MotherDuck là dịch vụ managed được xây dựng trên DuckDB, và từ beta năm 2024 qua GA năm 2025, đến năm 2026 đã ổn định như một lựa chọn thay thế thực tế cho Snowflake/BigQuery trong các workload phân tích quy mô vừa và nhỏ.
Đặc điểm nổi bật nhất là "thực thi hybrid". Một phần truy vấn (đọc file, lọc) được thực thi phía cloud, phần còn lại phía DuckDB local, giảm thiểu truyền dữ liệu trong khi tận dụng tài nguyên tính toán local. Đặc biệt với developer Python, trải nghiệm attach `motherduck` trong notebook rồi JOIN liền mạch bảng cloud quy mô lớn với CSV/Parquet tại chỗ là điều khó có ở nơi khác.
Giá cả cũng hấp dẫn, dữ liệu dưới 10GB có thể vận hành với gói miễn phí. Với phân tích cỡ 100GB~1TB, chi phí khoảng 1/5 so với Snowflake. Tuy nhiên với quy mô trên 10TB hoặc mục đích dashboard vượt quá 50 người dùng đồng thời, Snowflake/ClickHouse phù hợp hơn MotherDuck.
Con đường riêng của Turso và LibSQL
Turso là cơ sở dữ liệu SQL phân tán ở edge dựa trên LibSQL, một fork của SQLite, và về mặt kỹ thuật không phải OLAP thuần túy mà nghiêng về OLTP, nhưng với phần mở rộng Analytics (cơ chế kết hợp row-oriented và column-oriented như AlloyDB Columnar) được giới thiệu năm 2026, nó cũng hỗ trợ phân tích quy mô vừa và nhỏ.
Đặc điểm nổi bật là cấu hình multi-tenant có thể nhân bản cơ sở dữ liệu ra edge trên toàn thế giới. Điểm mạnh là có thể truy vấn trong một mili giây từ Cloudflare Workers hay Vercel Edge Functions. Phù hợp với các trường hợp hiệu suất phản hồi đến người dùng phân tán địa lý trở thành vấn đề, như nhà sản xuất thiết bị IoT hay mục đích dashboard SaaS.
Về mục đích OLAP thuần túy, kém hơn DuckDB/ClickHouse, nhưng là ứng cử viên hàng đầu trong trường hợp "muốn giải quyết OLTP kiêm phân tích nhẹ bằng một DB" hay "muốn triển khai ở edge".
Thiết kế tiered storage và hot/cold
Điều trở nên bắt buộc trong vận hành OLAP năm 2026 là tiered storage (lưu trữ phân cấp). ClickHouse Cloud lấy S3/GCS làm storage chính và local NVMe làm tầng cache với SharedMergeTree làm chuẩn. Snowflake/BigQuery có cấu trúc tương tự, nhưng ClickHouse cho phép tinh chỉnh cache policy một cách rõ ràng là điểm khác biệt.
Với khách hàng quảng cáo của KGA, chúng tôi đã giảm 80% chi phí lưu trữ bằng thiết kế 3 tầng: "30 ngày gần nhất = hot (thường trú cache NVMe), 31~180 ngày = warm (S3, tải vào NVMe theo yêu cầu), từ 181 ngày trở đi = cold (S3 Glacier, truy vấn trực tiếp bằng Athena)". Hiệu suất truy vấn hot/warm thực tế tương đương nhau, chỉ cold chậm hơn 10~20 lần, nhưng yêu cầu tương tác với dữ liệu hơn 180 ngày trước là hiếm và được chấp nhận.
Những cạm bẫy với workload tiếng Nhật
Chúng tôi nêu 5 thách thức đặc thù trong phân tích dữ liệu của doanh nghiệp Nhật Bản.
1. Timezone: Lỗi ngày tháng bị lệch một ngày do lẫn lộn JST (UTC+9) và UTC vẫn xảy ra thường xuyên ngay cả đến năm 2026. Với ClickHouse, hãy sử dụng tham số timezone `'Asia/Tokyo'` của `DateTime64` để khai báo rõ ràng, còn với BigQuery/Snowflake, hãy triệt để lưu trữ UTC và chuyển đổi khi hiển thị. DuckDB đã ổn định từ 1.2 với việc giới thiệu kiểu `TIMESTAMPTZ`.
2. Ký tự đa byte và collation: So sánh tên khách hàng/tên sản phẩm chứa dấu cách toàn góc, chữ số nửa góc/toàn góc, chữ cổ chỉ bằng so sánh byte UTF-8 là không đủ. ClickHouse xử lý bằng phần mở rộng ICU, DuckDB bằng hàm chuẩn hóa NFKC. Khi sử dụng làm khóa tổng hợp, việc xây dựng pipeline chuẩn hóa trước là nguyên tắc sắt.
3. Chữ số Hán và lịch Nhật: Trong các dự án chính phủ, không thể tránh việc xử lý các biểu thức như "Reiwa năm thứ 6 tháng 3". Thay vì xử lý ở cấp SQL, cách lành mạnh là chuẩn hóa về ISO 8601 khi nhập và lưu trữ.
4. Lẫn lộn CP932/Shift_JIS: Vẫn xuất hiện trong xuất CSV từ hệ thống cốt lõi legacy. `read_csv` của DuckDB hỗ trợ tham số encoding chính thức GA từ 1.2. ClickHouse chuyển đổi bằng hàm `INPUT`.
5. Katakana nửa góc: Vẫn tồn tại trong dữ liệu ngân hàng, và khi chuyển đổi thành toàn góc bằng NFKC, "ｶ" và "カ" trở thành cùng giá trị, nhưng sẽ gặp sự cố khi dữ liệu gốc mong đợi nửa góc làm khóa. Hãy cố định sớm quy tắc chuyển đổi và lập tài liệu.
Kiến trúc được khuyến nghị năm 2026
"Stack dữ liệu phân tích hiện đại" mà KGA khuyến nghị cho khách hàng có sự phân công như sau.
- DWH trung tâm (Snowflake / BigQuery / Databricks): Phân tích xuyên toàn công ty, tài chính, chỉ số kinh doanh. Mở ra bên ngoài bằng ghi lakehouse (Iceberg).
- OLAP thời gian thực (ClickHouse Cloud): Dashboard theo giây, sự kiện quảng cáo/game/IoT, APM.
- Notebook/phân tích cục bộ (DuckDB + MotherDuck): Thử nghiệm của data scientist, tạo data mart trung gian.
- Trực quan hóa phía trình duyệt (DuckDB-WASM): Dashboard công khai, frontend nhẹ của BI nội bộ.
- Edge OLTP+Analytics (Turso): DB theo tenant của SaaS phân tán địa lý.
Đích đến của "stack dữ liệu hiện đại" phiên bản 2026 là cấu hình tích hợp 5 tầng này bằng Semantic Layer (như Cube.dev) và có thể trích xuất tất cả bằng ngôn ngữ tự nhiên từ LLM agent. Thay vì hoàn thành với một nhà cung cấp duy nhất, thiết kế chọn công cụ tối ưu cho từng vai trò và kết nối bằng metadata và ngữ nghĩa có hiệu quả chi phí và khả năng mở rộng cao nhất về lâu dài.