大數據浪潮下的前端工程師
馬雲曾經說過『人類正從IT時代走向DT時代』。正如他說言，今天幾乎所有的互聯網公司背後都有一支規模龐大的數據團隊和一整套數據解決方案作決策，這個時代已經不是只有矽谷巨頭才玩數據的時代，是人人都在依賴著數據生存，可以說如今社會數據價值已經被推到前所未有的高度。
我作為一名前端工程師在阿里巴巴數據團隊工作多年，深入了解數據生產加工鏈路與產品化。我們這群前端是與界面最近的工程師們，似乎與數據離得很遠，對於我們來說與數據有些怎樣連接呢。
完整數據鏈路
首先，我用直觀的一張圖繪製出數據採集到產出的流程，中間省略技術細節。
業界常提到的 Hadoop，Spark，Druid 都在用戶側的下方，也就是數據研發與數據挖掘職能的工作。相對於前端職能而言，一定是與輸出終端相關，包括本職工作數據類產品的研發，如阿里指數或百度指數這樣的數據展示型產品，還有較為複雜的 BI 工具等，細分起來，最特別的工作應該是數據採集和數據可視化的工作。
但到今天而言，數據研發工程師已經很難說只精通其中一種技術。任何一環深入下去都涉及到整條鏈路的打通，我就從數據採集，數據可視化，數據產品研發到人工智慧幾個板塊來寫寫我的體會與經驗。
數據採集
過去還是流量為王的年代，流量就意味著錢，互聯網都用著簡單粗爆的方式導流。在過去做過站長的對數據採集已然不陌生，包括著名的第三方平台 CNZZ（現友盟+） 和 google analytics 兩個平台幾乎都使用過。
基本原理
Web 端的數據採集的鏈路從客戶端或後端開始一直到存儲結束。因此，數據採集這個動作涉及到了前端，客戶端，數據研發，產品經理等職位的參與。在這個過程中，前端工程師的工作集中在不同客戶端上（PC、iOS、Android）的信息收集及埋點上。
再說到採集應用信息這件事，系統可以採集到的信息越豐富，那麼數據可分析的內容就越多。數據採集在 Web 端可以分為幾個步驟，包括前端 JS 載入，觸發事件時收集各種瀏覽器端的信息，根據用戶行為上報日誌伺服器。
Web 端的數據採集可以收集哪些信息呢？這是一件同時帶有『用戶體驗』和『業務反饋』的工作。為什麼這麼說呢。
UX 和前端工程師都非常關注用戶體驗反饋，而用戶體驗反應在界面上可以表現為習慣性的瀏覽軌跡，點擊熱區等。一般可以採樣一部分用戶的行為來分析，比如發起一次純交互改版後，我們需要做一次 AB Test，對於等比例用戶分布的點擊熱力圖，同時收集一部分用戶的調查反饋，來驗證改版後的效果。如果是交互與功能同時改版的話，相對較難判斷影響面。
業務反饋就比較自然了。對於網站應用來說，一定會帶有用戶登錄的信息，或關聯業務的一次活動，那麼自然會把業務信息都帶到一起。此外，業務形態不同，會設計業務獨有的打點採集方式。如區塊明顯的應用， 我們需要精確的確定站點，頁面，區塊和鏈接，可以達到流量的精準定位，就是典型的為業務形態定製採集方案。對於區塊化不明顯的後台類應用就不完全適用。精細化採集更需要運營或產品經理對於產品功能有細節上的思考。
此外，業務反饋還可以從前端本身看，前端需要的穩定性指標也是從界面上採集到的，比如載入性能、JS 報錯等。大規模應用背後開發一般都有自己的監控平台，而前端的監控就從用戶界面開始。
再說說埋點，這是需要大量前端開發的工作。其實近年來為了減少開發的投入，業界有好一些方案產生，其中比較流行的是可視化埋點和無埋點。
可視化埋點對於 PD 或運營來說就十分友好了，僅通過界面就可以配置打點的位置。但有一個極大的問題，我們的界面經常會改變，導致了元素的變化，埋點就需要經常作更新。
另外就是無埋點，這是一些新興數據公司如 GrowingIO 推崇的概念。其實無埋點的理念十分簡單就是全採集，不論是有效還是無效，所有的點擊行為都會被採集下來。這種方案最大的優點就是零工作量，採集的數據非常全，缺點就有大量的無效信息需要到計算或存儲過濾。這是計算資源、硬體存儲與人力成本之間的考量。
新採集
前端只是客戶端採集的源頭。比如音頻，圖像，視頻等非結構化數據都需要可以量化成結構化數據的方式，沉澱有效信息；在 IoT 領域，更是涉及到硬體設備上採集技術，比如今天在無人駕駛領域，百度開放了所有無人駕駛技術，為了就是控制數據源頭。
數據多樣的同時，我們需要什麼樣的數據才是有價值的問題。同樣的信息有這樣收集，那樣收集的，但最好採集的方式是要考慮的。今天非常多的數據是被動的收集的，用戶沒有發現價值還被強迫採集。數據其實是業務的一部分，業務應該會自生產我們需要的數據，通過智能化手段改善業務，這是主動的方式。
數據可視化
經過清洗，計算與存儲後達到數據展現的階段。無論是面向哪個群體的數據產品都繞不開對數據的可視化，可以說產品端除了考慮分析鏈路或操作鏈路外，最重要的工作就是如何更好的反應它們，可視化在其中至關重要。
數據可視化絕不是單純的視覺，也不是單純的圖表，它是幫助人類從原始信息中做到對信息有一定程度的認知，任何可視化手段都為了這個過程，而非結果。如果計算機已經可以得出結論，那麼可視化是沒有意義的。
數據可視化對於我們而言其實是一個跨界的領域，交互視覺知識遠遠不夠，還還涉及硬體、客戶端編程、數據分析、機器學習等領域。
什麼是優秀的可視化圖表
數據可視化常指將數據用統計圖表方式呈現，從大的分類上看可以分為統計數據可視化、關係數據可視化、地理空間數據可視化，當然還有時間序列數據可視化、文本數據可視化等。
在這裡，我就從數據可視化中的圖表這個宏觀概念來講講，如何來構建可視化圖表，什麼是優秀的可視化圖表。
我們看過形形色色的圖表，可視化圖表是從數據 -> 清洗 -> 交互 -> 視覺 -> 開發的整個過程下創造的。那麼優秀的可視化作品具備哪些特徵呢？正如上圖所說，優秀的可視化作品 = 信息 + 故事 + 目標 + 視覺形式。
定義合適的可視化圖形，可以說是最為關鍵的。在統計領域的運用從 18 世紀已經有經典的案例。我相信每個人都熟知大部分的的統計圖表，如線柱餅等形式，但統計圖表的使用方式往往被經驗化，其實它也是一門學問而不是經驗。一般情況來看，線柱餅的確可以完成我們大部分的需求，但對於大數據場景或具體業務場景下就需要更多理論在背後作基礎。
我給出對於定義圖表的原則是即直觀又豐富，即相關又離散，看上去是兩對矛盾的詞。對於統計圖表與表格最大的不同在於它經過了一次對於數據的加工，反映在我們腦中的信息也許更容易觸達所想，同樣也可能會形成誤導。因此，我們需要展現出多方面的信息。
舉個例子，比如我們要研究不同瀏覽器在應用中的比例，主流的有 IE 系列，chrome，firefox 以及 Safari 等。
在統計圖表中，餅圖是我們最常用的圖形。但大部分用戶並不清楚餅圖僅適合少分類的情況，而在實際場景下大多是多分類的數據，這時餅圖是非常糟糕的圖表選擇。這種情況下橫向柱形圖更容易看到直觀的對比。
此外，餅圖還有一個致命的問題就是不能反應時間維度的變化。加入時間維度的分析，等於加入了變化的趨勢，不再是定量分析，這時候用堆積面積圖（Stacked Area Chart）是最合適的。
回到我說的原則了，即直觀又豐富表示了我們儘可能的展示我們所能提供的數據，用一種最直觀的形式。即相關又離散表示了我們需要把數據之間的關係表現出來，是趨勢還是對比，而優秀的可視化圖表在設計的時候還會考慮留下一些可分析的內容，讓閱讀者思考。
我在前年負責瀏覽器升級的事項，首先對於這件事有一個明確的目標，即 IE8 的比例佔總數的 5% 以下就可以放棄，接著在網站上放一些公告提示，以及客服導向，近一個月的效果非常顯著，IE 8 從 10% 下降到 4% 左右。在彙報時我就用了堆積面積圖來說明效果。
利用可視化圖表就可以完成初級的一些運用，比如做信息圖，產品中統計數據的展示等。
分析領域
理解可視化圖表是進軍數據可視化的第一步。數據可視化這個術語被工業界最常運用到的場景是 BI（商業智能）工具上，我們最熟悉的 BI 工具就是 Excel，它是以表格為主體的工具。
BI 工具的目標定位是數據分析師，最知名產品的有 tableau、chartio，還有開源的 metabase。它們都擁有完整的數據鏈路，包括數據源的接入（Data Source），到選擇圖表（Chart），最後可以製作儀錶盤（Dashboard）。
我們可以查閱 [Gallery | Tableau Public](Gallery) Tableau Gallery 中一些優秀的儀錶盤製作，有一個感官上的認識，看得到很多報表在交互與視覺上均做了深度的定製。
在這個領域中，有幾個關鍵的支持：
1. 多數據源的支持，一定能夠快速建立 OLAP 模型，這是基礎，大規模系統會提前部署好相應的集群。
2. 可視化圖表的豐富度與可交互性上是決定性的。在分析過程中，需要很多輔助手段，過去在表格當中是很常見的，但在圖表上一樣需要這樣的支持，如去噪點（如峰值），不同圖表同維度的聯動，值與比例的轉換等等。
3. 非常便捷的報表服務。比如現在 BI 工具都會提供儀錶盤的功能，對於分析人員提高工作效率非常重要。
到今天，大規模的數據集上的數據分析已是常態，那我們不得不引入更多的分析方法，像 tableau 在去年版本更新中已經支持了聚類的可視化展現。從豐富的可視化手段來看，不可否認，BI 工具不再局限在表格上的操作，新興產品更多地利用了可視化手段。
當然，BI 工具方面我也是淺嘗輒止，它本身涉及複雜的操作與數據分析思路，需要很多專業背景才能了解和掌握。
演算法領域
再說到演算法領域，在分析領域我們已經看到會引入像聚類的可視化手段。而在更底層的演算法領域其實早就在利用可視化做工作了。我們最熟知的是 R 語言中的 ggpolt 庫功能十分強大，它用來作模型評估在該領域中是必備工具了 。
這裡就提到了可視化在演算法領域的主要工作之一——模型評估。對於一個場景而言，比如定性分析用戶的類別，我們可能會同時跑邏輯回歸或決策樹多個演算法，怎麼知道我們的演算法欠擬合或過擬合呢，當然可以直接看結果。更好的方式就是通過可視化的方式直觀的對比。此外，以下還會提到深度學習中的應用。
另外，演算法過程可視化近年來慢慢流行起來。這個頁面就展示了決策樹的可視化過程 A visual introduction to machine learning。此外，著名的深度學習工具 TensorFlow 官方也推出了一個開源的可視化工具 Playground，用於簡單神經網路演示與實驗。
對演算法過程作可視化對於非專業人員去理解演算法來說很有必要。一方面可以作為演算法在學校或工作中的教學輔助，另一方面可以給非專業人員講解演算法的運算過程。
在演算法與可視化結合作得非常驚艷的不得不再說到 TensorFlow。它提供了 tensorboard 這樣的內置功能作為可視化的工具。
我們很多時候做好神經網路但沒有一個圖像的概念。用了 tensorboard 就可以看到整體神經網路的框架結構，如第一張是 GRAPH 網路結構，第二張圖是整個訓練過程中，各個參數的變換情況：
Web 可視化技術
可視化技術是有理論基礎的，由 Leland Wilkinson 在 1999 年出版的 The Grammar of Graphics 就是可視化圖形構建的理論基礎之一。由 Stanford Interactive Data Lab 推出的 vega 和螞蟻金服推出的 g2 都是由這套理念衍生而出的在 web 端的圖形語言。
還有很多複雜的圖形或個性化的圖表，我們需要自己去實現呢。那就需要 d3 這個庫，它提供了類似於插值器（Interpolators），標尺（Scales）等諸多圖形演算法上的實現，可以很方便地利用它函數式的特性來寫一個圖表。事實上，有很多圖表庫就是基於 d3 來實現的。較為著名的有 nvd3 和 c3。
我們團隊在數據可視化上的實踐也有一些成果，是基於 react 的圖表庫 recharts，它底層基於 SVG，利用了 react 的高可定製性與 VDOM 的優勢，可以方便的構建圖表服務。
數據可視化發展
可視化基礎圖表的發展一直在推陳出新。像 Datawatch 這家公司在 2008 年設計了一種圖表名叫 Horizon Graphs，這個圖表還在 2016 評為重要的可視化發展之一。它可以幫助你在狹小的空間下看到極多的類目基於時間序列的變化。這個圖表在視覺上很特別，非常有創意。對一名數據從業者，如果知道更多更多展現方式一定會事半功倍。
從工程領域來說，數據可視化會向更多基礎的工程領域擴展。在未來，智能化是一個持續的熱點，怎麼理解演算法，怎麼評估模型的有效，怎麼做平台化，都需要可視化參與。另外，像 jupyter 或 zeppelin 提供了直觀從代碼到圖形化展現的功能，這一點非常吸引數據全棧開發者去玩數據。
從技術實現方面，今天的 web 開發者們也不再滿足於傳統的開發方式，會思考用一些專業的 3D 引擎或遊戲引擎去做可視化效果，甚至會利用增強或虛擬設備（AR/VR）。在可視化上的探索是永遠不會局限的，人的想像力有多大就可以做得多不可思議。
數據產品研發
再說到數據產品研發。產品研發一直是前端工程師的主旋律，我們的工作除了基礎架構，穩定性保障，大部分都是在產品研發中。
我們在基礎架構上做了不少的探索，從過去的 Backbone 到今天的 React + Redux。在這個篇章，我想說的並不是怎麼選框架的問題，而是針對不同類型的產品使用不同的開發與思考方式。
從業務形態映射開發模式
一般來說我們構建應用的順序一定是從組件 -> 頁面 -> 應用。從這三個層面都有不同的協作對象的側重。數據產品與業務產品最大的區別在於展現的形式上極其區塊化，區塊內與數據內容的展現強關聯。從這一點也映射出數據前端在開發產品上的一些思考，用一句話說就是組件，頁面與應用切分開。
在組件層面我們與視覺交互會非常緊密，近而團隊一般會有帶有產品風格的組件庫。我們在這個層面考慮的問題往往是如何與 UED 形成一套高效的溝通機制。在數據產品這個層面，團隊與團隊之間一定會從理解上的一致到共同沉澱認可一致的規範。
到頁面層面，我們會關注兩點：
第一，業務模塊間的邏輯。這時候會定義一種輸入輸出固定的通信協議，形如使用 React Component 的方式調用。保證了頁面上模塊的載入的通信性，此外，用同樣協議的模塊是無關框架的。
第二，整體數據流。這時候與後端工程師的交流會多起來。大部分數據產品極少會出現在客戶端抽象的實體，大部分都是指標類的約定。因此，我們在設計上極難利用像 GraphQL 這樣的設計。而是轉為約定一些固有的返回形式，重轉換的過程，如格式化數據。
到應用層面，我們會關注產品本身的設計。比如導航，涉及到路由的配置。
當然，這三者是有一些交匯，只是當團隊做得較好時，會有比較清晰的流程式控制制。對於任何前端開發的 web 產品而言都不會逃離這個步驟，那麼我們如果不僅僅停留在開發階段，想通過工具化的方式來提升這三者的效率，會怎麼做呢。
自然地，我們會想到一種思路構建平台，把固有邏輯抽象出來成為一種標準化描述語言，然後通過引擎進行渲染，非常像可視化編輯器的邏輯。但事實上我們團隊並沒有走這條路，因為當業務中加入很多個性化的元素之後，引擎的維護難度也是相當的工作量。這裡也留下一個伏筆，以後來講講在這裡我們的具體思考。
總之，在產品研發上，總體思路都很相似，輕數據流的抽象界面，重數據流的抽象數據。但世界上哪有這麼方便歸類的而用同一種思路的，用一句經典的台詞，看起來代數問題，卻是幾何問題。
數據精細化運營
產品上線對於研發而言，就已經結束了，除了後續的問題反饋修復 bug。但我還是提下數據精細化運營。
我幾乎每天在看產品的數據報表，換個角色研究產品的增長。今天在阿里對於涉及到做營銷的角色都會希望有數據支持，比如內容IP，需要看它發表的文章或視頻的效果，用戶停留的時間多少，他們的粉絲喜歡讀哪一類的文章。那我會去看我們產品的功能是否得到滿足，哪些功能 MAU 很低。希望從用戶的角度去思考怎麼幫助他們更好的活著。
工程師具備一定的數據化運營的能力，可以思考產品的功能與研發做連接，問一下作為前端工程師能做什麼事。此外，自己在做一些技術推廣的時候，也會有一樣的思路，我寫的文章為什麼沒有人看，是太簡單，太難了？我做的專欄定位是所有前端，還是資深前端？很多問題，你就可以用數據採集的思路去構建更精細的指標。
前端與人工智慧
最後，講講前端在 AI (人工智慧) 時代的位置。目前，前端涉及到 AI 的主要是演算法數據可視化，這一點在上述也講到了。
很有意思的是，去年我們在做一款前端監控平台也涉及到了機器學習。我們都知道常規異常報警思路是一旦發生錯誤就發生通過。傳統異常檢測是機器學習演算法的一個常見應用，利用多維度的值的分布符合某個參數的正態分布來判斷。
但前端錯誤本身，我們無法判斷是否會造成影響，有時只是一個報錯而已，需要前端工程師自己去排查，這一點與傳統異常檢測的思路就不一樣。我們就利用出現的規模，時長，影響人數等因素利用統計學中的3σ原則，當然，進一步我們利用特徵工程的方法實時來檢測錯誤的影響程度。
除了在穩定性方面，只要是生產力工具都可以去思考是否讓 AI 改變我們的開發現狀。這個地方留給所有的工程師思考。
總結
不論講到採集還是可視化，還是做數據產品，我都想講兩點：
第一，數據的完整鏈路。沒有『好』的數據，沒有看到其中的意義，沒有這條鏈路中清洗計算部分，都是沒有意義的，像離線計算，實時流計算都是背後非常關鍵的技術。這也告述前端工程師專註在一個領域，不等於只看到冰山一角。
第二，不同的思考方式。就說可視化與機器學習這一對。從某種意義上來說思路完全相反，可視化需要人類從感知數據到認知數據，而機器學習是通過大量樣本學習得到結論。現在的科技由機器學習的技術還無法做到的事，都還會通過類似於可視化的方式傳遞給人類。如果某一天機器也可以做到能理解世界，那麼真正的人工智慧就來到了。
因此，人工智慧今天還是技術，也是思路，我們可以用在任何環節，不論是哪個崗位的工程師都應該掌握。在過去，前端的工作只與界面相關，而今天前端在一定程度上已經具備了全棧開發的能力，前端工具化平台化已經很常見，可以利用機器學習完善工具。
還有另一種說法，人工智慧的起點是人機交互的革命。要讓機器變得更智能，我們會用更多增強體驗的方式去改變今天的人機交互。因此，前端技術是有很大延展空間的。今天立足在 Web 領域我們是有優勢的，那麼在其它領域呢，我們今天的技能是否做到了編程語言與平台不受限。由此也看到前端工程師在大數據時代涉及的一些工作非常需要有綜合能力。前端工程師的基礎能力從過去縱深到現在更趨向於 T 字型發展。我相信這是未來工程師們的基本形態。
後記
這是我上周做的 GitChat 的一個專題。GitChat 平台非常棒，謝工老師在行業從業多年，給我們帶來一種新的分享方式。希望大家可以去看看。
補充閱讀
陳為等《數據可視化》
Leland Wilkinson《Grammar of Graphics》
@Benjamin Ba 推薦了兩本可視化的教材
《Inteructictive Data Visualization foundations, techniques, and applications》
《The Visual Display of Quantitative Information》
推薦閱讀：
※精選 20 個優質的載入動畫
※看啥雙拱門，來學 webpack 3啊
※極樂技術周報(第十二期)
※在移動端使用transform: translate代替top left marg等做位移有好處么 ？