這個工具太好用了!徹底擺脫了資料IT“天天取數”的噩夢
曾經在知乎上看到一則帖子,是關於“職場工具人“的討論,網友對工具人的定義如下:
再一看評論區,果然是一片哀嚎:
幹開發的吐槽自己的就是一個程式碼輸出機器,天天接需求、改bug。
運維覺得自己就是專業修理工、哪出問題都得隨叫隨到,空有一身本領,業務眼裡也只是個修電腦的。
測試天天就是找bug、找bug,時不時還要跟開發吵兩架。。。。。。
再反思一下我們資料部門的工作,好像也沒能逃脫“工具人“的宿命,每天睜眼就是業務方五花八門的取數和報表需求,累死累活功勞還總被業務搶走,就跟打遊戲一樣 ,IT打“輔助”,業務拿“人頭”。
最讓我覺得自己是工具人的工作就是“取數“,基本上是所有資料IT的噩夢。在行業認知裡,取數一項非常基礎的工作,一個新人1年的成長基本上就可以自如應對各種取數工作,但是這項低技術含量的工作偏偏要耗費IT很多的時間和精力,一些公司都開設了取數崗來專門滿足業務的取數需求,不過這個崗位在公司的地位可想而知,更尷尬的是,在很多厲害的網際網路公司,一些技術牛逼的業務都會自己寫sql資料了,更加看不起取數的IT。
那我們幹資料的IT怎麼才能擺脫取數的噩夢,來個翻身農奴把歌唱?
我們迴歸到“取數“這件事本身,剛才上面說了從技術的角度講,取數並不難,無非就是寫兩句sql嘛。而真正的阻礙是 企業隨著業務發展帶來的複雜和冗餘的取數需求和 IT與業務之間巨大的需求溝通成本。
曾經在一家金融公司資訊部工作過一段時間,深刻體會到取數這個活有多麼不容易,大多時候業務的一張報表會涉及到多個取數需求,看起來沒增加幾張報表,但實際上背後隱含了N個取數過程。而且對於集團企業來說,不僅總部的運營部、銷售部和市場部等各個業務部門的報表需求都壓在資訊部身上,而且有可能分公司的需求經由總部對應部門也彙總到資訊部身上,這就導致了資訊部每天都要應對成千上萬的取數需求。需求多了,響應速度慢,耽誤了業務分析決策,業務還會毫不留情地投訴我們。
然而這還不是最難的,更令人心碎的是和業務往往復復的需求溝通。每接一個需求,都要找業務反覆溝通核對,而且快速發展的業務讓需求總是不停變化,IT不是在和業務部門溝通需求,就是在溝通需求的路上,給業務/IT雙方來都帶去了很多工作量,耗時又費力。
為了跨越IT業務之間的“取數“鴻溝,一些企業探索出了新的辦法,那就是讓業務實現 自助取數,把取數這件事從IT身上轉移到業務身上,讓業務和想要的資料之間沒有IT這個“中間商”,這樣一來,“取數”這件事就從原來的“業務點餐“變成了“業務自助”,既縮短了取數流程又節約了溝通成本。
看到這裡,業務朋友們肯定要開噴了 :讓我們業務去學sql取數?要你們IT幹什麼吃的。
當然,讓業務去學sql取數必然是不現實的,而且資料全部下放給業務,IT更加會擔心資料安全和混亂問題。為了實現業務自助取數,解決這個問題的辦法就是搭建一個 自助取數平臺,透過IT集中資料管控來進行資料分發,業務透過平臺自助完成取數工作,這樣IT就省下了很大一部分的取數工作,業務不用等需求排期,很快拿到想要的資料。
不過,說起來容易做起來難,建設這類取數平臺,除了要體驗好,還要效能要高,在整個的開發過程中,如何設計好配置方式、如何做好業務和資料的對映、如何進行資料表之間的關聯、如何實現資料許可權管理等等一系列的問題都需要解決,還有一個前提是公司有足夠的技術人力支撐。所以對絕大部分的企業來說,量身打造這樣一個自助取數的平臺是非常困難的。
不過市場上現在已經出現了很多產品化的自助取數工具(單純取數)和自助BI工具(自助取數+分析)可以幫助企業解決這個難題。目前應用的比較多的是自助BI工具,業務能夠實現自助取數和分析,直接為業務決策提供依據,這就有點像我前面說的“自助餐“概念了,原先是IT提供食材,業務分析加工得出結論(菜餚),現在是業務自行準備食材、加工、做成菜餚,即解放IT,也讓業務真正成為資料的主人,企業層面上也提高了資料應用決策的效率。
以市面上比較知名的BI平臺FineBI為例,簡單介紹BI工具是如何解決取數這個問題的。
我們在平臺建設之前,搭建了資料倉儲,把業務系統產生的資料經過ETL載入到資料倉儲,然後在資料倉儲中設計好資料主題,配置好維度表和事實表資料集,將資料匯入到FineBI中,配置好表間關聯關係,供業務自助查詢分析,把一些日常固定報表也固化到平臺上供業務查詢,我們IT只需要負責底層的資料梳理,和自助分析平臺的資料許可權的維護,比原來的工作量直接少了一半。
當然,要真正實現自助分析光靠工具肯定也不行,IT把平臺搭好了,業務要能用得起來才行,所以自助BI工具的使用門檻要低,要讓業務輕鬆就能取到資料,快速實現分析。
比如像FineBI的自助集資料處理功能,IT 和業務都可以建立自助資料集,抽取想要的資料,在資料集中進行資料加工,而且這些加工只需要滑鼠點選就能完成,不需要寫一行行的sql語句。
資料處理之後,業務透過拖拽就能實現快速自助分析,支撐業務決策,並且 報表設計過程及分析過程,全程視覺化。
在這樣的自助分析模式下,我們IT省下了時間去集中精力梳理底層資料,企業的資料質量也越來越好,業務分析需求也能夠得到及時響應。,除此之外我們也有了時間去創新突破數字化轉型道路上更多技術點,比如資料探勘智慧式BI等,領導也更加認可IT在企業中的價值。這樣一來,我們資料IT人就逐漸從被業務壓制的輔助角色,轉向了推送企業資訊化建設的先鋒軍!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/21472864/viewspace-2885096/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- VueUse中的這5個函式,也太好用了吧Vue函式
- 如何擺脫工具類
- 這50款前端熱門工具簡直不要太好用了!(1)前端
- 這50款前端熱門工具簡直不要太好用了!(2)前端
- 這50款前端熱門工具簡直不要太好用了!(3)前端
- 這幾個功能也太好用了 | 平時工作學習愛用的私藏小工具
- 三消之王King的新遊戲徹底脫離了三消遊戲
- PostCSS真的太好用了!CSS
- AMD收購無線晶片開發商Nitero,讓VR頭顯徹底擺脫束縛晶片VR
- 這次徹底理解了Object這個屬性Object
- 這麼講執行緒池,徹底明白了!執行緒
- 資料視覺化│用了這個軟體我終於不禿頭了視覺化
- 零經驗噩夢般的面試面試
- 程式設計師的最大噩夢程式設計師
- 不就是分散式事務,這下徹底清楚了?分散式
- 徹底理解SpringIOC、DI-這篇文章就夠了Spring
- 首個徹底保證快取與資料庫一致性的開源方案快取資料庫
- 就因為這三個知識點,我徹底學廢了”正規表示式“
- 迷茫的軟體測試員,如何擺脫工具人身份?
- 使用了一下perl的XML::Smart模組,真是太好用了XML
- 徹底理解Netty,這一篇文章就夠了Netty
- 遊戲設計師的5大噩夢遊戲設計師
- 結對程式設計,我的噩夢程式設計
- oracle徹底刪除資料檔案Oracle
- 如何徹底擦除資料 防止資料被恢復?
- 圖解|這次,徹底理解MySQL的索引圖解MySql索引
- 看了這篇,我確定你已經徹底搞懂Java的繼承了Java繼承
- 世界盃所使用的應用程式帶來資料安全和隱私噩夢
- 程式設計師擺脫疲勞的 11 個建議程式設計師
- 沃爾瑪發力電商 亞馬遜噩夢來了 三大原因亞馬遜
- 如何徹底的解除安裝sql server資料庫SQLServer資料庫
- 不做第二個“陳老師” 教你徹底刪除硬碟資料硬碟
- SAP 徹底刪除物料主資料操作
- 實踐這一次,徹底搞懂瀏覽器快取機制瀏覽器快取
- 徹底弄懂瀏覽器快取策略瀏覽器快取
- 一文徹底搞懂Raft演算法,看這篇就夠了!!!Raft演算法
- 一文徹底搞懂ZAB演算法,看這篇就夠了!!!演算法
- 這一次,徹底掌握go modGo