后Hadoop時代的大數據架構

b77m 9年前發布 | 140K 次閱讀 Hadoop 分布式/云計算/大數據

提 到大數據分析平臺,不得不說Hadoop系統,Hadoop到現在也超過10年的歷史了,很多東西發生了變化,版本也從0.x進化到目前的2.6版本。我 把2012年后定義成后Hadoop平臺時代,這不是說不用Hadoop,而是像NoSQL (Not Only SQL)那樣,有其他的選型補充。我在知乎上也寫過Hadoop的一些入門文章 如何學習Hadoop - 董飛的回答,為了給大家有個鋪墊,簡單講一些相關開源組件。

背景篇

  • Hadoop: 開源的數據分析平臺解決了大數據(大到一臺計算機無法進行存儲,一臺計算機無法在要求的時間內進行處理)的可靠存儲和處理。適合處理非結構化數據,包括HDFS,MapReduce基本組件。
  • HDFS:提供了一種跨服務器的彈性數據存儲系統。
  • MapReduce:技術提供了感知數據位置的標準化處理流程:讀取數據,對數據進行映射(Map),使用某個鍵值對數據進行重排,然后對數據進行化簡(Reduce)得到最終的輸出。
  • Amazon Elastic Map Reduce(EMR): 托管的解決方案,運行在由Amazon Elastic Compute Cloud(EC2)和Simple Strorage Service(S3)組成的網絡規模的基礎設施之上。如果你需要一次性的或不常見的大數據處理,EMR可能會為你節省開支。但EMR是高度優化成與S3 中的數據一起工作,會有較高的延時。
  • Hadoop 還包含了一系列技術的擴展系統,這些技術主要包括了Sqoop、Flume、Hive、Pig、Mahout、Datafu和HUE等。
    • Pig:分析大數據集的一個平臺,該平臺由一種表達數據分析程序的高級語言和對這些程序進行評估的基礎設施一起組成。
    • Hive:用于Hadoop的一個數據倉庫系統,它提供了類似于SQL的查詢語言,通過使用該語言,可以方便地進行數據匯總,特定查詢以及分析存放在Hadoop兼容文件系統中的大數據。
    • Hbase:一種分布的、可伸縮的、大數據儲存庫,支持隨機、實時讀/寫訪問。
    • Sqoop:為高效傳輸批量數據而設計的一種工具,其用于Apache Hadoop和結構化數據儲存庫如關系數據庫之間的數據傳輸。
    • Flume:一種分布式的、可靠的、可用的服務,其用于高效地搜集、匯總、移動大量日志數據。
    • ZooKeeper:一種集中服務,其用于維護配置信息,命名,提供分布式同步,以及提供分組服務。
    • </ul>

    • Cloudera:最成型的Hadoop發行版本,擁有最多的部署案例。提供強大的部署、管理和監控工具。開發并貢獻了可實時處理大數據的Impala項目。
    • Hortonworks:使用了100%開源Apache Hadoop提供商。開發了很多增強特性并提交至核心主干,這使得Hadoop能夠在包括Windows Server和Azure在內平臺上本地運行。
    • MapR:獲取更好的性能和易用性而支持本地Unix文件系統而不是HDFS。提供諸如快照、鏡像或有狀態的故障恢復等高可用性特性。領導著Apache Drill項目,是Google的Dremel的開源實現,目的是在Hadoop數據上執行類似SQL的查詢以提供實時處理。
    • </ul>

      原理篇

      數據存儲

      我們的目標是做一個可靠的,支持大規模擴展和容易維護的系統。計算機里面有個locality(局部性定律),如圖所示。從下到上訪問速度越來越快,但存儲代價更大。后Hadoop時代的大數據架構

      相 對內存,磁盤和SSD就需要考慮數據的擺放, 因為性能會差異很大。磁盤好處是持久化,單位成本便宜,容易備份。但隨著內存便宜,很多數據集合可以考慮直接放入內存并分布到各機器上,有些基于 key-value, Memcached用在緩存上。內存的持久化可以通過 (帶電池的RAM),提前寫入日志再定期做Snapshot或者在其他機器內存中復制。當重啟時需要從磁盤或網絡載入之前狀態。其實寫入磁盤就用在追加日 志上面 ,讀的話就直接從內存。像VoltDB, MemSQL,RAMCloud 關系型又基于內存數據庫,可以提供高性能,解決之前磁盤管理的麻煩。

      后Hadoop時代的大數據架構

      HyperLogLog & Bloom Filter & CountMin Sketch

      都 是是應用于大數據的算法,大致思路是用一組相互獨立的哈希函數依次處理輸入。HyperLogLog 用來計算一個很大集合的基數(即合理總共有多少不相同的元素),對哈希值分塊計數:對高位統計有多少連續的0;用低位的值當做數據塊。 BloomFilter,在預處理階段對輸入算出所有哈希函數的值并做出標記。當查找一個特定的輸入是否出現過,只需查找這一系列的哈希函數對應值上有沒 有標記。對于BloomFilter,可能有False Positive,但不可能有False Negative。BloomFilter可看做查找一個數據有或者沒有的數據結構(數據的頻率是否大于1)。CountMin Sketch在BloomFilter的基礎上更進一步,它可用來估算某一個輸入的頻率(不局限于大于1)。

      CAP Theorem

      后Hadoop時代的大數據架構簡單說是三個特性:一致性,可用性和網絡分區,最多只能取其二。設計不同類型系統要多去權衡。分布式系統還有很多算法和高深理論,比如:Paxos算法( paxos分布式一致性算法--講述諸葛亮的反穿越),Gossip協議( Cassandra學習筆記之Gossip協議), Quorum (分布式系統)時間邏輯,向量時鐘( 一致性算法之四: 時間戳和向量圖), 拜占庭將軍問題二階段提交等,需要耐心研究。

      技術篇

      后Hadoop時代的大數據架構

      來自:http://thinkbig.teradata.com/leading_big_data_technologies/big-data-reference-architecture/

      根據不同的延遲要求(SLA),數據量存儲大小, 更新量多少,分析需求,大數據處理的架構也需要做靈活的設計。上圖就描述了在不同領域中大數據組件。

      說大數據的技術還是要先提Google,Google 新三輛馬車,Spanner, F1, Dremel

      Spanner高可擴展、多版本、全球分布式外加同步復制特性的谷歌內部數據庫,支持外部一致性的分布式事務;設計目標是橫跨全球上百個數據中心,覆蓋百萬臺服務器,包含萬億條行記錄!(Google就是這么霸氣^-^)

      F1: 構建于Spanner之上,在利用Spanner的豐富特性基礎之上,還提供分布式SQL、事務一致性的二級索引等功能,在AdWords廣告業務上成功代替了之前老舊的手工MySQL Shard方案。

      Dremel: 一種用來分析信息的方法,它可以在數以千計的服務器上運行,類似使用SQL語言,能以極快的速度處理網絡規模的海量數據(PB數量級),只需幾秒鐘時間就能完成。

      Spark

      后Hadoop時代的大數據架構

      2014年最火的大數據技術Spark,有什么關于 Spark 的書推薦? - 董飛的回答 做了介紹。主要意圖是基于內存計算做更快的數據分析。同時支持圖計算,流式計算和批處理。Berkeley AMP Lab的核心成員出來成立公司Databricks開發Cloud產品。

      Kafka

      后Hadoop時代的大數據架構

      Announcing the Confluent Platform 1.0 Kafka 描述為 LinkedIn 的“中樞神經系統”,管理從各個應用程序匯聚到此的信息流,這些數據經過處理后再被分發到各處。不同于傳統的企業信息列隊系統,Kafka 是以近乎實時的方式處理流經一個公司的所有數據,目前已經為 LinkedIn, Netflix, Uber 和 Verizon 建立了實時信息處理平臺。Kafka 的優勢就在于近乎實時性。

      Storm

      后Hadoop時代的大數據架構Handle Five Billion Sessions a Day in Real Time,推ter的實時計算框架。所謂流處理框架,就是一種分布式、高容錯的實時計算系統。Storm令持續不斷的流計算變得容易。經常用于在實時分析、在線機器學習、持續計算、分布式遠程調用和ETL等領域。

      Samza

      后Hadoop時代的大數據架構

      LinkedIn主推的流式計算框架。與其他類似的Spark,Storm做了幾個比較。跟Kafka集成良好,作為主要的存儲節點和中介。

      Lambda architecture

      Nathan寫了文章《如何去打敗CAP理論》How to beat the CAP theorem,提出Lambda Architecture,主要思想是對一些延遲高但數據量大的還是采用批處理架構,但對于即時性實時數據使用流式處理框架,然后在之上搭建一個服務層去合并兩邊的數據流,這種系統能夠平衡實時的高效和批處理的Scale,看了覺得腦洞大開,確實很有效,被很多公司采用在生產系統中。

      后Hadoop時代的大數據架構Summingbird

      Lambda架構的問題要維護兩套系統,推ter開發了Summingbird來做到一次編程,多處運行。將批處理和流處理無縫連接,通過整合批處理與流處理來減少它們之間的轉換開銷。下圖就解釋了系統運行時。

      后Hadoop時代的大數據架構

      NoSQL

      數 據傳統上是用樹形結構存儲(層次結構),但很難表示多對多的關系,關系型數據庫就是解決這個難題,最近幾年發現關系型數據庫也不靈了,新型NoSQL出現 如Cassandra,MongoDB,Couchbase。NoSQL 里面也分成這幾類,文檔型,圖運算型,列存儲,key-value型,不同系統解決不同問題。沒一個one-size-fits-all 的方案。

      后Hadoop時代的大數據架構

      Cassandra

      大數據架構中,Cassandra的主要作用就是存儲結構化數據。DataStax的Cassandra是一種面向列的數據庫,它通過分布式架構提供高可用性及耐用性的服務。它實現了超大規模的集群,并提供一種稱作“最終一致性”的一致性類型,這意味著在任何時刻,在不同服務器中的相同數據庫條目可以有不同的值。

      SQL on Hadoop

      開源社區業出現了很多 SQL-on-Hadoop的項目,著眼跟一些商業的數據倉庫系統競爭。包括Apache Hive, Spark SQL, Cloudera Impala, Hortonworks Stinger, 非死book Presto, Apache Tajo,Apache Drill。有些是基于Google Dremel設計。

      Impala

      Cloudera公司主導開發的新型查詢系統,它提供SQL語義,能夠查詢存儲在Hadoop的HDFS和HBase中的PB級大數據,號稱比Hive快5-10倍,但最近被Spark的風頭給罩住了,大家還是更傾向于后者。

      Drill

      Apache社區類似于Dremel的開源版本—Drill。一個專為互動分析大型數據集的分布式系統。

      Druid

      在大數據集之上做實時統計分析而設計的開源數據存儲。這個系統集合了一個面向列存儲的層,一個分布式、shared-nothing的架構,和一個高級的索引結構,來達成在秒級以內對十億行級別的表進行任意的探索分析。

      Berkeley Data Analytics Stack

      后Hadoop時代的大數據架構

      上面說道Spark,在Berkeley AMP lab 中有個更宏偉的藍圖,就是BDAS,里面有很多明星項目,包括

      Mesos:一個分布式環境的資源管理平臺,它使得Hadoop、MPI、Spark作業在統一資源管理環境下執行。它對Hadoop2.0支持很好。推ter,Coursera都在使用。

      Tachyon:是一個高容錯的分布式文件系統,允許文件以內存的速度在集群框架中進行可靠的共享,就像Spark和MapReduce那樣。有幸跟項目發起人李浩源聊過幾次,這個項目目前發展非常快,甚至比Spark當時還要驚人。目前到0.6版本,參與開源的規模和版本迭代速度都很快。

      BlinkDB:也很有意思,在海量數據上運行交互式 SQL 查詢的大規模并行查詢引擎。它允許用戶通過權衡數據精度來提升查詢響應時間,其數據的精度被控制在允許的誤差范圍內。

      Cloudera

      后Hadoop時代的大數據架構

      Hadoop老大哥提出的經典解決方案。

      HDP (Hadoop Data Platform)

      后Hadoop時代的大數據架構

      Hortonworks 提出的架構選型。

      Redshift

      后Hadoop時代的大數據架構Amazon RedShift是 ParAccel一個版本。它是一種(massively parallel computer)架構,是非常方便的數據倉庫解決方案,SQL接口,跟各個云服務無縫連接,最大特點就是快,在TB到PB級別非常好的性能,我在工作中 也是直接使用,它還支持不同的硬件平臺,如果想速度更快,可以使用SSD。

      Netflix

      后Hadoop時代的大數據架構

      完全基于AWS的數據處理解決方案。

      Intel

      后Hadoop時代的大數據架構

      創業公司篇

      這里的公司非常多,留作下一篇慢慢介紹吧

      參考鏈接

      The Hadoop Ecosystem Table

      How to beat the CAP theorem

      Lambda Architecture

      Questioning the Lambda Architecture

      來自

 本文由用戶 b77m 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!