本文除了一些常用的大資料工具，還總結匯總了其他大資料工具，幾乎是最全的大資料工具的總結。 如果你想入門大資料，可以對他們進行簡單的瞭解。 如果你想學習自己熟悉意外的大資料工具，可以看這篇文章。 如果你想選擇一個適合自己公司的大資料工具，也可以參考這篇文章。 我們將針對大資料開源工具不同的用處來進行分類，並且附上了官網和部分下載連結，希望能給做大資料的朋友做個參考。下面是第一部分。

查詢引擎

一、Phoenix 簡介：這是一個Java中間層，可以讓開發者在Apache HBase上執行SQL查詢。Phoenix完全使用Java編寫，程式碼位於GitHub上，並且提供了一個客戶端可嵌入的JDBC驅動。 Phoenix查詢引擎會將SQL查詢轉換為一個或多個HBase scan，並編排執行以生成標準的JDBC結果集。直接使用HBase API、協同處理器與自定義過濾器，對於簡單查詢來說，其效能量級是毫秒，對於百萬級別的行數來說，其效能量級是秒。 Phoenix最值得關注的一些特性有： ❶嵌入式的JDBC驅動，實現了大部分的java.sql介面，包括元資料API
❷可以通過多部行鍵或是鍵/值單元對列進行建模
❸完善的查詢支援，可以使用多個謂詞以及優化的掃描鍵
❹DDL支援：通過CREATE TABLE、DROP TABLE及ALTER TABLE來新增/刪除列
❺版本化的模式倉庫：當寫入資料時，快照查詢會使用恰當的模式
❻DML支援：用於逐行插入的UPSERT VALUES、用於相同或不同表之間大量資料傳輸的UPSERT ❼SELECT、用於刪除行的DELETE
❽通過客戶端的批處理實現的有限的事務支援
❾單表——還沒有連線，同時二級索引也在開發當中
➓緊跟ANSI SQL標準 二、Stinger 簡介：原叫Tez，下一代Hive,Hortonworks主導開發，執行在YARN上的DAG計算框架。 某些測試下，Stinger能提升10倍左右的效能，同時會讓Hive支援更多的SQL，其主要優點包括： ❶讓使用者在Hadoop獲得更多的查詢匹配。其中包括類似OVER的字句分析功能，支援WHERE查詢，讓Hive的樣式系統更符合SQL模型。 ❷優化了Hive請求執行計劃，優化後請求時間減少90%。改動了Hive執行引擎，增加單Hive任務的被秒處理記錄數。 ❸在Hive社群中引入了新的列式檔案格式（如ORC檔案），提供一種更現代、高效和高效能的方式來儲存Hive資料。 ❹引入了新的執行時框架——Tez，旨在消除Hive的延時和吞吐量限制。Tez通過消除不必要的task、障礙同步和對HDFS的讀寫作業來優化Hive job。這將優化Hadoop內部的執行鏈，徹底加速Hive負載處理。 三、Presto 貢獻者：：Facebook 簡介：Facebook開源的資料查詢引擎Presto ，可對250PB以上的資料進行快速地互動式分析。該專案始於 2012 年秋季開始開發，目前該專案已經在超過 1000 名 Facebook 僱員中使用，執行超過 30000 個查詢，每日資料在 1PB 級別。Facebook 稱 Presto 的效能比諸如 Hive 和 Map*Reduce 要好上 10 倍有多。 Presto 當前支援 ANSI SQL 的大多數特效，包括聯合查詢、左右聯接、子查詢以及一些聚合和計算函式；支援近似截然不同的計數(DISTINCT COUNT)等。 四、Shark 簡介：Shark即Hive on Spark，本質上是通過Hive的HQL解析，把HQL翻譯成Spark上的RDD操作，然後通過Hive的metadata獲取資料庫裡的表資訊，實際HDFS上的資料和檔案，會由Shark獲取並放到Spark上運算。Shark的特點就是快，完全相容Hive，且可以在shell模式下使用rdd2sql()這樣的API，把HQL得到的結果集，繼續在scala環境下運算，支援自己編寫簡單的機器學習或簡單分析處理函式，對HQL結果進一步分析計算。 ❶Shark速度快的原因除了Spark平臺提供的基於記憶體迭代計算外，在設計上還存在對Spark上進行了一定的改造，主要有 ❷partial DAG execution：對join優化，調節並行粒度，因為Spark本身的寬依賴和窄依賴會影響平行計算和速度 基於列的壓縮和儲存：把HQL表資料按列存，每列是一個array，存在JVM上，避免了JVM GC低效，而壓縮和解壓相關的技術是Yahoo!提供的。 結來說，Shark是一個外掛式的東西，在我現有的Spark和Hive及hadoop-client之間，在這兩套都可用的情況下，Shark只要獲取Hive的配置（還有metastore和exec等關鍵包），Spark的路徑，Shark就能利用Hive和Spark，把HQL解析成RDD的轉換，把資料取到Spark上運算和分析。在SQL on Hadoop這塊，Shark有別於Impala，Stringer，而這些系統各有自己的設計思路，相對於對MR進行優化和改進的思路，Shark的思路更加簡單明瞭些。

五、Pig

簡介：Pig是一種程式語言，它簡化了Hadoop常見的工作任務。Pig可載入資料、表達轉換資料以及儲存最終結果。Pig內建的操作使得半結構化資料變得有意義（如日誌檔案）。同時Pig可擴充套件使用Java中新增的自定義資料型別並支援資料轉換。 Pig最大的作用就是對mapreduce演算法(框架)實現了一套shell指令碼 ，類似我們通常熟悉的SQL語句，在Pig中稱之為Pig Latin，在這套指令碼中我們可以對加載出來的資料進行排序、過濾、求和、分組(group by)、關聯(Joining)，Pig也可以由使用者自定義一些函式對資料集進行操作，也就是傳說中的UDF(user-defined functions)。

六、Cloudera Impala

簡介：Cloudera Impala 可以直接為儲存在HDFS或HBase中的Hadoop資料提供快速，互動式的SQL查詢。除了使用相同的儲存平臺外， Impala和Apache Hive一樣也使用了相同的元資料，SQL語法（Hive SQL），ODBC驅動和使用者介面（Hue Beeswax），這就很方便的為使用者提供了一個相似並且統一的平臺來進行批量或實時查詢。 Cloudera Impala 是用來進行大資料查詢的補充工具。 Impala 並沒有取代像Hive這樣基於MapReduce的分散式處理框架。Hive和其它基於MapReduce的計算框架非常適合長時間執行的批處理作業，例如那些涉及到批量 Extract、Transform、Load ，即需要進行ETL作業。 Impala 提供了： ❶資料科學家或資料分析師已經熟知的SQL介面 ❷能夠在Apache Hadoop 的大資料中進行互動式資料查詢 ❸ Single system for big data processing and analytics so customers can avoid costly modeling and ETL just for analytics

七、Apache Drill

貢獻者：：MapR 簡介：Apache Drill是是一個能夠對大資料進行互動分析、開源的分散式系統，且基於Google Dremel實現，它能夠執行在上千個節點的伺服器叢集上，且能在幾秒內處理PB級或者萬億條的資料記錄。Drill能夠幫助企業使用者快速、高效地進行Hadoop資料查詢和企業級大資料分析。Drill於2012年8月份由Apache推出。 從Drill官方對其架構的介紹中得知，其具有適於實時的分析和快速的應用開發、適於半結構化/巢狀資料的分析、相容現有的SQL環境和Apache Hive等特徵。另外，Drill的核心模組是Drillbit服務，該服務模組包括遠端訪問子模組、SQL解析器、查詢優化器、任務計劃執行引擎、儲存外掛介面（DFS、HBase、Hive等的介面）、分散式快取模組等幾部分，如下圖所示

八、Apache Tajo

簡介：Apache Tajo專案的目的是在HDFS之上構建一個先進的資料倉庫系統。Tajo將自己標榜為一個“大資料倉庫”，但是它好像和之前介紹的那些低延遲查詢引擎類似。雖然它支援外部表和Hive資料集（通過HCatalog），但是它的重點是資料管理，提供低延遲的資料訪問，以及為更傳統的ETL提供工具。它也需要在資料節點上部署Tajo特定的工作程序。 Tajo的功能包括： ❶ANSI SQL相容
❷JDBC 驅動
❸整合Hive metastore能夠訪問Hive資料集
❹一個命令列客戶端
❺一個自定義函式API

九、Hive

簡介：hive是基於Hadoop的一個數據倉庫工具，可以將結構化的資料檔案對映為一張資料庫表，並提供簡單的sql查詢功能，可以將sql語句轉換為MapReduce任務進行執行。 其優點是學習成本低，可以通過類SQL語句快速實現簡單的MapReduce統計，不必開發專門的MapReduce應用，十分適合資料倉庫的統計分析。

流式計算

一、Facebook Puma 貢獻者：Facebook 簡介：實時資料流分析

二、Twitter Rainbird

貢獻者：Twitter 簡介：Rainbird一款基於Zookeeper, Cassandra, Scribe, Thrift的分散式實時統計系統，這些基礎元件的基本功能如下： ❶ Zookeeper，Hadoop子專案中的一款分散式協調系統，用於控制分散式系統中各個元件中的一致性。 ❷Cassandra，NoSQL中一款非常出色的產品，集合了Dynamo和Bigtable特性的分散式儲存系統，用於儲存需要進行統計的資料，統計資料，並且提供客戶端進行統計資料的查詢。（需要使用分散式Counter補丁CASSANDRA-1072） ❸ Scribe，Facebook開源的一款分散式日誌收集系統，用於在系統中將各個需要統計的資料來源收集到Cassandra中。 ❹ Thrift，Facebook開源的一款跨語言C/S網路通訊框架，開發人員基於這個框架可以輕易地開發C/S應用。 用處 Rainbird可以用於實時資料的統計： ❶統計網站中每一個頁面，域名的點選次數 ❷內部系統的執行監控（統計被監控伺服器的執行狀態） ❸記錄最大值和最小值  

3.jpg (57.5 KB, 下載次數: 7)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

三、Yahoo S4

貢獻者：Yahoo 簡介：S4（Simple Scalable Streaming System）最初是Yahoo!為提高搜尋廣告有效點選率的問題而開發的一個平臺，通過統計分析使用者對廣告的點選率，排除相關度低的廣告，提升點選率。目前該專案剛啟動不久，所以也可以理解為是他們提出的一個分散式流計算（Distributed Stream Computing）的模型。

S4的設計目標是：

·提供一種簡單的程式設計介面來處理資料流 ·設計一個可以在普通硬體之上可擴充套件的高可用叢集。 ·通過在每個處理節點使用本地記憶體，避免磁碟I/O瓶頸達到最小化延遲 ·使用一個去中心的，對等架構；所有節點提供相同的功能和職責。沒有擔負特殊責任的中心節點。這大大簡化了部署和維護。 ·使用可插拔的架構，使設計儘可能的即通用又可定製化。 ·友好的設計理念，易於程式設計，具有靈活的彈性

四、Twitter Storm

貢獻者：Twitter 簡介：Storm是Twitter開源的一個類似於Hadoop的實時資料處理框架，它原來是由BackType開發，後BackType被Twitter收購，將Storm作為Twitter的實時資料分析系統。

實時資料處理的應用場景很廣泛，例如商品推薦，廣告投放，它能根據當前情景上下文（使用者偏好，地理位置，已發生的查詢和點選等）來估計使用者點選的可能性並實時做出調整。

storm的三大作用領域：

1.資訊流處理（Stream Processing） Storm可以用來實時處理新資料和更新資料庫，兼具容錯性和可擴充套件性,它 可以用來處理源源不斷的訊息，並將處理之後的結果儲存到持久化介質中。 2.連續計算（Continuous Computation） Storm可以進行連續查詢並把結果即時反饋給客戶，比如將Twitter上的熱門話題傳送到客戶端。 3.分散式遠端過程呼叫（Distributed RPC） 除此之外，Storm也被廣泛用於以下方面：

• 精確的廣告推送
• 實時日誌的處理

迭代計算

一、Apache Hama 簡介：Apache Hama是一個純BSP（Bulk Synchronous Parallel）計算框架，模仿了Google的Pregel。用來處理大規模的科學計算，特別是矩陣和圖計算。 ❶建立在Hadoop上的分散式平行計算模型。 ❷基於 Map/Reduce 和 Bulk Synchronous 的實現框架。 ❸執行環境需要關聯 Zookeeper、HBase、HDFS 元件。 Hama中有2個主要的模型: – 矩陣計算(Matrix package) – 面向圖計算(Graph package)

二、Apache Giraph

簡介：Apache Giraph是一個可伸縮的分散式迭代圖處理系統，靈感來自BSP（bulk synchronous parallel）和Google的Pregel，與它們 區別於則是是開源、基於 Hadoop 的架構等。 Giraph處理平臺適用於執行大規模的邏輯計算，比如頁面排行、共享連結、基於個性化排行等。Giraph專注於社交圖計算，被Facebook作為其Open Graph工具的核心，幾分鐘內處理數萬億次使用者及其行為之間的連線。 三、HaLoop 簡介：迭代的MapReduce，HaLoop——適用於迭代計算的Hadoop 。   Hadoop與HaLoop的不同

與Hadoop比較的四點改變：

1.提供了一套新的程式設計介面，更加適用於迭代計算； HaLoop給迭代計算一個抽象的遞迴公式：
2.HaLoop的master進行job內的迴圈控制，直到迭代計算結束； 3.Task Scheduler也進行了修改，使得任務能夠儘量滿足data locality 4.slave nodes對資料進行cache並index索引，索引也以檔案的形式儲存在本地磁碟。

四、Twister

簡介：Twister， 迭代式MapReduce框架，Twister是由一個印度人開發的，其架構如下：  

5.jpg (46.42 KB, 下載次數: 13)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

在Twister中，大檔案不會自動被切割成一個一個block，因而使用者需提前把檔案分成一個一個小檔案，以供每個task處理。在map階段，經過map（）處理完的結果被放在分散式記憶體中，然後通過一個broker network（NaradaBroking系統）將資料push給各個reduce task（Twister假設記憶體足夠大，中間資料可以全部放在記憶體中）；在reduce階段，所有reduce task產生的結果通過一個combine操作進行歸併，此時，使用者可以進行條件判定， 確定迭代是否結束。combine後的資料直接被送給map task，開始新一輪的迭代。為了提高容錯性，Twister每隔一段時間會將map task和reduce task產生的結果寫到磁碟上，這樣，一旦某個task失敗，它可以從最近的備份中獲取輸入，重新計算。

為了避免每次迭代重新建立task，Twister維護了一個task pool，每次需要task時直接從pool中取。在Twister中，所有訊息和資料都是通過broker network傳遞的，該broker network是一個獨立的模組，目前支援NaradaBroking和ActiveMQ。

離線計算

一、Hadoop MapReduce 簡介：MapReduce是一種程式設計模型，用於大規模資料集（大於1TB）的並行運算。概念”Map（對映）”和”Reduce（歸約）”，和它們的主要思想，都是從函數語言程式設計語言裡借來的，還有從向量程式語言裡借來的特性。它極大地方便了程式設計人員在不會分散式並行程式設計的情況下，將自己的程式執行在分散式系統上。 當前的軟體實現是指定一個Map（對映）函式，用來把一組鍵值對對映成一組新的鍵值對，指定併發的Reduce（歸約）函式，用來保證所有對映的鍵值對中的每一個共享相同的鍵組。

二、Berkeley Spark

簡介：Spark是UC Berkeley AMP lab所開源的類Hadoop MapReduce的通用的並行，Spark，擁有Hadoop MapReduce所具有的優點；但不同於MapReduce的是Job中間輸出結果可以儲存在記憶體中，從而不再需要讀寫HDFS，因此Spark能更好地適用於資料探勘與機器學習等需要迭代的map reduce的演算法。 三、DataTorrent

簡介：DataTorrent基於Hadoop 2.x構建，是一個實時的、有容錯能力的資料流式處理和分析平臺，它使用本地Hadoop應用程式，而這些應用程式可以與執行其它任務，如批處理，的應用程式共存。該平臺的架構如下

鍵值儲存

一、LevelDB

貢獻者：Google 簡介：Leveldb是一個google實現的非常高效的kv資料庫，目前的版本1.2能夠支援billion級別的資料量了。 在這個數量級別下還有著非常高的效能，主要歸功於它的良好的設計。特別是LMS演算法。

LevelDB 是單程序的服務，效能非常之高，在一臺4核Q6600的CPU機器上，每秒鐘寫資料超過40w，而隨機讀的效能每秒鐘超過10w。

此處隨機讀是完全命中記憶體的速度，如果是不命中 速度大大下降。

二、RocksDB

貢獻者：facebook 簡介：RocksDB雖然在程式碼層面上是在LevelDB原有的程式碼上進行開發的，但卻借鑑了Apache HBase的一些好的idea。在雲端計算橫行的年代，開口不離Hadoop，RocksDB也開始支援HDFS，允許從HDFS讀取資料。RocksDB支援一次獲取多個K-V，還支援Key範圍查詢。LevelDB只能獲取單個Key。 RocksDB除了簡單的Put、Delete操作，還提供了一個Merge操作，說是為了對多個Put操作進行合併。 RocksDB提供一些方便的工具，這些工具包含解析sst檔案中的K-V記錄、解析MANIFEST檔案的內容等。RocksDB支援多執行緒合併，而LevelDB是單執行緒合併的。

三、HyperDex

貢獻者：Facebook  

8.jpg (6.38 KB, 下載次數: 7)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

HyperDex是一個分散式、可搜尋的鍵值儲存系統，特性如下：

• 分散式KV儲存，系統性能能夠隨節點數目線性擴充套件
• 吞吐和延時都能秒殺現在風頭正勁的MonogDB，吞吐甚至強於Redis
• 使用了hyperspace hashing技術，使得對儲存的K-V的任意屬性進行查詢成為可能

四、TokyoCabinet

日本人Mikio Hirabayashi（平林幹雄）開發的一款DBM資料庫。Tokyo Cabinet 是一個DBM的實現。這裡的資料庫由一系列key-value對的記錄構成。key和value都可以是任意長度的位元組序列,既可以是二進位制也可以是字串。這裡沒有資料型別和資料表的概念。

當做為Hash表資料庫使用時，每個key必須是不同的,因此無法儲存兩個key相同的值。提供了以下訪問方法:提供key,value引數來儲存，按 key刪除記錄，按key來讀取記錄，另外，遍歷key也被支援，雖然順序是任意的不能被保證。這些方法跟Unix標準的DBM,例如GDBM,NDBM 等等是相同的，但是比它們的效能要好得多（因此可以替代它們) 。下一代KV儲存系統，支援strings、integers、floats、lists、maps和sets等豐富的資料型別。

TokyoCabinet官方網站>>>

五、Voldemort
Voldemort是一個分散式鍵值儲存系統，是Amazon’s Dynamo的一個開源克隆。特性如下：

• 支援自動複製資料到多個伺服器上。
• 支援資料自動分割所以每個伺服器只包含總資料的一個子集。
• 提供伺服器故障透明處理功能。
• 支援可撥插的序化支援，以實現複雜的鍵-值儲存，它能夠很好的5.整合常用的序化框架如：Protocol Buffers、Thrift、Avro和Java Serialization。
• 資料項都被標識版本能夠在發生故障時儘量保持資料的完整性而不會影響系統的可用性。
• 每個節點相互獨立，互不影響。
• 支援可插拔的資料放置策略

六、Amazon Dynamo

貢獻者：亞馬遜

簡介：Amazon Dynamo 是一個經典的分散式Key-Value 儲存系統，具備去中心化，高可用性，高擴充套件性的特點，但是為了達到這個目標在很多場景中犧牲了一致性。Dynamo在Amazon中得到了成功的應用，能夠跨資料中心部署於上萬個結點上提供服務，它的設計思想也被後續的許多分散式系統借鑑。如近來火熱的Cassandra，實際上就是基本照搬了Dynamo的P2P架構，同時融合了BigTable的資料模型及儲存演算法。

Amazon Dynamo官方網站>>>

七、Tair

貢獻者：淘寶

簡介：tair 是淘寶自己開發的一個分散式 key/value 儲存引擎. tair 分為持久化和非持久化兩種使用方式. 非持久化的 tair 可以看成是一個分散式快取. 持久化的 tair 將資料存放於磁碟中. 為了解決磁碟損壞導致資料丟失, tair 可以配置資料的備份數目, tair 自動將一份資料的不同備份放到不同的主機上, 當有主機發生異常, 無法正常提供服務的時候, 其於的備份會繼續提供服務.tair 的總體結構
 

11.jpg (34.43 KB, 下載次數: 6)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

tair 作為一個分散式系統, 是由一箇中心控制節點和一系列的服務節點組成. 我們稱中心控制節點為config server. 服務節點是data server. config server 負責管理所有的data server, 維護data server的狀態資訊. data server 對外提供各種資料服務, 並以心跳的形式將自身狀況彙報給config server. config server是控制點, 而且是單點, 目前採用一主一備的形式來保證其可靠性. 所有的 data server 地位都是等價的.

八、Apache Accumulo
Apache Accumulo 是一個可靠的、可伸縮的、高效能的排序分散式的 Key-Value 儲存解決方案，基於單元訪問控制以及可定製的伺服器端處理。Accumulo使用 Google BigTable 設計思路，基於 Apache Hadoop、Zookeeper 和 Thrift 構建。

Redis是一個高效能的key-value儲存系統，和Memcached類似，它支援儲存的value型別相對更多，包括string（字串）、list（連結串列）、set（集合）和zset（有序集合）。與memcached一樣，為了保證效率，資料都是快取在記憶體中，區別的是Redis會週期性的把更新的資料寫入磁碟或者把修改操作寫入追加的記錄檔案，並且在此基礎上實現了主從同步。

Redis的出現，很大程度補償了memcached這類key/value儲存的不足，在部分場合可以對關係資料庫起到很好的補充作用。它提供了Python、Ruby、Erlang、PHP客戶端，使用很方便。

表格儲存

一、OceanBase 貢獻者：阿里巴巴 簡介：OceanBase是一個支援海量資料的高效能分散式資料庫系統，實現了數千億條記錄、數百TB資料上的跨行跨表事務，由淘寶核心系統研發部、運維、DBA、廣告、應用研發等部門共同完成。在設計和實現OceanBase的時候暫時摒棄了不緊急的DBMS的功能，例如臨時表，檢視(view)，研發團隊把有限的資源集中到關鍵點上，當前 OceanBase主要解決資料更新一致性、高效能的跨表讀事務、範圍查詢、join、資料全量及增量dump、批量資料匯入。

目前OceanBase已經應用於淘寶收藏夾，用於儲存淘寶使用者收藏條目和具體的商品、店鋪資訊，每天支援4～5千萬的更新操作。等待上線的應用還包括CTU、SNS等，每天更新超過20億，更新資料量超過2.5TB，並會逐步在淘寶內部推廣。

OceanBase 0.3.1在Github開源，開源版本為Revision:12336。

二、Amazon SimpleDB

貢獻者：亞馬遜 Amazon SimpleDB是一個分散式資料庫，以Erlang撰寫。同與Amazon EC2和亞馬遜的S3一樣作為一項Web 服務，屬於亞馬遜網路服務的一部分。 正如EC2和S3，SimpleDB的按照儲存量，在網際網路上的傳輸量和吞吐量收取費用。 在2008年12月1日，亞馬遜推出了新的定價策略，提供了免費1 GB的資料和25機器小時的自由層(Free Tire)。 將其中的資料轉移到其他亞馬遜網路服務是免費的。 它是一個可大規模伸縮、用 Erlang 編寫的高可用資料儲存。

三、Vertica

貢獻者：惠普 簡介：惠普2011年2月份起始3月21號完成收購Vertica。Vertica基於列儲存。基於列儲存的設計相比傳統面向行儲存的資料庫具有巨大的優勢。同時Vertica支援MPP（massively parallel processing）等技術，查詢資料時Vertica只需取得需要的列，而不是被選擇行的所有資料，其平均效能可提高50x-1000x倍。（查詢效能高速度快）

Vertica的設計者多次表示他們的產品圍繞著高效能和高可用性設計。由於對MPP技術的支援，可提供對粒度，可伸縮性和可用性的優勢。每個節點完全獨立運作，完全無共享架構，降低對共享資源的系統競爭。

Vertica的資料庫使用標準的SQL查詢，同時Vertica的架構非常適合雲端計算，包括虛擬化，分散式多節點執行等，並且可以和Hadoop/MapReduce進行整合。

四、Cassandra

貢獻者：facebook 簡介：Cassandra是一套開源分散式NoSQL資料庫系統。它最初由Facebook開發，用於儲存收件箱等簡單格式資料，集GoogleBigTable的資料模型與Amazon Dynamo的完全分散式的架構於一身Facebook於2008將 Cassandra 開源，此後，由於Cassandra良好的可擴放性，被Digg、Twitter等知名Web 2.0網站所採納，成為了一種流行的分散式結構化資料儲存方案。

Cassandra是一個混合型的非關係的資料庫，類似於Google的BigTable。其主要功能比Dynamo （分散式的Key-Value儲存系統）更豐富，但支援度卻不如文件儲存MongoDB（介於關係資料庫和非關係資料庫之間的開源產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。支援的資料結構非常鬆散，是類似json的bjson格式，因此可以儲存比較複雜的資料型別）。Cassandra最初由Facebook開發，後轉變成了開源專案。它是一個網路社交雲端計算方面理想的資料庫。以Amazon專有的完全分散式的Dynamo為基礎，結合了Google BigTable基於列族（Column Family）的資料模型。P2P去中心化的儲存。很多方面都可以稱之為Dynamo 2.0。

五、HyperTable

簡介：Hypertable是一個開源、高效能、可伸縮的資料庫，它採用與Google的Bigtable相似的模型。在過去數年中，Google為在PC叢集 上執行的可伸縮計算基礎設施設計建造了三個關鍵部分。

第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的檔案系統，提供了一個全域性的名稱空間。它通過跨機器（和跨機架）的檔案資料複製來達到高可用性，並因此免受傳統 檔案儲存系統無法避免的許多失敗的影響，比如電源、記憶體和網路埠等失敗。第二個基礎設施是名為Map-Reduce的計算框架，它與GFS緊密協作，幫 助處理收集到的海量資料。第三個基礎設施是Bigtable，它是傳統資料庫的替代。Bigtable讓你可以通過一些主鍵來組織海量資料，並實現高效的 查詢。Hypertable是Bigtable的一個開源實現，並且根據我們的想法進行了一些改進。

六、FoundationDB

簡介：支援ACID事務處理的NoSQL資料庫，提供非常好的效能、資料一致性和操作彈性。 2015年1月2日，FoundationDB已經發布了其key-value資料庫的3.0版本，主要專注於可伸縮性和效能上的改善。FoundationDB的CEO David Rosenthal在一篇部落格上宣佈了新的版本，其中展示了FoundationDB 3.0在可伸縮性方面的資料，它可以在一個32位的c3.8xlarge EC2例項上每秒寫入1440萬次；這在效能上是之前版本的36倍。 除了效能和可伸縮性的改善之外，FoundationDB 3.0還包含了對監控支援的改善。這種監控機制不僅僅是簡單的機器檢查，它添加了對多種潛在的硬體瓶頸的診斷，並且把那些高層級的資訊整合到現有監控基礎架構中。

七：HBase

貢獻者： Fay Chang 所撰寫的“Bigtable  

18.jpg (7.21 KB, 下載次數: 6)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

簡介：HBase是一個分散式的、面向列的開源資料庫，該技術來源於 Fay Chang 所撰寫的Google論文“Bigtable：一個結構化資料的分散式儲存系統”。就像Bigtable利用了Google檔案系統（File System）所提供的分散式資料儲存一樣，HBase在Hadoop之上提供了類似於Bigtable的能力。HBase是Apache的Hadoop專案的子專案。HBase不同於一般的關係資料庫，它是一個適合於非結構化資料儲存的資料庫。另一個不同的是HBase基於列的而不是基於行的模式。

檔案儲存

一、CouchDB 簡介：CouchDB是用Erlang開發的面向文件的資料庫系統，最近剛剛釋出了1.0版本（2010年7月14日）。CouchDB不是一個傳統的關係資料庫，而是面向文件的資料庫，其資料儲存方式有點類似lucene的index檔案格式，CouchDB最大的意義在於它是一個面向web應用的新一代儲存系統，事實上，CouchDB的口號就是：下一代的Web應用儲存系統。

特點：

一、CouchDB是分散式的資料庫，他可以把儲存系統分佈到n臺物理的節點上面，並且很好的協調和同步節點之間的資料讀寫一致性。這當然也得靠Erlang無與倫比的併發特性才能做到。對於基於web的大規模應用文件應用，分散式可以讓它不必像傳統的關係資料庫那樣分庫拆表，在應用程式碼層進行大量的改動。 二、CouchDB是面向文件的資料庫，儲存半結構化的資料，比較類似lucene的index結構，特別適合儲存文件，因此很適合CMS，電話本，地址本等應用，在這些應用場合，文件資料庫要比關係資料庫更加方便，效能更好。 三、CouchDB支援REST API，可以讓使用者使用JavaScript來操作CouchDB資料庫，也可以用JavaScript編寫查詢語句，我們可以想像一下，用AJAX技術結合CouchDB開發出來的CMS系統會是多麼的簡單和方便。 其實CouchDB只是Erlang應用的冰山一角，在最近幾年，基於Erlang的應用也得到的蓬勃的發展，特別是在基於web的大規模，分散式應用領域，幾乎都是Erlang的優勢專案。 二、MongoDB 簡介：MongoDB 是一個基於分散式檔案儲存的資料庫。由C++語言編寫。旨在為WEB應用提供可擴充套件的高效能資料儲存解決方案。 MongoDB是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。他支援的資料結構非常鬆散，是類似json的bson格式，因此可以儲存比較複雜的資料型別。Mongo最大的特點是他支援的查詢語言非常強大，其語法有點類似於面向物件的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。  

20.jpg (25.3 KB, 下載次數: 14)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

特點 它的特點是高效能、易部署、易使用，儲存資料非常方便。主要功能特性有： *面向集合儲存，易儲存物件型別的資料。 mongodb叢集參考 mongodb叢集參考 *模式自由。 *支援動態查詢。 *支援完全索引，包含內部物件。 *支援查詢。 *支援複製和故障恢復。 *使用高效的二進位制資料儲存，包括大型物件（如視訊等）。 *自動處理碎片，以支援雲端計算層次的擴充套件性。 *支援RUBY，PYTHON，JAVA，C++，PHP，C#等多種語言。 *檔案儲存格式為BSON（一種JSON的擴充套件）。 *可通過網路訪問。

三、Tachyon

貢獻者：Haoyuan Li（李浩源）

簡介：Tachyon是一個分散式記憶體檔案系統，可以在叢集裡以訪問記憶體的速度來訪問存在tachyon裡的檔案。把Tachyon是架構在最底層的分散式檔案儲存和上層的各種計算框架之間的一種中介軟體。主要職責是將那些不需要落地到DFS裡的檔案，落地到分散式記憶體檔案系統中，來達到共享記憶體，從而提高效率。同時可以減少記憶體冗餘，GC時間等。

Tachyon架構

Tachyon的架構是傳統的Master—slave架構，這裡和Hadoop類似，TachyonMaster裡WorkflowManager是 Master程序，因為是為了防止單點問題，通過Zookeeper做了HA，可以部署多臺Standby Master。Slave是由Worker Daemon和Ramdisk構成。這裡個人理解只有Worker Daemon是基於JVM的，Ramdisk是一個off heap memory。Master和Worker直接的通訊協議是Thrift。 下圖來自Tachyon的作者Haoyuan Li：  

23.jpg (48.43 KB, 下載次數: 8)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

四、KFS

簡介：GFS的C++開源版本，Kosmos distributed file system (KFS)是一個專門為資料密集型應用（搜尋引擎，資料探勘等）而設計的儲存系統，類似於Google的GFS和Hadoop的HDFS分散式檔案系統。 KFS使用C++實現，支援的客戶端包括C++，Java和Python。KFS系統由三部分組成，分別是metaserver、chunkserver和client library。

五、HDFS

簡介：Hadoop分散式檔案系統(HDFS)被設計成適合執行在通用硬體(commodity hardware)上的分散式檔案系統。它和現有的分散式檔案系統有很多共同點。但同時，它和其他的分散式檔案系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的資料訪問，非常適合大規模資料集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取檔案系統資料的目的。HDFS在最開始是作為Apache Nutch搜尋引擎專案的基礎架構而開發的。HDFS是Apache Hadoop Core專案的一部分。

資源管理

一、Twitter Mesos 開發者：Twitter研發人員John Oskasson

簡介：Apache Mesos是由加州大學伯克利分校的AMPLab首先開發的一款開源群集管理軟體，支援Hadoop、ElasticSearch、Spark、Storm 和Kafka等架構，由於其開源性質越來越受到一些大型雲端計算公司的青睞，例如Twitter、Facebook等。

二、Hadoop Yarn

Hadoop 新 MapReduce 框架 Yarn。為從根本上解決舊 MapReduce 框架的效能瓶頸，促進 Hadoop 框架的更長遠發展，從 0.23.0 版本開始，Hadoop 的 MapReduce 框架完全重構，發生了根本的變化。新的 Hadoop MapReduce 框架命名為 MapReduceV2 或者叫 Yarn，其架構圖如下圖所示： Yarn 框架相對於老的 MapReduce 框架什麼優勢呢？我們可以看到：

1、這個設計大大減小了 JobTracker（也就是現在的 ResourceManager）的資源消耗，並且讓監測每一個 Job 子任務 (tasks) 狀態的程式分散式化了，更安全、更優美。

2、在新的 Yarn 中，ApplicationMaster 是一個可變更的部分，使用者可以對不同的程式設計模型寫自己的 AppMst，讓更多型別的程式設計模型能夠跑在 Hadoop 叢集中，可以參考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。 3、對於資源的表示以記憶體為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的佔用 )，比之前以剩餘 slot 數目更合理。 4、老的框架中，JobTracker 一個很大的負擔就是監控 job 下的 tasks 的執行狀況，現在，這個部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個模組叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是監測 ApplicationMaster 的行狀況，如果出問題，會將其在其他機器上重啟。 5、Container 是 Yarn 為了將來作資源隔離而提出的一個框架。這一點應該借鑑了 Mesos 的工作，目前是一個框架，僅僅提供 java 虛擬機器記憶體的隔離 ,hadoop 團隊的設計思路應該後續能支援更多的資源排程和控制 , 既然資源表示成記憶體量，那就沒有了之前的 map slot/reduce slot 分開造成叢集資源閒置的尷尬情況。
接上一部分：這部分主要收集整理的內容主要有日誌收集系統、訊息系統、分散式服務、叢集管理、RPC、基礎設施、搜尋引擎、Iaas和監控管理等大資料開源工具。

日誌收集系統

一、Facebook Scribe  

27.jpg (2.54 KB, 下載次數: 15)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

貢獻者：Facebook 簡介：Scribe是Facebook開源的日誌收集系統，在Facebook內部已經得到大量的應用。它能夠從各種日誌源上收集日誌，儲存到一箇中央儲存系統（可以是NFS，分散式檔案系統等）上，以便於進行集中統計分析處理。它為日誌的“分散式收集，統一處理”提供了一個可擴充套件的，高容錯的方案。當中央儲存系統的網路或者機器出現故障時，scribe會將日誌轉存到本地或者另一個位置，當中央儲存系統恢復後，scribe會將轉存的日誌重新傳輸給中央儲存系統。其通常與Hadoop結合使用，scribe用於向HDFS中push日誌，而Hadoop通過MapReduce作業進行定期處理。

Scribe的系統架構

二、Cloudera Flume

簡介：Flume是Cloudera提供的一個高可用的，高可靠的，分散式的海量日誌採集、聚合和傳輸的系統，Flume支援在日誌系統中定製各類資料傳送方，用於收集資料；同時，Flume提供對資料進行簡單處理，並寫到各種資料接受方（可定製）的能力。 Flume提供了從console（控制檯）、RPC（Thrift-RPC）、text（檔案）、tail（UNIX tail）、syslog（syslog日誌系統，支援TCP和UDP等2種模式），exec（命令執行）等資料來源上收集資料的能力。 當前Flume有兩個版本Flume 0.9X版本的統稱Flume-og，Flume1.X版本的統稱Flume-ng。由於Flume-ng經過重大重構，與Flume-og有很大不同，使用時請注意區分。 Cloudera Flume構架：

三、logstash

簡介：logstash 是一個應用程式日誌、事件的傳輸、處理、管理和搜尋的平臺。你可以用它來統一對應用程式日誌進行收集管理，提供 Web 介面用於查詢和統計。他可以對你的日誌進行收集、分析，並將其儲存供以後使用（如，搜尋），您可以使用它。說到搜尋，logstash帶有一個web介面，搜尋和展示所有日誌。

四、kibana 簡介：Kibana 是一個為 Logstash 和 ElasticSearch 提供的日誌分析的 Web 介面。可使用它對日誌進行高效的搜尋、視覺化、分析等各種操作。kibana 也是一個開源和免費的工具，他可以幫助您彙總、分析和搜尋重要資料日誌並提供友好的web介面。他可以為 Logstash 和 ElasticSearch 提供的日誌分析的 Web 介面。

訊息系統

一、StormMQ 簡介：MQMessageQueue訊息佇列產品 StormMQ，是一種服務程式。

二、ZeroMQ

簡介：這是個類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關係），而ZMQ卻是可以N：M 的關係，人們對BSD套接字的瞭解較多的是點對點的連線，點對點連線需要顯式地建立連線、銷燬連線、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ遮蔽了這些細節，讓你的網路程式設計更為簡單。ZMQ用於node與node間的通訊，node可以是主機或者是程序。 引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket程式設計更加簡單、簡潔和效能更高。是一個訊息處理佇列庫，可在多個執行緒、核心和主機盒之間彈性伸縮。ZMQ的明確目標是“成為標準網路協議棧的一部分，之後進入Linux核心”。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的“傳統”BSD套接字之上的一 層封裝。ZMQ讓編寫高效能網路應用程式極為簡單和有趣。”

三、RabbitMQ

簡介：RabbitMQ是一個受歡迎的訊息代理，通常用於應用程式之間或者程式的不同元件之間通過訊息來進行整合。本文簡單介紹瞭如何使用 RabbitMQ，假定你已經配置好了rabbitmq伺服器。

RabbitMQ是用Erlang，對於主要的程式語言都有驅動或者客戶端。我們這裡要用的是Java，所以先要獲得Java客戶端。

像RabbitMQ這樣的訊息代理可用來模擬不同的場景，例如點對點的訊息分發或者訂閱/推送。我們的程式足夠簡單，有兩個基本的元件，一個生產者用於產生訊息，還有一個消費者用來使用產生的訊息。

四、Apache ActiveMQ

簡介：ActiveMQ 是Apache出品，最流行的，能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現，儘管JMS規範出臺已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。  

33.jpg (2.71 KB, 下載次數: 8)

下載附件  儲存到相簿

2015-3-13 15:32 上傳

特性： ⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP ⒉ 完全支援JMS1.1和J2EE 1.4規範 （持久化，XA訊息，事務) ⒊ 對Spring的支援，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支援Spring2.0的特性 ⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何相容J2EE 1.4 商業伺服器上 ⒌ 支援多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA ⒍ 支援通過JDBC和journal提供高速的訊息持久化 ⒎ 從設計上保證了高效能的叢集，客戶端-伺服器，點對點 ⒏ 支援Ajax ⒐ 支援與Axis的整合 ⒑ 可以很容易得呼叫內嵌JMS provider，進行測試

五、Jafka

貢獻者：LinkedIn 簡介：Jafka 是一個開源的、高效能的、跨語言分散式訊息系統，使用GitHub託管。Jafka 最早是由Apache孵化的Kafka（由LinkedIn捐助給Apache）克隆而來。由於是一個開放式的資料傳輸協議，因此除了Java開發語言受到支援，Python、Ruby、C、C++等其他語言也能夠很好的得到支援。 特性： 1、訊息持久化非常快，服務端儲存訊息的開銷為O(1)，並且基於檔案系統，能夠持久化TB級的訊息而不損失效能。 2、吞吐量取決於網路頻寬。 3、完全的分散式系統，broker、producer、consumer都原生自動支援分散式。自動實現複雜均衡。 4、核心非常小，整個系統（包括服務端和客戶端）只有一個272KB的jar包，內部機制也不復雜，適合進行內嵌或者二次開發 。整個服務端加上依賴元件共3.5MB。 5、訊息格式以及通訊機制非常簡單，適合進行跨語言開發。目前自帶的Python3.x的客戶端支援傳送訊息和接收訊息。

六、Apache Kafka

貢獻者：LinkedIn 簡介：Apache Kafka是由Apache軟體基金會開發的一個開源訊息系統專案，由Scala寫成。Kafka最初是由LinkedIn開發，並於2011年初開源。2012年10月從Apache Incubator畢業。該專案的目標是為處理實時資料提供一個統一、高通量、低等待的平臺。 Kafka是一個分散式的、分割槽的、多複本的日誌提交服務。它通過一種獨一無二的設計提供了一個訊息系統的功能。 Kafka叢集可以在一個指定的時間內保持所有釋出上來的訊息，不管這些訊息有沒有被消費。打個比方，如果這個時間設定為兩天，那麼在訊息釋出的兩天以內，這條訊息都是可以被消費的，但是在兩天後，這條訊息就會被系統丟棄以釋放空間。Kafka的效能不會受資料量的大小影響，因此保持大量的資料不是一個問題。

分散式服務

一、ZooKeeper 貢獻者：Google 簡介：ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、名字服務、分散式同步、組服務等。 ZooKeeper是以Fast Paxos演算法為基礎的，paxos演算法存在活鎖的問題，即當有多個proposer交錯提交時，有可能互相排斥導致沒有一個proposer能提交成功，而Fast Paxos作了一些優化，通過選舉產生一個leader，只有leader才能提交propose，具體演算法可見Fast Paxos。因此，要想弄懂ZooKeeper首先得對Fast Paxos有所瞭解。 架構：  

34.jpg (35.82 KB, 下載次數: 13)

下載附件  儲存到相簿

2015-3-13 15:33 上傳

RPC

（Remote Procedure Call Protocol）——遠端過程呼叫協議 一、Apache Avro 簡介：Apache Avro是Hadoop下的一個子專案。它本身既是一個序列化框架，同時也實現了RPC的功能。Avro官網描述Avro的特性和功能如下：

• 豐富的資料結構型別；
• 快速可壓縮的二進位制資料形式；
• 儲存持久資料的檔案容器；
• 提供遠端過程呼叫RPC；
• 簡單的動態語言結合功能。

相比於Apache Thrift 和Google的Protocol Buffers，Apache Avro具有以下特點：

• 支援動態模式。Avro不需要生成程式碼，這有利於搭建通用的資料處理系統，同時避免了程式碼入侵。
• 資料無須加標籤。讀取資料前，Avro能夠獲取模式定義，這使得Avro在資料編碼時只需要保留更少的型別資訊，有利於減少序列化後的資料大小。

二、Facebook Thrift

貢獻者：Facebook 簡介：Thrift源於大名鼎鼎的facebook之手，在2007年facebook提交Apache基金會將Thrift作為一個開源專案，對於當時的facebook來說創造thrift是為了解決facebook系統中各系統間大資料量的傳輸通訊以及系統之間語言環境不同需要跨平臺的特性。 thrift可以支援多種程式語言，例如: C++, C#, Cocoa, Erlang, Haskell, Java, Ocami, Perl, PHP, Python, Ruby, Smalltalk. 在多種不同的語言之間通訊thrift可以作為二進位制的高效能的通訊中介軟體，支援資料(物件)序列化和多種型別的RPC服務。 Thrift適用於程式對程 序靜態的資料交換，需要先確定好他的資料結構，他是完全靜態化的，當資料結構發生變化時，必須重新編輯IDL檔案，程式碼生成，再編譯載入的流程，跟其他IDL工具相比較可以視為是Thrift的弱項，Thrift適用於搭建大型資料交換及儲存的通用工具，對於大型系統中的內部資料傳輸相對於JSON和xml無論在效能、傳輸大小上有明顯的優勢。 Thrift 主要由5個部分組成： · 型別系統以及 IDL 編譯器：負責由使用者給定的 IDL 檔案生成相應語言的介面程式碼 · TProtocol：實現 RPC 的協議層，可以選擇多種不同的物件序列化方式，如 JSON, Binary。 · TTransport：實現 RPC 的傳輸層，同樣可以選擇不同的傳輸層實現，如socket, 非阻塞的 socket, MemoryBuffer 等。 · TProcessor：作為協議層和使用者提供的服務實現之間的紐帶，負責呼叫服務實現的介面。 · TServer：聚合 TProtocol, TTransport 和 TProcessor 幾個物件。 上述的這5個部件都是在 Thrift 的原始碼中通過為不同語言提供庫來實現的，這些庫的程式碼在 Thrift 原始碼目錄的 lib 目錄下面，在使用 Thrift 之前需要先熟悉與自己的語言對應的庫提供的介面。 Facebook Thrift構架：  

35.jpg (36.37 KB, 下載次數: 10)

下載附件  儲存到相簿

2015-3-13 15:33 上傳

叢集管理

一、Nagios

簡介：Nagios是一款開源的免費網路監視工具，能有效監控Windows、Linux和Unix的主機狀態，交換機路由器等網路設定，印表機等。在系統或服務狀態異常時發出郵件或簡訊報警第一時間通知網站運維人員，在狀態恢復後發出正常的郵件或簡訊通知。 Nagios可執行在Linux/Unix平臺之上，同時提供一個可選的基於瀏覽器的WEB介面以方便系統管理人員檢視網路狀態，各種系統問題，以及日誌等等。

二、Ganglia

簡介：Ganglia是UC Berkeley發起的一個開源叢集監視專案，設計用於測量數以千計的節點。Ganglia的核心包含gmond、gmetad以及一個Web前端。主要是用來監控系統性能，如：cpu 、mem、硬碟利用率， I/O負載、網路流量情況等，通過曲線很容易見到每個節點的工作狀態，對合理調整、分配系統資源，提高系統整體效能起到重要作用。  

36.jpg (43.07 KB, 下載次數: 11)

下載附件  儲存到相簿

2015-3-13 15:33 上傳

三、Apache Ambari

簡介：Apache Ambari是一種基於Web的工具，支援Apache Hadoop叢集的供應、管理和監控。Ambari目前已支援大多數Hadoop元件，包括HDFS、MapReduce、Hive、Pig、 Hbase、Zookeper、Sqoop和Hcatalog等。

Apache Ambari 支援HDFS、MapReduce、Hive、Pig、Hbase、Zookeper、Sqoop和Hcatalog等的集中管理。也是5個頂級hadoop管理工具之一。

Ambari主要取得了以下成績：

• 通過一步一步的安裝嚮導簡化了叢集供應。
• 預先配置好關鍵的運維指標（metrics），可以直接檢視Hadoop Core（HDFS和MapReduce）及相關專案（如HBase、Hive和HCatalog）是否健康。
• 支援作業與任務執行的視覺化與分析，能夠更好地檢視依賴和效能。
• 通過一個完整的RESTful API把監控資訊暴露出來，集成了現有的運維工具。
• 使用者介面非常直觀，使用者可以輕鬆有效地檢視資訊並控制叢集。

Ambari使用Ganglia收集度量指標，用Nagios支援系統報警，當需要引起管理員的關注時（比如，節點停機或磁碟剩餘空間不足等問題），系統將向其傳送郵件。 此外，Ambari能夠安裝安全的（基於Kerberos）Hadoop叢集，以此實現了對Hadoop 安全的支援，提供了基於角色的使用者認證、授權和審計功能，併為使用者管理集成了LDAP和Active Directory。

基礎設施

一、LevelDB 貢獻者：Jeff Dean和Sanjay Ghemawat 簡介：Leveldb是一個google實現的非常高效的kv資料庫，目前的版本1.2能夠支援billion級別的資料量了。 在這個數量級別下還有著非常高的效能，主要歸功於它的良好的設計。特別是LMS演算法。LevelDB 是單程序的服務，效能非常之高，在一臺4核Q6600的CPU機器上，每秒鐘寫資料超過40w，而隨機讀的效能每秒鐘超過10w。 Leveldb框架：  

38.jpg (33.42 KB, 下載次數: 6)

下載附件  儲存到相簿

2015-3-13 15:33 上傳

二、SSTable

簡介：如果說Protocol Buffer是谷歌獨立資料記錄的通用語言 ，那麼有序字串表（SSTable，Sorted String Table）則是用於儲存，處理和資料集交換的最流行​​的資料輸出格式。正如它的名字本身，SSTable是有效儲存大量鍵-值對的簡單抽象，對高吞吐量順序讀/寫進行了優化。 SSTable是Bigtable中至關重要的一塊，對於LevelDB來說也是如此。

三、RecordIO

貢獻者：Google 簡介：我們大家都在用檔案來儲存資料。檔案是儲存在磁碟上的。如果在一些不穩定的介質上，檔案很容損壞。即時檔案某個位置出現一點小小的問題，整個檔案就廢了。 下面我來介紹Google的一個做法，可以比較好的解決這個問題。那就是recordio檔案格式。recoidio的儲存單元是一個一個record。這個record可以根據業務的需要自行定義。但Google有一種建議的處理方式就是使用protobuf。 reocordio底層的格式其實很簡單。一個record由四部分組成：

• MagicNumber (32 bits)
• Uncompressed data payload size (64 bits)
• Compressed data payload size (64 bits), or 0 if the data is not compressed
• Payload, possibly compressed.

詳細格式如下圖所示：  

39.png (19.07 KB, 下載次數: 12)

下載附件  儲存到相簿

2015-3-13 15:33 上傳

到這裡，大家可能已經知道，recordio之所以能對付壞資料，其實就是在這個MagicNumber（校驗值）。

四、Flat Buffers

貢獻者：Google 簡介：谷歌開源高效、跨平臺的序列化庫FlatBuffers。 該庫的構建是專門為遊戲開發人員的效能需求提供支援，它將序列化資料儲存在快取中，這些資料既可以儲存在檔案中，又可以通過網路原樣傳輸，而不需要任何解析開銷。 FlatBuffers有如下一些關鍵特性——

• 訪問序列化資料不需要打包/拆包
• 節省記憶體而且訪問速度快——快取只佔用訪問資料所需要的記憶體；不需要任何額外的記憶體。
• 靈活性——通過可選欄位向前向後相容
• 程式碼規模小
• 強型別——錯誤在編譯時捕獲，而不是在執行時
• 便利性——生成的C++標頭檔案程式碼簡潔。如果需要，有一項可選功能可以用來在執行時高效解析Schema和JSON-like格式的文字。
• 跨平臺——使用C++編寫，不依賴STL之外的庫，因此可以用於任何有C++編輯器的平臺。當前，該專案包含構建方法和在Android、Linux、Windows和OSX等作業系統上使用該庫的示例。

與Protocol Buffers或JSON Parsing這樣的可選方案相比，FlatBuffers的優勢在於開銷更小，這主要是由於它沒有解析過程。

五、Protocol Buffers

貢獻者：Google 簡介：Protocol Buffers是Google公司開發的一種資料描述語言，類似於XML能夠將結構化資料序列化，可用於資料儲存、通訊協議等方面。它不依賴於語言和平臺並且可擴充套件性極強。現階段官方支援C++、JAVA、Python等三種程式語言，但可以找到大量的幾乎涵蓋所有語言的