Cloud DE 5 — Bản đồ dịch vụ dữ liệu managed

Vì sao đi theo "dịch vụ managed" thay vì tự dựng

Ở các bài trước ta đã xem lớp lưu trữ và lớp tính toán như những viên gạch nền. Bài này lắp các viên gạch đó thành một pipeline dữ liệu hoàn chỉnh, nhưng dùng dịch vụ managed (nhà cung cấp lo vận hành) thay vì tự cài phần mềm lên máy ảo.

Một dịch vụ managed nghĩa là bạn không phải: cài đặt, vá lỗi, nâng cấp, sao lưu, scale thủ công hay canh 3 giờ sáng khi node chết. Nhà cung cấp lo hạ tầng bên dưới; bạn chỉ trả tiền theo lượng dùng và tập trung vào logic dữ liệu. Mức "managed" có nhiều bậc:

• Managed thuần: bạn vẫn thấy "cụm", vẫn chọn số node/kích thước (ví dụ Amazon MSK, EMR). Đỡ cài đặt nhưng còn phải tune.
• Serverless: không thấy máy nào cả, tự co giãn từ 0, trả theo query/theo byte quét (BigQuery, Kinesis, Glue, Cloud Run). Đây là bậc "giảm vận hành" cao nhất — serverless-first là kim chỉ nam khi đội nhỏ.

Với một ngân hàng như NCB, đội data thường 10–30 người, không thể có riêng team lo Kafka, team lo Spark cluster, team lo Airflow. Chọn managed/serverless cho phép một nền tảng dữ liệu vận hành bởi vài người. Đổi lại là ba khoản đánh đổi phải cân: mất bớt quyền kiểm soát chi tiết, chi phí có thể cao khi quy mô lớn, và lock-in (dính chặt vào một nhà cung cấp).

Pipeline dữ liệu và 9 lớp kiến trúc

Dù cloud nào, một nền tảng dữ liệu đều đi qua các lớp giống nhau. Ta bám theo dòng chảy dữ liệu:

Xử lý từng lớp theo thứ tự, mỗi lớp kèm dịch vụ managed tương ứng trên ba cloud lớn.

Lớp 1 — Ingestion / EL (đưa dữ liệu vào)

Nhiệm vụ: kéo dữ liệu từ nguồn (database core banking, ứng dụng, SaaS, file) vào data lake/warehouse. "EL" = Extract-Load; phần Transform để dành lớp 5.

• AWS: DMS (Database Migration Service) cho CDC (Change Data Capture — bắt thay đổi từ DB nguồn theo thời gian thực); Glue có sẵn connector cho EL dạng batch.
• Azure: Azure Data Factory (ADF) — dịch vụ tích hợp dữ liệu chủ lực, hàng trăm connector, chạy pipeline copy có lịch.
• GCP: Datastream (CDC serverless từ Oracle/MySQL/Postgres), Cloud Data Fusion (ETL trực quan dựa trên CDAP).

Managed Kafka (nếu nguồn phát sự kiện qua Kafka): Amazon MSK (Managed Streaming for Kafka), Azure Event Hubs (có Kafka-compatible endpoint), hoặc Confluent Cloud (chạy đa cloud). MSK lo broker/ZooKeeper/vá lỗi; bạn vẫn chọn số broker.

Với ngân hàng, mẫu phổ biến là CDC từ core banking (Oracle/Db2) đổ vào lake gần thời gian thực, thay vì export batch cuối ngày — giảm độ trễ báo cáo từ T+1 xuống vài phút.

Lớp 2 — Streaming (dữ liệu chảy liên tục)

Nhiệm vụ: nhận và xử lý luồng sự kiện (giao dịch thẻ, click app, log) theo thời gian thực.

• Bus giữ sự kiện, cho nhiều consumer đọc lại theo thứ tự.
• Xử lý làm cửa sổ trượt (windowing), gộp, làm giàu, phát hiện bất thường. Dataflow (GCP) và Managed Flink (AWS) là serverless auto-scale; Stream Analytics (Azure) dùng cú pháp SQL cho luồng.

Ca dùng ngân hàng điển hình: phát hiện gian lận thẻ real-time — mỗi giao dịch swipe qua Kinesis/Pub/Sub, engine tính đặc trưng trong cửa sổ 60 giây rồi chấm điểm rủi ro trước khi cho phép. Xem thêm nền tảng phân tích luồng ở Elasticsearch overview cho lớp tìm kiếm/quan sát.

Lớp 3 — Data Lake (nơi lưu thô, rẻ, vô hạn)

Nền tảng vẫn là object storage đã bàn ở Cloud DE 2: S3 / ADLS Gen2 / GCS. Điểm mới của lớp managed là quản trị lake:

• AWS Lake Formation: cấp quyền chi tiết (theo bảng/cột/hàng) trên data lake, dựng lake nhanh, kết hợp Glue Data Catalog.
• Table format: các lake hiện đại dùng Apache Iceberg / Delta Lake / Hudi để có ACID, time-travel, schema evolution trên object storage. Đây là lõi của lakehouse — xem Databricks overview.

Ý tưởng: lake giữ dữ liệu một bản duy nhất, nhiều engine (warehouse, Spark, BI) cùng đọc, không copy trùng lặp.

Lớp 4 — Warehouse (kho phân tích có cấu trúc)

Nơi chạy phân tích SQL trên dữ liệu đã sạch, tối ưu cho báo cáo/BI.

• AWS Redshift: warehouse cột (columnar), có bản serverless.
• Azure Synapse Analytics: warehouse + Spark pool + pipeline trong một workspace.
• GCP BigQuery: serverless thuần, trả theo byte quét, không quản cụm — xem sâu ở BigQuery overview.

Điểm managed đáng giá: BigQuery và Redshift Serverless tự scale, không cần cấp phát cụm trước. Với data mart nghiệp vụ (ví dụ báo cáo nợ xấu, LTV khách hàng), warehouse cho phép analyst viết SQL quen thuộc:

-- ▶ Chạy được
SELECT c.city,
       COUNT(DISTINCT a.customer_id) AS so_khach,
       SUM(a.balance)               AS tong_so_du
FROM accounts a
JOIN customers c ON c.id = a.customer_id
GROUP BY c.city
ORDER BY tong_so_du DESC;

Câu trên chạy được trên sandbox PostgreSQL đọc-chỉ; trên warehouse cloud cú pháp gần như y hệt, chỉ khác cách tính tiền và quy mô dữ liệu.

Lớp 5 — Transform / Xử lý (biến thô thành sạch)

Nhiệm vụ: làm sạch, chuẩn hoá, join, tổng hợp — phần "T" trong ELT.

• Glue (AWS) là Spark serverless — không cần cụm, hợp job ETL vừa.
• EMR / Dataproc / Synapse Spark là cụm Spark managed — mạnh, tune được, hợp workload lớn.
• Databricks đặt lên trên cả ba cloud, thống nhất Spark + lakehouse + ML.
• dbt (data build tool) chuyên transform bằng SQL có kiểm thử/versioning ngay trong warehouse — rất phổ biến cho ELT hiện đại.

Nguyên tắc: dữ liệu nhỏ/vừa → Glue/dbt serverless; workload nặng, cần kiểm soát → cụm Spark managed.

Lớp 6 — Orchestration (điều phối lịch chạy)

Nhiệm vụ: chạy các bước theo thứ tự, đúng lịch, có retry, cảnh báo khi lỗi (DAG — đồ thị có hướng không chu trình).

• AWS MWAA (Managed Workflows for Apache Airflow) — Airflow managed.
• Azure Data Factory — pipeline + trigger + orchestration (kiêm luôn ingestion).
• GCP Cloud Composer — Airflow managed trên GCP.

Airflow managed (MWAA/Composer) giữ được DAG Python quen thuộc mà bỏ gánh nặng vận hành scheduler/worker. Đây là lớp "nhạc trưởng" gọi lần lượt ingestion → transform → load warehouse mỗi đêm.

Lớp 7 — Catalog & Governance (danh mục & quản trị)

Nhiệm vụ: biết có dữ liệu gì, ở đâu, ai được xem, dòng đời (lineage) ra sao — sống còn với ngân hàng phải tuân thủ.

• Glue Data Catalog là metastore trung tâm cho toàn hệ AWS (Athena, Redshift Spectrum, EMR cùng đọc).
• Purview (Azure) và Dataplex (GCP) làm catalog + lineage + phân loại dữ liệu nhạy cảm (PII).
• Unity Catalog (Databricks) thống nhất quản trị trên lakehouse đa cloud.

Với dữ liệu ngân hàng, đây là nơi gắn nhãn cột PII (CMND, số thẻ), áp masking, và ghi vết ai truy cập gì để phục vụ kiểm toán.

Lớp 8 — BI (báo cáo & trực quan)

• AWS QuickSight — BI serverless, tính tiền theo phiên đọc.
• Azure Power BI — mạnh nhất mảng doanh nghiệp Microsoft, tích hợp Office.
• GCP Looker — mô hình hoá ngữ nghĩa bằng LookML, "một nguồn sự thật" cho metric.

Chọn thường theo hệ sinh thái sẵn có: ngân hàng đã dùng Microsoft 365 gần như mặc định Power BI.

Lớp 9 — ML (học máy)

• AWS SageMaker, Azure Machine Learning, GCP Vertex AI — nền tảng ML managed toàn trình: notebook, training có quản lý, feature store, deploy endpoint, monitoring.

Ba dịch vụ này lấy dữ liệu từ lake/warehouse, huấn luyện mô hình (ví dụ credit scoring), rồi triển khai endpoint chấm điểm real-time — khép kín vòng dữ liệu → mô hình → sản phẩm.

Bảng ánh xạ tổng hợp 3 cloud theo lớp

Đa cloud/độc lập nhà cung cấp: Databricks (transform + lakehouse + ML) và dbt (transform SQL) chạy trên cả ba, giảm lock-in.

Nguyên tắc chọn: managed vs tự quản

1. Serverless-first khi đội nhỏ: ưu tiên BigQuery/Glue/Kinesis/Cloud Run — không có cụm để canh, co giãn về 0 khi rảnh, trả theo dùng. Đây là lựa chọn mặc định cho NCB.
2. Tích hợp trong hệ sinh thái: chọn dịch vụ cùng nhà để IAM, mạng, catalog, billing liền mạch. Ghép Redshift + Databricks + Purview cross-cloud sẽ đau về quyền và mạng.
3. Đánh đổi ba trục:
   • Kiểm soát: tự dựng Kafka/Spark cho tune sâu, nhưng tốn người.
   • Chi phí: serverless rẻ khi tải thấp/bùng nổ; ở quy mô rất lớn, chạy 24/7 thì cụm dành riêng (reserved) có khi rẻ hơn — xem BigQuery về slot vs on-demand.
   • Lock-in: dịch vụ độc quyền (Kinesis, BigQuery) dính chặt; dùng chuẩn mở (Kafka, Iceberg, Spark, dbt) dễ di chuyển hơn.
4. Tránh over-engineering: đừng dựng streaming + lakehouse + feature store khi nghiệp vụ chỉ cần báo cáo T+1. Bắt đầu bằng ingestion batch + warehouse + BI; thêm streaming/ML khi có nhu cầu thật.

Use case thực tế

Bối cảnh: NCB dựng nền tảng dữ liệu mới trên AWS, đội vận hành chỉ 4 kỹ sư, mục tiêu báo cáo rủi ro tín dụng gần thời gian thực và giữ chi phí vận hành thấp.

Kiến trúc chọn (serverless-first):

1. Ingestion: DMS CDC từ core banking Oracle → S3, độ trễ ~2–5 phút thay vì export batch cuối ngày (T+1).
2. Streaming: giao dịch thẻ qua Kinesis → Managed Flink tính đặc trưng cửa sổ 60s cho phát hiện gian lận.
3. Lake: S3 + Iceberg, quản quyền cột PII bằng Lake Formation.
4. Transform: Glue (Spark serverless) làm sạch + dbt dựng data mart tín dụng — tránh dựng cụm EMR để không phải tune.
5. Warehouse: Redshift Serverless cho analyst chạy SQL báo cáo.
6. Orchestration: MWAA chạy DAG mỗi đêm gọi Glue → dbt → Redshift.
7. Catalog: Glue Data Catalog + Lake Formation gắn nhãn PII, ghi vết truy cập cho kiểm toán.
8. BI: QuickSight dashboard nợ xấu.

Kết quả ước tính: 4 người vận hành toàn bộ nền tảng (không có cụm để canh); độ trễ báo cáo tín dụng giảm từ T+1 xuống dưới 15 phút; chi phí co theo tải nhờ serverless. Đánh đổi ghi nhận: lock-in vào AWS ở tầng Kinesis/Redshift — được bù bằng việc giữ lake ở chuẩn mở Iceberg và transform bằng dbt/Spark, để sau này còn đường di chuyển.

Ghi nhớ

• Pipeline dữ liệu có 9 lớp cố định: ingestion → streaming → lake → warehouse → transform → orchestration → catalog → BI → ML; mỗi cloud có dịch vụ managed tương ứng.
• Managed = nhà cung cấp lo vận hành; serverless là bậc cao nhất (không cụm, co về 0, trả theo dùng). Serverless-first khi đội nhỏ.
• Bộ ánh xạ nhớ nhanh: Warehouse = Redshift / Synapse / BigQuery; Orchestration = MWAA / Data Factory / Composer; Catalog = Glue Catalog / Purview / Dataplex; ML = SageMaker / Azure ML / Vertex AI.
• Ba trục đánh đổi khi chọn managed: kiểm soát ↔ chi phí ↔ lock-in. Chuẩn mở (Kafka, Iceberg, Spark, dbt) giảm lock-in; Databricks/dbt chạy đa cloud.
• Ưu tiên tích hợp cùng hệ sinh thái (IAM/mạng/catalog liền mạch) và tránh over-engineering: bắt đầu bằng batch + warehouse + BI, thêm streaming/ML khi có nhu cầu thật.
• Ngân hàng: dùng managed để nhỏ đội vận hành, nhưng phải gắn nhãn PII, lineage, masking ở lớp catalog/governance để tuân thủ và kiểm toán.