Các trường hợp sử dụng trí tuệ nhân tạo / máy học (AI / ML) trong thời gian thực, chẳng hạn như đề xuất và ngăn chặn gian lận, đang gia tăng và các cửa hàng tính năng đóng vai trò quan trọng trong việc triển khai thành công chúng vào sản xuất. Theo cửa hàng tính năng nguồn mở phổ biến Feast, một trong những câu hỏi phổ biến nhất mà người dùng hỏi trong cộng đồng Slack của họ là:làm thế nào có thể mở rộng / hiệu suất là Lễ? Điều này là do đặc điểm quan trọng nhất của cửa hàng tính năng cho AI / ML thời gian thực là tốc độ cung cấp tính năng từ cửa hàng trực tuyến sang mô hình ML cho các dự đoán hoặc tính điểm trực tuyến. Các cửa hàng tính năng thành công có thể đáp ứng các yêu cầu nghiêm ngặt về độ trễ (tính bằng mili giây), nhất quán (nghĩ là p99) và theo quy mô (lên đến hàng triệu truy vấn mỗi giây, với bộ dữ liệu có kích thước từ gigabyte đến terabyte) đồng thời duy trì tổng chi phí thấp quyền sở hữu và độ chính xác cao.
Như chúng ta sẽ thấy trong bài đăng này, việc lựa chọn cửa hàng tính năng trực tuyến, cũng như kiến trúc của cửa hàng tính năng đóng vai trò quan trọng trong việc xác định hiệu suất và hiệu quả chi phí của nó. Không có gì ngạc nhiên khi các công ty, trước khi chọn cửa hàng tính năng trực tuyến của họ, thực hiện đo điểm chuẩn kỹ lưỡng để xem lựa chọn kiến trúc hoặc cửa hàng tính năng trực tuyến nào hiệu quả nhất và tiết kiệm chi phí nhất. Trong bài đăng này, chúng tôi sẽ xem xét các kiến trúc và điểm chuẩn từ cả các cửa hàng tính năng DIY được xây dựng bởi các công ty triển khai thành công các trường hợp sử dụng AI / ML thời gian thực và các cửa hàng tính năng thương mại và mã nguồn mở. Hãy bắt đầu.
1. Lễ hội mã nguồn mở
Trước tiên, chúng ta hãy xem xét dữ liệu đo điểm chuẩn và sau đó là kiến trúc dữ liệu của cửa hàng tính năng nguồn mở Feast. Feast gần đây đã thực hiện một điểm chuẩn để so sánh độ trễ phân phát tính năng của nó khi sử dụng các cửa hàng trực tuyến khác nhau (Redis so với Google Cloud DataStore so với AWS DynamoDB). Nó cũng so sánh tốc độ sử dụng các cơ chế khác nhau để trích xuất các tính năng (ví dụ:máy chủ Java gRPC, máy chủ Python HTTP, hàm lambda, v.v.). Bạn có thể tìm thấy thiết lập điểm chuẩn đầy đủ và kết quả của nó trong bài đăng trên blog này. Điểm mấu chốt:Feast thấy rằng cho đến nay nó là hoạt động hiệu quả nhất khi sử dụng máy chủ Java gRPC và với Redis là cửa hàng trực tuyến.
Trong sơ đồ trên, bạn có thể thấy một ví dụ về cách công ty cho vay thế chấp trực tuyến Better.com triển khai hệ thống xếp hạng điểm dẫn đầu bằng cách sử dụng cửa hàng tính năng Feast mã nguồn mở. Như đã trình bày bởi Vitaly Sergey, Kỹ sư phần mềm cao cấp tại Better.com, các tính năng được hiện thực hóa từ các cửa hàng ngoại tuyến (S3, Snowflake và Redshift) sang cửa hàng trực tuyến (Redis). Ngoài ra, các tính năng cũng được đưa vào cửa hàng trực tuyến từ các nguồn phát trực tuyến (chủ đề Kafka). Feast gần đây đã bổ sung hỗ trợ cho các nguồn dữ liệu trực tuyến (ngoài các nguồn dữ liệu hàng loạt) hiện chỉ được hỗ trợ cho Redis. Hỗ trợ các nguồn dữ liệu phát trực tuyến là rất quan trọng đối với các trường hợp sử dụng AI / ML thời gian thực vì các trường hợp sử dụng này dựa trên dữ liệu trực tiếp mới.
Ví dụ:trong một trường hợp sử dụng tính điểm khách hàng tiềm năng cho Better.com, khách hàng tiềm năng mới đang được nhập liên tục trong ngày. Các tính năng đến từ nhiều nguồn khác nhau và cả các thực thể (khách hàng tiềm năng) và các tính năng được sử dụng để chấm điểm chúng luôn được cập nhật, do đó, các khách hàng tiềm năng được xếp hạng và xếp hạng lại. Ngay sau khi có một khách hàng tiềm năng mới, mô hình sẽ nhập và ghi điểm. Đồng thời khi nó được đưa vào cửa hàng trực tuyến, chúng tôi có thể muốn xếp hạng lại nó ngay sau đó. Khách hàng tiềm năng Better.com hết hạn sau 48 giờ và điều này được triển khai trong cửa hàng trực tuyến Redis bằng cách chỉ cần đặt thời gian tồn tại (TTL) thành 48 giờ, để thực thể (khách hàng tiềm năng) hết hạn và liên kết vectơ đặc điểm sau 48 giờ. Vì vậy, cửa hàng tính năng tự động làm sạch và không có thực thể hoặc tính năng cũ nào chiếm dung lượng lưu trữ trực tuyến có giá trị.
Một triển khai thú vị khác của Feast là Microsoft Azure Feature Store. Bạn có thể xem kiến trúc của nó tại đây. Nó chạy trên đám mây Azure được tối ưu hóa cho các trường hợp sử dụng AI / ML thời gian thực có độ trễ thấp, hỗ trợ cả nguồn hàng loạt và nguồn phát trực tuyến, cũng như tích hợp vào hệ sinh thái Azure Data &AI. Các tính năng được nhập vào cửa hàng trực tuyến từ cả hai nguồn hàng loạt (Azure Synapse Serverless SQL, Azure Storage / ADLS) và từ các nguồn phát trực tuyến (Azure Event Hub). Nếu bạn đã được triển khai trên Azure hoặc quen thuộc với hệ sinh thái Azure, thì cửa hàng tính năng này có thể phù hợp với bạn. Đối với cửa hàng trực tuyến, nó sử dụng Azure Cache cho Redis và với Enterprise Tiers của Azure Redis, nó bao gồm Active-Active Geo-Duplication để tạo ra các cache được phân phối trên toàn cầu với tính khả dụng lên đến 99,999%. Ngoài ra, có thể giảm chi phí hơn nữa bằng cách sử dụng cấp Enterprise Flash để chạy Redis trên kiến trúc bộ nhớ phân cấp sử dụng cả bộ nhớ trong (DRAM) và bộ nhớ Flash (NVMe hoặc SSD) để lưu trữ dữ liệu.
2. Cửa hàng tính năng Wix DIY - nền tảng của nền tảng MLOps
Dưới đây là một kiến trúc khác để triển khai các trường hợp sử dụng AI / ML thời gian thực. Đây là kiến trúc cửa hàng tính năng của nền tảng xây dựng trang web phổ biến Wix. Nó được sử dụng cho các trường hợp sử dụng thời gian thực như đề xuất, dự đoán churn và cao cấp, xếp hạng và phân loại thư rác. Wix phục vụ hơn 200 triệu người dùng đã đăng ký, trong đó chỉ có một phần nhỏ là 'người dùng đang hoạt động' tại bất kỳ thời điểm nào. Điều này có ảnh hưởng lớn đến cách triển khai cửa hàng tính năng. Chúng ta hãy nhìn vào nó.
Thông tin dưới đây dựa trên một bài thuyết trình trên TechTalk do Ran Romano trình bày khi ông lãnh đạo ML Engineering tại Wix. Hơn 90% dữ liệu được lưu trữ trong cửa hàng tính năng Wix là dòng nhấp chuột và các mô hình ML được kích hoạt trên mỗi trang web hoặc mỗi người dùng. Ran giải thích rằng đối với các trường hợp sử dụng thời gian thực, độ trễ là một vấn đề lớn. Ngoài ra, đối với một số trường hợp sử dụng sản xuất của họ, họ cần trích xuất các vectơ đặc trưng trong vòng mili giây.
Dữ liệu thô được lưu trữ trong tệp Parquet trên AWS trong một nhóm S3 và được phân vùng theo đơn vị kinh doanh (ví dụ:"biên tập viên", "nhà hàng", "đặt chỗ, v.v.) và sau đó là theo ngày. Nó là một phần của nền tảng dữ liệu Wix được sử dụng bởi các nhà phân tích dữ liệu của nó, vốn có trước Nền tảng Wix ML nhiều năm. Trong bản dựng hàng ngày quy trình hàng loạt sử dụng Spark, SQL (mất vài phút đến hàng giờ) tất cả các tính năng lịch sử của người dùng được trích xuất từ S3, được người dùng xoay trục và tổng hợp và nhập vào cửa hàng ngoại tuyến (Apache Hbase). Điều này cung cấp khả năng tra cứu lịch sử người dùng của ‘người dùng’ nhanh hơn nhiều. Sau khi hệ thống phát hiện thấy người dùng hiện đang hoạt động, ‘khởi động’ quy trình được kích hoạt và các tính năng của người dùng đó được tải vào cửa hàng trực tuyến (Redis) nhỏ hơn nhiều so với cửa hàng ngoại tuyến vì nó chỉ lưu giữ lịch sử người dùng của những người dùng đang hoạt động. Quá trình ‘khởi động’ này có thể mất vài giây. Và cuối cùng, các tính năng trong cửa hàng tính năng trực tuyến được cập nhật liên tục bằng cách sử dụng dữ liệu thời gian thực trực tiếp mới trực tiếp từ các nguồn phát trực tuyến cho mỗi sự kiện đến từ người dùng (sử dụng Apache Storm).
Loại kiến trúc này có tỷ lệ ghi và đọc thấp hơn so với kiến trúc Feast, rất hiệu quả về mặt vật chất hóa và lưu trữ trực tuyến vì nó chỉ lưu trữ các tính năng cho người dùng đang hoạt động trong cửa hàng trực tuyến chứ không phải cho tất cả người dùng. Bởi vì người dùng đang hoạt động chỉ chiếm một phần nhỏ trong số tất cả người dùng đã đăng ký trong Wix, điều này thể hiện một khoản tiết kiệm rất lớn. Tuy nhiên, điều này phải trả giá. Mặc dù việc truy xuất các tính năng từ cửa hàng trực tuyến rất nhanh, trong vòng mili giây nhưng chỉ khi các tính năng đó đã tồn tại trong cửa hàng trực tuyến. Do điều kiện cuộc đua, vì quá trình khởi động mất vài giây nên sẽ không đủ nhanh để tải các tính năng liên quan khi người dùng hoạt động. Vì vậy, việc chấm điểm hoặc dự đoán cho người dùng đó sẽ chỉ đơn giản là thất bại. Điều này được chấp nhận miễn là trường hợp sử dụng không phải là một phần của quy trình quan trọng hoặc đối với các trường hợp sử dụng quan trọng như phê duyệt giao dịch hoặc ngăn chặn gian lận. Loại kiến trúc này cũng rất cụ thể đối với Wix, trong đó chỉ một phần nhỏ người dùng là người dùng đang hoạt động tại bất kỳ thời điểm nào.
3. Cửa hàng tính năng thương mại Tecton
Bây giờ chúng ta hãy xem kiến trúc của cửa hàng tính năng doanh nghiệp thương mại Tecton. Như chúng ta có thể thấy trong sơ đồ bên dưới, ngoài các nguồn dữ liệu hàng loạt và nguồn dữ liệu trực tuyến, Tecton cũng hỗ trợ các nguồn dữ liệu thời gian thực ‘out-of-the-box’. Đây còn được gọi là ‘ các tính năng thời gian thực Chuyển đổi 'hoặc' thời gian thực '. Các tính năng thời gian thực chỉ có thể được tính toán theo yêu cầu suy luận. Ví dụ:sự khác biệt giữa quy mô của giao dịch bị nghi ngờ và quy mô giao dịch cuối cùng. Vì vậy, trong trường hợp của Better.com với mã nguồn mở Feast ở trên, Better.com đã tự phát triển để hỗ trợ các tính năng thời gian thực. Với cửa hàng tính năng Tecton, điều này dễ thực hiện hơn vì nó đã được cửa hàng tính năng hỗ trợ ban đầu. Giống như với Feast và các cửa hàng tính năng Wix, Tecton cũng xác định các tính năng trong sổ đăng ký để định nghĩa logic được xác định một lần cho cả cửa hàng ngoại tuyến và trực tuyến. Điều này làm giảm đáng kể độ lệch phục vụ đào tạo để đảm bảo độ chính xác cao của mô hình ML cũng trong quá trình sản xuất.
Đối với lựa chọn cửa hàng ngoại tuyến, cửa hàng trực tuyến và điểm chuẩn, đối với cửa hàng tính năng ngoại tuyến Tecton hỗ trợ S3, đối với cửa hàng trực tuyến Tecton hiện cung cấp cho khách hàng sự lựa chọn giữa DynamoDB và Redis Enterprise Cloud. Trong một bài thuyết trình gần đây, Tecton CTO Kevin Stumpf đã cung cấp các mẹo về cách chọn cửa hàng tính năng trực tuyến của bạn, dựa trên các điểm chuẩn mà công ty đã thực hiện gần đây. Ngoài việc đo độ trễ và thông lượng điểm chuẩn, Tecton cũng đo điểm chuẩn cho chi phí của cửa hàng trực tuyến. Tại sao nó quan trọng? Đối với các trường hợp sử dụng thông lượng cao hoặc độ trễ thấp, chi phí của cửa hàng trực tuyến có thể là một phần lớn và đáng kể trong tổng chi phí sở hữu toàn bộ nền tảng MLOps, do đó, mọi khoản tiết kiệm chi phí đều có thể đáng kể.
Điểm mấu chốt của điểm chuẩn của Tecton là đối với các trường hợp sử dụng thông lượng cao điển hình cho người dùng của Tecton, Redis Enterprise nhanh hơn gấp 3 lần và đồng thời ít tốn kém hơn 14 lần so với DynamoDB.
Vì vậy, bạn có thể yêu cầu bắt được gì? Nếu bạn chỉ có một trường hợp sử dụng và nó không có thông lượng cao hoặc nhất quán và không có bất kỳ yêu cầu nghiêm ngặt nào về độ trễ, thì bạn có thể sử dụng DynamoDB. Bạn có thể tìm thấy toàn bộ chi tiết và kết quả của các điểm chuẩn của Tecton tại đây.
4. Lightricks sử dụng Cửa hàng tính năng thương mại Qwak
Dưới đây là một ví dụ khác về kiến trúc cửa hàng tính năng. Cái này được sử dụng bởi Lightricks, dựa trên cửa hàng tính năng thương mại Qwak. Lightricks là một công ty kỳ lạ chuyên phát triển các ứng dụng di động chỉnh sửa video và hình ảnh, đặc biệt được biết đến với ứng dụng chỉnh sửa ảnh tự sướng, Facetune. Nó sử dụng kho tính năng cho hệ thống khuyến nghị của mình.
Như thể hiện trong sơ đồ trên, giống như Tecton, kho tính năng Qwak hỗ trợ ba loại nguồn tính năng - hàng loạt, tính năng phát trực tuyến và tính năng thời gian thực.
Điều quan trọng cần lưu ý là với kho tính năng Qwak, việc hiện thực hóa các tính năng vào kho tính năng được thực hiện trực tiếp từ các nguồn dữ liệu thô cho cả cửa hàng ngoại tuyến (sử dụng tệp Parquet trên S3) và cửa hàng trực tuyến (sử dụng Redis). Điều này khác với các ví dụ về cửa hàng tính năng từ Wix, Feast hoặc Tecton, trong đó việc thực hiện cửa hàng trực tuyến được thực hiện từ cửa hàng ngoại tuyến đến cửa hàng trực tuyến cho các nguồn hàng loạt. Điều này có lợi thế là không chỉ logic chuyển đổi của một đối tượng được thống nhất giữa các luồng đào tạo và phục vụ (như với các cửa hàng tính năng của Feast, Wix và Tecton ở trên), mà còn việc chuyển đổi thực tế hoặc tính toán đối tượng được thực hiện đồng nhất, giảm hơn nữa đào tạo-phục vụ xiên. Có một đường ống dữ liệu thống nhất cho ngoại tuyến và trực tuyến trực tiếp từ dữ liệu thô có khả năng đảm bảo độ chính xác cao hơn nữa trong quá trình sản xuất. Bạn có thể tìm thêm thông tin về cấu trúc cửa hàng tính năng và các thành phần của Qwak trong bản trình bày này.
Tóm tắt
Trong bài đăng này, chúng tôi đã xem xét những điểm nổi bật chính về điểm chuẩn và kiến trúc của một số cửa hàng tính năng cho AI / ML thời gian thực. Cửa hàng đầu tiên là Open Source Feast, cửa hàng tính năng Wix DIY thứ hai, cửa hàng thứ ba từ Tecton và cửa hàng thứ tư của Qwak. Chúng tôi cũng đã xem xét điểm nổi bật của một số điểm chuẩn mà các công ty này đã thực hiện để xem cửa hàng trực tuyến nào hoạt động hiệu quả nhất và tiết kiệm chi phí nhất. Chúng tôi cũng đã khám phá cơ chế hoặc máy chủ tính năng nào sẽ sử dụng để trích xuất các tính năng từ cửa hàng trực tuyến. Chúng tôi thấy rằng có sự khác biệt đáng kể về hiệu suất và chi phí của các cửa hàng tính năng, tùy thuộc vào kiến trúc, loại tính năng được hỗ trợ và các thành phần được chọn.
Ban đầu được xuất bản trong KDnuggets .