2017-8-5 藍藍設計的小編
今年在多個部門共同努力下,阿里集團在2015水立方雙十一媒體中心立起了一塊寬21米,高10米的LED大屏。DataV 數據可視化小組有幸在這么大一塊畫布上盡興創作,并且在這個項目中小組第一次嘗試使用了DataV數據可視化引擎來搭建所負責場景,這樣的機會實屬不易,所以想把其中的點點滴滴和大家分享。
先呈上現場效果的幾段視頻,熱個身。
今年的媒體大屏幕分為三大板塊,分別是總覽大屏,全球大屏,城市大屏。每一個大屏幕都有自己的主題,總覽大屏保留了2014年基本的信息點,全球屏是對于今年全球狂歡這一主題的數據展示,而城市大屏是今年在信息點上的一大創新,我們希望通過從地理維度的下探,讓來訪者對于阿里雙十一數據有更多個性化的認識和解讀,也讓數據和大家更加有貼近感。
而在展現形式上,本次數據大屏最受關注的兩個形式是:3D實時交易地球和3D北京市交易圖。這兩種形式都將數據從抽象世界還原到了人們所熟悉的3D世界,并且直接轉換回了產生這些數據的行為。例如北京3D城市中的一條條飛線正想一件件快遞包裹向滿心期待的買家們飛奔而去的景象。而看到3D地球的時候,即使是事先不太了解今年全球狂歡主題的來訪者,也留下了今年雙十一已經影響全球的感受。
在技術上,所有的媒體大屏都是基于web端技術實現的,這樣的選擇是因為數據大屏幕只是數據可視化在我們日常工作中的一個運用場景,我們需要能讓數據可視化的技術能在日常工作中得到最廣泛的落地運用,web端當然就是我們的主戰場。當然。拋開這一點,我們認為web端的相關技術也是大家落地相關數據可視化開發的良好平臺,為什么這么說呢?這基于以下幾點:功能全,前端技術svg,canvas,webgl三者的相互補充,已經讓我們在交互,2D&3D以及大規模數據量繪制有了充足的發揮空間,其次我們團隊在以前開發數據產品的過程中已經用Nodejs建立了良好的中間件來連接各種數據源,這讓目前接入各種數據庫變得非常便捷。最后就是便于分享,在任何硬件設備上只要打開瀏覽器就能看到最終的數據可視化作品,在當今這個注重信息分享的時代,這一點非常關鍵。
另外這也是第一次我們在公司大型項目上使用DataV數據可視化引擎搭建數據大屏。DataV數據可視化引擎是以我們日常圖表組件庫d.chart以及地理相關組件庫d.map為基礎,專業數據可視化模板設計為視覺框架,依托cube前端框架搭建起來的web服務。通過該引擎可以利用已有組件低成本還原設計師產出的原型圖,快速完成多種數據源的綁定,并通過最終的可視化配置調整系統完成所見即所得的視覺調試,最終產出數據大屏。
之前我們做了幾年的展示類可視化項目,有些坑有些不足。十月走進項目室的時候,我們有這些期許:
1、高性能,告別內存泄露
內存泄露一直是我們揮之不去的心病,想象幾百個鏡頭對著馬總講話的時候,運行了10個小時的大屏忽然崩潰是何情景。
過去的幾年里,在展示性很強的場合,我們常用svg去表現復雜的圖形,還記得去年為了snap.js里存在的內存泄露問題而徹夜不眠(庫本身有坑,除此還會有性能問題),而且svg和普通canvas,性能有限,不能使我們能表達萬級數量實時更新的圖形,我們希望以更高性能的方式,去還原數據的海量。所以,今年大部分的屏幕都是基于webgl的,我們又嘗試了許多方法,使得性能更好,且看下文。
2、走向城市級別
全球和全境的展示,如中國的物流網絡,全球的飛線圖,已在歷年的大屏考驗里愈發成熟。
更有意思的方向在哪里?我們覺得走向城市尺度有挑戰,如何表現城市錯綜復雜的建筑和街道結構、以及人類交易活動混沌而有序的空間分布。
3、從飛線到軌跡
飛來飛去圖,展示了很多年,我們如何更進一步,更有意思地展現數據。
我們想到的一個點,是讓交易沿著物流的方向行走,營造一個更真實的交易場景。
4、全面3d
2014年雙十一媒體大會里,3d的可視化場景小試牛刀,今年覆蓋更廣。
3d之于2d,有GPU加速性能上的好處,也為可視化增加了一個空間的維度,還讓某些場景更接近感官(如城市建筑的展現)
5、工程化
第一次高規格的首都雙十一晚會,鞭策我們推陳出新,也把大屏開發的數量,提到了去年的4-5倍,時間非常短,調整也很多,如何標準化地去做形態各異的不同大屏?
今年的雙十一盛況空前,海量的訂單和支付數據,經由客戶端和大后端的處理、公共數據平臺及產品部同學的合并和清洗,到了可視化大屏前,面對數百媒體以及媒體背后的觀眾。首先從我們如何處理和展現這些數據來開始我們的技術分享。
目前任何一種繪圖技術,都很難完整的去反映雙十一的海量交易,但我們盡力還原最真實的情況。
數據在數據部門清理之后,進入了我們的流程。
總體,我們今年把所有的屏,運行在阿里云的數據產品DataV數據可視化引擎上。DataV數據可視化引擎是一個集屏幕管理、多屏通訊、發布打包等功能為一體的大屏生產工具,除了可以集中管理屏幕,并通過頁面遙控大屏,還可以通過配置頁面,實時調整已經發布上線的大屏的一些參數。
我們的架構防止3種情況:
1、防網絡延遲/斷網
2、內存泄露
3、數據量過大
我們想表現2點:
1、海量的數據展現
2、飛線群和交易情況一起漲落,比如10日凌晨海量飛線,11日早晨數量變少。
我們的原則是數據上層層緩存,層層緩沖,組件上利用好GPU通信,架構如下圖。
幾乎所有的屏都以一定地頻率請求服務端。接收到數據后還要有處理的策略.
以我們的飛線和軌跡的處理策略為例,講講我們處理的流程。
飛線的數據,接口返回一般都如下格式:
[{
from: { lat: xxx, lng: xxx
}, to: { lat: yyy, lng: yyy
},
count: zzz
},
......
]
最簡單的動畫模型是有啥畫啥。
不可能來什么畫什么。頁面刷新率1/60秒,要維持交易動畫的綿綿不斷,高頻請求服務器,請求很可能無法及時返回造成積累,最后內存爆缸,何況如果下一次數據返回網絡不暢,會造成延時,體驗很差。
因此我們的接口以5s左右的速度去請求服務器,拿到數據的時候,也不合適直接畫出來。而是在ajax請求和繪制之間,建立一個先進先出,后進后出的數據緩存。數據緩存要具有一定的長度(否則在反復輪詢一組飛線,視覺上很明顯)。
每一次數據到達的時候,后端會計算好此刻飛線的繁忙程度(可以理解為0-1的數字),我們通過這個繁忙度,去控制繪制的speed(即瀏覽器的每一幀刷新,從數據池提取幾條飛線數據),這直接決定了此刻飛線的密集度。
在繪制層面,維護一個數量固定的飛線對象池,建立回收機制。每個飛線有一定的生命周期,當飛線生命結束(飛到了盡頭)的時候,會被回收到unusing的隊列里去,當新數據到來的時候,會從unsing的池子里取出飛線復活,放回到using的隊列里去。有一種情況是數據量太大,根本沒有空閑的飛線時候,新的數據就發過來了,這種情況下,我們拒絕繪制。
在這個繪制控制器里,我們維護一個requestAnimationFrame的線程,這比每個飛線獨自起requestAnimationFrame更新自己的生命周期更節約性能。
今年組件和去年組件的變化,在于數量,組件除了兼容回收機制,最大的改觀是所有的組件共享一個線幾何體。也就是,幾千條飛線其實是一條線,只是我們在視覺上隱藏了線和線之間的連接,在threejs里,建一個100000個點的線,要比 1000條100個點的線要節約大量的cpu資源,而我們把這種虛擬的飛線幾何體和一整根線的點,建立了虛擬的映射關系,最后通過shader給線附著顏色。通過顏色和透明度的控制,我們可以繪制出飛線。這種飛線本質是線幾何體,形態上沒有三角的strip精細,但為了海量,我們選擇了平衡(由于錯覺,我們覺得有透明度的線比沒有的更細,因此有流星拖尾的效果)。
本質上,飛線就是一個有生命周期的線,全球交易圖里,飛線是一根類似于拋物線的曲線,而軌跡圖里,飛線沿著經緯度數據的軌跡一步步往前挪動。
其實我們可以更推廣,任何線產生的動畫,我們都可以用這個組件去管理和表達,只是一小部分函數發生變化.
因此,做了雙十一前10億交易額的彩蛋。我們的主要想法是,雙十一海量的成交額如雨點般落在了地面上,像焊槍一樣焊接出11.11幾個大字,每300多萬訂單完成,就生成一個cube,到10億元完成的時候,模型旋轉并消失。
一方面我們可以看出成交量在不斷累加,一方面,在這個時間里,折線圖這種更的圖表,可以有個緩沖時間檢查是否有誤。
1、smooth step函數, 這是一個有意思的函數,詳見 https://en.wikipedia.org/wiki/Smoothstep
我們對 smooth step做一些改進,整體開n次方, 讓線條的形態更可控
function smoothStep(t){// t的取值 0 - 1 var n = 2; var k = 2 * t * t * t - 3 * t * t;
return Math.pow(k, n);
}
我們可以利用這個函數,繪制出空間任意兩點的流動關系,這比繪制貝塞爾線要率很多,我們用這個函數模擬了訂單雨。
1、sketchup 和模數系統。
建筑的模數系統,設計的柵格模式,都是為了產生可控制的比例,讓設計更好看更易控制。
為了在短時間內建出可控的11.11的模型,我用了sketchup建模,并打了個柵格的布局,并在模型軟件rhino中提取出每個cube的中心點。
為了完成動畫從下而上的變化,我們還需將每個cube的中心點按照z軸排序,但為了讓同一層的立方體繪制順序更有機,我們對同一層的點進行了隨機排序。
2、一筆畫問題。
我們用連續的動畫生成一個的方塊,需要遍歷方塊上所有的點。
可惜,不能完美地一筆畫方塊,讓每個頂點出現一次,這正是哈密爾頓問題。
我們最后的路徑是 0 -> 1 -> 2 -> 6 -> 5 -> 4 -> 7 -> 3 -> 0 -> 4 -> 7 -> 6 -> 5 -> 1 -> 2 -> 3。
其中還有很多細節,如用web worker進行數據處理,尤其是對軌跡數據的前端數據實時簡化等。
首先,在繪制3D建筑時,Three.js中的ExtrudeGeometry函數提供了非常簡便的方法來繪制3D的幾何圖形。通過繪制城市輪廓并將其擠出到對應建筑數據的高度,來達到建筑的效果。但這只允許繪制大概規模在幾百數量的建筑。
針對城市規模的繪制,其中包括建筑,道路,及河流,通過合并幾何圖形的方法,通常將上述所有幾何圖形合并成唯一的幾何圖形,來節省CPU與GPU的計算,并減少兩者間的通信,從而實現大規模城市的繪制。
同時,根據城市規劃的不同,有些城市中存在大量高度為一層的建筑。盡管通過3D繪制方法來繪制,這類建筑的高度仍是微乎其微甚至不可見的,在這種情況下,將此類建筑歸為2D建筑,2D建筑的好處是僅通過單一的面就可以展現出建筑的形狀,這樣可節省大量的計算,同時保證性能的優化。
最后,如果希望展示城市中某一或幾個建筑的細節,需要建立obj格式或dae格式的3D模型,通過Three.js將這些3D模型導入原本這些建筑所在地圖上的位置。
在處理建筑的陰影時,可以通過在城市底部建立新的平面圖層,來接收建筑的陰影,同時可以在Three.js中選擇讓建筑也同時接收陰影,這樣,根據燈光的位置,就可以模擬出愈發真實的城市。在有些情況下,旋轉燈光的位置,來觀測建筑陰影的變換,可以模擬出城市中一天的陰影變化。
數據層面
數據內容為建筑的輪廓數據,在導入前在nodejs里進行后端優化,通過減少距離太近的點(可直接使用 Leaflet 作者在github分享的simplify.js)從而減少對建筑面的繪制。
通常城市的建筑大概在幾十萬左右的數量,首先根據重點區域進行抽析,減少所繪制的建筑數量,但即使這樣城市的輪廓集合數據依然非常大,前端一次性讀取如此龐大的數據,等待時間過長,在此解決方式是,需要按照建筑數據id隨機的方式切成若干個小的文件,減少每次請求的大小,這樣就可以以一種符合視覺的方式載入地圖。
飛線層面上,通常使用飛線的效果來表現城市中的物流。在實時數據中由于物流是不斷增加的,所以飛線理所應當的在不斷的增加,但是不斷創建新的飛線會導致內存泄漏,這就需要對消失的飛線進行復用。由于飛線的數量同樣會增加CPU與GPU的通信,而影響性能,所以我們會將所有線段合并成唯一的線段。之后,將這根線段分散成成需要的飛線數量,每一個小的線段進行更新位置,來達到飛線的效果。
數據可視化,開發不一定能夠還原設計師的美學理想。而開發有時能創造設計難用ps和ai表達的圖形,如何協作?
這次,我們利用dat-gui等控制組件,根據設計稿,做出了大致的demo界面,讓設計師根據拖動條,像操作軟件一樣進行調整,而我們通過console中打印出來的配置,返到代碼里去。
這么做還有個好處,我們現場接入的都是預發和線上的頁面,代碼不易修改,而大屏和我們電腦的屏幕有很大的色差,所以我們可以通過這種slider,針對大屏的顯示,再進行微調,非常方便。
在大屏開發中,我們著重解決了以下創新
首先還是要感謝一下公共數據平臺及產品部
團隊、小馬VMAX
團隊、阿云PR
團隊、共享業務事業部LBS
團隊和IT技術
團隊的通力合作,才有了最后的媒體數據大屏。最后說說這次項目在數據可視化專業方向上的感受。
這次數據大屏只是向受眾面最廣人群來普及數據概念以及增強大眾數據感受的一種方式。可能大家會覺得這種形式太偏向于視覺展示,但是從我們團隊日常接觸到的案例可以看出,很多事情在阿里是做得超前了,特別是數據方面,其實社會上有太多的政府部門以及各種公司組織對于自己有什么的數據都還不了解,更不用說從什么維度來挖掘數據的價值。而數據可視化是幫助大家降低理解感受數據門檻一種非常有效的方式。隨著越來越多的數據被更容易地采集、存儲、查詢,人們一下子沒有從中得到便利,反而因為數據量的激增和數據維度的復雜化迷失了方向,數據成為了一種門檻,這和我們的初衷是相悖的。通過這次雙十一媒體大屏項目,我們看到了更多的媒體從數據維度對雙十一進行報道,也看到了媒體對于城市屏這種個性化數據大屏的歡迎。從某種程度上來說,數據大屏成為了一種讓大家可以拋開知識背景公平閱讀理解數據的平臺,這讓我們更為興奮的想將數據可視化能力輸出給更多人。在雙十一之前,其實我們已經邁出了第一步。DataV數據可視化引擎已經幫助數夢工廠和貨車幫分別搭建了政務云平臺數據大屏和貨車幫業務數據大屏,并在云棲大會上得以展示。我們也希望能有更多有相同愿望或者對于數據可視化有興趣愛好的朋友能加入我們!
藍藍設計( m.ssll180.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、大屏設計、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、大平面設計服務
相關文章