Cloud DE 3 — Compute cho workload dữ liệu

Compute là biến chi phí lớn nhất của một nền tảng dữ liệu

Ở Cloud DE 2 — Storage ta đã thấy storage trên object store (S3/GCS/ADLS) rẻ và gần như vô hạn. Nhưng dữ liệu nằm im không sinh giá trị — bạn phải tính toán trên nó: ETL đêm, huấn luyện mô hình, truy vấn báo cáo, chấm điểm giao dịch real-time. Compute chính là phần đắt nhất và khó quản nhất của hoá đơn cloud.

Cái hay của cloud là bạn không mua một loại máy chủ rồi ép mọi workload chạy trên đó (như thời on-premise, khi một cụm Hadoop cố định phải gánh cả batch lẫn ad-hoc). Cloud cho bạn một phổ lựa chọn compute, từ "tự quản hoàn toàn" đến "không thấy máy chủ đâu cả". Nghệ thuật của data engineer là ghép đúng workload với đúng loại compute — sai một nhịp, bạn hoặc trả tiền cho máy chạy không tải, hoặc chật vật vì khởi động nguội (cold start) khi cần độ trễ thấp.

Bài này đi qua sáu họ compute, khi nào dùng cái nào, và những nguyên tắc chọn lựa cốt lõi. Series liên quan: Cloud DE 1 — Tổng quan, Cloud DE 4 — Mạng & bảo mật, Cloud DE 5 — Managed data services, Cloud DE 7 — Chi phí & độ tin cậy.

---

Phổ compute: từ IaaS đến serverless

Hãy hình dung một trục "mức trừu tượng". Càng sang phải, bạn càng bớt phải quản (OS, patch, scaling, cấp phát máy), đổi lại càng ít quyền kiểm soát chi tiết và (thường) trả theo mức dùng thay vì theo thời gian máy chạy.

Sáu họ chính:

1. VM / instance (IaaS) — bạn thuê máy ảo, tự cài mọi thứ.
2. Container & Kubernetes — đóng gói ứng dụng, orchestrate trên cụm managed.
3. Serverless functions — chạy một hàm khi có sự kiện, không thấy máy chủ.
4. Managed Spark / xử lý phân tán — cụm Spark/Flink managed cho batch nặng.
5. Serverless query / warehouse — truy vấn SQL trực tiếp trên storage, không quản cụm.
6. Managed streaming compute — xử lý dòng sự kiện liên tục.

---

1. VM / instance (IaaS) — kiểm soát tối đa

Máy ảo (EC2 trên AWS, Compute Engine trên GCP, Virtual Machines trên Azure) là nền tảng cơ bản nhất. Bạn chọn CPU/RAM/GPU, cài OS, cài phần mềm, tự lo scaling và vá lỗi bảo mật.

Khi nào dùng: phần mềm legacy không container hoá được; workload cần kiểm soát kernel/driver đặc thù (ví dụ GPU driver cho một phiên bản CUDA cố định); hoặc khi bạn tự vận hành một hệ như Kafka/Trino và muốn tinh chỉnh tận gốc.

Ba mô hình giá ảnh hưởng trực tiếp tới data engineer:

Mô hình	Cơ chế	Dùng cho
On-demand	Trả theo giây/giờ, bật tắt tự do	Tải bất định, thử nghiệm ngắn
Reserved / Committed / Savings Plan	Cam kết 1–3 năm, giảm 40–70%	Tải nền chạy 24/7 (metastore, service ổn định)
Spot / Preemptible / Spot VM	Đấu giá dung lượng dư, giảm tới 70–90%, có thể bị thu hồi	Workload chịu được gián đoạn (worker Spark)

Spot rẻ khủng khiếp nhưng cloud có thể thu hồi máy khi cần dung lượng cho khách trả on-demand, thường báo trước rất ngắn (AWS: 2 phút). Với batch có checkpoint và retry, mất một worker chỉ là chậm chút; với một database chủ, mất máy là mất dịch vụ. Xem thêm ở Cloud DE 7.

Nhược điểm lớn của IaaS thuần cho dữ liệu: bạn ôm hết vận hành — cập nhật, giám sát, tự viết auto-scaling. Vì thế với workload dữ liệu, người ta thường leo lên các tầng managed phía trên.

---

2. Container & Kubernetes — nền chạy Spark/Flink/API dữ liệu

Container (Docker) đóng gói ứng dụng cùng dependencies thành một artifact chạy nhất quán mọi nơi. Kubernetes (K8s) là hệ điều phối container: nó lập lịch pod lên node, tự khởi động lại khi hỏng, và scale theo tải. Ba cloud đều có K8s managed: EKS (AWS), GKE (GCP), AKS (Azure) — bạn không phải tự quản control plane.

Với dữ liệu, K8s là nơi tự nhiên để chạy:

• API dữ liệu / microservice phục vụ feature store, scoring, tra cứu — cần luôn sẵn sàng, độ trễ thấp.
• Spark on Kubernetes hoặc Flink on Kubernetes — dùng K8s làm resource manager thay cho YARN.
• Airflow / dbt / job orchestration đóng container, chạy như pod ngắn hạn.

Điểm mạnh: một mặt phẳng điều phối duy nhất cho nhiều loại workload, tối ưu bin-packing (nhét nhiều pod lên ít node), tận dụng spot node cho nhóm worker. Đánh đổi: K8s có độ phức tạp vận hành cao (networking, RBAC, autoscaler). Chi tiết vận hành production ở Kubernetes 8 — Production Ops.

Với API real-time trong ngân hàng (ví dụ scoring giao dịch dưới 100ms), container trên K8s là lựa chọn hợp lý: pod luôn "ấm", horizontal pod autoscaler co giãn theo QPS, không dính cold start như serverless functions.

---

3. Serverless functions — event-driven, glue nhẹ

AWS Lambda, Google Cloud Functions, Azure Functions: bạn upload một hàm, cloud chạy nó khi có sự kiện (file mới trên S3, message trên queue, HTTP request, cron), tự scale từ 0 tới hàng nghìn instance, trả tiền theo số lần gọi và thời gian chạy (mili-giây × bộ nhớ).

Rất hợp cho:

• Glue / trigger: file đáp xuống bucket landing → Lambda ghi metadata, gọi kích hoạt pipeline.
• Xử lý nhẹ theo sự kiện: biến đổi từng bản ghi, validate schema, đẩy vào queue.
• Điều phối event-driven: dán các bước lại (S3 event → Lambda → Step Functions → job).

Giới hạn phải nhớ:

• Cold start: lần gọi đầu (hoặc sau nhàn rỗi) phải khởi tạo runtime — thêm hàng chục tới hàng trăm ms, tệ hơn với ngôn ngữ nặng (JVM). Có provisioned concurrency để giữ ấm nhưng mất phần "trả theo dùng".
• Thời gian chạy tối đa (Lambda: 15 phút), bộ nhớ có trần, khó xử lý dataset lớn — không thay được Spark cho batch nặng.
• Khó debug và quan sát trạng thái trong pipeline dài.

Nguyên tắc: functions là keo dán và xử lý mỏng theo sự kiện, không phải nơi làm heavy-lifting dữ liệu.

---

4. Managed Spark / xử lý phân tán — batch nặng

Đây là con ngựa thồ của kỹ thuật dữ liệu: transform terabyte, join bảng lớn, tổng hợp lịch sử. Bạn không muốn tự dựng cụm Spark từ VM trần. Các dịch vụ managed:

Dịch vụ	Cloud	Đặc điểm
EMR	AWS	Spark/Hive/Flink/Presto trên cụm; có EMR Serverless và EMR on EKS
Dataproc	GCP	Cụm Spark/Hadoop khởi động ~90s; có Dataproc Serverless
HDInsight / Synapse Spark	Azure	Spark pool trong Synapse Analytics
Databricks	Đa cloud	Nền lakehouse tối ưu Spark (Photon), quản lý cụm & DBU

Mẫu hình đúng: cụm phù du (ephemeral). Job ETL đêm khởi cụm lúc 1h sáng, chạy 90 phút, rồi tắt hoàn toàn — không để cụm chạy 24/7. Kết hợp:

• Worker chạy spot/preemptible (chịu được thu hồi nhờ retry/checkpoint), driver chạy on-demand cho ổn định.
• Auto-scaling theo lượng task chờ.
• Đọc/ghi thẳng vào object store, để compute và storage tách rời (mục dưới).

Xem Cloud DE 5 — Managed data services và series Databricks bắt đầu từ dbx-01 để đi sâu.

---

5. Serverless query / warehouse — truy vấn không quản hạ tầng

Một bước tiến lớn: truy vấn SQL mà không cần cụm nào cả. Bạn viết SQL, nền tảng lo phần tính toán và tính tiền theo dữ liệu quét hoặc theo đơn vị tính toán tạm thời.

Dịch vụ	Cloud	Mô hình
Athena	AWS	Query trên S3 (Trino/Presto), tính tiền theo TB quét
BigQuery	GCP	Warehouse serverless, on-demand theo byte quét hoặc slot
Redshift Serverless	AWS	Warehouse tự co giãn theo RPU, không quản node
Synapse serverless SQL	Azure	Query trên data lake (ADLS), theo TB quét

Khi nào dùng: truy vấn ad-hoc, khám phá dữ liệu, báo cáo BI với tần suất bất định — nơi việc duy trì một cụm luôn bật là lãng phí. Bạn "hỏi thì trả tiền", rảnh thì không tốn gì.

Lưu ý chi phí: mô hình theo-byte-quét trừng phạt query cẩu thả — SELECT * trên bảng khổng lồ có thể quét vài TB và tốn bộ tiền. Cách giảm: dùng định dạng cột (Parquet/ORC) để chỉ đọc cột cần, partition pruning, và nén. Đây chính là lý do storage layout (đã bàn ở Cloud DE 2) ảnh hưởng trực tiếp tới hoá đơn compute.

Ranh giới với managed Spark: serverless query mạnh cho SQL phân tích tương tác; batch transform phức tạp (UDF, ML, xử lý nhiều bước có state) vẫn hợp Spark hơn.

---

6. Managed streaming compute — xử lý dòng liên tục

Với dữ liệu chảy liên tục (giao dịch thẻ, log, sự kiện app), bạn cần compute luôn chạy, xử lý theo cửa sổ thời gian:

• Kinesis Data Analytics / Managed Flink (AWS), Dataflow (GCP, mô hình Apache Beam), Stream Analytics (Azure).
• Spark Structured Streaming hoặc Flink chạy trên EMR/Dataproc/K8s.

Khác biệt cốt lõi với batch: streaming compute là long-running — không có khái niệm "tắt khi rảnh" như ETL đêm; bạn trả tiền cho khả năng xử lý được cấp phát (đôi khi auto-scale theo throughput). Vì thế chi phí streaming cần theo dõi riêng (xem Cloud DE 7).

---

Nguyên tắc chọn compute

Sáu họ trên không thay thế nhau — chúng phục vụ hình dạng workload khác nhau. Bốn trục quyết định:

Hình dạng workload

• Batch nặng (transform TB, chạy theo lịch): managed Spark, cụm ephemeral, worker spot.
• Interactive / ad-hoc (query thưa, khó đoán): serverless query.
• Streaming (liên tục, cửa sổ thời gian): managed streaming.
• Event-driven / glue (phản ứng theo sự kiện, xử lý mỏng): serverless functions.
• Service luôn sẵn sàng (API độ trễ thấp): container trên K8s.

Tách compute khỏi storage

Kiến trúc cloud hiện đại tách compute và storage để scale độc lập: dữ liệu nằm trên object store, compute là những cụm phù du đọc/ghi vào đó. Lợi ích:

• Scale độc lập: thêm compute khi cần nhanh mà không đụng dữ liệu; ngược lại dữ liệu lớn lên không ép phải giữ compute lớn.
• Tắt khi rảnh: compute là chi phí biến đổi lớn nhất; tách ra thì tắt cụm ban ngày, storage vẫn còn nguyên.
• Nhiều engine trên một dữ liệu: Spark, Trino, warehouse cùng đọc một lake.

Serverless vs cluster: thưa hay dày?

Quy tắc ngón tay cái theo mật độ sử dụng:

• Tải thưa, bất định → serverless (functions, serverless query). Rảnh không tốn tiền, không cold-start ai để ý.
• Tải dày, liên tục → cluster/reserved. Khi máy chạy gần như 24/7, đơn giá cluster reserved rẻ hơn nhiều so với đơn giá cao của serverless.

Điểm hoà vốn tuỳ dịch vụ, nhưng logic không đổi: serverless bán sự tiện lợi và co giãn với đơn giá cao hơn; cluster rẻ hơn khi bạn ép được utilization cao.

Spot/preemptible cho phần chịu gián đoạn

Với workload idempotent, có checkpoint/retry (worker Spark, render batch), spot/preemptible cắt 70–90% chi phí. Không dùng spot cho thành phần có state không phục hồi được hoặc phải luôn sống (driver chính, database, service SLA cao). Chi tiết chiến lược chi phí ở Cloud DE 7 và series FinOps.

Auto-scaling, scale-to-zero và cold start

• Auto-scaling: cụm co giãn theo tải (task chờ, QPS, độ trễ queue). Cân bằng độ trễ scale-up với chi phí giữ dư.
• Scale-to-zero: serverless và một số dịch vụ (Cloud Run, serverless query) về 0 khi rảnh → không tốn tiền lúc nhàn.
• Cold start là cái giá của scale-to-zero: instance đầu tiên sau nhàn rỗi phải khởi động. Chấp nhận được với batch/glue; với API độ trễ thấp thì giữ tối thiểu instance ấm hoặc dùng container thường trú.

---

Bảng ánh xạ ba cloud

Nhu cầu compute	AWS	GCP	Azure
VM / IaaS	EC2	Compute Engine	Virtual Machines
Kubernetes managed	EKS	GKE	AKS
Container serverless	Fargate / App Runner	Cloud Run	Container Apps
Serverless functions	Lambda	Cloud Functions	Azure Functions
Managed Spark	EMR (+ Serverless)	Dataproc (+ Serverless)	Synapse Spark / HDInsight
Serverless query	Athena	BigQuery	Synapse serverless SQL
Warehouse serverless	Redshift Serverless	BigQuery	Synapse (dedicated/serverless)
Streaming compute	Managed Flink / KDA	Dataflow	Stream Analytics
Lakehouse đa cloud	Databricks	Databricks	Databricks / Fabric

---

Cây quyết định chọn compute

Cây này là điểm khởi đầu, không phải luật cứng — thực tế còn ràng buộc về bảo mật, kỹ năng đội ngũ, và stack sẵn có. Nhưng bốn câu hỏi (dạng tải → mật độ → độ trễ → khả năng chịu gián đoạn) bao trùm phần lớn quyết định.

---

Use case thực tế

Bối cảnh: Nền tảng dữ liệu của NCB trên AWS, dữ liệu thô đổ vào data lake trên S3. Ba nhóm workload rất khác nhau, và sai lầm ban đầu là ép cả ba lên một cụm EMR chạy 24/7 — hoá đơn compute phình to vì cụm nhàn rỗi phần lớn thời gian.

Sau khi tách theo hình dạng workload:

(1) ETL đêm — hồ sơ khách hàng & sao kê. Job Spark tổng hợp ~2 TB giao dịch mỗi đêm, chạy 1 lần/ngày lúc 1h sáng.

• Chọn EMR ephemeral: cụm khởi lúc 1:00, chạy ~80 phút, terminate lúc 2:20.
• Worker chạy spot (chịu thu hồi nhờ checkpoint + retry), driver on-demand.
• Kết quả: so với cụm 24/7 on-demand, tổng chi phí compute cho nhóm này giảm khoảng 70–80% (chỉ trả cho ~1.3 giờ/ngày thay vì 24 giờ, và phần worker rẻ thêm nhờ spot). Con số minh hoạ theo bậc độ lớn, không phải hoá đơn thực tế.

(2) Truy vấn ad-hoc — phân tích rủi ro & báo cáo. Analyst chạy vài chục query/ngày, giờ giấc bất định, khối lượng khó đoán.

• Chọn Athena trên S3 với dữ liệu Parquet + partition theo ngày.
• Rảnh không tốn tiền; mỗi query chỉ quét cột và partition cần → giảm mạnh TB quét so với để dạng CSV.
• Không phải nuôi một warehouse luôn bật cho tải thưa này.

(3) API real-time — chấm điểm giao dịch chống gian lận. Yêu cầu độ trễ p99 dưới 100ms, luôn sẵn sàng.

• Chọn container trên EKS: pod luôn ấm, HPA co giãn theo QPS, không dính cold start.
• Không dùng Lambda ở đây vì cold start + JVM có thể phá SLA độ trễ.

Kết quả tổng thể: mỗi workload nằm đúng loại compute, hoá đơn compute giảm đáng kể trong khi SLA của API real-time vẫn đảm bảo. Bài học: đừng ép mọi thứ lên một loại compute — cloud cho bạn phổ lựa chọn chính là để ghép đúng công cụ với đúng việc.

---

Ghi nhớ

• Compute là biến chi phí lớn nhất và khó quản nhất; ghép đúng workload với đúng loại compute là kỹ năng cốt lõi.
• Sáu họ: VM/IaaS, container+K8s, serverless functions, managed Spark, serverless query, managed streaming — chúng bổ trợ, không thay thế nhau.
• Batch nặng → managed Spark cụm ephemeral, worker spot; ad-hoc SQL → serverless query; streaming → managed streaming; glue → functions; API độ trễ thấp → container trên K8s.
• Tách compute khỏi storage: scale độc lập, tắt compute khi rảnh, nhiều engine trên một dữ liệu.
• Serverless vs cluster: tải thưa/bất định → serverless (rảnh không tốn tiền); tải dày/liên tục → cluster reserved (đơn giá rẻ hơn).
• Spot/preemptible cắt 70–90% chi phí cho phần idempotent, có checkpoint; không dùng cho thành phần luôn phải sống hoặc có state không phục hồi.
• Scale-to-zero đổi lại cold start: chấp nhận với batch/glue; với API độ trễ thấp thì giữ instance ấm hoặc dùng container thường trú.
• Storage layout (Parquet, partition) ảnh hưởng trực tiếp tới chi phí compute của serverless query theo-byte-quét.