廣告行業的大數據處理架構實踐

廣告行業的大數據處理架構實踐

 

 

若是您但願閱讀更多的大數據機器學習的文章，請關注公衆號：QCon大數據機器學習

 

 

時間：2015年5月26日 晚20點

講師介紹：AdMaster技術副總裁，資深大數據技術專家。關注高可靠、高可用、高擴展、高性能系統服務，關注Hadoop/Storm/Spark/ElasticSearch等離線、流式及實時分佈式計算技術。曾在聯想研究院、百度基礎架構部、Carbonite China工做；擁有超過10年雲存儲、雲計算開發及架構工做經驗，多年Hadoop實戰經驗，專一於分佈式存儲、分佈式計算、大數據分析等方向，有多個發明專利，《一種分佈式文件系統及其數據訪問方法》和《一種數據備份的版本管理方法及裝置》等。曾屢次被CSDN、51CTO、IT16八、InfoQ、阿里技術邀請爲嘉賓分享Hadoop大數據在互聯網的應用。

內容大綱：

（1）、混合異構數據介紹

（2）、混合異構數據平臺架構

（3）、混合異構數據分析

（4）、廣告數據平臺與混合異構數據的融合

（5）、廣告反做弊實踐分析

（6）、AdMaster數據處理平臺架構實踐

======講座實錄======

你們晚上好，很是感謝你們的支持。

這是今天我分享的提綱，若是後面你們有問題能夠再增長的。謝謝！

首先咱們來看看混合異構數據的特色，最重要的兩個特色是混合異構數據具備不一樣的數據類型以及用戶有着不一樣的訪問速度需求。

 

你們看到我給混合異構數據進行了一個簡單分類，分爲在線數據和離線數據，中間是用虛線分開，意思是說他們沒有嚴格意義的劃分。最重要的看需求來切分。

接下來咱們來看看混合異構數據的流程，首先咱們先來看很重要的部分-數據採集

數字、字符等稱爲格式化數據；

文本、圖形、圖像、聲音、視頻等稱爲非格式化數據；

融合分析這些數據的第一步是數據的預處理，傳統企業信息系統中ETL是羣內各位最熟悉的一種預處理過程。當咱們進入大數據以後，僅僅進行數據的抽取、轉換和加載每每會帶來災難，咱們必須花費很大的努力去作數據清洗，確保寶貴的大數據算力和存儲資源用在了有價值的分析計算之上。

這是混合異構數據平臺的通常架構。

我們羣裏對此係統應該都很是熟悉了，這裏重點說兩個系統一個是Flink，一個Elasticsearch。

Flink是一個高效、分佈式、基於Java實現的通用大數據分析引擎，它具備分佈式 MapReduce一類平臺的高效性、靈活性和擴展性以及並行數據庫查詢優化方案，它支持批量和基於流的數據分析，且提供了基於Java和Scala的API。

ElasticSearch是一個基於Lucene的搜索服務器。它提供了一個分佈式多用戶能力的全文搜索引擎，基於RESTful web接口。

接下來我給你們介紹廣告數據平臺與混合異構數據的融合

首先咱們來看看廣告營銷數據的一些概念

咱們收到的廣告來源主要有展現廣告，各類SNS，以及搜索引擎等

咱們通常分兩大類，一個是全流程營銷，一個實時競價營銷。

RTB(Real-Time Bidding) 實時競價，是一種利用第三方技術在數以百萬計的網站上針對每個用戶展現行爲進行評估以及出價的競價技術，它的核心是DSP平臺（需求方平臺）。

Ad Exchange 是互聯網廣告交易平臺，像股票交易平臺同樣，實現以每一個用戶爲單位的競價交易，AdExchange聯繫的是廣告交易的買方和賣方，也就是廣告主方和廣告位擁有方。

DSP(Demand-Side Platform) 即需求方平臺。它是一個廣告主服務平臺，廣告主可在DSP平臺上設置廣告的目標受衆、投放地域、廣告出價等等。

SSP(Sell-Side Platform) 即供應方平臺。可以讓出版商也介入廣告交易，從而使它們的庫存廣告能夠得到較高的單位展現費用和售出率，從而實現收益最大化。

DMP(Data-Management Platform) 數據管理平臺，是把分散的第1、第三方數據進行整合歸入統一的技術平臺，並對這些數據進行標準化和細分，從而把這些細分結果推向現有的互動營銷環境裏。

上面圖是各個部分的關係，出版商和廣告主是核心人物

接下來我給你們講幾個廣告裏結算的方式：

1.CPM(Cost Per Mille，或者Cost Per Thousand;CostPer Impressions)這是聽的最多的。

你們注意，這裏M不是指Million。是指千人成本。

2.CPC(Cost Per Click;Cost Per ThousandClick-Through) 按點擊計費。

3.CPA(Cost Per Action)按廣告投放實際效果計費。

固然還有CPV，CPD，CPS等等，這裏我就不詳細說了。

咱們瞭解到廣告精準投放主要是指3W原則

而要作這樣的效果主要是由如下方法來分析的

其實這是一個典型的推薦系統的流程。

而主要用到的方法是以下：

核心算法主要用到有SVM，天然語言處理，聚類分析，迴歸分析，時間序列分析。

 

舉一個時間序列：同一我的在不一樣的時間段具備不一樣的角色，舉例子一個男人在上班的時候是職員，回家後就是父親的角色了。若是在上班的時候你給他推薦兒童用品，他通常不會購買的，但回家後你再推薦他就可能會購買了。

廣告數據的數據類型多樣，算法以及時效也多種，跟混合異構數據架構是融合在一塊兒的。

因此接下來咱們看看系統裏用的最多的分析方式：

對於OLAP，百度大數據部，阿里的ADS等都在追求在1000億級數據時候實現秒級查詢。

架構跟之前都有很大不同的，最重要有一塊都是基於SSD來作的。

因爲昨天看到有同窗在問反做弊的問題，我這裏特意加了一節《廣告反做弊實踐分析》

咱們總結有兩個詞無中生有，魚目混珠。

因此基於上面兩大類咱們有以下方法的區分是否做弊：

細化一下主要是URL，時間，地域，頻次，行爲等方法來識別。

前面講了那麼多理論，接下來以AdMaster的數據分析爲例給你們介紹一下數據的採集、清洗、存儲、分析、展示等整個流程。

因爲中國的基礎網絡環境的互聯互通還不完善，各種營銷數據的產生環境也相對紛亂，所以AdMaster在國內首先部署了多點分佈式數據採集架構。多點分佈式採集架構的難點在於調度策略，大數據時代的負載均衡調度已經不只僅是DNS輪詢或者傳統的多機熱備，咱們還經過一些機器學習的方法預測潛在的併發突增，經過7層數據包的解析在鏈路物理層開始對數據異常模式進行學習和識別，從而動態調度、配置負載均衡策略，提升數據質量下降偏差。AdMaster在這個領域的思路與 軟件定義網絡SDN 不謀而合。

給你們分享幾個作WebService系統優化的幾個點：cat /proc/sys/net/ipv4/tcp_mem

cat /proc/net/sockstat

cat /proc/sys/net/ipv4/tcp_max_orphans

net.netfilter.nf_conntrack_max

net.netfilter.nf_conntrack_tcp_timeout_established

舉例來講當你看到/var/log/message報kernel: Out of socket memory這樣的錯誤。

通常經過以下方法解決：cat /proc/net/sockstat

sockets: used 16886

TCP: inuse 82422 orphan 65658 tw 2094alloc 82426 mem 3213

UDP: inuse 1 mem 0

RAW: inuse 0

FRAG: inuse 0 memory 0

看具體哪一個值須要調整咱們纔去修改系統內核參數。

廣告主在營銷和運營中產生了大量的數據，數據來自於廣告投放、搜索引擎、到站訪問、社交媒體、電商客服等數據。隨着移動互聯網的出現，將來諸如門店、渠道、會員、折扣、調研等線下的數據也會接入線上，這些數據過去出於散落在各處的狀態。AdMaster但願協助廣告主將這些數據統一採集、清洗、存儲並分析。

這裏重點提一下Redis和MongoDB的存儲咱們由原來的SATA硬盤所有換成了SSD硬盤。

這是咱們基於Hadoop自研發的ADH版本，專門針對廣告營銷數據行業的。

因爲天天新增 5TB 級數據，天天對千億條記錄進行幾千種維度的計算

這裏我給你們介紹幾個對Hadoop優化的幾個重要參數：/sys/kernel/mm/redhat_transparent_hugepage/enabled

/sys/kernel/mm/redhat_transparent_hugepage/defrag

dfs.socket.timeout

dfs.datanode.max.xcievers

dfs.datanode.socket.write.timeout

dfs.namenode.handler.count

在線數據分析裏我給你們介紹一個很是成功的案例就是AdMaster給可口可樂作的「暱稱瓶」活動

你們可能都瞭解在2013年，可口可樂出過一批帶各式暱稱的可樂。像「高富帥」、「白富美」、「月光族」、「喵星人」等。

AdMaster主要經過捕捉社交媒體過億數據，提取最頻繁使用的熱詞，而後從多個維度進行定量比較(例如聲量、互動性以及發帖率)，初步選出300個熱詞。

AdMaster幫助可口可樂全程監測了」暱稱瓶」在社交媒體上的表現,分析數據顯示，在此次的夏季活動中，社交元素由始至終進行了完整的貫穿。歸功於社會化媒體的「滾雪球式」傳播，廣告宣傳達到了近20億次，吸引了超過100萬個關鍵意見領袖自發表明品牌傳播這些熱詞。在參與本次活動的人羣中，僅新浪微博上，36.9%的人以爲可樂很是親民可愛，更有25%的人直接表達了本身購買可樂的意願。相比普通的活動，這種比例是很是高的。

從銷售結果來講，此次「接地氣」的活動完美收官。據可口可樂（中國）2013年6月初到7月底的銷售統計數據，暱稱裝可口可樂的銷量較去年同期增加兩成，超出了此前預期制定的10%的銷量增加目標。

這個案例具體用到以下模型：

人羣管理經過打標籤、標準化、多維細分，最後經過Lookalike輻射到更多受衆

這是AdMaster常見的應用場景。這是一個咱們將文本天然語言數據和廣告和站點訪問日誌結合的應用，用於提取匿名用戶的訪問瀏覽興趣，並針對頁面的內容進行關鍵詞的抽取。

在提取了大量用戶的訪問瀏覽興趣以後，並配合調研、社交和電商等基礎數據，咱們能夠經過聚類的方法，將相似的訪問者進行多個維度的切分，而且預估用戶潛在的興趣愛好和需求。一些廣告主已經逐漸意識到受衆細分的重要性，他們也提供一些脫敏的CRM數據，在和AdMaster採集的數據進行鏈接後，更好地優化受衆的分類模型。

數據分析出來後，數據可視化顯得就很是重要了：

主要有這三方面：一、數據呈現方式

二、展現層與數據層鬆耦合，多種數據源接入

三、極高的可靠性和容錯機制

最後講大數據都會提到數據隱私問題，我給你們分享AdMaster給出的一個方式：

核心在於找一個可信的第三方數據託管

你們都是把經過SHA2不可逆的方式把數據上傳至第三方數據，計算完各自把數據報表取回後，將放在第三方的數據完全銷燬。

 

好的，恰好一小時，歡迎你們提問和指正。謝謝！

 

 

 

==========問答時間==========

Q1.反做弊主要仍是規則引擎嗎？有沒有用到機器學習方面的算法？

Answer:

都有的，咱們有數據模型團隊（有專門的研究院算法團隊），經過咱們已有樣本庫經過機器學習來計算分析，而且還用到了GPU。

 

Q2.ADH的數據任務調度系統，能夠介紹下大概怎樣調度的嘛？

Answer:

經過下面三個方面來調度

A、Job 配額計算、配額查詢

B、項目的配額分配和更新

C、查詢任務優先級管理

@小海菜 還不徹底是的。咱們內部會把CPU、內存、硬盤、帶寬、時間等各類參數統一一種方式進行配額分配

@Ryan_Y不是指的container，是指的咱們本身將CPU、內存、硬盤、帶寬、時間、優先級等換算成的一種資源，有點相似於積分的概念，任務要跑的快，消耗的資源（積分）就大。

 

Q3.在展現層，部分指標數據來自異步離線計算結果部分來自事實計算，如何能統一展現不讓用戶有誤解呢，好比點擊數100實時計算的，可是展現數離線計算還比較延遲可能顯示20這樣用戶看到數據會有疑惑，還請老師給個方向

Answer:

這個問題很不錯。目前咱們用流式計算來解決，可是若是數據分佈在全國各地，須要把數據同步到中心機房再統一計算就會出現這樣的問題。因此咱們須要將同步速度提升，如經過UDT的傳輸方式解決公網的問題，這樣才能從根本解決問題。若是隻是在展現層作，有一個小方法就是將時間尺度延後必定時間，看起來仍是連續的，只時數據整個延遲一些。

Q4. 你們都是把經過SHA2不可逆的方式把數據上傳至第三方數據，計算完各自把數據報表取回後，將放在第三方的數據完全銷燬。 ==> 難道存儲和計算都是在第3方平臺作的？

Answer:

是加密脫敏後將須要的數據存儲在第3方平臺，用第3方的計算平臺的，雙方不擁有對方的數據源。

Q5. admaster是如何採集社交媒體數據的？是有商業接口仍是模擬登錄採集頁面？是否須要遵循對方的robots.txt協議？

Answer:

微博咱們用的是商業接口，咱們跟微博是高級合做夥伴，可是像新聞、BBS這一類的咱們採起的爬蟲的方式來獲取數據的，咱們嚴格遵循對方的robots.txt協議。

如今 微博、論壇（如天涯）活躍度等都大不如前了，從這些點取數據下來分析，價值/意義體如今？

只是咱們關注的點不同了。

另外咱們在微信這塊也投入了很大資源，好比說咱們在跟騰訊的廣點通合做。

嗯，是有這些的，可是目前仍是比較大的媒體在這方面投入資源，由於分行業了，好比說汽車之家、知乎、寶寶樹一類的

Q6.一個小問題，盧用說的RDD序列化優化指的是哪方面？我最近遇到這個瓶頸，從java換成使用kyro感受也沒有多大提高Answer:

RDD序列化優化主要是指數據存儲的方式根據不一樣應用作相就的調整。從java換成使用kyro性能沒有提高，大家應用場景是計算重，仍是數據交換多呢？

另外咱們也正在作基於SSD的OLAP實時系統，歡迎你們一塊兒探討。