Facebook 精準廣告的背後,Vertica 如何讓大數據分析發揮神效?

作者 | 發布日期 2017 年 04 月 10 日 14:00 | 分類 Big Data , Facebook , 物聯網 follow us in feedly

大家上網時應該都有類似經驗,就是瀏覽過某資訊或產品頁面之後,接著開啟 Facebook,旁邊的廣告欄就會跳出相關主題的廣告。Facebook 到底怎麼辦到的?其實幕後靠的就是大數據即時分析平台 Vertica。為了揭開其神秘面紗,科技新報獨家專訪了台灣 Hewlett Packard Enterprise(HPE)的業務總監廖智寧,來為大家揭曉 Vertica 的能耐。




資料「儲存、運算、回饋前端」即時完成

關於如何面對大數據,廖智寧說:「把資料傳進來儲存、運算、然後回饋到前端的 APP,這一連串動作如果沒有辦法即時完成的話,就不用玩了。」例如現在很流行的物聯網,可能一個大系統就有一萬多個感應器,每分每秒都會不斷收到最新數據,如果還要等週期性 index 更新完才能查詢,根本不可能進行「即時」分析,但 Vertica 卻能夠辦得到。

從 IT 的角度來說,Vertica 是一種特殊的資料庫,其特色是:

  • column(垂直向)based:row(水平向)based 的傳統 SQL 資料庫每天需要定期更新整個資料表的 index,不然就無法查詢;但只更新小範圍的 index,又會發生資料庫碎片化降低搜尋效率。而 column based 就沒有 row based 的這些問題,可以一收到資料,就馬上進行查詢。
  • MPP(Massively Parallel Processing)大量平行處理:不但可橫向擴張,還能收縮。
  • 跟關聯式資料庫(RDBMS)語法相容:不用學新的語法。
  • 整合 GIS(地理資訊系統)的呼叫:只要會 SQL 指令就可以查詢路線、形狀、nearby 等資訊,而不需要知道 GIS 系統的技術細節。

Facebook 精準廣告的奧祕

row based 跟 column base 的差別在哪裡呢?傳統資料庫是以 row 為基礎,記錄像是「收件人:王小春;購買產品:鉛筆、書本 A;購買日期:2017 年某月某日」這樣的資料,一筆一筆儲存到硬碟裡,且每天需要定期更新整個資料表的 index,才能被查詢。這種技術針對以天為週期、相對靜態的資料查詢是可以的;然而對於全球平均每日流量達 10PB(1PB=1024TB)的 Facebook 而言,投放廣告的資料分析,必須在幾分鐘甚至幾秒內即時完成,這是傳統的 row based SQL 資料庫所無法達成的任務,就算用最高速的 RAM based 資料庫也不可能。

至於 column based,其實就是在資料表中以垂直向的「資料屬性」為單位來儲存資料。以台北市交通為例,實際存到資料庫的資料會像這樣:「大安區;大安區;萬華區;大安區;文山區;大安區」,如果這些資料是 5 分鐘內傳進來的,就可以很快知道即時趨勢集中在大安區,推測有大活動正在該處舉行。廖智寧表示:「Vertica 是 column based 的資料庫,不需要作 indexing,資料來的當下馬上就能進行分析。」

「很多人以為,即時分析是在 Facebook 上面發生點擊行為後才發生,其實不然。如果檢查 Facebook 的網頁 javascript 碼,就會發現就算你沒點,只是移動滑鼠在照片上畫個圈,這樣的行為也都在 Facebook 追蹤下。」廖智寧繼續解釋道:「Facebook 就是透過 Vertica 即時分析用戶的行為模式,再加上合作網站的 cookie,推測出你感興趣的事物,然後即時媒合廣告商,放上投你所好的廣告。」大家恍然大悟了嗎?Facebook 並非只靠關鍵字與點擊,可是還使用 Vertica 掌握用戶的操作行為,才有辦法完善消費者偏好分析、進而靠精準的廣告投放大撈一筆啊!

▲ Facebook 後台透過 Vertica 大數據即時分析,能洞察用戶行為,立刻媒合廣告商投放廣告。(Source:《科技新報》攝)

主機群可自動擴張,還能收縮

在 MPP 大量平行處理上,也是另一項 Vertica 優於傳統 SQL 系的資料庫的地方。傳統上資訊系統的規劃方式,是先問「最多會有多少人來用」,然後估計需要採買的軟硬體設備數量。畢竟傳統資料庫就是一台一台買,如不能應付最大可能,偶發的尖峰到來時就會來不及買新機應付;然而尖峰時可能有 5 萬人次的流量,平時卻只有 1 萬人次,等於平常有大量的機器閒置,造成巨大浪費。

Vertica 就不同了,它會觀測流量成長趨勢,自行動態增加主機。廖智寧以另一個客戶 Twitter 為例:「比如最近的奧斯卡金像獎,頒獎時趨勢上有越來越大的流量,本來 N 台的資料庫 VM 群不夠,就會觸發一個事件,自動產生 N+1 台,甚至 N+2、N+3 台。」而 Vertica 更有收縮的能力,待流量尖峰過去後,Vertica 就會逐漸縮減 VM 群數量回到平常的配置。這是傳統只能擴張的 SQL 資料庫所辦不到的。因此,Twitter 就不用因臨時爆增的尖峰流量,得從此負擔大量備而不用的新主機鉅額租金。

理想的交通大數據

除了前述 Facebook、Twitter 以外,還包含 Zynga、Uber 等公司也均採用 Vertica 分析用戶行為。

傳統 Big Data 常用作大眾交通運輸的分析,但捷運、火車、公車等畢竟是運行固定的路線,需要叫車服務來完成抵達目的地的最後一哩,然而,叫車的行為通常很突然。站在乘客的立場,會希望不管何時何地,計程車越快來越好;從計程車司機的角度來說,則會希望避免空轉,等到有把握載到客人的時段,才開車上路「巡邏」。如何讓乘客方便、小客車司機又不空轉(同時減少塞車、空污),也是一門大學問。

要應用大數據分析來解決問題,就必須在所有的計程車上佈署感應器的節點。廖智寧表示:「姑且不論在台灣的法律問題,純就技術面看,Uber 的確把這個問題解決了一大半。」Uber 在前端,是安裝 APP 在司機們的手機內;在後台,則運用 Vertica 作大數據分析,因此能做到貼心的調派汽車與浮動費率,使得 Uber 盡可能在最需要叫車服務的地方,有最多的車子在跑。

更進一步,在 Uber 系統下,乘客不再是「隨機人物」,他們的叫車習慣(喜歡哪種車、叫車的規律為何)被分析後,可以指示司機提早駛向某乘客習慣乘車地點,增加接到客的「命中率」。也就是說,利用 Vertica,Uber 還能夠規劃車流,提升交通運輸效率。

叫車 APP 利用 Vertica 預估人潮所在,讓計程車可提早抵達,幫助改善交通。(SourceShutterstock

以舊代新,台灣離「智慧」還有多遠?

只要每台計程車都佈署好大數據分析的終端節點,不論是 Uber,還是知名大車隊,每一個司機都能享受得到好處。於是,去年交通部便推行智慧型計程車車表,並開啟台北、新北兩市計程車路線的研究案,由 HPE 與交通大學運輸研究所合作承接,這不啻是計程車業的福音。然而,真實的狀況卻不盡理想,因為智慧車表唯一的資料傳輸界面,竟然是 1960 年代發明的 RS-232!

沒有 NFC、藍芽、無線網路,甚至沒有 USB,完全無法進行即時大數據分析。取而代之的是由工讀生帶著筆電到計程車行,付錢懇請計程車司機暫停營業參與調查,還得把表從車上拔下來接電腦才能讀取資料,而輸出資料的指令只有一種──「一次輸出一年份,不能按月份輸出也不能指定範圍」。這一切得在標案預算內達成,且終究只能做到抽樣分析,Vertica 功能再強,也只能徒呼負負。

廖智寧解釋:「按照中華民國標案的法規,由於不能獨厚某間廠商,所以開的規格是『要有資訊界面、要有輸出資料的指令』。」由於沒有指名說是「哪一種資訊界面」、「要有哪些輸出資料的指令」,得標廠商用 20 多年前的舊科技做出這樣「新型」的智慧型計程車車表,依舊完全符合規格。「政府很多的美意,到這一關就卡住了。」從他的語氣中聽得出不無遺憾。

▲ 廖智寧認為,大數據即時分析能幫助節省時間人力,提升產品及服務品質,但在納入新科技時,法規也該做出因應,以免政府美意打折。(Source:《科技新報》攝)

法規沒有與時俱進,導致這類化老舊腐朽為最新智慧科技的施政行為層出不窮。即便計程車司機們裝了這款車表,也無法享受到類似 Uber 以及大型車隊進行大數據分析的好處,於是大者恆大,不公平的狀況無從改善。可見智慧新創不能只是口號,必須從法規開始完善配套措施,新科技才能真正落實,造福社會。

(首圖來源:《科技新報》攝)