一共81個，開源大數據處理工具彙總（下），包括日誌收集系統/集羣管理/RPC等

時間 2019-12-04

原文原文鏈接

做者：大數據女神-諾藍（微信公號：dashujunvshen）。本文是36大數據專稿，轉載必須標明來源36大數據。 前端

接上一部分：一共81個，開源大數據處理工具彙總（上），第二部分主要收集整理的內容主要有日誌收集系統、消息系統、分佈式服務、集羣管理、RPC、基礎設施、搜索引擎、Iaas和監控管理等大數據開源工具。 java

日誌收集系統

1、Facebook Scribe node

貢獻者：Facebook ios

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

Scribe的系統架構 github

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

2、Cloudera Flume 算法

貢獻者：Cloudera sql

簡介：Flume是Cloudera提供的一個高可用的，高可靠的，分佈式的海量日誌採集、聚合和傳輸的系統，Flume支持在日誌系統中定製各種數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各類數據接受方（可定製）的能力。 docker

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。

特性：