【51CTO.com原創稿件】在WOT2016移動互聯網技術峰會平臺技術專場，TalkingData 研發副總裁馬驥先生給我們帶來了《地圖可視化Client Service架構設計及實踐》的精彩演講，與參會的朋友共同分享了地圖在大數據領域當中的應用和如何通過數據可視化進行數據挖掘、探索以及數據決策等精彩內容。

　　TalkingData成立于2012年，目前已經進行了 C輪融資，并正在啟動D輪融資。截止到現在， TalkingData已經積累了30多億移動開發數據，我們的產品主要圍繞三方向：一是面向于開發者服務，二是應用統計分析、三是廣告監測。TalkingData公司總部設在北京，在上海有研發中心，深圳有一個辦事處。此外，還在國外設置了一些分資機構。

　　談到當前的數據市場，馬驥先生認為，當前數據體量積累了大約有30億設備，日活2.5億，月活6.5億，每天吞吐能力大約14T，交互會話34億，處理事件300多億。WIFI數據覆蓋了80個城市，3000多個商場，WIFI指紋有400多萬，POI數據是4200萬。另外，圍繞這些數據有各種標簽800多個。他表示，在大數據時代地圖的發展出現了一些瓶頸，如何解決地圖在大數據領域中的使用是一個非常重要的課題。

　　針對這一課題，TalkingData公司研發出一套完整的解決方案。首先，是繪制引擎TD Seagull，因為地圖數據和PVI數據對于任何一家公司都是很有價值的，需要各種保護、防破解，我們同樣采用這樣的方案，把加密數據拿過來，前端解密。另外，如何把數據壓縮更小，有一套壓縮算法解開。

　　在Client端和Server端，500萬數據放到前端明顯完不成，肯定是前后配合做。解決辦法最重要的是這兩塊：***， 500萬個點的數據，在全國視野內是否給5000個點就能把500萬個點表示出來，甚至給500個點是不是也能夠把上面的地圖表示出來。我們認為，這完全是可以的，當然把500萬個點提取出5000個點或者500個點，如何把特征點弄好，就要有數據聚合服務。第二，大量數據在放大之后很大全國的數據是沒有用的，在打開地圖放大到一定級別后只顯示可視區內或者需要繪制的數據，返給前端是不是可以?答案是的，這是最重要的解決辦法。例如，用圍欄計算，畫一個圍欄，海淀區有多少數據需要計算。另外，大部分都是即時服務，坐標轉換，因此涉及到轉換有N多種坐標體系。幾何計算如何判斷一個點是否在圍欄內，好像很簡單，其實真的蠻復雜。500萬個點如何判斷圍欄?本身有100個點，這件事情很復雜。這個方案是后端到即時N多服務，把數據提煉出來，吐到前端，前端做解密、壓縮，通過地圖各種熱力圖API顯示出來，這是我們最初的一套方案。

　　當然，在這套方案中我們也發現有幾個問題：***個問題是后端開銷比較大，系統開銷很大，計算能力對內存、對CPU計算很大。另外，SLA性能，一個請求是否能在一秒內把數據接口不是返回接口，而是返回到前端來，系統是否能夠支撐。這就造成硬件投入比較多，但是有些行業客戶需求點很小，需要加一套即時服務，對成本來說有問題，即時服務硬件投入很大 如何解決這個問題?簡單的辦法是前端能否有更多的事情，這是一個很正常的思維，如何把后端服務放到前端做，或者能否前后端協同做，這樣就降低了后端的技術復雜性。

　　另外一個問題是把后端服務拿了出來，上移到前端客戶端瀏覽器。由于數據聚合瀏覽器完全可以做，圍欄計算、坐標轉換，很多都試圖想要瀏覽器承擔減輕后端的服務，甚至有些后端服務可以不做了或者少做點。

　　TD Seagull面臨的挑戰主要來自幾個方面：***個方面是前端繪制，現在前端的解決方案還是很多的，不做細說。第二個是Client端的問題，大量數據導致整體地圖拖拽非常卡頓，甚至致使瀏覽器崩潰了。 Client繪制極限值能做多大，如果容器就是一萬、幾千，沒什么可談的，如果能夠更大可能會更好，但是面臨的問題也會很多，比如地圖拖拽一下或滑動一下，可能都需要有N多計算。計算復雜度和算法邏輯，前端GS做地圖很有意思，真的有很多算法邏輯，但是導致的結果是這塊帶來的問題也會比較多。前面是原因，后面是表象，這個表象對于用戶的體驗很差，GS的執行原理是單線程的，很容易有大量的計算在，執行效率在，很容易堵塞后面腳本咨詢，除了卡頓現象都是因為這種問題導致的。

　　既然把服務往上移，如何提升計算能力，成為處理架構設計最核心的。前端經過十幾年的發展，H5做了很多，大家也經常提到MVC，為什么前端的M層很薄?甚至有的根本沒有M層?為什么前后端分離的標準，前端是負責展現邏輯，后端負責業務邏輯?當然，現在有些客戶端很多的業務邏輯逐漸往前移。但是，在計算能力方面，前端一直以來是弱的，原因很簡單，既然是一個單線程的，意味著只能利用好一個CPU，現在手機都多核了，前端GS執行沒有充分利用好CPU資源，可以得出這個結論。H5的發展各種解決方案出來了，做前端的已經很清楚了。

　　整個方案完成后，目前在整體計算能力方面有了很大的提高。圖中橫軸代表PUI個數，是2000個，扔到Worker里，返回是70毫秒，如果是5000個點100毫秒。一般情況下，3萬個點500毫秒對于瀏覽器整個過程用戶體驗非常不錯。這個測試在電腦性能相對比較弱，如果好的電腦形成反饋更高。比如到10萬個PVI計算達到了1.3秒，20萬是2秒多。現在整體已經沒有峰值了，只是用戶是否可接受，做了Worker之后，另外一個問題20萬個點如何從服務器端跑到客戶端，這是另外一個事，至少可以看到Worker、多線程計算能力真的大大提升，在業務處理上沒有瓶頸了，現在可以放20萬個，其實30萬也不會有什么問題，只是是否能夠執行完而已。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】