迎戰大資料-SAP篇(上)
好吧,這的確是個系列了。
這篇文字的主要內容譯自IDC的白皮書, Carl W. Olofson和Dan Vesset 發表於2012年8月的《Big Data: Trends, Strategies, and SAP Technology》。這份白皮書主要討論了因大資料而出現的新技術,對這些技術所應發揮的作用和應用情況進行了分析。還討論了大資料現在為什麼變得如此重要,以及大資料怎麼幫企業達成業務目標。之後它描述了大資料提出的挑戰,怎麼面對這些挑戰。最後羅列出了SAP提供的相關技術,並展示了這些技術如何幫企業利用大資料取得競爭優勢。
SAP不久前才收了Sybase,實力充盈了不少。經過幾輪收購整合,BI場上的真正玩家越來越少了。不知道那些產品線單一的刺客們還能獨行多久。
一個新的時代已然披紅掛綵鞭炮齊鳴地揭開了序幕。
這裡的黎明真熱鬧
資訊時代圓滿落幕,智慧時代破曉而出。寬頻通訊、智慧終端、社交網路、量化分析重新定義了生產商、分銷商和消費者之間的關係。資料在容量、種類、速度方面的增長帶來了新的挑戰,而這挑戰中蘊藏著巨大的商機。
資訊的獲取、分析和管理是智慧時代的主要任務。那些還在沉睡的組織,它們可能馬上就會被資料壓住,然後從噩夢中驚醒,不堪重負,氣喘吁吁。而那些天還沒亮就行動起來的勤勞小鳥,不僅能抓住資料,還會進化出量化分析能力,並由此做出正確決策,取得競爭優勢。在又一次商業大潮來臨之際佔得先機,有效分配資源,進行可持續、安全的管理,為自己的社群提供更好的產品或服務。
大資料的動力
為什麼是現在?它有什麼新鮮玩意兒?
商業和公共組織要在全業務流程上投資大資料解決方案有各種各樣的原因。儘管在各種大資料會議和與大資料相關的文章中最引人注目的是社交網站產生的資料,但經過調查,業務資料分析才是推動組織採用大資料解決方案的根本原因。
圖1 使用BI、量化分析和大資料技術主要動力的調查反饋佔比
然而,不管上圖中反饋結果的評級如何,我們都必須意識到,大資料所涉及的業務流程、技術和專業知識範圍都很廣泛。正因如此,大資料幾乎帶來了無限的機遇,但因為天地太過廣闊,指望著大有可為的青年們也會覺得有點找不著北。
大資料解決方案的終極目標,是為組織中所有層面的決策者提供更強大、更快速、更全面的洞察力,從而讓他們做出更好的決策。
IDC 決策管理框架
IDC 決策管理框架是一個評估這些機遇的工具。這個框架可以應用到大資料用例上,並能描繪三種決策型別和每種決策型別的四個主要變數,如圖所示:
圖2 IDC 決策管理框架
戰略決策因為其週期長,未知因素多,所以範圍最廣、風險最高。戰略決策的數量相對來說也很少;它們要求內部決策者和外部決策者之間要有較高的協作水平,而且實現自動化的可能性也很低。而另一端的戰術決策可能是由一線員工或系統完成的。在一個時間週期內會有很多這種決策,並且所有決策幾乎都沒什麼風險,也易於自動化。這些決定都是在現場,在工作流當中做出的,因此決策過程中發生協作的可能性很小。在IDC 決策管理框架中,運營決策介於兩者之間。
每個決策型別相關的人群也不同。運營決策是由業務分析師或定量分析師跟管理層一起做的,戰略決策是高管做的,戰術決策是一線員工或自動化系統、應用程式或機器做的。某一級決策的輸出會變成下一級決策的輸入。除了要考慮人員、資金和業務流程之外,理解組織的決策需求是邁向建立業務分析戰略的重要一步,而業務分析戰略是考慮所有相關技術的根本。
最後,不同的決策型別和決策者可能會要求不同的資料和資料技術支援。這些技術包括資料收集、資料監測、資料管理、資料分析和資料傳播等。戰術決策通常都是基於對實時資料流的監測,所採取的行動也是遵照預先定義好的規則。運營決策可能需要對海量的多種結構資料進行深入分析。戰略決策可能需要對即時系統根據情景所作出的響應進行快速評估,以便能夠改善風險管理。
滿足所有決策者的需求是一項艱鉅的任務,不可能僅憑一種技術或一個專案就可以完成。
大資料的挑戰
決定哪些資料相關是個難題。
2012年初IDC發起的一項調查表明,被提到最多的困難是決定哪些資料相關。IT和業務部門都聲稱他們需要重新評估組織內部為支援決策過程所評測的資料。很多組織都在重新思考如何分析現有資料和新的資料來源,以改變或改善決策支援、決策自動化和績效管理流程。量化的思想或許會對解決這個難題有所幫助。
此外,技術基礎設施的成本,缺乏合適的分析人員和IT人員,缺乏業務支援,或理解不了大資料所能帶來的好處,這些挑戰都在阻礙著他們抓住智慧時代帶來的機遇。
這些挑戰表明許多大資料應用都缺乏公認的最佳實踐。你有資料可以收集、分析,並按分析結果所做的決策採取行動。然而能否實現目標卻取決於:
- 組織是否具備確定新指標的能力;
- 組織僱傭的員工是否有稱職的分析技能、資訊管理和系統管理技能;
- 組織的文化是否由分析驅動,能把分析結果當做可信的輸入來做出決策;
- 組織是否有合適的技術可用。
大資料對技術的需求
什麼是大資料
IDC對大資料技術的定義:為了能用經濟有效的辦法從各式各樣的海量資料裡提煉價值而開發出來的新技術,包括硬體、軟體,和服務。它們能高速地完成資料捕獲,發現和分析任務,對符合“4V”特性的資料進行整合、組織、管理、分析和呈現。
4V指資料量(volume), 資料種類(variety),資料產生和處理的速度( velocity), 資料的價值(value)
資料量:大小並不是特別重要
儘管大資料裡的“大”暗指資料的量大,但我們必須明白“大”是一個相對的概念。某些行業和組織可能連GB或TB的資料都很少見,而社交網站的資料則動輒就達到了PB或EB的級別。不管怎樣,那些看起來不大的應用程式進行資訊處理和分析的緊張複雜程度可能完全符合我們對大資料應用的定義。金融服務業就能很好地說明這個問題。在某些大資料處理活動中,所涉及的記錄數可能有上百萬甚至上億行,但每條記錄的長度可能只有幾個位元組(比如股票行情資訊)。相反,email歸檔累計起來可能有幾個PB的資料,其中包含著高階客戶的建議或抱怨,專案的記錄,法務記錄,合同和提案等各種資料。郵件歸檔通常能最準確地反映出未決的及當前的業務狀況,但只有經過排序和挖掘之後,才能發現其中的價值。產品設計製造也是這樣,比如在汽車和航空公司裡,要對成百上千個虛擬原型進行評估,以便找出最佳的車輛(飛行器)設計。還有大型科學實驗,每天要產生PB級的混合資料,作為複雜的模擬資料輸入計算模型中。
資料種類:重要的是資料來源和資料格式
多樣性是大資料的關鍵屬性。是否從多種資料來源對多種格式的資料進行整合,是判斷一個應用程式能否被稱為大資料應用的決定性條件。
大資料應用通常都會從多個資料來源(既有內部資料來源,也有外部資料來源)抽取型別不同的資料(結構化、半結構化和非結構化)。無論從技術上,還是從潛在影響來看,這都是大資料中很重要的一個方面。對不同型別的資訊進行組合是一個複雜的技術難題:一條客戶記錄跟一條微博哪個比較重要?怎麼才能把大量不斷變化的病人記錄跟公開發表的醫療研究報告和基因組資料結合起來,以便為某個病人找出最佳治療方案?
把來自於ERP系統的內部運營資料,來自於web日誌檔案的半結構化資料(識別客戶線上行為),以及來自客戶評論的非結構化文字情感分析資料混搭在一起就是這種情況。先進的天氣/氣候模型也屬於這種情況,借鑑100多年的天氣資料和新的海水行為物理模型,CO水平變化,結合衛星資料進行實時天氣狀況模擬。
速度:資訊到達、分析和交付的速度
組織內部有各種不同的系統,資料移動的速度可以分為批量整合定期載入和實時資料流兩種。傳統的資料倉儲,也是現在使用Hadoop的主流資料處理方法用的就是批量整合、定期載入。而採用實時資料流的技術領域一般包括複雜事件處理(ECP),規則引擎,文字分析和搜尋,推理,機器學習和基於事件的架構。
評估大資料速度需求的關鍵是搞懂業務流程和終端使用者的需求。比如說,對於應急響應組織或證券交易公司而言,每一秒(甚至毫秒)產生的資料都很寶貴。還有機場,為了在罪犯進入機場時就能發現,需要進行實時的面部識別。然而作為MapReduce和Hadoop發祥地的搜尋引擎,為確定演算法的準確性或廣告的匹配度時而對十幾億的查詢資料進行處理和挖掘時,並不需要實時分析。換句話說,用恰當的時間獲取準確度合適的恰當資訊才是我們所需要的。
不同的用例適用的技術架構也不同。在架構界流傳著一句老話,“只要扔進去足夠多的硬體,任何問題都能解決”。業界已經為解決特定問題搭建過大型超級計算機和大規模叢集了,這句話的正確性毋庸置疑。
然而現在需要用專門的硬體來滿足的高效能需求越來越少了。高可用叢集,可擴充套件的檔案系統,多CPU,多核處理器的出現意味著利用現成的商業元件進行組合就能輕鬆滿足效能要求。現在社會化應用甚至大多選擇部署在雲服務上,根本就不專門考慮硬體。
價值:資金,運營,業務優勢一個都不能少
在大資料裡談到價值,既指使用大資料所需技術成本的降低,也指使用大資料創造的價值。成本是大資料問題在智慧時代得以解決的決定性因素。在金融服務,電信,零售,研發和政府組織中的大型資料倉儲已經存在好多年了。在交易、天氣監測或欺詐檢測應用裡的實時資料管理也存在好多年了。以文字挖掘的形式出現的非結構化內容分析也存在好多年了。用於科學研究的高效能運算系統也存在好多年了。然而自從進入智慧時代,那些曾經只有政府機構或某些行業少數幾個大公司才負擔得起的系統,現在也擺上了“尋常百姓家”的餐桌。更多可用軟體的出現和不斷降價的硬體,讓更多的組織可以在預算中hold住這些大資料技術。
從大資料專案中得到的好處大致可以分為:
- 資金成本降低 :軟硬體和其它基礎設施的成本降低了
- 運營效率提高:由於資料整合、管理、分析和交付的方法更加高效,人力成本也降低了
- 業務流程改進 : 因為採用新辦法(或更好的辦法)來開展業務,包括商業交易的改善,社群的可持續管理,社會資源、醫療保健和教育服務的恰當分配,使回報或者說利潤得到了增長。
大資料所代表的並不是企業範圍內單一、同質的需求。然而大多數人並沒有認識到這一點,普遍的看法是隻有那些要用Hadoop處理的海量資料才是大資料。比如在IDC得到的調查反饋報告中,40%的受訪者認為大資料是指海量資料,26%認為是指各種各樣的資料,24%認為是指實時流資料,10%認為它是指高效能運算。
對大資料的誤解
大資料技術所呈現出來的機遇持續增長,越來越大。改善現有業務流程和大資料技術有關,推出新業務和大資料技術有關,改變跟客戶的互動方式跟大資料技術有關,為了支援範圍更加廣泛的決策過程,要對為什麼分析資料,以及怎麼分析資料進行重新評估,這還和大資料技術有關。
哪裡有需求,哪裡就有市場。大資料解決方案的市場雛形剛具,各路英雄豪傑各顯其能,打破了頭也想要擠上這趟車,場面一片混亂。對於什麼是大資料,以及大資料技術能幹什麼,無論使用者還是供應商,都有諸多誤解。
- 大資料分析就是用最新開發出來的技術做些新穎的,不同以往的事情。大資料就是做些新東西的思想是錯的。大資料的概念已經出現幾年了。真正發生變化的,是現在的經濟條件允許我們使用大資料了,是我們現在有能力用計算機輔助發現那些從各種資料來源匯聚而成的超大資料集之間的關係了,是我們已經意識到,如果能用正確的工具在正確的時間向正確的決策者提供正確的資訊,量化分析是可以形成競爭優勢的。
- 大資料技術就是跟Hadoop環境(廣義上說是MapReduce環境)有關的技術,和工作負載或應用無關。 我們產生這種誤解的原因可能是因為覺得關係型資料庫不能擴充套件到超大規模資料容量上,所以不能算大資料技術,或者說正規化化的DBMS已經過時了,正規化資料庫只是大資料部署中的資料來源之一。另外一種常見的誤解是大資料是一種技術,比如Hadoop,能滿足所有的大資料處理需求。而事實是完成這項任務的技術必須經過精挑細選。就像沒有一把鑰匙能開所有的鎖,沒有哪種大資料技術可以滿足所有的大資料需求。儘管NoSQL資料庫在大資料應用中越來越流行,關係型資料庫也仍然在發揮著重要作用。儘管Hadoop在市場上越來越受青睞,但它既不是資料管理的唯一之選,也不是僅有MapReduce的實現。
- 大資料僅僅跟超大量的資料有關,引申來說,主要是跟資料有關。 大資料集肯定是大資料市場趨勢的關鍵部分。實際上,40%的組織認為大資料就是超大量的資料。但它還有其他特性,比如實時或流資料、型別或格式繁多的資料。有些大資料技術針對的是三種特性的其中之一,有些針對其中兩個或全部三個特性。
- 大資料就是資料探勘的時髦叫法。 資料探勘是指可以用來分析大資料集的一組分析技術。其中的一些技術已經用了幾個世紀了;也有一些是最近才出現的。然而,大資料,按照IDC和大多數市場觀察和參與者的定義,是個範圍更廣泛的主題,包括資料收集,資料管理和組織,資料分析,資訊訪問以及運營負載,還有用到一些新的和已有的大資料技術的應用。
- 大資料是個挑戰。可能現在對大資料最嚴重的誤解就是隻要採用了大資料技術,就能解決業務問題,就能增加收入,降低成本,還能吸引客戶。把大量資料儲存下來,不管是在關係型資料庫中還是在Hadoop叢集中,都不是最終的目的。搭上就好的技術部署方式從來就沒有成功過,在大資料這兒也不靈。分析資料也不是最終目的。到不了決策者手裡,或被決策者忽略的分析結果非常多,其中不乏由鼎鼎大名的資料科學家做出來的偉大的、有見地的,並且及時的分析,還有些分析因為沒考慮到人類在互動過程中的行為變化而適得其反。最近就有個非常有名的例子,一家大型零售商為確定客戶群開發了一套非常精確的分值預測系統,但在向選定客戶進行營銷時卻失敗了,因為它對受眾對個人隱私保護的敏感程度考慮的不夠充分。
理解這些誤解非常重要,不然你很可能會陷入毫無意義的技術對比優劣之爭。實際上,對於大多數有一定規模的組織來說,為了對工作負載和應用進行改善,需要多種大資料技術共存。
大資料技術
根據所處理資料的不同,IDC認為大資料技術可以分為兩類:處理運動中的大資料,處理空閒期的大資料。
運動中的大資料
運動的大資料是指快速流動的大量資料,這些資料一經收到就要馬上處理。這樣的資料包括股票交易資料,智慧電錶資料,實時庫存管理系統中的RFID資料等等。與資料相關的操作可以分為三類。
對於運動中的大資料,在收到之後會對它們進行過濾,並做正規化處理(變成統一的或可讀的格式)。這通常是由接收程式完成的。系統會決定是否需要進行響應。這可能會牽涉到一個複雜的事件處理引擎,得到新資料,根據保留的資料(包括來自資料流的快取資料和儲存在快速儲存【一般是記憶體】資料庫中的資料)應用新的資料,並確定發生的是否為已定義的事件。如果發生的是已定義的事件,CEP引擎會觸發一個動作,也就是程式對該事件的響應。
運動中的大資料對技術的要求是資料接收,格式化和響應的速度能跟上資料到達的速度。相關的技術包括智慧高速資料遷移和轉換技術,記憶體資料庫和CEP技術。
空閒期的大資料
目前所討論的大資料大部分是指空閒期的大資料,處於空閒期的大資料包括“機構化”和“非結構化”的資料。後來,很多專家對這些術語提出了異議,指出我們所說的“非結構化”資料實際上也有結構,只是它們的結構不是由正規化或程式程式碼確定的。要處理這個問題,我們可以考慮下表中的分類:
型別 | 容器 | |
---|---|---|
結構化資料 | 外部顯式結構 | 固定或可變正規化的資料庫(比如., RDBMS,OODBMS) 結構是由資料之外的正規化管理器顯式宣告和管理的。 |
外部隱式結構 | 非正規化資料庫(鍵-值儲存) 應用程式知道這個結構,但沒有顯式的管理 | |
非結構化資料 | 內在顯式結構 | 標籤格式的資料,如XML,CDF,標準交換格式檔案等等。 該結構以標題,標籤,或其他形式的標籤的形式表現在資料中。 |
內在隱式結構 | 人類語言內容 結構沒有顯式宣告,但可以從資料中推匯出來。人類語言的語義是可以從句法和語法中找出來的 |
對於空閒期的大資料,相應的技術應該具備儘快採集資料的能力,整理和轉換資料的能力,分析資料的能力,還有將資料置於待處理狀態的能力,從而可以對它們進行有意義的搜尋、挖掘、探索、查詢,和產生報告。
NoSQL和SQL資料庫技術在大資料中都有重要作用。NoSQL資料庫非常善於支援大資料的“多樣性”,能夠接受來自多種資料來源的多種格式的資料,然後程式程式碼可以對這些資料進行篩選,過濾,和組織。很多Hadoop程式都是這麼幹的。SQL資料庫非常善於處理大量結構一致的資料,可以在這樣的資料上產生常規報告、挖掘和重複進行分析。
具備動態擴充套件能力的RDBMS能處理非常大的資料庫,而且作為大資料SQL DBMS能快速處理這種資料庫請求。
NoSQL是另一回事。這個隨處可見的詞實際上是很多種DBMS的統稱,每種DBMS都有特殊的用途,而且多種資料庫可能會一起出現在同一系統中,作為大資料操作流的有效組成部分。如下表所示:
正規化 | 用途 |
---|---|
鍵-值 | 快取共享資料,建立臨時資料空間 |
基於網格的鍵-值 | 用於分析的超大型臨時可擴充套件資料集合 |
列表處理 | 收集大量不可預測的結構化資料進行分析 |
圖 | 管理資料實體之間的不限層次的關係,具備快速遍歷和搜尋能力 |
新SQL | 接受隨後應用或推斷結構的資料,以支援沒有預定義schema的關係型查詢 |
大資料應用
大資料解決方案的使用範圍非常廣泛。目前市面上能見到的基本如下圖所示:
我們可以從活動、業務流程和行業三個維度來對這些用例進行評估。
活動
並不是所有使用大資料技術的應用都是為了分析資料。有一些是為了部署社交網站或遊戲應用,還有一些是為了儲存大型內容,提供海量文件的資訊訪問。
- 分析(比如資料探勘,多維分析,資料視覺化)
- 運營(比如執行網站,處理線上訂單)
- 資訊訪問(比如基於搜尋的資訊訪問,規範化,以及跨內容和資料來源的訪問)
業務流程
大資料技術被部署在商業組織、非盈利組織和政府組織內部以支援他們的工作流程。組織所面臨的問題和困難不是大資料挑戰,而是受大資料影響的業務或組織問題。部署大資料技術的業務流程有:
- 客戶關係管理(銷售,營銷,客服等)
- 供應鏈和運營
- 管理(集中在財務及會計,人力資源,法務等方面)
- 研發
- 資訊科技管理
- 風險管理
行業
除了財務、營銷和資訊科技管理這樣跨行業的業務流程,還有多種特定行業的應用。這樣的例子包括:
- 運輸行業中的物流優化
- 零售行業的價格優化
- 媒體和娛樂行業的智慧財產權管理
- 石油和天然氣行業的自然資源勘探
- 製造業的質保期管理
- 當地執法部門的預防犯罪和調查
- 保險行業的預測性損失評估
- 銀行業的欺詐檢測
- 醫療保健行業的病人治療和欺詐檢測
面對如此廣闊的市場前景,提供大資料技術解決方案的供應商既有小型的專業化公司,也有產品線豐富,生態系統完備的大型公司。SAP屬於後者。
想要廣告,請看下集!
相關文章
- 迎戰大資料-Oracle篇大資料Oracle
- 手機上的大資料:手機大資料的挑戰大資料
- 大資料應用場景之戰-行業篇大資料行業
- 如何使用SAP HANA Vora規劃HANA大資料戰略?LH大資料
- Android 大檔案上傳秒傳之實戰篇Android
- 中國迎來大資料“黃金時代”資料安全需求更加迫切大資料
- 為什麼python大資料受歡迎?Python大資料
- 【雲端大資料實戰】大資料誤區、大資料處理步驟分析大資料
- 大資料技術之資料採集篇大資料
- 【乾貨合輯】大資料難,難於上青天?快接好這套學習寶典迎難而上!大資料
- 大資料時代,為什麼python大受歡迎?大資料Python
- Go 大資料生態迎來重要產品 CDSGo大資料
- 大資料看郭韓大決戰——資訊圖大資料
- 【大資料】大資料行業洞察:未來2-3年或迎資料時代的真正高潮大資料行業
- 大資料實戰:電商該如何利用大資料獲取流量?大資料
- 大資料開發之路:hive篇大資料Hive
- 騰訊雲大資料實戰案例大資料
- 羊毛黨的大資料攻防戰大資料
- 資料庫週刊34丨首屆達夢資料庫精英挑戰賽啟動;2020(上)最受歡迎資料庫文章…資料庫
- 2018年Analytics Vidhya上最受歡迎的15篇資料科學和機器學習文章資料科學機器學習
- Go 大資料生態迎來重量級產品 CDSGo大資料
- 大資料導航新版上線大資料
- 淺談醫學大資料(上)大資料
- 大資料解決方案-(基礎篇)大資料
- 【大資料】MapReduce開發小實戰大資料
- 資料大屏視覺化挑戰視覺化
- 矽谷大資料【上】:什麼是 “改變世界” 的大資料公司大資料
- 大資料帶給保險業的三大挑戰大資料
- 送給前端的乾貨,1000篇前端學習資料大合集!(上)前端
- SAP HANA Cloud 學習教程之二: 如何往SAP BTP 上 HANA Cloud 資料庫表裡插入資料Cloud資料庫
- sap strans 資料
- 大資料,大資料,大資料大資料
- 影響資料驅動業務目標的大資料挑戰大資料
- 資料建模大資料就業挑戰月薪30K大資料就業
- 使用JDBC操作SAP雲平臺上的HANA資料庫JDBC資料庫
- Flutter上線專案實戰——路由篇Flutter路由
- 大資料下的Distinct Count(二):Bitmap篇大資料
- 史上最全的“大資料”學習資源(上)大資料