可能有些同學會好奇DSP系統內部的技術架構。下面截取部分DSP系統的技術架構圖供大家參考，同樣對于非技術的同學對此有個感性認識即可。也不做大篇幅的展開了。

1. 技術架構概要

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

圖7-22 技術架構概要示例

2. DSP內部技術處理流程概要

DSP內部技術處理主要依賴一些關鍵技術處理設施，主要的包括：原始海量log系統、海量消息并行處理隊列（例如采用spark技術）、海量內存系統（例如采用redis技術）、業務系統關系型數據數據庫等等。如圖7-23所示，一條技術處理線路是廣告請求處理線：廣告競價Bidder海量的實時廣告請求處理會產生海量的原始log、同時Bidder也頻繁的同海量內存系統交互讀寫廣告請求相關的頻次、消耗等等數據，然后廣告請求log經過過并行處理隊列處理灌入報表數據庫及相應的大數據人群及模型數據庫。另一條技術處理線路是廣告曝光、點擊等等監測數據的回收，開始也是產生大量的原始log、同時數據回收引擎同海量內存系統交互寫如廣告曝光、點擊相關的頻次、消耗等等數據。然后廣告曝光、點擊log經過過并行處理隊列處理灌入相應報表數據庫及相應的大數據人群及模型數據庫，同時并行處理隊列進行大量的機器智能分析更新部分人群數據及模型數據，同時同步更新到Bidder數據庫及內容系統中供Bidder實時競價時使用。

圖7-23 DSP內部技術處理流程概要示例

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

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

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

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

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

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

5. 分布式集群概要

如圖7-26所示，為了應對海量的廣告競價業務需要，及大數據的分布式計算基礎設施的需要。DSP在系統架構設計上需要支持分布式支持水平擴容，架構支持大并發、大數據、高可用、高容錯等等特征。

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