姑且不論大資料到底是退燒了，還是已經進入企業落實階段，對大資料感興趣的企業到底該怎麼評估需求、又該從哪裡下手，在眾多大資料技術中做選擇，這些問題讓不少企業卻步，臺灣Hadoop社群發起人王耀聰近日在Big Data Conference 2015大會上，剖析大資料的過去、現在與未來，並揭露企業導入大資料之前與導入過程中，應思考的關鍵流程。
王耀聰同時也是知意圖（Etu）的首席架構師，負責大資料平臺管理軟體的產品開發，他認為，企業要先回歸基本面，針對自己的商業問題，判斷對大資料解決方案，到底是需要還是想要，如果真的有導入需求，則可照他的4階段執行心法，分別就人力面、流程面、技術面以及整個導入藍圖來逐一檢視。
6個導入前必問的問題
他表示，決定導入前，先問自己6個問題，第1個是企業想解決什麼問題，而這個問題是否可用資料來解決。他表示，不同產業採用大資料有不同需求與優先順序，確定是資料可解決的問題後，第2個問題是，所需的資料來自內部還是外部，資料源有哪幾種型態，分別可由什麼管道來取得。
第3個是法規面問題，由於有些企業內部資料牽涉個資問題，有使用上的疑慮跟限制，甚至會限制整個流程的運作方式，因此企業要先確保這些資料的使用合乎法規需求。再來，第4個問題要做資料驗證，確定答案在這些資料中，而資料是否可靠，以及需要多少資料才能找到答案。
王耀聰表示，不是蒐集大量資料就一定能進行大資料分析、找出解答，企業得先做資料驗證，確定要找的商業價值跟答案可以從這些資料中取得，另外也要考慮資料的可靠性與含金度，像是感測器所蒐集到的資料，要評估誤差值是否在可容許範圍內，此外，資料量不夠也無法找出答案。
第5個問題是企業要選擇一個符合自己預期的資料處理平臺，需要定義一個可接受的資料處理時間，最後1個問題則是要衡量系統效益、投資報酬率等績效指標，確定這套系統效益高於建置成本。王耀聰說，要說服老闆導入大資料之前，最好先準備好這6個問題的答案。
人力面思考關鍵：需克服Dev和Ops的文化衝擊
一旦企業確定要導入大資料，可從四個導入階段來逐一檢視，第一階段要做企業內部的人力資源盤點，王耀聰表示，導入大資料需要有一個團隊，而團隊組成涵蓋各領域的人，包括電機、網管、系統管理、資工、資管、統計到決策者都會參與其中，這些人有各自被賦予的角色，需要重新規範好每個人的權責分工。
他以自身經驗為例，由於Hadoop從Ops角度出發，最初設計目的是為了讓維運更容易，會考慮HA架構及安全性問題，因此，系統管理者較能接受Hadoop的思維，而Spark則是從Dev角度出發，以開發者需求為主。由於兩套系統本身的出發點和設計想法有很大的落差，因此，會面臨到Dev和Ops的文化衝擊，一邊是負責系統維運的IT人員，另一邊是開發者、分析師，兩邊有各自的立場和被賦予的規範。他說，除了不斷溝通之外，比較好的方式是建立企業的協作文化，善用協作平臺，維持資訊可以通透。
流程面思考關鍵：網路架構易成盲點
第二階段是流程架構，要設計一個從資料產生到傳遞的資料流，他將處理大資料的常見流程以十個字呈現，生（資料源）、流（通訊協定）、蒐（前處理）、存（儲存方式）、取（存取方式）、算（資料處理）、析（資料分析）、用（視覺化）、看（解讀）、變（行動）。不過他也說，這個流程是用於批次分析的大資料流程參考，未考慮到即時串流的狀況。
他進一步解釋整個資料流的流程設計，從資料源開始，不同資料源使用的通訊協定不一樣，有些是現存的Log文字檔，有些是外部Log，需要靠FTP傳進來，依據資料源以及用什麼方法傳進來，來決定蒐集方法。資料蒐集後會儲存起來，需決定使用何種檔案格式或介面把資料取出，在運算平臺上做資料處理，再放到結構化平臺上當資料倉儲，做資料分析，最後用視覺化工具呈現數據，由分析師再將數據解讀給決策者。他特別提醒，設計流程時要驗證每個項目的負責人與利害關係人，並找架構師來協助確認每個流程之間的技術可行性。
他說，有時候看起來簡單的流程，實際執行時還是會卡在某一個環節，像是網路架構就是一個常被忽略的盲點，因此，要注意哪些資料在外網，哪些在內網。他舉例，若因資安考量把Hadoop放在內網，但是資料從外部來，這時候就要建置DMZ來串接內外網。此外，資料是否落地也會影響到整個處理流程的速度。
技術面思考關鍵：軟體堆疊無絕對好壞
第三階段是技術面盤點，他建議企業用「人＋流程－風險」的公式，來選擇技術，以及合適的軟體堆疊（Software Stack）。他說，企業選用的軟體堆疊也會基於過去員工所具備與學習的技術能力，因此這些軟體堆疊的組成往往跟組織成員的學習歷程與商業目標有關，並沒有絕對好壞。
王耀聰也提到，近幾年導入大資料的常見原因是要做異質資料整合，常以資料倉儲（DW）為切入點，目的是用Hive、Impala技術來做資料處理。
導入藍圖思考關鍵：先求可行、安全、再求更好
最後一個階段是檢視整個導入藍圖，並關注資訊安全跟資料品質這兩大風險。他建議企業不要好高騖遠，想一次到位，要先求可行，二求安全，再求更好。他說，許多企業想用Hadoop Big Data Stack取代現有的資料倉儲，但是Hadoop今年才10歲，相較於38歲的Oracle RDBMS，Hadoop就像一個具備新技能的童工，企業應思考當初選擇Hadoop的原因為何。他認為，不論是童工還是老員工有各自的地位，彼此會互補，而非取代。
王耀聰表示，大資料在去年7月的Gatner Hype Cycle中，開始從夢幻期進入幻滅期，沒想到今年8月，大資料完全消失在Hype Cycle中，很多人說大資料已死。不過，根據Gatner解釋，大資料很難自己獨立在一個領域，因此讓大資料「畢業」，隱身進入其他技術領域之中，成為其他技術的一份子，包括物聯網、BI、Enterprise Architecture、Web-Scale IT及數位金融轉型等領域，王耀聰表示，不只是最容易聯想的電子商務領域，大資料也將是數位金融背後的關鍵技術。
綜觀整個大資料技術的發展歷程，王耀聰表示，以前大資料處理的是靜止資料（Big Data at Rest），企業蒐集資料後，才做批次分析，代表技術包括MapReduce、Hadoop或Hive等工具，Petabyte檔案系統可以滿足Volume問題，而MapReduce架構可把資料從非結構化轉為結構化，不過，這些技術無法解決即時性的資料分析，資料進來後要等排程才能做運算，遇到迭代時很痛苦。
而現在的大資料已經能處理流動的大資料（Big Data in Motion），如金融交易、IoT災害預防等應用情境，必須做即時性的資料處理，此時，若是結構化資料則用HBase、Drill、Impala來滿足即時分析，使用記憶體內的資料處理方式（In-memory Processing），資料進來後先在記憶體內做運算，最後再將結果寫入硬碟。若是非結構化資料，則要用Message Queue的處理方式，採用Storm、Kafka等技術。
Lambda架構則是新的混合式大資料處理架構，運用Hadoop平臺同時處理串流即時訊息和大資料批次分析，王耀聰解釋，資料蒐集後分別送往兩邊，一邊寫到Hadoop平臺進行即時分析，採用Storm、Kafka等技術，另一邊寫到Speed Layer，進行批次處理。
他也表示，安全性（Security）是大資料接下來要面臨的一大課題，而安全機制可分為帳號密碼認證（Authentication）、基於帳號身分的管理讀寫權限（Authorization）、稽核讀寫紀錄（Auditing），以及資料加密、通訊加密（Encryption），王耀聰表示，現階段Hadoop生態圈在這四大安全性問題上已有對應的解決方法，不過Spark仍在努力中，尚未滿足這些安全性需求。
此外，非揮發性記憶體NVM也將是未來大資料發展的關鍵，王耀聰表示，以前資料在儲存與記憶體之間傳遞，如果未來記憶體本身就是儲存，將引爆軟體的新革命。