使用者福利
阿裡雲最新釋出業界首款雲原生多模資料庫Lindorm，新使用者可享9.9元/3個月優惠，技術交流釘釘群：35977898，更多内容請
參考連結一、背景
在傳統的商場裡的銷售人員往往會對顧客進行察言觀色，揣摩其喜好，然後投其所好，達到營銷的目的，實作收益最大化。進入網際網路時代，店鋪搬到了線上，買家和賣家都處于一個“虛拟”的世界當中，你的“對手”是男是女、是美是醜、是普通的上班族還是家裡有礦的土豪，這些資訊似乎變得不可獲得。
網際網路的“虛拟”性決定了需要通過技術手段解決“察言觀色”的問題。好在進入網際網路，特别是移動網際網路時代，使用者随時随地都會在網上留下“言”和“行”，如何讓這些言行資料“開口說話”就變得越來越重要。使用者畫像應運而生，而且已經廣泛的應用到精準營銷、推薦系統、廣告投放、風控、智能客服等等領域。
那麼使用者畫像資料及其面向的應用場景有什麼的特征，針對這樣的特征應該選擇什麼樣的資料存儲呢？
二、使用者畫像資料特征
首先我們先明确下本文所指的使用者畫像包含兩類資料。一類是明細資料，是通過采集擷取到的使用者行為資料或其他的基礎資料。另一類是經過分析後産生的标簽資料，即通常意義上大家所稱的使用者畫像資料，比如使用者性别，住址，喜好，購物需求等等。使用者畫像可以通過如下的架構簡圖描述：
從架構簡圖中我們可以看到，系統一般會包括4個部分，資料采集系統、線上查詢系統、離線分析系統以及資料存儲系統。資料采集後會把資料寫入資料存儲系統，同時資料也會歸檔到離線系統，離線系統周期性的對資料進行訓練生成新的使用者畫像，新的畫像回流到線上系統供上層業務查詢。線上系統中包含了明細資料和曆史畫像兩個部分的資料。
基于上述的使用者畫像的資料範圍定義及應用到的業務場景的定義，使用者畫像資料有哪些痛點呢？
- 資料量大：網際網路應用的一個典型特征是擁有海量的使用者，往往都是以千萬甚至億計算，海量的使用者意味着會産生海量的行為資料。有些産品還有爬取外部資料的需求，以豐富其資料次元。基于海量明細資料，通過離線模型訓練産出最終的使用者畫像，最終的使用者畫像資料往往也是數以億計的高維(數百，數千甚至萬計的字段數量)資料。
- 高并發讀寫：海量使用者産生大量的資料需要實時寫入到背景的存儲系統中，是以資料寫入的并發度往往會達到每秒數萬，數十萬甚至數百萬或更高。同時，使用者畫像資料的線上應用場景，如推薦、廣告投放等，往往會随着投放效果的提升，營運推廣意願也會提升，則意味着更多的查詢數量和更高的查詢并發。
- 明細資料需要歸檔：寫入後端存儲的使用者行為明細或其他基礎資料，為了盡快的回報到使用者畫像資料中，往往需要準實時的歸檔到離線系統。
- 大資料量回流：歸檔到離線系統的資料經過分析後産生新的畫像資料，需要回流到線上提供線上查詢。
- 有動态列需求：使用者畫像的資料次元往往處于不斷變化不斷豐富當中，是以表結構也會處于不斷變化當中。
-
查詢種類多而且複雜：面向不同的業務需求，對使用者畫像資料的查詢需求也會有差異。比如：擷取使用者的畫像資料，隻需要根據key做單條記錄的查詢；對使用者行為資料的分析，可能是按照使用者ID批量擷取其資料；也可能是營運人員根據需要查詢某個次元的統計資料。
針對使用者畫像資料的上述痛點，同時畫像資料通常來講沒有強事務要求的特點，是否存在一個合适的存儲方案呢？
三、面向大資料場景的Lindorm
既然使用者畫像沒有強事務要求，又是大資料量、高并發讀寫場景，那麼關系型資料庫并不是合适的選擇。在此筆者向大家推薦一款可以完美解決使用者畫像業務痛點，面向大資料的NoSQL資料庫産品“Lindorm”。
作為面向大資料場景的半結構化、結構化存儲系統，Lindorm已經在阿裡發展近十年，并始終保持着快速的能力更新和技術更新，是目前支撐阿裡經濟體業務的核心資料庫産品之一。在過去的歲月，伴随着經濟體内部對于海量結構資料存儲處理的需求牽引，其在功能、性能、穩定性等方面的諸多創新曆經了長時間的大規模實踐考驗，被全面應用于阿裡集團、螞蟻集團、菜鳥、大文娛等各個業務闆塊，成為目前為阿裡内部資料體量最大、覆寫業務最廣的資料庫産品。
基于lindorm存儲的使用者畫像架構可以用下圖來描述：
下面筆者詳細闡述下Lindorm的那些特性可以解決使用者畫像的業務痛點。
3.1 低成本
大資料有衆所周知5V特征，這其中首當其沖的是Volume，是以面向大資料場景的資料存儲解決方案必須具備高密度、低成本的特性。Lindorm是誕生于大資料時代的一款NoSQL資料庫，低成本解決海量大資料的高效存、取是根植于其體内的基因。Lindorm的低成本能力展現在：
-
多樣化存儲類型支援
性能型存儲、标準型存儲、容量型存儲，總有一款适合你的業務場景
-
深度壓縮優化
存儲成本最低的系統是沒有資料需要存儲的系統，但這點顯然是不現實的，現實可行的方案是将需要存儲的資料降到合理的最低點。為了降低存儲開銷，Lindorm引入了一種新的無損壓縮算法，旨在提供快速壓縮，并實作高壓縮比。它既不像LZMA和ZPAQ那樣追求盡可能高的壓縮比，也不像LZ4那樣追求極緻的壓縮速度。這種算法的壓縮速度超過200MB/s, 解壓速度超過400MB/s（實驗室資料），很好的滿足Lindorm對吞吐量的需求。經實際場景驗證，新的壓縮優化下，壓縮比相對于LZO有非常顯著的提高，存儲節省可以達到50%～100%，對于存儲型業務，這就意味着最高可以達到50%的成本減少。
-
冷熱分離
Lindorm具備在單一個存儲架構下的“一張表”内實作資料的冷熱分離，系統會自動根據使用者設定的冷熱分界線，自動将表中的冷資料歸檔到冷存儲中。在使用者的通路方式上和普通表幾乎沒有任何差異，在查詢的過程中，使用者隻需配置查詢Hint或者Time Range，系統根據條件自動地判斷查詢應該落在熱資料區還是冷資料區。對使用者而言始終是一張表，對使用者幾乎做到完全的透明。
3.2 高性能吞吐
根據實測同樣規格，相同資料量的情況下，Lindorm不管是在單行讀、範圍讀還是單行寫及批量寫場景下，其吞吐量和P99延遲相比社群版本HBase2.0都有數倍提升。
備注：1) P99延遲指99%請求的響應時間小于該值; 2) 圖中數值供參考，具體以實際場景為準
下圖為以批量寫為主的真實業務場景遷移後的表現，而使用者畫像的行為日志資料采集往往也可以通過累積一定量的資料後做批量寫入。 3.3 實時增量歸檔
實時增量歸檔是Lindorm的一項獨立服務，通過監聽Lindorm産生的日志，LTS解析日志并同步到離線系統比如Hadoop或者MaxCompute。同步到離線系統的資料按時間分區，這樣可以很友善的進行T+1，H+1或其他不同周期的計算。
這樣的同步機制下，一方面資料歸檔過程與線上存儲解耦，線上讀寫完全不會受到資料歸檔的影響。另一方面明細資料可以實作準實時同步到離線，然後進行分析，進而可以高效實作使用者畫像資料的更新。
3.4 Bulkload技術
與關系型資料庫不同，Lindorm采用LSM Tree架構。讀取存儲到Lindorm裡的一條記錄需要合并對應資料分片記憶體中(即memestore)的資料、該資料分片所owner的多個LDFile中該記錄的最新版本資料，合并後送出給用戶端。基于這樣的原理，Lindorm可以實作直接生成并向系統中“插入”新的LDFile，進而實作“新”資料的加載，使得其相比于其他的關系型資料庫或NoSQL有非常大的優勢。這樣的資料加載過程完全繞過了存儲引擎，WAL及Memstore等等，隻有必不可少的實體IO和網絡開銷，進而極大的提升了資料加載的性能，降低了對線上業務請求的影響。
3.5 動态列
Lindorm的寬表模型支援多列簇、動态列、TTL、多版本等特性，可以很好的适合使用者畫像這樣表結構不穩定，經常需要進行變更的業務場景。
3.6 多元度&複雜查詢
對于基于rowkey的單key或基于rowkey字首的scan，Lindorm自身就可以很好的滿足業務的需求。
當遇到多元度、少量組合列，而且有固定查詢模式的場景來說，Lindorm内置的高性能全局二級索引功能也可以滿足業務需求，同時仍保持強大的吞吐與性能。
當面對更加複雜的查詢，比如模糊查找、随機條件組合查詢等等，二級索引方案會顯得力不從心，這時候Lindorm搜尋引擎LSearch就有其用武之地。LSearch是面向海量資料設計的分布式搜尋引擎，相容開源Solr标準接口，同時可無縫作為寬表、時序引擎的索引存儲，加速檢索查詢。其整體架構與寬表引擎一緻，基于資料自動分區+分區多副本+Lucene的結構設計，具備全文檢索、聚合計算、複雜多元查詢等能力，支援水準擴充、一寫多讀、跨機房容災、TTL等，滿足海量資料下的高效檢索需求。
四、Lindorm核心能力概述
Lindorm通過其具備的全方位、多角度的能力，可以很好的滿足使用者畫像業務大資料量、高并發、實時歸檔、高效&穩定批量資料加載、動态列及多元度複雜查詢的需求。
當然，Lindorm的能力還遠不止于此，Lindorm具備了大資料背景下，面向海量資料的存儲系統應該具備的一系列的能力：
- 是一款支援寬表、時序、搜尋、檔案的多模資料庫
- 是一款基于存儲計算分離架構的資料庫，提供極緻的計算、存儲彈性伸縮能力，并将全新提供Serverless服務，實作按需即時彈性、按使用量付費的能力
- 是一款支援冷熱分離、、追求更優壓縮優化方案的極具成本效益的資料庫
- 是一款具備全局二級索引、多元檢索、時序索引等功能的資料庫
- 提供具備智能化服務能力的LDInsight工具，白屏化完成系統管理、資料通路及故障診斷
- 提供LTS(Lindorm Tunnel Service，原BDS)，支援簡單易用的資料交換、處理、訂閱等能力，滿足使用者的資料遷移、實時訂閱、數湖轉存、數倉回流、單元化多活、備份恢複等需求
五、案例
某大型三方支付公司金融風控系統
風控系統是一個金融系統的基石，該三方支付公司的風控系統提供的安全保障在業界是最高的，資損率低至百萬分之零點5，全世界排第二的資損率是萬分之六(2018年公布的資料)。這背後有安全團隊做出的各種模型和規則，而為這些規則和模型的運作提供資料存儲支援的正是Lindorm。
大家在進行支付，掃描二維碼的時候，可能隻有短短的零點幾秒的時間，這其中有100毫秒系統會針對這筆交易擷取使用者的安全畫像資料進行安全甄别，比如：支付的場景，對方的背景，支付時候所處的環境，以及你的一些行為特征，購物喜好，通常的購物時間等等，去幫你甄别這個交易是否存在風險，如果存在風險，便在交易的兩端去盡量的提醒，甚至截斷交易，整個交易的背後是大概一百多個風險模型和五百多個風險政策的一個運算。
上文提到的使用者安全畫像資料正是下圖所描述的明細資料和經過歸檔、分析和回流後導入Lindorm的日帳資料。
對于一筆交易而言就需要這麼大量的模型和規則，那麼雙十一大促高峰期間，其對背後的資料支撐系統的要求可想而知。
咨詢交流
歡迎加入Lindorm技術交流群