後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的查詢語言，通過使用該語言，可以方便地進行數據匯總，特定查詢以及分析。
• Hbase：一種分布的、可伸縮的、大數據儲存庫，支持隨機、實時讀/寫訪問。
• Sqoop：為高效傳輸批量數據而設計的一種工具，其用於Apache Hadoop和結構化數據儲存庫如關係資料庫之間的數據傳輸。
• Flume：一種分散式的、可靠的、可用的服務，其用於高效地搜集、匯總、移動大量日誌數據。
• ZooKeeper：一種集中服務，其用於維護配置信息，命名，提供分散式同步，以及提供分組服務。
• Cloudera：最成型的Hadoop發行版本，擁有最多的部署案例。提供強大的部署、管理和監控工具。開發並貢獻了可實時處理大數據的Impala項目。
• Hortonworks：使用了100%開源Apache Hadoop提供商。開發了很多增強特性並提交至核心主幹，這使得Hadoop能夠在包括Windows Server和Azure在內平台上本地運行。
• MapR：獲取更好的性能和易用性而支持本地Unix文件系統而不是HDFS。提供諸如快照、鏡像或有狀態的故障恢復等高可用性特性。領導著Apache Drill項目，是Google的Dremel的開源實現，目的是執行類似SQL的查詢以提供實時處理。

原理篇

數據存儲

我們的目標是做一個可靠的，支持大規模擴展和容易維護的系統。計算機裡面有個locality（局部性定律），如圖所示。從下到上訪問速度越來越快，但存儲代價更大。

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

HyperLogLog & Bloom Filter & CountMin Sketch

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

CAP Theorem

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

技術篇

來自：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

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

Flink

使用了一種類似於SQL資料庫查詢優化的方法，這也是它與當前版本的Apache Spark的主要區別。它可以將全局優化方案應用於某個查詢之上以獲得更佳的性能。

Kafka

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

Storm

Handle Five Billion Sessions a Day in Real Time，Twitter的實時計算框架。所謂流處理框架，就是一種分散式、高容錯的實時計算系統。Storm令持續不斷的流計算變得容易。經常用於在實時分析、在線機器學習、持續計算、分散式遠程調用和ETL等領域。

Heron

https://blog.twitter.com/2015/flying-faster-with-twitter-heron

2015年6月1號， Twitter 對外宣講了他們的Heron系統， 從ppt和論文中，看起來完爆storm。在一年前，Twitter就已經開始了從Storm遷徙到Heron；半年前，Storm在Twitter內部已經完全被捨棄。換言之，Heron已經很好地在Twitter用於線上運行超過半年。

Heron更適合超大規模的機器， 超過1000台機器以上的集群。 在穩定性上有更優異的表現， 在性能上，表現一般甚至稍弱一些，在資源使用上，可以和其他編程框架共享集群資源，但topology級別會更浪費一些資源。

Samza

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

Lambda architecture

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

Summingbird

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

NoSQL

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

Cassandra

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

SQL on Hadoop

開源社區業出現了很多 SQL-on-Hadoop的項目，著眼跟一些商業的數據倉庫系統競爭。包括Apache Hive, Spark SQL, Cloudera Impala, Hortonworks Stinger, Facebook 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

上面說道Spark，在Berkeley AMP lab 中有個更宏偉的藍圖，就是BDAS，裡面有很多明星項目，除了Spark，還包括：

Mesos：一個分散式環境的資源管理平台，它使得Hadoop、MPI、Spark作業在統一資源管理環境下執行。它對Hadoop2.0支持很好。Twitter，Coursera都在使用。

Tachyon：是一個高容錯的分散式文件系統，允許文件以內存的速度在集群框架中進行可靠的共享，就像Spark和MapReduce那樣。項目發起人李浩源說目前發展非常快，甚至比Spark當時還要驚人，已經成立創業公司Tachyon Nexus.

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

Cloudera

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

HDP （Hadoop Data Platform)

Hortonworks 提出的架構選型。

Redshift

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

Netflix

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

Intel

參考鏈接

The Hadoop Ecosystem Table

How to beat the CAP theorem

Lambda Architecture

Questioning the Lambda Architecture

推薦閱讀：