後Hadoop時代的大資料架構(轉)

標籤：

原文：http://zhuanlan.zhihu.com/donglaoshi/19962491 董飛

 

 

 

提到巨量資料分析平台，不得不說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內部資料庫，支援外部一致性的分散式交易;設計目標是橫跨全球上百個資料中心,覆蓋百萬台伺服器,包含萬億條行記錄！(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令持續不斷的StreamCompute變得容易。經常用於在即時分析、線上機器學習、持續計算、分布式遠程調用和ETL等領域。

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：是一個高容錯的Distributed File System，允許檔案以記憶體的速度在叢集架構中進行可靠的共用，就像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

來源：http://zhuanlan.zhihu.com/donglaoshi/19962491  轉自 https://linux.cn/article-5324-1.html

後Hadoop時代的大資料架構(轉)