Pinot-LinkedIn如何將大數據做到實時與民主化
回國創業已經兩個月了，最近Pinot開源的消息布滿了我的朋友圈。作為在世界上第一個嘗試使用，并推廣Pinot作為分析型工具的LinkedIn團隊，對我們的Pinot團隊由衷贊賞。我代表我的團隊在這里與社區的小伙伴們分享下一些體會和經驗。
一切都來源于LinkedIn Sponsored Update這個LinkedIn廣告業務轉型到移動端成功的產品開發。2013年，LinkedIn致力于構建300萬的企業與2.3億（2013年第 二季度的用戶數）全球用戶聯通的橋梁，幫助企業直接推送最相關的信息流到用戶首頁。這是一個重要的戰略性產品。之前的應用都是先有網頁端產品，然后才會建 立移動端的應用。而Sponsored Update是第一個同時在Web和Mobile App上發布的LinkedIn商業應用。實質上，Sponsored Update是鏈接網頁端和手機端的廣告業務，貨幣化是業務重點。然而，LinkedIn把用戶體驗放在首位來考量，努力尋找收入和互動的平衡點，避免用 戶被鋪天蓋地，或是不相干的廣告影響。而尋找平衡點的關鍵在于對數據的應用，使有償廣告與自然信息合理地更新。但是多平臺的特性，更增加了我們分析的復雜 度。
圖1 2014年10月，我和Parveen在紐約舉辦的 Starta+Hadoop會議 上一起做了分享 。
做好數據分析，必先做好數據點采集的工作。對于Sponsored Update來說，是網頁和移動端同時采集，而且由于產品剛剛落地，對數據量和種類也有很多要求。那時候我們分析團隊的廣告數據分析經理單元明，將很多時 間都花在配合產品經理和業務人員建立大量的頁面標簽，追蹤代碼以及核心的KPI定義上。大致分為幾類思路：第一，維度需求：比如用戶的地區，職業級別，職 業功能，行業，技能，人脈數量等等；第二，行為數據：比如用戶多少次登陸LinkedIn，互動級別，這些用戶關注了哪些公司，訪問了哪些公司的主頁等 等；第三，分群用戶：根據一些維度區分用戶，每個群組所看到的有償廣告更新與自然信息更新的頻次是不一樣的。這個部分，我們團隊的元明帶領整個 LinkedIn廣告數據分析組，每周7天在線將各種分析標簽、數據采集的計劃和商業分析KPI與整個的管理層，廣告產品，移動端和工程部門進行各種分析 結果的溝通。
然而，當時我負責整個商業分析部門的數據解決方案，按照query的時間、用戶維度、用戶行為維度、不同的群組維度估算了一下，如果要做任意時間 范圍內的任意維度組合的指標運算，用2000臺左右的Hadoop集群，在有很重的Queue的基礎上，即使跑一天的Hadoop腳本，也不能跑完所有的 分析組和。而且，每天產品經理要對超過數十億行的數據進行實時的分析，我們當時的BI解決方案刷新一次要滯后5分鐘，速度很慢。而新產品對分析的要求就是 不斷提出假設，不斷分析變量的過程，維度無法確定下來，如果分析師要增加分析維度的需求，那么我們商業數據分析部要跑更多的腳本。我們都知道，維度越多， 要預先聚合運算的可能性是2的N次方增加。
Sponsored Update是LinkedIn首頁上的產品，生成的數據量很大，而且每一條更新背后都有各種多維度的邏輯。這樣的挑戰，不能用傳統的辦法解決，這就是我 們一直在尋找各種方案的原因。當時的Pinot是完全服務于線上交易型數據庫的一種方案。在我們與LinkedIn的工程資深主管溝通后，我們決定在沒有 OLAP分析案例的情況下嘗試Pinot。
為何使用 Pinot ？
使用Pinot的原因。在LinkedIn和工程師團隊保持良好的關系很關鍵（好像在哪里都一樣啊），我最初在嘗試senseidb，但是 senseidb的主程已經去了推ter。當時管理LinkedIn搜索的主管就向我介紹了Pinot開發團隊，一共只有3個人的團隊，還有一個工 程師是新加入的。Pinot當時主要是支持LinkedIn線上的系統，每個QPS要求小于600毫秒，產品支持SQL的Rest API，數據源可以是kafka，可以是從Hadoop Avro format直接建segment導入Pinot，支持filter，group by。他們團隊小，任務重，主要專注于線上服務，本來沒有時間支持我們線下分析案例。好在他們團隊主管與我們分析團隊有很多合作，我們不斷向他勾畫 Pinot的未來，可以支持OLAP查詢，最終才得到4臺機器，包括：16 core，48G，SSD的機器，于是我們開始嘗試。
圖2 Pinot能夠滿足的技術場景
圖3 Pinot的Architecture
圖4 Pinot用到的index，包括實現前面提到得到多值filter
很興奮地裝載了1天1B的數據，跑了些query后，查Log，發現掃描的數據越多，query就越容易斷線，第一個結論就是小query多次發 送沒有問題，Concurrent很好，小任務，小步快跑沒有問題，步子邁太大慢跑就不行，將timeout設置得很大也是這個問題。最終我們決定，前端 先將大的query根據每次可以掃描的數據量將query拆成多個query，然后控制并發度，保證query能夠在10秒內返回結果。這樣的結果符合我 的預期。如果放在Hadoop里面跑，我要等很久才有結果。
后臺完成之后，我給產品經理和分析師迅速搭建起網頁端界面，允許任意篩選和整合數據，保證新的數據從Hadoop到Pinot的導入。而在用戶看來，是質的飛躍：從前要等一天才能看到結果，現在10幾秒鐘就解決了。這使我們的分析師可以在短時間內，對產品表現做出判斷。
緊接著我們要求加了兩個特性：支持count unique user和filter on tuple。剛開始的時候，我在準備avro format數據的時候，就將user分別存在不同的segment文件里面，而且要保證每次生成的segment文件里面都是consistent存放 相同的KEY區間。這樣就能將count unique變成count很多小query，然后做total merge的簡單方法。其實還是count運算，只是保證每個segment文件沒有重復的KEY。后來Pinot團隊增加hyper loglog的功能。Filter on multiple value也是一個很好的特性，LinkedIn每個用戶都有不同的技能，而且每個user的技能長度都不一樣。而搜索變得十分簡單：例如我們想要尋找有 Java或Scala技能的人，只需要寫skills in (Java或Scala)就可以得到了，而背后實現全靠bitmap index。
那時候只有3個人的Pinot團隊做出這樣優秀的產品，十分了不起。之后我們團隊和Pinot團隊開展了很多更深入的聯合開發，也與Pinot的主程Praveen建立了非常好的關系。
作者： 吳繼業
作者簡介： 在數據倉庫，數據分析和數據工程領域有13年工作經驗，前LinkedIn商務分析部數據工程總監，現任Gorwoingio聯合創始人。曾經就職于寶信 軟件，HP，eBay和Linkedin，2007年出國，于2015年回國和Simon Zhang一起創辦GrowingIO。