大數據概述 在大數據這個概念興起之前,信息系統存儲數據的方法主要是我們熟知的關係型資料庫,關係型資料庫,關係型模型之父 Edgar F. Codd,在 1970 年 Communications of ACM 上發表了《大型共用資料庫數據的關係模型》的經典論文,從此之後關係模型的語義設計達到了 4 ...
大數據概述
在大數據這個概念興起之前,信息系統存儲數據的方法主要是我們熟知的關係型資料庫,關係型資料庫,關係型模型之父 Edgar F. Codd,在 1970 年 Communications of ACM 上發表了《
作為早期的互聯網、電子政務、商業管理、工業製造等行業領域,首先每天產生的數據量並不大,而且以高價值的結構化數據為主,例如:早期互聯網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,那麼我就能實時分析出一筆業務需要經歷多少台伺服器,經歷了多少服務轉發,在哪些服務上出現了延時,從而達到快速運維感知,尤其是面向公共事業、互聯網電商、互聯網金融無法容忍分鐘級的故障導致的系統不可用,實時運維感知的作用就是剛性需求。
談到信用卡機構、銀行、保險行業,最重要的一項分析就是對顧客群體的預測分析,這在防欺詐、信用評級、貸款方面可以說大數據應用起到了無可替代的作用,我們需要通過數據挖掘、機器學習,將碎片化的不同數據集合,進行搜集、清洗、完善,建立數據分析演算法模型,不斷通過對海量數據的分析,參數優化,從數據中發現隱藏的關係,預測個體行為概率。
本文來自博客園,作者:守護石,轉載請註明原文鏈接:https://www.cnblogs.com/readbyte/p/16246786.html