用戶福利

阿里雲最新發布業界首款雲原生多模數據庫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的日帳數據。

對於一筆交易而言就需要這麼大量的模型和規則，那麼雙十一大促高峰期間，其對背後的數據支撐系統的要求可想而知。