在使用者行為分析和圈人情境中，經常需要從億級甚至幾十億級使用者中快速篩選出符合特定標籤的指標結果，本文為您介紹Hologres中如何進行使用者行為分析。
行業背景與痛點
UV（Unique Visitor）是行為分析中最常見的指標，代表訪問網頁的自然人，可以引申為某段時間內某個指標精確去重後的量。例如大促時，電商商家需要Realtime Compute店鋪的即時UV，並根據UV情況及時調整營運策略，從而達成銷售目標。
在計算使用者UV時，由於業務需求不同，計算的維度和資料量也不同，通常來講會有以下訴求。
使用者資料量大，每天幾億條，維度多（10+以上），需要支援各維度間任意組合查詢。
查詢時間需要更靈活，不僅局限於天、周、月、年等，還需要支援更細粒度即時更新查詢。
需要對使用者數量精確去重。
面對上訴高複雜度UV計算情境，業界常見的手段包括使用Apche Kylin等預計算系統或者Flink+MySQL的固定維度組合方案，但這些方案會遇見以下痛點。
需求維度過多時，會帶來儲存爆炸，預計算時間長。
精確去重需要消耗大量資源，容易出現OOM（Out Of Memory）。
即時更新難，無法支援更加靈活開放的時間周期處理。
解決方案與優勢
Hologres是基於分析服務一體化理念（Hybrid Serving & Analytical Processing，HSAP）設計的即時數倉產品，採用分布式架構，支援資料即時寫入，高並發、低延時的分析處理PB級資料，相容PostgreSQL協議，使用最熟悉的工具就能進行開發。
在Hologres中，通過RoaringBitmap和Serial，結合Hologres自身的高效能，就能實現億級UV精確計算。
RoaringBitmap
RoaringBitmap是一種壓縮位元影像索引，RoaringBitmap自身的資料壓縮和去重特性十分適合對於巨量資料下UV計算。其主要原理如下：
對於32Bit數，RoaringBitmap會構造216個桶，對應32位元的高16位；32位元的低16位則映射到對應桶的一個Bit上。單個桶的容量由桶中已有的最大數值決定。
Bitmap把32位元用1位表示，可以極大地壓縮資料。
Bitmap位元運算為去重提供了手段。
RoaringBitmap使用詳情請參見RoaringBitmap函數。
Serial
自增序列Serial，常用於維表關聯中的使用者映射（user_mapping）。因為常見的業務系統或者埋點中的使用者ID很多是字串類型或Long類型，因此需要使用uid_mapping類型構建一張映射表。RoaringBitmap類型要求使用者ID必須是32位INT類型且越稠密越好（即使用者ID最好連續），映射表利用Hologres的SERIAL類型（自增的32位INT）來實現使用者映射的自動管理和穩定映射。Serial使用詳情請參見自增序列Serial（Beta）。
離線UV計算情境
離線UV計算應用T+1思想：將前一天的所有資料根據最大的查詢維度彙總出uid結果放入RoaringBitmap中，RoaringBitmap和查詢維度存放在彙總結果表（每天百萬條）。之後查詢時，利用Hologres強大的列存計算直接按照查詢維度去查詢彙總結果表，對其中關鍵的RoaringBitmap欄位做或運算進行去重後並統計基數，即可得出對應使用者數UV，計數條數即可計算得出PV，達到亞秒級查詢。
只需進行一次最細粒度的預彙總計算，也只產生一份最細粒度的預彙總結果表。得益於Hologres的計算能力，該方案下預計算所需的次數和空間都達到較低的開銷。詳情使用請參見離線UV計算。
即時UV計算情境
Hologres與Flink有著強大的融合最佳化，支援Flink資料高通量即時寫入，寫入即可見，支援Flink SQL維表關聯，以及作為CDC Source事件驅動開發。
即時UV計算主要是Hologres與Flink結合完成：Flink關聯Hologres使用者維表，並基於RoaringBitmap，即時對使用者標籤去重。這樣的方式，可以較細粒度地即時得到使用者UV、PV資料，同時便於根據需求調整最小統計視窗（如最近5分鐘的UV），實作類別似即時監控的效果，更好地在大屏等BI中展示。相較於以天、周、月等為單位的去重，更適合在活動日期進行更細粒度的統計，並且通過簡單的彙總，也可以得到較大時間單位的統計結果。
該方案資料鏈路簡單，可以任意維度靈活計算，只需要一份Bitmap儲存，也沒有儲存爆炸問題，還能保證即時更新，從而實現更即時、開發更靈活、功能更完善的多維分析數倉。使用詳情請參見Hologres+Flink通過預彙總實現即時UV統計。