Snowflake 1 — Kiến trúc & định vị trong hệ sinh thái dữ liệu

Snowflake là gì và vì sao khác biệt

Snowflake là một cloud data platform — nền tảng kho dữ liệu (data warehouse) chạy hoàn toàn trên hạ tầng đám mây, được cung cấp dưới dạng dịch vụ (SaaS). Bạn không cài đặt, không quản lý server, không vá bản (patch), không lo dung lượng ổ đĩa. Bạn tạo tài khoản, kết nối, nạp dữ liệu và chạy SQL — phần còn lại (elasticity, backup, upgrade) do Snowflake lo.

Điểm khác biệt cốt lõi so với các kho dữ liệu truyền thống (Oracle Exadata, Teradata, hay cả Redshift đời đầu) nằm ở kiến trúc tách rời lưu trữ và tính toán (decoupled storage and compute). Trong kho dữ liệu cổ điển, mỗi node vừa giữ một phần dữ liệu vừa xử lý query trên phần đó (shared-nothing MPP). Muốn tăng sức tính toán, bạn phải thêm node, và thêm node đồng nghĩa với việc phải phân phối (redistribute) lại dữ liệu — một thao tác chậm và rủi ro. Snowflake phá vỡ ràng buộc này: dữ liệu nằm một nơi (object storage), sức tính toán nằm nơi khác (các cụm compute độc lập), hai bên co giãn hoàn toàn tách biệt.

Hệ quả thực tế với một ngân hàng: đội nạp dữ liệu (ETL) ban đêm, đội phân tích rủi ro tín dụng, và dashboard BI ban ngày có thể dùng ba cụm tính toán riêng biệt cùng đọc một tập dữ liệu mà không giẫm chân nhau. Không còn cảnh một truy vấn báo cáo cuối tháng làm nghẽn toàn hệ thống.

Kiến trúc 3 lớp tách rời

Snowflake được thiết kế theo kiến trúc hybrid — kết hợp shared-disk (mọi node thấy chung một kho dữ liệu) và shared-nothing (mỗi node xử lý cục bộ, song song). Kiến trúc chia làm ba lớp độc lập, mỗi lớp co giãn riêng.

Lớp 1 — Database Storage (lưu trữ)

Đây là nơi dữ liệu thực sự nằm. Khi bạn nạp dữ liệu, Snowflake tự động tổ chức lại nó về định dạng cột (columnar), nén và mã hoá, rồi lưu trên object storage của nhà cung cấp đám mây (Amazon S3, Azure Blob Storage hoặc Google Cloud Storage). Bạn không truy cập trực tiếp các file này — chỉ tương tác qua SQL.

Đơn vị lưu trữ nội bộ là micro-partition: mỗi micro-partition chứa khoảng 50–500 MB dữ liệu chưa nén (tương ứng vài MB đến vài chục MB sau nén). Snowflake tự cắt dữ liệu thành micro-partition khi nạp, và với mỗi partition lưu metadata như giá trị min/max của từng cột, số lượng distinct value, số dòng. Metadata này cho phép pruning — khi query có điều kiện lọc, optimizer bỏ qua toàn bộ những micro-partition chắc chắn không chứa dữ liệu cần, nên không cần quét toàn bảng.

Điểm quan trọng: micro-partition là bất biến (immutable). Snowflake không sửa file tại chỗ; mọi thay đổi tạo phiên bản mới. Đây chính là nền tảng cho tính năng Time Travel (truy vấn dữ liệu tại một thời điểm quá khứ) và zero-copy cloning (nhân bản không tốn thêm chỗ), sẽ bàn ở bài snow-08-timetravel-sharing.

Lớp 2 — Query Processing (xử lý truy vấn)

Đây là lớp compute, hiện thân qua khái niệm virtual warehouse (VWH) — một cụm compute gồm một hoặc nhiều node MPP mà Snowflake cấp phát trên nền đám mây. Khi chạy query, VWH lấy dữ liệu từ lớp storage lên, cache cục bộ (local disk cache) rồi xử lý song song.

Virtual warehouse có các cỡ theo thang số nhân: X-Small, Small, Medium, Large, X-Large... mỗi bậc lớn hơn gấp đôi số node (và gấp đôi chi phí mỗi giờ). Điểm mấu chốt:

• Bật/tắt tức thì: VWH có thể auto-suspend khi rảnh (ngừng tính tiền) và auto-resume khi có query mới.
• Nhiều VWH độc lập cùng đọc chung một storage: mỗi đội, mỗi workload dùng warehouse riêng — không tranh chấp tài nguyên (resource contention).
• Co giãn theo hai chiều: scale up (đổi cỡ warehouse cho query nặng) và scale out (multi-cluster warehouse tự thêm cụm khi nhiều người dùng đồng thời).

Chi tiết vận hành virtual warehouse — cách chọn cỡ, auto-scaling, quản lý cache — được trình bày ở snow-02-virtual-warehouses.

Lớp 3 — Cloud Services (dịch vụ điều phối)

Đây là "bộ não" điều phối toàn hệ thống, chạy trên một pool compute do Snowflake quản lý (bạn không thấy và thường không trả tiền riêng, trừ khi vượt ngưỡng ~10% compute). Lớp này gồm:

Nhờ lớp này tập trung, mọi virtual warehouse chia sẻ chung một catalog nhất quán. Một warehouse ETL vừa ghi xong một bảng, warehouse BI đọc ngay lập tức thấy dữ liệu mới, đúng và nhất quán (consistent) — vì transaction manager điều phối phiên bản.

Tách compute khỏi storage nghĩa là gì

Ý tưởng cốt lõi cần khắc sâu: lưu trữ trả theo dung lượng (GB/tháng), tính toán trả theo thời gian chạy (giây/giờ), hai loại độc lập.

Hình dung một kho on-prem: bạn mua một cụm 20 node. Cụm đó vừa là nơi cất dữ liệu vừa là nơi xử lý. Dữ liệu tăng gấp đôi → bạn phải mua thêm node dù nhu cầu tính toán không đổi. Ngược lại, cuối quý cần chạy báo cáo nặng gấp 5 lần → bạn không thể tăng compute tạm thời, phải chịu chậm hoặc mua dư quanh năm.

Với Snowflake, ba lợi ích trực tiếp:

1. Scale độc lập. Dữ liệu 50 TB nhưng đa số query nhẹ → dùng warehouse Small quanh năm, chỉ trả tiền storage cho 50 TB. Đến kỳ đóng sổ, tạm phóng lên X-Large trong vài giờ rồi thu về.
2. Nhiều warehouse cùng đọc một dữ liệu, không tranh chấp. Đây là điều kho MPP truyền thống không làm được. Ở Snowflake, đội AML, đội báo cáo NHNN, và dashboard giám đốc dùng ba warehouse riêng, cùng đọc bảng transactions, hoàn toàn cách ly về hiệu năng.
3. Không phải di chuyển dữ liệu khi đổi compute. Đổi cỡ warehouse chỉ là cấp lại node — dữ liệu không nhúc nhích, vì nó ở object storage tách rời.

Chạy trên đâu và các edition

Snowflake không có hạ tầng đám mây riêng — nó chạy trên AWS, Azure hoặc GCP. Khi tạo tài khoản, bạn chọn một cloud provider và một region (ví dụ AWS ap-southeast-1 Singapore). Với ngân hàng Việt Nam, việc chọn region ảnh hưởng đến độ trễ, chi phí egress, và đặc biệt là yêu cầu chủ quyền dữ liệu (data residency) — cần đối chiếu với quy định của NHNN và Nghị định về bảo vệ dữ liệu cá nhân trước khi đặt dữ liệu ra region nước ngoài.

Snowflake phân tầng theo edition, khác nhau ở tính năng bảo mật/tuân thủ và số ngày Time Travel, không phải ở hiệu năng thô:

Với ngân hàng, Business Critical thường là mức phù hợp vì nhu cầu tuân thủ PCI-DSS (dữ liệu thẻ), kết nối riêng không đi qua internet công cộng, và khả năng failover. Chi tiết bảo mật/masking ở snow-07-security-governance.

Định vị: Snowflake vs BigQuery vs Redshift vs on-prem

Cần phân biệt hai triết lý compute:

• Snowflake — warehouse-centric (provisioned compute). Bạn cấp phát virtual warehouse rõ ràng, kiểm soát cỡ và số cụm. Trả tiền theo thời gian warehouse chạy. Dễ dự đoán chi phí, kiểm soát mịn.
• BigQuery — serverless (on-demand). Không có "cụm" nào để bật/tắt; Google tự động cấp phát slot (đơn vị tính toán) khi bạn chạy query. Mô hình mặc định trả tiền theo lượng byte quét (per-query on-demand), hoặc mua slot reservation cố định. Bạn hầu như không phải quản lý compute, nhưng đổi lại kiểm soát ít hơn và chi phí biến động theo query. Xem thêm bq-01-overview.

Bảng định vị tổng quát:

Nhìn chung: BigQuery phù hợp khi đội đã đứng trên Google Cloud và muốn zero-ops tuyệt đối, chấp nhận chi phí biến động theo byte quét. Redshift hợp lý khi đã "all-in" AWS và muốn tích hợp sâu với hệ sinh thái AWS. On-prem chỉ còn giữ vai trò khi ràng buộc pháp lý bắt buộc dữ liệu không rời trung tâm dữ liệu nội bộ. Snowflake nổi bật khi cần đa cloud, cách ly workload mạnh, và trải nghiệm SQL/quản trị mượt mà mà không khoá chặt vào một nhà cung cấp đám mây.

Khi nào ngân hàng nên chọn Snowflake

Nên nghiêm túc cân nhắc Snowflake khi tổ chức có các đặc điểm sau:

• Nhiều workload đụng nhau trên cùng dữ liệu. ETL đêm, báo cáo cuối tháng, dashboard giám đốc, mô hình rủi ro — tất cả cần đọc cùng bảng giao dịch nhưng không được làm chậm nhau. Multi-warehouse giải quyết trực tiếp.
• Tải biến động mạnh theo chu kỳ. Đóng sổ cuối tháng/quý, báo cáo NHNN định kỳ, stress test — cần bùng compute vài giờ rồi thu về, không muốn trả tiền cho hạ tầng dư quanh năm.
• Cần chia sẻ dữ liệu an toàn giữa các phòng ban, công ty con, hoặc với bên thứ ba (kiểm toán) mà không sao chép — dùng Secure Data Sharing.
• Muốn giảm gánh nặng vận hành để đội data engineer tập trung vào modeling và pipeline thay vì vá server, tuning ổ đĩa.

Ngược lại, cân nhắc kỹ (hoặc chưa vội) nếu: khối lượng dữ liệu và query còn nhỏ (một Postgres/MySQL managed vẫn đủ và rẻ hơn); ràng buộc data residency chưa cho phép đặt dữ liệu lên cloud region hiện có; hoặc đội chưa có kỷ luật kiểm soát chi phí — vì mô hình trả-theo-giờ dễ "chảy máu" nếu warehouse không auto-suspend. Xem snow-06-cost-management để quản lý chi phí.

Về mặt kỹ thuật, Snowflake hỗ trợ SQL chuẩn ANSI cùng phần mở rộng riêng cho dữ liệu bán cấu trúc (semi-structured) như kiểu VARIANT cho JSON — chi tiết ở snow-04-sql-semistructured. Lưu ý: cú pháp Snowflake là một phương ngữ (dialect) riêng, không tương thích trực tiếp với PostgreSQL. Một câu như dưới đây là hợp lệ trên Snowflake nhưng không chạy được trên sandbox PostgreSQL của Knowledge Base (chỉ để minh hoạ):

-- Cú pháp Snowflake (KHÔNG chạy trên sandbox PostgreSQL — chỉ minh hoạ)
SELECT
    account_id,
    raw:transaction.merchant::string AS merchant,   -- truy cập VARIANT/JSON
    SUM(amount) AS total
FROM transactions_raw
WHERE created_at >= DATEADD('day', -30, CURRENT_DATE())
GROUP BY 1, 2
QUALIFY ROW_NUMBER() OVER (PARTITION BY account_id ORDER BY total DESC) = 1;

Snowflake cũng là một mắt xích tự nhiên trong kiến trúc lakehouse (xem 07-lakehouse) và là đích triển khai phổ biến cho các mô hình biến đổi bằng dbt-01-overview — dbt sinh SQL, Snowflake thực thi.

Use case thực tế

Bối cảnh. Một ngân hàng cỡ vừa có ~8 TB dữ liệu giao dịch lịch sử trong kho on-prem Oracle. Ba nhóm cùng khai thác: (1) pipeline ETL nạp dữ liệu core banking mỗi đêm, (2) đội báo cáo tuân thủ chạy các báo cáo NHNN nặng vào ngày 1–5 hàng tháng, (3) dashboard giám đốc chạy suốt giờ hành chính. Vấn đề: đúng đầu tháng, báo cáo tuân thủ làm nghẽn Oracle, dashboard treo, ETL đêm trễ giờ.

Chuyển sang Snowflake. Kiến trúc bố trí như sau:

• Dữ liệu 8 TB nạp một lần vào storage layer; storage tính tiền ~8 TB nén (thực tế nhỏ hơn nhiều sau nén cột).
• Ba virtual warehouse tách biệt, cùng đọc chung bảng:

Kết quả (minh hoạ). Ba workload không còn tranh chấp: báo cáo tuân thủ chạy trên X-Large riêng, dashboard vẫn mượt trên Small. Nhờ auto-suspend, WH_COMPLIANCE chỉ tính tiền trong 5 ngày/tháng thay vì thường trực. Micro-partition pruning giúp báo cáo lọc theo tháng chỉ quét đúng phần dữ liệu liên quan thay vì full-scan 8 TB. Đội data engineer thôi phải tuning ổ đĩa Oracle ban đêm, dồn thời gian vào modeling.

Tham khảo cách nạp dữ liệu hiệu quả ở snow-03-loading-data và tối ưu hiệu năng ở snow-05-performance.

Ghi nhớ

• Snowflake là cloud data platform (SaaS) chạy trên AWS/Azure/GCP; bạn không quản lý hạ tầng, chỉ dùng SQL.
• Kiến trúc 3 lớp tách rời: Database Storage (micro-partition cột, nén, mã hoá trên object storage) — Query Processing (virtual warehouse) — Cloud Services (metadata, optimizer, security, transaction).
• Tách compute khỏi storage là đặc trưng cốt lõi: scale độc lập, nhiều warehouse cùng đọc một dữ liệu không tranh chấp, đổi compute không phải di chuyển dữ liệu.
• Micro-partition bất biến là nền cho Time Travel và zero-copy cloning; metadata min/max cho phép pruning để không full-scan.
• Edition: Standard (cơ bản, Time Travel 1 ngày) → Enterprise (multi-cluster, masking, 90 ngày) → Business Critical (PCI-DSS/HIPAA, PrivateLink, failover) — ngân hàng thường cần Business Critical.
• Định vị: Snowflake dùng warehouse cấp phát (provisioned); BigQuery serverless trả theo byte quét/slot; Redshift gắn AWS; on-prem gắn chặt storage-compute.
• Chọn Snowflake khi có nhiều workload đụng nhau, tải biến động theo chu kỳ, cần chia sẻ dữ liệu an toàn và giảm gánh nặng vận hành — nhưng phải có kỷ luật auto-suspend để kiểm soát chi phí và kiểm tra ràng buộc data residency.
• SQL Snowflake là phương ngữ riêng (VARIANT, QUALIFY, DATEADD...), không tương thích trực tiếp PostgreSQL — không chạy được trên sandbox.