使用者福利
阿裡雲最新釋出業界首款雲原生多模資料庫Lindorm，新使用者可申請首月免費試用，擷取産品技術支援，請加入釘釘群：35977898，更多内容請
參考連結一、背景
廣告顧名思義就是廣而告之，通過廣告推銷商品或服務。在人類進入網際網路時代之前，廣告往往依賴傳統的報紙、雜志、電視等大衆媒體，廣告的售賣也以線下的方式進行。當人類進入網際網路、移動網際網路之後，廣告的售賣形式随着門戶網站、各類手機APP的出現而發生了翻天覆地的變化，由此也推動了廣告程式化購買的不斷發展，與之相關的各類線上廣告系統也不斷發展。
二、廣告的程式化購買流程及業務特征
2.1 一次廣告的購買流程
廣告的程式化購買通過廣告交易平台(Ad Exchange,簡寫為ADX)、供應方平台(Supply-Side Platform，簡寫為SSP)、需求方平台(Demand-Side Platform，簡寫為DSP)、資料管理平台(Data Management Platform，簡寫為DMP)等幾個新興的網際網路技術平台，将消費者、廣告主、媒體等幾方的需求有機的聯系起來。
在SSP内實作廣告庫存的管理，當消費者觸達廣告位時，資訊傳遞到ADX，同時在DMP内完成對消費者的畫像資料查詢，确定廣告位展現需求，接着向各個DSP發起邀約，确定合适的廣告主，然後進入競價環節，達成廣告交易，并最終在媒體端将廣告主需要宣傳的産品投放出去，展現在消費者面前。
備注：本圖檔來自網絡，如有侵權請聯系作者删除。
2.2 廣告購買流程分析
從上述整個程式化購買廣告的流程中可以看到:
- 整個廣告購買鍊路涉及到環節衆多，鍊路非常長，而實時性要求卻非常高，通常在百毫秒級别，否則使用者體驗就會很差，逾時的請求對于各方而言都是有損的：媒體的廣告位沒有賣出去、廣告主沒有将其産品展現給終端使用者、DSP/SSP/DMP等各方也因為交易未達成而收不到傭金
- 為了實作廣告的“精準營銷”、“千人千面”，使用者畫像資料發揮了至關重要的作用，決定着向該特定使用者展現什麼樣的廣告内容，否則就會鬧出把冰箱賣給愛斯基摩人的笑話。
那麼，這裡的資料包含哪些可能的内容呢？
- 使用者畫像資料，即使用者的一些基本屬性資料，如：性别、年齡、位址、收入狀況等
- 使用者在廣告主網站/門店的浏覽(包括時長等)、收藏、加購、交易等行為資料
- 使用者其他行為資料，如：頻道浏覽，商家頁面浏覽、評論、打分、社群&論壇等
- 場景化廣告中的特定資料，如：使用者實時位置及時間資料
- 使用者在投放廣告的點選/互動的資料
- 來自于三方的線下資料。人們的線下行為往往比線上行付出的代價更大，是以往往具有更強的目的性，比如去4S店往往是有購車的意向。
2.3廣告業務系統的資料存儲特征
- 能低成本支撐海量資料：網際網路應用的一個典型特征是擁有海量的使用者，往往都是以千萬甚至億計算，其浏覽/加購/收藏及其他各類行為資料、場景化資料、廣告點選&互動資料也必然是海量的。海量明細資料需要通過離線模型訓練産出最終的使用者畫像資料，是數以億計的高維(數百，數千甚至萬計的字段數量)資料。
- 能支撐高并發讀寫并且低延遲：海量使用者産生大量的資料需要實時寫入到背景的存儲系統中，是以資料寫入的并發度往往會達到每秒數萬，數十萬甚至數百萬或更高。同時廣告投放與交易不同，往往和使用者的浏覽行為成正比，是以是一種更高頻的讀行為，而且在鍊路非常長的廣告系統中需要確定百毫秒内傳回。
- 需要具備歸檔能力：寫入後端存儲的使用者行為明細或其他類型資料，為了盡快的回報到使用者畫像資料中，往往需要準實時的歸檔到離線系統以完成分析産出結果。
- 需要具備高效&低影響的資料回流能力：歸檔到離線系統的資料經過分析後産生新的畫像資料，需要能高效、無影響(對線上查詢業務)的情況下，回流到線上存儲内提供線上查詢。
- 需具備動态Schema能力：如前所述，廣告系統依賴的資料來源衆多，例如：行為資料的采集需求也會不斷變化，是以表結構也會處于不斷變化當中。
針對上述資料存儲的能力要求，同時該類資料沒有強事務要求的特點，是否存在一個合适的存儲方案呢？
三、面向大資料場景的Lindorm
沒有強事務要求、海量資料、高并發&低延遲、準實時歸檔能力、高效資料回流能力以及動态schema能力，這些種種要求正是阿裡雲自研NoSQL資料庫産品着力要解決的問題。
作為面向大資料場景的半結構化、結構化存儲系統，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 多AZ + Speculative通路
Lindorm提供跨可用區強一緻或最終一緻不同模式來滿足不同業務場景下的高可用及性能要求。對于以使用者畫像為基礎資料的廣告場景，對于資料一緻性的要求并不高，能保證最終一緻即可。在這樣的前提下，就可以通過Lindorm提供的Speculative通路方式來大幅度降低單機/叢集異常導緻的通路毛刺，進而滿足廣告場景對于響應時間的極高要求。
3.4 實時增量歸檔
實時增量歸檔是Lindorm的一項獨立服務，通過監聽Lindorm産生的日志，LTS解析日志并同步到離線系統比如Hadoop或者MaxCompute。同步到離線系統的資料按時間分區，這樣可以很友善的進行T+1，H+1或其他不同周期的計算。
這樣的同步機制下，一方面資料歸檔過程與線上存儲解耦，線上讀寫完全不會受到資料歸檔的影響。另一方面明細資料可以實作準實時同步到離線，然後進行分析，進而可以高效實作使用者畫像資料的更新。
3.5 Bulkload技術
與關系型資料庫不同，Lindorm采用LSM Tree架構。讀取存儲到Lindorm裡的一條記錄需要合并對應資料分片記憶體中(即memestore)的資料、該資料分片所owner的多個LDFile中該記錄的最新版本資料，合并後送出給用戶端。基于這樣的原理，Lindorm可以實作直接生成并向系統中“插入”新的LDFile，進而實作“新”資料的加載，使得其相比于其他的關系型資料庫或NoSQL有非常大的優勢。這樣的資料加載過程完全繞過了存儲引擎，WAL及Memstore等等，隻有必不可少的實體IO和網絡開銷，進而極大的提升了資料加載的性能，降低了對線上業務請求的影響。
3.6 動态列
Lindorm的寬表模型支援多列簇、動态列、TTL、多版本等特性，可以很好的适合使用者畫像這樣表結構不穩定，經常需要進行變更的業務場景。
四、Lindorm核心能力概述
Lindorm通過其具備的全方位、多角度的能力，可以很好的滿足使用者畫像業務大資料量、高并發、實時歸檔、高效&穩定批量資料加載、動态列及多元度複雜查詢的需求。
當然，Lindorm的能力還遠不止于此，Lindorm具備了大資料背景下，面向海量資料的存儲系統應該具備的一系列的能力：
- 是一款支援寬表、時序、搜尋、檔案的多模資料庫
- 是一款基于存儲計算分離架構的資料庫，提供極緻的計算、存儲彈性伸縮能力，并将全新提供Serverless服務，實作按需即時彈性、按使用量付費的能力
- 是一款支援冷熱分離、、追求更優壓縮優化方案的極具成本效益的資料庫
- 是一款具備全局二級索引、多元檢索、時序索引等功能的資料庫
- 提供具備智能化服務能力的LDInsight工具，白屏化完成系統管理、資料通路及故障診斷
- 提供LTS(Lindorm Tunnel Service，原BDS)，支援簡單易用的資料交換、處理、訂閱等能力，滿足使用者的資料遷移、實時訂閱、數湖轉存、數倉回流、單元化多活、備份恢複等需求
五、案例
某全球性的媒介投資管理集團
該公司每年管理着超過千億美金的媒介投資，在全球市場上擁有衆多深入了解消費者和媒體平台的媒介專家、專業的媒介購買能力、引領市場的品牌安全舉措、技術解決方案，為客戶及其他利益相關者打造市場優勢。
該公司通過将其廣告系統依賴的記憶體型資料庫couchbase遷移至Lindorm，在大幅度降低運作成本的同時，成本通過Lindorm提供的Speculative通路方式，實作P99最大毛刺5ms，很好的滿足了廣告系統對于響應時間的極緻要求，同時該架構下具備了多可用區的災備能力。
系統架構如及業務流程參考下圖所示：
咨詢交流
歡迎加入Lindorm技術交流群