### **一、大數據和他的朋友們** #### **1. 大數據和數據庫的關系** 這里直接引用廈門大學林子雨老師的比喻，“池塘捕魚”好比傳統數據庫時代的數據管理方式，而“大海捕魚”則對應著大數據時代的數據管理方式。“魚”是要處理的數據，而“捕魚”環境的變化直接導致了“捕魚”方式的變更。 1. 數據規模：“池塘”規模較小，即便是比較大的“池塘”，如VLDB（Very Large Database），和“大海”的XLDB（Extremely Large Database）相比仍舊偏小。**數據庫的處理對象通常是以 MB 為單位，而大數據則動輒 GB，TB、PB乃至ZB也不為過**。 2. 數據類型：“池塘”中“魚”的種類一般只有一種或幾種，以結構化數據為主。**而“大海”中“魚”的種類繁多，不僅包含結構化數據，還有半結構化和非結構化數據，而且后兩者的比例越來越高**。 3. 數據模式：模式，即Schema。傳統數據庫是先有模式，再產生數據。好比先建好“池塘”，然后再投放適合在其中生長的“魚苗”。**而大數據時代往往難以預料模式，模式只有在數據產生之后才能確定，而且還會隨著數據規模的變化而不斷演變**。隨著時間的推移，“魚”在不斷增長和變化，從而推動了“大海”成分和環境也在不斷變化。 4. 處理對象：在“池塘”中捕魚，純粹就是捕魚，這就是最終目的。而在“大海”中捕魚，除了捕魚，還可以通過某些“魚”來預測其他“魚”的存在。也就是說，傳統數據庫中的數據僅作為處理對象，**而大數據時代，數據是一種資源，關鍵是進行分析、挖掘、預測和解決領域問題**。 5. 處理工具：在“池塘”捕魚，少數幾種工具就可以應對，也就是所謂的“One Size Fits All”。而在“大海”中捕魚，**可能要針對不同類型的“魚”采用不同的工具，也就是所謂的 “No Size Fits All”**。 圖靈獎獲得者、著名數據庫專家 Jim Gray 博士觀察并總結人類自古以來， 在科學研究上先后歷經了**實驗、理論和計算**三種范式。當數據量不斷增長和累積到今天，傳統的三種范式在科學研究，特別是一些新的研究領域已經無法很好的發揮作用。Jim Gray 提出了一種新的“數據探索型”研究方式，稱其為科學研究“第四種范式”(The Fourth Paradigm)。 對于這四種范式： * **實驗范式**，數千年的歷史，大部分時間都是依靠實驗范式對自然現象的描述進行科學研究。 * **理論范式**，隨著文藝復興與工業革命的到來，科學研究不再滿足于簡單自然現象的闡述，而是希望通過縝密的理論找到因果關系，大概擁有幾百年的歷史。 * **計算范式**，隨著計算機的發明，用強大的計算能力實現曾經難以觸及的領域，這也就是過去幾十年發生的事情。 * **數據探索范式**，今天正在發生，依靠對大量數據的分析，預測事情發展的規律。 第四種范式的實質就是**從以計算為中心，轉變到以數據處理為中心，也就是我們所說的數據思維，這是一種根本的思維轉變**。比如計算社會科學，基于特定社會需求，在特定的社會理論指導下，收集、整理和分析數據足跡(data print)，以便進行社會解釋、監控、預測與規劃的過程和活動。 #### **2. 大數據和云計算的關系** 1. 大數據和云計算是相輔相成的。**大數據聚焦“數據”，云計算聚焦“計算”**。沒有大數據的積淀，計算能力無用武之地；沒有云計算的處理能力，大數據也只是鏡花水月。 2. 大數據在技術方面根植于云計算。比如**MapReduce編程模型**（分布式編程模型，可用于并行處理大規模數據集的軟件框架）、**海量數據存儲技術**（分布式數據存儲，冗余機制保證系統可靠性）、**海量數據管理技術**（NoSQL數據庫，進行海量數據管理和數據分析）等技術。 #### **3. 大數據和物聯網的關系** 物聯網（IoT - Internet of Things）通過智能感知、識別技術、泛在網絡的融合應用，被稱為繼計算機、互聯網之后世界信息產業發展的第三次浪潮。 物聯網架構大致可分為三層： 1. 感知層：由各種各樣的傳感器（Sensor）構成，如溫濕度傳感器、二維碼標簽讀寫器、GPS、攝像頭、穿戴設備等。**這是物聯網信息數據的來源**。 2. 網絡層：由各種網絡，如互聯網、廣電網、通訊網、專用承載網、網管系統、云計算平臺等組成。**這是物聯網的中樞，負責傳遞和處理感知層獲取的信息**。 3. 應用層：**是物聯網和用戶的接口**，與行業需求相結合，實現物聯網智能應用。 物聯網用途廣泛，遍及交通、環境保護、政府工作、公共安全、家居、消防、工業監測、環境監測、照明管控、老人護理、個人健康、水系監測、食品溯源、敵情偵查和情報搜集等多個領域。物聯網每天都在產生海量數據，需要利用大數據技術對數據進行篩選、處理和分析，提取出有用的信息，以便支撐自身的創新。而大數據領域的一些專業公司，也非常渴望獲取物聯網領域豐富多彩的數據信息，豐富自身的內容樣本庫。 #### **4. 大數據和人工智能的關系** 正在辛苦的寫作中…… *** ### **二、大數據是多種技術協同的體系** >[info] ***大數據價值的完整體現需要多種技術的協同。文件系統提供最底層存儲能力的支持。為了便于數據管理，需要在文件系統之上建立數據庫系統。通過索引等的構建，對外提供高效的數據查詢等常用功能。最終通過數據分析技術從數據庫中的大數據提取出有益的知識。*** > > ---- 摘自《大數據技術基礎》（廈門大學 林子雨） 大數據不是單一的技術，文件系統、數據庫系統、數據挖掘與分析系統、數據呈現系統、大數據應用系統自下而上構成了一套技術體系和生態鏈。同時，雖然底層數據來源多種多樣，應用訴求和數據類型不盡相同，但基本的處理流程卻基本相同： >[info] ***整個大數據的處理流程可以定義為:在合適工具的輔助下，對廣泛異構的數據源進行抽取和集成，結果按照一定的標準進行統一存儲，并利用合適的數據分析技術對存儲的數據進行分析，從中提取有益的知識并利用恰當的方式將結果展現給終端用戶。*** > > ---- 摘自《大數據技術基礎》（廈門大學 林子雨） 簡單總結就是：異構數據源 ----> 數據抽取與集成 ----> 數據分析 ----> 數據呈現 *** ### **三、大數據處理的基本流程** #### **1. 數據抽取與集成** 由于數據來源的多樣性，在處理數據之前，需要先對數據進行預處理，從中提取出關系或對象實體，經過關聯和聚合之后采用統一定義的邏輯結構進行存儲。同時也要進行一定的清洗工作，以保證數據的質量和可信度。 數據抽取與集成不是全新的技術，在數據庫時代已有成熟的研究和方法論。比如以下常用的幾種數據集成方式： 1. **數據整合（Data Consolidation）**：通過工具將不同數據源批量集成到同一個物理倉庫，當數據量較大時，數據整合的代價也可能較高。 2. **數據聯邦（Data Federation）**：在多個數據源之上建立一個邏輯視圖，提供一個統一的數據訪問入口，對外屏蔽不同數據源的分布細節，被請求時臨時從不同數據源獲取數據。 3. **數據傳播（Data Propagation）**：通過技術手段實現數據在多個應用之間可傳播。 #### **2. 數據分析** 數據分析是大數據的核心。大數據的目的就是為了通過分析，作出預測，給出決策建議。傳統的數據分析技術如數據挖掘、機器學習、統計分析在大數據時代面臨新的挑戰，需要作出一定調整： 1. 數據量變得巨大不代表價值的增加，反而可能提升噪音。**數據清洗難度變高，代價變大**。 2. 算法需要與時俱進。比如大數據應用往往對實時性較高要求，而對準確性的要求可能降低，**這就要求算法在準確率與實時性上取一個均衡**。再比如大數據主要依托云計算，云計算的重要特征之一是分布式和高擴展，**算法能否匹配與適應基礎設施的變化**？ 3. 數據分析結果好壞難以評價。給出分析結果并不難，但由于大數據的數據來源分布廣，數據結構類型多，數據量大，**如何證明該結果的準確性和價值高低是困難的**。 #### **3. 數據呈現** 再好的分析結果，如果沒有良好的呈現，用戶可能難以理解，甚至受到誤導，這就背離了大數據的初衷。大數據時代要呈現的數據量很大，相互關聯關系又變得更為復雜，可以考慮從如下兩個方面提升呈現效果： 1. **可視化技術**：諸如標簽云(Tag Cloud)、歷史流 (History Flow)、空間信息流(Spatial Information Flow)等，而且有很多專業公司致力于此。 2. **讓用戶參與和了解數據分析過程**。 *** ### **四、大數據處理模型** #### **1. 大數據唯快不破** >[info] ***設想我們站在某個時間點上，背后是靜靜躺著的老數據，面前是排山倒海撲面而來的新數據。在令人窒息的數據海嘯面前，我們的數據存儲系統如同一個小型水庫，而數據處理系統則可以看作是水處理系統。數據涌入這個水庫，如果不能很快處理，只能原封不動地排出。對于數據擁有者來說，除了付出了存儲設備的成本，沒有收獲任何價值。*** > > ---- 摘自《大數據技術基礎》（廈門大學 林子雨) 在老板眼中，數據是成本，是投資，是價值回報。： 1. **時間就是金錢**：數據是礦產，“挖礦”效率就是競爭力。 2. **數據價值會折舊**： >[info] ***等量數據在不同時間點上價值不等。NewSQL 的先行者 VoltDB 發明了一個概念叫做 Data Continuum，即數據存在于一個連續時間軸(time continuum)上，每一個數據項都有它的年齡，不同年齡的數據有不同的價值取向，“年輕”(最近)時關注個體的價值，“年長”(久遠) 時注重集合價值。*** > > ---- 摘自《大數據技術基礎》（廈門大學 林子雨) 3. **數據具有時效性**： >[info] ***炒股軟件免費版給你的數據有十幾秒的延遲，這十幾秒是快速獵食者宰割散戶的機會；而華爾街大量的機構使用高頻機器交易(70%的成交量來自高頻交易)，能發現微秒級交易機會的吃定毫秒級的；物聯網這塊，很多傳感器的數據，產生幾秒之后就失去意義了；美國國家海洋和大氣管理局的超級計算機能夠在日本地震后 9 分鐘計算出海嘯的可能性，但 9 分鐘的延遲對于瞬間被海浪吞噬的生命來說還是太長了。*** > > ---- 摘自《大數據技術基礎》（廈門大學 林子雨） #### **2. 大數據的兩種處理模式** 數據可能是靜止的，也可能是動態的，這也分別對應了批處理和流處理兩種處理范式： ###### **第一，靜止的：數據像水庫中的水，靜靜地躺在那里，等待輸入不同的邏輯對其進行處理，計算完將價值留下。對應批處理范式。** 批處理范式下最核心的思想就是數據不動邏輯動，簡單看下 Google 的 MapReduce 思想： :-:  首先，MapReduce 模型的核心思想是： * 將待處理問題分而治之。 * 把計算推到數據而不是把數據推到計算，避免數據傳遞過程中大量的通訊開銷。 MapReduce 模型的處理過程基本上可以分成三部分： * MapReduce 模型將用戶的原始數據源進行分塊，交給不同的 Map 任務處理。 * Map 任務從輸入中解析出 Key/Value 對集合，對這些集合執行用戶自行定義的 Map 函數，并將執行結果寫入本地硬盤。 * Reduce 任務從硬盤上讀取數據，根據 key 值進行排序，將具有相同 key 值的數據組織在一起，對組織好的數據執行用戶自定義的 Reduce 函數，并輸出最終結果。 >[info] ***Hadoop 就是典型的批處理范式：HDFS存放已經沉淀下來的數據，MapReduce的作業調度系統把處理邏輯送到每個節點進行計算。這非常合理，因為搬動數據比發送代碼更昂貴。*** > > ----摘自《大數據技術基礎》（廈門大學 林子雨） ##### **第二，動態的：數據像流動的小溪，從外界不斷涌進，而邏輯保持不變，計算完將價值留下，原始數據或加入靜態數據中，或丟棄。對應流處理范式。** 流處理范式的基本理念是數據的價值會隨時間的流逝而降低，因此需要盡快對最新的數據進行處理。 流處理范式看重數據處理的實時性，而數據流本身可能會很大很快，因此不太可能對數據進行持久化，而是直接在內存中進行處理，內存也進而成為流處理的瓶頸點。 :-:  >[info] ***流處理品類繁多，包括傳統的消息隊列(絕大多數名字以 MQ 結尾)、事件流處理(Event Stream Processing)、復雜事件處理(Complex Event Processing 或 CEP)(如 Tibco 的 BusinessEvents 和 IBM 的 InfoStreams)、分布式發布/訂閱系統(如 Kafka)、專注于日志處理的(如 Scribe 和 Flume)、通用流處理系統(如 Storm 和 S4)等。*** > > ----摘自《大數據技術基礎》（廈門大學 林子雨） ##### **第三，動靜態數據和處理邏輯之間的關系** 下面這張圖體現了靜態和動態兩種數據和各自的處理邏輯之間的關系 :-:  這兩種范式沒有誰更好一說，好比生活中，有人喜歡把事情攢成一堆兒一起做，而有些人則喜歡來一件事就處理一件事。一般認為，流處理范式更快一些，但流處理模式往往對應最近的一個數據窗口，只能獲得實時智能，而難以實現全時智能，而此又恰恰是批處理范式的優勢所在。因此這兩種范式常常配合使用，甚至形成了這樣的定式： * **流處理范式作為批處理范式的前端**，先用流范式過濾噪音，留下感興趣的數據，保存下來以待批處理范式進行后續處理。 * **流處理范式與批處理范式分工協作**，流處理范式負責動態數據和實時智能，皮處理范式則負責靜態的歷史數據和歷史智能，實時智能與歷史智能共同組成全時智能。 #### **3.怎么快起來** 前面說了大數據唯快不破，也講了大數據的兩種處理范式，那如何才能做到“快”呢？這同時是商業決策者和系統架構師的巨大挑戰。 1. **首先，快是要付出代價的**。所以，要先搞清楚什么是“快”，需要多“快”。是毫秒級，秒級，分鐘級，小時級，天級……快無止境，適度即可。 2. **其次，要考慮當前的系統是否有潛力做到更快，還是要重新重構**。基于傳統的關系型數據庫，大概能做到TB量級，并可以通過分庫分表（sharding）以及緩存（memcached）來延續傳統數據庫架構的生命。但如果有更高的要求，就需要考慮新的架構，是批處理范式，還是流處理范式，或者是兩者的結合？這就需要量身定做了。 >[info] ***Intel 有一位老法師說：any big data platform needs to be architected for particular problems (任何一個大數據平臺都需要為特定的問題度身定做)。這是非常有道理的。為什么呢？比如說大方向決定了要用流處理架構，落實到具體產品少說有上百種，所以要選擇最適合的流處理產品。再看批處理架構，MapReduce 也不能包打天下，碰到多迭代、交互式計算就無能為力了；NoSQL更是枝繁葉茂，有名有姓的 NoSQL 數據庫好幾十種。*** > > ----摘自《大數據技術基礎》（廈門大學 林子雨） 上面說的是原則，實際上還是有一些通用的方法論讓大數據“快起來”： 1. 如果判斷前端流入數據量過大，**及時采用流處理范式過濾非重要數據**。 2. **通過預處理把數據分成適于快速處理的格式**。如谷歌大數據引擎 Dremel 就是把只讀的嵌套數據轉成類似于列式數據庫的形式，實現了 PB 級數據的秒級查詢。當然，也需要注意預處理需要消耗一定的資源。 3. 增量計算，**把重點放在新增的數據之上，先滿足“快”，抽空再把新數據更新回老的數據系統中**。谷歌的 Web 索引服務自2010年起從老的 MapReduce 批量系統升級成新的增量索引系統，就極大地縮短網頁被爬蟲爬到（新增數據）和被搜索到（產生大數據分析結果）之間的延遲。 4. **用內存計算（In-memory Comuputing）代替基于磁盤I/O的計算**。最簡單的就是內存緩存，復雜一點的涉及內存數據庫和分析平臺，比如伯克利的開源內存計算框架Spark，斯坦福的內存數據庫系統RAMCloud。未來隨著非易失性內存(斷電數據不會丟失)的成熟，內存計算會大行其道。 5. **降低精確性要求。大體量、精確性和快，三者最多得其二**。不能太貪心，將精確性控制在一定誤差范圍內，能夠滿足商業要求即可。 *** #### **參考材料** * 《大數據技術基礎》，林子雨 * 《人工智能和大數據的關系及中國在AI領域如何趕超世界》，鈦極客 * 《一張圖看懂AI與大數據》，中國科技網