今天主要回顧壹下近兩年大數據行業公司大數據前端發展情況。最近剛換工作，我把我的經驗分享給大家。有什麽建議，歡迎在評論區熱情留言。謝謝妳。
今天的主題主要是從大數據發展的角度，到大數據治理的必要性，到圖形化建模的想象，最後到數據質量的控制，再到大數據可視化的應用。博主總結自己兩年的經驗，不知道對我研究結果的理解有沒有偏差。希望大家給點建議。
大數據開發
大數據開發有幾個階段:
1.數據采集原始數據
2.數據聚合清理合並後的可用數據。
3.對分類提取的專題數據進行數據轉換和映射。
4.數據應用提供api智能系統應用系統等。
數據采集
收集數據有兩種方式:線上和線下。壹般在線數據都是通過爬蟲、爬蟲或者現有的應用系統收集的。現階段可以做壹個大數據采集平臺，依靠自動爬蟲(用python或nodejs做爬蟲軟件)、ETL工具，或者自定義的抽取轉換引擎，從文件、數據庫、網頁中抓取數據。如果這壹步是通過自動化系統完成的，會非常方便。並且可以更方便地管理目標數據源。
數據收集的難點在於多個數據源，如mysql、postgresql、sqlserver、mongodb、sqllite等。還有本地文件，excel統計文檔，甚至doc文件。如何有規律、有計劃地把它們組織到我們的大數據流程中，也是不可或缺的壹部分。
數據聚合
數據聚合是大數據流程中最關鍵的壹步。妳可以在這裏添加數據標準化，妳也可以在這裏做數據清理和數據合並，妳也可以在這壹步對數據進行歸檔，通過壹個可監控的流程對確認的可用數據進行整理和分類。這裏產生的所有數據都是整個公司的數據資產，當它達到壹定數量時，就是固定資產。
數據聚合的難點在於如何標準化數據，比如表名標準化、表標簽分類、表用途、數據量、是否有數據增量等。數據是否可用？在業務上需要下很大功夫，必要的話還要引入智能處理，比如根據內容訓練結果自動標註，自動分配推薦表名和表字段名。以及如何從原始數據導入數據。
數據轉換和映射
如何將數據聚合後的數據資產提供給特定用戶？這壹步，主要是考慮如何應用數據，如何將兩者結合起來。三個？數據表被轉換成可以提供服務的數據。然後定期更新增量。
經過前面的步驟，這壹步就沒有太多的困難了。如何轉換數據和如何清理數據和標準數據是壹樣的，將兩個字段的值轉換成壹個字段，或者根據多個可用的表統計壹個圖表數據，等等。
數據應用
有許多方法可以應用數據，包括外部的和內部的。如果妳前期有大量的數據資產，通過restful API提供給用戶會怎麽樣？還是提供流媒體引擎KAFKA供應用消費？還是直接合成專題數據供自己的應用查詢？這裏對數據資產的要求比較高，所以前期工作已經做得很好，這裏的自由度很高。
總結:大數據發展的困難
大數據發展的難點主要是監控。如何規劃開發人員的工作？開發者隨便收集了壹堆垃圾數據，直接連上數據庫。短期來看，這些問題都比較小，可以糾正。但是當資產量越來越大的時候，它就是壹個定時炸彈，隨時會引爆，進而引發對數據資產的壹系列影響。比如數據混亂導致數據資產價值降低，客戶信任度降低。
如何監控開發者的開發過程？
答案只能是自動化平臺。只有自動化平臺才能讓開發者感到舒適，接受新的交易，拋棄手工時代。
這是大數據行業前端開發工程師的優勢。如何做壹個交互性好的視覺界面？如何把現有的工作流程和工作需求變成可視化的操作界面？能否用智能代替壹些無腦操作？
從某種意義上說，在大數據開發中，我個人認為前端開發工程師占據了更重要的位置，僅次於大數據開發工程師。至於後臺開發，系統開發第三。良好的互動很重要。數據怎麽轉換，數據怎麽提取，壹定程度上有老祖宗踩過的坑，比如水壺，卡夫卡，管道，解決方案很多。關鍵是怎麽互動。怎麽把它變成可視化界面？這是壹個重要的課題。
現有的朋友側重點不同，認為前端作用可有可無。我認為這是錯誤的。後臺真的很重要，但是後臺有很多解決方案。前端的實際位置更重要，但基本沒有開源的解決方案。如果對前端開發不夠重視，面臨的問題就是交互差，界面差，體驗差，導致開發者的排斥。但是可視化的知識點比較多，對開發人員的素質要求比較高。
大數據治理
大數據治理應該貫穿於整個大數據發展過程，它起著重要的作用。以下是幾點:
數據血緣
數據質量審查
全平臺監控
數據血緣
從數據血緣的角度來看，數據血緣應該是大數據治理的入口。通過壹個表，我們可以清楚地看到它的來龍去脈，字段的拆分，清洗過程，表的循環，數據量的變化，都應該從數據血緣開始。我個人認為大數據治理的整個目標就是這個數據血緣，從中可以監控全局。
數據血緣是基於大數據開發過程，圍繞著整個大數據開發過程。應該相應地記錄每個開發步驟的歷史和數據導入的歷史。當數據資產有壹定規模時，數據血緣是必不可少的。
數據質量審查
在數據開發中，每個模型(表)創建後，都要有壹個數據質量審核的過程。在大型系統環境中，還應該在關鍵步驟中添加批準，如涉及客戶數據提供的數據轉換和映射。應該建立完善的數據質量審核體系，幫助企業第壹時間發現數據問題，當數據出現問題時，也能第壹時間看到問題，從根源上解決問題。
全平臺監控
監控其實包括很多點，比如應用監控、數據監控、預警系統、工單系統等。我們需要實時監控我們接管的每壹個數據源和數據表。如遇停電或斷電，我們可以第壹時間電話或短信通知具體負責人。這裏可以借鑒壹些自動化運維平臺的經驗。監控大約等於運維，好的監控提供的數據資產保護也很重要。
大數據可視化
大數據可視化不僅僅是圖表的展示，大數據可視化不僅僅是圖表的展示，大數據可視化不僅僅是圖表的展示，重要的事情說三遍，大數據可視化分類的數據開發有的屬於應用類，有的屬於開發類。
在開發中，大數據可視化起到可視化運營的作用。如何通過可視化模式建立模型？如何通過拖拽或者三維操作來實現數據質量的可操作性？畫兩張表加幾個按鈕實現復雜的操作流程是不現實的。
在可視化的應用中，轉換數據和顯示數據的方式更多，圖表就是其中的壹部分。通常更多的工作還是數據的分析，如何更直觀的表達數據？這需要對數據和業務有深刻的理解，才能做出合適的可視化應用。
智能可視化平臺
可視化可以再可視化，比如超集，通過操作sql實現圖表。有些產品甚至可以根據數據的內容智能分類，推薦圖表類型，實時開發可視化。該功能是可視化現有的發展方向。我們需要大量的可視化內容為公司產生輸出，比如服裝行業，銷售部門:進出貨的影響，配色對用戶的影響，季節對選擇的影響。生產部:面料價格走勢？生產力和效率的統計？以此類推，每個部門都可以有壹個大數據屏，都可以通過平臺隨意規劃自己的大屏，每個人都可以每天關註自己的領域動態，這就是大數據可視化應用的具體意義。
寫在最後
寫了很多，總結了這兩年的所見所聞所學。有的童鞋會問，難道不是科技嗎？為什麽沒有代碼？博主要說代碼博客主要是學習和寫作，和工作無關。代碼是我的個人技能，是實現個人思想的重要技能。但是，代碼和業務關系不大。在工作中，懂業務的人可以寫出更好的代碼，因為他們知道公司想要什麽。如果妳的業務很差，沒關系，只要妳的代碼好，按照別人的指令工作也很好。技術和商業是相輔相成的，後面博主會總結代碼的改進。
寫完之後很焦慮，代碼不夠規範。目前技術棧js，java，nodejs，python。
主業Js熟練度80%。我在研究阮壹峰的es6(看起來差不多)和vuejs的源代碼(有點擱淺)。vuejs中等，css和布局可以說還行，d3.js和go.js都在用，可以工作。Nodejs，express，koa都沒問題。看過壹些express的源碼，寫過兩個中間件。
Java和python是能做項目的水平。目前我們不想在他們身上花太多精力，只想讓他們保持在有用的水平。
未來幾年，努力工作，多學習人工智能和大數據發展。未來應該會有些熱度。
最後鼓勵壹下，希望大家給點規劃建議。在三人行中，我們必須互相學習。