通俗理解大資料及其應用價值

大資料概述

在大資料這個概念興起之前，資訊系統儲存資料的方法主要是我們熟知的關係型資料庫，關係型資料庫，關係型模型之父 Edgar F. Codd，在 1970 年 Communications of ACM 上發表了《大型共享資料庫資料的關係模型》的經典論文，從此之後關係模型的語義設計達到了 40 年來普世、易於理解，語法的巢狀，閉環，完整。關係型資料庫管理系統（RDBMS）就是基於關係模型在資料庫領域所構建的傳統資料庫管理工具，例如大名鼎鼎的Oracle、DB2、MySQL、PostgreSQL、SQLServer等。

作為早期的網際網路、電子政務、商業管理、工業製造等行業領域，首先每天產生的資料量並不大，而且以高價值的結構化資料為主，例如：早期網際網路Web1.0時代，一臺SQLServer資料庫就能支撐絕大多數的入口網站，一臺小機搭配Oracle就能輕鬆應對線上金融業務系統；其次資料訪問需求比較簡單，主要是業務資料模型之間的關聯設計，業務資料的插入、更新和刪除，對於更復雜的資料需求主要還是對欄位的分組查詢形成多維統計和明細下鑽。

但是這一切都被網際網路的發展所打破，尤其是到了2010年移動網際網路的爆發。大資料的名詞和概念隨著Google的定義席捲了全球，那麼大資料最基本的一個特徵就是資訊服務所接收到的資料請求量非常龐大，這對於傳統的RDBMS來講是衝擊性的，舉個例子：微博一個頂流明星關注的粉絲都是千萬級以上，若按照關係型資料庫的儲存與查詢方法來做一次明星內容推送，那麼就需要按照明星ID查詢到所有粉絲ID，給每個粉絲的關注者動態表增加一條明星新發布內容的ID，這對於關係型資料庫來講是極為恐怖的一次二級索引遍歷事件和索引構建事件，而這種事件在微博業務裡面每天都是高頻次產生，另外B樹索引會被千萬級的索引量撐大得特別寬，這種遍歷基本上就是瘋狂的IO掃描。那麼我們可以想象到，上億次的釋出，在成千上百億的資料量中不斷遍歷，再強悍的關係型資料庫都會瞬間崩潰。

上面主要提到的是網際網路大平臺的常見請求服務，資料庫對於海量資料進行索引請求操作的恐怖效能需求，那麼這些資料量在大資料概念興起之後的驟然劇增是什麼原因導致的呢？

主要因素就是網際網路越來越普及，被連線的資訊點越來越密，資訊的傳輸和交流變得越來越通暢，例如：早期的金融、保險、電信等資訊系統若要將資料彙集到管理中心，都是各個地區負責人對自身所轄資料庫進行檔案輸出，然後再將檔案定期上傳到中心，最後由中心管理員統一彙總，這種方式最大的問題就是資料延遲很大，提交的資料質量總會因為不統一的規範而導致參差不齊的質量，尤其是匯聚到中心的資料，儘管體量龐大，但是不具有從起點到終點的全過程設計，因此資料的應用程度很低，這就導致了資料倉儲變成了資料墳墓。

但是透過網際網路、移動化，現在大量的業務從源頭就開始了向一箇中心平臺服務的業務提交，資料匯聚，那麼資料就實時地流動起來了，每天形成了大量的資料業務儲存，這在金融、電信、保險、政府公共事業方面特別明顯，例如：我們曾經做過的稅務健康監測系統，每天都需要監測上百G的資料量，而這都是整個城市的公眾在一個稅務系統上進行稅務業務辦理所產生的龐大資料量，這就是大資料產生的一個重要因素。

大資料產生的另外一個因素就是城市基礎設施、人、水源河流、天氣環境、公路交通、工業裝置、機房等活動狀態可監測的物件，透過(生物)感測器、物聯網的技術手段，採集了大量基於時間線的感應資料，這些資料最大的特徵在於資料長期是穩定的走勢，但是恰恰不穩定的資料是需要被重點監測，以達到及時預防，防止故障與災難，因此我們可以理解這些資料大多數是低價值的，只有少量變異資料和具有挖掘出潛在關聯關係的資料卻又具有極高的價值，這個特色還特別體現在股票方面，例如：透過多支股票的走勢進行資料探勘，從它們的歷史峰值和谷底中找到相似性的走勢，再從相似性走勢中預測可能發生的機率。

大資料技術描述

我們在上面的概述中其實心裡就應該很清楚傳統RDBMS資料庫是難以支撐大資料場景，那麼到底有哪些技術屬於大資料技術，這些技術又起到什麼作用呢？

回答這個問題之前，我們需要先搞清楚解決大資料業務需要的流程和步驟，在這個問題上的複雜度已經遠遠超過了傳統資料庫處理的場景，我們上面提到過傳統資料庫主要就是支撐線上業務資料的查詢、寫入和更新，但是大資料業務需要考慮的主要流程就是：採集、資料流處理、資料管道、儲存、搜尋、挖掘分析、查詢服務和分析展示等

下圖是個比較典型的大資料採集、傳輸、儲存和分析的示意圖：

大資料計算流程示意圖

在大資料中非常重要起點就是對於資料的採集，一般大資料主流程不會直接從使用者端的請求服務中進行計算，我們將這個領域定位為OLTP，也就是由傳統資料庫或支撐海量資料寫入的NoSQL來完成，然後我們透過採集工具從RDBMS、檔案或NoSQL中進行採集同步，例如上圖中：利用CDC(資料變更捕獲)，我們可以從PostgreSQL的邏輯複製中捕獲WAL(預寫日誌檔案)的資料變更，然後將變更資料傳送到大資料平臺，也可以從檔案中採集獲取，常見的採集工具有ELK的Filebeat、Logstash採集檔案，Flume作為多源採集管道並整合HDFS，Canal採集MySQL Binlog，Flink CDC採集PostgresSQL WAL等。

資料流處理主要應用在資料傳輸實時性比較高的場景，我們常見的Flink、Storm、Spark Streaming都是為此場景而產生，在上圖中我們可以看到流處理管道，起到了資料傳輸過程中非常重要的資料轉換和資料寫入作用，它們還能在流傳輸的過程中進行流庫連線、流流連線進行二次加工，生成新的資料流，並在流轉的過程中進行實時資料取樣、過濾、轉換、封裝、清洗等多種實時處理操作。

資料流在中轉過程中往往需要緩衝進佇列，這在大資料的實時流處理中非常重要，例如：Kafka、RocketMQ，它們不僅形成了資料在上下游計算流轉過程中的資料持久化所帶來的資料可靠性，而且還能形成一對多的釋出與訂閱的扇形資料流轉結構，這樣就可以一個資料為多個計算服務所用，如上圖中變更佇列一方面可以由搜尋管道來訂閱，資料就流向了資料搜尋引擎，另一方面可以由分析管道來訂閱，資料流就流向了OLAP平臺，另外佇列保持了發生情況的前後一致性，那麼我們儲存的過程中就能輕鬆解決資料的時間線或事務問題。

大資料儲存需要根據資料所適用的場景進行多種情況的構建，如上圖中我們可以看到，若應用於搜尋場景，那麼最好的儲存就是搜尋引擎，例如：Elasticsearch、Solr，這些資料庫都是典型的文件型資料庫，基於文件樹的結構儲存，並對文件進行全文索引；若應用於OLAP場景，我們可以從圖中看到使用到了HBase分散式KV資料庫，它是完全遵循Google BigTable論文的開源實現，基於列簇格式儲存，行鍵排序，形成一個非常寬大的稀疏表，非常適合做線上統計處理和離線資料探勘。

例如：我們前面提到的微博問題，對於HBase來說，一個行鍵、兩個列簇、千萬級稀疏列，明星(行鍵)、粉絲集合（列簇）、粉絲（列）或者明星（行鍵）、釋出集合（列簇）、釋出微博（列），我們總能快速的透過明星ID，掃描他的粉絲集合，獲取千萬粉絲進行推送，粉絲也能透過明星ID，定位到他的微博釋出集合，快速找到最新發布的微博。這僅僅是面向高併發的實時聚合查詢的一個案例。

上圖中我們可以透過HBase完全承載PostgreSQL的結構化資料，還能透過資料管道結構化檔案資料，在HBase列簇中形成統一的資料結構，上圖的目的是從PostgreSQL中採集到車輛資料，檔案中採集到車輛執行中的座標資料，那麼HBase中就能以車輛資料為行鍵，座標資料為列簇與列，可以進一步分析不同時間點不同路段的擁堵情況。

同時我們從上圖中可以看到HBase只是分散式的資料庫引擎，真正資料落盤在了Hadoop HDFS，它是分散式檔案系統，基於Google GFS 論文的開源實現，提供了資料塊的高可靠儲存。

資料分析過程主要是分散式資料庫海量資料的批次資料探勘，我們往往需要一些支援MPP（大規模並行處理）的分散式計算框架來解決，例如：Spark、MapReduce、Tez、Hive、Presto等。這些處理引擎主要是以叢集化的分散式平行計算將資料切分成多工來解決，這樣再超大規模的資料集合都可以被更多的計算節點切分而快速完成。

那麼基於Spark的這樣的大資料技術棧進行預測分析，就有了Spark MLlib這樣的機器學習模型庫，例如：我們要透過對一組海量進行一項顧客風險評測訓練，預測某一位顧客購買某項保險項未來出現賠付的機率，那麼就能透過MLlib的DecisionTree(決策樹)演算法，不斷調整訓練引數，去熵提純集合，找到最佳的預測模型。

總結

作為大資料的應用與價值非常廣泛，我們上面只是大資料整個生態體系的冰山一角，比如說：透過對廣告投放資料的採集並寫入時序資料庫(TSDB)，我們可以非常快速地在每秒百億次的點選中，分析出每分鐘每個投放網站的收益，投放平臺為每個廣告顧客創造的投放次數、展示次數、廣告瀏覽時長等；

再比如說：我們透過日誌資料跟蹤，能將上千臺伺服器的日誌進行分散式Track，那麼我就能實時分析出一筆業務需要經歷多少臺伺服器，經歷了多少服務轉發，在哪些服務上出現了延時，從而達到快速運維感知，尤其是面向公共事業、網際網路電商、網際網路金融無法容忍分鐘級的故障導致的系統不可用，實時運維感知的作用就是剛性需求。

談到信用卡機構、銀行、保險行業，最重要的一項分析就是對顧客群體的預測分析，這在防欺詐、信用評級、貸款方面可以說大資料應用起到了無可替代的作用，我們需要透過資料探勘、機器學習，將碎片化的不同資料集合，進行蒐集、清洗、完善，建立資料分析演算法模型，不斷透過對海量資料的分析，引數最佳化，從資料中發現隱藏的關係，預測個體行為機率。

---

A Relational Model of Data for Large Shared Data Banks

論文下載連結：

~zives/03f/cis550/codd.pdf

Bigtable: A Distributed Storage System for Structured Data

論文下載連結：

The Google File System

論文下載連結：