大資料開發工程師的兩年工作經驗總結

今年廣州的六月，在經歷了大雨的洗禮之後，一切都變得更加明朗起來，新的工作，新的人和事。懶惰讓我變得更焦慮，焦慮促使我進步，程式設計師的焦慮大家應該都有共同的感覺，時代的步伐太快了，在這個環境下的軟體開發一定會淘汰掉那些不懂得學習，懶惰的人。

希望跟大家共勉。

今天呢，博主主要回顧這兩年來，在大資料行業公司從事大資料類的前端開發的工作。最近剛剛換了一份工作，把我的經驗稍作總結分享給大家，有什麼建議大家在評論區踴躍。 謝謝。

今天的主題，主要是從大資料開發的角度，到大資料治理的必要性，再到圖形化建模的暢想，最後在資料質量的把關，然後到大資料視覺化的應用，博主總結兩年的見聞，和我學習的成果，也不知理解有無偏差吧，希望大家能給出建議。

大資料開發

大資料開發，有幾個階段：

1.資料採集【原始資料】

2.資料匯聚【經過清洗合併的可用資料】

3.資料轉換和對映【經過分類，提取的專項主題資料】

4.資料應用 【提供api 智慧系統  應用系統等】

資料採集

資料採集有線上和線下兩種方式，線上一般透過爬蟲、透過抓取，或者透過已有應用系統的採集，在這個階段，我們可以做一個大資料採集平臺，依託自動爬蟲（使用python或者nodejs製作爬蟲軟體），ETL工具、或者自定義的抽取轉換引擎，從檔案中、資料庫中、網頁中專項爬取資料，如果這一步透過自動化系統來做的話，可以很方便的管理所有的原始資料，並且從資料的開始對資料進行標籤採集，可以規範開發人員的工作。並且目標資料來源可以更方便的管理。

資料採集的難點在於多資料來源，例如mysql、postgresql、sqlserver 、 mongodb 、sqllite。還有本地檔案、excel統計文件、甚至是doc檔案。如何將他們規整的、有方案的整理進我們的大資料流程中也是必不可缺的一環。

資料匯聚

資料的匯聚是大資料流程最關鍵的一步，你可以在這裡加上資料標準化，你也可以在這裡做資料清洗，資料合併，還可以在這一步將資料存檔，將確認可用的資料經過可監控的流程進行整理歸類，這裡產出的所有資料就是整個公司的資料資產了，到了一定的量就是一筆固定資產。

資料匯聚的難點在於如何標準化資料，例如表名標準化，表的標籤分類，表的用途，資料的量，是否有資料增量？，資料是否可用？ 需要在業務上下很大的功夫，必要時還要引入智慧化處理，例如根據內容訓練結果自動打標籤，自動分配推薦表名、表欄位名等。還有如何從原始資料中匯入資料等。

資料轉換和對映

經過資料匯聚的資料資產如何提供給具體的使用方使用？在這一步，主要就是考慮資料如何應用，如何將兩個？三個？資料錶轉換成一張能夠提供服務的資料。然後定期更新增量。

經過前面的那幾步，在這一步難點並不太多了，如何轉換資料與如何清洗資料、標準資料無二，將兩個欄位的值轉換成一個欄位，或者根據多個可用表統計出一張圖表資料等等。

資料應用

資料的應用方式很多，有對外的、有對內的，如果擁有了前期的大量資料資產，透過restful API提供給使用者？或者提供流式引擎 KAFKA 給應用消費? 或者直接組成專題資料，供自己的應用查詢？這裡對資料資產的要求比較高，所以前期的工作做好了，這裡的自由度很高。

總結：大資料開發的難點

大資料開發的難點主要是監控，怎麼樣規劃開發人員的工作？開發人員隨隨便便採集了一堆垃圾資料，並且直連資料庫。 短期來看，這些問題比較小，可以矯正。 但是在資產的量不斷增加的時候，這就是一顆dingshzhadan，隨時會引爆，然後引發一系列對資料資產的影響，例如資料混亂帶來的就是資料資產的價值下降，客戶信任度變低。

如何監控開發人員的開發流程？

答案只能是自動化平臺，只有自動化平臺能夠做到讓開發人員感到舒心的同時，接受新的事務，拋棄手動時代。

這就是前端開發工程師在大資料行業中所佔有的優勢點，如何製作互動良好的視覺化操作介面？如何將現有的工作流程、工作需求變成一個個的視覺化操作介面？ 可不可以使用智慧化取代一些無腦的操作？

從一定意義上來說，大資料開發中，我個人認為前端開發工程師佔據著更重要的位置，僅次於大資料開發工程師。至於後臺開發，系統開發是第三位的。好的互動至關重要，如何轉換資料，如何抽取資料，一定程度上，都是有先人踩過的坑，例如kettle，再例如kafka，pipeline ，解決方案眾多。關鍵是如何互動？ 怎麼樣變現為視覺化介面？ 這是一個重要的課題。

現有的各位朋友的側重點不同，認為前端的角色都是可有可無，我覺得是錯誤的，後臺的確很重要，但是後臺的解決方案多。 前端實際的地位更重要，但是基本無開源的解決方案，如果不夠重視前端開發， 面臨的問題就是互動很爛，介面爛，體驗差，導致開發人員的排斥，而視覺化這塊的知識點眾多，對開發人員的素質要求更高。

大資料治理

大資料治理應該貫穿整個大資料開發流程，它有扮演著重要的角色，淺略的介紹幾點：

資料血緣

資料質量審查

全平臺監控

資料血緣

從資料血緣說起，資料血緣應該是大資料治理的入口，透過一張表，能夠清晰看見它的來龍去脈，欄位的拆分，清洗過程，表的流轉，資料的量的變化，都應該從資料血緣出發，我個人認為，大資料治理整個的目標就是這個資料血緣，從資料血緣能夠有監控全域性的能力。

資料血緣是依託於大資料開發過程的，它包圍著整個大資料開發過程，每一步開發的歷史，資料匯入的歷史，都應該有相應的記錄，資料血緣在資料資產有一定規模時，基本必不可少。

資料質量審查

資料開發中，每一個模型（表）建立的結束，都應該有一個資料質量審查的過程，在體系大的環境中，還應該在關鍵步驟新增審批，例如在資料轉換和對映這一步，涉及到客戶的資料提供，應該建立一個完善的資料質量審查制度，幫助企業第一時間發現資料存在的問題，在資料發生問題時也能第一時間看到問題的所在，並從根源解決問題，而不是盲目的透過連線資料庫一遍一遍的查詢sql。

全平臺監控

監控呢，其實包含了很多的點，例如應用監控，資料監控，預警系統，工單系統等，對我們接管的每個資料來源、資料表都需要做到實時監控，一旦發生殆機，或者發生停電，能夠第一時間電話或者簡訊通知到具體負責人，這裡可以借鑑一些自動化運維平臺的經驗的，監控約等於運維，好的監控提供的資料資產的保護也是很重要的。

大資料視覺化

大資料視覺化不僅僅是圖表的展現，大資料視覺化不僅僅是圖表的展現，大資料視覺化不僅僅是圖表的展現，重要的事說三遍，大資料視覺化歸類的資料開發中，有一部分屬於應用類，有一部分屬於開發類。

在開發中，大資料視覺化扮演的是視覺化操作的角色， 如何透過視覺化的模式建立模型？ 如何透過拖拉拽，或者立體操作來實現資料質量的可操作性？ 畫兩個表格加幾個按鈕實現複雜的操作流程是不現實的。

在視覺化應用中，更多的也有如何轉換資料，如何展示資料，圖表是其中的一部分，平時更多的工作還是對資料的分析，怎麼樣更直觀的表達資料？這需要對資料有深刻的理解，對業務有深刻的理解，才能做出合適的視覺化應用。

智慧的視覺化平臺

視覺化是可以被再視覺化的，例如superset，透過操作sql實現圖表，有一些產品甚至能做到根據資料的內容智慧分類，推薦圖表型別，實時的進行視覺化開發，這樣的功能才是視覺化現有的發展方向，我們需要大量的視覺化內容來對公司發生產出，例如服裝行業，銷售部門：進貨出貨，顏色搭配對使用者的影響，季節對選擇的影響   生產部門：布料價格走勢？  產能和效率的資料統計？  等等，每一個部門都可以有一個資料大屏，可以透過平臺任意規劃自己的大屏，所有人每天能夠關注到自己的領域動向，這才是大資料視覺化應用的具體意義。

寫在最後

洋洋灑灑寫了很多，對我近兩年的所見所聞所學所想進行了一些總結，有些童鞋會問，不是技術麼？為什麼沒有程式碼？   博主要說，程式碼博主要學的，要寫的，但是與工作無關，程式碼是我個人的技能，個人傍身，實現個人想法的重要技能。 但是，程式碼與業務的關係不大，在工作中，懂業務的人程式碼寫的更好，因為他知道公司想要什麼。 如果你業務很差，那也沒關係，你程式碼好就行了呀，根據別人的交代幹活，也是很不錯的。技術和業務是相輔相成的，稍後博主總結程式碼的精進。

寫完了，博主的焦慮一絲未少，我的程式碼規範性不夠，目前技術棧js、java、nodejs、python 。

主業js熟練度80%吧，正在研究阮一峰的es6（看的差不多）和vuejs的原始碼（有點擱淺），vuejs算是中等，css和佈局方面可以說還可以，另外d3.js，go.js都是處於會用，能幹活。 nodejs呢，express和koa無問題，看過一些express的原始碼，還寫過兩個中介軟體。

java、python都處於能做專案的程度，目前也不想抽很多精力去深入它們，就想要保持在想用能用的地步吧。

未來的幾年，博主努力工作，多學學人工智慧、大資料開發的知識，未來這塊應該還有一些熱度的吧。

最後，和大家共勉，更希望大家能給一些規劃建議，三人行，必有我師焉。