NO IMAGE

大資料是指資料如此之多以至於它超越了傳統的資料庫系統的能力,資料量太大,移動太快,也不滿足(傳統)資料庫架構的約束。為了能從資料裡面獲得價值,你必須選擇其他的替代方案來處理它。

大資料是2012年的熱門IT流行詞。大資料變的很高光可見,因為高費效比的方法已經出現了,可以馴服那些無論是量、速度還是變化性都很大的海量資料。在這些資料裡存在著有價值的模式和資訊,而之前因為獲得他們的代價和工作量是如此之大而很難獲得。對於領先的企業,比如沃爾瑪或谷歌,他們已經獲得了這些能力,但代價高昂。如今,隨處可見的普通硬體裝置、雲基礎架構和開源軟體已經讓大資料處理發展到了一個接近資源豐富的階段。大資料處理方式是有名的靈活,即使是很小的車庫創業公司也能通過租用很便宜的雲端伺服器來使用。

大資料能為組織帶來的價值可以歸為兩類:分析應用和產生新產品。大資料分析可以發現藏在資料裡的洞察,而以前因為花費太大而很難獲得。例如,這樣的洞察可以是客戶間的相互影響,這可以通過分析購物者的交易記錄、社會資訊和地理位置資訊來獲得。相對於靜態特性的方法,比如執行那些預先定義好的報表,能夠在合理的時間裡處理每一條資料就可以消除資料抽樣的影響,同時也能促進探索性分析方法的使用。

過去十年裡成功的網際網路創業企業就是把大資料用來產生新產品和服務的絕佳例子。例如,結合使用者和他們的朋友行為裡的海量訊號,臉書能夠打造高度個性化的使用者體驗,同時創造一種新的廣告業務模式。因此支援大資料的大牛的思想和工具出現在谷歌、雅虎、亞馬遜和臉書就絕不是偶然了。

大資料在企業裡的出現則帶來了一個必要的補充:敏捷。成功的開採大資料裡的價值需要實驗和探索。不管是產生新產品還是找到能帶來競爭優勢的方法,這些工作都要有好奇心和創業的眼光。

大資料是什麼樣子?

作為一個無所不包的名詞,“大資料”也相當的含糊不清,就如“雲端計算”覆蓋了很多技術一樣。大資料系統的輸入可以來自社交網路上的聊天者、網站伺服器日誌檔案、交通感測器、衛星圖片、廣播語音流、銀行交易記錄、搖滾樂的MP3檔案、網頁的內容、政府檔案的掃描、GPS的路徑、汽車的遙感器、金融市場資料,這個列表可以很長。這些都是一樣的東西嗎?

為了更清楚,這三個V(大數量、時效性、多樣性,Volume,Velocity,Variety)常常被用來定義大資料的不同方面。他們是有用的鏡片,通過他們可以觀察和理解資料以及可用來挖據資料的軟體平臺的特性。很可能你會與這三個V的每一個都有一定程度的鬥爭。

大數量(Volume

能處理海量的資訊並從中得到益處是大資料分析最吸引人的地方。有更多的資料可以抵消有更好的模型:在海量資料面前,簡單的數學可以非常不合理得有效。如果你能用300個因素而不是6個因素來做預測,你能不能預測的更好?

資料的大數量代表了對於傳統的IT架構最直接的挑戰。它需要有可擴充套件的儲存,以及可以分佈的查詢。很多企業已經擁有了海量的歸檔資料(可能是以日誌的形式存在),但沒有能力來挖掘。

當資料的量已經大到這些傳統的關係型資料庫基礎設施無法匹敵的時候,處理他們的方法選擇基本上也就是兩個,大規模並行處理架構(資料倉儲,或如Greenplum的資料庫)和基於Apache Hadoop的解決方案。如何選擇也經常會不同程度上受其他的一個V—多樣性—的影響。典型的是,資料倉儲的方法涉及到預先定義的資料模式,適用於那些比較規律並變化較慢的資料。與之相反,Apache Hadoop對要處理的資料結構和模式沒有這樣的限制。

Hadoop的核心是一個為跨大量服務節點的分散式計算問題而設計的平臺。它首先是由雅虎開發,並作為開源專案釋出的。它實現了MapReduce演算法,這個演算法最初是谷歌為了建立搜尋檢索而開發的。Hadoop的MapReduce涉及了把資料集分佈到多個伺服器上,並在“map”階段對資料進行(本地化的)運算。部分的結果在“reduce”階段被再組合起來。

為了儲存資料,Hadoop使用它自己的分散式檔案系統—HDFS—把資料分佈儲存在多個計算節點上。一個典型的Hadoop使用場景一般涉及三個階段:

  • 把資料匯入HDFS;

  • MapReduce運算;

  • 從HDFS裡查詢結果。

這個過程本質上是一個批處理過程,適合於分析和非互動的計算任務。也正因為這個,Hadoop自己並不是一個資料庫或者資料倉儲解決方案,而是和他們結合的一個分析助手。

廣為人知的Hadoop使用者之一就是臉書,它的模型就遵循上面的模式。一個MySQL資料庫儲存著核心的資料。資料隨後被匯入Hadoop進行計算,比如建立基於使用者和使用者的朋友興趣的推薦。隨後臉書把結果在導回MySQL資料庫,讓前端頁面呼叫。

時效性(Velocity

時效性是指資料流入的速度。時效性的重要性與大數量有類似的發展模式,最初的難題只侷限於特定行業,但現在卻出現在更廣泛的場景下。像金融交易這樣的特定企業早已經會調校他們的系統來利用快速移動的資料。現在是輪到我們了!

為什麼要這樣?網際網路和移動時代意味著,我們使用和消費產品與服務的模式已經更多的被測量,產生的資料又流回了產品和服務的提供者。電商企業也能夠收集大量的客戶歷史資料,不僅僅只是最後的購買行為,還包括客戶的每次點選和互動。能夠快速利用這些資訊的企業和個人則能獲得競爭優勢,比如推薦給客戶其他的購買選項。智慧手機時代更加增加了資料產生的速度,因為消費者自己隨身帶著一個不斷產生地理位置、圖片和聲音資料的資料來源。

不僅僅是產生資料的速度帶來的問題,例如也可以把快速流入的資料成塊的儲存起來留作以後處理。把輸入資料轉化為決策的速度是另外一個重點。IBM的一個廣告裡說明了這一點,如果你拿到的是五分鐘前的交通快照,你是不敢過馬路的。一定會有這樣的時候,你不能等到一個報表執行完或是Hadoop跑完一個任務。

對於這些快速流動的資料的行業術語可以是“流資料”或“複雜事件處理”。後者出現的比較早但已經逐漸的消失了,現在流式資料處理已經越來越廣泛地被認可。

使用流計算有兩個主要原因。第一個是輸入資料的速度太快從而沒法完全都存下來。為了能保證儲存的需求更實際,在資料流入的同時就必須進行一定的分析。這個問題的最極端的案例就是歐洲原子研究組織(CERN)的大型強子對撞機(Large Hadron Collider)。對撞機產生的資料太大,以至於科學家不得不丟棄其中絕大部分的資料,同時只能希望他們沒有丟棄那些有用的資料。第二個原因就是應用必須要求立刻就有響應。伴隨著移動應用和線上遊戲的興起,這樣的場景也越來越常見。

能處理流式資料的產品目錄可以分為已經商業化的產品,比如IBM的InfoSphere Streams,和那些來自網際網路行業的不是很完善但依然不斷湧現的開源框架,比如推特的Storms和雅虎的S4。

如前所說,不光是輸入資料的速度的問題,系統輸出資料的速度也很重要。反饋迴圈越緊密,競爭優勢越明顯。反饋的結果可以直接進入產品,例如臉書的推薦,或是儀表盤來幫助決策的形成。

正是網際網路行業裡對速度的需要才驅動了鍵—值儲存和列式資料庫,才帶來了對預先計算的資訊的快速檢索的優化。這些資料庫已經形成了一個叫NoSQL的分類,可以應對那些關係型資料庫所不適用的場合。

多樣性(Variety

很難得見到資料是排列完美且可以馬上處理的。大資料系統最常見的情形是資料來源非常繁雜,也不會很完美地符合關係型的結構。它們或是社交網路裡的文字、影象資料或是來自感測器的原始讀數,但沒有任何一個能馬上被整合進應用裡。

即便是網際網路裡,計算機到計算機的通訊本應能帶來某些格式保證。但現實的資料也是很混亂的。不同的瀏覽器傳送不同的資料,使用者的系統接收資訊,然後可能用不同的版本或供應商的軟體來通訊。同時如果這中間的任何部分涉及到人,那肯定會有出錯或不一致的情況發生。

一種常見的大資料分析場景就是從非結構化的資料中抽取出有序的內容,再交由人或者應用系統來使用。一個例子就是實體解析(Entity Resolution),即判斷一個名字到底指什麼東西。例如London這個詞到底是說的英國首都倫敦市,還是美國德州的倫敦市。當你的業務邏輯需要知道這個的時候,你可不想猜測。

從源資料到應用可用的資料的處理過程中,經常會發生資訊丟失。當你收拾整齊,就意味著你仍了東西。因此這指出了大資料的一個基本原則就是:如果可能,什麼都別丟。很可能在你丟掉的資料裡就存在著有用的訊號。一旦你丟失了原始資料,沒機會再找回來了。

儘管關係型資料庫已經相當流行且原理也廣為人知,這也不意味著他們應該是資料的最終歸宿,即便要求的是規整的資料。特定的資料型別適用於特定的資料庫型別。例如XML格式的文件就是最好是儲存在專門針對XML的資料庫,如MarkLogic。而社交網路本質上就是圖類資料,因此用諸如Neo4J的圖資料庫才容易讓對圖類資料的運算更簡單和有效。

即便資料的結構和資料庫沒有很大的不匹配,關係型資料庫還是有缺點,即它要求有靜態的資料模式。在一個敏捷的探索性環境裡,計算分析的結果將會隨著更多訊號的發現和抽取而不斷變化。準結構化的NoSQL資料庫就可以應對這種靈活性的需求。他們可以提供足夠的結構化來組織資料,同時也不用要求資料儲存前就定義好確切的資料模式。

來到現實

上面我們探索了大資料的本質,並從高的層面上瀏覽了大資料的風光。但通常情況都是,當落地到部署的層面,總是有超出工具選擇的其他維度需要考慮。

雲還是企業內部?

大多數的大資料解決方案都有三種提供方式:只有軟體,應用,以及基於雲的應用。使用哪種方式取決於很多東西,包括資料要本地化否、隱私和法規的限制、人力資源是否夠以及專案的需求。很多企業採用了混合的方式,即內部部署加按需申請的雲上的資源。

大資料是很大的

一個基本的事實是用傳統的方法無法處理的大資料也很難被傳輸移動。IT行業的一個漸成共識就是,應該移動計算而不是移動資料。如果你想分析美國人口普查資料,那直接在儲存這些資料的亞馬遜平臺上利用他們的網路服務來執行你的程式碼就非常容易,你就不用花時間和金錢來傳輸這些資料了。

即便資料不那麼大,也不難移動,將資料儲存在本地依然有問題,尤其是在資料更新很快的場景下。金融交易系統總是試圖用最快的連線鏈路來獲取源資料,因為處理時間上毫秒級的差別就意味著競爭優勢。

大資料是混亂的

混亂並不是總指基礎設施。大資料從業人員一致認為他們80%的精力和時間都花費在一開始的清理資料上了。正如皮特•瓦爾登(Pete Warden)在他的大資料術語表一文中所說:“我花費在把混亂的資料清理成可用的形式比我花在其他所有資料分析工作裡的時間都長。”

考慮到獲取資料和清理他們的高昂花費,就很有必要考慮一下從哪裡來獲取資料。有很多的資料集市,他們是獲得普通常見資料的地方,你也經常可以把改進後的資料交易回去。不同資料集市裡,資料質量肯定會有不同,但是在競爭的環境下,資料質量將會逐步成為(好的)資料集市的基準。

文化

大資料這種現象是和資料科學的出現緊密相關的。資料科學集合了數學、計算機學以及科學的精神。為了從大資料中獲益,需要投入資源來組建擁有資料科學技能的團隊,需要從組織架構上為他們提供支援,創造理解使用資料能帶來益處的氛圍。

D.J. 帕蒂爾(D.J. Patil)在他的報告《組建資料科學團隊》中定義了資料科學家所需要擁有的特性。

  • 技術專家:最好的資料科學家一般都擁有某個科學專業的深度專業知識和技能。

  • 好奇心:渴望能從資料表象下發現問題並萃取出一系列非常清晰的可檢測的假設。

  • 講故事能力:能使用資料來講故事,並能有效的進行溝通。

  • 聰明:能從不同方向看待問題,產生創新性的解決方案。

大資料分析專案的深遠的特性也帶來了不令人愉快的方面。為了能被挖掘,資料必須從存倉裡搬出,組織機構必須學會如何來溝通和解釋分析的結果。

講故事的技巧和聰明則是關口性的因素,能最終表明分析工作的好處是否能被機構所消化吸收。為了能有效地把分析產生的洞察用有意義的方法來傳達,視覺化資料的藝術性和實踐能力正變的更加重要。

知道你想往哪裡去

最後,需要記住的是大資料不是萬能藥。你可以在你的資料中發現模式和線索,但是之後會如何?IBM北美先進分析的領導者克里斯•約翰遜(Christer Johnson)給出一個開始大資料業務的建議:首先,決定你想要解決的問題。

如果你挑選一個真正的業務問題,例如如何改變廣告策略來提升每使用者的花費。那麼這個問題將能引導你的具體實施路徑。大資料的工作會從企業家精神裡獲益,同時它也能從一個非常具體的目標中獲益。

埃德·達姆比爾(Edd Dumbill)

埃德·達姆比爾是加州的一個技術專家、作家和程式設計師。他是O’Reilly的Strata和開源傳統大會的委員會主席。 他是Expecnation會議管理系統的開發者和創始人,還是Pharmalicensing.com線上智慧財產權交易中心的聯合創始人。 作為開源的老兵,埃德對多個開源專案都有貢獻,例如Debian和GNOME。並建立了描述軟體專案的DOAP詞彙表。 埃德已經寫作了四本書,包括O’Reilly出版的《學習的軌道》。他還經常性的在Google 和他自己的部落格eddology.com上撰寫博文。

閱讀原文(read more), 獲得更多資訊。