(轉)一共81個，開源大數據處理工具彙總

[思路網注] 本文一共分爲上下兩部分。咱們將針對大數據開源工具不一樣的用處來進行分類，而且附上了官網和部分下載連接，但願能給作大數據的朋友作個參考。

 

本文一共分爲上下兩部分。咱們將針對大數據開源工具不一樣的用處來進行分類，而且附上了官網和部分下載連接，但願能給作大數據的朋友作個參考。下面是第一部分。

查詢引擎

1、Phoenix

貢獻者：：Salesforce

簡介：這是一個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、用於相同或不一樣表之間大量數據傳輸的UPSERTSELECT、用於刪除行的DELETE

經過客戶端的批處理實現的有限的事務支持

單表——尚未鏈接，同時二級索引也在開發當中

緊跟ANSI SQL標準

2、Stinger

貢獻者：：Hortonworks

簡介：原叫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負載處理。

Stinger官方網站>>>

3、Presto

貢獻者：：Facebook

簡 介：Facebook開源的數據查詢引擎Presto，可對250PB以上的數據進行快速地交互式分析。該項目始於2012年秋季開始開發，目前該項目已 經在超過1000名 Facebook僱員中使用，運行超過30000個查詢，每日數據在1PB級別。Facebook稱 Presto的性能比諸如Hive和 Map*Reduce要好上10倍有多。

Presto當前支持ANSI SQL的大多數特效，包括聯合查詢、左右聯接、子查詢以及一些聚合和計算函數；支持近似大相徑庭的計數(DISTINCT COUNT)等。

github源代碼下載>>>

4、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的思 路更加簡單明瞭些。

Shark官方網站>>>

5、Pig

簡介：Pig是一種編程語言，它簡化了Hadoop常見的工做任務。Pig可加載數據、表達轉換數據以及存儲最終結果。Pig內置的操做使得半結構化數據變得有意義（如日誌文件）。同時Pig可擴展使用Java中添加的自定義數據類型並支持數據轉換。

Pig 最大的做用就是對mapreduce算法(框架)實現了一套shell腳本 ，相似咱們一般熟悉的SQL語句，在Pig中稱之爲Pig Latin，在這套腳本中咱們能夠對加載出來的數據進行排序、過濾、求和、分組(group by)、關聯(Joining)，Pig也能夠由用戶自定義一些函數對數據集進行操做，也就是傳說中的UDF(user-defined functions)。

Pig官方網站>>>

6、ClouderaImpala

貢獻者：:Cloudera

簡 介：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

ClouderaImpala官方網站>>>

7、ApacheDrill

貢獻者：：MapR

簡 介：Apache Drill是是一個可以對大數據進行交互分析、開源的分佈式系統，且基於Google Dremel實現，它可以運行在上千個節點的服務器集羣上，且能在幾秒內處理PB級或者萬億條的數據記錄。Drill可以幫助企業用戶快速、高效地進行 Hadoop數據查詢和企業級大數據分析。Drill於2012年8月份由Apache推出。

從 Drill官方對其架構的介紹中得知，其具備適於實時的分析和快速的應用開發、適於半結構化/嵌套數據的分析、兼容現有的SQL環境和Apache Hive等特徵。另外，Drill的核心模塊是Drillbit服務，該服務模塊包括遠程訪問子模塊、SQL解析器、查詢優化器、任務計劃執行引擎、存儲 插件接口（DFS、HBase、Hive等的接口）、分佈式緩存模塊等幾部分，以下圖所示：

ApacheDrill官方網站>>>

8、ApacheTajo

簡 介：Apache Tajo項目的目的是在HDFS之上構建一個先進的數據倉庫系統。Tajo將本身標榜爲一個「大數據倉庫」，可是它好像和以前介紹的那些低延遲查詢引擎類 似。雖然它支持外部表和Hive數據集（經過HCatalog），可是它的重點是數據管理，提供低延遲的數據訪問，以及爲更傳統的ETL提供工具。它也需 要在數據節點上部署Tajo特定的工做進程。

Tajo的功能包括：

ANSI SQL兼容

JDBC驅動

集成Hive metastore可以訪問Hive數據集

一個命令行客戶端

一個自定義函數API

ApacheTajo官方網站>>>

9、Hive

簡 介：hive是基於Hadoop的一個數據倉庫工具，能夠將結構化的數據文件映射爲一張數據庫表，並提供簡單的sql查詢功能，能夠將sql語句轉換爲 MapReduce任務進行運行。 其優勢是學習成本低，能夠經過類SQL語句快速實現簡單的MapReduce統計，沒必要開發專門的MapReduce應用，十分適合數據倉庫的統計分析。

Hive官方網站>>>

流式計算

1、FacebookPuma

貢獻者：Facebook

簡介：實時數據流分析

2、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、Yahoo S4

貢獻者：Yahoo

簡 介：S4（Simple Scalable Streaming System）最初是Yahoo!爲提升搜索廣告有效點擊率的問題而開發的一個平臺，經過統計分析用戶對廣告的點擊率，排除相關度低的廣告，提高點擊率。 目前該項目剛啓動不久，因此也能夠理解爲是他們提出的一個分佈式流計算（Distributed Stream Computing）的模型。

S4的設計目標是：

·提供一種簡單的編程接口來處理數據流

·設計一個能夠在普通硬件之上可擴展的高可用集羣。

·經過在每一個處理節點使用本地內存，避免磁盤I/O瓶頸達到最小化延遲

·使用一個去中心的，對等架構；全部節點提供相同的功能和職責。沒有擔負特殊責任的中心節點。這大大簡化了部署和維護。

·使用可插拔的架構，使設計儘量的即通用又可定製化。

·友好的設計理念，易於編程，具備靈活的彈性

Yahoo S4官方網站>>>

4、TwitterStorm

貢獻者：Twitter

簡介：Storm是Twitter開源的一個相似於Hadoop的實時數據處理框架，它原來是由BackType開發，後BackType被Twitter收購，將Storm做爲Twitter的實時數據分析系統。

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

storm的三大做用領域：

1.信息流處理（Stream Processing）

Storm能夠用來實時處理新數據和更新數據庫，兼具容錯性和可擴展性,它 能夠用來處理源源不斷的消息，並將處理以後的結果保存到持久化介質中。

2.連續計算（Continuous Computation）

Storm能夠進行連續查詢並把結果即時反饋給客戶，好比將Twitter上的熱門話題發送到客戶端。

3.分佈式遠程過程調用（Distributed RPC）

除此以外，Storm也被普遍用於如下方面：

精確的廣告推送

實時日誌的處理

TwitterStorm官方網站>>>

迭代計算

1、Apache Hama

簡介：Apache Hama是一個純BSP（Bulk Synchronous Parallel）計算框架，模仿了Google的Pregel。用來處理大規模的科學計算，特別是矩陣和圖計算。

創建在Hadoop上的分佈式並行計算模型。

基於Map/Reduce和 Bulk Synchronous的實現框架。

運行環境須要關聯Zookeeper、HBase、HDFS組件。

Hama中有2個主要的模型:

– 矩陣計算(Matrix package)

– 面向圖計算(Graph package)

2、ApacheGiraph

代碼託管地址：

簡介：Apache Giraph是一個可伸縮的分佈式迭代圖處理系統，靈感來自BSP（bulk synchronous parallel）和Google的Pregel，與它們 區別於則是是開源、基於Hadoop的架構等。

Giraph處理平臺適用於運行大規模的邏輯計算，好比頁面排行、共享連接、基於個性化排行等。Giraph專一於社交圖計算，被Facebook做爲其Open Graph工具的核心，幾分鐘內處理數萬億次用戶及其行爲之間的鏈接。

3、HaLoop

簡介：迭代的MapReduce，HaLoop——適用於迭代計算的Hadoop。

Hadoop與HaLoop的不一樣

與Hadoop比較的四點改變：

1.提供了一套新的編程接口，更加適用於迭代計算；

HaLoop給迭代計算一個抽象的遞歸公式：

2.HaLoop的master進行job內的循環控制，直到迭代計算結束；

3.Task Scheduler也進行了修改，使得任務可以儘可能知足data locality

4.slave nodes對數據進行cache並index索引，索引也以文件的形式保存在本地磁盤。

HaLoop官網>>>

4、Twister

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

 

在 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。

離線計算

1、HadoopMapReduce

簡 介：MapReduce是一種編程模型，用於大規模數據集（大於1TB）的並行運算。概念」Map（映射）」和」Reduce（歸約）」，和它們的主要思 想，都是從函數式編程語言裏借來的，還有從矢量編程語言裏借來的特性。它極大地方便了編程人員在不會分佈式並行編程的狀況下，將本身的程序運行在分佈式系 統上。 當前的軟件實現是指定一個Map（映射）函數，用來把一組鍵值對映射成一組新的鍵值對，指定併發的Reduce（歸約）函數，用來保證全部映射的鍵值對中 的每個共享相同的鍵組。

HadoopMapReduce官方網站>>>

2、Berkeley Spark

簡 介：Spark是UC Berkeley AMP lab所開源的類Hadoop MapReduce的通用的並行，Spark，擁有Hadoop MapReduce所具備的優勢；但不一樣於MapReduce的是Job中間輸出結果能夠保存在內存中，從而再也不須要讀寫HDFS，所以Spark能更好 地適用於數據挖掘與機器學習等須要迭代的map reduce的算法。

3、DataTorrent

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

相關文章：DataTorrent 1.0每秒處理超過10億個實時事件

DataTorrent將數據分析速度從「實時」提高至「如今時」

鍵值存儲

1、LevelDB

貢獻者：Google

簡介：Leveldb是一個google實現的很是高效的kv數據庫，目前的版本1.2可以支持billion級別的數據量了。 在這個數量級別下還有着很是高的性能，主要歸功於它的良好的設計。特別是LMS算法。

LevelDB是單進程的服務，性能很是之高，在一臺4核Q6600的CPU機器上，每秒鐘寫數據超過40w，而隨機讀的性能每秒鐘超過10w。

此處隨機讀是徹底命中內存的速度，若是是不命中 速度大大降低。

LevelDB官方網站>>>

2、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是單線程合併的。

RocksDB官方網站>>>

3、HyperDex

貢獻者：Facebook

HyperDex是一個分佈式、可搜索的鍵值存儲系統，特性以下：

分佈式KV存儲，系統性能可以隨節點數目線性擴展

吞吐和延時都能秒殺如今風頭正勁的MonogDB，吞吐甚至強於Redis

使用了hyperspace hashing技術，使得對存儲的K-V的任意屬性進行查詢成爲可能

官網：http://hyperdex.org/

4、TokyoCabinet

日 本人MikioHirabayashi（平林幹雄）開發的一款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官方網站>>>

5、Voldemort

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

支持自動複製數據到多個服務器上。

支持數據自動分割因此每一個服務器只包含總數據的一個子集。

提供服務器故障透明處理功能。

支持可撥插的序化支持，以實現複雜的鍵-值存儲，它可以很好的5.集成經常使用的序化框架如：Protocol Buffers、Thrift、Avro和Java Serialization。

數據項都被標識版本可以在發生故障時儘可能保持數據的完整性而不會影響系統的可用性。

每一個節點相互獨立，互不影響。

支持可插拔的數據放置策略

官網：http://project-voldemort.com/

6、AmazonDynamo

貢獻者：亞馬遜

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

Amazon Dynamo官方網站>>>

7、Tair

貢獻者：淘寶

簡 介：tair是淘寶本身開發的一個分佈式key/value存儲引擎.tair分爲持久化和非持久化兩種使用方式. 非持久化的tair能夠當作是一個分佈式緩存. 持久化的tair將數據存放於磁盤中. 爲了解決磁盤損壞致使數據丟失,tair能夠配置數據的備份數目,tair自動將一份數據的不一樣備份放到不一樣的主機上, 當有主機發生異常, 沒法正常提供服務的時候, 其於的備份會繼續提供服務.tair的整體結構

tair 做爲一個分佈式系統, 是由一箇中心控制節點和一系列的服務節點組成. 咱們稱中心控制節點爲config server. 服務節點是data server.config server負責管理全部的data server, 維護data server的狀態信息.data server對外提供各類數據服務, 並以心跳的形式將自身情況彙報給config server.config server是控制點, 並且是單點, 目前採用一主一備的形式來保證其可靠性. 全部的data server地位都是等價的.

8、ApacheAccumulo

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

官網：http://accumulo.apache.org/

9、Redis

Redis 是一個高性能的key-value存儲系統，和Memcached相似，它支持存儲的value類型相對更多，包括string（字符串）、list（鏈 表）、set（集合）和zset（有序集合）。與memcached同樣，爲了保證效率，數據都是緩存在內存中，區別的是Redis會週期性的把更新的數 據寫入磁盤或者把修改操做寫入追加的記錄文件，而且在此基礎上實現了主從同步。

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

官網：http://redis.io/

表格存儲

1、OceanBase

貢獻者：阿里巴巴

相關文章：26頁PPT解密支撐支付寶交易的分佈式數據庫系統——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。

官網：http://alibaba.github.io/oceanbase/

2、AmazonSimpleDB

貢獻者：亞馬遜

Amazon SimpleDB是一個分散式數據庫，以Erlang撰寫。同與Amazon EC2和亞馬遜的S3同樣做爲一項Web服務，屬於亞馬遜網絡服務的一部分。

正如EC2和S3，SimpleDB的按照存儲量，在互聯網上的傳輸量和吞吐量收取費用。 在2008年12月1日，亞馬遜推出了新的訂價策略，提供了免費1 GB的數據和25機器小時的自由層(Free Tire)。 將其中的數據轉移到其餘亞馬遜網絡服務是免費的。

它是一個可大規模伸縮、用Erlang編寫的高可用數據存儲。

官網：http://aws.amazon.com/cn/simpledb/

3、Vertica

貢獻者：惠普

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

Vertica的設計者屢次表示他們的產品圍繞着高性能和高可用性設計。因爲對MPP技術的支持，可提供對粒度，可伸縮性和可用性的優點。每一個節點徹底獨立運做，徹底無共享架構，下降對共享資源的系統競爭。

Vertica的數據庫使用標準的SQL查詢，同時Vertica的架構很是適合雲計算，包括虛擬化，分佈式多節點運行等，而且能夠和Hadoop/MapReduce進行集成。

Vertica官網：http://www.vertica.com/

4、Cassandra

貢獻者：facebook

相關文章：開源分佈式NoSQL數據庫系統——Cassandra Cassandra與HBase的大數據對決 誰是勝者？

簡 介：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。

Cassandra官網：http://cassandra.apache.org/

5、HyperTable

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

第 一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的文件系統，提供了一個全局的命名空間。它經過跨機器（和跨機架）的文件數據複製來達到高可用性，並所以免受傳統 文件存儲系統沒法避免的許多失敗的影響，好比電源、內存和網絡端口等失敗。第二個基礎設施是名爲Map-Reduce的計算框架，它與GFS緊密協做，幫 助處理收集到的海量數據。第三個基礎設施是Bigtable，它是傳統數據庫的替代。Bigtable讓你能夠經過一些主鍵來組織海量數據，並實現高效的 查詢。Hypertable是Bigtable的一個開源實現，而且根據咱們的想法進行了一些改進。

HyperTable官網：http://hypertable.org/

6、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還包含了對監控支持的改善。這種監控機制不只僅是簡單的機器檢查，它添加了對多種潛在的硬件瓶頸的診斷，而且把那些高層級的信息整合到現有監控基礎架構中。

官網：https://foundationdb.com/

七：HBase

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

簡 介：HBase是一個分佈式的、面向列的開源數據庫，該技術來源於Fay Chang所撰寫的Google論文「Bigtable：一個結構化數據的分佈式存儲系統」。就像Bigtable利用了Google文件系統（File System）所提供的分佈式數據存儲同樣，HBase在Hadoop之上提供了相似於Bigtable的能力。HBase是Apache的Hadoop 項目的子項目。HBase不一樣於通常的關係數據庫，它是一個適合於非結構化數據存儲的數據庫。另外一個不一樣的是HBase基於列的而不是基於行的模式。

官網：http://hbase.apache.org/

文件存儲

1、CouchDB

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

特色：

1、 CouchDB是分佈式的數據庫，他能夠把存儲系統分佈到n臺物理的節點上面，而且很好的協調和同步節點之間的數據讀寫一致性。這固然也得靠Erlang 無與倫比的併發特性才能作到。對於基於web的大規模應用文檔應用，分佈式可讓它沒必要像傳統的關係數據庫那樣分庫拆表，在應用代碼層進行大量的改動。

2、CouchDB是面向文檔的數據庫，存儲半結構化的數據，比較相似lucene的index結構，特別適合存儲文檔，所以很適合CMS，電話本，地址本等應用，在這些應用場合，文檔數據庫要比關係數據庫更加方便，性能更好。

3、CouchDB支持REST API，可讓用戶使用JavaScript來操做CouchDB數據庫，也能夠用JavaScript編寫查詢語句，咱們能夠想像一下，用AJAX技術結合CouchDB開發出來的CMS系統會是多麼的簡單和方便。

其實CouchDB只是Erlang應用的冰山一角，在最近幾年，基於Erlang的應用也獲得的蓬勃的發展，特別是在基於web的大規模，分佈式應用領域，幾乎都是Erlang的優點項目。

官網：http://couchdb.apache.org/

2、MongoDB

簡介：MongoDB是一個基於分佈式文件存儲的數據庫。由C++語言編寫。旨在爲WEB應用提供可擴展的高性能數據存儲解決方案。

MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構很是鬆散，是相似json的bson 格式，所以能夠存儲比較複雜的數據類型。Mongo最大的特色是他支持的查詢語言很是強大，其語法有點相似於面向對象的查詢語言，幾乎能夠實現相似關係數 據庫單表查詢的絕大部分功能，並且還支持對數據創建索引。

 

第二部分主要收集整理的內容主要有日誌收集系統、消息系統、分佈式服務、集羣管理、RPC、基礎設施、搜索引擎、Iaas和監控管理等大數據開源工具。

　　日誌收集系統

　　1、Facebook Scribe

　　貢獻者：Facebook

　　簡介：Scribe是Facebook開源的日誌收集系統，在Facebook內部已經獲得大量的應用。它 可以從各類日誌源上收集日誌，存儲到一箇中央存儲系統（能夠是NFS，分佈式文件系統等）上，以便於進行集中統計分析處理。它爲日誌的「分佈式收集，統一 處理」提供了一個可擴展的，高容錯的方案。當中央存儲系統的網絡或者機器出現故障時，scribe會將日誌轉存到本地或者另外一個位置，當中央存儲系統恢復 後，scribe會將轉存的日誌從新傳輸給中央存儲系統。其一般與Hadoop結合使用，scribe用於向HDFS中push日誌，而Hadoop經過 MapReduce做業進行按期處理。

　　Scribe的系統架構

　　代碼託管：https://github.com/facebook/scribe

　　2、Cloudera Flume

　　貢獻者：Cloudera

　　簡介：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構架：

　　官網：http://flume.apache.org/

　　3、logstash

　　簡介：logstash 是一個應用程序日誌、事件的傳輸、處理、管理和搜索的平臺。你能夠用它來統一對應用程序日誌進行收集管理，提供 Web 接口用於查詢和統計。他能夠對你的日誌進行收集、分析，並將其存儲供之後使用（如，搜索），您能夠使用它。說到搜索，logstash帶有一個web界 面，搜索和展現全部日誌。

　　官網：http://www.logstash.net/

　　4、kibana

　　簡介：Kibana 是一個爲 Logstash 和 ElasticSearch 提供的日誌分析的 Web 接口。可以使用它對日誌進行高效的搜索、可視化、分析等各類操做。kibana 也是一個開源和免費的工具，他能夠幫助您彙總、分析和搜索重要數據日誌並提供友好的web界面。他能夠爲 Logstash 和 ElasticSearch 提供的日誌分析的 Web 界面。

　　主頁： http://kibana.org/

　　代碼託管： https://github.com/rashidkpc/Kibana/downloads

　　消息系統

　　1、StormMQ

　　簡介：MQMessageQueue消息隊列產品 StormMQ，是一種服務程序。

　　官網：http://stormmq.com/

　　2、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讓編寫高性能網絡應用程序極爲簡單和有趣。」

　　官網：http://zeromq.org/

　　3、RabbitMQ

　　簡介：RabbitMQ是一個受歡迎的消息代理，一般用於應用程序之間或者程序的不一樣組件之間經過消息來進行集成。本文簡單介紹瞭如何使用 RabbitMQ，假定你已經配置好了rabbitmq服務器。

　　RabbitMQ是用Erlang，對於主要的編程語言都有驅動或者客戶端。咱們這裏要用的是Java，因此先要得到Java客戶端。

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

　　官網：https://www.rabbitmq.com/

　　4、Apache ActiveMQ

　　簡介：ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現，儘管JMS規範出臺已是好久的事情了，可是JMS在當今的J2EE應用中間仍然扮演着特殊的地位。

　　特性：

　　⒈ 多種語言和協議編寫客戶端。語言: 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，進行測試

　　官網：http://activemq.apache.org/

　　5、Jafka

　　貢獻者：LinkedIn

　　簡介：Jafka 是一個開源的、高性能的、跨語言分佈式消息系統，使用GitHub託管。Jafka 最先是由Apache孵化的Kafka（由LinkedIn捐助給Apache）克隆而來。因爲是一個開放式的數據傳輸協議，所以除了Java開發語言受 到支持，Python、Ruby、C、C++等其餘語言也可以很好的獲得支持。

　　特性：

　　一、消息持久化很是快，服務端存儲消息的開銷爲O(1)，而且基於文件系統，可以持久化TB級的消息而不損失性能。

　　二、吞吐量取決於網絡帶寬。

　　三、徹底的分佈式系統，broker、producer、consumer都原生自動支持分佈式。自動實現複雜均衡。

　　四、內核很是小，整個系統（包括服務端和客戶端）只有一個272KB的jar包，內部機制也不復雜，適合進行內嵌或者二次開發 。整個服務端加上依賴組件共3.5MB。

　　五、消息格式以及通訊機制很是簡單，適合進行跨語言開發。目前自帶的Python3.x的客戶端支持發送消息和接收消息。

　　官網：http://kafka.apache.org/

　　6、Apache Kafka

　　貢獻者：LinkedIn

　　簡介：Apache Kafka是由Apache軟件基金會開發的一個開源消息系統項目，由Scala寫成。Kafka最初是由LinkedIn開發，並於2011年初開源。 2012年10月從Apache Incubator畢業。該項目的目標是爲處理實時數據提供一個統1、高通量、低等待的平臺。

　　Kafka是一個分佈式的、分區的、多複本的日誌提交服務。它經過一種獨一無二的設計提供了一個消息系統的功能。

　　Kafka集羣能夠在一個指定的時間內保持全部發布上來的消息，無論這些消息有沒有被消費。打個比方，若是這個時間設置爲兩天，那麼在消息發佈 的兩天之內，這條消息都是能夠被消費的，可是在兩天後，這條消息就會被系統丟棄以釋放空間。Kafka的性能不會受數據量的大小影響，所以保持大量的數據 不是一個問題。

　　官網：http://kafka.apache.org/

　　分佈式服務

　　1、ZooKeeper

　　貢獻者：Google

　　簡介：ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、名字服務、分佈式同步、組服務等。

　　ZooKeeper是以Fast Paxos算法爲基礎的，paxos算法存在活鎖的問題，即當有多個proposer交錯提交時，有可能互相排斥致使沒有一個proposer能提交成 功，而Fast Paxos做了一些優化，經過選舉產生一個leader，只有leader才能提交propose，具體算法可見Fast Paxos。所以，要想弄懂ZooKeeper首先得對Fast Paxos有所瞭解。

　　架構：

　　官網：http://zookeeper.apache.org/

　　RPC

　　（Remote Procedure Call Protocol）——遠程過程調用協議

　　1、Apache Avro

　　簡介：Apache Avro是Hadoop下的一個子項目。它自己既是一個序列化框架，同時也實現了RPC的功能。Avro官網描述Avro的特性和功能以下：

　　豐富的數據結構類型；

　　快速可壓縮的二進制數據形式；

　　存儲持久數據的文件容器；

　　提供遠程過程調用RPC；

　　簡單的動態語言結合功能。

　　相比於Apache Thrift 和Google的Protocol Buffers，Apache Avro具備如下特色：

　　支持動態模式。Avro不須要生成代碼，這有利於搭建通用的數據處理系統，同時避免了代碼入侵。

　　數據無須加標籤。讀取數據前，Avro可以獲取模式定義，這使得Avro在數據編碼時只須要保留更少的類型信息，有利於減小序列化後的數據大小。

　　官網：http://avro.apache.org/

　　2、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構架：

　　官網：http://thrift.apache.org/

　　集羣管理

　　1、Nagios

　　簡介：Nagios是一款開源的免費網絡監視工具，能有效監控Windows、Linux和Unix的主機狀態，交換機路由器等網絡設置，打印機等。在系統或服務狀態異常時發出郵件或短信報警第一時間通知網站運維人員，在狀態恢復後發出正常的郵件或短信通知。

　　Nagios可運行在Linux/Unix平臺之上，同時提供一個可選的基於瀏覽器的WEB界面以方便系統管理人員查看網絡狀態，各類系統問題，以及日誌等等。

　　官網：http://www.nagios.org/

　　2、Ganglia

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

　　官網：http://ganglia.sourceforge.net/

　　3、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。

　　官網：http://ambari.apache.org/

　　基礎設施

　　1、LevelDB

　　貢獻者：Jeff Dean和Sanjay Ghemawat

　　簡介：Leveldb是一個google實現的很是高效的kv數據庫，目前的版本1.2可以支持 billion級別的數據量了。 在這個數量級別下還有着很是高的性能，主要歸功於它的良好的設計。特別是LMS算法。LevelDB 是單進程的服務，性能很是之高，在一臺4核Q6600的CPU機器上，每秒鐘寫數據超過40w，而隨機讀的性能每秒鐘超過10w。

　　Leveldb框架：

　　官網：http://code.google.com/p/leveldb/

　　2、SSTable

　　簡介：若是說Protocol Buffer是谷歌獨立數據記錄的通用語言 ，那麼有序字符串表（SSTable，Sorted String Table）則是用於存儲，處理和數據集交換的最流行​​的數據輸出格式。正如它的名字自己，SSTable是有效存儲大量鍵-值對的簡單抽象，對高吞吐 量順序讀/寫進行了優化。

　　SSTable是Bigtable中相當重要的一塊，對於LevelDB來講也是如此。

　　3、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.

　　詳細格式以下圖所示：

　　到這裏，你們可能已經知道，recordio之因此能對付壞數據，其實就是在這個MagicNumber（校驗值）。

　　4、Flat Buffers

　　貢獻者：Google

　　簡介：谷歌開源高效、跨平臺的序列化庫FlatBuffers。

　　該庫的構建是專門爲遊戲開發人員的性能需求提供支持，它將序列化數據存儲在緩存中，這些數據既能夠存儲在文件中，又能夠經過網絡原樣傳輸，而不須要任何解析開銷。

　　FlatBuffers有以下一些關鍵特性——

　　訪問序列化數據不須要打包/拆包

　　節省內存並且訪問速度快——緩存只佔用訪問數據所須要的內存；不須要任何額外的內存。

　　靈活性——經過可選字段向前向後兼容

　　代碼規模小

　　強類型——錯誤在編譯時捕獲，而不是在運行時

　　便利性——生成的C++頭文件代碼簡潔。若是須要，有一項可選功能能夠用來在運行時高效解析Schema和JSON-like格式的文本。

　　跨平臺——使用C++編寫，不依賴STL以外的庫，所以能夠用於任何有C++編輯器的平臺。當前，該項目包含構建方法和在Android、Linux、Windows和OSX等操做系統上使用該庫的示例。

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

　　代碼託管：https://github.com/google/flatbuffers

　　5、Protocol Buffers

　　貢獻者：Google

　　簡介：Protocol Buffers是Google公司開發的一種數據描述語言，相似於XML可以將結構化數據序列化，可用於數據存儲、通訊協議等方面。它不依賴於語言和平臺 而且可擴展性極強。現階段官方支持C++、JAVA、Python等三種編程語言，但能夠找到大量的幾乎涵蓋全部語言的第三方拓展包。

　　經過它，你能夠定義你的數據的結構，並生成基於各類語言的代碼。這些你定義的數據流能夠輕鬆地在傳遞並不破壞你已有的程序。而且你也能夠更新這些數據而現有的程序也不會受到任何的影響。

　　Protocol Buffers常常被簡稱爲protobuf。

　　官網：http://code.google.com/p/protobuf/

　　6、Consistent Hashing（哈希算法）

　　簡介：一致性哈希算法在1997年由麻省理工學院提出的一種分佈式哈希（DHT）實現算法，設計目標是爲了 解決因特網中的熱點(Hot spot)問題，初衷和CARP十分相似。一致性哈希修正了CARP使用的簡 單哈希算法帶來的問題，使得分佈式哈希（DHT）能夠在P2P環境中真正獲得應用。

　　一致性hash算法提出了在動態變化的Cache環境中，斷定哈希算法好壞的四個定義：

　　一、平衡性(Balance)：平衡性是指哈希的結果可以儘量分佈到全部的緩衝中去，這樣能夠使得全部的緩衝空間都獲得利用。不少哈希算法都可以知足這一條件。

　　二、單調性(Monotonicity)：單調性是指若是已經有一些內容經過哈希分派到了相應的緩衝中，又有新的緩衝加入到系統中。哈希的結果應可以保證原有已分配的內容能夠被映射到原有的或者新的緩衝中去，而不會被映射到舊的緩衝集合中的其餘緩衝區。

　　三、分散性(Spread)：在分佈式環境中，終端有可能看不到全部的緩衝，而是隻能看到其中的一部分。當終端但願經過哈希過程將內容映射到緩 衝上時，因爲不一樣終端所見的緩衝範圍有可能不一樣，從而致使哈希的結果不一致，最終的結果是相同的內容被不一樣的終端映射到不一樣的緩衝區中。這種狀況顯然是應 該避免的，由於它致使相同內容被存儲到不一樣緩衝中去，下降了系統存儲的效率。分散性的定義就是上述狀況發生的嚴重程度。好的哈希算法應可以儘可能避免不一致 的狀況發生，也就是儘可能下降分散性。

　　四、負載(Load)：負載問題其實是從另外一個角度看待分散性問題。既然不一樣的終端可能將相同的內容映射到不一樣的緩衝區中，那麼對於一個特定 的緩衝區而言，也可能被不一樣的用戶映射爲不一樣 的內容。與分散性同樣，這種狀況也是應當避免的，所以好的哈希算法應可以儘可能下降緩衝的負荷。

　　在分佈式集羣中，對機器的添加刪除，或者機器故障後自動脫離集羣這些操做是分佈式集羣管理最基本的功能。若是採用經常使用的hash(object)%N算法，那麼在有機器添加或者刪除後，不少原有的數據就沒法找到了，這樣嚴重的違反了單調性原則。

　　7、Netty

　　貢獻者：JBOSS

　　簡介：Netty是由JBOSS提供的一個java開源框架。Netty提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。

　　也就是說，Netty 是一個基於NIO的客戶，服務器端編程框架，使用Netty 能夠確保你快速和簡單的開發出一個網絡應用，例如實現了某種協議的客戶，服務端應用。Netty至關簡化和流線化了網絡應用的編程開發過程，例如，TCP 和UDP的socket服務開發。

　　「快速」和「簡單」並不意味着會讓你的最終應用產生維護性或性能上的問題。Netty 是一個吸取了多種協議的實現經驗，這些協議包括FTP,SMTP,HTTP，各類二進制，文本協議，並通過至關精心設計的項目，最終，Netty 成功的找到了一種方式，在保證易於開發的同時還保證了其應用的性能，穩定性和伸縮性。

　　官網：http://netty.io/

　　8、BloomFilter

　　簡介：Bloom filter 是由 Howard Bloom 在 1970 年提出的二進制向量數據結構，它具備很好的空間和時間效率，被用來檢測一個元素是否是集合中的一個成員。若是檢測結果爲是，該元素不必定在集合中；但若是 檢測結果爲否，該元素必定不在集合中。所以Bloom filter具備100%的召回率。這樣每一個檢測請求返回有「在集合內（可能錯誤）」和「不在集合內（絕對不在集合內）」兩種狀況，可見 Bloom filter 是犧牲了正確率和時間以節省空間。

　　Bloom filter 優勢就是它的插入和查詢時間都是常數，另外它查詢元素卻不保存元素自己，具備良好的安全性。

　　搜索引擎

　　1、Nutch

　　簡介：Nutch 是一個開源Java 實現的搜索引擎。它提供了咱們運行本身的搜索引擎所需的所有工具。包括全文搜索和Web爬蟲。

　　儘管Web搜索是漫遊Internet的基本要求, 可是現有web搜索引擎的數目卻在降低. 而且這頗有可能進一步演變成爲一個公司壟斷了幾乎全部的web搜索爲其謀取商業利益.這顯然 不利於廣大Internet用戶.

　　Nutch爲咱們提供了這樣一個不一樣的選擇. 相對於那些商用的搜索引擎, Nutch做爲開放源代碼 搜索引擎將會更加透明, 從而更值得你們信賴. 如今全部主要的搜索引擎都採用私有的排序算法, 而不會解釋爲何一個網頁會排在一個特定的位置. 除此以外, 有的搜索引擎依照網站所付的 費用, 而不是根據它們自己的價值進行排序. 與它們不一樣, Nucth沒有什麼須要隱瞞, 也沒有 動機去扭曲搜索的結果. Nutch將盡本身最大的努力爲用戶提供最好的搜索結果.

　　Nutch目前最新的版本爲version v2.2.1。

　　官網：https://nutch.apache.org/

　　2、Lucene

　　開發者：Doug Cutting（Hadoop之父，你懂的）

　　簡介：Lucene是apache軟件基金會4 jakarta項目組的一個子項目，是一個開放源代碼的全文檢索引擎工具包，即它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構，提供了完整的 查詢引擎和索引引擎，部分文本分析引擎（英文與德文兩種西方語言）。Lucene的目的是爲軟件開發人員提供一個簡單易用的工具包，以方便的在目標系統中 實現全文檢索的功能，或者是以此爲基礎創建起完整的全文檢索引擎。

　　官網：http://lucene.apache.org/

　　3、SolrCloud

　　簡介：SolrCloud是Solr4.0版本之後基於Solr和Zookeeper的分佈式搜索方案。SolrCloud是Solr的基於Zookeeper一種部署方式。Solr能夠以多種方式部署，例如單機方式，多機Master-Slaver方式。

　　原理圖：

　　SolrCloud有幾個特點功能：

　　集中式的配置信息使用ZK進行集中配置。啓動時能夠指定把Solr的相關配置文件上傳

　　Zookeeper，多機器共用。這些ZK中的配置不會再拿到本地緩存，Solr直接讀取ZK中的配置信息。配置文件的變更，全部機器均可以感 知到。另外，Solr的一些任務也是經過ZK做爲媒介發佈的。目的是爲了容錯。接收到任務，但在執行任務時崩潰的機器，在重啓後，或者集羣選出候選者時， 能夠再次執行這個未完成的任務。

　　自動容錯SolrCloud對索引分片，並對每一個分片建立多個Replication。每一個Replication均可以對外提供服務。一個 Replication掛掉不會影響索引服務。更強大的是，它還能自動的在其它機器上幫你把失敗機器上的索引Replication重建並投入使用。

　　近實時搜索當即推送式的replication（也支持慢推送）。能夠在秒內檢索到新加入索引。

　　查詢時自動負載均衡SolrCloud索引的多個Replication能夠分佈在多臺機器上，均衡查詢壓力。若是查詢壓力大，能夠經過擴展機器，增長Replication來減緩。

　　自動分發的索引和索引分片發送文檔到任何節點，它都會轉發到正確節點。

　　事務日誌事務日誌確保更新無丟失，即便文檔沒有索引到磁盤。

　　4、Solr

　　簡介：Solr是一個獨立的企業級搜索應用服務器，它對外提供相似於Web-service的API接口。用戶能夠經過http請求，向搜索引擎服務器提交必定格式的XML文件，生成索引；也能夠經過Http Get操做提出查找請求，並獲得XML格式的返回結果。

　　Solr是一個高性能，採用Java5開發，基於Lucene的全文搜索服務器。同時對其進行了擴展，提供了比Lucene更爲豐富的查詢語言，同時實現了可配置、可擴展並對查詢性能進行了優化，而且提供了一個完善的功能管理界面，是一款很是優秀的全文搜索引擎。

　　官網：https://lucene.apache.org/solr/

　　5、ElasticSearch

　　簡介：ElasticSearch是一個基於Lucene的搜索服務器。它提供了一個分佈式多用戶能力的全 文搜索引擎，基於RESTful web接口。Elasticsearch是用Java開發的，並做爲Apache許可條款下的開放源碼發佈，是第二最流行的企業搜索引擎。設計用於雲計算 中，可以達到實時搜索，穩定，可靠，快速，安裝使用方便。

　　官網：http://www.elasticsearch.org/

　　6、Sphinx

　　簡介：Sphinx是一個基於SQL的全文檢索引擎，能夠結合MySQL,PostgreSQL作全文搜 索，它能夠提供比數據庫自己更專業的搜索功能，使得應用程序更容易實現專業化的全文檢索。Sphinx特別爲一些腳本語言設計搜索API接口，如 PHP,Python,Perl,Ruby等，同時爲MySQL也設計了一個存儲引擎插件。

　　Sphinx單一索引最大可包含1億條記錄，在1千萬條記錄狀況下的查詢速度爲0.x秒（毫秒級）。Sphinx建立索引的速度爲：建立100 萬條記錄的索引只需 3～4分鐘，建立1000萬條記錄的索引能夠在50分鐘內完成，而只包含最新10萬條記錄的增量索引，重建一次只需幾十秒。

　　官網：http://sphinxsearch.com

　　7、SenseiDB

　　貢獻者：linkedin

　　簡介：SenseiDB是一個NoSQL數據庫，它專一於高更新率以及複雜半結構化搜索查詢。熟悉 Lucene和Solor的用戶會發現，SenseiDB背後有許多似曾相識的概念。SenseiDB部署在多節點集羣中，其中每一個節點能夠包括N塊數據 片。Apache Zookeeper用於管理節點，它可以保持現有配置，並能夠將任意改動（如拓撲修改）傳輸到整個節點羣中。SenseiDB集羣還須要一種模式用於定義 將要使用的數據模型。

　　從SenseiDB集羣中獲取數據的惟一方法是經過Gateways（它 沒有「INSERT」方法）。每一個集羣都鏈接到一個單一gateway。你須要瞭解很重要的一點是，因爲SenseiDB自己無法處理原子性 （Atomicity）和隔離性（Isolation），所以只能經過外部在gateway層進行限制。另外，gateway必須確保數據流按照預期的方 式運做。內置的gateway有如下幾種形式：

　　來自文件

　　來自JMS隊列

　　經過JDBC

　　來自Apache Kafka

　　官網：http://senseidb.com

　　數據挖掘

　　1、Mahout

　　簡介：Apache Mahout 是 Apache Software Foundation (ASF) 開發的一個全新的開源項目，其主要目標是建立一些可伸縮的機器學習算法，供開發人員在 Apache 在許可下無償使用。該項目已經發展到了它的最二個年頭，目前只有一個公共發行版。Mahout 包含許多實現，包括集羣、分類、CP 和進化程序。此外，經過使用 Apache Hadoop 庫，Mahout 能夠有效地擴展到雲中。

　　雖然在開源領域中相對較爲年輕，但 Mahout 已經提供了大量功能，特別是在集羣和 CF 方面。Mahout 的主要特性包括：

　　Taste CF。Taste 是 Sean Owen 在 SourceForge 上發起的一個針對 CF 的開源項目，並在 2008 年被贈予 Mahout。

　　一些支持 Map-Reduce 的集羣實現包括 k-Means、模糊 k-Means、Canopy、Dirichlet 和 Mean-Shift。

　　Distributed Naive Bayes 和 Complementary Naive Bayes 分類實現。

　　針對進化編程的分佈式適用性功能。

　　Matrix 和矢量庫。

　　上述算法的示例。

　　官網：http://mahout.apache.org/

　　Iaas

　　IaaS（Infrastructure as a Service），即基礎設施即服務。

　　1、OpenStack

　　簡介：OpenStack是一個由NASA（美國國家航空航天局）和Rackspace合做研發併發起的，以Apache許可證受權的自由軟件和開放源代碼項目。

　　OpenStack是一個開源的雲計算管理平臺項目，由幾個主要的組件組合起來完成具體工做。OpenStack支持幾乎全部類型的雲環境，項 目目標是提供實施簡單、可大規模擴展、豐富、標準統一的雲計算管理平臺。OpenStack經過各類互補的服務提供了基礎設施即服務（IaaS）的解決方 案，每一個服務提供API以進行集成。

　　6個核心項目：Nova（計算，Compute），Swift（對象存儲，Object），Glance（鏡 像，Image），Keystone（身份，Identity），Horizon（自助門戶，Dashboard），Quantum &Melange（網絡&地址管理），另外還有若干社區項目，如Rackspace（負載均衡）、Rackspace（關係型數據庫）。

　　相關閱讀：

　　什麼是OpenStack？

　　成功部署OpenStack的十大要點

　　 官網：https://www.openstack.org/

　　2、Docker

　　貢獻者：dotCloud

　　簡介：Docker 是一個開源的應用容器引擎，讓開發者能夠打包他們的應用以及依賴包到一個可移植的容器中，而後發佈到任何流行的 Linux 機器上，也能夠實現虛擬化。容器是徹底使用沙箱機制，相互之間不會有任何接口（相似 iPhone 的 app）。幾乎沒有性能開銷,能夠很容易地在機器和數據中心中運行。最重要的是,他們不依賴於任何語言、框架或包括系統。

　　官網：http://www.docker.io/

　　3、Kubernetes

　　貢獻者：Google

　　簡介：Kubernetes是Google開源的容器集羣管理系統。它構建Ddocker技術之上，爲容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能，本質上可看做是基於容器技術的mini-PaaS平臺。

　　Kubernetes從另外一個角度對資源進行抽象，它讓開發人員和管理人員共同着眼於服務的行爲和性能的提高，而不是僅僅關注對單一的組件或者是基礎資源。

　　那麼Kubernetes集羣到底提供了哪些單一容器所沒有功能?它主要關注的是對服務級別的控制而並不是僅僅是對容器級別的控 制，Kubernetes提供了一種「機智」的管理方式，它將服務當作一個總體。在Kubernete的解決方案中，一個服務甚至能夠自我擴展，自我診 斷，而且容易升級。例如，在Google中，咱們使用機器學習技術來保證每一個運行的服務的當前狀態都是最高效的。

　　代碼託管：https://github.com/GoogleCloudPlatform/kubernetes/

　　4、Imctfy

　　貢獻者：Google

　　簡介：Google開源了本身所用Linux容器系統的開源版本lmctfy，讀音爲lem-kut-fee。包括一個C++庫（使用了C++11，文檔能夠參考頭文件）和命令行界面。目前的版本是0.1，只提供了CPU與內存隔離。項目還在密集開發中。

　　mctfy自己是針對某些特定使用場景設計和實現的，目前擁有一臺機器上全部容器時運行狀況最好，不推薦與LXC和其餘容器系統一塊兒使用（雖然也可行）。已在Ubuntu 12.04+和Ubuntu 3.3與3.8內核上測試。

　　代碼託管：https://github.com/google/Imctfy/

　　監控管理

　　1、Dapper

　　貢獻者：Google

　　簡介：Dapper是一個輕量的ORM(對象關係映射（英語：Object Relational Mapping，簡稱ORM，或O/RM，或O/R mapping）。並不單純的是一個DBHelper.由於在Dapper中數據其實就是一個對象。Dapper擴展與IDbConnection上，所 以事實上它的傾入性很低。我用了StructureMap。若是不喜歡能夠本身更換，或者本身實現下。

　　代碼就一個SqlMapper.cs文件,主要是IDbConnection的擴展方法，編譯後就40K的一個很小的dll。

　　特性：

　　Dapper很快。Dapper的速度接近與IDataReader。

　　Dapper支持主流數據庫 Mysql,SqlLite,Mssql2000,Mssql2005,Oracle等一系列的數據庫

　　支持多表並聯的對象。支持一對多 多對多的關係，而且沒侵入性。

　　原理經過Emit反射IDataReader的序列隊列，來快速的獲得和產生對象

　　Dapper語法十分簡單。而且無須遷就數據庫的設計

　　官方站點http://code.google.com/p/dapper-dot-net/

　　代碼託管：http://bigbully.github.io/Dapper-translation/

　　2、Zipkin

　　貢獻者：Twitter

　　簡介：Zipkin （分佈式跟蹤系統）是 Twitter 的一個開源項目，容許開發者收集 Twitter 各個服務上的監控數據，並提供查詢接口。該系統讓開發者可經過一個 Web 前端輕鬆的收集和分析數據，例如用戶每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。

　　官方網站：http://twitter.github.io/zipkin/

　　代碼託管：https://github.com/twitter/zipkin/