Feature Store trong MLOps – Hiện Thực Hóa Với Feast

Nhóm: CONQ024
Học viên: Lê Quốc Thịnh
Lớp: AI Việt Nam – AIO 2025
Ngày: 18/10/2025

1. Khởi Nguồn: Vòng Lặp Chuẩn Tắc Của Dự Án Machine Learning

Khi tiếp cận lĩnh vực MLOps (Machine Learning Operations), chúng ta thường bắt đầu với mô hình Vòng Lặp Chuẩn Tắc (Standard Lifecycle). Đây là một quy trình tự động hóa, tuần hoàn, đảm bảo sự liên tục trong việc cải tiến mô hình, bao gồm các tác vụ cốt lõi: Thu thập Dữ liệu (Data Ingestion), Tiền xử lý (Preprocessing), Huấn luyện Mô hình (Training), Triển khai (Deployment), và cuối cùng là Giám sát Hiệu năng (Monitoring).

Về mặt lý thuyết, luồng công việc này dường như rất trơn tru. Tuy nhiên, trên thực tế, độ phức tạp và rủi ro lớn nhất lại nằm ở chi tiết, đặc biệt là tại phần quản lý và di chuyển các đặc trưng dữ liệu (features) giữa các môi trường khác nhau.

2. Vấn Đề Cốt Lõi: Khuynh Hướng Training-Serving Skew

Thách thức kỹ thuật lớn nhất khi chuyển đổi một mô hình từ giai đoạn nghiên cứu sang môi trường sản xuất chính là sự xuất hiện của Khuynh Hướng Training-Serving Skew.

Hiện tượng này xảy ra do sự mâu thuẫn về mặt vận hành giữa hai môi trường:

Vì hai môi trường này có yêu cầu đối lập, logic xử lý đặc trưng (Feature Engineering Logic) thường bị nhân đôi. Các nhà khoa học dữ liệu viết một phiên bản bằng Python/Spark cho môi trường Offline, và đội kỹ sư vận hành phải viết lại một phiên bản khác, thường bằng ngôn ngữ khác (ví dụ: Java, Go) trên hệ thống phục vụ tốc độ cao.

Sự không nhất quán, dù là nhỏ nhất, giữa hai đoạn mã này chính là nguồn gốc của Skew, dẫn đến sự sụt giảm nghiêm trọng về hiệu suất của mô hình khi được đưa vào thực tế so với kết quả thử nghiệm ban đầu. Hơn nữa, việc thiếu một kho chứa tập trung còn khiến các đội nhóm lãng phí tài nguyên khi tái xây dựng các đặc trưng đã có.

3. Giải Pháp Toàn Diện: Feature Store - Nguồn Chân Lý Duy Nhất

Để phá vỡ "bức tường vô hình" giữa nghiên cứu và vận hành, Feature Store được xây dựng như một lớp hạ tầng chuyên biệt. Nó đóng vai trò là nguồn chân lý duy nhất (Single Source of Truth) cho tất cả các đặc trưng trong toàn bộ tổ chức. Mục tiêu chính là đảm bảo cả môi trường huấn luyện và phục vụ đều sử dụng chung một định nghĩa và nguồn dữ liệu đặc trưng.

Các Thành Phần Kiến Trúc Cốt Lõi của Feature Store:

Một Feature Store hiện đại thường bao gồm năm thành phần chính, hoạt động như một giao diện thống nhất giữa dữ liệu thô và mô hình ML:

1. Storage (Lưu Trữ Dữ Liệu):
   - Offline Store: Kho dữ liệu lịch sử khổng lồ (Data Lake/Warehouse) tối ưu cho huấn luyện mô hình theo lô.
   - Online Store: Kho dữ liệu tốc độ cao (NoSQL Key-Value store) chỉ lưu trữ giá trị đặc trưng mới nhất, tối ưu cho dự đoán thời gian thực với độ trễ thấp.

2. Serving (Cơ Chế Phục Vụ):
   - Cung cấp API/SDK để truy cập dữ liệu một cách nhất quán. Chức năng quan trọng nhất là Point-in-Time Correctness (Tính chính xác tại thời điểm) khi truy vấn dữ liệu Offline, ngăn chặn rò rỉ dữ liệu từ tương lai vào bộ dữ liệu huấn luyện.

3. Registry (Sổ Đăng Ký):
   - Là "bộ não" lưu trữ siêu dữ liệu và định nghĩa chính thức của mọi đặc trưng. Nó hoạt động như một danh mục trung tâm để các nhóm cộng tác và tái sử dụng đặc trưng.

4. Transformation (Biến Đổi Dữ Liệu):
   - Quản lý và điều phối các tác vụ tính toán đặc trưng (Batch, Streaming, On-demand Transformations). Việc tái sử dụng mã nguồn biến đổi giữa các môi trường là chìa khóa để giải quyết triệt để vấn đề Training-Serving Skew.

5. Monitoring (Giám Sát):
   - Theo dõi chất lượng dữ liệu (Data Drift) và hiệu suất vận hành (Latency, Throughput, độ mới của dữ liệu) để phát hiện sớm các vấn đề như Training-Serving Skew.

4. Feast: Công Cụ Mã Nguồn Mở Hiện Thực Hóa Feature Store

Feast là một công cụ mã nguồn mở hàng đầu, ra đời để hiện thực hóa kiến trúc Feature Store một cách linh hoạt.

Triết Lý Thiết Kế: Lớp Điều Phối Mỏng
Điểm mạnh lớn nhất của Feast là tính linh hoạt và khả năng tận dụng hạ tầng dữ liệu hiện có của tổ chức (như BigQuery, Snowflake, Redis). Feast hoạt động như một lớp trừu tượng hóa và điều phối mỏng chứ không phải là một nền tảng "tất cả trong một" cồng kềnh.

Các Khái Niệm Cốt Lõi Của Feast
Feast sử dụng một hệ thống phân cấp các đối tượng khai báo bằng Python để định nghĩa Feature Store:

• Entity: Đại diện cho đối tượng kinh doanh (ví dụ: customer_id, transaction_id), đóng vai trò là khóa kết nối (join key) để tra cứu đặc trưng.
• DataSource: Chỉ định nguồn dữ liệu vật lý (file Parquet, bảng BigQuery, topic Kafka) nơi các giá trị đặc trưng được lưu trữ.
• FeatureView: Thành phần trung tâm, định nghĩa một nhóm logic các đặc trưng (Feature) và liên kết chúng với một Entity cùng một DataSource.

Luồng Vận Hành Điển Hình và Thao Tác Cơ Bản
Feast điều phối vòng đời của đặc trưng thông qua các bước chính:
1. Khai báo và Đăng ký: Định nghĩa các đối tượng (Entity, FeatureView) và chạy lệnh CLI feast apply để đăng ký chúng vào Registry.
2. Materialization: Sử dụng lệnh CLI feast materialize để tính toán và nạp dữ liệu đặc trưng từ Offline Store vào Online Store, giúp Online Store luôn có sẵn dữ liệu mới nhất.
3. Huấn Luyện (Offline Serving): Sử dụng hàm SDK store.get_historical_features(...) để truy vấn dữ liệu lịch sử với tính Point-in-Time Correctness, tạo bộ dữ liệu huấn luyện an toàn.
4. Dự Đoán (Online Serving): Sử dụng hàm SDK store.get_online_features(...) để truy vấn vector đặc trưng mới nhất từ Online Store với độ trễ cực thấp.

5. Kết Luận

• Feature Store không chỉ là một công cụ, mà là một tài sản hạ tầng không thể thiếu trong hệ sinh thái MLOps hiện đại. Nó đại diện cho một sự thay đổi tư duy từ việc quản lý các mô hình sang việc quản lý tài sản đặc trưng dữ liệu.
• Với sự hỗ trợ của các công cụ mã nguồn mở mạnh mẽ như Feast, việc chuẩn hóa, tái sử dụng và giải quyết triệt để vấn đề Training-Serving Skew đã trở nên dễ tiếp cận hơn bao giờ hết, mở đường cho các hệ thống Machine Learning bền vững, đáng tin cậy và có khả năng mở rộng.

6. Minh Họa Mã Nguồn Với Feast

Định Nghĩa Đặc Trưng (Feature Definition)

# features.py
from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64, String

# 1. Định nghĩa Entity
customer = Entity(
    name="customer_id",
    description="Định danh khách hàng trong hệ thống"
)

# 2. Nguồn dữ liệu
customer_source = FileSource(
    path="data/customer_features.parquet",
    event_timestamp_column="event_timestamp"
)

# 3. Định nghĩa FeatureView
customer_features = FeatureView(
    name="customer_features",
    entities=["customer_id"],
    ttl=timedelta(days=30),
    schema=[
        Field(name="monthly_charges", dtype=Float32),
        Field(name="tenure", dtype=Int64),
        Field(name="contract_type", dtype=String)
    ],
    online=True,
    input=customer_source
)

Giải thích:
- Đoạn mã trên minh họa cách định nghĩa đặc trưng và nguồn dữ liệu trong Feast.
- Khi chạy feast apply, toàn bộ định nghĩa này được đăng ký vào Registry, sẵn sàng cho cả huấn luyện và phục vụ.

Truy Xuất Dữ Liệu Offline & Online

# example_serving.py
from feast import FeatureStore
import pandas as pd

# Khởi tạo FeatureStore
store = FeatureStore(repo_path=".")

# 1. Lấy dữ liệu lịch sử (Offline)
entity_df = pd.DataFrame.from_dict({
    "customer_id": [1001, 1002, 1003],
    "event_timestamp": ["2025-10-01", "2025-10-02", "2025-10-03"]
})
training_data = store.get_historical_features(
    entity_df=entity_df,
    features=[
        "customer_features:monthly_charges",
        "customer_features:tenure",
        "customer_features:contract_type"
    ]
).to_df()
print("Offline training data:")
print(training_data.head())

# 2️. Lấy dữ liệu phục vụ (Online)
online_features = store.get_online_features(
    features=[
        "customer_features:monthly_charges",
        "customer_features:tenure",
        "customer_features:contract_type"
    ],
    entity_rows=[{"customer_id": 1001}]
).to_df()
print("Online serving data:")
print(online_features)

7. Nguồn thông tin và ảnh

• AIO2025