數(shù)據(jù)可視化在滴滴的應(yīng)用

1. 

前言

隨著技術(shù)的發(fā)展，更多的人不滿足于使用基礎(chǔ)的圖表來展示數(shù)據(jù)，如何讓數(shù)據(jù)更直觀、更炫酷的展示成為了大家的追求。為了能更好的展示滴滴各業(yè)務(wù)線的發(fā)展，本文介紹的數(shù)據(jù)可視化大屏從城市、全國和全球維度展示了業(yè)務(wù)線的實時信息，下面將從基礎(chǔ)地圖的構(gòu)建、軌跡、氣泡、熱力、飛線、散點六個方面來講述一下開發(fā)中遇到的難題及解決方案。

• 1）地圖的一次性加載，考慮到易用性和維護性，需自研一套地圖框架；

• 2）大量數(shù)據(jù)涉及到的性能問題，包含數(shù)據(jù)的計算、傳輸和實時渲染；

• 3）數(shù)據(jù)業(yè)務(wù)方較多，接口穩(wěn)定性和維護性問題；

• 4）可視化還原度；

• 1）自研地圖框架map3；

• 2）將數(shù)據(jù)計算移到后端，對數(shù)據(jù)進行壓縮，同時在大量數(shù)據(jù)的傳輸方面采用ArrayBuffer。盡量減輕GPU和CPU的壓力，提高頁面流暢度。

• 3）因為數(shù)據(jù)大屏對數(shù)據(jù)的依賴性較強，為了保障展示的穩(wěn)定性，對數(shù)據(jù)采取了緩存兜底方案；

• 4）通過開發(fā)調(diào)試面板，降低與設(shè)計師溝通的成本，為提高可視化還原度提供了便利。

  
  

const map3 = new Map3({  container: string | HTMLElement;  style: Style;  center?: number[];  pitch?: number;  bearing?: number;  zoom?: number;  controller?: boolean;  hash?: boolean；});

其中，style是我們傳入的樣式數(shù)據(jù)，針對本項目中的北京地圖，style文件中包含了背景、燈光、天空、結(jié)構(gòu)(建筑、道路、水、綠地等數(shù)據(jù))、精模(望京SOHO、CCTV、故宮、工人體育館、中關(guān)村等精細模型數(shù)據(jù))。通過在map3中對style數(shù)據(jù)一層層的解析和渲染，最終我們可以得到一次性加載完成的北京地圖。

▍3.數(shù)據(jù)壓縮

項目中需要用threejs來繪制整個北京城，包括道路、建筑、綠地、山脈等，數(shù)據(jù)量超過300M，且要求一次性加載完畢。平時js文件超過2M就要考慮優(yōu)化，300M已經(jīng)突破了瀏覽器的最大限制，即這么大的文件瀏覽器不會緩存（當然可以通過設(shè)置來更改這個最大限制，但是首次加載是必須的），所以要考慮如何壓縮文件。

mapbox的geobuf可以解決這個問題。geobuf能以近乎無損的方式將geojson壓縮6-8倍，即使經(jīng)過gzip處理也能壓縮2-2.5倍。通過源碼大致了解其壓縮原理，下面寫出來與大家交流下，有不完善的地方望指正。

geobuf使用protocol buffers作為數(shù)據(jù)存儲的格式，protocol buffers是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲格式，可以用于結(jié)構(gòu)化數(shù)據(jù)串行化，或者說序列化。它很適合做數(shù)據(jù)存儲或RPC數(shù)據(jù)交換格式。它是與語言無關(guān)、平臺無關(guān)、可擴展的序列化結(jié)構(gòu)數(shù)據(jù)格式。關(guān)于protocol buffers的介紹這里不再贅述，大家可以參考官網(wǎng)或網(wǎng)絡(luò)上的一些介紹，這里只重點指出與geobuf相關(guān)的一個特性，就是varint。varint的介紹及原理，也可以參考官網(wǎng)或https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html，這里直接說下其特點。varint的特點就是存儲較小的數(shù)據(jù)所用的字節(jié)數(shù)很少，例如存儲1、2、3這樣的數(shù)字，就只用1個字節(jié)。varint的這個特性與后面所要講的geobuf的壓縮有很大關(guān)系，所以這里重點強調(diào)下。

geobuf把數(shù)據(jù)壓縮的那么小，還是涉及很多方面的優(yōu)化，下面我將對個人認為壓縮得最厲害的地方做一個介紹。以下是一段geojson，描述了一段LineString，geobuf并不是直接使用浮點數(shù)來存儲這些數(shù)值，而是將數(shù)值做了一個計算，除第一組經(jīng)緯度外，其他經(jīng)緯度取與前面經(jīng)緯度的差值，再將差值乘1e5（為了方便介紹，后面這一步暫時稱為整型化，具體是乘1e5還是1e6或者其他值，取決于geojson本身的精度）。

圖3.3 geojson數(shù)據(jù)示例

以上面的數(shù)據(jù)為例，取差值后的值為[[120.07045, 30.20248], [0.00001, -0.00022], [-0.00001, -0.00009]...]，整型化后的值為[[12007045, 3020248], [1, -22], [-1, -9]...]。geojson描述的無論是polygon還是linestring，coordinates里面的經(jīng)緯度值其實都比較接近，所以處理后的數(shù)值都會比較小，這樣再使用varint來存儲就會得到比較好的壓縮效果。

最后說下項目中對geobuf的改進。主要包含以下兩點：

• 1）因為項目中繪制的區(qū)域相對較小，例如杭州，范圍在東經(jīng)118°21′-120°30′，北緯29°11′-30°33′ °，這樣對于每一條LineString或者polygon的首個點來說，存儲全部的數(shù)值也存在一些浪費，于是我們在計算前加入了一個減法計算，將所有的經(jīng)緯度減去一組數(shù)值，例如上面的例子中，減去[120, 30]，這樣數(shù)值將變?yōu)閇[7045, 20248], [1, -22], [-1, -9]...]，首個點的數(shù)值更小了，所需要的字節(jié)數(shù)也更少了（這一步雖然減小了一點數(shù)據(jù)量，但失去了靈活性，需要權(quán)衡利弊）。
  

• 2）地圖繪制都存在投影計算，我們將投影計算放在了encode的代碼中，瀏覽器接收到數(shù)據(jù)decode后可以直接使用，這步可以減小瀏覽器的計算，節(jié)省cpu和計算時間的開支。

改良后的geobuf叫做mbuf，下面是一組對比數(shù)據(jù)：（注：geobuf和mbuf還剔除了一些不需要的屬性，所以geobuf相比官方提供的測試數(shù)據(jù)壓縮比更大，官方提供的數(shù)據(jù)中g(shù)zip后可壓縮2-2.5倍）

如何讓軌跡動起來呢？其實就是每一幀都讓軌跡沿著預(yù)設(shè)好的路線向前移動。設(shè)想軌跡有一個頭和一個尾，每幀讓頭和尾都沿著路線移動固定的距離，再將頭尾間的點連接起來即可。通常我們會用若干點來描繪一條路徑（下面我們稱這些點為路徑點，即下圖所示的實心點），點在路徑上并不是均勻分布的，在轉(zhuǎn)彎的地方會比較密集，直線的地方相對稀疏。所以在確認好頭尾點的位置后，還需要將頭尾點與中間的路徑點串聯(lián)起來，才是我們最終需要繪制的軌跡。如下圖所示，紅色曲線是需要繪制的部分。

圖4.2 軌跡示意圖1

所以如何定位首尾點的位置是重點。假設(shè)軌跡長為length，每幀向前移動x米，軌跡可見部分，即頭尾長y米，第z幀的時候，head的位置就在距離起點x*z米的地方，但如果x*z>length，即head位置超過軌跡的總長度，則head的位置為length處，所以為min(x*z, length)；tail的位置需要判斷有沒有在可視范圍內(nèi)，所以值為max(0, x*z - y)。

那么現(xiàn)在問題又歸結(jié)到如何在路徑上找到距離起始點特定長度的點的坐標。大家可能會想到使用turf的distance方法， 使用起來很方便，輸入兩個點的坐標就可以得到兩點間的距離，所以一開始我們也是想到使用turf，這也是埋的一個坑。turf的性能很差，原因就是每次計算兩點之間距離的時候都會重新計算已經(jīng)計算過的點，造成了性能上的浪費，畫不了幾條長軌跡就會卡，所以另尋他法。后來我們采用動態(tài)規(guī)劃的思路，方法如下：

• 時間范圍

  可以展示過去一分鐘、十分鐘、一小時等任意時間間隔內(nèi)的熱力情況。

• 半徑大小

  可以以任意距離為單位，該范圍內(nèi)的訂單數(shù)對應(yīng)的色階上的顏色即為該范圍的熱力圖顏色。

• 色階

  熱力圖的顏色是可調(diào)的。

7. 

飛線

1）取點

曲線是由一系列的點連接組成，若想得到平滑的曲線，首先需要得到能生成我們想要的曲線的點。這里我們每條曲線是由100個點連接而成，那么如何得到這100個點呢？如果只是想在地球上兩點之間生成一條曲線這本身不是難事，但是為了美觀性，我們想要達到每條曲線的最高點距離地球的距離都是相同的，這樣在地球轉(zhuǎn)動或者各種視角下，視覺體驗上才會比較好。為了實現(xiàn)這點，我們做了以下計算，代表的是飛線起點向量和終點向量之間的夾角：

① 

② 

當角度大于30度時，我們發(fā)現(xiàn)得到的曲線兩端變化較大，中間很長一部分幾乎都是平緩的，整條曲線的彎曲變化不是特別順滑。所以為了解決這種情況，我們對 的曲線采用了不同于三維三次貝塞爾曲線的方法，使用的是CatmullRomCurve3，即使用Catmull-Rom算法， 從一系列的點創(chuàng)建一條平滑的三維樣條曲線，不僅限于兩個控制點。我們采取的方案是根據(jù)起點和終點的經(jīng)緯度差值、地球的半徑和曲線最高點對應(yīng)的半徑進行插值計算，得到20個插值點的坐標，將這20個點傳入CatmullRomCurve3中生成曲線，并利用其提供的getPoints方法得到曲線上的100個點用于繪制。

2）紋理映射

上一步我們獲取的100個點是描繪一條完整曲線的全部點，但是從圖7.1(b)中可以看出，飛線在飛的過程中展示的是完整的紋理，但是飛線長度只占總長度的1/3。如果按照正常的映射的話應(yīng)該是完整的紋理對應(yīng)完整的曲線，所以在飛的過程中應(yīng)該只展示對應(yīng)的紋理部分。那么如何實現(xiàn)動圖中的效果呢？

第一反應(yīng)就是改變頂點坐標，例如第一次render第0～30個點的范圍，第二次render第10～40個點的范圍，以此類推。效果確實是實現(xiàn)了，但是性能上有問題，由于頻繁的更換頂點導致了頁面的卡頓。

想到的第二種方案就是100個點全部繪制，在render的過程中z不斷變換頂點對應(yīng)的uv坐標。例如開始是第0～30個對應(yīng)的uv坐標從0～1，下一次是第10～40個點對應(yīng)的uv坐標從0～1，以此類推可以滿足1/3長度的飛線展示完整的紋理，且不斷移動。在這里還有個優(yōu)化，一開始是在每次render的時候去遍歷uv數(shù)組更改每個點對應(yīng)的值，但是遍歷數(shù)組也是耗性能的，特別是當數(shù)據(jù)量大的時候，后來是將一個常數(shù)傳進了shader中用于計算每個點此時的uv坐標，每次render都會改變這個數(shù)，同時同步到shader中。

8. 

散點

平時我們用靜態(tài)的散點比較多，這種實現(xiàn)很簡單。但當展示的信息量不是很豐滿時就顯得頁面有些空洞，這時候就需要添加動態(tài)呼吸的散點，讓頁面看起來更熱鬧。我們在散點大小變化的過程中對應(yīng)的改變其透明度，產(chǎn)生漸隱漸現(xiàn)的呼吸效果，同時我們可以隨機點出現(xiàn)的位置，讓效果看起來更靈動。

9. 

結(jié)語

以上就是在全業(yè)務(wù)之城開發(fā)過程中的一些總結(jié)和思考，日后在不斷開發(fā)數(shù)據(jù)可視化大屏的同時，我們也會加速沉淀通用組件庫和搭建平臺。

·················END·················

推薦閱讀

1. 我在字節(jié)做了哪些事
   

2. 寫給所有數(shù)據(jù)人。

3. 從留存率業(yè)務(wù)案例談0-1的數(shù)據(jù)指標體系

4. 數(shù)據(jù)分析師的一周
   

5. 超級菜鳥如何入門數(shù)據(jù)分析？
   

歡迎長按掃碼關(guān)注「數(shù)據(jù)管道」