今年在多個部門共同努力下，阿裡集團在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服務。通過該引擎可以利用已有元件低成本還原設計師産出的原型圖，快速完成多種資料源的綁定，并通過最終的可視化配置調整系統完成所見即所得的視覺調試，最終産出資料大屏。
datav資料可視化引擎大屏管理界面
之前我們做了幾年的展示類可視化項目，有些坑有些不足。十月走進項目室的時候，我們有這些期許:
1、高性能，告别記憶體洩露
記憶體洩露一直是我們揮之不去的心病，想象幾百個鏡頭對着馬總講話的時候，運作了10個小時的大屏忽然崩潰是何情景。
過去的幾年裡，在展示性很強的場合，我們常用svg去表現複雜的圖形，還記得去年為了snap.js裡存在的記憶體洩露問題而徹夜不眠（庫本身有坑，除此還會有性能問題），而且svg和普通canvas，性能有限，不能使我們能表達萬級數量實時更新的圖形，我們希望以更高性能的方式，去還原資料的海量。是以，今年大部分的螢幕都是基于webgl的，我們又嘗試了許多方法，使得性能更好，且看下文。
2、走向城市級别
全球和全境的展示，如中國的物流網絡，全球的飛線圖，已在曆年的大屏考驗裡愈發成熟。
更有意思的方向在哪裡？我們覺得走向城市尺度有挑戰，如何表現城市錯綜複雜的建築和街道結構、以及人類交易活動混沌而有序的空間分布。
3、從飛線到軌迹
飛來飛去圖，展示了很多年，我們如何更進一步，更有意思地展現資料。
我們想到的一個點，是讓交易沿着物流的方向行走，營造一個更真實的交易場景。
4、全面3d
2014年雙十一媒體大會裡，3d的可視化場景小試牛刀，今年覆寫更廣。
3d之于2d，有gpu加速性能上的好處，也為可視化增加了一個空間的次元，還讓某些場景更接近感官（如城市建築的展現）
5、工程化
第一次高規格的首都雙十一晚會，鞭策我們推陳出新，也把大屏開發的數量，提到了去年的4-5倍，時間非常短，調整也很多，如何标準化地去做形态各異的不同大屏？
今年的雙十一盛況空前，海量的訂單和支付資料，經由用戶端和大後端的處理、公共資料平台及産品部同學的合并和清洗，到了可視化大屏前，面對數百媒體以及媒體背後的觀衆。首先從我們如何處理和展現這些資料來開始我們的技術分享。
目前任何一種繪圖技術，都很難完整的去反映雙十一的海量交易，但我們盡力還原最真實的情況。
資料在資料部門清理之後，進入了我們的流程。
datav資料可視化引擎
總體，我們今年把所有的屏，運作在阿裡雲的資料産品datav資料可視化引擎上。datav資料可視化引擎是一個集螢幕管理、多屏通訊、釋出打包等功能為一體的大屏生産工具，除了可以集中管理螢幕，并通過頁面遙控大屏，還可以通過配置頁面，實時調整已經釋出上線的大屏的一些參數。
前端模型
我們的架構防止3種情況：
1、防網絡延遲/斷網
2、記憶體洩露
3、資料量過大
我們想表現2點：
1、海量的資料展現
2、飛線群和交易情況一起漲落，比如10日淩晨海量飛線，11日早晨數量變少。
我們的原則是資料上層層緩存，層層緩沖，元件上利用好gpu通信，架構如下圖。
幾乎所有的屏都以一定地頻率請求服務端。接收到資料後還要有處理的政策.
以我們的飛線和軌迹的處理政策為例，講講我們處理的流程。
飛線的資料，接口傳回一般都如下格式:
資料池：
最簡單的動畫模型是有啥畫啥。
不可能來什麼畫什麼。頁面重新整理率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次方， 讓線條的形态更可控
我們可以利用這個函數，繪制出空間任意兩點的流動關系，這比繪制貝塞爾線要高效率很多，我們用這個函數模拟了訂單雨。
cube字
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北京城市
首先，在繪制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表達的圖形，如何協作？
這次，我們利用datav-gui等控制元件，根據設計稿，做出了大緻的demo界面，讓設計師根據拖動條，像操作軟體一樣進行調整，而我們通過console中列印出來的配置，返到代碼裡去。
這麼做還有個好處，我們現場接入的都是預發和線上的頁面，代碼不易修改，而大屏和我們電腦的螢幕有很大的色差，是以我們可以通過這種slider，針對大屏的顯示，再進行微調，非常友善。
在大屏開發中，我們着重解決了以下創新
與後端保持實時一緻
防網絡延遲/斷網
防記憶體洩露
防資料過載
防大屏色差
緊急預案
首先還是要感謝一下<code>公共資料平台及産品部</code>團隊、<code>小馬vmax</code>團隊、<code>阿雲pr</code>團隊、<code>共享業務事業部lbs</code>團隊和<code>it技術</code>團隊的通力合作，才有了最後的媒體資料大屏。最後說說這次項目在資料可視化專業方向上的感受。
這次資料大屏隻是向閱聽人面最廣人群來普及資料概念以及增強大衆資料感受的一種方式。可能大家會覺得這種形式太偏向于視覺展示，但是從我們團隊日常接觸到的案例可以看出，很多事情在阿裡是做得超前了，特别是資料方面，其實社會上有太多的政府部門以及各種公司組織對于自己有什麼的資料都還不了解，更不用說從什麼次元來挖掘資料的價值。而資料可視化是幫助大家降低了解感受資料門檻一種非常有效的方式。随着越來越多的資料被更容易地采集、存儲、查詢，人們一下子沒有從中得到便利，反而因為資料量的激增和資料次元的複雜化迷失了方向，資料成為了一種門檻，這和我們的初衷是相悖的。通過這次雙十一媒體大屏項目，我們看到了更多的媒體從資料次元對雙十一進行報道，也看到了媒體對于城市屏這種個性化資料大屏的歡迎。從某種程度上來說，資料大屏成為了一種讓大家可以抛開知識背景公平閱讀了解資料的平台，這讓我們更為興奮的想将資料可視化能力輸出給更多人。在雙十一之前，其實我們已經邁出了第一步。datav資料可視化引擎已經幫助數夢工廠和貨車幫分别搭建了政務雲平台資料大屏和貨車幫業務資料大屏，并在雲栖大會上得以展示。我們也希望能有更多有相同願望或者對于資料可視化有興趣愛好的朋友能加入我們！