開源大數據處理工具彙總（二）

日誌收集系統

一、Facebook Scribe

貢獻者：Facebook

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

Scribe的系統架構

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

二、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/

三、logstash

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

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

四、kibana

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

主頁： http://kibana.org/

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

消息系統

一、StormMQ

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

官網：http://stormmq.com/

二、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/

三、RabbitMQ

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

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

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

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

四、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/

五、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的客戶端支持發送消息和接收消息。

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

六、Apache Kafka

貢獻者：LinkedIn

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

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

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

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

分佈式服務

一、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）——遠程過程調用協議

一、Apache Avro

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

• 豐富的數據結構類型；
• 快速可壓縮的二進制數據形式；
• 存儲持久數據的文件容器；
• 提供遠程過程調用RPC；
• 簡單的動態語言結合功能。

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

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

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

二、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/

集羣管理

一、Nagios

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

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

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

二、Ganglia

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

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

三、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/

 

基礎設施

一、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/

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

詳細格式如下圖所示：

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

四、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

五、Protocol Buffers

貢獻者：Google

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

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

Protocol Buffers經常被簡稱爲protobuf。

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

六、Consistent Hashing（哈希算法）

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

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

1、平衡性(Balance)：平衡性是指哈希的結果能夠儘可能分佈到所有的緩衝中去，這樣可以使得所有的緩衝空間都得到利用。很多哈希算法都能夠滿足這一條件。

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

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

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

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

七、Netty

貢獻者：JBOSS

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

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

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

官網：http://netty.io/

八、BloomFilter

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

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

搜索引擎

一、Nutch

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

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

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

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

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

二、Lucene

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

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

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

三、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來減緩。

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

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

四、Solr

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

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

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

五、ElasticSearch

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

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

六、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

七、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

數據挖掘

一、Mahout

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

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

1. Taste CF。Taste 是 Sean Owen 在 SourceForge 上發起的一個針對 CF 的開源項目，並在 2008 年被贈予 Mahout。
2. 一些支持 Map-Reduce 的集羣實現包括 k-Means、模糊 k-Means、Canopy、Dirichlet 和 Mean-Shift。
3. Distributed Naive Bayes 和 Complementary Naive Bayes 分類實現。
4. 針對進化編程的分佈式適用性功能。
5. Matrix 和矢量庫。
6. 上述算法的示例。

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

Iaas

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

一、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/

二、Docker

貢獻者：dotCloud

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

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

三、Kubernetes

貢獻者：Google

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

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

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

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

四、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/

 

監控管理

一、Dapper

貢獻者：Google

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

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

特性：

1. Dapper很快。Dapper的速度接近與IDataReader。
2. Dapper支持主流數據庫 Mysql,SqlLite,Mssql2000,Mssql2005,Oracle等一系列的數據庫
3. 支持多表並聯的對象。支持一對多 多對多的關係，並且沒侵入性。
4. 原理通過Emit反射IDataReader的序列隊列，來快速的得到和產生對象
5. Dapper語法十分簡單。並且無須遷就數據庫的設計

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

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

二、Zipkin

貢獻者：Twitter

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

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

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

End.