AnalyticDB是怎樣支撐數(shù)據(jù)銀行超大規(guī)模低成本實(shí)時(shí)分析

這篇文章將為大家詳細(xì)講解有關(guān)AnalyticDB是怎樣支撐數(shù)據(jù)銀行超大規(guī)模低成本實(shí)時(shí)分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

前言

數(shù)據(jù)銀行是一款品牌消費(fèi)者運(yùn)營的商業(yè)數(shù)據(jù)產(chǎn)品，由于其核心分析能力需要在海量數(shù)據(jù)上實(shí)現(xiàn)任意維度自由分析和響應(yīng)時(shí)間上的強(qiáng)需求，我們大規(guī)模使用AnalyticDB作為底層的分析引擎，最終以較低的成本，出色的性能，支撐了上萬品牌商大促期間每天百萬級(jí)的OLAP查詢。

當(dāng)前數(shù)據(jù)銀行在AnalyticDB中存儲(chǔ)了約幾十萬億條數(shù)據(jù)，占用存儲(chǔ)空間約1.6P，查詢平均響應(yīng)時(shí)間在5秒以內(nèi)。

數(shù)據(jù)銀行業(yè)務(wù)介紹

數(shù)據(jù)銀行作為消費(fèi)者運(yùn)營的商業(yè)數(shù)據(jù)產(chǎn)品，提供了鏈路流轉(zhuǎn)分析、人群圈選、人群畫像等眾多數(shù)據(jù)能力。

鏈路流轉(zhuǎn)分析

AIPL是數(shù)據(jù)銀行的特有指標(biāo)，用于衡量品牌和消費(fèi)者關(guān)系的指標(biāo)（AIPL是4個(gè)階段的縮寫，分別是A認(rèn)知、I興趣、P購買、L忠誠），鏈路流轉(zhuǎn)分析用于獲取品牌任意兩天消費(fèi)者AIPL關(guān)系的變化（如下圖，某品牌在某個(gè)類目下，從去年雙十一到今年雙十一AIPL的變化，非真實(shí)數(shù)據(jù)）。

在這個(gè)場(chǎng)景，用戶可以選擇近540天內(nèi)的任意兩個(gè)日期，加上品牌和類目這兩個(gè)維度，用戶可能的輸入情況在百萬億級(jí)別。

人群畫像

人群畫像是消費(fèi)者運(yùn)營產(chǎn)品的核心能力，數(shù)據(jù)銀行除了可以針對(duì)用戶沉淀的具體人群進(jìn)行畫像操作，還可以對(duì)鏈路流轉(zhuǎn)的人群進(jìn)行畫像以幫助品牌分析消費(fèi)者關(guān)系變化的原因（如下圖，某品牌去年雙十一是購買狀態(tài)但今年雙十一是流失狀態(tài)的人群畫像，非真實(shí)數(shù)據(jù)）。

在這個(gè)場(chǎng)景，數(shù)據(jù)銀行為用戶提供了200多個(gè)標(biāo)簽，大部分為行業(yè)相關(guān)，每次人群畫像只會(huì)涉及到部分標(biāo)簽，如果為人群預(yù)先計(jì)算所有標(biāo)簽會(huì)導(dǎo)致資源的極大浪費(fèi)。

人群圈選計(jì)算人數(shù) / 人群圈選

人群圈選是消費(fèi)者運(yùn)營產(chǎn)品的核心能力，相比大部分消費(fèi)者運(yùn)營產(chǎn)品限制用戶只能使用標(biāo)簽數(shù)據(jù)，數(shù)據(jù)銀行人群圈選（分鐘級(jí)）可以讓用戶使用標(biāo)簽、觸點(diǎn)（可以理解為消費(fèi)者行為，如購買、搜索、看直播等）等各類數(shù)據(jù)，同時(shí)用戶還可以即時(shí)查看圈選條件下消費(fèi)者的數(shù)量（秒級(jí)）。

在這個(gè)場(chǎng)景，各類圈選條件可以通過交并差自由組合，同時(shí)部分圈選條件如購買金額是讓用戶填寫的數(shù)值，無法枚舉。

數(shù)據(jù)銀行為什么選擇AnalyticDB

普通的分析業(yè)務(wù)，如果對(duì)響應(yīng)時(shí)間沒有要求，離線計(jì)算（Hadoop/Hive/Maxcompute）幾乎可以滿足所有數(shù)據(jù)分析的需要，但是從用戶在線響應(yīng)的角度出發(fā)，高頻使用的功能對(duì)響應(yīng)時(shí)間都會(huì)有強(qiáng)需求。

例如：用戶決策需要大量人群畫像的對(duì)比，而人群的選擇存在一定的依賴關(guān)系，下一個(gè)畫像人群的選擇取決于前一個(gè)人群畫像的結(jié)果。如果采用離線計(jì)算，不僅會(huì)大幅度拉長用戶的決策時(shí)間，還會(huì)打斷用戶分析思維的連續(xù)性，對(duì)用戶體驗(yàn)產(chǎn)生較大的影響。

解決響應(yīng)時(shí)間問題一般有兩種思路：

1. 預(yù)計(jì)算，把用戶所有可選維度組合下的指標(biāo)先離線計(jì)算出來，用戶在分析時(shí)，系統(tǒng)直接去數(shù)據(jù)庫取結(jié)果。

2. OLAP在線計(jì)算，把輕度聚合的數(shù)據(jù)（保留所有用戶可選維度）存放在MPP引擎中，根據(jù)用戶提交的條件，即時(shí)計(jì)算出指標(biāo)。

這兩種思路各有特點(diǎn)，預(yù)計(jì)算需要考慮維度爆炸、離線預(yù)計(jì)算無法在有限時(shí)間內(nèi)完成、或者是需求變化導(dǎo)致預(yù)先計(jì)算的結(jié)果沒有被使用導(dǎo)致的資源浪費(fèi)等一系列問題。而OLAP能夠提任意維度的自由計(jì)算，無需預(yù)先計(jì)算，但則也需要考慮MPP引擎的存儲(chǔ)成本、容量和計(jì)算性能等問題。

綜合來看，作為面向消費(fèi)者運(yùn)營的數(shù)據(jù)產(chǎn)品，對(duì)響應(yīng)時(shí)間有強(qiáng)需求，不適合使用預(yù)計(jì)算的情況；同時(shí)因?yàn)閿?shù)據(jù)量巨大（幾十萬億、PB級(jí)別），整體的成本也是一個(gè)重要的考慮點(diǎn)。

OLAP引擎選型

數(shù)據(jù)銀行的OLAP有幾大挑戰(zhàn)：

• 數(shù)據(jù)量上的挑戰(zhàn)：原始數(shù)據(jù)量非常龐大，歷史數(shù)據(jù)總量有1.6PB、22萬億條記錄，其中10張以上的萬億級(jí)大表，全部存儲(chǔ)在AnalyticDB中。

• 數(shù)據(jù)寫入性能上的挑戰(zhàn)：單日新增寫入量600億行記錄，總大小10TB，其中基線任務(wù)在每天早晨7:00 - 9:00兩小時(shí)內(nèi)完成導(dǎo)入，要求導(dǎo)入速度至少為千萬級(jí)的tps；

• 復(fù)雜查詢性能上的挑戰(zhàn)：查詢類型復(fù)雜，多為較大的復(fù)雜交互分析，2萬億級(jí)別的大表經(jīng)過篩選后再與8張表做關(guān)聯(lián)，需要在10秒內(nèi)返回。

• 導(dǎo)出性能上的挑戰(zhàn)：快速的結(jié)果集導(dǎo)出，業(yè)務(wù)中需要將分析圈選的人群做數(shù)據(jù)導(dǎo)出。需要能夠?qū)nalyticDB計(jì)算好的結(jié)果便捷、高效的導(dǎo)出到Maxcompute中。并且要求能夠支撐每分鐘20個(gè)以上的百萬級(jí)結(jié)果導(dǎo)出任務(wù)。

• 成本上的挑戰(zhàn)：考慮到PB級(jí)的數(shù)據(jù)，全部存儲(chǔ)到SSD成本太高，因此希望系統(tǒng)具備冷熱數(shù)據(jù)分層存儲(chǔ)能力，用接近離線的價(jià)格實(shí)現(xiàn)在線的性能。

• 穩(wěn)定性上的挑戰(zhàn)：復(fù)雜的工作負(fù)載，在真實(shí)線上場(chǎng)景，上面提到的3個(gè)挑戰(zhàn)會(huì)同時(shí)出現(xiàn)，要求能夠在這種復(fù)雜的workload下系統(tǒng)平穩(wěn)運(yùn)行。

通過前期技術(shù)調(diào)研和測(cè)試，選擇AnalyticDB作為數(shù)據(jù)銀行業(yè)務(wù)分析的基礎(chǔ)平臺(tái)，具體如下：

1.冷熱數(shù)據(jù)分層能力

AnalyticDB提供的數(shù)據(jù)冷熱分離這一企業(yè)級(jí)特性，可以大幅提升數(shù)據(jù)存儲(chǔ)的性價(jià)比?？梢园幢砹６冗x擇熱表（存的在ESSD）、冷表（存儲(chǔ)在OSS）和溫表（混合方式，部分存在ESSD，部分存儲(chǔ)在OSS）存儲(chǔ)，客戶完全可以按業(yè)務(wù)需求自由指定，并且冷熱策略可以任意轉(zhuǎn)換，對(duì)用戶來說是一份存儲(chǔ)，一套語法，輕松實(shí)現(xiàn)聯(lián)合查詢。我們使用的場(chǎng)景更多的是冷表為主，而且AnalyticDB針對(duì)冷表具有SSD Cache來做加速，降低成本的同時(shí)兼顧了性能。數(shù)據(jù)銀行在AnalyticDB中存儲(chǔ)幾十萬億條數(shù)據(jù)，占用存儲(chǔ)空間約2P，已經(jīng)成為數(shù)據(jù)銀行的核心數(shù)倉存儲(chǔ)，而預(yù)計(jì)未來會(huì)繼續(xù)增長。

2.高吞吐實(shí)時(shí)寫入

AnalyticDB底層采用分布并行的架構(gòu)，實(shí)現(xiàn)了極高的寫入/導(dǎo)入吞吐，海量數(shù)據(jù)可以直接以千萬級(jí)甚至億級(jí)tps實(shí)時(shí)寫入。同時(shí)針對(duì)離線聚合過的表，AnalyticDB提供了直通的batch load方式可以高吞吐直接加載數(shù)據(jù)進(jìn)行在線查詢。

強(qiáng)大的高并發(fā)、低延時(shí)實(shí)時(shí)計(jì)算能力。

三類業(yè)務(wù)查詢場(chǎng)景下對(duì)響應(yīng)時(shí)間都是強(qiáng)需求，查詢大部分是萬億大表圈選后的聚合和連接查詢，AnalyticDB使用冷數(shù)據(jù)緩存、預(yù)熱等技術(shù)，使這些查詢的平均響應(yīng)時(shí)間在10秒以下。

數(shù)據(jù)模型和表設(shè)計(jì)

數(shù)據(jù)銀行主要在AnalyticDB中存儲(chǔ)四類數(shù)據(jù)：

1、AIPL數(shù)據(jù)，即品牌和消費(fèi)者關(guān)系
2、標(biāo)簽數(shù)據(jù)，即消費(fèi)者屬性
3、觸點(diǎn)數(shù)據(jù)，即消費(fèi)者行為
4、人群數(shù)據(jù)，即數(shù)據(jù)銀行用戶在數(shù)據(jù)銀行沉淀的人群

由于所有場(chǎng)景的分析對(duì)象都是消費(fèi)者ID，所以大部分表都以消費(fèi)者ID為分布鍵，這樣可以最大避免查詢過程中的數(shù)據(jù)shuffle（重分布）。以下主要介紹AIPL和標(biāo)簽的表設(shè)計(jì)，觸點(diǎn)和人群的表設(shè)計(jì)類似，不再贅述。

1、AIPL數(shù)據(jù)

AIPL數(shù)據(jù)按天分區(qū)，但由于每天產(chǎn)生的數(shù)據(jù)量較大（500多億），即使AnalyticDB批量導(dǎo)入性能較為突出，仍然需要較長的導(dǎo)入時(shí)間，考慮到AnalyticDB不支持多級(jí)分區(qū)，我們將AIPL表從品牌維度拆分為20張子表，一方面提升導(dǎo)入性能，另一方面也能提升查詢性能。

數(shù)據(jù)銀行除了在品牌維度提供AIPL分析，用戶還可以下鉆到二級(jí)類目維度，要支持二級(jí)類目有兩種方案：

1、在原有的AIPL表上擴(kuò)展二級(jí)類目維度
2、新增一套包含二級(jí)類目維度的AIPL表

第一種方案更節(jié)省存儲(chǔ)空間，也只需要導(dǎo)入一套表；第二種方案的查詢性能更好。

經(jīng)過驗(yàn)證，我們使用了第二種方案，不包含二級(jí)類目的查詢?cè)跀?shù)據(jù)銀行中占了較大比重，當(dāng)查詢不包含二級(jí)類目時(shí)，第一種方案需要group by 消費(fèi)者ID，執(zhí)行過程會(huì)占用較大內(nèi)存，可承載的并發(fā)度較低，性能也較差。得益于AnalyticDB較低的存儲(chǔ)成本，使用第二種方案在并沒有導(dǎo)致成本大幅度增長。

同時(shí)由于品牌ID是查詢時(shí)必帶的維度，而AIPL狀態(tài)是高頻使用的維度，所以在建表時(shí)將品牌ID和AIPL狀態(tài)設(shè)置為聚集列可以有效降低查詢IO，提升查詢性能。

兩組表的表結(jié)構(gòu)如下（示意）：

-- 不帶二級(jí)類目維度的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`)

-- 帶二級(jí)類目維度的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、標(biāo)簽

一般由于有多值標(biāo)簽存在（例如一個(gè)消費(fèi)者可以有多個(gè)興趣愛好），標(biāo)簽表會(huì)設(shè)計(jì)為kv結(jié)構(gòu)，如下（示意）：

CREATE TABLE `tag` (
  `customer_id` bigint,
  `tag_key` int,
  `tag_value` int
)
DISTRIBUTE BY HASH(`customer_id`)

但是數(shù)據(jù)銀行在人群圈選時(shí)是可以選擇多個(gè)標(biāo)簽進(jìn)行交并差的，使用kv結(jié)構(gòu)會(huì)導(dǎo)致多個(gè)標(biāo)簽值的消費(fèi)者ID集合在內(nèi)存中做交并差，性能較差。

利用AnalyticDB的多值列（multivalue/或者json列），數(shù)據(jù)銀行的標(biāo)簽表的表結(jié)構(gòu)如下（示意）：

CREATE TABLE `tag` (
  `customer_id` bigint,
  `tag1` int,
  `tag2` int,
  `tag3` multivalue,
  ......
)
DISTRIBUTE BY HASH(`customer_id`)

多個(gè)標(biāo)簽的交并差在底層會(huì)轉(zhuǎn)換成標(biāo)簽表的AND / OR關(guān)系。但是由于標(biāo)簽較多，200多列的表不僅在導(dǎo)入性能上較慢，同時(shí)由于填入了較多的空值（customer_id在某個(gè)標(biāo)簽下如果沒有值，會(huì)填充特定的值）導(dǎo)致數(shù)據(jù)膨脹得較為厲害，所以類似于AIPL的拆分，標(biāo)簽表也按不同的主題拆分成了十幾張表。

人群圈選加速

數(shù)據(jù)銀行會(huì)將用戶圈選的人群固化下來（即保存消費(fèi)者ID列表）用于后續(xù)操作，由于人群圈選會(huì)涉及到數(shù)十個(gè)子查詢的交并差，圈選的時(shí)間長，中間結(jié)果可能會(huì)很大，所以數(shù)據(jù)銀行會(huì)把一次圈選拆分為多個(gè)查詢分片，發(fā)送到ADB執(zhí)行，最后將每個(gè)分片的查詢結(jié)果（消費(fèi)者ID列表）在ETL中進(jìn)行交并差，完成人群圈選。

整個(gè)人群圈選過程充分利用了ADB的索引能力和在離線混合負(fù)載能力，不但能加快人群圈選的速度，還能提高整體資源的利用率，特別是條件篩選率較高的查詢（如涉及到AIPL的人群圈選）。同時(shí)ADB的云原生彈性能也能輕松應(yīng)對(duì)雙十一的峰值壓力。

業(yè)務(wù)價(jià)值

總體來說，AnalyticDB對(duì)數(shù)據(jù)銀行的業(yè)務(wù)價(jià)值主要體現(xiàn)在如下幾個(gè)方面：

1、高性能的OLAP引擎：在數(shù)據(jù)銀行高達(dá)22萬億條數(shù)據(jù)，占用1.6P存儲(chǔ)空間的背景下，實(shí)現(xiàn)了平均3-5秒的查詢響應(yīng)，支撐數(shù)據(jù)銀行秒級(jí)OLAP的產(chǎn)品實(shí)現(xiàn)，為用戶提供了靈活高效的分析工具。
2、成本大幅下降：數(shù)據(jù)在使用AnalyticDB冷熱分層存儲(chǔ)后+按量付費(fèi)模式后，在保證性能的同時(shí)，使用成本大幅下降，相比上一代版本，成本下降約46%。
3、應(yīng)對(duì)大促的彈性能力，數(shù)據(jù)銀行基于AnalyticDB實(shí)現(xiàn)的混合人群圈選模式，在大促期間，利用AnalyticDB的云原生彈性能力，可以實(shí)現(xiàn)快速擴(kuò)展資源以應(yīng)對(duì)峰值。

關(guān)于AnalyticDB是怎樣支撐數(shù)據(jù)銀行超大規(guī)模低成本實(shí)時(shí)分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。