Hopsworks特征存儲(chǔ)庫(kù)統(tǒng)一了在線和批處理應(yīng)用程序的特征訪問(wèn)而屏蔽了雙數(shù)據(jù)庫(kù)系統(tǒng)的復(fù)雜性。我們構(gòu)建了一個(gè)可靠且高性能的服務(wù)，以將特征物化到在線特征存儲(chǔ)庫(kù)，不僅僅保證低延遲訪問(wèn)，而且還保證在服務(wù)時(shí)間可以訪問(wèn)最新鮮的特征值。

企業(yè)機(jī)器學(xué)習(xí)模型為指導(dǎo)產(chǎn)品用戶交互提供了價(jià)值價(jià)值。通常這些 ML 模型應(yīng)用于整個(gè)實(shí)體數(shù)據(jù)庫(kù)，例如由唯一主鍵標(biāo)識(shí)用戶。離線應(yīng)用程序的一個(gè)示例是預(yù)測(cè)客戶終身價(jià)值（Customer Lifetime Value），其中可以定期（每晚、每周）分批預(yù)測(cè)，然后用于選擇營(yíng)銷(xiāo)活動(dòng)的目標(biāo)受眾。然而更先進(jìn)的人工智能應(yīng)用程序可以實(shí)時(shí)指導(dǎo)用戶交互，例如推薦系統(tǒng)。對(duì)于這些在線應(yīng)用程序，模型輸入的某些部分（特征向量）將在應(yīng)用程序本身中可用，例如最后點(diǎn)擊的按鈕，而特征向量的其他部分則依賴于歷史或上下文數(shù)據(jù)，必須檢索后端存儲(chǔ)，例如用戶在過(guò)去一小時(shí)內(nèi)點(diǎn)擊按鈕的次數(shù)或按鈕是否為熱門(mén)按鈕。

在這篇博客中，我們將深入探討在線應(yīng)用程序的需求細(xì)節(jié)，以及 Hopsworks特征庫(kù)如何抽象并規(guī)避雙存儲(chǔ)系統(tǒng)的復(fù)雜性。

1. 生產(chǎn)中的機(jī)器學(xué)習(xí)模型

雖然具有（分析）模型的批處理應(yīng)用程序在很大程度上類似于模型本身的訓(xùn)練，需要有效訪問(wèn)將要參與評(píng)分的大量數(shù)據(jù)，但在線應(yīng)用程序需要低延遲訪問(wèn)給定主鍵的最新特征值，然后作為特征向量發(fā)送到模型服務(wù)實(shí)例進(jìn)行推理。

據(jù)我們所知沒(méi)有單一的數(shù)據(jù)庫(kù)能夠高性能滿足這兩個(gè)要求，因此數(shù)據(jù)團(tuán)隊(duì)傾向于將用于訓(xùn)練和批量推理的數(shù)據(jù)保留在數(shù)據(jù)湖中，而 ML工程師更傾向于構(gòu)建微服務(wù)以將微服務(wù)中的特征工程邏輯復(fù)制到在線應(yīng)用程序中。

然而，這給數(shù)據(jù)科學(xué)家和機(jī)器學(xué)習(xí)工程師帶來(lái)了不必要的障礙，無(wú)法快速迭代并顯著增加機(jī)器學(xué)習(xí)模型的用于生產(chǎn)環(huán)境的時(shí)間

?數(shù)據(jù)科學(xué)視角：數(shù)據(jù)和基礎(chǔ)設(shè)施通過(guò)微服務(wù)緊密耦合，導(dǎo)致數(shù)據(jù)科學(xué)家無(wú)法從開(kāi)發(fā)轉(zhuǎn)向生產(chǎn)，也無(wú)法復(fù)用特征。?ML 工程視角：大量工程工作以保證對(duì)生產(chǎn)中數(shù)據(jù)的一致訪問(wèn)，正如 ML 模型在訓(xùn)練過(guò)程中所看到的那樣。

2. Hopsworks特征存儲(chǔ)庫(kù)：透明的雙存儲(chǔ)系統(tǒng)

Hopsworks特征存儲(chǔ)庫(kù)是一個(gè)雙存儲(chǔ)系統(tǒng)，由高帶寬（低成本）離線存儲(chǔ)和低延遲在線存儲(chǔ)組成。離線存儲(chǔ)是我們 HopsFS 文件系統(tǒng)上的 Apache Hudi 表（由 S3 或 Azure Blob 存儲(chǔ)支持）和外部表（例如 Snowflake、Redshift 等），提供對(duì)大量特征數(shù)據(jù)的訪問(wèn)以用于訓(xùn)練或批量評(píng)分。相比在線存儲(chǔ)是一個(gè)低延遲的鍵值數(shù)據(jù)庫(kù)，它只存儲(chǔ)每個(gè)特征的最新值及其主鍵。因此在線特征存儲(chǔ)充當(dāng)這些特征值的低延遲緩存。

為了使該系統(tǒng)對(duì)數(shù)據(jù)科學(xué)家有價(jià)值并縮短生產(chǎn)時(shí)間，并為最終用戶提供良好的體驗(yàn)，它需要滿足一些要求：

?用于訓(xùn)練和服務(wù)的一致特征：在 ML 中，為生產(chǎn)中的特征復(fù)制精確的特征工程邏輯非常重要，因?yàn)樗糜谏赡Ｐ陀?xùn)練的特征。?特征新鮮度：低延遲、高吞吐量的在線特征存儲(chǔ)只有在存儲(chǔ)在其中的數(shù)據(jù)保持最新時(shí)才有益，特征新鮮度被定義為觸發(fā)特征重新計(jì)算的事件到達(dá)與重新計(jì)算的特征在在線特征庫(kù)中發(fā)布之間的端到端延遲。?延遲：在線特征庫(kù)必須提供近乎實(shí)時(shí)的低延遲和高吞吐量，以便應(yīng)用程序能夠使用盡可能多的特征及其可用的SLA。?可訪問(wèn)性：數(shù)據(jù)需要可通過(guò)直觀的 API 訪問(wèn)，就像從離線特征存儲(chǔ)中提取數(shù)據(jù)進(jìn)行訓(xùn)練一樣容易。

Hopsworks在線特征庫(kù)圍繞四大支柱構(gòu)建，以滿足需求，同時(shí)擴(kuò)展以管理大量數(shù)據(jù)：

?HSFS API：Hopsworks 特征存儲(chǔ)庫(kù)是開(kāi)發(fā)人員特征存儲(chǔ)的主要入口點(diǎn)，可用于 Python 和 Scala/Java。HSFS 將兩個(gè)存儲(chǔ)系統(tǒng)抽象出來(lái)，提供透明的 Dataframe API（Spark、Spark Structured Streaming、Pandas）用于在線和離線存儲(chǔ)的寫(xiě)入和讀取。?元數(shù)據(jù)：Hopsworks 可以存儲(chǔ)大量自定義元數(shù)據(jù)，以便數(shù)據(jù)科學(xué)家發(fā)現(xiàn)、管理和復(fù)用特征，而且還能夠在將模型移至生產(chǎn)時(shí)依賴模式和數(shù)據(jù)質(zhì)量。?引擎：在線特征存儲(chǔ)帶有可擴(kuò)展的無(wú)狀態(tài)服務(wù)，可確保數(shù)據(jù)盡快寫(xiě)入在線特征存儲(chǔ)，而不會(huì)從數(shù)據(jù)流（Spark 結(jié)構(gòu)化流）或靜態(tài) Spark 或 Pandas DataFrame中進(jìn)行寫(xiě)入放大，即不必在攝取特征之前先將特征物化到存儲(chǔ)中 - 可以直接寫(xiě)入特征存儲(chǔ)。?RonDB：在線存儲(chǔ)背后的數(shù)據(jù)庫(kù)是世界上最快的具有 SQL 功能的鍵值存儲(chǔ)^[1]。不僅為在線特征數(shù)據(jù)構(gòu)建基礎(chǔ)，而且還處理 Hopsworks 中生成的所有元數(shù)據(jù)。

我們將在以下部分詳細(xì)介紹其中的每一部分，并提供一些用于定量比較的基準(zhǔn)。

3. RonDB：在線特征存儲(chǔ)，文件系統(tǒng)和元數(shù)據(jù)的基礎(chǔ)

Hopsworks 是圍繞分布式橫向擴(kuò)展元數(shù)據(jù)從頭開(kāi)始構(gòu)建的。這有助于確保 Hopsworks 內(nèi)服務(wù)的一致性和可擴(kuò)展性，以及數(shù)據(jù)和 ML 工件的注釋和可發(fā)現(xiàn)性。

自第一次發(fā)布以來(lái)，Hopsworks 一直使用 NDB Cluster（RonDB 的前身）作為在線特征存儲(chǔ)。2020 年我們創(chuàng)建了 RonDB 作為 NDB Cluster 的托管版本，并針對(duì)用作在線特征存儲(chǔ)進(jìn)行了優(yōu)化。

但是在 Hopsworks 中我們將 RonDB 用于不僅僅是在線特征存儲(chǔ)。RonDB 還存儲(chǔ)整個(gè)特征存儲(chǔ)庫(kù)的元數(shù)據(jù)，包括模式、統(tǒng)計(jì)信息和提交。RonDB 還存儲(chǔ)了文件系統(tǒng) HopsFS 的元數(shù)據(jù)，其中存儲(chǔ)了離線 Hudi 表，具體實(shí)踐可參考 如何將Apache Hudi應(yīng)用于機(jī)器學(xué)習(xí)。使用 RonDB 作為單個(gè)元數(shù)據(jù)數(shù)據(jù)庫(kù)，我們使用事務(wù)和外鍵來(lái)保持 Feature Store 和 Hudi 元數(shù)據(jù)與目標(biāo)文件和目錄（inode）一致。Hopsworks 可通過(guò) REST API 或直觀的 UI（包括特征目錄）訪問(wèn)或通過(guò) Hopsworks 特征存儲(chǔ) API (HSFS) 以編程方式訪問(wèn)。

4. OnlineFS：可擴(kuò)展的在線特征物化引擎

有了底層的 RonDB 和所需的元數(shù)據(jù)，我們就能夠構(gòu)建一個(gè)橫向擴(kuò)展、高吞吐量的物化服務(wù)，以在在線特征存儲(chǔ)上執(zhí)行更新、刪除和寫(xiě)入——我們簡(jiǎn)單地將其命名為 OnlineFS。

OnlineFS 是一種使用 ClusterJ 直接訪問(wèn) RonDB 數(shù)據(jù)節(jié)點(diǎn)的無(wú)狀態(tài)服務(wù)。ClusterJ 被實(shí)現(xiàn)為原生 C++ NDB API 之上的高性能 JNI 層，提供低延遲和高吞吐量。由于 RonDB 中元數(shù)據(jù)的可用性，例如 avro 模式和特征類型，我們能夠使 OnlineFS 無(wú)狀態(tài)。使服務(wù)無(wú)狀態(tài)允許我們通過(guò)簡(jiǎn)單地添加或刪除服務(wù)的實(shí)例來(lái)向上和向下擴(kuò)展對(duì)在線特征存儲(chǔ)的寫(xiě)入，從而隨著實(shí)例的數(shù)量線性地增加或減少吞吐量。

讓我們完成將數(shù)據(jù)寫(xiě)入在線特征存儲(chǔ)所需的步驟，這些步驟在下圖中編號(hào)。

1.特征作為 Pandas 或 Spark DataFrame寫(xiě)入特征存儲(chǔ)

每個(gè) Dataframe 更新一個(gè)稱為特征組的表（離線存儲(chǔ)中有一個(gè)類似的表）。一個(gè)特征組中的特征共享同一個(gè)主鍵，可以是復(fù)合主鍵。主鍵與元數(shù)據(jù)的其余部分一起被跟蹤。因此Hopsworks 特征存儲(chǔ)庫(kù)有一個(gè) Dataframe API，這意味著特征工程的結(jié)果應(yīng)該是將寫(xiě)入到特征存儲(chǔ)的常規(guī) Spark、Spark Structured Streaming 或 Pandas Dataframe。對(duì)于所有三種類型的DataFrame，用于寫(xiě)入特征存儲(chǔ)的 API 幾乎相同。通過(guò)對(duì)特征組對(duì)象的引用可以插入DataFrame。特征組在創(chuàng)建時(shí)已配置為將 Dataframe 存儲(chǔ)到在線和離線庫(kù)或僅存儲(chǔ)到其中之一。

2.編碼和產(chǎn)生

Dataframe 的行使用 avro 進(jìn)行編碼并寫(xiě)入在 Hopsworks 上運(yùn)行的 Kafka中。每個(gè)特性組都有自己的 Kafka 主題，具有可配置的分區(qū)數(shù)量，并按主鍵進(jìn)行分區(qū)，這是保證寫(xiě)入順序所必需的。

3.消費(fèi)和解碼

我們使用 Kafka 來(lái)緩沖來(lái)自 Spark 特征工程作業(yè)的寫(xiě)入，因?yàn)橹苯訉?xiě)入 RonDB 的大型 Spark 集群可能會(huì)使 RonDB 過(guò)載，因?yàn)楝F(xiàn)有 Spark JDBC 驅(qū)動(dòng)程序中缺乏背壓。OnlineFS 從 Kafka 讀取緩沖的消息并對(duì)其進(jìn)行解碼。重要的是OnlineFS 僅解碼原始特征類型，而嵌入等復(fù)雜特征以二進(jìn)制格式存儲(chǔ)在在線特征存儲(chǔ)中。

4.基于主鍵的Upsert

OnlineFS 可以使用 ClusterJ API 將行實(shí)際更新插入到 RonDB。Upsert 分批執(zhí)行（具有可配置的批量大小）以提高吞吐量。

由于管道步驟中的所有服務(wù)都可以訪問(wèn)相同的元數(shù)據(jù)，因此我們能夠向用戶隱藏與編碼和模式相關(guān)的所有復(fù)雜性。此外所有涉及的服務(wù)都是水平可擴(kuò)展的（Spark、Kafka、OnlineFS），并且由于我們類似于流的設(shè)置，該過(guò)程不會(huì)創(chuàng)建不必要的數(shù)據(jù)副本，即沒(méi)有寫(xiě)放大。由于模式注冊(cè)表、X.509 證書(shū)管理器和 Hopsworks 中的 Kafka 等服務(wù)的可用性，這種高度可擴(kuò)展的設(shè)置成為可能。在任何時(shí)候X.509 證書(shū)都用于雙向身份驗(yàn)證，而 TLS 用于加密網(wǎng)絡(luò)流量。

5. 可訪問(wèn)性意味著透明的 API

在分布式系統(tǒng)中，我們經(jīng)常談?wù)撏该鞫取Ｈ绻植际较到y(tǒng)對(duì)開(kāi)發(fā)人員隱藏網(wǎng)絡(luò)訪問(wèn)和實(shí)現(xiàn)特定知識(shí)，則它是透明的。在 Hopsworks 特征存儲(chǔ)庫(kù)中，寫(xiě)入是通過(guò)相同的 API 透明地完成的，如前所述（1）無(wú)論是常規(guī)的 Spark、Spark Streaming 還是 Pandas 以及（2）系統(tǒng)負(fù)責(zé)一致地更新在線和離線存儲(chǔ)

插入

HSFS 庫(kù)中的核心抽象是表示特征組、訓(xùn)練數(shù)據(jù)集和特征存儲(chǔ)中的特征的元數(shù)據(jù)對(duì)象。我們使用 HSFS 的目標(biāo)是讓開(kāi)發(fā)人員能夠使用他們喜歡的語(yǔ)言和框架來(lái)設(shè)計(jì)功能。當(dāng)我們?cè)?Dataframe API 上對(duì)齊時(shí)，Dataframe 中包含的任何內(nèi)容都可以寫(xiě)入特征存儲(chǔ)。如果您有現(xiàn)有的 ETL 或 ELT 管道，它們生成包含特征的數(shù)據(jù)幀，您可以通過(guò)簡(jiǎn)單地獲取對(duì)其特征組對(duì)象的引用并使用您的數(shù)據(jù)幀作為參數(shù)調(diào)用 .insert() 來(lái)將該數(shù)據(jù)幀寫(xiě)入特征存儲(chǔ) . 這可以從定期安排的作業(yè)中調(diào)用（使用您選擇的任何編排器，或者，如果您想要開(kāi)箱即用的編排器，則 Hopsworks 附帶 Airflow）。但是也可以通過(guò)將批次寫(xiě)入 Spark 結(jié)構(gòu)化流應(yīng)用程序中的數(shù)據(jù)幀來(lái)連續(xù)更新特征組對(duì)象。

# populate feature group metadata objectstore_fg_meta = fs.create_feature_group(name="store_fg",    version=1,    primary_key=["store"],    description="Store related features",    online_enabled=True)# create feature group for the first time in feature storefg.save(Dataframe)# replace .save with .insert for scheduled batch jobfg.insert(Dataframe)# if required, stream data only to the online feature store in long running Spark# Structured Streaming applicationfg.insert_stream(streaming_Dataframe)

讀取

許多現(xiàn)有的特征存儲(chǔ)沒(méi)有模型的表示。然而Hopsworks 引入了訓(xùn)練數(shù)據(jù)集抽象來(lái)表示用于訓(xùn)練模型的特征集和特征值。也就是說(shuō)，不可變的訓(xùn)練數(shù)據(jù)集和模型之間存在一對(duì)一的映射關(guān)系，但可變特征組與不可變的訓(xùn)練數(shù)據(jù)集之間是一對(duì)多的關(guān)系。您可以通過(guò)從特征組中加入、選擇和過(guò)濾特征來(lái)創(chuàng)建訓(xùn)練數(shù)據(jù)集。訓(xùn)練數(shù)據(jù)集包括特征的元數(shù)據(jù)，例如它們來(lái)自哪個(gè)特征組、該特征組的提交 ID 以及訓(xùn)練數(shù)據(jù)集中特征的順序。所有這些信息使 HSFS 能夠在稍后的時(shí)間點(diǎn)重新創(chuàng)建訓(xùn)練數(shù)據(jù)集，并在服務(wù)時(shí)透明地構(gòu)建特征向量。

# create a queryfeature_join = rain_fg.select_all() \                        .join(temperature_fg.select_all(), on=["location_id"]) \                        .join(location_fg.select_all())td = fs.create_training_dataset("rain_dataset",                        version=1,                        label=”weekly_rain”,                        data_format=”tfrecords”)# materialize query in the specified file formattd.save(feature_join)# we can also use the training dataset for serving# this serving code typically runs in a Python environmenttd = fs.get_training_dataset(“rain_dataset”, version=1)# get serving vectortd.get_serving_vector({“location_id”: “honolulu”})

在線特征庫(kù)的使用方要么是使用 ML 模型的應(yīng)用程序，要么是模型服務(wù)基礎(chǔ)設(shè)施，這些基礎(chǔ)設(shè)施通過(guò)缺失的特征來(lái)豐富特征向量。Hopsworks 為在線庫(kù)提供了一個(gè)基于 JDBC 的 API。JDBC 具有提供高性能協(xié)議、網(wǎng)絡(luò)加密、客戶端身份驗(yàn)證和訪問(wèn)控制的優(yōu)勢(shì)。HSFS 為 Python 和 Scala/Java 提供語(yǔ)言級(jí)別的支持。但是，如果您的服務(wù)應(yīng)用程序在不同的編程語(yǔ)言或框架中運(yùn)行，您總是可以直接使用 JDBC。

6. Benchmarks

Mikael Ronstrom（NDB 集群的發(fā)明者和邏輯時(shí)鐘的數(shù)據(jù)負(fù)責(zé)人，領(lǐng)導(dǎo) RonDB 團(tuán)隊(duì)）為 RonDB 提供了 sysbench 基準(zhǔn)測(cè)試，并提供了針對(duì) Redis 的比較性能評(píng)估。在本節(jié)中我們展示了 OnlineFS 服務(wù)的性能，能夠處理和維持寫(xiě)入在線特征存儲(chǔ)的高吞吐量，以及對(duì) Hopsworks 中典型托管 RonDB 設(shè)置的特征向量查找延遲和吞吐量的評(píng)估。

在此基準(zhǔn)測(cè)試中，Hopsworks 設(shè)置了 3xAWS m5.2xlarge（8 個(gè) vCPU，32 GB）實(shí)例（1 個(gè)頭，2 個(gè)工作器）。Spark 使用 worker 將數(shù)據(jù)幀寫(xiě)入在線庫(kù)。此外相同的工作人員被重新用作客戶端，在在線特征存儲(chǔ)上執(zhí)行讀取操作以進(jìn)行讀取基準(zhǔn)測(cè)試。

RonDB 設(shè)置了 1x AWS t3.medium（2 vCPU，4 GB）實(shí)例作為管理節(jié)點(diǎn)，2x r5.2xlarge（8 vCPU，64 GB）實(shí)例作為數(shù)據(jù)節(jié)點(diǎn)，3x AWS c5.2xlarge（8 vCPU，16 GB） ) MySQL 服務(wù)器的實(shí)例。這種設(shè)置允許我們?cè)诰哂?2 倍復(fù)制的在線特征存儲(chǔ)中存儲(chǔ) 64GB 的內(nèi)存數(shù)據(jù)。MySQL 服務(wù)器為在線特征存儲(chǔ)提供 SQL 接口，在此基準(zhǔn)測(cè)試中，我們沒(méi)有使 RonDB 數(shù)據(jù)節(jié)點(diǎn)完全飽和，因此可以潛在地添加更多 MySQL 服務(wù)器和客戶端，以增加超出此處所示水平的吞吐量。

寫(xiě)吞吐

我們對(duì) OnlineFS 服務(wù)中寫(xiě)入 RonDB 的吞吐量進(jìn)行了基準(zhǔn)測(cè)試。此外，我們測(cè)量了從 Kafka 主題中獲取記錄到提交到 RonDB 之間處理記錄所需的時(shí)間。對(duì)于這個(gè)基準(zhǔn)測(cè)試，我們部署了兩個(gè) OnlineFS 服務(wù)，一個(gè)在頭節(jié)點(diǎn)上，一個(gè)在 MySQL 服務(wù)器節(jié)點(diǎn)之一上。

我們通過(guò)將 20M 行從 Spark 應(yīng)用程序?qū)懭朐诰€特征存儲(chǔ)來(lái)運(yùn)行實(shí)驗(yàn)。經(jīng)過(guò)短暫的預(yù)熱期后，兩個(gè)服務(wù)實(shí)例的吞吐量穩(wěn)定在約 126K 行/秒（11 個(gè)特征）、約 90K 行/秒（51 個(gè)特征）和最大特征向量約 60K 行/秒。由于其設(shè)計(jì)，這可以通過(guò)添加更多服務(wù)實(shí)例輕松擴(kuò)展。

其次，我們輸出了在 OnlineFS 服務(wù)中處理特征向量所需的時(shí)間。這個(gè)時(shí)間不包括一條記錄在 Kafka 中等待處理的時(shí)間，原因是等待時(shí)間在很大程度上取決于寫(xiě)入 Kafka 的 Spark 執(zhí)行程序的數(shù)量。

處理時(shí)間是按行報(bào)告的，但 OnlineFS 中的部分管道是并行化的，例如，行以 1000 的批次提交給 RonDB。通過(guò)這種設(shè)置，我們實(shí)現(xiàn)了 11 個(gè)特征的 p99 約為 250 毫秒，行大小為 948 字節(jié)。

服務(wù)查找吞吐量和延遲

我們對(duì)與越來(lái)越多的并行執(zhí)行請(qǐng)求的客戶端相關(guān)的不同特征向量大小的吞吐量和延遲進(jìn)行了基準(zhǔn)測(cè)試。請(qǐng)注意，客戶端被分成兩個(gè)工作節(jié)點(diǎn)（每個(gè) 8vCPU）。

每個(gè)請(qǐng)求的單個(gè)向量

在這個(gè)基準(zhǔn)測(cè)試中，每個(gè)請(qǐng)求都包含一個(gè)主鍵值查找（一個(gè)特征向量）。吞吐量和延遲可線性擴(kuò)展至 16 個(gè)客戶端，同時(shí)保持低延遲。對(duì)于超過(guò) 16 個(gè)客戶端，我們觀察到運(yùn)行客戶端的主機(jī)達(dá)到其最大 CPU 和網(wǎng)絡(luò)利用率。此外，我們沒(méi)有看到 RonDB 數(shù)據(jù)節(jié)點(diǎn)或 MySQL 服務(wù)器的過(guò)度使用，這意味著我們可以通過(guò)從更大的工作實(shí)例運(yùn)行客戶端或添加更多工作主機(jī)來(lái)運(yùn)行客戶端來(lái)進(jìn)一步線性擴(kuò)展。

批處理，每個(gè)請(qǐng)求 100 個(gè)向量

為了證明 RonDB 每秒可擴(kuò)展到更多的關(guān)鍵查找，我們運(yùn)行了另一個(gè)基準(zhǔn)測(cè)試，其中每個(gè)客戶端以 100 個(gè)批次請(qǐng)求特征向量。正如我們所看到的查找數(shù)量仍然線性擴(kuò)展，查找吞吐量增加了 15 倍，而 每個(gè)請(qǐng)求的延遲僅適度增加。

7. 結(jié)論

Hopsworks 附帶托管 RonDB，為 Hopsworks 和在線特征提供統(tǒng)一的元數(shù)據(jù)存儲(chǔ)。在這篇博客中，我們展示了一個(gè)高度可用的雙節(jié)點(diǎn) RonDB 集群（r5.2xlarge VM）線性擴(kuò)展到 >250k ops/sec，特征向量查找的 11 個(gè)特征的大小約為 1KB，p99 延遲為 7.5 毫秒。因此Hopsworks 提供了當(dāng)今市場(chǎng)上性能最高的在線特征庫(kù)。

引用鏈接

[1] 世界上最快的具有 SQL 功能的鍵值存儲(chǔ): https://www.logicalclocks.com/blog/rondb-the-worlds-fastest-key-value-store-is-now-in-the-cloud