簡述雲端數據管理

Cloud Data Management
它算是一個蠻新到傳統教育體制是難以跟進的專業,也不能怪大學教授們,因為光是消化吸收一堆新名詞與概念到設計教材、評量標準乃至口頭上課準備齊全後,結果學生都以翹課致敬的心理打擊加上教學評鑑夠令人喪氣了。所以這一方面人才自然是少,少到這些人才是從哪裡冒出來也不得而知,非常神秘。
至於為何雲端數據管理開始被重視?

上一世紀1995年,windows 95年代,網路還得用數據機經過霹哩啪拉尖銳刺耳的聲音才能有理論值56KB的網速比起。和一堆小小軟碟片不太像是我這幼齒會看過的磁碟片,片片卻才1.44MB裝個GBA模擬器加神奇寶貝都不夠,可能當年畢業展的學生繳個畢業專題都得拿個50片以上去交作業吧。
反觀現代,如今年2019一直被炒作是5G元年,5G手機上網理論值就達1G(儘管我不知道要那麼大頻寬幹嘛,且我恨智慧型手機常弄丟不熟)貼近一般家庭點,一般家庭有線電視申裝了,半吹半捧也會裝100MB光纖網路進駐,光是民生就有這樣頻寬,加上手機,可想而知我們每人每天會產生多少數據出來。

那麼工作上就更驚人不意外,在工作場所,或因為雲端的便利害的全世界都是你的工作場所,製造出來任何數據,如下週三某某部門coco飲料訂購統計表.xlsx或今日中午便當口味問卷.docx之類的,公司若不妥善管理,將有如宿便開始累積在那等著幾年後哪位倒霉IT不小心接手崩潰。
妥善管理數據有什麼好處?
只要打開各位的臉書、IG、推特,並把adblock擋廣告外掛關掉,開始搜尋”雲端數據管理”或大數據、Big data反覆操作幾次,答案就會被你的求知慾感動到,自己主動過來找你。
以上描述,雲端數據管理看似就只是把大家產生出來的數位資料做個管理,有啥難的。就換個角度,現在有各式各樣的資料又不同的副檔名、for 不同專案、不同交件日期等諸多條件下,要讓你建構出一個雲端檔案管理系統要從何做起呢?坊間常使用的數據管理是以下兩本:
- Agile Data Warehouse Design by Lawrence Corr (2011)
- The Data Warehouse Toolkit by Ralph Kimball (originally published in 2004 with a 3rd edition update in 2013)
但因為人們不知道腦袋在裝什麼,讓網速發展神速,以上看似年代與我們先將,實質上已經過時了,56KB有56KB的管理方式,256MB有256MB的管理方式,當進展到動輒幾G甚至TB的時候,那管理就真的高深(想到過去某年協助看到某PS4遊戲啥秘境探險還禁忌探險的,主角3D model 就798mb實在讓我不敢點開)
所以勢必又得開始建構新的數據管理系統知識體系。目前最新的託管在Github且每天都有來自全世界各地,不知何方冒出來的強者,不記較無薪酬、無怨悔、真性情的更新之。

人生已經夠難且複雜,所以專業上盡量化繁為簡是大家的共識,故雲端數據管理分為四階段:Source、Lake、Warehouse、Mart
上面帶點小清新感的圖中的每個垂直軸都可以是一個有效的堆棧(Stack),保持著彈性根據資源的規模和公司組織中數據的重要性來進行操作劃分。例如,現在公司有20位員工,每週產生的專案進度資料數據,秘書小姐們就會想破頭白髮飆冒如何有效又彈性的命名歸檔原則,就是所謂源代碼級別工作。
但當公司成長到超過百名員工,且數據如滾雪球般持續越滾越大,甚至直接推進到Mart時,做過上百個專案以上累積的數據,卻剛好其中東拼西湊就能恰巧解決公司某營運或公款淘空案件的關鍵時,數據管理就更顯德重要。
階段1: Source

當開始學習使用數據管理時,可能只有幾個感興趣的來源。早期的兩個常見來源是Google Analytics(分析)和產品所使用的PostgreSQL或MySQL數據庫中的應用程序數據。如果您公司中只有少數幾個人需要使用這些資源,通常是網管之類的,則可以將其設置為具有直接訪問權限;對於他們來說,直接直接處理數據更加簡單和敏捷。
在此早期階段,將受益於使用BI系列產品,該產品可在需要時編寫SQL,因為所產生的資料可能是為事務目的而構造的,並且通常需要某些複雜查詢的指令。
階段2:Lake
(刻意用原文英文就是不挖坑給自己跳,大大的寫“湖‘?)

當開始依賴更多的數據源,並且更頻繁地需要合併數據時,將需要構建一個Data Lake,這是把所有數據以統一格式一起存在的地方。白話一點就是將香蕉蘋果芭樂啥的丟到果汁機榨成果汁一樣道理就是。
偏偏事情又進展到得同時使用Salesforce,HubSpot,Jira和Zendesk一堆聽起來很姦邪的應用程式中的資料數據時,就得先為這些數據創建一個主目錄,以便可以使用單個SQL語法直接一起查詢所有數據,而不是創了N個API。
但如果今天公司有幸產生的數據已經達到大數據級別(每天100GB以上),你就得需要將其存放在S3中了,就是社群網站常跑出來煩你的S3,它的真面目就是Data Lake,號稱性能好,可以一種SQL語法查透透,並為公司下一個階段做好準備。
階段3:Warehouse

在Lake階段,當你不小心拖人下海使用數據庫時,你必須向他們解釋每種模式的奇特之處,哪些數據在哪里以及需要在每個表中進行過濾的特殊條件,和哪些絕對不能看等等。這會變得很折騰人,加上公司裡明爭暗鬥,簡單事情傳出去都變成什麼了,明明只是做數據管理卻經常身陷誠信問題。為了證明自身的清白,就得開始將數據清除到單一的數據資料庫中。
從上古神話中,在創建數據資料庫的事工一直是一場噩夢,你得從一堆聲稱自己是最優的可以最完美建構數據資料庫以便分析的架構選擇一個、你得向新進同仁解釋架構有哪些小小不太完美怪異之處(實質破綻超大)以免隔天秘書又跑過來罵害她又得刊登徵人啟事了。
至於你自己的數據資料分析模型現在應該僅是原始事務模式的簡化,過濾,最小化,描述性命名的純淨版。這理想具有乾淨的操作架構,它將成為公司的真理之源,且會慢慢發展。
但如果你和我一樣有個習慣:真的懶到連創資料夾都直接命名”懶得整理 v 14.0正式版"然後將45GB的資料拖進去就當歸檔結束了,那麼就是另一種發展。
階段4:Marts
當擁有乾淨的數據並搭配良好的BI產品時,你應該開始注意到公司中訂錯便當數量次數或是下午茶手搖杯飲料珍奶訂成西米露的次數略減,這是個好兆頭:代表大家對公司數據資料可以很輕易地調閱並達成共識,業務和生產力也透明化。這樣做數據管理的就不必擔心完整性問題,因為已經對數據進行了思考周詳構建,並且不斷地將其維護為乾淨。接下來只要等老闆覺得好像數據管理的那位都不知道在幹啥,花錢請來有啥用,因而被資遣就好。
但是,常常公司數據資料庫中有上百個表單,並且同仁在查詢時,直接教他們用SQL會引起暴動的,且現在還流行客製化,有些人喜歡粉紅色呈現圖表,有些喜歡黃色馬卡龍裝飾,不同部門不同團隊提出的奇耙要求都得滿足的情況下,就得推出Data Mart

Data Mart是查閱詞更小更具體的真理之源。例如,業務團隊可能只需要Warehouse中12個左右的表單,而康樂團隊可能需要其中20個表單-其中一些是相同的,但有些不同。
創建這些Data Mart的方法與Warehouse相同。使用已可視化的SQL(無論是真實現還是拿假的jpg魚目混珠)來創建新的架構。
我剛剛好像才整理完一小部分新藝術史,晃悠的現在整理完Cloud Data management
崩潰
