Facebook 精準廣告的背後，Vertica 發揮神效！

大家上網時應該都有類似經驗，就是瀏覽過某資訊或產品頁面之後，接著開啟 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 還能夠規劃車流，提升交通運輸效率。

以舊代新，中國台灣地區離「智能」還有多遠？

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

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

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

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

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

（首圖來源：《科技新報》攝）

如需獲取更多資訊，請關注微信公眾賬號：Technews科技新報

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！