2012/07/30-闞大成
如果已對Hadoop、MapReduce、HDFS、HBase、Hive…等一干關於巨量資料分散式處理的技術知之甚詳，而且也有實作經驗、並非僅能紙上談兵，那麼如果僅能將此技能發揮在IT底層庶務，未免太過可惜，理應以此根基，好好地做出幾套足以提振企業營運績效的應用，那才可謂物超所值。
說真的，任何企業的執行長或財務長，即使對於公司建立巨量資料分析環境，抱持樂觀其成態度，甚至不吝於核准放行一些IT投資案，主要目的絕不是為了讓IT部門養出一堆Hadoop高手，更不是為了看到程式開發人員談論MapReduce時的神采飛揚，終極目標是在於創新、在於應用，從而帶出成本撙節、生產力提升、新品研發速度加快、業績上揚、客戶基礎變大…等各類型正面效應。
|
|
放大
而在探究各行各業可能繁衍的巨量資料應用情境之前，此處還是先談論一些基本問題，旨在針對若干有關Hadoop的迷思加以釐清，避免企業產生一些誤解，因而對巨量資料的應用前景做出錯誤期待，或者太過低估應用的揮灑空間，畢竟過猶不及，都非屬健康狀態。
Hadoop僅擅長Web分析？ 絕非如此！
比HDFS更早出身的MapReduce，似乎已在若干業者的強力吹捧之下，讓若干用戶產生似是而非的錯覺，其中最讓人啼笑皆非的謬思，便是誤認MapReduce可以做分析，而且有能力取代OLTP或OLAP等資料庫系統。
事實上，有些類似ETL的MapReduce，算是1種通用引擎，可被視為MPP架構的進化版，平行運算的能力頗強，但充其量只能對分析加以控制管理，本身並不做分析，因此企業無需因為有了MapReduce，就天真以為不必再引進任何商業分析工具。
此外，由於Big Data太過於「如雷貫耳」，所以飽受洗禮的用戶，自然將Hadoop視為處理大量資料的載具，這樣的認知雖然不能說不對，但卻不夠全面，甚至忽略掉更大的關鍵，即是Hadoop可以處理多元化資料類型的能力。
因此企業若認為自己的資料倉儲胃納量已經夠大，處理TB等級的資料並無問題，不需要花心力去搞Hadoop，那麼可能是弄錯了方向，因為Hadoop能夠處理的半結構化資料、非結構化資料，似乎都不在資料倉儲的能力範圍之內。儘管如此，Hadoop之於資料倉儲，只是作為補充、絕非取代，所以企業亦無需認為Hadoop是資料倉儲的「替代品」。
再者，因為Hadoop的出身背景與Google、Yahoo! 息息相關，再加上又已建立eBay、VisaNet、Facebook 乃至於百度等指標型應用案例，於是乎，人們就自然而然認為，Hadoop非常擅長處理Web分析，甚至誤以為它只能做這件事。
然而前面提到，Hadoop可以處理相當多元化的資料型態，所以其可能衍生的應用範圍，怎會僅僅侷限於Web分析？舉例來說，經營鐵道的機構，可藉由傳感器來探測軌道車輛，並利用Hadoop環境處理相關數據，再結合BI工具進行分析，如此即可提前察覺異常高溫的現象，及早預防意外事故的發生，試問這件案例從頭到尾的內容，有任何1點指向Web分析？答案是沒有的，既然如此，企業大可不必劃地自限。
最後，不可否認巨量資料分析的重要性，確實呈現與日俱增的趨勢，有鑑於此，有的企業便思考是否為此釋出更多人力資源配額，用以延攬相關領域的高手，而奇貨可居的Hadoop認證專家，便是鎖定的對象之一。
倘若企業的人力資源額度真的很緊，了不起只能延請1位頂級高手，那麼取得Hadoop認證的專業人才，未必值得被列為首選，因為他只擅長於建構分散式運算環境，其價值不在於最終的分析或應用，與其如此，倒不如延聘一些懂得建立分析模型、解讀數據的資料科學家(Data Scientist)，還更具有重大意義。
只不過，Hadoop認證專家為數不多，Data Scientist也同樣有此情況，所以企業或許可以從內部培養人才，因為Data Scientist除了得擅長統計分析外，其實也需要深入瞭解產業Domain Know-how，外部專家不見得符合這項條件。
各行各業，都可望因巨量資料分析而受惠
至於在產業應用部分，能夠列舉的適用情境，可謂多不勝數。以電信業為例，可透過對於網路流量的即時攔截而獲取大量Meta Data，不管其資料格化如何凌亂發散，都通通送進Hadoop生態體系予以處理、分析，如此一來，便可清楚理解網路使用者的行為特性，譬如有多少人習慣造訪臉書、推特、YouTube或谷歌？而在應用市集裡頭，哪些App被下載的頻率最高？種種問題的解答，都將逐一浮出檯面。
以銀行為例，亦可將攸關人口分布、地理位置、金融商品資訊、客戶資訊(甚至包括客戶之間的社群網絡關係)…等各式各樣的大量資料予以蒐集，繼而結合適當的方法、工具、技術、最佳實務(Best Practices)指南，藉此推動複雜分析，終至推演出最適合設置分行的地點，以及最適合在該分行推廣的金融商品，乃至於該分行服務人員最需要培養的技能，通通皆能一目瞭然，使得銀行更能聚焦於Target Market火力全開，促使營運績效大幅提升。
有人難免好奇，此事早在多年前銀行熱衷建置資料倉儲的年代，不就已經發生了？其實不然，因為當時分析的重點，是偏向靜態且已經發生的結構化數據，如今賴以分析的資料來源中，則是摻雜半結構化、非結構化等其他型態的資料，且資訊本身的即時性更強、移動性更大，凡此種種，顯然都不是早先資料倉儲或資料超市所擅長處理的環節。
至於在台灣舉足輕重的晶圓製造業，也早已投入巨量資料的懷抱。主因在於，從現在回過去的10年，半導體製程從90奈米、65奈米、40奈米推進到28奈米，生產技術愈來愈精緻，良率控制的難度也愈來愈高，所以該產業所需處理、分析的資訊，也從過去以批(Lot)、晶圓(Wafer)、晶粒(Die)為單位，一路擴及相關的機台設備。
更有甚者，以往等到1段生產流程結束，再來整理機台設備的資料即可，現在則不然，甚至精細到需要以「秒」為單位，可以想像，其MES所需彙集的資料量，將是何等巨大？如果墨守成規沿襲既有分析架構，豈能應付得了這麼龐大的體量？當然需要建立Hadoop之類的巨量資料處理架構。
刻正大力推動智慧電網、先進讀表等應用的電力事業，當然也是迫切需要分析巨量資料的一大族群。更值得一提的是，電力公司有時難免需要針對某些地區或道路，進行局部性停電，那怕預計停電的時間再短，都可能因為剛好卡在重大商業或公益活動，從而對市民或企業產生莫大衝擊，所以必須通盤考量這些變數，擇定較為適當的停電時機，或是採取必要的因應措施。
於是乎，透過巨量資料的精密演算與分析，電力公司即能做到多害相權取其輕，真正優化停電管理的品質，讓一切損失趨於最小化，從而創造更理想的營收數字。
點我進原文連結
沒有留言:
張貼留言