作者：崚嶒（楊然）資料技術及産品部-進階技術專家
前言
資料銀行是一款品牌消費者營運的商業資料産品，由于其核心分析能力需要在海量資料上實作任意次元自由分析和響應時間上的強需求，我們大規模使用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的雲原生彈性能力，可以實作快速擴充資源以應對峰值。
随時歡迎技術圈的小夥伴們過來交流^_^：
AnalyticDB詳情見：
産品詳情AnalyticDB産品試用：
産品試用AnalyticDB知乎公衆号：
雲原生資料倉庫AnalyticDB開發者社群公衆号：
AnalyticDB開發者釘釘群：23128105