從數據庫底層說起，探究用戶畫像系統的儲存該如何選型

在給用戶畫像做定義之前，我們先來了解一下什么是推薦系統

場景：

在現在的互聯網時代，網上購物已經稱為常態，當我們在各大電商平臺購物的時候，不難發現這樣一個現象。當你搜索某個上面進行瀏覽的時候，點擊目標商品，之后返回到首頁，很大概率你就可以發現，你剛才搜索的商品的相關產品已經在首頁的推薦欄目。例如，你購買了一件護膚品面霜，回到首頁推薦處，系統可能就會給你推薦口紅或者相關護膚品。又例如當你搜索用戶畫像書籍的時候，推薦欄目就會出現有關用戶畫像的書籍。這些功能就叫做推薦，而完成這些行為的即為推薦系統。

本質：

推薦系統就是對用戶的瀏覽行為進行記錄分析，并基于這些行為對用戶將要購買的商品進行預測。老王購買了用戶畫像的書籍，那么老王便與這本書之間產生一個連接。小麗購買了護膚品，那么小麗便于這個護膚品之間產生了連接。而推薦系統就是根據一些算法去預測用戶與商品之間還未產生的連接。

來看一張簡單的用戶畫像表：

給用戶畫像下定義：

用戶畫像是對用戶的一種標注，通過給用戶打上標簽的形式來描述用戶

這個標簽可以是一個人的年齡，性別，收入情況，也可以是一個人的購物傾向或者是常居住地

總而言之我們能想到的用來描述一個人的各方面特征的都可以算作是畫像的范疇

畫像表相對比較稀疏，一般一個用戶畫像的項目至少有近百個標簽，而大部分用戶都應該只打上一部分呢標簽，所以總體來說畫像表應該較為稀疏

大部分標簽使用ID進行匹配查找，定位到用戶標簽再找到用戶群體

進行聚合統計的需求較多

需要數據庫可以按key查詢，聚合統計查詢，以及多條件組合查詢

稀疏表的儲存不應該占用太多空間資源

mysql這個數據庫大家應該都不陌生，這里我們從這個數據庫的底層結構開始說起，mysql底層所選用的數據結構為B+樹，說到B+樹這里就不得不提一下另一種數據結構B數

B樹介紹：

上圖是一個 B樹 的形式, 每個節點有兩個數據元素, 每個節點有三個子節點, 每個葉子節點有兩個數據元素

無論是什么形式的 B樹, 都具備以下定理, 這四個定理也是保證 B樹 插入和刪除能夠平衡的原因

根節點至少兩個子節點

每個中間節點都包含 m 個孩子, 每個中間節點都包含 m - 1 個數據元素

最底層的節點稱之為葉子節點, 所有葉子節點都位于同一層

所有節點中的數據元素按照大小排列, 所有子節點按照數據元素的大小排列, 父節點的數據元素恰好是子節點數據元素的值域劃分點

B樹插入規則：

如果當前節點未滿, 插入

如果當前節點已滿, 分裂節點, 中間大小的值提升, 直到插入根節點

如果根節點也已滿, 插入節點成為新的根節點, 層級 +1

B樹存在的問題：

因為 B樹 中所有節點都可攜帶數據元素, 所以導致性能不穩定

范圍查找效率太低

基于B樹存在的這些問題，B+樹出現了

B+樹：

B+樹的特性：

有 k 個子樹的中間節點, 就可以存放 K 個數據元素(比 B樹 多一個)

中間節點不保存數據, 只用來索引, 劃分子樹值域, 所有數據元素都以衛星的形式和葉子節點關聯

葉子節點本身按照 Key 有序

所有中間節點的元素都存在于子節點

B+數的優點：

單一節點存儲更多的元素, IO 次數變少

所有查詢都要查找到葉子節點, 看起來每次都是都是最差情況, 但是三層的 B+樹 可以存放一百萬條數據, 通常 B+樹 都很低很寬

所有葉子節點是形成有序鏈表, 范圍查詢性能極強

B+樹與MySql的關系：

聚集索引：

非聚集索引：

MySQL的索引類型：

在 MySQL 中, 有兩個引擎, 如下

MyISAM,引擎, 事務支持很差, 較少使用

InnoDB,引擎, 事務支持完備, 使用較廣泛

InnoDB 的特點

任何一張表的數據都自帶一個聚集索引

默認情況下, 建表必須有主鍵, 默認的聚集索引以主鍵為 Key

總的來說，無論是否聚集, MySQL 中的索引都是 B+樹 結構

MySQL特性總結：

根據 B+樹 的特性可以知道, 每次在插入的時候都比較復雜, 當數據量增多的時候, 性能衰減會非常明顯

B+樹 是查找樹, 其節點之間是有序的, 當需要搜索的時候, 時間復雜度和折半查找一樣, 只有 Log2N

B+樹 的葉子節點構成了一個類似鏈表的結構, 所以進行范圍查找的時候, 不需要回到父節點, 可以直接在子節點中進行, 所以在進行一些復雜查詢的時候比較方便范圍取數據

因為 MySQL 的主要目的是 OLTP, OLTP 更強調每次操作一條或者多條數據, 所以 MySQL 是行存儲的形式, 行存儲為了對齊所有的列, 即使某列為 Null, 也依然會有按照數據類型的占位

MySQL存在的問題：

插入性能會隨著樹的復雜度而遞減

數據多的話會導致樹變得很寬，這個時候插入數據就復雜度就變高了

隨著數據量不斷增加，樹從插入性能就下架了

HBase是一個高可靠、高性能、面向列、可伸縮的分布式數據庫，參考谷歌的BigTable后使用java語言進行了實現。也是Apache軟件基金會的Hadoop項目的一部分，可以運行運行在HDFS文件系統容錯地存儲海量稀疏的數據。

先來說說LSM-Tree

LSM-Tree全稱是Log Structured Merge Tree，是一種分層，有序，面向磁盤的數據結構，其核心思想是充分了利用了，磁盤批量的順序寫要遠比隨機寫性能高出很多。

如圖為LSM-Tree日志合并樹

當我們的log以這種格式寫入的時候，全部都是以Append的模式追加的，不存在刪除和修改，這種結構雖然大大提升了數據的寫入能力，但是以犧牲部分讀取性能為代價，索引這種結構通常適合于寫多讀少的場景。故LSM被設計來提供比傳統的B+樹或者ISAM更好的寫操作吞吐量。

Hbase與LSM-Tree

HBase 的一個表有多個 Region 分布在多個 RegionServer 上, 一個 RegionServer 有多個 Region

每個 Region 又分為 Memstore 和 DiskStore, 其實就是 LSM樹

HBase 的存儲結構是 Key-Value

雖然 HBase 對外提供的看起來好像一種表, 但其實在 Region 中, 數據以 KV 的形式存在

一級緩存: BlockCache

MySQL 的 B+樹 并不是把數據直接存放在樹中, 而是把數據組成 頁(Page) 然后再存入 B+樹, MySQL 中最小的數據存儲單元是 Page

HBase 也一樣, 其最小的存儲單元叫做 Block, Block 會被緩存在 BlockCache 中, 讀數據時, 優先從 BlockCache 中讀取

BlockCache 是 RegionServer 級別的

BlockCache 叫做讀緩存, 因為 BlockCache 緩存的數據是讀取返回結果給客戶端時存入的

二級緩存: 當查找數據時, 會先查內存, 后查磁盤, 然后匯總返回

因為寫是寫在 Memstore 中, 所以從 Memstore 就能立刻讀取最新狀態

Memstore 沒有的時候, 掃描 HFile, 通過布隆過濾器優化讀性能

綜上所述：

HBase 是 LSM樹 的一種開源實現, 類似的還有 LevelDB, RocketDB 等

HBase 無論是批量寫還是實時寫, 性能都超過 MySQL 不少

HBase 的查詢只有一種, 就是掃描, Get 也是掃描的一種特殊情況, 所以 HBase 的查詢能力不強

HBase 以 KV 的形式存儲數據, 所以如果某一單元數據為 Null 則不存, 所以 HBase 適合存儲比較稀疏的表

對上面所提到的數據庫再進行一次總結：

MySQL

隨著數據的增多, 插入性能遞減

查找延遲低

范圍查詢優勢明顯, 可以實現復雜的查詢

完整存儲所有數據, 不適合稀疏表

Hbase

HBase 無論是批量寫還是實時寫, 性能都超過 MySQL 不少

HBase 的查詢只有一種, 就是掃描, Get 也是掃描的一種特殊情況, 所以 HBase 的查詢能力不強

HBase 以 KV 的形式存儲數據, 所以如果某一單元數據為 Null 則不存, 所以 HBase 適合存儲比較稀疏的表

MySQL VS Hbase

從存儲形式上來看, 選 HBase, HBase 是 KV 型數據庫, 是不需要提前預設 Schema 的, 添加新的標簽時候比較方便

從使用方式上來看, 選 MySQL 似乎更好, 但是 HBase 也可以, 因為并沒有太多復雜查詢

從寫入方式上來看, 選 HBase, 因為畫像的數據一般量也不小, HBase 可以存儲海量數據, 而 MySQL 不太適合集群部署

總結：

最終選擇的方案為HBase，其實在大數據的生態圈中還存在著很多數據儲存的工具，例如Hive，ES等等，在特定的情況下這些輸出儲存工具也是可取的。

大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。