Databricks 7 — ML, MLflow & Feature Store

Vì sao ML trên lakehouse

Trong hầu hết ngân hàng, quy trình xây mô hình bị đứt gãy: dữ liệu nằm ở data warehouse, data scientist copy sang máy riêng bằng CSV, train ở laptop, rồi engineer phải viết lại pipeline để đưa mô hình lên production. Mỗi lần "ném qua tường" là một lần rò lệch: feature tính lúc train khác feature tính lúc serve (train-serve skew), không ai biết mô hình nào đang chạy, dữ liệu train không audit được.

Databricks giải bài này bằng lakehouse hợp nhất: dữ liệu thô, feature, mô hình và điểm serving đều nằm trên cùng một nền tảng, cùng một lớp quản trị (Databricks 5 — Unity Catalog). Bạn làm feature, train, đăng ký, serve mô hình mà không phải di chuyển dữ liệu ra ngoài. Feature được đọc trực tiếp từ bảng Delta (Databricks 2 — Delta Lake); compute là cluster Spark (Databricks 3 — Spark & Compute); lineage từ bảng nguồn tới mô hình được UC ghi tự động.

Toàn bộ vòng đời — feature → train → registry → serve → monitor → retrain — nằm gọn trong một nền có governance. Đây là điểm mấu chốt với mô hình rủi ro trong ngân hàng, nơi mọi quyết định phải giải trình được với kiểm toán và NHNN.

MLflow: xương sống theo dõi mô hình

Databricks là nơi khai sinh MLflow (open-source năm 2018) và tích hợp nó sâu vào nền tảng. Bạn có thể coi MLflow như hệ điều hành của vòng đời ML. Nếu đã đọc loạt MLOps, hãy xem MLOps — Model Registry & Serving để đối chiếu khái niệm; ở đây tập trung vào cách Databricks hiện thực hóa.

Tracking: ghi lại mọi lần chạy

MLflow Tracking ghi lại mỗi run (một lần thực nghiệm): tham số (params), chỉ số (metrics), artifact (biểu đồ, file), và bản thân mô hình. Mỗi run thuộc một experiment. Nhờ đó bạn có sổ cái đầy đủ: mô hình v12 dùng learning_rate nào, AUC bao nhiêu, ai chạy, lúc nào.

# Minh hoạ — KHÔNG đảm bảo chạy được nguyên trạng
import mlflow
from sklearn.ensemble import GradientBoostingClassifier

mlflow.set_experiment("/Users/risk/fraud_scoring")

with mlflow.start_run(run_name="gbt_v3") as run:
    mlflow.log_param("n_estimators", 300)
    mlflow.log_param("max_depth", 5)

    model = GradientBoostingClassifier(n_estimators=300, max_depth=5)
    model.fit(X_train, y_train)

    auc = roc_auc_score(y_val, model.predict_proba(X_val)[:, 1])
    mlflow.log_metric("val_auc", auc)
    mlflow.log_metric("val_recall", recall)

    mlflow.sklearn.log_model(model, artifact_path="model")

Autolog: khỏi log tay

mlflow.autolog() tự động bắt params, metrics và mô hình cho hầu hết framework phổ biến (scikit-learn, XGBoost, LightGBM, PyTorch, Spark MLlib, TensorFlow). Chỉ cần một dòng trước khi fit, MLflow tự chèn hook.

# Minh hoạ
import mlflow
mlflow.autolog()   # bắt tự động cho fit() phía dưới
model.fit(X_train, y_train)   # params/metrics/model được log ngầm

Với đội ngân hàng, autolog giảm rủi ro "quên log" — mọi lần train đều để lại dấu vết, phục vụ audit. Bạn vẫn có thể log_param/log_metric thủ công để bổ sung chỉ số nghiệp vụ mà framework không tự bắt (ví dụ chi phí kỳ vọng của false negative theo bảng tổn thất). Kết hợp autolog cho phần khung xương và log tay cho phần nghiệp vụ là thực hành cân bằng nhất.

MLflow Tracking còn hỗ trợ so sánh run trực quan: chọn nhiều run trong UI, xem bảng so params/metrics cạnh nhau và biểu đồ song song (parallel coordinates) để nhìn ra siêu tham số nào đẩy AUC lên. Với dự án rủi ro kéo dài nhiều tháng, đây là cách nhanh nhất để trả lời "vì sao chọn version này chứ không phải version kia".

Model Registry — nay là "models" trong Unity Catalog

Trước đây Model Registry là dịch vụ riêng với stage (None → Staging → Production → Archived). Databricks đang chuyển sang mô hình đăng ký trong Unity Catalog: mô hình trở thành một đối tượng UC theo namespace 3 cấp catalog.schema.model, hưởng chung governance với bảng dữ liệu (Governance — Catalog & Lineage).

Điểm khác biệt cần nắm:

Alias linh hoạt hơn stage cứng: bạn gán @champion cho version đang phục vụ, @challenger cho ứng viên, và đổi con trỏ mà không phải đổi tên. Serving tham chiếu qua alias nên promote/rollback chỉ là trỏ lại alias.

# Minh hoạ — đăng ký & gán alias trong UC
import mlflow
mlflow.set_registry_uri("databricks-uc")

mv = mlflow.register_model(
    model_uri=f"runs:/{run.info.run_id}/model",
    name="risk.fraud.txn_scorer",
)

from mlflow import MlflowClient
client = MlflowClient()
client.set_registered_model_alias(
    name="risk.fraud.txn_scorer", alias="champion", version=mv.version
)

Packaging: MLflow Projects & Models

• MLflow Models: định dạng đóng gói chuẩn (có MLmodel, conda/requirements), đa "flavor" (python_function, sklearn, spark...) để một mô hình chạy được ở nhiều môi trường serving mà không viết lại.
• MLflow Projects: đóng gói code + môi trường (git repo có MLproject) để tái lập lần chạy — hữu ích khi cần chứng minh với kiểm toán rằng mô hình được train lại y hệt.

Feature Engineering trong Unity Catalog

Databricks Feature Store (nay là Feature Engineering trong UC) giải quyết bài toán tái dùng và nhất quán feature. Xem thêm MLOps — Feature Store cho nền lý thuyết.

Ý tưởng: feature table là một bảng Delta trong UC có khóa chính (primary key). Bạn định nghĩa logic tính feature một lần, ghi ra bảng, rồi mọi mô hình đọc lại — thay vì mỗi team tự tính "số giao dịch 30 ngày qua" theo một kiểu.

# Minh hoạ — tạo feature table
from databricks.feature_engineering import FeatureEngineeringClient
fe = FeatureEngineeringClient()

fe.create_table(
    name="risk.features.customer_txn_30d",
    primary_keys=["customer_id"],
    timestamp_keys=["as_of_ts"],
    df=features_df,            # DataFrame đã tính sẵn
    description="Feature giao dịch 30 ngày gần nhất",
)

Hai chế độ phục vụ:

• Offline store: chính là bảng Delta — dùng khi training (join khối lượng lớn, batch).
• Online store: sao chép feature sang kho low-latency (vd DynamoDB, Cosmos DB, hoặc online table của Databricks) để serving real-time đọc trong vài mili-giây.

Point-in-time lookup — chống rò rỉ dữ liệu (data leakage)

Đây là tính năng quan trọng nhất với mô hình rủi ro. Khi build tập train, nếu bạn join feature bằng giá trị hiện tại, mô hình vô tình "nhìn thấy tương lai" — ví dụ tính "tổng nợ" tại thời điểm hôm nay để dự đoán vỡ nợ của khoản vay 6 tháng trước. Đó là data leakage, làm AUC đẹp giả tạo lúc offline nhưng sập lúc production.

Feature Store hỗ trợ point-in-time lookup: với mỗi dòng nhãn ở thời điểm t, nó chỉ join giá trị feature có hiệu lực tại hoặc trước t. Bạn khai báo qua FeatureLookup + timestamp_lookup_key, và framework tự đảm bảo tính đúng thời điểm.

# Minh hoạ — training set point-in-time
from databricks.feature_engineering import FeatureLookup

lookups = [
    FeatureLookup(
        table_name="risk.features.customer_txn_30d",
        lookup_key="customer_id",
        timestamp_lookup_key="event_ts",   # join theo thời điểm sự kiện
    )
]

training_set = fe.create_training_set(
    df=labels_df,               # có customer_id, event_ts, label
    feature_lookups=lookups,
    label="is_fraud",
)
train_df = training_set.load_df()

Lợi ích kép: (1) tái dùng — một feature table phục vụ nhiều mô hình; (2) nhất quán train-serve — cùng một định nghĩa feature dùng cho cả offline training và online serving, triệt tiêu skew. Khi bạn log_model với training_set, MLflow gắn thông tin feature lookup vào mô hình, để lúc serving nó tự tra online store — engineer không phải viết lại logic feature ở tầng API.

Một tính năng đáng chú ý là on-demand feature: feature tính ngay tại thời điểm request từ dữ liệu đến trong payload (ví dụ độ dài giao dịch, chênh lệch múi giờ) qua hàm Python đã đăng ký, kết hợp với feature tra từ online store. Nhờ đó những đại lượng chỉ biết được lúc chấm điểm vẫn được xử lý nhất quán giữa train và serve. Về governance, vì feature table là đối tượng UC, bạn cấp quyền đọc feature như cấp quyền đọc bảng, và lineage cho thấy mô hình nào đang phụ thuộc feature nào — trước khi sửa một feature, bạn biết ngay nó ảnh hưởng những mô hình downstream nào.

Model Serving

Từ mô hình đã đăng ký, Databricks Model Serving dựng endpoint REST serverless real-time: gửi request JSON, nhận điểm số trong vài chục mili-giây, hạ tầng tự co giãn (kể cả scale-to-zero khi rảnh). Bên cạnh đó:

• Batch / streaming inference: chấm điểm cả bảng bằng fe.score_batch hoặc mlflow.pyfunc.spark_udf — hợp cho chấm điểm rủi ro hàng đêm.
• A/B & shadow: một endpoint có thể phân traffic giữa nhiều version (canary), hoặc chạy shadow — model mới nhận bản sao traffic để so sánh mà không ảnh hưởng kết quả thật (Kiểm định A/B).
• Giám sát: endpoint tự log request/response ra bảng inference (Delta) để theo dõi chất lượng và drift sau này.

Cùng hạ tầng đó, Mosaic AI Model Serving phục vụ cả LLM (mô hình nền tảng, mô hình bạn tự fine-tune, hoặc gọi mô hình bên ngoài qua external model) — nên team có thể vừa serve mô hình gian lận cổ điển, vừa serve trợ lý LLM nội bộ trên một nền.

AutoML: dựng baseline nhanh

Databricks AutoML tự thử nhiều thuật toán và siêu tham số trên tập của bạn, trả về mô hình baseline cùng notebook sinh sẵn (glass-box) — không phải hộp đen. Bạn thấy đúng code đã train mô hình tốt nhất, sửa lại theo nghiệp vụ rồi đưa vào pipeline. Với ngân hàng, AutoML hữu ích để có mốc so sánh nhanh (điểm sàn) trước khi đầu tư feature engineering thủ công, chứ không nên coi là mô hình cuối cho quyết định tín dụng.

Notebook cộng tác & Git

Data scientist làm việc trong notebook (Python/SQL/Scala/R lẫn lộn) có real-time collaboration, và Databricks Repos đồng bộ với Git (GitHub/GitLab/Azure DevOps). Nhờ đó code mô hình được version, review qua pull request, và đưa vào CI/CD như code thường — không còn notebook "mồ côi" trên máy cá nhân.

MLOps trên Databricks

Ghép các mảnh trên lại thành quy trình vận hành:

• CI/CD: dùng Databricks Asset Bundles hoặc Terraform để triển khai job train, endpoint serving theo môi trường dev → staging → prod.
• Webhook / event: khi có version mới đăng ký, kích hoạt pipeline test tự động (kiểm tra chất lượng trước khi cho promote).
• Promote qua alias/stage: sau khi test đạt, gán alias @champion cho version mới; serving tự trỏ theo alias.
• Giám sát drift: Lakehouse Monitoring theo dõi phân phối feature và điểm số theo thời gian; khi lệch quá ngưỡng, cảnh báo và kích hoạt retrain (MLOps — Monitoring & Drift).

Toàn bộ được quản trị qua Unity Catalog: quyền trên mô hình theo GRANT/REVOKE, và lineage cho bạn truy vết một mô hình về đúng những bảng và feature đã sinh ra nó — cực kỳ giá trị khi kiểm toán hỏi "điểm rủi ro này dựa trên dữ liệu nào".

Use case thực tế

Bài toán: NCB cần mô hình chấm điểm gian lận giao dịch thẻ real-time, quyết định trong < 100ms mỗi giao dịch, và mô hình phải giải trình được với kiểm toán.

Cách làm trên Databricks:

1. Feature. Định nghĩa 3 feature table trong UC từ bảng Delta giao dịch: tần suất 24h, độ lệch số tiền so với trung bình 30 ngày, khoảng cách địa lý so với giao dịch trước. Ghi offline (Delta) + đẩy online store.
2. Train. Dùng point-in-time lookup dựng tập train 18 tháng (≈ 40 triệu giao dịch, tỷ lệ gian lận ~0,3%). Train GBT, autolog toàn bộ. Kết quả: PR-AUC 0,71, recall 0,68 tại ngưỡng chặn 2% giao dịch.
3. Đăng ký & test. register_model vào risk.fraud.txn_scorer; webhook chạy suite kiểm tra (fairness theo phân khúc, độ trễ). Đạt → gán alias @champion.
4. Serve. Endpoint serverless tự tra online store để lấy feature, chấm điểm trong ~45ms p95. Bật shadow cho challenger v-mới suốt 2 tuần.
5. Giám sát. Lakehouse Monitoring so phân phối điểm số tuần này với baseline; PSI feature "tần suất 24h" vượt 0,25 → cảnh báo, kích hoạt retrain.

Kết quả: một nền tảng duy nhất, lineage từ giao dịch thô tới điểm số, không copy dữ liệu ra ngoài — vừa đáp ứng tốc độ vừa thỏa yêu cầu giải trình của khối tuân thủ.

Ghi nhớ

• Lakehouse hợp nhất: feature → train → registry → serve → monitor trên cùng nền, không di chuyển dữ liệu, chung governance của Unity Catalog.
• MLflow (khai sinh tại Databricks): Tracking log params/metrics/artifacts/model; autolog() bắt tự động; Projects/Models đóng gói tái lập.
• Model Registry nay là "models" trong UC: namespace 3 cấp, dùng alias (@champion/@challenger) thay stage cứng, hưởng GRANT/REVOKE và lineage.
• Feature Store trong UC: feature table trên Delta; offline cho train, online store cho serving real-time; point-in-time lookup chống data leakage và diệt train-serve skew.
• Model Serving: endpoint serverless real-time (scale-to-zero), batch/streaming inference, A/B & shadow; Mosaic AI serve cả LLM.
• AutoML cho baseline nhanh + notebook glass-box; notebook cộng tác + Git qua Repos.
• MLOps: CI/CD, webhook, promote qua alias, giám sát drift với Lakehouse Monitoring; UC lo quyền + lineage cho audit.
• Không có block SQL nào đánh dấu "chạy được" — mọi ví dụ là PySpark/MLflow minh hoạ.