【TensorFlow】01 TensorFlow簡介與Python基礎(chǔ)
853
2025-03-31
【王喆-推薦系統(tǒng)】線上服務(wù)篇-(task2)用Redis存儲(chǔ)特征
學(xué)習(xí)總結(jié)
本次task學(xué)習(xí)推薦系統(tǒng)的存儲(chǔ)模塊（遵循“分級存儲(chǔ)”原則，在開銷和性能中平衡；具體而言：把越頻繁訪問的數(shù)據(jù)放到越快的數(shù)據(jù)庫甚至緩存中，把海量的全量數(shù)據(jù)放到廉價(jià)但是查詢速度較慢的數(shù)據(jù)庫中）和對Sparrow Recsys中的redis實(shí)踐。其實(shí)和計(jì)算機(jī)的存儲(chǔ)設(shè)備一樣（分為寄存器、Cache、內(nèi)存、SSD等金字塔形）。我們麻雀推薦系統(tǒng)的存儲(chǔ)結(jié)構(gòu)如下：
使用內(nèi)存數(shù)據(jù)庫redis（兩大特點(diǎn)：key-value形式存儲(chǔ)；純內(nèi)存數(shù)據(jù)庫）。在具體的特征存取過程中，要熟悉利用 redis 執(zhí)行 SET，GET 等 Redis 常用操作的方法。
搭建一套完整的推薦服務(wù)，有3個(gè)大問題：用 Jetty Server 搭建推薦服務(wù)器問題、用 Redis 解決特征存儲(chǔ)的問題，還有下個(gè)task的線上服務(wù)召回層的設(shè)計(jì)。
文章目錄
學(xué)習(xí)總結(jié)
一、推薦系統(tǒng)的存儲(chǔ)模塊
二、SparrowRecsys 的存儲(chǔ)系統(tǒng)
三、Redis 基礎(chǔ)知識
3.1 所有的數(shù)據(jù)都以 Key-value 的形式存儲(chǔ)。
3.2 所有的數(shù)據(jù)都存儲(chǔ)在內(nèi)存中
四、Sparrow Recsys中的Redis實(shí)踐
4.1 安裝 Redis
4.2 運(yùn)行離線程序，通過 jedis 客戶端寫入 Redis
4.3 在推薦服務(wù)器中把 Redis 數(shù)據(jù)讀取出來
五、數(shù)據(jù)庫分類
5.1 SQL
5.2 NoSQL
（1）基于文檔（基于查詢的數(shù)據(jù)）
（2）圖形存儲(chǔ)
（3）Key-value 存儲(chǔ)
（4）柱狀數(shù)據(jù)庫（不斷增加的數(shù)據(jù)）
六、作業(yè)
七、課后答疑
Reference
一、推薦系統(tǒng)的存儲(chǔ)模塊
大數(shù)據(jù)平臺(tái)的數(shù)據(jù)處理是離線的，而上次task我們搭建Jetty推薦服務(wù)器是線上環(huán)境，本次task的內(nèi)容是讓離線的特征數(shù)據(jù)導(dǎo)入到線上供服務(wù)器使用，所使用的redis數(shù)據(jù)庫存儲(chǔ)特征。
Netflix 采用了非常經(jīng)典的 Offline、Nearline、Online 三層推薦系統(tǒng)架構(gòu)。架構(gòu)圖中最核心的位置就是在圖中用紅框標(biāo)出的部分，它們是三個(gè)數(shù)據(jù)庫 Cassandra、MySQL 和 EVcache，用來存儲(chǔ)特征和模型參數(shù)。
并非簡單的將推薦特征和模型用數(shù)據(jù)庫存儲(chǔ)起來，然后給推薦服務(wù)器寫幾個(gè)SQL讓它取出數(shù)據(jù)就可以。之所以Netflix搞這三個(gè)數(shù)據(jù)庫是因?yàn)椋?/p>
（1）速度要快：由于線上的 QPS 壓力巨大，每次有推薦請求到來，推薦服務(wù)器都需要把相關(guān)的特征取出。這就要求推薦服務(wù)器一定要“快”。
（2）數(shù)據(jù)很大：多用戶和物品特征所需的存儲(chǔ)量。
幾乎所有的工業(yè)級推薦系統(tǒng)都會(huì)把特征的存儲(chǔ)做成
分級存儲(chǔ)
，把越頻繁訪問的數(shù)據(jù)放到越快的數(shù)據(jù)庫甚至緩存中，把海量的全量數(shù)據(jù)放到便宜但是查詢速度較慢的數(shù)據(jù)庫中。
舉栗子：如果你把特征數(shù)據(jù)放到基于 HDFS 的 HBase 中，雖然你可以輕松放下所有的特征數(shù)據(jù)，但要讓你的推薦服務(wù)器直接訪問 HBase 進(jìn)行特征查詢，等到查詢完成，這邊用戶的請求早就超時(shí)中斷了，而 Netflix 的三個(gè)數(shù)據(jù)庫正好滿足了這樣分級存儲(chǔ)的需求。
比如說，Netflix 使用的 Cassandra，它作為流行的 NoSQL 數(shù)據(jù)庫，具備大數(shù)據(jù)存儲(chǔ)的能力，
（1）但為支持推薦服務(wù)器高 QPS 的需求，還需要把最常用的特征和模型參數(shù)存入 EVcache 這類內(nèi)存數(shù)據(jù)庫。
（2）而對于更常用的數(shù)據(jù)，我們可以把它們存儲(chǔ)在 Guava Cache 等服務(wù)器內(nèi)部緩存，甚至是服務(wù)器的內(nèi)存中。
（3）而對于 MySQL 來說，由于它是一個(gè)強(qiáng)一致性的關(guān)系型數(shù)據(jù)庫，一般存儲(chǔ)的是
比較關(guān)鍵的要求強(qiáng)一致性的信息
，比如物品是否可以被推薦這種控制類的信息，物品分類的層級關(guān)系，用戶的注冊信息等等。這類信息一般是由推薦服務(wù)器進(jìn)行階段性的拉取，或者利用分級緩存進(jìn)行階段性的更新，避免因?yàn)檫^于頻繁的訪問壓垮 MySQL。
強(qiáng)一致性：可以理解為在任意時(shí)刻，所有節(jié)點(diǎn)中的數(shù)據(jù)是一樣的 弱一致性：相當(dāng)于異步，系統(tǒng)并不保證續(xù)進(jìn)程或者線程的訪問都會(huì)返回最新的更新過的值
推薦系統(tǒng)存儲(chǔ)模塊的設(shè)計(jì)原則：“分級存儲(chǔ)，把越頻繁訪問的數(shù)據(jù)放到越快的數(shù)據(jù)庫甚至緩存中，把海量的全量數(shù)據(jù)放到廉價(jià)但是查詢速度較慢的數(shù)據(jù)庫中”。
二、SparrowRecsys 的存儲(chǔ)系統(tǒng)
麻雀推薦系統(tǒng)的存儲(chǔ)模塊：使用基礎(chǔ)的文件系統(tǒng)保存全量的離線特征和模型數(shù)據(jù)，用 Redis 保存線上所需特征和模型數(shù)據(jù)，使用服務(wù)器內(nèi)存緩存頻繁訪問的特征。
在實(shí)現(xiàn)技術(shù)方案之前，對于問題的整體分析永遠(yuǎn)都是重要的。我們需要先確定具體的存儲(chǔ)方案，這個(gè)方案必須
精確到哪級存儲(chǔ)對應(yīng)哪些具體特征和模型數(shù)據(jù)
。
根據(jù)上面的特征數(shù)據(jù)，做一個(gè)初步的分析：
首先，用戶特征的總數(shù)比較大，它們很難全部載入到服務(wù)器內(nèi)存中，所以把用戶特征載入到 Redis 之類的內(nèi)存數(shù)據(jù)庫中。
其次，物品特征的總數(shù)比較小，而且每次用戶請求，一般只會(huì)用到一個(gè)用戶的特征，但為了物品排序，推薦服務(wù)器需要訪問幾乎所有候選物品的特征。所以可以把所有物品特征階段性地載入到服務(wù)器內(nèi)存中，大大減少 Redis 的線上壓力。
最后，我們還要找一個(gè)地方去存儲(chǔ)特征歷史數(shù)據(jù)、樣本數(shù)據(jù)等體量比較大，但
不要求實(shí)時(shí)獲取
的數(shù)據(jù)。可以放到分布式文件系統(tǒng)（單機(jī)環(huán)境下以本機(jī)文件系統(tǒng)為例）——因?yàn)轭愃?HDFS 之類的分布式文件系統(tǒng)具有近乎無限的存儲(chǔ)空間，因此可以
把每次處理的全量特征，每次訓(xùn)練的 Embedding 全部保存到分布式文件系統(tǒng)中，方便離線評估時(shí)使用
。
文件系統(tǒng)的存儲(chǔ)操作較為簡單，在 SparrowRecsys 中就是利用 Spark 的輸出功能實(shí)現(xiàn)的。而服務(wù)器（如我們上次task搭的Jetty服務(wù)器）內(nèi)部的存儲(chǔ)操作主要是跟 Redis 進(jìn)行交互，下面學(xué)習(xí)Redis 的特性以及寫入和讀取方法。
三、Redis 基礎(chǔ)知識
Redis 是當(dāng)今業(yè)界最主流的內(nèi)存數(shù)據(jù)庫。
3.1 所有的數(shù)據(jù)都以 Key-value 的形式存儲(chǔ)。
Key 只能是字符串，value 可支持的數(shù)據(jù)結(jié)構(gòu)包括 string(字符串)、list(鏈表)、set(集合)、zset(有序集合) 和 hash(哈希)。這個(gè)特點(diǎn)決定了 Redis 的使用方式，無論是存儲(chǔ)還是獲取，都應(yīng)該以鍵值對的形式進(jìn)行，并且
根據(jù)你的數(shù)據(jù)特點(diǎn)，設(shè)計(jì)值的數(shù)據(jù)結(jié)構(gòu)
。
3.2 所有的數(shù)據(jù)都存儲(chǔ)在內(nèi)存中
磁盤只在持久化備份或恢復(fù)數(shù)據(jù)時(shí)起作用。
這個(gè)特點(diǎn)決定了 Redis 的特性：一是 QPS 峰值可以很高，二是數(shù)據(jù)易丟失，所以我們在維護(hù) Redis 時(shí)要充分考慮數(shù)據(jù)的備份問題，或者說，不應(yīng)該把關(guān)鍵的業(yè)務(wù)數(shù)據(jù)唯一地放到 Redis 中。但對于可恢復(fù)，不關(guān)乎關(guān)鍵業(yè)務(wù)邏輯的推薦特征數(shù)據(jù)，就非常適合利用 Redis 提供高效的存儲(chǔ)和查詢服務(wù)。
QPS：每秒查詢率QPS是對一個(gè)特定的查詢服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)，在因特網(wǎng)上，作為域名系統(tǒng)服務(wù)器的機(jī)器的性能經(jīng)常用每秒查詢率來衡量。
四、Sparrow Recsys中的Redis實(shí)踐
在實(shí)際的 Sparrow Recsys 的 Redis 部分中，用到了 Redis 最基本的操作，set、get 和 keys，value 的數(shù)據(jù)類型用到了 string。
4.1 安裝 Redis
Redis 的安裝過程在 linux/Unix 環(huán)境下安裝參考：（http://www.redis.cn/download.html）。
Windows 環(huán)境下的安裝：（https://www.cnblogs.com/liuqingzheng/p/9831331.html）。
在啟動(dòng) Redis 之后，如果沒有特殊的設(shè)置，Redis 服務(wù)會(huì)默認(rèn)運(yùn)行在 6379 端口，沒有特殊情況保留這個(gè)默認(rèn)的設(shè)置就可以了，Sparrow RecSys 也是默認(rèn)從 6379 端口存儲(chǔ)和讀取 Redis 數(shù)據(jù)的。
下圖即安裝好redis后，在命令行中進(jìn)入redis的目錄，然后啟動(dòng)對應(yīng)的redis客戶端程序，顯示正確端口號，表示服務(wù)已經(jīng)啟動(dòng)。然后可以測試一下讀寫：
4.2 運(yùn)行離線程序，通過 jedis 客戶端寫入 Redis
在 Redis 運(yùn)行起來之后，我們就可以在離線 Spark 環(huán)境下把特征數(shù)據(jù)寫入 Redis。這里以（【王喆-深度學(xué)習(xí)推薦系統(tǒng)實(shí)戰(zhàn)】特征工程篇-(task5)Embedding實(shí)踐）中生成的 Embedding 數(shù)據(jù)為例，來實(shí)現(xiàn) Redis 的特征存儲(chǔ)過程。
實(shí)際的過程：
（1）首先利用最常用的 Redis Java 客戶端 Jedis 生成 redisClient；
（2）然后遍歷訓(xùn)練好的 Embedding 向量；
（3）將 Embedding 向量以字符串的形式存入 Redis，并設(shè)置過期時(shí)間（ttl）。
具體實(shí)現(xiàn)請參考下面的代碼（代碼參考 com.wzhe.sparrowrecsys.offline.spark.featureeng.Embedding 中的 trainItem2vec 函數(shù)）：
if (saveToRedis) { //創(chuàng)建redis client val redisClient = new Jedis(redisEndpoint, redisPort) val params = SetParams.setParams() //設(shè)置ttl為24小時(shí) params.ex(60 * 60 * 24) //遍歷存儲(chǔ)embedding向量 for (movieId <- model.getVectors.keys) { //key的形式為前綴+movieId，例如i2vEmb:361 //value的形式是由Embedding向量生成的字符串，例如 "0.1693846 0.2964318 -0.13044095 0.37574086 0.55175656 0.03217995 1.327348 -0.81346786 0.45146862 0.49406642" redisClient.set(redisKeyPrefix + ":" + movieId, model.getVectors(movieId).mkString(" "), params) } //關(guān)閉客戶端連接 redisClient.close() }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
4.3 在推薦服務(wù)器中把 Redis 數(shù)據(jù)讀取出來
剛才的存儲(chǔ)方案說了，把所有物品 Embedding 階段性地全部緩存在服務(wù)器內(nèi)部，用戶 Embedding 則進(jìn)行實(shí)時(shí)查詢。緩存物品 Embedding 的代碼如下：
就是先用 keys 操作把所有物品 Embedding 前綴的鍵找出，然后依次將 Embedding 載入內(nèi)存。
//創(chuàng)建redis client Jedis redisClient = new Jedis(REDIS_END_POINT, REDIS_PORT); //查詢出所有以embKey為前綴的數(shù)據(jù) Set
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
在具體為用戶推薦的過程中，我們再利用相似的接口查詢出用戶的 Embedding，與內(nèi)存中的 Embedding 進(jìn)行相似度的計(jì)算，就可以得到最終的推薦列表了。
具體操作：
（1）安裝好 Redis；
（2）運(yùn)行 SparrowRecsys 中 Offline 部分 Embedding 主函數(shù)，先把物品和用戶 Embedding 生成并且插入 Redis（注意把 saveToRedis 變量改為 true）。
（3）然后再運(yùn)行 Online 部分的 RecSysServer，看一下推薦服務(wù)器有沒有正確地從 Redis 中讀出物品和用戶 Embedding 并產(chǎn)生正確的推薦結(jié)果（注意，記得要把 util.Config 中的 EMB_DATA_SOURCE 配置改為 DATA_SOURCE_REDIS）。
五、數(shù)據(jù)庫分類
除了 Redis，還有多種不同的緩存和數(shù)據(jù)庫，如 Cassandra、EVcache、GuavaCache 等等，都是業(yè)界非常流行的存儲(chǔ)特征的工具。在掌握了特征存儲(chǔ)的基本原則之后，了解每個(gè)數(shù)據(jù)庫的不同和它們最合適的應(yīng)用場景。
取決于使用哪個(gè)數(shù)據(jù)庫的因素有：
數(shù)據(jù)結(jié)構(gòu)；查詢模式；需要處理的數(shù)量或規(guī)模。
5.1 SQL
結(jié)構(gòu)取決于我們用來確定將使用哪種類型的因素
如果需要ACID屬性，則需要使用關(guān)系DBMS。如MySQL，Oracle，Postgres等
付款系統(tǒng)主要需要交易和原子性。
強(qiáng)一致性主要可以通過SQL數(shù)據(jù)庫來實(shí)現(xiàn)。
5.2 NoSQL
假設(shè)正在嘗試為諸如Amazon之類的商品建立目錄，想在其中存儲(chǔ)有關(guān)
具有各種屬性的不同產(chǎn)品的信息
。例如，不同產(chǎn)品的這些屬性通常不同。藥品將有有效期，但冰箱將具有能量等級。
在這種情況下，我們的數(shù)據(jù)不能表示為表格。這意味著我們需要使用NoSQL數(shù)據(jù)庫。
如果需要BASE屬性，則可以使用非關(guān)系數(shù)據(jù)庫前進(jìn)。
對于最終一致性，我們可以使用NoSQL數(shù)據(jù)庫
最常見的NoSQL DB是MongoDB，Cassandra，DynamoDB.
（1）基于文檔（基于查詢的數(shù)據(jù)）
如果我們擁有大量數(shù)據(jù)-不僅是數(shù)量，而且還有各種各樣的屬性-并且我們需要運(yùn)行各種各樣的查詢，則需要使用一種稱為Document DB的東西。
使用文檔數(shù)據(jù)庫，隨機(jī)查詢或其他查詢最有效
Couchbase或MongoDB是一些常用的文檔數(shù)據(jù)庫
（2）圖形存儲(chǔ)
這些類型的數(shù)據(jù)庫使數(shù)據(jù)可視化更加容易。
它們非常善于在節(jié)點(diǎn)的幫助下存儲(chǔ)不同數(shù)據(jù)點(diǎn)之間的關(guān)系。
圖形存儲(chǔ)可能不是最可擴(kuò)展的數(shù)據(jù)庫。
但是，它們在防止欺詐等使用案例方面效率很高。
圖形數(shù)據(jù)庫的常見示例是Neo4j 和 JanusGraph。
（3）Key-value 存儲(chǔ)
這些都是非常簡單的數(shù)據(jù)庫管理系統(tǒng)，存儲(chǔ)關(guān)鍵值對。
最終目標(biāo)是
快速獲取基本數(shù)據(jù)
。
這些類型的數(shù)據(jù)庫的常見用例是排行榜和購物車數(shù)據(jù)。
redis是流行的key value 存儲(chǔ)。
（4）柱狀數(shù)據(jù)庫（不斷增加的數(shù)據(jù)）
有限的查詢種類，但是數(shù)據(jù)庫的大小持續(xù)快速增加。例如訂單，目錄
現(xiàn)在，Uber司機(jī)的數(shù)量將逐日增加，即每天收集的數(shù)據(jù)也會(huì)逐日增加。這成為越來越多的數(shù)據(jù)。
在這種情況下，我們使用諸如Cassandra或HBase之類的列式數(shù)據(jù)庫。
六、作業(yè)
課程中存儲(chǔ) Embedding 的方式還有優(yōu)化的空間嗎？除了 string，我們是不是還可以用其他 Redis value 的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ) Embedding 數(shù)據(jù)，那從效率的角度考慮，使用 string 和使用其他數(shù)據(jù)結(jié)構(gòu)的優(yōu)缺點(diǎn)有哪些？為什么？
（1）redis keys命令不能用在生產(chǎn)環(huán)境中，如果數(shù)量過大效率十分低，導(dǎo)致redis長時(shí)間堵塞在keys上。生產(chǎn)環(huán)境我們一般選擇提前載入一些warm up物品id的方式載入物品embedding。
（2）Redis value 可以用pb格式（protobuf）存儲(chǔ), 存儲(chǔ)上節(jié)省空間. 解析起來相比string, cpu的效率也應(yīng)該會(huì)更高
（3）1.redis這種緩存中盡量放活躍的數(shù)據(jù)，存放全量的embedding數(shù)據(jù)，對內(nèi)存消耗太大。尤其物品庫，用戶embedding特別多的情況下。
2.分布式kv可以做這種embedding的存儲(chǔ)
3.關(guān)于embedding的編碼可以用pb來解決。embedding維度太大的時(shí)候，redis里的數(shù)據(jù)結(jié)構(gòu)占用空間會(huì)變大，因?yàn)槌薳mbedding本身的空間，還有數(shù)據(jù)結(jié)構(gòu)本身占用的空間。
七、課后答疑
（1）文中的兩部分redis相關(guān)的代碼，可以在Maven項(xiàng)目中找到嗎？可不可以提供以下路徑信息方便找到？
參照 com.wzhe.sparrowrecsys.offline.spark.embedding.Embedding中的trainItem2vec函數(shù)
以及com.wzhe.sparrowrecsys.online.datamanager.DataManager中的loadMovieEmb函數(shù)
（2）在IntelliJ的Maven porject里用到的工具比如spark， redis， 這些需要我們額外下載安裝到電腦上嗎？還是說在Maven項(xiàng)目中已經(jīng)通過代碼添加依賴，就已經(jīng)完成了安裝？
spark本質(zhì)上是一個(gè)java lib，所以可以被maven安裝依賴。
redis是一個(gè)數(shù)據(jù)庫，需要按照文中的方式安裝到電腦上。
Reference
（1）https://github.com/wzhe06/Reco-papers
（2）《深度學(xué)習(xí)推薦系統(tǒng)實(shí)戰(zhàn)》，王喆
（3）常見數(shù)據(jù)庫介紹和使用場景
Redis 推薦系統(tǒng)
版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。
版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。
相關(guān)文章