新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計(jì)應(yīng)用 > DSP很難學(xué)?一文讀懂系統(tǒng)技術(shù)架構(gòu)

DSP很難學(xué)?一文讀懂系統(tǒng)技術(shù)架構(gòu)

作者: 時間:2017-12-07 來源:網(wǎng)絡(luò) 收藏

  前面基本已經(jīng)將的典型模式、主要機(jī)制及要點(diǎn)都介紹了??赡苡行┩瑢W(xué)會好奇系統(tǒng)內(nèi)部的技術(shù)架構(gòu)。下面截取部分系統(tǒng)的技術(shù)架構(gòu)圖供大家參考,同樣對于非技術(shù)的同學(xué)對此有個感性認(rèn)識即可。也不做大篇幅的展開了。

本文引用地址:http://2s4d.com/article/201712/372675.htm

  1. 技術(shù)架構(gòu)概要

  如圖7-22所示,DSP系統(tǒng)從技術(shù)架構(gòu)上涉及:投放平臺、投放設(shè)置用戶交互模塊(setup UI)、報(bào)表(Report)、算法引擎等等模塊。算法引擎模塊主要是大數(shù)據(jù)及算法的機(jī)器學(xué)習(xí)大量采用分布式技術(shù)(例如hadoop),對用戶日志、人群數(shù)據(jù)進(jìn)行建模及機(jī)器智能處理。算法引擎模塊處理好的人群數(shù)據(jù)、算法模型等等數(shù)據(jù)通過海量內(nèi)存技術(shù)(例如redis)暫存在內(nèi)存中,便于Bid投放引擎快速查詢使用,全部暫存在內(nèi)存中的目的是為了在100ms完成競價過程,確保在DSP方<30ms處理完成,為網(wǎng)絡(luò)通訊流出時間。Bid投放引擎是典型的大集群模式用于響應(yīng)大并發(fā)的請求,且確保每個請求<30ms處理完成。Bid投放引擎的投放規(guī)則(預(yù)算、頻次、投放策略設(shè)置等等數(shù)據(jù))也都是存在內(nèi)存中的便于快速查詢。投放策略設(shè)置的數(shù)據(jù)內(nèi)容都是用戶通過投放設(shè)置用戶交互模塊中的界面完成的。另外還有一些十分重要的輔助模塊,例如:廣告曝光點(diǎn)擊數(shù)據(jù)回收模塊、idmapping模塊、大數(shù)據(jù)報(bào)表模塊、內(nèi)置DMP模塊等等。

    

  圖7-22 技術(shù)架構(gòu)概要示例

  2. DSP內(nèi)部技術(shù)處理流程概要

  DSP內(nèi)部技術(shù)處理主要依賴一些關(guān)鍵技術(shù)處理設(shè)施,主要的包括:原始海量log系統(tǒng)、海量消息并行處理隊(duì)列(例如采用spark技術(shù))、海量內(nèi)存系統(tǒng)(例如采用redis技術(shù))、業(yè)務(wù)系統(tǒng)關(guān)系型數(shù)據(jù)數(shù)據(jù)庫等等。如圖7-23所示,一條技術(shù)處理線路是廣告請求處理線:廣告競價Bidder海量的實(shí)時廣告請求處理會產(chǎn)生海量的原始log、同時Bidder也頻繁的同海量內(nèi)存系統(tǒng)交互讀寫廣告請求相關(guān)的頻次、消耗等等數(shù)據(jù),然后廣告請求log經(jīng)過過并行處理隊(duì)列處理灌入報(bào)表數(shù)據(jù)庫及相應(yīng)的大數(shù)據(jù)人群及模型數(shù)據(jù)庫。另一條技術(shù)處理線路是廣告曝光、點(diǎn)擊等等監(jiān)測數(shù)據(jù)的回收,開始也是產(chǎn)生大量的原始log、同時數(shù)據(jù)回收引擎同海量內(nèi)存系統(tǒng)交互寫如廣告曝光、點(diǎn)擊相關(guān)的頻次、消耗等等數(shù)據(jù)。然后廣告曝光、點(diǎn)擊log經(jīng)過過并行處理隊(duì)列處理灌入相應(yīng)報(bào)表數(shù)據(jù)庫及相應(yīng)的大數(shù)據(jù)人群及模型數(shù)據(jù)庫,同時并行處理隊(duì)列進(jìn)行大量的機(jī)器智能分析更新部分人群數(shù)據(jù)及模型數(shù)據(jù),同時同步更新到Bidder數(shù)據(jù)庫及內(nèi)容系統(tǒng)中供Bidder實(shí)時競價時使用。

    

  圖7-23 DSP內(nèi)部技術(shù)處理流程概要示例

  3. DSP競價核心處理流程概要(<30ms)

  如圖7-24所示,DSP的Bidder競價模塊設(shè)計(jì)約束核心處理時間極短,<30ms。為了解決適配不同ADX流量的不同接口。在接受廣告請求,及輸出返回時,會針對不同ADX平臺接口使用適配器設(shè)計(jì)模式采用不同適配器予以處理。但整體處理流程不變。中間業(yè)務(wù)處理部分也使用過濾器的設(shè)計(jì)模式,增加新業(yè)務(wù)時根據(jù)業(yè)務(wù)需要增加過濾器實(shí)現(xiàn)即可。這樣做的好處是整體的Bidder競價核心模塊處理流程框架相對穩(wěn)定,不會隨這業(yè)務(wù)的變化而變化。具備十分強(qiáng)大的業(yè)務(wù)靈活性和應(yīng)對高性能的水平擴(kuò)充性。

    

  圖7-24 DSP競價核心處理流程概要示例

  4. 競價程序處理過程概要

  如圖7-25所示,Bidder競價處理器內(nèi)部也會依據(jù)業(yè)務(wù)處理依次分為:索引器快速過濾廣告(采用索引器的好處是檢索效率極高,當(dāng)然索引器僅能用戶簡單的過濾條件,例如:尺寸索引、平臺及廣告位索引、瀏覽器索引、操作系統(tǒng)索引、地域索引等等)。廣告過濾(投放策略相關(guān)規(guī)則需計(jì)算的過濾條件是無法使用索引器,例如:預(yù)算、曝光、日期、頻次、人群定向、創(chuàng)意類型等等)。上述這兩層過濾都是為了廣告請求過濾可供投放的候選廣告列表,然后通過出價算法的處理給出該廣告列表中各廣告的出價(這里可能會用到動態(tài)出價算法,也可能使用的固定出價策略(采用何種出價策略及是否使用算法都是在投放設(shè)置界面中有人工設(shè)設(shè)置的))。然后會進(jìn)行低價過濾(根據(jù)廣告請求中的底價過濾掉出價低于底價的那些候選廣告)。最后排序并決策勝出(根據(jù)各候選廣告的出價及算法附帶給出的優(yōu)先級權(quán)重綜合排序,排名第一的勝出,即將以該廣告內(nèi)容準(zhǔn)備競價返回)。曝光點(diǎn)擊動態(tài)代碼生成(以上一步勝出的廣告內(nèi)容生成曝光點(diǎn)擊動態(tài)代碼,生成動態(tài)曝光點(diǎn)擊代碼有很多目的,例如防作弊,全程攜帶投放參數(shù)追蹤等等)。Bid/Unbid日志記錄(結(jié)束處理時異步啟動)。

    

  圖7-25競價程序處理過程概要示例

  5. 分布式集群概要

  如圖7-26所示,為了應(yīng)對海量的廣告競價業(yè)務(wù)需要,及大數(shù)據(jù)的分布式計(jì)算基礎(chǔ)設(shè)施的需要。DSP在系統(tǒng)架構(gòu)設(shè)計(jì)上需要支持分布式支持水平擴(kuò)容,架構(gòu)支持大并發(fā)、大數(shù)據(jù)、高可用、高容錯等等特征。

    

  圖7-26 分布式集群概要示例



關(guān)鍵詞: DSP

評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉