前言
也許很多人都會覺得奇怪， 在這樣一個更多以後臺資料分析為主的公司， 為什麼需要一個專注於前端的團隊?今天這篇文章就來講述那些年我們錯過的前端資料視覺化，
需求
那麼， 在我們的專案中是如何實現資料視覺化的呢?下面以這樣一個需求開始我們的講解： 我們需要向使用者展示目前使用者產品的風險情況， 有沒有風險產生、產生於何地、是否被攔截等資訊。
最終效果圖：
技術選型
說到資料視覺化， 可謂是百花齊放， 一時之間前端界出現了琳琅滿目的協力廠商庫： Highcharts ， Echarts ， Chart.js ， D3.js 等。 但是， 萬變不離其宗。
總的來說， 所有的協力廠商庫都是基於這兩種流覽器圖形渲染技術實現的： Canvas 和 SVG 。
通過各種比較之後，
為什麼不選用更加豐富的圖形庫， 比如 Echarts ?
——資料視覺化看似簡單， 但其中蘊含的科學可謂博大精深。
Echarts 提供的圖表的確可以滿足大部分的需求， 遵循了資料視覺化的一些經典範式。 然而， 每個不同的行業對於資料視覺化都會有一些定制化的需求， 希望能以一些帶有行業特徵的圖表向使用者展示資料背後隱藏的秘密。
因此， 我們希望可以使用一個比較基礎的圖形庫， 這個庫對一些基礎演算法進行了封裝。 然後在此基礎之上， 我們可以進行二次開發， 定制適合的圖表向使用者展示更有針對性的資料。
為什麼不選用基於 Canvas 的庫?
——我們的應用存在大量的用戶交互場景。
在 Canvas 中， 如果要為細細微性的元素添加事件處理器，
所謂成也蕭何敗蕭何。 這裡的蕭何源於 SVG 是基於 DOM 操作的。
眾所周知， 頻繁的 DOM 操作十分消耗性能。 對於用戶體驗的影響便是可能出現閃爍、卡頓等現象。 幸好， 偉大的前端界對於這個問題已經有了解決方案： Virtual DOM 技術 。
所以我們要做的， 就是選擇一個支援 Virtual Dom 技術的框架與 D3.js 結合使用。 同時， 我們的最終目標是將這些圖示封裝成可複用的組件。
因此， 最終我們選擇了 facebook 出品的 React 。 這是一個相對輕量、簡單、專注於 View 的庫。
實際問題
細心的讀者一定會提出這樣一個問題：既然是一個即時資料展示圖表， 如何做到如此頻繁且流暢地渲染大量資料?其實很簡單， 關鍵在於把握以下兩個階段：
1. 資料的獲取。
在這裡， 我們主要還是採用了用戶端主動輪詢拉取的方式。 只要選定了採樣頻率， 剩下的就是每隔一段時間從伺服器拉取資料了。
當然， 這種方式的缺點也顯而易見：由於延時造成的資料滯後， 並且隨著時間的推移， 這種滯後會越來越嚴重。
為了解決這一問題， 我們會在一段時間之後進行資料即時性的校正。
2. 數據的渲染。
需求中， 攻擊情況需要依據時間順序進行展示， 表現為一條從攻擊源到攻擊目標的運動軌跡。 如果一段時間內產生了大量的攻擊， 那麼頁面中的 DOM 元素會迅速增加，渲染速度變慢，出現卡頓現象。
為了解決這一問題，當每一條運動軌跡展示完畢的時候，相應的 DOM 元素會被及時銷毀。當更大量的攻擊產生時，我們會控制展示的數量，同時發出警告，因為這明顯已經屬於一種攻擊非常極端的情況了
未來展望
事實上，對於即時資料的處理，前文所述的方法並不是最佳實踐，只能說是一種降級方案。 我們的長遠目標是要做到真正的即時資料展示，因此下一步我們會即時資料推送技術，敬請期待。
豈安 Warden 2.0 監控屏
大資料 時代，前 端也迎來了新的挑戰。資料視覺化已然成為了新的風向標。資料團隊的前端要做的就是： 用最科學的方法向使用者展示最形象的圖表 ，而這，也是我們前行的目標。
作者簡介
張靜 豈安科技前端架構師
三年互聯網前端開發經驗，曾參與多個大型應用的前端開發，負責豈安科技產品的前端架構設計與開發。
那麼頁面中的 DOM 元素會迅速增加，渲染速度變慢，出現卡頓現象。為了解決這一問題，當每一條運動軌跡展示完畢的時候，相應的 DOM 元素會被及時銷毀。當更大量的攻擊產生時，我們會控制展示的數量，同時發出警告，因為這明顯已經屬於一種攻擊非常極端的情況了
未來展望
事實上，對於即時資料的處理，前文所述的方法並不是最佳實踐，只能說是一種降級方案。 我們的長遠目標是要做到真正的即時資料展示，因此下一步我們會即時資料推送技術，敬請期待。
豈安 Warden 2.0 監控屏
大資料 時代，前 端也迎來了新的挑戰。資料視覺化已然成為了新的風向標。資料團隊的前端要做的就是： 用最科學的方法向使用者展示最形象的圖表 ，而這，也是我們前行的目標。
作者簡介
張靜 豈安科技前端架構師
三年互聯網前端開發經驗，曾參與多個大型應用的前端開發，負責豈安科技產品的前端架構設計與開發。