共計 4859 個字符，預計需要花費 13 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關 AnalyticDB 是怎樣支撐數據銀行超大規模低成本實時分析，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
前言
數據銀行是一款品牌消費者運營的商業數據產品，由于其核心分析能力需要在海量數據上實現任意維度自由分析和響應時間上的強需求，我們大規模使用 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 是怎樣支撐數據銀行超大規模低成本實時分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
