摘要：高性能、大容量、低成本、強(qiáng)穩(wěn)定性，廣告業(yè)務(wù)需要的Ta都有

一、從需求場景說起，什么是RTA廣告業(yè)務(wù)？

在互聯(lián)網(wǎng)時(shí)代，媒體平臺(tái)逐漸成為廣告業(yè)務(wù)的主體，而作為廣告主的企業(yè)往往每年需花費(fèi)數(shù)億甚至數(shù)十億廣告費(fèi)，卻依然難以準(zhǔn)確觸達(dá)目標(biāo)用戶，這就造成大量資金浪費(fèi)。在這樣的需求場景下，RTA廣告業(yè)務(wù)模式逐漸流行起來。

RTA 即Realtime API的簡稱，是一套接口服務(wù)，用于滿足廣告主實(shí)時(shí)個(gè)性化的投放需求，在競價(jià)中減少資金浪費(fèi)。簡單來說，RTA大體流程如下：

1. 媒體在將廣告曝光給用戶前，先通過RTA接口詢問廣告主是否參與本次競價(jià)；
2. 廣告主結(jié)合自己的__畫像數(shù)據(jù)（一般是百GB~數(shù)TB的key-value數(shù)據(jù)）__進(jìn)行決策，快速響應(yīng)媒體側(cè)，表明是否要參與本次曝光競價(jià)，以及具體的曝光策略；
3. 媒體平臺(tái)根據(jù)價(jià)高者得原則，進(jìn)行精準(zhǔn)目標(biāo)廣告投放。

RTA廣告業(yè)務(wù)流程圖

RTA讓廣告投放變得更精準(zhǔn)，更省錢，還可以滿足許多不同的投放需求，例如獲取新用戶、召回流失用戶等。

二、聊聊RTA中的數(shù)據(jù)存儲(chǔ)選型

對(duì)廣告主來說，RTA業(yè)務(wù)價(jià)值明顯，但媒體側(cè)可是設(shè)置了不小的技術(shù)門檻，一般要求RTA系統(tǒng)高峰承載20w+ QPS，50到100ms快速響應(yīng)。當(dāng)不達(dá)標(biāo)時(shí)，媒體側(cè)會(huì)有降級(jí)和清退機(jī)制，例如暫時(shí)關(guān)閉廣告主的RTA接入通道。

因此，RTA業(yè)務(wù)的首要需求是使用靠譜的畫像數(shù)據(jù)庫：

1. 毫秒級(jí)響應(yīng)，支持?jǐn)?shù)十萬級(jí)QPS
2. 穩(wěn)定性高，關(guān)鍵時(shí)刻不能掉鏈子
3. 支持百GB~數(shù)TB的畫像存儲(chǔ)，且成本可控

根據(jù)經(jīng)驗(yàn)，很多公司會(huì)使用開源Redis集群來做這件事，但其實(shí)__開源Redis并不太適合這類大數(shù)據(jù)場景：__

一方面，雖然開源Redis并發(fā)性能和響應(yīng)都很優(yōu)秀，但終究只是緩存，無法提供數(shù)據(jù)庫級(jí)的穩(wěn)定性保障，丟數(shù)據(jù)、fork抖動(dòng)、分片不均OOM、擴(kuò)容耗時(shí)久等等，都是很常見的問題。

另一方面，由于開源Redis中存放的數(shù)據(jù)無法突破內(nèi)存限制，上百GB的數(shù)據(jù)存儲(chǔ)價(jià)格非常昂貴，例如512GB規(guī)格的開源Redis接近5w/月。

在這類大數(shù)據(jù)業(yè)務(wù)場景下，我們推薦使用華為云數(shù)據(jù)庫GaussDB(for Redis)做畫像數(shù)據(jù)存儲(chǔ)。

三、大數(shù)據(jù)業(yè)務(wù)存儲(chǔ)神器：華為云數(shù)據(jù)庫GaussDB(for Redis)

GaussDB(for Redis)是華為云企業(yè)級(jí)存算分離Redis數(shù)據(jù)庫，使用上與開源Redis別無二致，并且能夠兼顧緩存與存儲(chǔ)兩類典型場景：

1. 內(nèi)存+分布式存儲(chǔ)池（Nvme SSD），提供毫秒級(jí)響應(yīng)速度，并實(shí)現(xiàn)了大幅降本
2. 命令兼容度>98%，業(yè)務(wù)零改造平遷
3. 容量最大支持36TB，高壓縮比，且保障數(shù)據(jù)庫級(jí)別可靠存儲(chǔ)
4. 算力用多少買多少，支持水平擴(kuò)展到千萬級(jí)QPS
5. 無感熱擴(kuò)容，128GB到512GB也只需一秒
6. 支持多DB租戶訪問權(quán)限隔離（增強(qiáng)版ACL）

RTA廣告業(yè)務(wù)對(duì)畫像存儲(chǔ)的核心需求是：響應(yīng)快、穩(wěn)定性高、大容量且不貴，GaussDB(for Redis)充分滿足這類大數(shù)據(jù)業(yè)務(wù)需求。

• 超低時(shí)延，性能滿足媒體側(cè)要求

根據(jù)現(xiàn)網(wǎng)的案例經(jīng)驗(yàn)，在數(shù)十萬QPS流量下，GaussDB(for Redis)可穩(wěn)定保持平均時(shí)延1ms，p99時(shí)延2ms。

媒體側(cè)一般對(duì)廣告主端到端響應(yīng)要求在50~100ms，這其中包括了業(yè)務(wù)及網(wǎng)絡(luò)鏈路的耗時(shí)，GaussDB(for Redis)可以很好地滿足響應(yīng)要求，并給業(yè)務(wù)鏈路留有充足的余量。

為什么GaussDB(for Redis)在存算分離的架構(gòu)下還能提供低時(shí)延訪問？

1. 自動(dòng)冷熱分離，計(jì)算層的內(nèi)存資源會(huì)被用來充分加速熱數(shù)據(jù)
2. 存儲(chǔ)池是基于高性能Nvme SSD和RDMA網(wǎng)絡(luò)所構(gòu)建，響應(yīng)速度其實(shí)也很快

實(shí)際上，響應(yīng)快速并非內(nèi)存的專利，Nvme SSD同樣有優(yōu)秀的時(shí)延表現(xiàn)，下圖是市面上某款Nvme SSD的性能指標(biāo)：

• 作為存算分離的數(shù)據(jù)庫，穩(wěn)定性遠(yuǎn)超緩存Redis

開源Redis的穩(wěn)定性問題存在已久，單線程、fork機(jī)制、Gossip協(xié)議……這些都是讓開源Redis穩(wěn)定性不夠好的原因。在小數(shù)據(jù)量緩存場景問題不一定經(jīng)常出現(xiàn)，但在百GB的大數(shù)據(jù)存儲(chǔ)場景下很容易成為打破系統(tǒng)穩(wěn)定的隱患。

GaussDB(for Redis)存算分離架構(gòu)對(duì)穩(wěn)定性的提升是巨大的。在擴(kuò)容場景，只需調(diào)整存儲(chǔ)池配合，即可1秒完成擴(kuò)容，業(yè)務(wù)0感知。由于數(shù)據(jù)全部存儲(chǔ)在分布式存儲(chǔ)池中，當(dāng)計(jì)算節(jié)點(diǎn)發(fā)生故障，數(shù)據(jù)依然可見，業(yè)務(wù)只感知秒級(jí)抖動(dòng)。同時(shí)，也不會(huì)發(fā)生分片數(shù)據(jù)不均OOM問題。

• 存儲(chǔ)百GB畫像數(shù)據(jù)，比緩存Redis成本節(jié)省 50%以上

GaussDB(for Redis)在這類場景下能夠幫助企業(yè)實(shí)現(xiàn)有效降本，原因是：

1. 內(nèi)存+分布式存儲(chǔ)池（Nvme SSD）

開源Redis技術(shù)上無法突破內(nèi)存限制，因此成本會(huì)隨著每漲1GB而線性增長，大數(shù)據(jù)業(yè)務(wù)中很容易帶來成本痛點(diǎn)。

GaussDB(for Redis)分布式存儲(chǔ)池采用的高性能Nvme SSD硬件成本雖然比普通SSD高，但是跟內(nèi)存相比還是比較高性價(jià)比的。另外還支持根據(jù)實(shí)際所需QPS購買計(jì)算節(jié)點(diǎn)，避免不必要的算力成本浪費(fèi)。

2. 高壓縮比

很多畫像類業(yè)務(wù)使用protobuf格式，GaussDB(for Redis)采用了邏輯數(shù)據(jù)+塊數(shù)據(jù)雙重壓縮機(jī)制，對(duì)于protobuf的壓縮比效果很好。根據(jù)現(xiàn)網(wǎng)案例經(jīng)驗(yàn)，500GB的protobuf數(shù)據(jù)寫入GaussDB(for Redis)后，實(shí)際占用的存儲(chǔ)空間可壓縮到160G，壓縮率30%。

四、總結(jié)

RTA廣告競價(jià)業(yè)務(wù)近年來發(fā)展?jié)摿薮?，一方面要滿足媒體側(cè)的性能指標(biāo)要求，另一方面又要承擔(dān)企業(yè)降本重任。在這類典型大數(shù)據(jù)業(yè)務(wù)中，往往需要一款能夠兼顧性能與存儲(chǔ)降本需求的KV數(shù)據(jù)庫來做畫像存儲(chǔ)，華為云數(shù)據(jù)庫GaussDB(for Redis)無論從性能、穩(wěn)定性，還是大容量、低成本，都充分滿足這類場景的需求，是其最佳存儲(chǔ)選型。
審核編輯：湯梓紅