慎選解決方案 化巨量資料為極致價值
- DIGITIMES企劃
-
現今不管從網路或報章媒體，用戶皆不難看到一缸子能扯得上「巨量資料」的解決方案，有的被歸類在Log資料應用、商業智慧、分析及視覺化等範疇，有的專注發展資料分析、資料管理等基礎架構，也有來自開原碼陣營的Hadoop、MapReduce、HBase、Mahout或Cassandra等技術方案，讓人看得目不暇給，一時之間真不知該如何做出正確抉擇。
只因Big Data實在太過火熱，眼見機不可失，許多來自四面八方的資訊系統供應商，都紛紛齊聚這個饒富潛力的新戰場，從各自擅長的角度，推出不同功能取向的產品，極力爭取成為用戶端巨量資料平台的一環。
雖然選項眾多，看似對用戶十分有利，但不可否認，巨量資料仍算一門極為新穎、又有些抽象的技術，真能將其Landscape搞得一清二楚的企業，其實並不算多，即使能弄懂這整個構圖，對於單一領域所存在的眉眉角角，也未必能通盤瞭解；於是在這個略顯渾沌不明的偌大場域中，滋生了若干陷阱或迷思，亟需加以釐清。
中小企業難入Big Data之門？
第一道迷思，由於巨量資料產品要價偏高、技術偏難，且幾乎所有研討會的訴求對象，聽起來都一面倒傾向中大型企業，合理推測，中小企業似乎不適合導入此項技術，況且也未必有殷切需求(因無TB等級龐大資料需要處理)。
然而，這真的是一番誤解。首先，中小企業也需要做營運管理，也需運用批次處理方式產出報表，而其所面對的市場競爭壓力，也不會比大企業來得小，所以先撇開巨量資料的Volume或Variety不談，光是在於Velocity方面，即可因為善用巨量資料技術而受用無窮，讓原本得耗時數天處理的工作，急縮到半天內完成，何樂而不為？
其次，有些MPP(Massively Parallel Processing)資料庫被包裹成Appliance型式提供，裡頭集結了不少節點，的確逾越中小企業的資料胃納需求，但並非所有產品個個如此，有的甚至可在單一實體或虛擬主機環境中運轉，中小企業可朝著這類型產品做思考；否則，現階段有一些關於巨量資料主題的IaaS雲端服務，例如Amazon Web Services或微軟Windows Azure，也俾使中小企業能以低廉租賃費用，換取可觀運算資源，亦是不錯的選項。
開原碼vs.商用系統，哪個好？
Hadoop挾著擅長於分散平行運算的特質，因而掀起陣陣旋風，但凡事講求穩健的企業，一方面對於Hadoop這類型開放原始碼技術頗感疑慮，二方面也對於Hadoop略顯緩慢的查詢速度不敢恭維，但如果把分散平行運算工交由純商用系統來進行，又得負擔龐大財務支出，沒幾個企業有福消受。
兩難之間如何抉擇？最好的方式，就是把它們混在一起，取Hadoop之於分散平行運算的優點，又因商用系統(例如MPP資料庫)而得以滿足即時查詢需求，實為相得益彰的解決之道。
但是必須切記，有些商用系統，未必能與Hadoop家族的一干徒子徒孫做整合，值此時刻，企業要嘛以Hardcode方式「蠻幹」，但容易導致資料平台的底層架構趨於紊亂，日後恐有後遺症產生，要嘛就是另行購置ETL工具，徒增一筆不算低廉的開銷，都有其不利因素存在；所以最好的方式，就是利用POC嚴加測試，凡是整合出現問題的，就只好予以剔除。
然而如果可接受以Hardcode或ETL等方式進行整合，則後者是相對理想的選項。有人曾說，運用Hadoop即可取代ETL功能，但此話其實只說對了3分之1，因為ETL三個字代表Extract-Transform-Load的縮寫，主要用以描述將資料從來源端，經過萃取、轉換、載入至目的端之過程，Hadoop充其量只具備強大的「Load」功能，對於E或T則並不拿手，所以才這麼容易在異質系統整合過程中碰壁，但ETL則無此顧慮。
既有的BI投資，如何處理？
不少人誤以為，巨量資料解決方案與現存的BI系統，兩者之間一定有互斥關係，有了新的，就得淘汰舊的，但這實在是天大的謬思。
可以這麼形容，一隻翩翩飛舞的彩蝶，一定得靠頭、身體、翅膀同時存在，才會展現生命力，而Hadoop MapReduce、MPP資料庫(或In-Memory資料庫)、OLAP、報表系統、資料探勘、企業績效管理(EPM)等新舊工具之間，全都是構築這個生命力的重要元素，任何環節都有其存在價值，根本無所謂相互取代的關係，而且這些環節之間，都肯定存在資料交換的需求；甚至是只能處理傳統結構式資料的關聯式資料庫，都不該因此而遭捨棄。
主因在於，有些沿用許久的應用軟體，不見得依平行架構進行系統設計，所以某些應用場景，在關聯式資料庫得以運行順暢，到了平行資料庫，反倒步履蹣跚；因此應該針對何等用途採用巨量資料技術，需要審慎考量，避免用一竿子打翻整艘船。
唯一較有取代意味的場景，會出現在低效率的舊式資料倉儲，即將被轉為高效率的新式平行資料庫；不過這是一個頗為浩大的工程，用戶在進行評估測試的過程中，務必需要有嚴格的把關程序，以及正確的測試題目，才能如願享受到轉換效益。
導入巨量資料，方知頻寬資源困窘？
若干企業在部署巨量資料解決方案，才驚覺既有的企業網路資源，根本不敷所需，導致塞車現象時有所聞。
為何如此？可能的原因之一，平行運算架構多為Master-Node模式，好比一個首腦率取一群士兵(即大批運算節點)，如果不做高可用性(HA)部署情況倒還好，一旦施作了HA，所有事情都得等到「兩個首腦」做完同步再說，豈有不拖慢網路效能之理？
可能的原因之二，雖然大家都強調支援資料壓縮，但部分產品要等到把資料處理完，才執行壓縮程序，下回用戶想調出這個處理結果，又重新解開壓縮，假使檔案過大，存取速度自然快不起來。
可能的原因之三，也是最棘手的狀況，有些Big Data Appliance係以一個個整櫃方式輸出，在相同機櫃內的不同節點，彼此交換資料，只需1 Gigabit速率便綽綽有餘，但只要跨櫃做交換，頻寬需求立即爆漲到10 Gigabit、甚至InfiniBand，值此時刻，倘若用戶端原本的核心交換器規格不夠高，可想而知當然會出現網路壅塞現象。
很簡單的道理，底下的不同機櫃或伺服器之間，都已經10 Gigabit來、10 Gigabit去，位居制高點的核心交換器，若還不到10 Gigabit速率，怎能不失控？但對多數用戶而言，只因導入Big Data Appliance，居然得將網路骨幹進行升速，實在茲事體大，早知如此，肯定不會輕易導入，但不幸的是，在部署過程中，不管是原廠或經銷商，怎麼都沒人做出善意提醒？
為了避免這3個可能性發生，用戶在挑選產品的過程中，自然需要睜大眼睛。首先，既然要做HA，就得將此列為POC重要考題，不容廠商和稀泥蒙混過去，畢竟不是所有平行運算架構都走Master-Node路線，就算是，也未必個個都會造成如此大影響；其次，大家都標榜壓縮，有的做足了全套，有的卻只做半套，用戶務必需要看得清楚分明，而真正做到全程壓縮者，吞吐需求自然較小，較不會造成網路壅塞；再者，在導入任何產品的同時，謹記得要再三確認其對於網路拓樸的影響性。
