摘要：提供的圖表的確可以滿足大部分的需求，遵循了數(shù)據可視化的一些經典范式。數(shù)據可視化已然成為了新的風向標。數(shù)據團隊的前端要做的就是用最科學的方法向用戶展示最形象的圖表，而這，也是我們前行的目標。

也許很多人都會覺得奇怪，在這樣一個更多以后臺數(shù)據分析為主的公司，為什么需要一個專注于前端的團隊？今天這篇文章就來講述那些年我們錯過的前端數(shù)據可視化，以此來解答這個問題。

那么，在我們的項目中是如何實現(xiàn)數(shù)據可視化的呢？下面以這樣一個需求開始我們的講解：我們需要向用戶展示目前用戶產品的風險情況，有沒有風險產生、產生于何地、是否被攔截等信息。

最終效果圖：

說到數(shù)據可視化，可謂是百花齊放，一時之間前端界出現(xiàn)了琳瑯滿目的第三方庫： Highcharts ， Echarts ， Chart.js ， D3.js 等。但是，萬變不離其宗。

總的來說，所有的第三方庫都是基于這兩種瀏覽器圖形渲染技術實現(xiàn)的： Canvas 和 SVG 。

通過各種比較之后，我們最終選擇基于 D3.js 進行開發(fā)。

“
*為什么不選用更加豐富的圖形庫，比如 Echarts ？
——數(shù)據可視化看似簡單，但其中蘊含的科學可謂博大精深。*
”

Echarts 提供的圖表的確可以滿足大部分的需求，遵循了數(shù)據可視化的一些經典范式。然而，每個不同的行業(yè)對于數(shù)據可視化都會有一些定制化的需求，希望能以一些帶有行業(yè)特征的圖表向使用者展示數(shù)據背后隱藏的秘密。

因此，我們希望可以使用一個比較基礎的圖形庫，這個庫對一些基礎算法進行了封裝。然后在此基礎之上，我們可以進行二次開發(fā)，定制適合的圖表向用戶展示更有針對性的數(shù)據。

“
*為什么不選用基于 Canvas 的庫？
——我們的應用存在大量的用戶交互場景。*
”

在 Canvas 中，如果要為細粒度的元素添加事件處理器，必須涉及到邊緣檢測算法，無疑為開發(fā)帶來了一定的難度，同時，采用這種方法并不一定精確。相比之下，SVG 是基于 DOM 操作的，支持更精確的用戶交互，無疑更適合我們這樣一個小規(guī)模的團隊。

所謂成也蕭何敗蕭何。這里的蕭何源于 SVG 是基于 DOM 操作的。

眾所周知，頻繁的 DOM 操作十分消耗性能。對于用戶體驗的影響便是可能出現(xiàn)閃爍、卡頓等現(xiàn)象。幸好，偉大的前端界對于這個問題已經有了解決方案：?Virtual DOM 技術。

所以我們要做的，就是選擇一個支持 Virtual Dom 技術的框架與 D3.js 結合使用。同時，我們的最終目標是將這些圖標封裝成可復用的組件。

因此，最終我們選擇了 facebook 出品的 React 。這是一個相對輕量、簡單、專注于 View 的庫。

細心的讀者一定會提出這樣一個問題：既然是一個實時數(shù)據展示圖表，如何做到如此頻繁且流暢地渲染大量數(shù)據？其實很簡單，關鍵在于把握以下兩個階段：

數(shù)據的獲取。

在這里，我們主要還是采用了客戶端主動輪詢拉取的方式。只要選定了采樣頻率，剩下的就是每隔一段時間從服務器拉取數(shù)據了。

當然，這種方式的缺點也顯而易見：由于延時造成的數(shù)據滯后，并且隨著時間的推移，這種滯后會越來越嚴重。

為了解決這一問題，我們會在一段時間之后進行數(shù)據實時性的校正。

數(shù)據的渲染。

需求中，攻擊情況需要依據時間順序進行展示，表現(xiàn)為一條從攻擊源到攻擊目標的運動軌跡。如果一段時間內產生了大量的攻擊，那么頁面中的 DOM 元素會迅速增加，渲染速度變慢，出現(xiàn)卡頓現(xiàn)象。

為了解決這一問題，當每一條運動軌跡展示完畢的時候，相應的 DOM 元素會被及時銷毀。當更大量的攻擊產生時，我們會控制展示的數(shù)量，同時發(fā)出警告，因為這明顯已經屬于一種攻擊非常極端的情況了。

事實上，對于實時數(shù)據的處理，前文所述的方法并不是最佳實踐，只能說是一種降級方案。我們的長遠目標是要做到真正的實時數(shù)據展示，因此下一步我們會實時數(shù)據推送技術，敬請期待。

大數(shù)據時代，前端也迎來了新的挑戰(zhàn)。數(shù)據可視化已然成為了新的風向標。數(shù)據團隊的前端要做的就是：用最科學的方法向用戶展示最形象的圖表，而這，也是我們前行的目標。

反爬蟲
文章來源：http://bigsec.com/

張靜 豈安科技前端架構師?
三年互聯(lián)網前端開發(fā)經驗，曾參與多個大型應用的前端開發(fā)，負責豈安科技產品的前端架構設計與開發(fā)。