Data Engineering 11 — Nền tảng dữ liệu đám mây

Vì sao chuyển lên nền tảng dữ liệu đám mây?

Trong nhiều năm, kho dữ liệu (data warehouse) doanh nghiệp chạy trên các "appliance" on-prem như Teradata, Oracle Exadata hay IBM Netezza. Đây là những cỗ máy mạnh nhưng có ba điểm đau cố hữu mà bất kỳ kỹ sư dữ liệu nào từng vận hành cũng nhận ra.

Thứ nhất là giới hạn cứng về quy mô. Khi dữ liệu tăng hay số người dùng truy vấn tăng, bạn phải mua thêm node — một quy trình mua sắm kéo dài hàng tháng, tốn vốn đầu tư (CAPEX) lớn, và một khi đã mua thì không thể "trả lại" lúc nhàn rỗi. Bạn buộc phải mua theo đỉnh tải (peak), nên phần lớn thời gian phần cứng nằm không.

Thứ hai là compute và storage bị buộc chặt vào nhau. Trên kiến trúc truyền thống, CPU và đĩa nằm chung trên một node. Muốn lưu thêm dữ liệu, bạn phải mua thêm cả CPU dù không cần; muốn tăng sức tính toán, bạn phải mua thêm cả đĩa dù không cần. Điều này khiến việc tối ưu hóa chi phí gần như bất khả thi.

Thứ ba là xung đột tài nguyên (resource contention). Khi đội ETL chạy job nặng ban đêm trùng với báo cáo của ban lãnh đạo, hai khối lượng công việc tranh nhau cùng một bộ CPU. Một truy vấn ngốn tài nguyên có thể làm chậm toàn bộ hệ thống.

Nền tảng dữ liệu đám mây (cloud data platform) ra đời để giải quyết đúng ba điểm này, dựa trên ba lời hứa:

• Co giãn (elasticity): Tăng/giảm năng lực tính toán trong vài giây hoặc vài phút, không cần mua phần cứng. Cần thì bật, không cần thì tắt.
• Tách compute và storage: Lưu trữ và tính toán được tách thành hai lớp độc lập, mở rộng riêng rẽ. Trả tiền lưu trữ rẻ cho dữ liệu lớn, và chỉ trả tiền tính toán khi thực sự chạy truy vấn.
• Trả theo dùng (pay-per-use): Chuyển từ CAPEX sang OPEX. Bạn trả tiền theo giây/phút compute hoặc theo lượng dữ liệu quét, thay vì mua trước cả một cỗ máy.

Bài này phân tích kiến trúc đứng sau những lời hứa đó (MPP, tách compute–storage), so sánh khách quan bốn nền tảng phổ biến nhất, cách tính phí và tối ưu chi phí, các vấn đề bảo mật — tuân thủ, và một khung quyết định để chọn nền tảng — đặc biệt trong bối cảnh nhạy cảm như ngân hàng.

Kiến trúc nền tảng: MPP và tách compute–storage

MPP là gì?

MPP (Massively Parallel Processing) là mô hình xử lý song song quy mô lớn. Thay vì một máy chủ duy nhất xử lý toàn bộ truy vấn (mô hình SMP — symmetric multiprocessing), MPP chia dữ liệu và công việc ra nhiều node, mỗi node xử lý một phần độc lập rồi tổng hợp kết quả lại.

Hãy hình dung một truy vấn SELECT region, SUM(amount) FROM transactions GROUP BY region trên 10 tỷ dòng. Trên một máy đơn, bạn phải đọc tuần tự cả 10 tỷ dòng. Trên hệ MPP với 20 node, dữ liệu được phân tán đều, mỗi node chỉ đọc và tổng hợp ~500 triệu dòng cục bộ, sau đó một bước trộn (shuffle/aggregate) cuối cùng gộp 20 kết quả riêng phần lại. Lý thuyết là gần tuyến tính: gấp đôi node, gần như giảm nửa thời gian.

Đặc trưng kỹ thuật của MPP:

• Shared-nothing: mỗi node có CPU, RAM và (truyền thống) đĩa riêng, không chia sẻ trạng thái. Đây là yếu tố giúp mở rộng ngang dễ dàng.
• Data distribution / partitioning: dữ liệu được phân tán theo một khóa (distribution key) hoặc theo hash, sao cho các node cân bằng tải và giảm shuffle khi join.
• Lưu trữ cột (columnar): hầu hết kho dữ liệu MPP lưu theo cột chứ không theo dòng, nên truy vấn phân tích chỉ đọc đúng các cột cần, nén tốt và quét ít hơn nhiều.

Tách compute–storage — bước nhảy của thế hệ cloud

MPP truyền thống (Teradata, Redshift đời đầu) vẫn theo shared-nothing có đĩa cục bộ: dữ liệu nằm ngay trên node tính toán. Hệ quả là muốn co giãn compute, bạn phải di chuyển/cân bằng lại dữ liệu (redistribution) — chậm và rủi ro.

Thế hệ cloud (Snowflake, BigQuery, Redshift RA3) tách lớp lưu trữ ra một dịch vụ object storage dùng chung và bền (S3, Google Cloud Storage, Azure Blob), còn các cụm tính toán chỉ là những node "vô trạng thái" đọc dữ liệu từ kho chung đó, có cache cục bộ để tăng tốc.

Lợi ích trực tiếp:

• Mở rộng độc lập: thêm dung lượng lưu trữ không đụng tới compute và ngược lại.
• Nhiều cụm trên cùng một dữ liệu: đội ETL, đội BI và đội ML chạy trên ba cụm riêng, không tranh tài nguyên, cùng đọc một bản dữ liệu duy nhất. Không còn xung đột tải.
• Tắt khi nhàn: cụm compute có thể tự ngừng (auto-suspend) khi không có truy vấn, ngừng tính tiền compute, trong khi dữ liệu vẫn an toàn ở lớp storage.

Đây chính là nền móng kỹ thuật giúp ba lời hứa ở phần đầu trở thành hiện thực.

So sánh các nền tảng

Dưới đây là bốn nền tảng phổ biến nhất, cùng vài cái tên đáng nhắc. Mỗi nền tảng có một triết lý kiến trúc khác nhau, dẫn tới thế mạnh và mô hình chi phí khác nhau.

Snowflake

Snowflake là nền tảng "cloud-native" thuần, chạy trên cả AWS, Azure và GCP. Điểm cốt lõi là kiến trúc ba lớp: lưu trữ tập trung, các virtual warehouse (cụm compute) độc lập, và lớp dịch vụ điều phối/metadata.

• Multi-cluster warehouse: một warehouse có thể tự nhân thêm cụm khi nhiều người dùng truy vấn đồng thời (xử lý concurrency), rồi tự co lại.
• Tách compute triệt để: mỗi nhóm công việc dùng warehouse riêng (size XS đến 6XL), bật/tắt độc lập, tính tiền theo giây sau phút đầu.
• Dễ dùng: gần như không phải tinh chỉnh index, vacuum hay phân phối dữ liệu thủ công; vận hành nhẹ.
• Điểm cần lưu ý: chi phí compute có thể tăng nhanh nếu warehouse để chạy không kiểm soát; cần kỷ luật về auto-suspend.

Google BigQuery

BigQuery là kho dữ liệu serverless của Google. Bạn không quản lý cụm nào cả — chỉ gửi SQL, Google tự cấp phát tài nguyên (gọi là "slots").

• Serverless thật sự: không có khái niệm node/cluster để bật tắt; phù hợp đội nhỏ, ít vận hành.
• Tính theo dữ liệu quét (on-demand): mặc định tính tiền theo số byte quét cho mỗi truy vấn. Một truy vấn SELECT * trên bảng lớn có thể tốn bất ngờ.
• Hiệu năng cao với dữ liệu lớn nhờ tách compute–storage (Dremel/Colossus) và partition + cluster.
• Tích hợp hệ sinh thái Google (GCS, Looker, Vertex AI). Có chế độ giá theo dung lượng (capacity/editions) để kiểm soát chi phí nếu khối lượng lớn ổn định.

Databricks

Databricks không xuất phát là data warehouse mà là nền tảng lakehouse dựa trên Apache Spark và định dạng bảng mở Delta Lake (cùng họ với Iceberg/Hudi). Lakehouse là ý tưởng kết hợp tính linh hoạt/rẻ của data lake với tính giao dịch/chất lượng của warehouse.

• Mạnh nhất về ETL quy mô lớn, dữ liệu phi cấu trúc và Machine Learning — Spark xử lý mọi dạng dữ liệu, MLflow quản lý vòng đời mô hình.
• Delta Lake mang lại ACID, time travel, schema enforcement trên file Parquet đặt ngay trên object storage.
• Databricks SQL / Photon cung cấp engine truy vấn nhanh cho BI, thu hẹp khoảng cách với warehouse thuần.
• Điểm cần lưu ý: linh hoạt đi kèm độ phức tạp; cần năng lực kỹ thuật cao hơn để vận hành tốt so với Snowflake hay BigQuery.

Amazon Redshift

Redshift là kho dữ liệu MPP của AWS, ra đời sớm. Thế hệ node RA3 đã tách compute khỏi storage (dùng "managed storage" trên S3), thu hẹp khoảng cách với thế hệ cloud-native.

• MPP truyền thống + RA3: kiểm soát node chi tiết, gắn bó chặt với hệ sinh thái AWS (S3, Glue, IAM).
• Redshift Serverless: lựa chọn không quản lý cụm, tính theo năng lực dùng.
• Điểm cần lưu ý: cần tinh chỉnh nhiều hơn (distkey, sortkey, vacuum) để đạt hiệu năng tốt; vận hành "tay chân" hơn Snowflake.

Đáng nhắc thêm

• Azure Synapse Analytics: kho dữ liệu MPP của Microsoft, tích hợp sâu hệ Azure và Power BI; gồm cả dedicated pool (MPP) lẫn serverless SQL trên data lake. Lựa chọn tự nhiên nếu doanh nghiệp đã dùng Azure.
• ClickHouse: cơ sở dữ liệu OLAP columnar mã nguồn mở, cực nhanh cho phân tích thời gian thực và truy vấn trên dữ liệu sự kiện/log với độ trễ rất thấp; không phải warehouse đa năng nhưng vô địch ở mảng analytics tốc độ cao.

Bảng so sánh

Nền tảng	Mô hình	Thế mạnh	Tính phí	Khi nào dùng
Snowflake	Cloud-native, tách compute, multi-cluster	Dễ dùng, vận hành nhẹ, xử lý concurrency tốt	Theo giây compute (per warehouse) + storage	Đội muốn warehouse mạnh, ít vận hành, đa cloud
BigQuery	Serverless	Không quản lý hạ tầng, scale tự động, hệ sinh thái Google	Theo byte quét (on-demand) hoặc theo capacity	Đội nhỏ/GCP, workload không đều, muốn zero-ops
Databricks	Lakehouse (Spark + Delta)	ETL lớn, dữ liệu phi cấu trúc, ML/AI	Theo DBU (compute) + storage	Khối lượng ML/ETL nặng, dữ liệu đa dạng
Redshift	MPP + RA3 / Serverless	Tích hợp sâu AWS, kiểm soát node chi tiết	Theo node-giờ hoặc serverless (RPU)	Đã dùng AWS, cần kiểm soát chi phí/hiệu năng
Synapse	MPP + serverless SQL	Tích hợp Azure & Power BI	Theo pool/giờ hoặc theo dữ liệu xử lý	Doanh nghiệp dùng hệ Azure
ClickHouse	OLAP columnar (open source)	Analytics realtime, độ trễ thấp	Tự host (hạ tầng) hoặc Cloud theo dùng	Phân tích log/sự kiện tốc độ cao

Mô hình tính phí và tối ưu chi phí

Một sự thật phũ phàng: cloud data platform dễ bắt đầu nhưng cũng dễ "đốt tiền". Hiểu mô hình tính phí là kỹ năng cốt lõi của kỹ sư dữ liệu hiện đại. Có hai trường phái tính phí chính:

1. Tính theo compute (Snowflake, Databricks, Redshift provisioned). Bạn trả tiền cho thời gian cụm chạy, bất kể truy vấn nặng hay nhẹ. Đòn bẩy tối ưu là kích thước cụm và thời gian cụm bật.

2. Tính theo dữ liệu quét (BigQuery on-demand). Bạn trả tiền theo số byte mà truy vấn đọc từ đĩa. Đòn bẩy tối ưu là giảm lượng dữ liệu mỗi truy vấn phải quét.

Các kỹ thuật tối ưu chi phí

• Auto-suspend / auto-resume: đặt cụm tự ngừng sau vài phút nhàn rỗi (ví dụ 60 giây với Snowflake). Đây thường là khoản tiết kiệm lớn nhất — đừng để warehouse chạy 24/7 cho một workload chỉ hoạt động vài giờ.
• Partitioning (phân vùng): chia bảng theo cột thường lọc, điển hình là ngày. Truy vấn có WHERE ngay = '2026-06-30' chỉ quét đúng phân vùng đó thay vì cả bảng — gọi là partition pruning. Tác động trực tiếp tới hóa đơn BigQuery.
• Clustering / sorting: sắp xếp dữ liệu vật lý theo cột hay lọc/join (cluster key trên BigQuery/Snowflake, sortkey trên Redshift) để engine bỏ qua các block không liên quan.
• Tránh SELECT *: với lưu trữ cột, chỉ chọn cột cần dùng sẽ giảm mạnh dữ liệu quét — đặc biệt quan trọng trên mô hình tính theo byte.
• Chọn đúng size cụm: cụm lớn chạy nhanh hơn nhưng tốn theo cấp số nhân; nhiều khi cụm nhỏ chạy lâu hơn một chút lại rẻ hơn. Đo và thử nghiệm.
• Materialization & cache: lưu kết quả trung gian (materialized view) hoặc tận dụng result cache cho các truy vấn lặp lại, tránh tính lại từ đầu.
• Tách workload theo cụm: ETL nặng ban đêm dùng cụm riêng, có thể tắt ban ngày; BI dùng cụm nhỏ luôn sẵn sàng.
• Giám sát & cảnh báo: đặt budget alert và quota; theo dõi truy vấn tốn nhất hằng ngày. Một dashboard chi phí là khoản đầu tư đáng giá.

Bảo mật và tuân thủ trên cloud

Khi dữ liệu rời khỏi trung tâm dữ liệu nội bộ, bảo mật trở thành trách nhiệm chia sẻ giữa nhà cung cấp và bạn (shared responsibility model). Nhà cung cấp bảo vệ hạ tầng; bạn chịu trách nhiệm cấu hình truy cập, phân quyền và bảo vệ dữ liệu của mình.

Các lớp kiểm soát cần có:

• Mã hóa: bật mã hóa khi lưu (at-rest) và khi truyền (in-transit, TLS). Cân nhắc tự quản lý khóa (CMK/BYOK) cho dữ liệu nhạy cảm.
• Kiểm soát truy cập: RBAC (role-based access control), nguyên tắc đặc quyền tối thiểu, tách bạch vai trò người vận hành và người đọc dữ liệu.
• Bảo vệ ở mức cột/dòng: column-level masking che dữ liệu nhạy cảm (số tài khoản, CMND), row-level security giới hạn dòng theo người dùng/chi nhánh.
• Cô lập mạng: private link/VPC endpoint để dữ liệu không đi qua internet công cộng; danh sách IP cho phép.
• Audit log: ghi lại mọi truy vấn và truy cập, phục vụ điều tra và chứng minh tuân thủ.
• Data masking & tokenization cho dữ liệu cá nhân (PII) trước khi đưa vào môi trường phân tích/test.

Về tuân thủ, các nền tảng lớn đều có chứng nhận SOC 2, ISO 27001, PCI-DSS và hỗ trợ các yêu cầu về cư trú dữ liệu (data residency) — chọn region phù hợp với quy định nơi bạn hoạt động.

Di chuyển từ on-prem (bối cảnh ngân hàng)

Với một ngân hàng đang vận hành kho dữ liệu on-prem (ví dụ Teradata/Oracle), chuyển lên cloud không đơn thuần là vấn đề kỹ thuật mà là bài toán pháp lý — rủi ro.

Những lưu ý đặc thù:

• Quy định về dữ liệu: nhiều quốc gia (Việt Nam có Nghị định 13/2023 về bảo vệ dữ liệu cá nhân, cùng các quy định của ngân hàng nhà nước về dữ liệu) yêu cầu dữ liệu khách hàng phải lưu trong nước hoặc tuân theo điều kiện chuyển dữ liệu ra nước ngoài. Phải kiểm tra region và điều khoản cư trú dữ liệu trước tiên.
• Phân loại dữ liệu: không phải mọi dữ liệu đều nhạy cảm như nhau. Một chiến lược thực dụng là phân loại trước, rồi giữ lại dữ liệu nhạy cảm nhất (PII trần) ở nơi kiểm soát chặt, chỉ đẩy dữ liệu đã mã hóa/tokenize/ẩn danh lên cloud.
• Mô hình lai (hybrid): nhiều ngân hàng chọn hybrid trong giai đoạn đầu — analytics và ML trên cloud, dữ liệu lõi giao dịch còn ở on-prem — để cân bằng rủi ro.
• Cách tiếp cận di chuyển: ưu tiên strangler (di chuyển dần từng domain/workload) thay vì "big bang"; chạy song song (parallel run) và đối chiếu kết quả on-prem với cloud trước khi cắt chuyển.
• Quản trị nhà cung cấp: đánh giá rủi ro nhà cung cấp, điều khoản hợp đồng (SLA, thoát ràng buộc - exit), và khả năng tránh khóa cứng (vendor lock-in) bằng định dạng mở như Parquet/Iceberg.

Tóm lại: trong ngân hàng, quyết định kiến trúc luôn phải bắt đầu từ câu hỏi "dữ liệu này được phép đặt ở đâu?" trước khi bàn tới hiệu năng hay chi phí.

Tiêu chí chọn nền tảng (cây quyết định)

Không có nền tảng "tốt nhất" tuyệt đối — chỉ có nền tảng phù hợp nhất với ràng buộc của bạn. Hãy trả lời theo thứ tự ưu tiên: ràng buộc pháp lý/cloud hiện có, loại khối lượng công việc, rồi mức độ sẵn sàng vận hành.

Một vài nguyên tắc thực dụng kèm theo cây trên:

• Nếu doanh nghiệp đã đầu tư sâu vào một cloud, hãy bắt đầu từ kho dữ liệu native của cloud đó — giảm chi phí tích hợp và truyền dữ liệu.
• Nếu trọng tâm là BI và SQL với mong muốn vận hành nhẹ, Snowflake (đa cloud) hoặc BigQuery (GCP) là điểm khởi đầu tự nhiên.
• Nếu trọng tâm là ML, dữ liệu phi cấu trúc và ETL quy mô lớn, lakehouse kiểu Databricks phù hợp hơn.
• Nếu là analytics thời gian thực trên log/sự kiện, cân nhắc ClickHouse.
• Trong môi trường bị ràng buộc pháp lý nặng (ngân hàng), tiêu chí cư trú dữ liệu và bảo mật có thể loại bỏ lựa chọn trước cả khi xét hiệu năng.

Tóm tắt

• Nền tảng dữ liệu đám mây giải quyết ba điểm đau của kho on-prem: giới hạn quy mô, compute/storage bị buộc chặt, và xung đột tài nguyên — bằng co giãn, tách compute–storage và trả theo dùng.
• MPP chia dữ liệu và công việc ra nhiều node song song; thế hệ cloud tách lớp storage chung (object storage) khỏi các cụm compute vô trạng thái, cho phép mở rộng độc lập và nhiều cụm trên cùng dữ liệu.
• Bốn nền tảng chủ đạo theo bốn triết lý: Snowflake (cloud-native, dễ dùng), BigQuery (serverless, tính theo byte quét), Databricks (lakehouse, Spark + Delta, mạnh ML), Redshift (MPP + RA3, gắn AWS); thêm Synapse (Azure) và ClickHouse (OLAP realtime).
• Chi phí có hai trường phái — theo compute và theo dữ liệu quét; tối ưu bằng auto-suspend, partition/cluster, tránh SELECT *, chọn đúng size cụm và giám sát budget.
• Bảo mật là trách nhiệm chia sẻ: mã hóa, RBAC, masking cột/dòng, private network, audit log; tuân thủ cần xét chứng nhận và cư trú dữ liệu.
• Trong ngân hàng, câu hỏi "dữ liệu được phép đặt ở đâu?" đến trước hiệu năng và chi phí; ưu tiên di chuyển dần (hybrid/strangler) và định dạng mở để tránh khóa cứng.

Tự kiểm tra

1. Vì sao việc tách compute khỏi storage lại quan trọng hơn nhiều so với việc chỉ "chạy MPP trên cloud"? Nó giải quyết những điểm đau on-prem nào?
2. Giải thích sự khác nhau cốt lõi giữa mô hình tính phí của BigQuery (on-demand) và Snowflake. Mỗi mô hình cần đòn bẩy tối ưu nào?
3. Một truy vấn SELECT * FROM giao_dich WHERE thang = '2026-06' chạy tốn bất ngờ trên BigQuery. Bạn sẽ đề xuất hai thay đổi nào và vì sao?
4. Trong tình huống nào bạn chọn Databricks thay vì Snowflake, và ngược lại?
5. Một ngân hàng muốn đưa dữ liệu khách hàng lên cloud. Hãy liệt kê ba lưu ý pháp lý/bảo mật phải kiểm tra trước khi bàn về kỹ thuật.
6. "Shared responsibility model" nghĩa là gì? Đâu là phần trách nhiệm của bạn mà nhà cung cấp không gánh thay?

Đọc tiếp

Data Engineering 12 — CDC & Realtime