Hướng dẫn sử dụng Apache Cassandra làm kho lưu trữ tính năng thời gian thực

Đây là hướng dẫn thực tế để sử dụng Apache Cassandra làm kho lưu trữ tính năng thời gian thực. Chúng tôi khám phá AI thời gian thực cũng như các thuộc tính chi phí và hiệu suất độc đáo của Cassandra giúp nó trở thành cơ sở dữ liệu tuyệt vời cho kho tính năng, sau đó đi sâu vào kiến thức cơ bản về kho tính năng và vai trò của chúng trong các ứng dụng thời gian thực. Cassandra được sử dụng như một cửa hàng tính năng của các công ty lớn, bao gồm Uber và Netflix; trong điều kiện thực tế, nó có thể phục vụ các tính năng suy luận thời gian thực với tp99 < 23ms.

Hướng dẫn được chia thành nhiều phần chính. Chúng tôi bắt đầu bằng cách giới thiệu Cassandra và các tính năng giúp nó trở thành lựa chọn lý tưởng cho cửa hàng tính năng. Sau đó, chúng tôi giải thích những kiến thức cơ bản về kho tính năng, bao gồm chúng là gì và cách chúng có thể được sử dụng trong các ứng dụng thời gian thực. Sau đó, chúng tôi khám phá các chi tiết triển khai của việc tạo một cửa hàng tính năng bằng Cassandra. Điều này bao gồm lập mô hình dữ liệu, nhập và truy xuất các tính năng cũng như xử lý các bản cập nhật dữ liệu. Cuối cùng, chúng tôi cung cấp các mẹo và phương pháp hay nhất để sử dụng Cassandra làm kho lưu trữ tính năng nhằm đảm bảo hiệu suất và khả năng mở rộng tối ưu - từ các yêu cầu về độ trễ đến các yêu cầu về chỉ số hiệu suất ước tính cho đến kiến trúc tham chiếu và khả năng tương thích hệ sinh thái.

Hướng dẫn này không thảo luận vềkhía cạnh khoa học dữ liệu của học máy thời gian thực hoặc là các khía cạnh quản lý vòng đời của các tính năng trong một cửa hàng tính năng . Các phương pháp hay nhất mà chúng tôi sẽ đề cập dựa trên các cuộc trò chuyện kỹ thuật với các học viên tại các công ty công nghệ lớn như Google, Facebook, Uber , AirBnB , Và Netflix về cách họ cung cấp trải nghiệm AI theo thời gian thực cho khách hàng trên cơ sở hạ tầng dựa trên đám mây của họ. Mặc dù chúng tôi sẽ đặc biệt tập trung vào cách triển khai tính năng lưu trữ theo thời gian thực với Cassandra, nhưng các nguyên tắc kiến trúc thực sự áp dụng cho bất kỳ công nghệ cơ sở dữ liệu nào, bao gồm Redis, MongoDB và Postgres.

AI thời gian thực là gì?

AI thời gian thực đưa ra các suy luận hoặc mô hình đào tạo dựa trên các sự kiện gần đây . Theo truyền thống, các mô hình đào tạo và suy luận (dự đoán) dựa trên các mô hình đã được thực hiện theo đợt – thường là qua đêm hoặc định kỳ trong ngày. Ngày nay, các hệ thống máy học hiện đại thực hiện suy luận dữ liệu gần đây nhất để đưa ra dự đoán chính xác nhất có thể. Một nhóm nhỏ các công ty như TikTok và Google đã thúc đẩy mô hình thời gian thực hơn nữa bằng cách bao gồm đào tạo mô hình nhanh chóng khi có dữ liệu mới.

Do những thay đổi này trong suy luận và những thay đổi có thể xảy ra đối với quá trình đào tạo mô hình, tính bền vững của dữ liệu tính năng – dữ liệu được sử dụng để đào tạo và thực hiện các suy luận cho mô hình ML – cũng cần phải thích ứng. Khi bạn đọc xong hướng dẫn này, bạn sẽ có một bức tranh rõ ràng hơn về cách Cassandra và DataStax Astra DB, một dịch vụ được quản lý được xây dựng trên Cassandra, đáp ứng nhu cầu AI thời gian thực và cách chúng có thể được sử dụng cùng với các công nghệ cơ sở dữ liệu khác cho mô hình suy luận và đào tạo.

Cửa hàng tính năng là gì?

Cửa hàng tính năng là một hệ thống dữ liệu dành riêng cho máy học (ML):

• Chạy các đường dẫn dữ liệu chuyển đổi dữ liệu thô thành các giá trị tính năng
• Lưu trữ và quản lý dữ liệu tính năng, và
• Phục vụ dữ liệu tính năng một cách nhất quán cho mục đích đào tạo và suy luận

Trí tuệ nhân tạo thời gian thực đặt ra các yêu cầu cụ thể đối với một kho tính năng mà Cassandra có đủ điều kiện duy nhất để đáp ứng, đặc biệt khi nói đến việc lưu trữ và cung cấp các tính năng để phục vụ mô hình và Đào tạo mô hình.

Thực hành tốt nhất

**Triển khai các truy vấn có độ trễ thấp để cung cấp tính năng

Để suy luận theo thời gian thực, các tính năng cần được trả lại cho các ứng dụng có độ trễ thấp trên quy mô lớn. Các mô hình điển hình bao gồm ~200 tính năng trải rộng trên ~10 thực thể. Suy luận thời gian thực cần có thời gian để lập ngân sách cho việc thu thập các tính năng, chuyển đổi dữ liệu nhẹ và thực hiện suy luận. Theo cuộc khảo sát sau đây (cũng được xác nhận bởi các cuộc trò chuyện của chúng tôi với các học viên), các cửa hàng tính năng cần trả lại các tính năng cho một ứng dụng thực hiện suy luận trong thời gian dưới 50 mili giây.

Thông thường, các mô hình yêu cầu “liên kết bên trong” trên nhiều thực thể logic – kết hợp các giá trị hàng từ nhiều bảng chia sẻ một giá trị chung; điều này đặt ra một thách thức đáng kể đối với việc cung cấp tính năng có độ trễ thấp. Lấy trường hợp của Uber Eats, dự đoán thời gian giao bữa ăn. Dữ liệu cần được kết hợp từ thông tin đặt hàng, thông tin này được kết hợp với thông tin nhà hàng, thông tin này được kết hợp thêm với thông tin giao thông trong khu vực của nhà hàng. Trong trường hợp này, cần có hai phép nối bên trong (xem hình minh họa bên dưới).

Để đạt được phép nối bên trong Cassandra, người ta có thể không chuẩn hóa dữ liệu khi chèn hoặc thực hiện hai truy vấn tuần tự tới Cassandra + thực hiện phép nối ở phía máy khách. Mặc dù có thể thực hiện tất cả các phép nối bên trong khi chèn dữ liệu vào cơ sở dữ liệu thông qua quá trình không chuẩn hóa, nhưng tỷ lệ 1:1 giữa mô hình và bảng là không thực tế vì điều đó có nghĩa là duy trì số lượng bảng không chuẩn hóa quá nhiều. Các phương pháp hay nhất gợi ý rằng kho lưu trữ tính năng cần cho phép 1-2 truy vấn tuần tự đối với các kết nối bên trong, kết hợp với chuẩn hóa.

Dưới đây là tóm tắt các chỉ số hiệu suất có thể được sử dụng để ước tính các yêu cầu đối với quy trình ML thời gian thực:

Điều kiện thử nghiệm:

• tính năng = 200

• số lượng bảng (thực thể) = 3

• số lượng kết nối bên trong = 2

• Truy vấn TPS : 5000 truy vấn/giây

• Viết TPS: 500 bản ghi/giây

• Kích thước cụm : 3 nút trên AstraDB*

  
  

Tóm tắt hiệu suất độ trễ (độ không chắc chắn ở đây là độ lệch chuẩn):

• tp95 = 13,2(+/-0,6) mili giây

• tp99 = 23,0(+/-3,5) mili giây

• tp99,9 = 63(+/- 5) mili giây

  
  

Ảnh hưởng của đầm nén:

• tp95 = không đáng kể
• tp99, tp999 = không đáng kể, được chụp bởi sigma được trích dẫn ở trên

Ảnh hưởng của việc thu thập dữ liệu thay đổi (CDC):

• tp50, tp95 ~ 3-5 ms

• tp99 ~ 3 ms

• tp999 ~ không đáng kể

  
  

*Các thử nghiệm sau được thực hiện trên bậc miễn phí của DataStax Astra DB , đây là môi trường không có máy chủ dành cho Cassandra. Người dùng sẽ mong đợi hiệu suất độ trễ tương tự khi được triển khai trên ba ghi chú bằng cách sử dụng các cài đặt được đề xuất sau đây .

Tác động đáng kể nhất đến độ trễ là số lượng kết nối bên trong. Nếu chỉ một bảng được truy vấn thay vì ba, tp99 giảm 58%; đối với hai bảng, nó ít hơn 29%. tp95 giảm lần lượt là 56% và 21%. Vì Cassandra có thể mở rộng theo chiều ngang nên việc truy vấn nhiều tính năng hơn cũng không làm tăng đáng kể độ trễ trung bình.

Cuối cùng, nếu không thể đáp ứng các yêu cầu về độ trễ ngay lập tức, Cassandra có hai tính năng bổ sung: khả năng hỗ trợ dữ liệu không chuẩn hóa (và do đó giảm các kết nối bên trong) do khả năng ghi thông lượng cao và khả năng sao chép có chọn lọc dữ liệu vào bộ nhớ cache (ví dụ: Redis) thông qua Thay đổi dữ liệu Capture. Bạn có thể tìm thêm các mẹo để giảm độ trễ tại đây.

Thực hiện khả năng chịu lỗi và ghi độ trễ thấp để chuyển đổi tính năng

Một thành phần quan trọng của AI thời gian thực là khả năng sử dụng dữ liệu gần đây nhất để thực hiện suy luận mô hình, vì vậy, điều quan trọng là dữ liệu mới có sẵn để suy luận càng sớm càng tốt. Đồng thời, đối với các trường hợp sử dụng của doanh nghiệp, điều quan trọng là quá trình ghi phải bền bỉ vì việc mất dữ liệu có thể gây ra những thách thức đáng kể về sản xuất.

*Các cửa hàng đối tượng (ví dụ: S3 hoặc HIVE) có thể được thay thế bằng các loại hệ thống định hướng hàng loạt khác, chẳng hạn như kho dữ liệu.

Có sự đánh đổi giữa khả năng ghi lâu bền có độ trễ thấp và việc cung cấp tính năng có độ trễ thấp. Ví dụ: chỉ có thể lưu trữ dữ liệu ở một vị trí không bền (ví dụ: Redis), nhưng lỗi sản xuất có thể gây khó khăn cho việc khôi phục các tính năng cập nhật nhất vì nó sẽ yêu cầu tính toán lại lớn từ các sự kiện thô .

Kiến trúc phổ biến gợi ý ghi các tính năng vào cửa hàng ngoại tuyến (ví dụ: Hive/S3) và sao chép các tính năng vào cửa hàng trực tuyến (ví dụ: bộ đệm trong bộ nhớ). Mặc dù điều này mang lại độ bền và độ trễ thấp cho việc phân phối tính năng, nhưng nó phải trả giá bằng việc tạo ra độ trễ cho việc ghi tính năng, điều này luôn gây ra hiệu suất dự đoán kém hơn.

Cassandra cung cấp sự cân bằng tốt giữa việc cung cấp tính năng có độ trễ thấp và ghi tính năng “bền” có độ trễ thấp. Dữ liệu được ghi vào Cassandra thường được sao chép tối thiểu ba lần và nó hỗ trợ sao chép đa vùng. Độ trễ từ khi ghi đến khi có sẵn để đọc thường là dưới một phần nghìn giây. Do đó, bằng cách duy trì các tính năng trực tiếp đến cửa hàng trực tuyến (Cassandra) và bỏ qua cửa hàng ngoại tuyến, ứng dụng có quyền truy cập nhanh hơn vào dữ liệu gần đây để đưa ra dự đoán chính xác hơn. Đồng thời, CDC, từ cửa hàng trực tuyến đến cửa hàng ngoại tuyến, cho phép đào tạo hàng loạt hoặc khám phá dữ liệu bằng các công cụ hiện có.

Thực hiện độ trễ thấp và ghi để dự đoán bộ nhớ đệm và theo dõi hiệu suất

Ngoài việc lưu trữ chuyển đổi tính năng, cũng cần lưu trữ các dự đoán và dữ liệu theo dõi khác để theo dõi hiệu suất.

Có một số trường hợp sử dụng để lưu trữ dự đoán:

1. Lưu trữ dự đoán – Trong trường hợp này, một cơ sở dữ liệu được sử dụng để lưu trữ các dự đoán được tạo bởi hệ thống lô hoặc hệ thống phát trực tuyến . Kiến trúc phát trực tuyến đặc biệt hữu ích khi thời gian suy luận vượt quá mức có thể chấp nhận được trong hệ thống phản hồi yêu cầu.
2. Giám sát hiệu suất dự đoán Thông thường cần phải giám sát đầu ra dự đoán của suy luận thời gian thực và so sánh với kết quả cuối cùng. Điều này có nghĩa là có một cơ sở dữ liệu để ghi kết quả dự đoán và kết quả cuối cùng.

Cassandra là một kho lưu trữ phù hợp cho cả hai trường hợp sử dụng vì khả năng ghi thông lượng cao của nó.

Lập kế hoạch cho khối lượng công việc đọc và ghi đàn hồi

Mức độ truy vấn và ghi giao dịch mỗi giây thường phụ thuộc vào số lượng người dùng đồng thời sử dụng hệ thống. Do đó, khối lượng công việc có thể thay đổi dựa trên thời gian trong ngày hoặc thời gian trong năm. Có khả năng nhanh chóng tăng và giảm quy mô cụm để hỗ trợ khối lượng công việc gia tăng là rất quan trọng. Cassandra và Astra DB có các tính năng cho phép thay đổi quy mô cụm động.

Khía cạnh thứ hai có thể ảnh hưởng đến khối lượng công việc ghi là nếu có những thay đổi trong logic chuyển đổi tính năng. Với khối lượng công việc ghi tăng đột biến, Cassandra tự động ưu tiên duy trì các truy vấn có độ trễ thấp và ghi TPS dựa trên tính nhất quán của dữ liệu, điều này thường được chấp nhận để thực hiện suy luận theo thời gian thực.

Triển khai hỗ trợ đa khu vực, độ trễ thấp

Khi AI thời gian thực trở nên phổ biến trên tất cả các ứng dụng, điều quan trọng là phải đảm bảo rằng dữ liệu tính năng có sẵn càng gần nơi xảy ra suy luận càng tốt. Điều này có nghĩa là có cửa hàng tính năng trong cùng khu vực với ứng dụng đang thực hiện suy luận. Sao chép dữ liệu trong kho tính năng giữa các vùng giúp đảm bảo tính năng đó. Hơn nữa, việc chỉ sao chép các tính năng chứ không phải dữ liệu thô được sử dụng để tạo các tính năng sẽ cắt giảm đáng kể phí ra khỏi đám mây.

Astra DB hỗ trợ sao chép đa vùng ngay lập tức, với độ trễ sao chép tính bằng mili giây. Đề xuất của chúng tôi là truyền trực tuyến tất cả dữ liệu sự kiện thô đến một vùng duy nhất, thực hiện tạo tính năng, đồng thời lưu trữ và sao chép các tính năng sang tất cả các vùng khác.

Mặc dù về mặt lý thuyết, người ta có thể đạt được một số lợi thế về độ trễ bằng cách tạo các tính năng ở từng khu vực, nhưng dữ liệu sự kiện thường cần được kết hợp với dữ liệu sự kiện thô từ các khu vực khác;. từ quan điểm về tính chính xác và hiệu quả, việc chuyển tất cả các sự kiện đến một khu vực để xử lý cho hầu hết các trường hợp sử dụng sẽ dễ dàng hơn. Mặt khác, nếu việc sử dụng mô hình có ý nghĩa nhất trong bối cảnh khu vực và hầu hết các sự kiện được liên kết với các thực thể dành riêng cho khu vực, thì sẽ hợp lý khi coi các đối tượng địa lý là khu vực cụ thể. Bất kỳ sự kiện nào cần được sao chép giữa các khu vực đều có thể được đặt trong các không gian khóa với chiến lược sao chép toàn cầu, nhưng lý tưởng nhất, đây phải là một tập hợp con nhỏ các sự kiện. Tại một thời điểm nhất định, việc sao chép các bảng sự kiện trên toàn cầu sẽ kém hiệu quả hơn so với việc chỉ chuyển tất cả các sự kiện đến một khu vực duy nhất để tính toán đối tượng địa lý.

Lập kế hoạch hỗ trợ nhiều đám mây có độ trễ thấp và hiệu quả về chi phí

Hỗ trợ nhiều đám mây giúp tăng khả năng phục hồi của các ứng dụng và cho phép khách hàng thương lượng mức giá thấp hơn. Các cửa hàng trực tuyến trên một đám mây như DynamoDB dẫn đến cả độ trễ truy xuất tính năng tăng lên và chi phí xuất dữ liệu đáng kể nhưng cũng tạo ra sự khóa đối với một nhà cung cấp đám mây duy nhất.

Cơ sở dữ liệu nguồn mở hỗ trợ sao chép trên các đám mây mang lại sự cân bằng tốt nhất về chi phí hiệu suất. Để giảm thiểu chi phí đầu ra, các sự kiện và tính năng tạo phải được hợp nhất vào một đám mây và dữ liệu tính năng phải được sao chép sang cơ sở dữ liệu nguồn mở trên các đám mây khác. Điều này giảm thiểu chi phí đầu ra.

Lập kế hoạch cho cả đào tạo hàng loạt và thời gian thực cho các mô hình sản xuất

Cơ sở hạ tầng xử lý hàng loạt để xây dựng mô hình được sử dụng cho hai trường hợp sử dụng: xây dựng và thử nghiệm các mô hình mới và xây dựng mô hình cho sản xuất. Do đó, dữ liệu đối tượng thường được lưu trữ trong kho lưu trữ đối tượng chậm hơn cho mục đích đào tạo thường là đủ. Tuy nhiên, các mô hình đào tạo mô hình mới hơn bao gồm cập nhật các mô hình theo thời gian thực hoặc gần thời gian thực (đào tạo thời gian thực); đây được gọi là “học trực tuyến” (ví dụ: TikTok's Monolith ). Mẫu truy cập cho đào tạo thời gian thực nằm ở đâu đó giữa suy luận và đào tạo hàng loạt truyền thống. Các yêu cầu về thông lượng dữ liệu cao hơn so với suy luận (vì nó thường không truy cập tra cứu một hàng), nhưng không cao bằng xử lý hàng loạt liên quan đến quét toàn bộ bảng.

Cassandra có thể hỗ trợ xếp hạng TPS ở mức hàng trăm nghìn mỗi giây (với mô hình dữ liệu phù hợp), có thể cung cấp đủ thông lượng cho hầu hết các trường hợp sử dụng đào tạo thời gian thực. Tuy nhiên, trong trường hợp người dùng muốn tiếp tục đào tạo theo thời gian thực từ kho lưu trữ đối tượng, Cassandra đạt được điều này thông qua CDC để lưu trữ đối tượng. Đối với đào tạo hàng loạt, CDC nên sao chép dữ liệu vào bộ lưu trữ đối tượng. Cần lưu ý rằng các khung máy học như Tensorflow và PyTorch được tối ưu hóa đặc biệt để đào tạo song song các mô hình ML từ bộ nhớ đối tượng.

Để có giải thích chi tiết hơn về “học tập trực tuyến”, hãy xem giải thích của Chip Huyuen vềHọc liên tục hoặc bài báo kỹ thuật này từ Gomes et. tất cả .

Hỗ trợ kiến trúc Kappa

Kiến trúc Kappa đang dần thay thế kiến trúc Lambda do các vấn đề về chi phí và chất lượng dữ liệu do độ lệch trực tuyến/ngoại tuyến. Mặc dù rất nhiều bài viết thảo luận về lợi ích của việc chuyển từ các lớp tính toán thời gian thực và hàng loạt riêng biệt sang một lớp thời gian thực duy nhất, các bài báo thường không mô tả cách kiến trúc lớp phục vụ.

Sử dụng kiến trúc Kappa để tạo các tính năng mang đến một số cân nhắc mới:

• Các tính năng cập nhật đang được cập nhật hàng loạt và có thể dẫn đến một số lượng đáng kể các lần ghi vào cơ sở dữ liệu. Điều quan trọng là phải đảm bảo rằng độ trễ truy vấn không bị ảnh hưởng trong các bản cập nhật lớn này.
• Lớp phục vụ vẫn cần hỗ trợ các loại truy vấn khác nhau, bao gồm truy vấn có độ trễ thấp để suy luận và truy vấn TPS cao để đào tạo hàng loạt mô hình.

Cassandra hỗ trợ kiến trúc Kappa theo các cách sau:

• Cassandra được thiết kế để ghi; dòng ghi tăng lên không làm giảm đáng kể độ trễ của truy vấn. Cassandra chọn xử lý ghi với tính nhất quán cuối cùng thay vì tính nhất quán mạnh, thường được chấp nhận để đưa ra dự đoán.
• Sử dụng CDC, dữ liệu có thể được sao chép vào bộ lưu trữ đối tượng để đào tạo và bộ nhớ trong bộ nhớ để suy luận. CDC ít ảnh hưởng đến độ trễ của các truy vấn tới Cassandra.

Hỗ trợ kiến trúc Lambda

Hầu hết các công ty đều có kiến trúc Lambda, với quy trình lớp hàng loạt tách biệt với quy trình thời gian thực. Có một số loại tính năng trong trường hợp này:

1. Các tính năng chỉ được tính toán trong thời gian thực và được sao chép vào kho lưu trữ tính năng hàng loạt để đào tạo
2. Các tính năng chỉ được tính toán theo đợt và được sao chép vào kho lưu trữ tính năng theo thời gian thực
3. Các tính năng được tính toán theo thời gian thực trước, sau đó được tính toán lại theo đợt. Sự khác biệt sau đó được cập nhật trong cả cửa hàng đối tượng và thời gian thực.

Tuy nhiên, trong trường hợp này, DataStax đề xuất kiến trúc như được mô tả trong hình minh họa này:

Những lý do như sau:

1. Cassandra được thiết kế để tải dữ liệu lên hàng loạt mà ít ảnh hưởng đến độ trễ đọc
2. Bằng cách có một hệ thống bản ghi duy nhất, việc quản lý dữ liệu trở nên dễ dàng hơn nhiều so với việc dữ liệu được phân chia giữa kho lưu trữ đối tượng và kho lưu trữ đối tượng. Điều này đặc biệt quan trọng đối với các tính năng được tính toán thời gian thực đầu tiên, sau đó được tính toán lại hàng loạt.
3. Khi xuất dữ liệu từ Cassandra qua CDC sang kho lưu trữ tính năng đối tượng, quá trình xuất dữ liệu có thể được tối ưu hóa để đào tạo hàng loạt ( mẫu phổ biến được sử dụng tại các công ty như Facebook ), giúp cắt giảm đáng kể chi phí cơ sở hạ tầng đào tạo.

Nếu không thể cập nhật các quy trình hiện có hoặc có những lý do cụ thể khiến các tính năng cần phải có trong kho đối tượng trước tiên, chúng tôi khuyên bạn nên sử dụng đường dẫn CDC hai chiều giữa kho tính năng Cassandra và kho đối tượng, như minh họa bên dưới.

Đảm bảo khả năng tương thích với hệ sinh thái phần mềm ML hiện có

Để sử dụng Cassandra làm kho lưu trữ tính năng, nó phải được tích hợp với hai phần của hệ sinh thái: thư viện máy học thực hiện suy luận và đào tạo và thư viện xử lý dữ liệu thực hiện chuyển đổi tính năng.

Hai khung phổ biến nhất cho máy học là TensorFlow và PyTorch. Cassandra có trình điều khiển Python cho phép dễ dàng truy xuất các tính năng từ cơ sở dữ liệu Cassandra; nói cách khác, nhiều tính năng có thể được tìm nạp song song ( xem mã ví dụ này ). Hai khung phổ biến nhất để thực hiện chuyển đổi tính năng là Flink và Spark Structured Streaming . Trình kết nối cho cả Flink và Spark đều có sẵn cho Cassandra. Các học viên có thể sử dụng các hướng dẫn cho Truyền phát có cấu trúc Flink và Spark và Cassandra.

Các cửa hàng tính năng Nguồn mở như FEAST cũng có trình kết nối và hướng dẫn cho Cassandra.

Hiểu các mẫu truy vấn và thông lượng để xác định chi phí

Số lượng truy vấn đọc cho Cassandra dưới dạng kho lưu trữ tính năng phụ thuộc vào số lượng yêu cầu suy luận đến. Giả sử dữ liệu tính năng được chia thành nhiều bảng hoặc nếu dữ liệu có thể được tải song song, điều này sẽ đưa ra ước tính về phân tán giữa suy luận thời gian thực có thể được thực hiện. Ví dụ: 200 tính năng trên 10 thực thể trong 10 bảng riêng biệt cung cấp cho bạn tỷ lệ 1:10 giữa suy luận thời gian thực và truy vấn tới Cassandra.

Việc tính toán số lượng suy luận đang được thực hiện sẽ phụ thuộc vào mẫu lưu lượng truy cập suy luận. Ví dụ: trong trường hợp “suy luận trực tuyến”, một suy luận sẽ được thực hiện bất cứ khi nào một đối tượng địa lý có liên quan thay đổi, vì vậy tổng số lần suy luận phụ thuộc vào tần suất dữ liệu đối tượng địa lý thay đổi. Khi suy luận được thực hiện trong cài đặt “yêu cầu-trả lời”, nó chỉ được thực hiện khi người dùng yêu cầu.

Hiểu các mẫu ghi hàng loạt và thời gian thực để xác định chi phí

Thông lượng ghi chủ yếu bị chi phối bởi tần suất các tính năng thay đổi. Nếu không chuẩn hóa xảy ra, điều này cũng có thể ảnh hưởng đến số lượng tính năng được viết. Các cân nhắc về thông lượng ghi khác bao gồm suy luận bộ nhớ đệm cho các kịch bản suy luận hàng loạt hoặc truyền trực tuyến.

Phần kết luận

Khi thiết kế đường dẫn ML thời gian thực, cần đặc biệt chú ý đến hiệu suất và khả năng mở rộng của kho tính năng. Các yêu cầu đặc biệt được đáp ứng tốt bởi các cơ sở dữ liệu NoSQL như Cassandra. Xây dựng kho tính năng của riêng bạn với Cassandra hoặc AstraDB và dùng thử Feast.dev với trình kết nối Cassandra .