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

xyz藍月發表於2019-04-22

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

希望跟大家共勉。

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

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

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

大資料開發

大資料開發,有幾個階段:

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都處於能做專案的程度,目前也不想抽很多精力去深入它們,就想要保持在想用能用的地步吧。

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

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


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69903766/viewspace-2642201/,如需轉載,請註明出處,否則將追究法律責任。

相關文章