Twitter重構了廣告平臺,twitter有哪些廣告位-ESG跨境

Twitter重構了廣告平臺,twitter有哪些廣告位

Twitter重構了廣告平臺

軟件系統(tǒng)的一大優(yōu)點是它們具有極強的適應性。然而，在復雜軟件系統(tǒng)的演進過程中，這種可塑性會阻礙而不是促進其發(fā)展。在某種程度上，軟件將進入一個不再服務于其目的——為人們提供幫助——的階段。

這就是2019年初Twitter AdServer的情況。經(jīng)過10年的迭代開發(fā)之后，系統(tǒng)的效率已經(jīng)太低，無法與組織的發(fā)展保持同步。剛開始的時候，我們是一個非常小的工程師團隊，只提供單一類型的廣告格式（推廣推文），創(chuàng)造了大約2800萬美元的收入。如今，Twitter的收入組織包括10倍以上的工程師和約30億美元的收入，支持多種廣告格式——品牌、視頻、卡片。

新產(chǎn)品發(fā)布慢，團隊之間緊密依賴，管理成本很高，這些都增加了組織的復雜性。為了進一步擴大規(guī)模，我們就得進行根本性的改革。

我們是如何投放廣告的

AdServer漏斗（funnel）主要由Admixer和Adshard組成。Admixer是上游客戶端和AdServer管道之間的接口。當Admixer收到一個廣告請求時，在將請求分發(fā)給Adshard之前，它會將額外的用戶信息補充到請求中。Adshard在分片架構下運行，每個Adshard負責一個廣告子集，通過AdServer漏斗的3個主要階段運行請求：

·候選項選擇：為用戶選擇一組有效的活動子項（即一組具有相同目標市場選擇標準的廣告；有關詳細信息，請參考活動子項定義）。在這一階段，（1）我們應用了所有標準的活動目標選擇條件，最終為用戶提供符合條件的廣告（例如地理位置、年齡、興趣等）；（2）剔除用戶可能不喜歡的不相關的廣告；（3）確保我們只提供有效的廣告（例如，只提供沒有結束的活動）。

·產(chǎn)品邏輯：此階段根據(jù)一些業(yè)務規(guī)則將來自候選項選擇階段的每個活動子項擴展為一組創(chuàng)意，并添加額外的產(chǎn)品特性豐富這些創(chuàng)意。（創(chuàng)意是實際展示給用戶的廣告，例如一條推廣推文——請參考創(chuàng)意定義了解更多細節(jié)）。

·候選項排名：完成上述階段后，對廣告進行排名。每個廣告都會得到一個分數(shù)（表示用戶瀏覽該廣告的可能性），并根據(jù)這個分數(shù)對廣告進行排名。我們使用一些實時訓練的機器學習模型和廣告客戶數(shù)據(jù)來計算我們在競價管道中使用的分數(shù)。

在這個漏斗中，不同的組件還附加了與廣告請求和廣告候選相關聯(lián)的元數(shù)據(jù)，并會將這些元數(shù)據(jù)寫入AdMixer中我們的底層鍵值存儲中。稍后，在反饋循環(huán)中，分析管道將使用這些數(shù)據(jù)，用于賬單、欺詐檢測和其他分析。

過去，我們是通過盡可能減少網(wǎng)絡跳數(shù)來優(yōu)化系統(tǒng)，以最小化延遲和操作開銷。這導致單個服務（即Adshard）完成了大部分繁重的工作，進而形成了一個單體模型。

熵增

當Twitter只有兩種廣告產(chǎn)品——推廣推文和推廣賬戶時，這個單體平臺運行得很好。然而，當我們擴大業(yè)務時，單體模式帶來的挑戰(zhàn)便多于解決方案了。

新增一個廣告產(chǎn)品

在舊的Adserver中，由于遺留代碼的挑戰(zhàn)和復雜性，重用現(xiàn)有模式和實踐就成了常態(tài)。上圖是一個在舊的AdServer上新增一個廣告產(chǎn)品（如推廣趨勢）的例子。該廣告產(chǎn)品具有以下特點：

1.應該總是根據(jù)條件Geo==Country選取；

2.應該不需要競價，從而可以跳過排名階段。

通常，新增一個廣告產(chǎn)品需要做一些零零碎碎的工作。考慮到現(xiàn)有框架的性質(zhì)和其他遺留代碼的約束，跳過排名階段不是可行的選項，于是我們采用了一種不合常規(guī)的變通方法，在排名管道里向代碼中添加基于產(chǎn)品的條件邏輯if(producttype==PROMOTEDTREND){...}else{..}。這種基于產(chǎn)品的邏輯也存在于選擇管道中，導致了這些階段緊密耦合，增加了日益增多的意大利面式代碼的復雜性。

開發(fā)速度

下面是所有基于大量的遺留代碼進行開發(fā)的團隊都面臨的一些挑戰(zhàn)。

·過度膨脹的數(shù)據(jù)結構：請求和響應對象的大小隨著業(yè)務邏輯的增加而快速增長。由于請求/響應對象在這3個階段中共享，所以不變性保證是一項挑戰(zhàn)。在候選排名階段添加一個新特性，需要了解該特性所需的字段在上游（選擇和創(chuàng)意階段）和下游（Admixer）是在何處如何設置的。要想修改的話，就幾乎需要了解整個服務管道。這是一個令人畏縮的過程，尤其是對新工程師來說。

·數(shù)據(jù)訪問挑戰(zhàn)：從歷史上看，Admixer一直是負責獲取用戶相關數(shù)據(jù)的服務，這主要是為了延遲和資源優(yōu)化。（由于采用分片架構，在Adshard中獲取相同的用戶數(shù)據(jù)需要25x RPC）。因此，要在Adshard中使用一個新屬性，我們需要在Admixer中添加相應的用戶數(shù)據(jù)獲取器，并將其發(fā)快遞給Adshard。這個過程非常耗時，并且，取決于用戶屬性的類型，可能會對AdServer的性能產(chǎn)生影響。這個過程也使得解耦平臺與產(chǎn)品變得非常具有挑戰(zhàn)性。

·技術債務：復雜的遺留代碼增加了技術債務。棄用舊字段以及清理未使用代碼的風險越來越大。這通常會導致功能的意外更改，引入bug并拉低整體生產(chǎn)力。

解決方案：我們?nèi)绾卧O計這些服務

這些長期存在的工程問題以及開發(fā)人員的生產(chǎn)力損失，使得我們需要改變系統(tǒng)設計的范式。我們在架構中缺乏明確的關注點分離，并且不同的產(chǎn)品領域之間高度耦合。

在軟件行業(yè)中，這些問題相當常見，而將單體分解成微服務是解決這些問題的流行方法。然而，它本身也是有利有弊，如果倉促設計，反而會導致生產(chǎn)率降低。讓我們通過一個例子看下分解服務時可能采用的一種方法。

服務分解思考練習：每個產(chǎn)品一個AdServer

由于單體AdServer對每個產(chǎn)品團隊而言都是一個瓶頸，而不同的產(chǎn)品可能有不同的架構需求，所以我們可以選擇將單個AdServer分解為N個不同的AdServer，每個產(chǎn)品一個，或者一組類似的產(chǎn)品一個。

在上面的架構中，我們有三個不同的AdServer，分別用于Video Ad Product、Takeover Ad Product和Performance Ad Product。它們由各自的產(chǎn)品工程團隊負責，每個團隊都有自己的代碼庫和部署管道。這似乎提供了自主性，并有助于分離關注點，解耦不同的產(chǎn)品領域，然而，實際上，這樣的分離可能會使事情變得更糟。

現(xiàn)在，每個產(chǎn)品工程團隊都必須增加人手來維護整個AdServer。每個團隊都必須維護和運行自己的候選生成和候選排名管道，即使他們很少修改它們（這些通常是由機器學習領域?qū)＜邑撠熜薷模?。對于這些領域，情況變得更糟?，F(xiàn)在，要發(fā)布一個用于廣告預測的新特性，我們需要修改三個不同服務的代碼，而不是一個最后，很難確保來自所有AdServer的分析數(shù)據(jù)和日志能夠融合到一起，以確保下游系統(tǒng)的正常運行（分析是跨產(chǎn)品的橫切關注點）。

經(jīng)驗總結

我們認識到，僅僅分解是不夠的。我們在上面為每個產(chǎn)品構建的AdServer架構既缺少內(nèi)聚性)（每個AdServer仍然做了太多的事情），也缺少可重用性（例如，在所有三個服務中都運行著的廣告候選排名）。我們突然認識到，如果我們要為產(chǎn)品工程團隊提供自主性，就必須用可以跨產(chǎn)品重用的橫向平臺組件來為他們提供支持為橫切關注點提供即插即用的服務可以為工程團隊創(chuàng)造乘數(shù)效應。

我們構建了橫向平臺組件

因此，我們確定了可以被大多數(shù)廣告產(chǎn)品直接使用的“通用廣告技術功能”，包括：

·候選項選擇：給定用戶屬性，確定可以針對用戶需求展開競逐的廣告候選項。

·候選項排名：給定用戶屬性和廣告候選項，根據(jù)與用戶的相關性給廣告候選項打分。

·回調(diào)和分析：定義契約，標準化所有提供廣告服務的服務的分析數(shù)據(jù)集。

我們圍繞這些功能構建服務，并將自己重組為平臺團隊，每個團隊擁有其中一個功能。以前架構中的產(chǎn)品AdServer現(xiàn)在變成了更精簡的組件，它們依賴于橫向平臺組件，并在其上構建特定于產(chǎn)品的邏輯。

好處

便于添加新產(chǎn)品

讓我們重新審視上面提到的與聚光燈廣告有關的問題，以及新架構如何處理這個問題。通過構建不同的廣告候選項選擇服務和廣告候選項排名服務，我們可以更好地將關注點分離開來。它打破了廣告產(chǎn)品必須采用AdServer管道的3階段范式這一模式。現(xiàn)在，聚光燈廣告有了靈活性，可以只與選擇服務集成，使得這些廣告可以跳過排名階段。這讓我們擺脫了為繞過推廣趨勢廣告排名而采用的笨拙方法，實現(xiàn)了一個更干凈、更健壯的代碼庫。

隨著廣告業(yè)務的持續(xù)增長，添加新產(chǎn)品將會很容易，只要在需要的時候引入這些橫向平臺服務就可以了。

提升速度

通過定義良好的API，我們可以在團隊之間實現(xiàn)職責分離。修改候選項排名管道不需要理解選擇或創(chuàng)意階段。這是一種雙贏的局面，每個團隊只需要理解和維護他們自己的代碼，這讓他們可以更快地采取行動。這也使得故障更加容易診斷，因為我們可以隔離服務中的問題并獨立地測試它們。

風險與利弊

在Twitter，這種廣告模式的轉變必然會伴隨著風險和權衡。我們想列出其中一些，以提醒讀者，在決定對現(xiàn)有系統(tǒng)進行大規(guī)模重構之前，必須識別和承認存在的弊端。

·增加硬件成本：從一個服務創(chuàng)建許多不同的服務無疑意味著增加運行這些系統(tǒng)的計算成本。為了確保增長在可接受的范圍內(nèi)，我們?yōu)樽约涸O定了一個具體目標，將廣告服務系統(tǒng)的運營成本控制在收入的5%以內(nèi)。這有助于我們在需要的時候優(yōu)先考慮效率，讓我們更容易做出設計決策。就計算資源而言，新架構的開銷大約是前一個架構的兩倍，但這在我們可以接受的限度之內(nèi)。

·增加了產(chǎn)品開發(fā)團隊的運營成本：擁有多個新服務意味著維護和運營這些服務的工程成本，其中一些新增的負擔落在了產(chǎn)品開發(fā)團隊身上（而不是像之前那樣更多地落在平臺團隊身上）。這意味著除了要加速開發(fā)新特性外，產(chǎn)品開發(fā)團隊還需要適當?shù)爻砷L以支持他們擁有的新系統(tǒng)。

·新特性開發(fā)的暫時放緩：這項工作需要花費超過40名工程師以及工程和產(chǎn)品經(jīng)理1.5年的時間。我們估計，在此期間，新特性的開發(fā)速度會降低大約15%（主要是在廣告服務方面）。為了支持這個項目，組織負責人會愿意做出這樣的權衡。

·競價排名的復雜性增加：這是對新架構的技術考量——由于每個產(chǎn)品負責人都服務于自己的請求，我們部分失去了在更低粒度上對廣告排名和競價做出全局最優(yōu)決策的能力。通過將這種邏輯轉移到更高粒度的集中式平臺服務上，可以在某種程度上彌補這一點。

我們評估了這些風險，并且確定，新架構的好處大于這些風險造成的影響。整體開發(fā)速度的提高和更可預測的特性改進交付，對于我們?yōu)樽约涸O定的雄心勃勃的業(yè)務目標至關重要。新架構提供了一個模塊化系統(tǒng)，讓我們可以更快的試驗，并降低了耦合度。

我們已經(jīng)開始看到這種決策的好處了：

·對于大多數(shù)規(guī)劃好的項目，沒有一個團隊會成為瓶頸，而在規(guī)劃好的廣告服務項目中，90%以上的都可以執(zhí)行。

·試驗速度快了許多——在廣告服務空間進行的在線排名試驗現(xiàn)在快了50%。

遷移

多個團隊每天都推快遞新代碼這樣一個部署節(jié)奏，再加上數(shù)十萬QPS的龐大規(guī)模，使得AdServer的分解非常具有挑戰(zhàn)性。

在開始遷移時，我們采用了內(nèi)存內(nèi)API優(yōu)先的方法，對代碼進行邏輯分離。另外，這還使我們能夠運行一些初始的系統(tǒng)性能分析，保證與舊系統(tǒng)相比，CPU和內(nèi)存占用的增量是可接受的。這奠定了橫向平臺服務的基礎，這些基本服務源自重構代碼并重新安排內(nèi)存版本的打包結構。

為了確保新舊服務在功能上的一致性，我們開發(fā)了一個自定義的正確性評估框架。它分別針對舊AdServer和新AdServer重放了請求，以便在可接受的閾值內(nèi)比較兩個系統(tǒng)的指標。我們在離線測試中使用了這種方法，借此我們可以了解新系統(tǒng)的性能。它幫助我們及早發(fā)現(xiàn)問題，防止錯誤進入生產(chǎn)環(huán)境。

在將代碼發(fā)國際快遞生產(chǎn)環(huán)境后，我們使用了一個試驗框架，讓我們可以洞察生產(chǎn)環(huán)境中的總體收益指標。許多預測和競價相關的度量標準需要一個更長的反饋循環(huán)來消除噪音和評估變更的真實影響。因此，對于遷移的真正的端到端驗證，我們依賴這個框架來保證收入指標的正常。

總結

分解AdServer改善了我們系統(tǒng)的狀態(tài)，強化了Twitter廣告業(yè)務的基礎，讓我們可以把時間和資源集中在解決真正的工程問題上，而不是與遺留基礎設施的問題作斗爭。隨著廣告業(yè)務和技術的發(fā)展，更多的挑戰(zhàn)將會到來，但我們很高興能夠建立可以提高系統(tǒng)效率的解決方案。

英文原文：

https://blog.twitter.com/engineering/enus/topics/infrastructure/2020/buildingtwittersadplatformarchitectureforthefuture.html

作者TwitterEng

譯者平川

策劃Tina

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內(nèi)容、版權或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。