數據可視化的web前端開發採用什麼樣的架構比較合適？

12-29

大概就類似於Google Analytics這樣形式的web程序，主要是各種數據和圖表的展現。因為人力不夠，所以盡量避免造輪子，期望採用一些開源框架來提高效率。當前是使用NodeJS做前後端分離，前端準備用Polymer構建組件庫，用HighCharts或者Echarts來繪製圖表，也在考慮要不要用Backbone等框架來做成單頁應用提高體驗。

期望能夠得到業內同行的一些經驗意見。

我反對說做這種平台前端只是簡單的把圖和表查詢填滿而已，因為我是實際的做過。列舉幾個例子：

平台數據圖化展示分多種類型，參見echart的文檔，對應不同的配置前後端如何約定協議？可以做到統一，可配置，可擴展？

表的展示相對固定，但是不同的表項會有額外的一些擴展操作比如對單行的詳情查詢，列的排序。

當然這些都已經有了很成熟的前端解決方案，但是如何融合到一起，我相信你如果做過就知道我在說啥了…

對應的一套後端查詢體系我們的架構是nodejs做的，dba和數據工程師負責對接我們mysql的視圖，保證我們的查詢簡單化。

對應不同的數據產生對應的pdf，excel，xml，json，表，圖都已經做成了一套統一的api。方便復用需求。

至於單頁和非單頁，我覺得從開發的角度考慮，單頁不利於快速產生新的數據展示需求，除了前端和後端都需要額外開發外，速度和人力也是個問題。

非單頁是我們採用的，通過nodejs統一配置的路由出口，通過一套配置加一個中間數據的filter機制保證復用性。

一個新產品來了，我們通過配置加寫過濾器的方法，可以非常快速的開發很多頁面，而不必關注路由，控制器，查詢db等操作。當然，所有頁面提供的交互肯定也會不一致，我們同樣採用全配置的方式，前端js讀取之後再採取對應的策略加交互。（後期會改進成按需）

說真的，數據顯示類產品，如果圖表組件不是自己開發的，就被說成沒有技術含量，我是真心的想說朋友你有點反智了…

大家都知道這種東西很多公司都是內部系統，內部系統一般只有產品而沒有ui的，前端的美醜不是第一要務，要緊的是理解和溝通運營的數據需求，一個需求如何實現成本更低我相信經驗老道的程序員自然有自己砍需求的方法，所以還要有一些額外的培訓產品經理的工作…

最後，你們真的以為除了圖表之外就沒了么。一套查詢加時間控制項的組件開發起來也是很有難度的，當然這部分也是可以抽象成可配置的。

關鍵看你怎麼想，是當個切圖查介面的，還是想解放自己做更多的人了。

有點跑題，架構和某個答主類似，bootstarp，jq，vue，lithe，echart，jqtable，nodejs 只要用express，orm2，緩存用的內存nodejs自己做的，一整套運維前端自己做的，沒有後端支持，3-4個人包括2個大數據工程師。可能還是沒什麼概念，通過配置這點人力，2個月從啥都沒有，變出來一個完整的數據展示後台，包含150多個查詢頁面和上千項數據展示的需求。

我們還沒加班…

去年做了快一年的數據可視化，說不上架構，主要用HighCharts+DataTables兩個庫，解決圖和表的這兩種承載數據的展示容器。

前後端JSON通信沒什麼好說的。

搞數據可視化，數據量都不會小，如果帶有實時操作的，後端需要做好預計算、中間量保存、運算結果緩存。否則稍微帶交互操作拉取實時計算的數據就死翹翹。

單頁應用體驗會稍微好點，原因後面說。

數據可視化站點，和一般的富應用web站點沒什麼區別。

一個數據可視化站點的好壞，關鍵在於整個數據信息展示路徑是否清晰。

例如：
1.從數據指標趨勢、波動，用戶可以得出一些關於這組數據的結論。
2.從結論，反過來觀察指標趨勢、波動，用戶可以得出產生結論的原因。

數據可視化不是說上了餅圖、折線圖、柱狀圖就完事了，而是要能把這兩條線給用戶清楚的理出來。

繞遠了，就前端架構來說，真沒覺得有什麼好說的，怎麼弄都行。

前面提到單頁應用體驗稍微好，原因是這種數據信息流的站點，單頁應用中的轉場動畫，可以稍微緩解用戶在海量數據中的迷茫，幫助用戶理解整個數據信息路徑。

所謂數據可視化的web的前端其實從一個廣義角度講，跟傳統網頁開發沒有什麼區別。都是數據 + 模板，組件化模塊化也都是類似。前後端分離什麼的，也是跟傳統網頁開發沒有兩樣。現在node作為中間層來做分離方案是比較多(天貓的wormhole, 淘寶的midway), 數據處理交給java或者其他更適合的，node用來做密集IO和模板展現。（但是對於體量不大的應用，其實不需要考慮這麼多）

要不要做成單頁面應用提高體驗取決於你的應用還得看場景，還有開發複雜度等因素（其實一開始不建議做成單應用，除非一開始就有完整的規劃）。如果類似Google Analytics的程序，也不是整站都直接單應用，還是取決於場景。因為往往在網頁中單應用的形式，往往複雜度都會高很多，處理的問題也會疊加，圖表的性能問題，內存問題，持久性問題，過場的問題等等，都是需要考慮的。

之前我做過一個項目，其實都沒用組件庫(當然後來維護問題會很多,也不夠優雅)。但是對於構建組件庫，無論是Polymer、react感覺都可以，react這麼火，但是還是選自己比較熟悉的更好。

前端框架上最好還是mvvm的框架，vue, angular, react都很不錯，用過vue，現在更傾向於使用react。圖表展示，是更重數據交互的，所以肯定是開發以數據驅動的方式來。圖表庫來說，echarts是比較牛逼的了，底層是canvas，百度開源的。highcharts是svg的，老牌牛逼圖表庫，商業使用需要授權。之前我們用的是kcharts(阿里自己開發)。現在更傾向於百度Echarts，從圖表展現和用例豐富上，可以減少很多自己開發的工作量。

這樣想：如果把echarts去掉，直接把json顯示到textarea里，跟最普通的web項目比，有什麼差別嗎？然後搞定之後，也只是把對textarea的賦值改成調用echarts api而已啊

任何架構或框架你沒有嘗試過，以後都會遇到問題，且有可能導致項目延期很長時間，代碼質量也有很多問題

你們明明再說數據圖形化的事卻偏偏說成數據可視化。

專註做數據平台4年+了，團隊里的前端選型基本是我來定，這邊前端團隊技術選型基本上定型下來是 jQuery + Backbone + Bootstrap + Highcharts + RequireJS，各方面算可攻可守。

WEB組件方面，Polymer這玩意在實踐方面總感覺還不是很成熟，只是在瀏覽器里用是沒問題了，但如果報表涉及到SERVER端渲染輸出報表時，可能需要驗證一下可行性。我們基本還是用jQuery Plugin + Backbone View的風格來做通用組件和業務組件的包裝。

框架上，Angular 按理說是很適合這種數據導向的展示的，但貌似裡面坑也不少。這種框架選型上我的經驗是一定要堅定堅持，新人最容易犯的錯誤就是在各種技術選型之間搖擺不定，在框架上這種猶豫尤其致命，沒有持續地積累和實踐很難確保整個系統的穩定性。相反，跟一個框架相處時間久了，進入蜜月期那基本上是所向披靡，能為整個系統以及新技術使用保駕護航。至於說單頁應用，這個跟Backbone沒啥區別，貌似沒什麼框架做不了單頁應用吧……

圖表上，Highcharts這邊已經用得相當順了，普通的圖表基本沒有不能做的；但建議還是要在D3js上投入一定的預研成本，否則有些特殊的可視化案例突然要做會做不出來。值得一說的是，Highcharts的數據格式是挺成熟挺值得參考的一種協議實現，這個配置是可以考慮在自己的協議棧里引入、然後讓後端數據能直接控制部分的圖表展示的。我也正在團隊里推進以Highcharts為主的JSON API的設計，能做到很方便的數據對接能力和很強的擴展性。

後端的東西水很深，但只是SERVER層用node肯定是沒問題的，再繼續往後走的技術選型可選擇的太多了，單是資料庫的選型和架構設計估計後台那邊都能開個幾天會。這個問題不是前端應該插手的。

201611更新:

現在開始比較多複雜界面簡單圖表型的站開始往 react + echarts 遷移，對移動端和工程化友善點。比較複雜的圖表還是用 d3 然後上面封裝一層。逐漸淘汰掉 backbonejs。

純展示一個圖表其實沒什麼難的，用echarts還是用textarea展示一堆裸數據區別也僅僅是一個好看一個難看嘛（捂臉

不過LZ所說的數據可視化平台我理解應該難點在於圖標與UI的聯動，就跟看股票或者看地圖的時候似的，要能隨時調整比例尺啊什麼的似的。

這樣就需要對圖表組件進行一定封裝，讓它能夠動態重繪。否則的話每次改數據就重新生成圖表可能就會效率低下，也許拖動比例尺的時候就會看著圖表稀里嘩啦的閃。
如果圖表組件本身支持重繪那就容易一些，只是關聯一些事件而已。否則可能需要hack進圖表組件的內部來提供這種功能。

在這個前提之下怎麼構建UI的其他部分我覺得跟構建其他應用沒有什麼差別。
那些用來調節圖表的UI再炫酷無非也就是一個可視化的「查詢編輯器」，通過操作UI來生成一組查詢條件，在客戶端或者發向服務端，用這組條件來查詢數據，最後將結果扔進圖表。這和將結果扔進表格其實是一回事，對吧……

推薦直接用Node/io做直出，D3做圖表處理，最好是docker化,結合redis做持久化。
Polymer使用比較簡單，但成熟度沒有angular高，react的flux架構可以試試，支持前後端的數據處理。

可以參考下 Kibana

現在也在做類似的數據展示，用vue加echarts

挖墳。

看了一下問題，沒有非常具體的應用場景和技術難題，我認為架構應該是基於業務和技術難點去做的。感覺自己還不能達到架構的層次，但還是想表達一下和其他人不同的看法。

假如只是一個一般頁面加個數據表提高說服力，這種「數據可視化」沒什麼可說的。

假如題主說的「主要是各種數據和圖表的展現。因為人力不夠，所以盡量避免造輪子，期望採用一些開源框架來提高效率。」這是一個相對簡單的選型問題。可以去看看antv和echarts,兩框各有優勢，主要antv的數據處理和拓撲類，echarts有3D圖表和2D下更豐富表現。陳立林：echarts antv 區別比較？（知乎吃了我一段關於寫數據處理的，有心情再補了。），數據交互使用Graphql。用來填數據應該夠了。

假如更高難度業務場景就要去理解業務場景和技術難點在哪了，一些其他的已經成熟的業務場景有沒有可以借鑒的方案。

比如一些比較常見的特點：

1，絕大多數都是get請求，分析的數據都是從外面採集採集過來的，單向的數據流。

2，傳統場景下的話，請求API的數量會很多，可復用性很差。數據多，數據關係複雜，業務複雜，服務端複雜，這樣導致交流請求數據介面成本大大大大大大大提升，改動需求難度大大大大大。

3，有大量數據要放在前端計算。

4.大數據的實時性展示需求，交互方式？

5.服務端太大壓力，需不需要前端分擔，比如數據點太多太大，計算壓力大，可以選擇分片傳來給前端，前端一點點渲染上去有一個漸進效果。

6.客戶可能需求明確，角度刁鑽。客戶可能沒明確需求，但有錢就像要個滿意的產品。（反正就要改需求）。

7....

驅動架構的點，還是看場景和需求吧。明白了難點所在，架構思路就應該會清晰很多，相信各位大佬針對各種特點也有自己心儀的架構。有和其他web應用相同可以借鑒的地方，完全照搬卻不一定可行。當然架構的最終目的還是在完成需求之餘，讓開發就是介面填數據，最終高效出產品。

隨便借個圖，看圖寫作文。

這個圖展示非常好的展示了店家的轉化率，從展現到客人下單中一個遞減比例，當然要具體訂單數還是可以有的。

店家：「難不成這個人是個傻逼？我賣多少我不知道？就算我不知道給我看這個東西有個卵用，是來要自行車的吧？」

我突然又想到一個段子。

web使用數據表羅列了各種數據,清晰詳細。

老闆：「把那什麼化的前端都炒了吧，請個會用sql的實習生」

數據查詢+展示而已，我們用的是前端：vue+echarts，後端Django+mysql,原始數據存在Excel里，需要先解析存到資料庫

我在看薦數據分析黑板報有看到關於數據可視化的淺析，由於人類大腦在記憶能力的限制，所以我們利用視覺獲取的信息量多於感官，在大數據與互聯網時代，企業從傳統的流程式管理方式過渡到基於數據的管理方式將會成為必然的趨勢，數據可視化能夠幫助分析的人對數據有更全面的認識。
常見方法
數據採集：在數據採集過程中進行數據分類，根據數據屬性和方法去可視化解決問題；
可視化映射：將數據的數值、空間坐標、不同位置數據間的聯繫等映射為可視化視覺通道的不同元素如標記、位置、形狀、大小和顏色；
數據變換和處理：通過去噪，清洗數據、提取數據；
用戶驗證：數據的正確與否，需要用戶的大膽假設和積極驗證，反覆驗證數據的合理性等，從而向公眾或者上司展示數據。