Databricks Feature Store: Đột phá độ trễ dưới 1 giây cho dữ liệu đặc trưng

Các mô hình học máy (machine learning) chỉ hiệu quả khi các tín hiệu đầu vào chất lượng. Một trường hợp sử dụng trong phát hiện gian lận cần quyết định trong vài mili giây kể từ khi người dùng nhấn nút mua hàng xem có nên cho phép giao dịch hay không. Việc đưa ra quyết định đúng đắn phụ thuộc vào việc nhìn thấy một giao dịch đáng ngờ vừa mới xảy ra vài giây trước. Việc kết hợp các giao dịch trung bình của người dùng trong 30 ngày qua cùng với tổng số tiền giao dịch trong 10 phút gần nhất sẽ làm nổi bật hành vi gian lận tiềm ẩn. Các tập hợp dữ liệu dài hạn thiết lập một hồ sơ cơ sở của người dùng để xác định thế nào là bình thường, trong khi dữ liệu mới nhất giúp phát hiện bất kỳ hành vi bất thường nào ngay khi nó đang diễn ra. Cá nhân hóa cũng đối mặt với áp lực tương tự: các tín hiệu mới nhất chính là thứ nắm bắt ý định hiện tại của người dùng và thúc đẩy sự tương tác.

Các pipeline Spark là một cách thức đã được khẳng định để xử lý dữ liệu khối lượng lớn trong Lakehouse cho các đặc trưng cơ sở lịch sử. Việc chạy các công việc theo lô (batch jobs) theo lịch trình định kỳ là điều đã quá quen thuộc, nhưng nó gây ra độ trễ từ vài phút đến vài giờ. Đối với các tín hiệu cơ sở về người dùng, độ trễ này là một cái giá chấp nhận được cho cơ sở hạ tầng đơn giản hơn. Khi các mô hình yêu cầu tín hiệu mới, cơ sở hạ tầng này trở nên quá tải; việc đạt đến mức giây hoặc mili giây là không thể trong các nền tảng feature store hiện có. Để mang lại giá trị của các đặc trưng mới (fresh features), các nhà khoa học dữ liệu buộc phải triển khai logic phức tạp, chuyên biệt cho streaming để xử lý các tập hợp này và thiết lập cơ sở hạ tầng lưu trữ tùy chỉnh.

Databricks Feature Store cho phép bạn tạo một đặc trưng một lần và sử dụng ở mọi nơi: cùng một định nghĩa đó điều khiển các luồng batch quy mô lớn ở chế độ offline và các pipeline đặc trưng có độ tươi mới cao ở chế độ online. Khung này loại bỏ gánh nặng cơ sở hạ tầng, điều phối Spark Real-Time Mode (RTM) để xử lý luồng liên tục, Lakebase để lưu trữ online tối ưu cho streaming, và Model Serving để truy xuất ở quy mô lớn. Và một khi đã được tạo, đặc trưng đó sẽ được phục vụ trong vài mili giây: độ trễ p99 toàn trình là 200ms, từ lúc sự kiện đến Kafka cho đến khi khả dụng trong online feature store.

Kiến trúc: Từ Kafka đến Feature Store trong 200ms

Hãy cùng xem xét bên trong để thấy cách Databricks Feature Store lấy một định nghĩa đặc trưng không phụ thuộc vào cơ sở hạ tầng và xây dựng một pipeline để tính toán nó một cách nhất quán trong vài mili giây. Đường dẫn toàn trình cho một đặc trưng streaming trông như sau:

Hãy liên hệ điều này với đặc trưng gian lận của chúng ta, là tổng số tiền giao dịch của người dùng trong 10 phút qua. Mỗi sự kiện đến mang theo chi tiết giao dịch - số tiền, vị trí, ID người dùng, thông tin người bán - và được định tuyến đến một pipeline có trạng thái (stateful pipeline). Pipeline tham vấn một instance RocksDB cục bộ đang lưu giữ tổng giao dịch hiện tại của người dùng, với thời gian hết hạn giúp duy trì cửa sổ trong 10 phút gần nhất. Pipeline đọc và tăng giá trị cục bộ, sau đó ghi giá trị đặc trưng đã cập nhật vào Lakebase. Vì vậy, khi một truy vấn gửi đến mô hình để phê duyệt giao dịch mới, tổng giao dịch cập nhật sẽ khả dụng với độ tươi mới dưới một giây trong feature store. Đặc trưng tổng này sẽ được lấy cùng với cơ sở lịch sử mua hàng của người dùng để đưa ra quyết định phê duyệt. Một khoản tổng vượt xa mức cơ sở lịch sử là chỉ báo mạnh mẽ cho mô hình về khả năng gian lận.

Mỗi thành phần trong pipeline này đã được tối ưu hóa để các sự kiện đến được định tuyến, các phép tính tập hợp được thực hiện và các đặc trưng được ghi vào online store nhanh nhất có thể.

Cửa sổ trượt (Rolling window): cập nhật các tập hợp trong vài mili giây

Trước khi đi sâu hơn vào cơ sở hạ tầng, hãy nói về các đặc trưng tập hợp và việc chuyển dịch từ mô hình đồng bộ theo lô sang cập nhật thời gian thực.

Các đặc trưng tập hợp trên một cửa sổ thời gian - ví dụ như đếm, tổng hoặc trung bình - là những tín hiệu mạnh mẽ và linh hoạt cho ML thời gian thực. Một đặc trưng batch dài hạn thiết lập cơ sở lịch sử cho người dùng trong một khoảng thời gian, cho phép mô hình thích nghi và hiểu hành vi của từng người dùng. Một đặc trưng ngắn hạn, mới mẻ phản ứng nhanh chóng với các tình huống thay đổi để phân biệt sự quan tâm mới của người dùng hoặc hoạt động gian lận. Các cửa sổ thời gian xác định một phạm vi thời gian (ví dụ: 10 phút) cũng như cách các phạm vi thời gian đó phát triển theo thời gian (ví dụ: chồng lấp hoặc tách biệt).

Databricks Feature Store hỗ trợ 3 loại cửa sổ thời gian khác nhau:

Các cửa sổ Tumbling và sliding vẫn hữu ích khi một đặc trưng không thay đổi thường xuyên: chúng phát ra ít bản cập nhật hơn, chi phí duy trì rẻ hơn và phù hợp tự nhiên với các pipeline theo lịch trình đơn giản hơn. Các cửa sổ Rolling đánh đổi hiệu quả đó để lấy độ tươi mới tối đa, điều này có giá trị nhất đối với các tín hiệu mà mọi sự kiện mới đều nên ảnh hưởng ngay lập tức đến giá trị được phục vụ cho mô hình.

Đây là cách đơn giản để định nghĩa một đặc trưng cửa sổ rolling với API khai báo của Feature Store:

Spark Real-Time Mode: công cụ để tính toán đặc trưng

Chuyển sang cơ sở hạ tầng nền tảng, pipeline streaming là thứ giúp các đặc trưng mới có thông lượng cao trở nên khả thi. Pipeline này lấy dữ liệu từ Kafka đến tận online feature store. Pipeline streaming được vận hành bởi Spark Real-Time Mode (RTM), một chế độ thực thi hoàn toàn mới cho Spark Structured Streaming. RTM là sự đổi mới kiến trúc then chốt giúp độ tươi mới ở mức mili giây trở nên khả thi.

Các giai đoạn đồng thời và xử lý có trạng thái

Trong chế độ microbatch truyền thống (MBM), Spark xử lý dữ liệu streaming theo các lô rời rạc. Mỗi lô thu thập các sự kiện trong một khoảng thời gian có thể cấu hình, xử lý chúng tuần tự qua từng giai đoạn, kiểm tra (checkpoint) và sau đó bắt đầu lô tiếp theo. Điều này tạo ra một giới hạn tối thiểu về độ trễ: ngay cả với việc tinh chỉnh mạnh mẽ, các pipeline MBM cho các tập hợp có trạng thái thường hoạt động ở mức giây đến phút. Ngược lại, RTM chạy các giai đoạn một cách đồng thời. Các toán tử tập hợp xử lý các hàng ngay khi chúng khả dụng, mà không cần đợi giai đoạn thượng nguồn hoàn tất xử lý tất cả các hàng.

Đối với các tập hợp rolling, có hai giai đoạn quan trọng. Giai đoạn đầu tiên là xử lý dữ liệu, xác thực lược đồ, gộp dữ liệu, ép kiểu. Giai đoạn này chạy logic nghiệp vụ để chuyển đổi các sự kiện hành động chung thành định dạng cho việc tập hợp đặc trưng của bạn. Giai đoạn thứ hai là tập hợp dữ liệu theo từng thực thể để tính toán các tập hợp cửa sổ rolling. Mỗi hàng đến ngay lập tức cập nhật giá trị tập hợp trong một kho lưu trữ trạng thái RocksDB cục bộ và phát ra giá trị mới xuống hạ nguồn. Việc hết hạn cửa sổ cũng diễn ra trên từng hàng: khi thời lượng cửa sổ trôi qua cho một sự kiện nhất định, pipeline sẽ loại bỏ đóng góp của sự kiện đó và phát ra giá trị tập hợp đã hiệu chỉnh vào Lakebase. RocksDB chạy cục bộ trên mỗi executor, cho phép kích thước trạng thái vượt quá dung lượng bộ nhớ của cụm.

Quản lý trạng thái pipeline trong RTM serverless

Checkpointing là yếu tố thiết yếu cho khả năng chịu lỗi trong streaming có trạng thái vì nó cho phép pipeline phục hồi từ bất kỳ lỗi nào của worker. Nhưng checkpointing cũng có cái giá của nó. Trong chế độ microbatch, Spark thực hiện checkpoint tại mỗi ranh giới lô, và mỗi checkpoint làm tăng độ trễ cho pipeline vì nó tương tác với các cloud object store.

RTM áp dụng một cách tiếp cận khác: chi phí lập kế hoạch và checkpointing được phân bổ qua các khoảng thời gian dài hơn. Chi phí checkpointing được trải đều trên tất cả các hàng được xử lý trong khoảng thời gian đó thay vì chặn pipeline tại mỗi ranh giới lô. Điều này không làm ảnh hưởng đến khả năng chịu lỗi. Các đảm bảo xử lý "exactly-once" (chính xác một lần) được duy trì - khi có lỗi, pipeline sẽ phát lại tối đa 5 phút dữ liệu từ nguồn Kafka. Sự đánh đổi là khối lượng phát lại tăng nhẹ để đổi lấy việc giảm đáng kể độ trễ xử lý ở trạng thái ổn định.

Feature Store chạy các pipeline RTM serverless trên Lakeflow Spark Delta Pipelines (SDP), loại bỏ hoàn toàn việc quản lý cụm và lập kế hoạch dung lượng. Bạn không cần cấp phát máy, tinh chỉnh số lượng executor hay lo lắng về bảo trì cụm. Khi các bản cập nhật cơ sở hạ tầng yêu cầu khởi động lại pipeline, SDP sẽ điều phối việc chuyển giao: cụm serverless mới được cấp phát và sẵn sàng hoàn toàn trước khi cụm cũ dừng lại. Sự điều phối này được đồng bộ hóa tại các khoảng checkpoint 5 phút, giảm thiểu thời gian ngừng hoạt động và tránh các khoảng trống xử lý lại. Kết quả là gần như không có sự gián đoạn nào đối với độ tươi mới của đặc trưng trong các cửa sổ bảo trì.

Lakebase: giảm thiểu chi phí cho các luồng ghi streaming

Databricks Feature Store sử dụng Lakebase để lưu trữ các giá trị đặc trưng online cho việc suy luận (inference). Kiến trúc Lakebase tách biệt tính toán và lưu trữ cho phép tự động mở rộng để xử lý tải biến đổi cho việc suy luận mô hình. Online Feature Store tận dụng khả năng này để mở rộng quy mô lên hàng chục nghìn lượt đọc mỗi giây với độ trễ hàng chục mili giây.

Các luồng ghi streaming đặc biệt thách thức vì chúng bao gồm một số lượng lớn các thao tác upsert nhỏ khi các giá trị cửa sổ rolling mới được phát ra trên mỗi hàng Kafka nhận được. Trong Postgres tiêu chuẩn, mô hình này có thể tạo ra khối lượng log ghi trước (write-ahead log - WAL) lớn vì Postgres sử dụng ghi toàn trang để cho phép phục hồi dễ dàng hơn. Sau mỗi checkpoint, sửa đổi đầu tiên đối với một trang sẽ ghi toàn bộ hình ảnh trang 8KB vào WAL, chứ không chỉ là thay đổi logic nhỏ. Đối với các hàng thực thể nóng được cập nhật thường xuyên, điều này khiến việc khuếch đại WAL trở thành nút thắt cổ chai cho thông lượng ghi, sao chép và chi phí phục hồi.

Lakebase hiện tận dụng sự tách biệt giữa tính toán và lưu trữ phân tán để giảm thiểu sự khuếch đại ghi streaming so với Postgres tiêu chuẩn. Kiến trúc Lakebase cho phép Postgres ghi các bản ghi thay đổi nhỏ, gọn thay vì liên tục ghi các bản chụp trang 8KB đầy đủ vào WAL. Độ bền vẫn được bảo vệ vì các bản ghi nhỏ gọn đó được xác nhận bởi một nhóm các nút safekeeper phân tán. Các bản chụp toàn trang vẫn cần thiết cho việc phục hồi sau khi có đủ các bản ghi thay đổi, nhưng chúng được tạo ra sau đó trong lớp lưu trữ thay vì làm phình to đường dẫn ghi. Đối với Feature Store, kết quả là RTM có thể liên tục xuất bản các giá trị đặc trưng mới vào Lakebase với sự khuếch đại WAL ít hơn nhiều và độ trễ bổ sung tối thiểu.

Model Serving: truy xuất đặc trưng độ trễ thấp ở quy mô lớn

Chặng cuối của hành trình là truy xuất các đặc trưng mới từ Lakebase và cung cấp chúng cho mô hình tại thời điểm suy luận. Điều này được xử lý bởi Databricks Model Serving, một cơ sở hạ tầng phục vụ được quản lý hoàn toàn, tối ưu hóa cho các khối lượng công việc có QPS cao và độ trễ thấp.

Model Serving được xây dựng cho các nhu cầu thông lượng của ML thời gian thực:

Đối với Feature Store, việc tích hợp là liền mạch. Khi một mô hình được ghi lại với MLflow, các phụ thuộc đặc trưng của nó sẽ được ghi lại. Tại thời điểm suy luận, Model Serving tự động tra cứu các đặc trưng cần thiết từ Lakebase - không cần mã tra cứu tùy chỉnh, không cần kết nối thủ công. Tập hợp mới được tính toán bởi RTM và lưu trữ trong Lakebase được truy xuất và kết hợp với yêu cầu suy luận một cách minh bạch.

Feature Store ngoài streaming

Các khả năng thời gian thực hiệu năng cao chỉ là một phần những gì Feature Store có thể giải quyết. Hai thách thức khác đáng được xem xét ngắn gọn:

Dữ liệu huấn luyện cho các đặc trưng stream

Việc tạo dữ liệu huấn luyện có thể khó khăn đối với các đặc trưng streaming vì các cửa sổ lưu giữ ngắn trên các stream đòi hỏi phải duy trì một kho lưu trữ offline riêng biệt. Databricks Feature Store giải quyết vấn đề này bằng cách lưu trữ một bản sao offline của dữ liệu Kafka đã được tiếp nhận. Để huấn luyện mô hình, Feature Store tính toán các giá trị đặc trưng giống như các pipeline streaming sẽ làm cho các giá trị lịch sử và thực hiện các phép nối chính xác theo thời điểm (point-in-time accurate joins). Khả năng tương tự này được sử dụng để lấp đầy các đặc trưng streaming online nhằm cho phép triển khai nhanh chóng vào môi trường sản xuất.

Tích hợp

Như đã trình bày ở trên, Feature Store điều phối một số thành phần cơ sở hạ tầng phức tạp. Sự phân mảnh đó có thể gây khó khăn cho quản trị, dòng dõi (lineage) và việc tái sử dụng đặc trưng. Nó cũng làm chậm quá trình phát triển, vì các kỹ sư phải phối hợp các thay đổi giữa các ranh giới hệ thống.

Trong Databricks, các đặc trưng là các đối tượng hạng nhất trong Unity Catalog - có thể khám phá, được quản trị với các kiểm soát truy cập và được theo dõi với dòng dõi đầy đủ. Các biến đổi đặc trưng được đóng gói cùng với mô hình, MLflow ghi lại những đặc trưng nào đã được sử dụng và dòng dõi triển khai kết nối các mô hình với các phụ thuộc đặc trưng của chúng. Nền tảng này là một điểm dừng duy nhất để phát triển, triển khai và quản trị toàn bộ stack ML của bạn.