一、畫像系統命中接口相關簡介
什麼是畫像系統
标簽畫像系統是一種資料管理和分析工具，它通過整合和分析使用者的行為資料、交易資料、社交資料等多元度資訊，建構出使用者的詳細畫像，幫助咱們營運人員更好地了解目标使用者群體，進而實作精準營銷和精細化營運。
提供了那些能力：标簽注冊，标簽沉澱，标簽取值；群體圈選；群體服務（群體命中，群體下載下傳和訂閱等）核心能力
怎麼實作精準營銷和精細化營運
命中接口：它作為連接配接使用者資料和營銷活動的橋梁，確定了營銷資訊能夠準确地傳遞給最合适的使用者群體。
業務場景
▪場景一：商城收銀台頁面，優惠券展示與否，以及優惠金額多少。
▪場景二：金融APP端資源位，展示哪種營銷活動。
•……
在支付、消金、财富等核心業務中發揮着至關重要的作用，影響着使用者拉新、交易轉化、促活等關鍵環節。
命中接口實作邏輯
挑戰
•如何保證三高：高性能（50ms以下），高并發（百萬級TPS），高可用。
•資料量大：群體數量多，而且大量的群體的pin數量都是千萬級别以上，甚至有的群體pin數量達到了數十億。
二、畫像系統1.0和2.0版本的命中接口
存儲方式（實體機記憶體）
将人群資料從OSS拉取并存儲在實體機（32C256G）中，由于群體數量過多，256G不足以将所有的群體的OSS檔案都儲存下來，是以采用分片的邏輯，每個分片隻存儲群體OSS檔案的四分之一。
方案優缺點
優點：
1、性能達标：基于記憶體取值，減少中間件依賴，單機壓測到30000TPS，TP999最高40ms；
2、存儲成本較低：在當時，和直接使用緩存相比，成本較低；
3、緩解了CK的壓力：從OSS拉取檔案，減少了CK查詢次數。
缺點：
1、初始化群體非常慢：由于資料是存在機器記憶體中，每次啟動機器總要全量加載所有群體，但随着業務發展，群體數量的增加重新開機也會越來越慢；
2、擴容成本高：雖然分組内可以水準擴容，但是固定分組後，單機器的記憶體有限，一旦達到上限需要擴容分組時，必須成倍的擴容，導緻擴容分組困難；
3、排查問題效率低：由于是自研的依賴于機器記憶體的存儲方案，整體結構複雜，在運維的能力方面偏弱，運維的相關工具少。
三、畫像系統3.0版本的命中接口
背景
•遷移到了JDOS，JDOS沒有256G記憶體的實體機，是以我們采用的是192G記憶體的實體機。
•群體數量由8000+群體膨脹到25000+群體，由于1.0和2.0版本的四分片實體機存儲的資料越來越多，快到實體機記憶體的極限了。
•從OSS拉取群體的時候，會由于網絡抖動，導緻拉取人群資訊有不完整就斷掉的情況，會造成重複拉取，導緻實體機堆記憶體抖動，不穩定，影響TP999，影響業務正常進行。
存儲方式（實體機記憶體）
依舊将人群資料存儲在實體機中，但使用了拆分前置的操作，并且将原先的實體機四份片改為了八分片。先将群體的OSS檔案拆分成8分，然後實體機對應的分片隻需要去拉取自己分片對應的檔案即可。
資料分層方案（緩存）
為什麼需要使用緩存做資料分層
•提高系統的可用性和可靠性：應對不可預測的故障，網絡問題，伺服器故障等，資料分層政策可以幫助系統應對這些不可預測的故障，提高系統的可用性和可靠性
存儲方式
因為set集合的特征，元素小于512個會自動壓縮，是以我們使用set集合來存使用者的offset的。
四、畫像系統4.0版本的命中接口
背景
由于在3.0的時候，offset的編碼已經超過了2的32次方。我們使用的ck版本加工群體位圖的時候不支援大于2的32次方位圖計算，更新版本不相容。對ck計算層架構更新：小于32位的offset計算到現有的bitmap中，大于32位的offset計算時，所有offset - 2^32，計算到高32位bitmap。基于這點想到了如果低成本使用R2M。也可以通過開發達到RoaringBitmap的壓縮效果。
為什麼要壓縮
我們知道建立Bitmap的時候，長度必須是最大的offset的長度。再結合我們的場景，我們現在的pin數量已經超過了數十億，但是每個人群不可能都是數十億之多，是以我們位圖存儲的資料不是連續的，而是稀疏的。
假設我們現在隻有64個使用者，然後有一個人群包，隻有1個offset，63。
按照正常我們需要建立一個64位的Bitmap
| 1 | 2 | 3 | …… | 63 | 64 |
| …… | 1 |
這時候我們就把數組拆分成2組，1到32的使用者存儲到第1組，把33到64的使用者存儲到第二組。此時我們發現第一組的數組裡全是0，那第一組是不是可以不建立？這樣我們就用一個32位大小的數組存儲了64位的資料。
接下來更進一步，把64位的數組拆成每16個一組，那麼我們隻需要建立最後一個分組的數組，也就是16位的數組來達到進一步壓縮的目的。
| 49 | 50 | 51 | …… | 63 | 64 |
| …… | 1 |
壓縮流程
根據我們的業務場景，每個位圖大小是65536壓縮效果最好。
存儲方式（緩存）
部署多個R2M叢集（或分組），将群體bitmap進行拆分，并根據一定的路由政策存儲到不同的叢集上，通過不同的叢集提供查詢能力，如下圖
在新方案中，增加了一整套的群體推送服務，包括資料的新增，更新，删除，檢測，重試等全部可視化到頁面，大大增強了群體加載的可監測性及有效性，而在之前的方案中，非常缺少這些有效的運維手段。
流程對比
采用集中緩存替換自研分布式存儲優缺點對比
| 自研分布式存儲 | R2M存儲（新方案） | |
| 劣勢 | 優勢 | |
| 穩定性 | ·突然新增的大量人群資訊新增或變更，堆記憶體變化比較劇烈，容易達到伺服器上限 ·恢複周期長：伺服器出現當機後，恢複周期較長 ·單分片比較大，單台命中存儲服務的流量占比比較大，出現故障時，影響比較大 | ·R2M具有自動擴容的能力，當達到了一定的使用比例，分片會自動擴容 ·分片出現當機，會主從切換，瞬間恢複，并且支援異地機房備份 ·單分片比較小，影響範圍更小 |
| 維護成本 | ·啟動慢：單台存儲服務啟動比較慢，啟動最長達到30分鐘 ·上線難：總共有103台伺服器，65個分組（8個預發分組，57個生産分組），分組管理比較複雜，配置檔案比較難以管理，啟動要注意的事項比較多 ·擴容難：由于各分組是有狀态的，并且要求均是特殊的實體機，擴容相對複雜 | ·沒有這個節點了，不存在啟動慢，上線難問題 ·擴容簡單：自動擴容或者提擴容工單即可 ·緩存叢集由運維團隊在維護，他們有專業的團隊和工具維護 |
| 硬體成本 | ·總共103台實體機伺服器，其中預發伺服器 8台，命中伺服器48台，下載下傳伺服器8台，其他39台（待下線）--32C192G伺服器 | ·R2M是科技叢集，碎片會更小有的管理和使用，可以更有效的使用緩存空間 ·不存在預發的伺服器一直在在浪費 ·40億叢集大概500M，如果是13000個平均是10個億的人群，大概是1.5T，主從結構大概就是3T，換算成成192G的實體，大概就是15台實體機，如果保持水位是60%的話，大概實體機是25台實體機 |
| 其他 | ·隻在初始化時拉取一次OSS檔案即可，減少帶寬占用 |
性能對比
接口整體TP999耗時從40ms下降到10ms以内
五、命中接口的後續探索
一、逆向存儲
背景
我們對一些耗時長的請求進行分析時發現，有些業務方傳的群體編碼，一次可能傳幾十個，這種情況我們可能需要判定幾十次，然後把結果傳回給使用者，性能肯定比一次隻傳一個群體會差。是以我們想使用使用者的pin當作key，然後value是使用者所在的群體資料。這樣不管使用者一次傳多少個群體，我們隻用取一次緩存就可以。
存儲方式
key：使用者的pin的offset為key
value：使用者所在的所有群體集合（以位圖的方式存儲）
優勢
•性能高：使用者傳多個群體編碼的時候，我們隻需要取一次緩存就可以，性能大大提高了。
二、規則判定
背景
發現有些使用者在建立群體的時候，隻用到了标簽，然後對這些标簽做邏輯與或非的操作。
舉個例子：如果使用者選擇了兩個标簽（标簽1:男性，标簽2:三十歲以上，而且是且的關系）建立了一個人群，現在想判斷一個pin是否在這個群體裡面，我們可以怎麼操作？我們隻需要先判定使用者是否是男性，然後判斷使用者是否三十歲以上，然後在記憶體中做邏輯且的操作就可以了。
優勢
•存儲空間：不用存儲整個群體位圖檔案，而且标簽位圖可重複使用，大大節省了存儲空間
六、相關技術附錄
CDP系統中目前存在大量由pin集合組成的标簽和群體，截止目前共有标簽4000+，有效群體17000+。而且大量的群體都是pin數量都是千萬級别以上，甚至有的群體pin數量達到了40億+。如此大量的pin集合，對我們存儲結構提出較高的要求。
這裡拿群體舉例，如果某群體包含1000W個pin，通過文本檔案存儲，大概需要150M，40億的群體就達到了驚人的150*40*10=60000M，大約60G，而我們的群體數量已經達到了17000+，再加上标簽資料，所需要的存儲空間将不可接受。
并且，資料的存儲隻是其中一個方面，後續針對标簽和群體的組合計算，建立出更細粒度的pin包也是一個挑戰。
面對以上問題，CDP采用了Bitmap的思路來解決，不但解決了存儲空間問題，而且Bitmap本身的交并差運算，能夠很好的支援使用者對不同标簽和群體的組合計算，詳細方案如下。
一、bitmap簡介
它的基本思想是用bit位來唯一标記某個數值，這樣可以用它來記錄一個數值沒有重複的資料元組。并且每一條資料隻使用一個bit來辨別，能夠大大的節省存儲空間。
比如，如果想存儲一個數值數組[2,4,6,8]。
Java中如果用byte類型來存儲，不考慮其他開銷，需要4個位元組的空間，一個位元組8位，也就是4*8=32bit。
倘若使用更大的資料類型，存儲空間也會相應增大，如使用Integer（4位元組），則需要4*4*8=128bit。
而如果采用bitmap的思想，隻需要建構一個8bit空間，也就是一個位元組的空間來存儲，如下圖。
二、pin池編碼
通過上文的例子，可以看到，使用Bitmap思想來存儲，實際上每一個資料是一個bit，而且不能重複，這一點使用者pin是符合的，沒有重複的pin。
由于bitmap裡隻能存0或者1來辨別目前位是否有值，而使用者pin确是一個字元串，這就需要将數十億的使用者pin進行唯一性編碼，這個編碼也就是我們常說的offset偏移量。
每一個pin對應一個唯一的offset，目前已到46億+，也就是說目前最大的偏移量是45億+，這部分由資料同學幫我們加工一張pin池表，其中包含了pin和offset的對應關系。這樣，新注冊的pin，隻要順序增加offset值即可。
下邊是一個簡單示意圖，假設我有8個pin，pin1~pin8，對應的offset編号為1~8。
我要建一個隻包含雙數pin的标簽或群體，則我隻需要将offset為2，4，6，8的位設為1即可。
三、ClickHouse簡介
有了位圖之後，存在哪裡，以及怎麼進行位圖之間的交并差的運算。基于這些問題，我們使用了ClickHouse（以下簡稱CK），一個由俄羅斯Yandex在2016年年開源的⾼性能分析型SQL資料庫，是一個用于聯機分析處理（OLAP）的列式資料庫管理系統（columnar DBMS）。
它具有以下特點：
1、完備的資料庫管理功能，包括DML（資料操作語言）、DDL（資料定義語言）、權限控制、資料備份與恢複、分布式計算和管理。
2、列式存儲與資料壓縮: 資料按列存儲，在按列聚合的場景下，可有效減少查詢時所需掃描的資料量。同時，按列存儲資料對資料壓縮有天然的友好性（列資料的同類性），降低網絡傳輸和磁盤 IO 的壓力。
3、關系模型與SQL: ClickHouse使用關系模型描述資料并提供了傳統資料庫的概念（資料庫、表、視圖和函數等）。與此同時，使用标準SQL作為查詢語言，使得它更容易了解和學習，并輕松與第三方系統內建。
4、資料分片與分布式查詢: 将資料橫向切分，分布到叢集内各個伺服器節點進行存儲。與此同時，可将資料的查詢計算下推至各個節點并行執行，提高查詢速度。
更多特性可檢視官方文檔：https://clickhouse.com/docs/zh/introduction/distinctive-features
還可以檢視同僚的這篇文章：如何使用Clickhouse搭建數十億級使用者畫像平台看這一篇就夠了
除了上文CK的特性之外，它還具有分析資料高性能，開發流程簡便，開源社群活躍度高，并且支援壓縮位圖等優勢。
四、群體加工鍊路
基于上面對bitmap以及clickhouse的介紹，我們采用的是ClickHouse+Bitmap實作标簽群體組合計算和群體的存儲
上圖可以看到除了CK中的資料外，我們在OSS對象存儲中也放了一份群體資料。
五、RoaringBitmap壓縮
我們最終使用的是RoaringBitmap，一種高效的壓縮位圖實作，簡稱RBM。于2016年由S. Chambi、D. Lemire、O. Kaser等人在論文《Better bitmap performance with Roaring bitmaps》 《Consistently faster and smaller compressed bitmaps with Roaring》中提出。
基本實作思路如下：
以整型int（32位）為例，将資料分成高16位和低16位兩部分，低16位不變，作為資料位Container，高16位作為桶的編号Container，可以了解為高位的Container中，存放了很多個低位Container。
比如，我要存放65538這個值，則高位為65538>>>16=1，低位為65538-65536*1=2，即存儲在1号桶的2号位置，存儲位置如下圖：
我們目前使用的RoaringBitmap版本為0.8.13，Container包含了三種實作：ArrayContainer(數組容器)，
作者：京東科技 王京星
來源：京東雲開發者社群