簡介： 數據銀行是一款品牌消費者運營的商業數據產品，由於其核心分析能力需要在海量數據上實現任意維度自由分析和響應時間上的強需求，我們大規模使用AnalyticDB作爲底層的分析引擎，最終以較低的成本，出色的性能，支撐了上萬品牌商大促期間每天百萬級的OLAP查詢。
作者：崚嶒（楊然）數據技術及產品部-高級技術專家
前言
數據銀行是一款品牌消費者運營的商業數據產品，由於其核心分析能力需要在海量數據上實現任意維度自由分析和響應時間上的強需求，我們大規模使用AnalyticDB作爲底層的分析引擎，最終以較低的成本，出色的性能，支撐了上萬品牌商大促期間每天百萬級的OLAP查詢。
當前數據銀行在AnalyticDB中存儲了約幾十萬億條數據，佔用存儲空間約1.6P，查詢平均響應時間在5秒以內。
數據銀行業務介紹
數據銀行作爲消費者運營的商業數據產品，提供了鏈路流轉分析、人羣圈選、人羣畫像等衆多數據能力。
鏈路流轉分析
AIPL是數據銀行的特有指標，用於衡量品牌和消費者關係的指標（AIPL是4個階段的縮寫，分別是A認知、I興趣、P購買、L忠誠），鏈路流轉分析用於獲取品牌任意兩天消費者AIPL關係的變化（如下圖，某品牌在某個類目下，從去年雙十一到今年雙十一AIPL的變化，非真實數據）。
在這個場景，用戶可以選擇近540天內的任意兩個日期，加上品牌和類目這兩個維度，用戶可能的輸入情況在百萬億級別。
人羣畫像
人羣畫像是消費者運營產品的核心能力，數據銀行除了可以針對用戶沉澱的具體人羣進行畫像操作，還可以對鏈路流轉的人羣進行畫像以幫助品牌分析消費者關係變化的原因（如下圖，某品牌去年雙十一是購買狀態但今年雙十一是流失狀態的人羣畫像，非真實數據）。
在這個場景，數據銀行爲用戶提供了200多個標籤，大部分爲行業相關，每次人羣畫像只會涉及到部分標籤，如果爲人羣預先計算所有標籤會導致資源的極大浪費。
人羣圈選計算人數 / 人羣圈選
人羣圈選是消費者運營產品的核心能力，相比大部分消費者運營產品限制用戶只能使用標籤數據，數據銀行人羣圈選（分鐘級）可以讓用戶使用標籤、觸點（可以理解爲消費者行爲，如購買、搜索、看直播等）等各類數據，同時用戶還可以即時查看圈選條件下消費者的數量（秒級）。
在這個場景，各類圈選條件可以通過交併差自由組合，同時部分圈選條件如購買金額是讓用戶填寫的數值，無法枚舉。
數據銀行爲什麼選擇AnalyticDB
普通的分析業務，如果對響應時間沒有要求，離線計算（Hadoop/Hive/Maxcompute）幾乎可以滿足所有數據分析的需要，但是從用戶在線響應的角度出發，高頻使用的功能對響應時間都會有強需求。
例如：用戶決策需要大量人羣畫像的對比，而人羣的選擇存在一定的依賴關係，下一個畫像人羣的選擇取決於前一個人羣畫像的結果。如果採用離線計算，不僅會大幅度拉長用戶的決策時間，還會打斷用戶分析思維的連續性，對用戶體驗產生較大的影響。
解決響應時間問題一般有兩種思路：
- 預計算，把用戶所有可選維度組合下的指標先離線計算出來，用戶在分析時，系統直接去數據庫取結果。
- OLAP在線計算，把輕度聚合的數據（保留所有用戶可選維度）存放在MPP引擎中，根據用戶提交的條件，即時計算出指標。
這兩種思路各有特點，預計算需要考慮維度爆炸、離線預計算無法在有限時間內完成、或者是需求變化導致預先計算的結果沒有被使用導致的資源浪費等一系列問題。而OLAP能夠提任意維度的自由計算，無需預先計算，但則也需要考慮MPP引擎的存儲成本、容量和計算性能等問題。
綜合來看，作爲面向消費者運營的數據產品，對響應時間有強需求，不適合使用預計算的情況；同時因爲數據量巨大（幾十萬億、PB級別），整體的成本也是一個重要的考慮點。
OLAP引擎選型
數據銀行的OLAP有幾大挑戰：
- 數據量上的挑戰：原始數據量非常龐大，歷史數據總量有1.6PB、22萬億條記錄，其中10張以上的萬億級大表，全部存儲在AnalyticDB中。
- 數據寫入性能上的挑戰：單日新增寫入量600億行記錄，總大小10TB，其中基線任務在每天早晨7:00 - 9:00兩小時內完成導入，要求導入速度至少爲千萬級的tps；
- 複雜查詢性能上的挑戰：查詢類型複雜，多爲較大的複雜交互分析，2萬億級別的大表經過篩選後再與8張表做關聯，需要在10秒內返回。
- 導出性能上的挑戰：快速的結果集導出，業務中需要將分析圈選的人羣做數據導出。需要能夠將AnalyticDB計算好的結果便捷、高效的導出到Maxcompute中。並且要求能夠支撐每分鐘20個以上的百萬級結果導出任務。
- 成本上的挑戰：考慮到PB級的數據，全部存儲到SSD成本太高，因此希望系統具備冷熱數據分層存儲能力，用接近離線的價格實現在線的性能。
- 穩定性上的挑戰：複雜的工作負載，在真實線上場景，上面提到的3個挑戰會同時出現，要求能夠在這種複雜的workload下系統平穩運行。
通過前期技術調研和測試，選擇AnalyticDB作爲數據銀行業務分析的基礎平臺，具體如下：
1.冷熱數據分層能力
AnalyticDB提供的數據冷熱分離這一企業級特性，可以大幅提升數據存儲的性價比。可以按表粒度選擇熱表（存的在ESSD）、冷表（存儲在OSS）和溫表（混合方式，部分存在ESSD，部分存儲在OSS）存儲，客戶完全可以按業務需求自由指定，並且冷熱策略可以任意轉換，對用戶來說是一份存儲，一套語法，輕鬆實現聯合查詢。我們使用的場景更多的是冷表爲主，而且AnalyticDB針對冷表具有SSD Cache來做加速，降低成本的同時兼顧了性能。數據銀行在AnalyticDB中存儲幾十萬億條數據，佔用存儲空間約2P，已經成爲數據銀行的核心數倉存儲，而預計未來會繼續增長。
**
2.高吞吐實時寫入
AnalyticDB底層採用分佈並行的架構，實現了極高的寫入/導入吞吐，海量數據可以直接以千萬級甚至億級tps實時寫入。同時針對離線聚合過的表，AnalyticDB提供了直通的batch load方式可以高吞吐直接加載數據進行在線查詢。
- 強大的高併發、低延時實時計算能力。
三類業務查詢場景下對響應時間都是強需求，查詢大部分是萬億大表圈選後的聚合和連接查詢，AnalyticDB使用冷數據緩存、預熱等技術，使這些查詢的平均響應時間在10秒以下。
數據模型和表設計
數據銀行主要在AnalyticDB中存儲四類數據：
1、AIPL數據，即品牌和消費者關係
2、標籤數據，即消費者屬性
3、觸點數據，即消費者行爲
4、人羣數據，即數據銀行用戶在數據銀行沉澱的人羣
由於所有場景的分析對象都是消費者ID，所以大部分表都以消費者ID爲分佈鍵，這樣可以最大避免查詢過程中的數據shuffle（重分佈）。以下主要介紹AIPL和標籤的表設計，觸點和人羣的表設計類似，不再贅述。
1、AIPL數據
AIPL數據按天分區，但由於每天產生的數據量較大（500多億），即使AnalyticDB批量導入性能較爲突出，仍然需要較長的導入時間，考慮到AnalyticDB不支持多級分區，我們將AIPL表從品牌維度拆分爲20張子表，一方面提升導入性能，另一方面也能提升查詢性能。
數據銀行除了在品牌維度提供AIPL分析，用戶還可以下鑽到二級類目維度，要支持二級類目有兩種方案：
1、在原有的AIPL表上擴展二級類目維度
2、新增一套包含二級類目維度的AIPL表
第一種方案更節省存儲空間，也只需要導入一套表；第二種方案的查詢性能更好。
經過驗證，我們使用了第二種方案，不包含二級類目的查詢在數據銀行中佔了較大比重，當查詢不包含二級類目時，第一種方案需要group by 消費者ID，執行過程會佔用較大內存，可承載的併發度較低，性能也較差。得益於AnalyticDB較低的存儲成本，使用第二種方案在並沒有導致成本大幅度增長。
同時由於品牌ID是查詢時必帶的維度，而AIPL狀態是高頻使用的維度，所以在建表時將品牌ID和AIPL狀態設置爲聚集列可以有效降低查詢IO，提升查詢性能。
兩組表的表結構如下（示意）：
-- 不帶二級類目維度的aipl表
CREATE TABLE `aipl_[001-020]` (
`customer_id` bigint,
`brand_id` bigint,
`aipl_status` int,
`day` bigint
)
DISTRIBUTE BY HASH(`customer_id`)
PARTITION BY VALUE(day)
CLUSTERED BY (`brand_id`,`aipl_status`)
-- 帶二級類目維度的aipl表
CREATE TABLE `aipl_cate_[001-020]` (
`customer_id` bigint,
`brand_id` bigint,
`cate_id` bigint,
`aipl_status` int,
`day` bigint
)
DISTRIBUTE BY HASH(`customer_id`)
PARTITION BY VALUE(day)
CLUSTERED BY (`brand_id`,`cate_id`, `aipl_status`)2、標籤
一般由於有多值標籤存在（例如一個消費者可以有多個興趣愛好），標籤表會設計爲kv結構，如下（示意）：
CREATE TABLE `tag` (
`customer_id` bigint,
`tag_key` int,
`tag_value` int
)
DISTRIBUTE BY HASH(`customer_id`)但是數據銀行在人羣圈選時是可以選擇多個標籤進行交併差的，使用kv結構會導致多個標籤值的消費者ID集合在內存中做交併差，性能較差。
利用AnalyticDB的多值列（multivalue/或者json列），數據銀行的標籤表的表結構如下（示意）：
CREATE TABLE `tag` (
`customer_id` bigint,
`tag1` int,
`tag2` int,
`tag3` multivalue,
......
)
DISTRIBUTE BY HASH(`customer_id`)多個標籤的交併差在底層會轉換成標籤表的AND / OR關係。但是由於標籤較多，200多列的表不僅在導入性能上較慢，同時由於填入了較多的空值（customer_id在某個標籤下如果沒有值，會填充特定的值）導致數據膨脹得較爲厲害，所以類似於AIPL的拆分，標籤表也按不同的主題拆分成了十幾張表。
人羣圈選加速
數據銀行會將用戶圈選的人羣固化下來（即保存消費者ID列表）用於後續操作，由於人羣圈選會涉及到數十個子查詢的交併差，圈選的時間長，中間結果可能會很大，所以數據銀行會把一次圈選拆分爲多個查詢分片，發送到ADB執行，最後將每個分片的查詢結果（消費者ID列表）在ETL中進行交併差，完成人羣圈選。
整個人羣圈選過程充分利用了ADB的索引能力和在離線混合負載能力，不但能加快人羣圈選的速度，還能提高整體資源的利用率，特別是條件篩選率較高的查詢（如涉及到AIPL的人羣圈選）。同時ADB的雲原生彈性能也能輕鬆應對雙十一的峯值壓力。
業務價值
總體來說，AnalyticDB對數據銀行的業務價值主要體現在如下幾個方面：
1、高性能的OLAP引擎：在數據銀行高達22萬億條數據，佔用1.6P存儲空間的背景下，實現了平均3-5秒的查詢響應，支撐數據銀行秒級OLAP的產品實現，爲用戶提供了靈活高效的分析工具。
2、成本大幅下降：數據在使用AnalyticDB冷熱分層存儲後+按量付費模式後，在保證性能的同時，使用成本大幅下降，相比上一代版本，成本下降約46%。
3、應對大促的彈性能力，數據銀行基於AnalyticDB實現的混合人羣圈選模式，在大促期間，利用AnalyticDB的雲原生彈性能力，可以實現快速擴展資源以應對峯值。
原文鏈接
本文爲阿里雲原創內容，未經允許不得轉載。