大數據技術1：大數據發展簡史

前言：學習大數據技術，知道會用已經夠了，但是要想走得更遠，應該了解它發展的來龍去脈，為何會有新的技術/工具的出現，相比老的技術有什么樣的進步。

1、傳統數據處理系統存在的問題

隨著信息時代互聯網技術爆炸式的發展，人們對于網絡的依賴程度日漸加深，在業務中需要處理的數據量快速增加，逐漸飆升到了一個驚人的數量級。并且數據產生的速度隨著采集與處理技術的更新仍在加快。

數據量從兆字節(MB)、吉字節 (GB) ?的級別到現在的太字節 (TB)、柏?字?節?(PB) ?級別，數據量的變化促使數據管理系統?(DBMS) ?和數據倉庫?(Data??Warehouse,DW)?系統也在悄然地變化著。傳統應用的數據系統架構設計時，應用直接訪問數據庫系統。當用戶訪問量增加時，數據庫無法支撐日益增長的用戶請求的負載，從而導致數據庫服務器無法及時響應用戶于數據修改的請求時，就需要增加多個工作處理層并發執行，數據庫又將再次成為響應請求的瓶頸。一個解決辦法是對數據庫進行分區 (Horizontal??Partitioning)。分區的方式通常以?Hash?值作為?key?。這樣就需要應用程序端知道如何去尋找每個key?所在的分區。

但即便如此，問題仍然會隨著用戶請求的增加接踵而來。當之前的分區無法滿足負載時，?就需要增加更多分區，這時就需要對數據庫進行reshard?。resharding?的工作非常耗時而痛苦，因?為需要協調很多工作，例如數據的遷移、更新客戶端訪問的分區地址，更新應用程序代碼。如果系統本身還提供了在線訪問服務，對運維的要求就更高。這種情況下，就可能導致數據寫到錯誤的分區，因此必須要編寫腳本來自動完成，且需要充分的測試。

由此可見，在數據層和應用中增加了緩沖隔離，數據量的日漸增多仍然迫使傳統數據倉庫的開發者一次又一次挖掘系統，試圖在各個方面尋找一點可提升的性能。架構變得越來越復雜，?增加了隊列、分區、復制、重分區腳本?(Resharding??Scripts)。應用程序還需要了解數據庫的?schema,?并能訪問到正確的分區。問題在于：數據庫對于分區是不了解的，無法幫助你應對分?區、復制與分布式查詢。

最嚴重的問題是系統并沒有對人為錯誤進行工程設計，僅靠備份是不能治本的。歸根結底，?系統還需要限制因為人為錯誤導致的破壞。然而，數據永不止步，傳統架構的性能被壓榨至極?限，檢索數據的延遲和頻繁的硬件錯誤問題逐漸使用戶不可接受，在傳統架構上進行繼續挖掘被證明是“擠牙膏”。幫助處理海量數據的新技術和新架構開發被提上日程，以求得讓企業在現代競爭中占得先機。越來越多的開發者參與到新技術與新架構的研究探討中，結論與成果逐漸豐碩。人們發現，當系統的用戶訪問量持續增加時，就需要考慮讀寫分離技術?(Master-Slave)和分庫分表技術。常見讀寫分離技術架構如上圖所示。

現在，數據處理系統的架構變得越來越復雜了，相比傳統的數據庫，?一次數據處理的過程增加了隊列、分區、復制等處理邏輯。應用程序不僅僅需要了解數據的存儲位置，還需要了解數據庫的存儲格式、數據組織結構?(schema) ???等信息，才能訪問到正確的數據。

隨著技術的不斷發展，商業現實也發生了變化。除了要求同一時間內可以處理的數據量提?升，現代商業要求更快做出的決定更有價值。現在，Kafka、Storm、Trident、Samza、Spark、?Flink?、Parquet?、Avro?、Cloud???????providers?等新技術成為了工程師和企業廣泛采用的流行語。基于新技術，不少企業開發了自己的數據處理方式，現代基于Hadoop??的?Map/Reduce?管?道 (?使?用?Kafka,Avro?和數據倉庫等現代二進制格式，即?Amazon??Redshift,用于臨時查詢)采用了?如圖所示。

這個方式雖然看起來有其非常好的優勢，但它仍然是一種傳統的批處理方式，具有所有已知的缺點，主要原因是客戶端的數據在批處理花費大量時間完成之前的數據處理時，新的數據已經進入而導致數據過時。

基于傳統系統出現的上述問題和無數人對于新技術的渴求與探討，“大數據”的概念被適時?的提出，研究與設計大數據系統成為了新的風潮。我們要學習的大數據系統架構設計理論，正是為了解決在處理海量數據時出現的種種問題，并讓系統在一定的度量屬性下可以接受，成為構造大數據系統的良好范式。

2、大數據處理系統架構分析

2.1??大數據處理系統面臨挑戰

當今，大數據的到來，已經成為現實生活中無法逃避的挑戰。每當我們要做出決策的時候，?大數據就無處不在。大數據術語廣泛地出現也使得人們漸漸明白了它的重要性。大數據漸漸向人們展現了它為學術、工業和政府帶來的巨大機遇。與此同時，大數據也向參與的各方提出了巨大的挑戰。那么主要挑戰表現在以下三點。

（1）如何利用信息技術等手段處理非結構化和半結構化數據

大數據中，結構化數據只占15%左右，其余的85%都是非結構化的數據，它們大量存在于社交網絡、互聯網和電子商務等領域。另一方面，也許有90%的數據來自開源數據，其余的被存儲在數據庫中。大數據的不確定性表現在高維、多變和強隨機性等方面。股票交易數據流是不確定性大數據的一個典型例子。

大數據催生了大量研究問題。非結構化和半結構化數據的個體表現、?一般性特征和基本原理尚不清晰，這些都需要通過包括數學、經濟學、社會學、計算機科學和管理科學在內的多學科交叉來研究和討論。給定一種半結構化或非結構化數據，比如圖像，如何把它轉換成多維數據表、面向對象的數據模型或者直接基于圖像的數據模型。值得注意的是，大數據每一種表示形式都僅為數據本身的一個側面表現，并非全貌。

如果把通過數據挖掘提取“粗糙知識”的過程稱為“一次挖掘”過程，那么將粗糙知識與被化后主觀知識，包括具體的經驗、常識、本能、情境知識和用戶偏好，相結合而產生“智能?知識”過程就叫作“二次挖掘”。從“一次挖掘”到“二次挖掘”,就類似于事物由“量”到?“質”的飛躍。

由于大數據所具有的半結構化和非結構化特點，基于大數據的數據挖掘所產生的結構化的?“粗糙知識”(潛在模式)也伴有一些新的特征。這些結構化的粗糙知識可以被主觀知識加工處?理并轉化，生成半結構化和非結構化的智能知識。尋求“智能知識”反映了大數據研究的核心?價值。

（2）如何探索大數據復雜性、不確定性特征描述的刻畫方法及大數據的系統建模

這一問題的突破是實現大數據知識發現的前提和關鍵。從長遠角度來看，依照大數據的個體復雜性和隨機性所帶來的挑戰將促使大數據數學結構的形成，從而促使大數據統一理論日趨?完備。從短期而言，學術界鼓勵發展一種一般性的結構化數據和半結構化、非結構化數據之間?的轉換原則，以支持大數據的交叉工業應用。管理科學，尤其是基于最優化的理論將在大數據?知識發現的一般性方法和規律性的研究中發揮重要的作用。

大數據的復雜形式導致許多對“粗糙知識”的度量和評估相關的研究問題。已知的最優?化、數據包絡分析、期望理論、管理科學中的效用理論可以被應用到研究如何將主觀知識?融合到數據挖掘產生的粗糙知識的“二次挖掘”過程中。這里人機交互將起到至關重要的?作用。

（3）數據異構性與決策異構性的關系對大數據知識發現與管理決策的影響

由于大數據本身的復雜性，這一問題無疑是一個重要的科研課題，對傳統的數據挖掘理論和技術提出了新的挑戰。在大數據環境下，管理決策面臨著兩個“異構性”問題：“數據異構性”?和“決策異構性”。傳統的管理決策模式取決于對業務知識的學習和日益積累的實踐經驗，而管???理決策又是以數據分析為基礎的。

大數據已經改變了傳統的管理決策結構的模式。研究大數據對管理決策結構的影響會成為一個公開的科研問題。除此之外，決策結構的變化要求人們去探討如何為支持更高層次的決策?而去做“二次挖掘”。無論大數據帶來了哪種數據異構性，大數據中的“粗糙知識”仍可被看作?“一次挖掘”的范疇。通過尋找“二次挖掘”產生的“智能知識”來作為數據異構性和決策異構性?之間的橋梁是十分必要的。探索大數據環境下決策結構是如何被改變的，相當于研究如何將決?策者的主觀知識參與到決策的過程中。

大數據是一種具有隱藏法則的人造自然，尋找大數據的科學模式將帶來對研究大數據之美?的一般性方法的探究，盡管這樣的探索十分困難，但是如果我們找到了將非結構化、半結構化?數據轉換成結構化數據的方法，已知的數據挖掘方法將成為大數據挖掘的工具。

2.2??大數據處理系統架構特征

Storm?之父Nathan?Marz?在《大數據系統構建：可擴展實時數據系統構建原理與最佳實踐》?一書中，提出了他認為大數據系統應該具有的屬性。

（1）魯棒性和容錯性(Robust?and?Fault-tolerant?)

對大規模分布式系統來說，機器是不可靠的，可能會宕機，但是系統需要是健壯、行為正確的，即使是遇到機器錯誤。除了機器錯誤，人更可能會犯錯誤。在軟件開發中難免會有一些Bug, ??系統必須對有Bug?的程序寫入的錯誤數據有足夠的適應能力，所以比機器容錯性更加重要的容錯性是人為操作容錯性。對于大規模的分布式系統來說，人和機器的錯誤每天都可能會發生，如何應對人和機器的錯誤，讓系統能夠從錯誤中快速恢復尤其重要。

（2）低延遲讀取和更新能力?(Low?Latency?Reads?and?Updates)

許多應用程序要求數據系統擁有幾毫秒到幾百毫秒的低延遲讀取和更新能力。有的應用程序允許幾個小時的延遲更新，但是只要有低延遲讀取與更新的需求，系統就應該在保證魯棒性的前提下實現。

（3）橫向擴容?(Scalable)

當數據量/負載增大時，可擴展性的系統通過增加更多的機器資源來維持性能。也就是常說的系統需要線性可擴展，通常采用scale out(通過增加機器的個數)而不是?scale up?(通過增?強機器的性能)。

（4）通用性(General)

系統需要支持絕大多數應用程序，包括金融領域、社交網絡、電子商務數據分析等。

（5）延展性(Extensible)

在新的功能需求出現時，系統需要能夠將新功能添加到系統中。同時，系統的大規模遷移?能力是設計者需要考慮的因素之一，這也是可延展性的體現。

（6）即席查詢能力?(Allows?Ad?Hoc?Queries)

用戶在使用系統時，應當可以按照自己的要求進行即席查詢(Ad過系統多樣化數據處理，產生更高的應用價值。

（7）最少維護能力(Minimal???Maintenance)

系統需要在大多數時間下保持平穩運行。使用機制簡單的組件和算法讓系統底層擁有低復?雜度，是減少系統維護次數的重要途徑。Marz?認為大數據系統設計不能再基于傳統架構的增量?更新設計，要通過減少復雜性以減少發生錯誤的幾率、避免繁重操作。

（8）可調試性?(Debuggable)

系統在運行中產生的每一個值，需要有可用途徑進行追蹤，并且要能夠明確這些值是如何?產生的。

3、大數據技術發展簡史

3.1、大數據技術的起源（大數據的三駕馬車）

大數據最早是起源于google。大家都知道google主要是提供網頁檢索服務，而這項服務依賴兩個能力：網頁的收集，索引的構建。有了這兩個能力，我們才能通過檢索服務搜索到互聯網上的網頁。這些網頁和索引都需要大量的存儲和計算能力。為了提高這兩個能力，谷歌發表了三篇重要的論文。

2003年，分布式文件系統GFS。
2004年，大數據分布式計算框架MapReduce。
2006年，NoSql數據庫系統BigTable。

這三篇論文奠定了大數據技術的基礎，也就是我們經常說的大數據得三駕馬車。一個是文件系統，一個是計算框架，一個是數據庫系統，當時Google發表的論文讓業界沸騰，從此開啟了大數據時代。在那之前，大多數公司其實還是聚焦在單機上，在思考如何提升單機的性能，尋找更貴更好的服務器。而 Google 的思路是部署一個大規模的服務器集群，通過分布式的方式將海量數據存儲在這個集群上，然后利用集群上的所有機器進行數據計算。這樣，Google 其實不需要買很多很貴的服務器，它只要把這些普通的機器組織到一起，就能夠進行大規模的計算了。

3.2、Hadoop的誕生（分布式數據存儲和計算的框架）

Lucene開源項目創始人Doug Cutting正在開發開源搜索引擎Nutch，閱讀了Google的論文后，根據論文原理實現了類似GFS和MapReduce的功能。3年后也就是2006年，Doug Cutting將這些大數據相關的功能從Nutch中分離了出來，然后啟動了一個獨立的項目專門開發和維護大數據技術，這就是后來赫赫有名的Hadoop，主要包括 Hadoop 分布式文件系統 HDFS 和大數據計算引擎 MapReduce。

大家看Hadoop的源碼就會發現，這個用純Java實現的軟件沒有什么特別之處，誕生它給社會帶來了巨大的影響，甚至帶動了一場深刻的科技革命，推動了人工智能的發展和進步。

Hadoop發布以后，Yahoo開始使用起來，2007年百度和阿里也開始使用Hadoop進行大數據存儲和計算。2008年Hadoop成為Apache頂級項目。

3.3、Yahoo的Pig

2006年，Yahoo覺得用MapReduce進行大數據編程太麻煩了，于是開發了Pig腳本語言，類似SQL語法，Pig經過編譯后生成MapReduce程序，在Hadoop上運行，大大優化了MapReduce的使用難度。

3.4、Facebook的Hive（Hadoop數據倉庫工具）

2007年，編寫Pig雖然比MapReduce編程簡單，但是還是要學習。于是Facebook發布了Hive，支持使用SQL語法進行大數據計算，寫個Select語句進行數據查詢，Hive會將SQL語句轉化成

MapReduce計算程序。這樣，熟悉數據庫的數據分析師和工程師便可以無門檻地使用大數據進行數據分析和處理了，Hive出現后大大降低了Hadoop的使用難度，迅速得到開發者和企業的追捧。

眾多Hadoop產品開始出現，包括：專門將關系數據庫中的數據導入導出到 Hadoop 平臺的 Sqoop；針對大規模日志進行分布式收集、聚合和傳輸的 Flume；MapReduce 工作流調度引擎 Oozie 等。

?Hive是基于Hadoop的一個數據倉庫工具，用來進行數據提取、轉化、加載，這是一種可以存儲、查詢和分析存儲在Hadoop中的大規模數據的機制。hive數據倉庫工具能將結構化的數據文件映射為一張數據庫表，并提供SQL查詢功能，能將SQL語句轉變成MapReduce任務來執行。Hive的優點是學習成本低，可以通過類似SQL語句實現快速MapReduce統計，使MapReduce變得更加簡單，而不必開發專門的MapReduce應用程序。hive十分適合對數據倉庫進行統計分析。?

3.5、Powerset的HBASE（NoSQL列式數據庫）

2007年Powerset的工作人員，通過google的論文開發出了BigTable的java版本，即HBASE。2008年HBASE貢獻給了Apache。

3.6、Yarn的誕生（大數據資源調度框架）

Hadoop 早期，MapReduce 既是一個執行引擎，又是一個資源調度框架，服務器集群的資源調度管理由 MapReduce 自己完成。但是這樣不利于資源復用，也使得 MapReduce 非常臃腫。于是一個新項目啟動了，將 MapReduce 執行引擎和資源調度分離開來，這就是 Yarn大數據資源調度框架。

3.7、Spark的誕生（批處理計算引擎）

2012 年，UC 伯克利 AMP 實驗室開發的 Spark 開始嶄露頭角，馬鐵博士發現使用 MapReduce 進行機器學習計算的時候性能非常差，因為機器學習算法通常需要進行很多次的迭代計算，而 MapReduce 每執行一次 Map 和 Reduce 計算都需要重新啟動一次作業，帶來大量的無謂消耗，影響執行效率。

MapReduce 主要使用磁盤作為存儲介質，而 2012 年的時候，內存已經突破容量和成本限制，成為數據運行過程中主要的存儲介質。Spark 一經推出，立即受到業界的追捧，并逐步替代MapReduce 在企業應用中的地位。

3.8、大數據批處理和流處理

（1）批處理（大數據離線計算）

像 MapReduce、Spark 這類計算框架處理的業務場景都被稱作批處理計算，通常按天或者固定時間段，進行一次計算，計算的數據是歷史數據，也稱為大數據離線計算。

（2）流處理（大數據實時計算）

還有一種場景，需要對實時產生的大量數據進行即時計算，例如人臉識別，這類計算稱為大數據流計算，對應的有Storm、Flink、Spark Streaming 等流計算框架來滿足此類大數據應用的場景，這類計算也稱為大數據實時計算。

3.9. NoSQL

NoSQL 曾經在 2011 年左右非常火爆，涌現出 HBase、Cassandra 等許多優秀的產品，其中 HBase 是從 Hadoop 中分離出來的、基于 HDFS 的 NoSQL 系統。

4、?OLTP和OLTP區別

（1）OLTP 聯機事務處理

為了保證對業務的快速響應和支持，針對產品和業務功能有一個直接的數據庫與之進行交互。

OLTP（OnLine Transaction Processsing 聯機事務處理）是與功能、業務強相關的事務查詢系統，要保證高并發場景下低時延的查詢和處理效率，因此對CPU的性能要求較高。直接存儲與功能和業務直接相關的地方，就叫數據庫，一般是服務端開發的同事來負責。

如上提到，數據庫主要為在線業務服務。如果是分析場景需要查詢數據，涉及到從業務數據庫取數據，就意味著會影響業務數據庫對業務的支持。量小還好，量大或者查詢比較復雜，服務端的同事就會擔心影響到線上業務，或者把業務數據庫查“崩”了影響線上業務，因此非常nice地拒絕你的需求。所以企業在經過初期的市場驗證階段后，會開始尋求從數據中找到下一步發展的方向，直接從業務數據庫獲取數據限制頗多，因此這時候就需要搭建數據倉庫體系了。

（2）OLAP（OnLine Analytical Processing聯機分析處理）

數據倉庫是獨立于業務數據庫之外的一套數據存儲體系，OLAP（OnLine Analytical Processing聯機分析處理）是數據倉庫系統的主要應用，能夠支持復雜的分析操作，與數據庫需要直接直接線上業務不同，數據倉庫側重于分析決策，提供直觀的數據查詢結果。（當然數據倉庫也是可以支持線上業務的，下面會提到）。