Databricks 8 — Vận hành, chi phí & use case ngân hàng

Từ "chạy được" đến "vận hành được"

Bảy bài trước dựng nền kỹ thuật: Delta Lake, Spark/Photon, Workflows/DLT, Unity Catalog, Databricks SQL, MLflow. Nhưng một ngân hàng không sống bằng notebook chạy tay. Câu hỏi thật sự của khối vận hành là: làm sao triển khai job giống hệt nhau qua ba môi trường, làm sao không bị hoá đơn cloud gấp ba dự toán, làm sao chứng minh với kiểm toán rằng số dư khách hàng không rời khỏi Việt Nam. Bài cuối này ghép các mảnh đó thành một bức tranh vận hành hoàn chỉnh, rồi tổng kết cả series.

Điểm mấu chốt: control plane (Databricks quản UI, scheduler, metadata) tách khỏi data plane (compute và dữ liệu trong VPC của ngân hàng, mô hình classic). Đây là nền của cả câu chuyện tuân thủ lẫn chi phí.

Vận hành & DevOps

Ba môi trường, một khuôn

Chuẩn thực chiến là tách dev → staging → prod, thường là ba workspace riêng (hoặc ít nhất ba catalog trong Unity Catalog). Nguyên tắc bất di bất dịch: không ai sửa job production bằng tay trên UI. Mọi thay đổi đi qua Git và được triển khai lại từ mã.

Infrastructure as Code

Đừng "bấm nút" tạo job. Định nghĩa job/pipeline/cấu hình bằng mã để triển khai lặp lại được, review được, rollback được. Hai công cụ chính:

• Databricks Asset Bundles (DAB) — cách "chính chủ" đóng gói một dự án Databricks (job, DLT pipeline, notebook, cấu hình) vào một file YAML, rồi databricks bundle deploy theo từng target dev/staging/prod.
• Terraform (provider databricks) — khi ngân hàng đã chuẩn hoá hạ tầng bằng Terraform, dùng để tạo workspace, cluster policy, quyền UC, secret scope cùng phần còn lại của cloud.

# Minh hoạ Databricks Asset Bundle (databricks.yml) — KHÔNG phải cấu hình chạy nguyên trạng
bundle:
  name: risk-daily
targets:
  dev:
    mode: development
    workspace: { host: https://adb-dev.azuredatabricks.net }
  prod:
    mode: production
    workspace: { host: https://adb-prod.azuredatabricks.net }
resources:
  jobs:
    risk_gold_daily:
      tasks:
        - task_key: build_gold
          notebook_task: { notebook_path: ./src/build_gold.py }
          job_cluster_key: policy_small
      job_clusters:
        - job_cluster_key: policy_small
          new_cluster:
            policy_id: ${var.small_policy}   # bat buoc theo cluster policy
            autoscale: { min_workers: 2, max_workers: 8 }
      email_notifications:
        on_failure: [ [email protected] ]

CI/CD

Databricks Repos đồng bộ trực tiếp với Git (GitHub/GitLab/Azure DevOps). Luồng chuẩn: branch → PR → chạy test tự động (unit test cho hàm transform, kiểm thử schema) trên staging → merge → pipeline CI gọi bundle deploy lên prod. Notebook và code Python/SQL đều được version-control, xoá bỏ tình trạng "notebook thần thánh chỉ một người hiểu".

Cluster policy — cổng kiểm soát

Cluster policy giới hạn loại/kích cỡ máy, buộc tag, bật auto-termination, cấm loại instance đắt. Đây là công cụ đa nhiệm: vừa kiểm soát chi phí (không ai lỡ tạo cluster 100 node), vừa tuân thủ (buộc mọi cluster gắn Unity Catalog, không cho tắt mã hoá). Trong ngân hàng, prod thường chỉ cho tạo cluster qua vài policy được duyệt sẵn.

Chi phí: đọc kỹ hoá đơn

Chi phí Databricks gồm hai lớp cộng lại: DBU (Databricks Unit — đơn vị năng lực tính toán Databricks tính tiền, khác nhau theo loại workload và tier) cộng phí hạ tầng cloud bên dưới (VM, storage, mạng) trả cho AWS/Azure/GCP. Hiểu sai điểm này là nguồn của mọi bất ngờ hoá đơn. Nền tảng chung về tối ưu chi phí xem FinOps — thực hành ngân hàng.

Các đòn bẩy chính, xếp theo tác động thường thấy:

Giám sát bằng system tables (schema system.billing cho usage) và dashboard billing của cloud. Nguyên tắc: tag trước, đo sau, tối ưu cái đắt nhất. Đừng tối ưu một job chạy 5 phút/ngày khi có một all-purpose cluster ai đó quên tắt cả tuần.

Bảo mật & tuân thủ ngân hàng

Đây là phần khối tuân thủ NCB quan tâm nhất, và cũng là lý do mô hình control/data plane tách rời của Databricks có giá trị.

Mạng & vị trí dữ liệu. Với mô hình classic, data plane nằm trong VPC của ngân hàng: compute và dữ liệu Delta không rời khỏi tài khoản cloud của bạn, control plane chỉ giữ metadata. Cấu hình chuẩn cho ngân hàng:

• Private Link / no public IP — cluster không có địa chỉ IP công khai; lưu lượng đến control plane đi qua đường riêng, không qua internet công cộng.
• Customer-managed keys (CMK) — dùng khoá mã hoá do ngân hàng quản trong KMS/Key Vault để mã hoá storage và (tuỳ nền) cả managed disk. Databricks không giữ khoá.
• Data residency / region — chọn vùng cloud (ví dụ Singapore, hoặc region trong nước khi có) sao cho dữ liệu định danh khách hàng không rời phạm vi cho phép. Cân nhắc kỹ khi bật serverless vì compute do Databricks quản.

Governance. Unity Catalog (Databricks 5) là trục quản trị: quyền theo vai trò/hàng/cột, audit log mọi truy cập, lineage từ bảng nguồn tới dashboard/mô hình. Đây là bằng chứng trực tiếp cho kiểm toán khi trả lời "ai đã đọc bảng PII này, dữ liệu báo cáo rủi ro đến từ đâu". Nguyên tắc access control tổng quát xem gov-06 — Access control.

Secret. Không hard-code mật khẩu/token trong notebook. Dùng secret scope (backed bởi Databricks hoặc Azure Key Vault) và tham chiếu bằng dbutils.secrets.get(...).

Tuân thủ VN. Kiến trúc data-plane-trong-VPC + CMK + audit UC hỗ trợ trực tiếp yêu cầu Nghị định 13/2023 (NĐ13) về bảo vệ dữ liệu cá nhân và các quy định của NHNN về an toàn hệ thống thông tin. Chi tiết khung pháp lý xem gov-07 — Quyền riêng tư & tuân thủ.

Độ tin cậy

Vận hành production đòi hỏi cơ chế chịu lỗi rõ ràng:

• Job retry — cấu hình số lần thử lại và khoảng chờ cho mỗi task; task idempotent (như MERGE vào Delta) an toàn khi retry.
• Alert — thông báo email/webhook khi job fail hoặc chạy quá lâu (như ví dụ on_failure ở trên).
• DR / backup — sao lưu định kỳ, cân nhắc Delta deep clone sang region khác cho các bảng trọng yếu.
• Delta time travel — khôi phục nhanh khi pipeline ghi sai: RESTORE/đọc lại version cũ mà không cần backup ngoài (xem Databricks 2 — Delta Lake).

Migration lên lakehouse (khái quát)

Ngân hàng hiếm khi bắt đầu từ con số 0 — thường có warehouse Oracle/Teradata hoặc cụm Hadoop cũ. Cách tiếp cận an toàn:

1. Đánh giá & ưu tiên — chọn vài luồng đau nhất (ví dụ báo cáo rủi ro chạy chậm) làm pilot, không "big bang".
2. Ingest song song — đổ dữ liệu vào bronze Delta song song với hệ cũ, đối soát kết quả trước khi cắt.
3. Dựng lại logic — chuyển transform sang Spark/DLT, tổ chức theo medallion; giữ hệ cũ chạy đối chứng.
4. Cutover từng phần — chuyển từng consumer (dashboard, downstream) sang gold mới khi đã đối soát khớp, rồi mới tắt hệ cũ.

Rủi ro lớn nhất không phải kỹ thuật mà là đối soát số: đảm bảo báo cáo mới ra đúng con số như báo cáo cũ trước khi ai đó ký duyệt dựa trên nó.

Databricks vs Snowflake vs Spark tự quản

Nói gọn: Databricks khi bạn muốn xoá các bản sao dữ liệu rời rạc giữa engineering và ML; Snowflake khi trọng tâm là kho phân tích SQL vận hành đơn giản; Spark tự quản khi bạn có đủ người và muốn kiểm soát mọi thứ. Đối chiếu thêm kiến trúc lakehouse chung ở data-engineering-07 — Lakehouse.

Tổng kết series: bản đồ 8 bài

• Databricks 1 — Tổng quan & Lakehouse: kiến trúc control/data plane, medallion, định vị nền tảng.
• Databricks 2 — Delta Lake: transaction log, ACID, time travel, MERGE, OPTIMIZE.
• Databricks 3 — Spark & Compute: cluster, Photon, tuning, job vs all-purpose.
• Databricks 4 — Workflows & DLT: orchestration job, Delta Live Tables khai báo, expectations.
• Databricks 5 — Unity Catalog: governance thống nhất, quyền, lineage, audit.
• Databricks 6 — SQL & BI: SQL Warehouse, dashboard, phục vụ analyst.
• Databricks 7 — ML & MLflow: feature, train, registry, serving trên cùng nền.
• Databricks 8 (bài này) — vận hành, chi phí, bảo mật, migration, chọn nền.

Sợi chỉ xuyên suốt: một bản sao dữ liệu, một lớp governance, phục vụ đồng thời engineering, phân tích và ML.

Use case thực tế

Bối cảnh: Khối Dữ liệu NCB đưa nền tảng Databricks (đã pilot ở bài 1) lên vận hành chính thức cho ba khối: tuân thủ (báo cáo rủi ro), vận hành thẻ (mô hình gian lận), và analyst (BI). Yêu cầu: triển khai lặp lại được, hoá đơn dự đoán được, qua được đánh giá bảo mật theo NĐ13.

Triển khai (minh hoạ):

1. Ba workspace dev/staging/prod, mỗi cái một catalog UC riêng; prod chỉ 3 người có quyền ghi trực tiếp.
2. IaC: toàn bộ job risk và fraud đóng gói trong Databricks Asset Bundle; Terraform tạo cluster policy, secret scope, quyền UC. Deploy prod chỉ qua pipeline CI, không sửa tay.
3. Chi phí: đổi 12 job từ all-purpose sang job cluster + auto-termination 15 phút + spot cho batch bronze; bật Photon cho job gold nặng. Gắn tag cost-center cho từng khối, đọc system.billing hàng tuần. Chi phí compute giảm khoảng 40% so với tháng pilot (minh hoạ), trong khi job gold chạy nhanh hơn nhờ Photon.
4. Bảo mật: data plane trong VPC ngân hàng vùng Singapore, no public IP + Private Link, CMK cho storage. UC audit + lineage nộp cho kiểm toán chứng minh bảng PII chỉ được các vai trò được duyệt truy cập.
5. Độ tin cậy: job gold có retry 2 lần + alert on_failure về đội on-call; bảng silver trọng yếu deep clone sang region backup hàng đêm.

Kết quả (minh hoạ): release lên prod từ 1-2 ngày thủ công xuống dưới 30 phút qua CI; hoá đơn tháng ổn định trong ±10% dự toán; hồ sơ bảo mật qua vòng đánh giá nội bộ ngay lần đầu.

Ghi nhớ

• Vận hành production = ba môi trường dev/staging/prod + IaC (Databricks Asset Bundles hoặc Terraform) + CI/CD qua Git; không sửa job prod bằng tay.
• Cluster policy là cổng kép: kiểm soát chi phí (giới hạn loại/kích cỡ) và tuân thủ (buộc tag, buộc UC, cấm tắt mã hoá).
• Chi phí = DBU + hạ tầng cloud; đòn bẩy: job cluster thay all-purpose, auto-termination, autoscale, spot, serverless, Photon, tag để chargeback, giám sát system.billing.
• Bảo mật ngân hàng: data plane trong VPC (classic), Private Link + no public IP, customer-managed keys, Unity Catalog cho quyền/audit/lineage, secret scope — hỗ trợ trực tiếp NĐ13/NHNN.
• Độ tin cậy: job retry idempotent, alert, DR/deep clone sang region, Delta time travel để khôi phục nhanh.
• Migration lên lakehouse đi từng phần, chạy song song, đối soát số — rủi ro lớn nhất là con số báo cáo, không phải kỹ thuật.
• Chọn nền: Databricks khi DE/ML hoà làm một; Snowflake khi ưu tiên BI SQL đơn giản; Spark tự quản khi cần chủ quyền hạ tầng tuyệt đối.
• Series 8 bài: từ lakehouse & Delta → compute → orchestration → governance → BI → ML → vận hành, tất cả quanh một bản sao dữ liệu, một lớp governance.