1.什麼是使用者畫像
在給使用者畫像做定義之前，我們先來了解一下什麼是推薦系統
場景：
在現在的網際網路時代，網上購物已經稱為常态，當我們在各大電商平台購物的時候，不難發現這樣一個現象。當你搜尋某個上面進行浏覽的時候，點選目标商品，之後傳回到首頁，很大機率你就可以發現，你剛才搜尋的商品的相關産品已經在首頁的推薦欄目。例如，你購買了一件護膚品面霜，回到首頁推薦處，系統可能就會給你推薦口紅或者相關護膚品。又例如當你搜尋使用者畫像書籍的時候，推薦欄目就會出現有關使用者畫像的書籍。這些功能就叫做推薦，而完成這些行為的即為推薦系統。
本質：
推薦系統就是對使用者的浏覽行為進行記錄分析，并基于這些行為對使用者将要購買的商品進行預測。老王購買了使用者畫像的書籍，那麼老王便與這本書之間産生一個連接配接。小麗購買了護膚品，那麼小麗便于這個護膚品之間産生了連接配接。而推薦系統就是根據一些算法去預測使用者與商品之間還未産生的連接配接。
來看一張簡單的使用者畫像表：
給使用者畫像下定義：
使用者畫像是對使用者的一種标注，通過給使用者打上标簽的形式來描述使用者
這個标簽可以是一個人的年齡，性别，收入情況，也可以是一個人的購物傾向或者是常居住地
總而言之我們能想到的用來描述一個人的各方面特征的都可以算作是畫像的範疇
2.使用者畫像在儲存方面的要求
畫像表相對比較稀疏，一般一個使用者畫像的項目至少有近百個标簽，而大部分使用者都應該隻打上一部分呢标簽，是以總體來說畫像表應該較為稀疏
大部分标簽使用ID進行比對查找，定位到使用者标簽再找到使用者群體
進行聚合統計的需求較多
需要資料庫可以按key查詢，聚合統計查詢，以及多條件組合查詢
稀疏表的儲存不應該占用太多空間資源
3.一号選手：Mysql
上圖是一個 B樹 的形式, 每個節點有兩個資料元素, 每個節點有三個子節點, 每個葉子節點有兩個資料元素
無論是什麼形式的 B樹, 都具備以下定理, 這四個定理也是保證 B樹 插入和删除能夠平衡的原因
根節點至少兩個子節點
每個中間節點都包含 m 個孩子, 每個中間節點都包含 m - 1 個資料元素
最底層的節點稱之為葉子節點, 所有葉子節點都位于同一層
所有節點中的資料元素按照大小排列, 所有子節點按照資料元素的大小排列, 父節點的資料元素恰好是子節點資料元素的值域劃分點
B樹插入規則：
如果目前節點未滿, 插入
如果目前節點已滿, 分裂節點, 中間大小的值提升, 直到插入根節點
如果根節點也已滿, 插入節點成為新的根節點, 層級 +1
B樹存在的問題：
因為 B樹 中所有節點都可攜帶資料元素, 是以導緻性能不穩定
範圍查找效率太低
基于B樹存在的這些問題，B+樹出現了
B+樹：
MySQL的索引類型：
在 MySQL 中, 有兩個引擎, 如下
MyISAM,引擎, 事務支援很差, 較少使用
InnoDB,引擎, 事務支援完備, 使用較廣泛
InnoDB 的特點
任何一張表的資料都自帶一個聚集索引
預設情況下, 建表必須有主鍵, 預設的聚集索引以主鍵為 Key
總的來說，無論是否聚集, MySQL 中的索引都是 B+樹 結構
MySQL特性總結：
根據 B+樹 的特性可以知道, 每次在插入的時候都比較複雜, 當資料量增多的時候, 性能衰減會非常明顯
B+樹 是查找樹, 其節點之間是有序的, 當需要搜尋的時候, 時間複雜度和折半查找一樣, 隻有 Log2N
B+樹 的葉子節點構成了一個類似連結清單的結構, 是以進行範圍查找的時候, 不需要回到父節點, 可以直接在子節點中進行, 是以在進行一些複雜查詢的時候比較友善範圍取資料
因為 MySQL 的主要目的是 OLTP, OLTP 更強調每次操作一條或者多條資料, 是以 MySQL 是行存儲的形式, 行存儲為了對齊所有的列, 即使某列為 Null, 也依然會有按照資料類型的占位
MySQL存在的問題：
插入性能會随着樹的複雜度而遞減
資料多的話會導緻樹變得很寬，這個時候插入資料就複雜度就變高了
随着資料量不斷增加，樹從插入性能就下架了
4.二号選手：Hbase
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
一級緩存: BlockCache
MySQL 的 B+樹 并不是把資料直接存放在樹中, 而是把資料組成 頁(Page) 然後再存入 B+樹, MySQL 中最小的資料存儲單元是 Page
HBase 也一樣, 其最小的存儲單元叫做 Block, Block 會被緩存在 BlockCache 中, 讀資料時, 優先從 BlockCache 中讀取
BlockCache 是 RegionServer 級别的
BlockCache 叫做讀緩存, 因為 BlockCache 緩存的資料是讀取傳回結果給用戶端時存入的
綜上所述：
HBase 是 LSM樹 的一種開源實作, 類似的還有 LevelDB, RocketDB 等
HBase 無論是批量寫還是實時寫, 性能都超過 MySQL 不少
HBase 的查詢隻有一種, 就是掃描, Get 也是掃描的一種特殊情況, 是以 HBase 的查詢能力不強
HBase 以 KV 的形式存儲資料, 是以如果某一單中繼資料為 Null 則不存, 是以 HBase 适合存儲比較稀疏的表
5.使用者畫像儲存選型
對上面所提到的資料庫再進行一次總結：
MySQL
随着資料的增多, 插入性能遞減
查找延遲低
範圍查詢優勢明顯, 可以實作複雜的查詢
完整存儲所有資料, 不适合稀疏表
Hbase
MySQL VS Hbase
從存儲形式上來看, 選 HBase, HBase 是 KV 型資料庫, 是不需要提前預設 Schema 的, 添加新的标簽時候比較友善
從使用方式上來看, 選 MySQL 似乎更好, 但是 HBase 也可以, 因為并沒有太多複雜查詢
從寫入方式上來看, 選 HBase, 因為畫像的資料一般量也不小, HBase 可以存儲海量資料, 而 MySQL 不太适合叢集部署
總結：
最終選擇的方案為HBase，其實在大資料的生态圈中還存在着很多資料儲存的工具，例如Hive，ES等等，在特定的情況下這些輸出儲存工具也是可取的。