//
一共81個，開源大數(shù)據(jù)處理工具匯總（下），包括日志收集系統(tǒng)/集群管理/RPC等 | 36大數(shù)據(jù)
http://www.36dsj.com/archives/25042
接上一部分：一共81個，開源大數(shù)據(jù)處理工具匯總（上），第二部分主要收集整理的內(nèi)容主要有日志收集系統(tǒng)、消息系統(tǒng)、分布式服務(wù)、集群管理、RPC、基礎(chǔ)設(shè)施、搜索引擎、Iaas和監(jiān)控管理等大數(shù)據(jù)開源工具。
日志收集系統(tǒng)
一、Facebook Scribe
貢獻(xiàn)者：Facebook
簡介：Scribe是Facebook開源的日志收集系統(tǒng)，在Facebook內(nèi)部已經(jīng)得到大量的應(yīng)用。它能夠從各種日志源上收集日志，存儲到一個中央存儲系統(tǒng)（可以是NFS，分布式文件系統(tǒng)等）上，以便于進(jìn)行集中統(tǒng)計分析處理。它為日志的“分布式收集，統(tǒng)一處理”提供了一個可擴(kuò)展的，高容錯的方案。當(dāng)中央存儲系統(tǒng)的網(wǎng)絡(luò)或者機(jī)器出現(xiàn)故障時，scribe會將日志轉(zhuǎn)存到本地或者另一個位置，當(dāng)中央存儲系統(tǒng)恢復(fù)后，scribe會將轉(zhuǎn)存的日志重新傳輸給中央存儲系統(tǒng)。其通常與Hadoop結(jié)合使用，scribe用于向HDFS中push日志，而Hadoop通過MapReduce作業(yè)進(jìn)行定期處理。
Scribe的系統(tǒng)架構(gòu)
代碼托管：https://github.com/facebook/scribe
二、Cloudera Flume
貢獻(xiàn)者：Cloudera
簡介：Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，F(xiàn)lume提供對數(shù)據(jù)進(jìn)行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力。
Flume提供了從console（控制臺）、RPC（Thrift-RPC）、text（文件）、tail（UNIX tail）、syslog（syslog日志系統(tǒng)，支持TCP和UDP等2種模式），exec（命令執(zhí)行）等數(shù)據(jù)源上收集數(shù)據(jù)的能力。
當(dāng)前Flume有兩個版本Flume 0.9X版本的統(tǒng)稱Flume-og，F(xiàn)lume1.X版本的統(tǒng)稱Flume-ng。由于Flume-ng經(jīng)過重大重構(gòu)，與Flume-og有很大不同，使用時請注意區(qū)分。
Cloudera Flume構(gòu)架：
官網(wǎng)：http://flume.apache.org/
三、logstash
簡介：logstash 是一個應(yīng)用程序日志、事件的傳輸、處理、管理和搜索的平臺。你可以用它來統(tǒng)一對應(yīng)用程序日志進(jìn)行收集管理，提供 Web 接口用于查詢和統(tǒng)計。他可以對你的日志進(jìn)行收集、分析，并將其存儲供以后使用（如，搜索），您可以使用它。說到搜索，logstash帶有一個web界面，搜索和展示所有日志。
官網(wǎng)：http://www.logstash.net/
四、kibana
簡介：Kibana 是一個為 Logstash 和 ElasticSearch 提供的日志分析的 Web 接口?？墒褂盟鼘θ罩具M(jìn)行高效的搜索、可視化、分析等各種操作。kibana 也是一個開源和免費的工具，他可以幫助您匯總、分析和搜索重要數(shù)據(jù)日志并提供友好的web界面。他可以為 Logstash 和 ElasticSearch 提供的日志分析的 Web 界面。
主頁： http://kibana.org/
代碼托管： https://github.com/rashidkpc/Kibana/downloads
消息系統(tǒng)
一、StormMQ
簡介：MQMessageQueue消息隊列產(chǎn)品 StormMQ，是一種服務(wù)程序。
官網(wǎng)：http://stormmq.com/
二、ZeroMQ
簡介：這是個類似于Socket的一系列接口，他跟Socket的區(qū)別是：普通的socket是端到端的（1:1的關(guān)系），而ZMQ卻是可以N：M 的關(guān)系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協(xié)議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細(xì)節(jié)，讓你的網(wǎng)絡(luò)編程更為簡單。ZMQ用于node與node間的通信，node可以是主機(jī)或者是進(jìn)程。
引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內(nèi)核和主機(jī)盒之間彈性伸縮。ZMQ的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分，之后進(jìn)入Linux內(nèi)核”?，F(xiàn)在還未看到它們的成功。但是，它無疑是極具前景的、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網(wǎng)絡(luò)應(yīng)用程序極為簡單和有趣?！?br> 官網(wǎng)：http://zeromq.org/
三、RabbitMQ
簡介：RabbitMQ是一個受歡迎的消息代理，通常用于應(yīng)用程序之間或者程序的不同組件之間通過消息來進(jìn)行集成。本文簡單介紹了如何使用 RabbitMQ，假定你已經(jīng)配置好了rabbitmq服務(wù)器。
RabbitMQ是用Erlang，對于主要的編程語言都有驅(qū)動或者客戶端。我們這里要用的是Java，所以先要獲得Java客戶端。
像RabbitMQ這樣的消息代理可用來模擬不同的場景，例如點對點的消息分發(fā)或者訂閱/推送。我們的程序足夠簡單，有兩個基本的組件，一個生產(chǎn)者用于產(chǎn)生消息，還有一個消費者用來使用產(chǎn)生的消息。
官網(wǎng)：https://www.rabbitmq.com/
四、Apache ActiveMQ
簡介：ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn)，盡管JMS規(guī)范出臺已經(jīng)是很久的事情了，但是JMS在當(dāng)今的J2EE應(yīng)用中間仍然扮演著特殊的地位。
特性：
⒈ 多種語言和協(xié)議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應(yīng)用協(xié)議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4規(guī)范 （持久化，XA消息，事務(wù))
⒊ 對Spring的支持，ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性
⒋ 通過了常見J2EE服務(wù)器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上
⒌ 支持多種傳送協(xié)議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通過JDBC和journal提供高速的消息持久化
⒎ 從設(shè)計上保證了高性能的集群，客戶端-服務(wù)器，點對點
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 可以很容易得調(diào)用內(nèi)嵌JMS provider，進(jìn)行測試
官網(wǎng)：http://activemq.apache.org/
五、Jafka
貢獻(xiàn)者：LinkedIn
簡介：Jafka 是一個開源的、高性能的、跨語言分布式消息系統(tǒng)，使用GitHub托管。Jafka 最早是由Apache孵化的Kafka（由LinkedIn捐助給Apache）克隆而來。由于是一個開放式的數(shù)據(jù)傳輸協(xié)議，因此除了Java開發(fā)語言受到支持，Python、Ruby、C、C++等其他語言也能夠很好的得到支持。
特性：
1、消息持久化非?？欤?wù)端存儲消息的開銷為O(1)，并且基于文件系統(tǒng)，能夠持久化TB級的消息而不損失性能。
2、吞吐量取決于網(wǎng)絡(luò)帶寬。
3、完全的分布式系統(tǒng)，broker、producer、consumer都原生自動支持分布式。自動實現(xiàn)復(fù)雜均衡。
4、內(nèi)核非常小，整個系統(tǒng)（包括服務(wù)端和客戶端）只有一個272KB的jar包，內(nèi)部機(jī)制也不復(fù)雜，適合進(jìn)行內(nèi)嵌或者二次開發(fā) 。整個服務(wù)端加上依賴組件共3.5MB。
5、消息格式以及通信機(jī)制非常簡單，適合進(jìn)行跨語言開發(fā)。目前自帶的Python3.x的客戶端支持發(fā)送消息和接收消息。
官網(wǎng)：http://kafka.apache.org/
六、Apache Kafka
貢獻(xiàn)者：LinkedIn
簡介：Apache Kafka是由Apache軟件基金會開發(fā)的一個開源消息系統(tǒng)項目，由Scala寫成。Kafka最初是由LinkedIn開發(fā)，并于2011年初開源。2012年10月從Apache Incubator畢業(yè)。該項目的目標(biāo)是為處理實時數(shù)據(jù)提供一個統(tǒng)一、高通量、低等待的平臺。
Kafka是一個分布式的、分區(qū)的、多復(fù)本的日志提交服務(wù)。它通過一種獨一無二的設(shè)計提供了一個消息系統(tǒng)的功能。
Kafka集群可以在一個指定的時間內(nèi)保持所有發(fā)布上來的消息，不管這些消息有沒有被消費。打個比方，如果這個時間設(shè)置為兩天，那么在消息發(fā)布的兩天以內(nèi)，這條消息都是可以被消費的，但是在兩天后，這條消息就會被系統(tǒng)丟棄以釋放空間。Kafka的性能不會受數(shù)據(jù)量的大小影響，因此保持大量的數(shù)據(jù)不是一個問題。
官網(wǎng)：http://kafka.apache.org/
分布式服務(wù)
一、ZooKeeper
貢獻(xiàn)者：Google
簡介：ZooKeeper是一個分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個開源的實現(xiàn)，是Hadoop和Hbase的重要組件。它是一個為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護(hù)、名字服務(wù)、分布式同步、組服務(wù)等。
ZooKeeper是以Fast Paxos算法為基礎(chǔ)的，paxos算法存在活鎖的問題，即當(dāng)有多個proposer交錯提交時，有可能互相排斥導(dǎo)致沒有一個proposer能提交成功，而Fast Paxos作了一些優(yōu)化，通過選舉產(chǎn)生一個leader，只有l(wèi)eader才能提交propose，具體算法可見Fast Paxos。因此，要想弄懂ZooKeeper首先得對Fast Paxos有所了解。
架構(gòu)：
官網(wǎng)：http://zookeeper.apache.org/
RPC
（Remote Procedure Call Protocol）——遠(yuǎn)程過程調(diào)用協(xié)議
一、Apache Avro
簡介：Apache Avro是Hadoop下的一個子項目。它本身既是一個序列化框架，同時也實現(xiàn)了RPC的功能。Avro官網(wǎng)描述Avro的特性和功能如下：
豐富的數(shù)據(jù)結(jié)構(gòu)類型；
快速可壓縮的二進(jìn)制數(shù)據(jù)形式；
存儲持久數(shù)據(jù)的文件容器；
提供遠(yuǎn)程過程調(diào)用RPC；
簡單的動態(tài)語言結(jié)合功能。
相比于Apache Thrift 和Google的Protocol Buffers，Apache Avro具有以下特點：
支持動態(tài)模式。Avro不需要生成代碼，這有利于搭建通用的數(shù)據(jù)處理系統(tǒng)，同時避免了代碼入侵。
數(shù)據(jù)無須加標(biāo)簽。讀取數(shù)據(jù)前，Avro能夠獲取模式定義，這使得Avro在數(shù)據(jù)編碼時只需要保留更少的類型信息，有利于減少序列化后的數(shù)據(jù)大小。
官網(wǎng)：http://avro.apache.org/
二、Facebook Thrift
貢獻(xiàn)者：Facebook
簡介：Thrift源于大名鼎鼎的facebook之手，在2007年facebook提交Apache基金會將Thrift作為一個開源項目，對于當(dāng)時的facebook來說創(chuàng)造thrift是為了解決facebook系統(tǒng)中各系統(tǒng)間大數(shù)據(jù)量的傳輸通信以及系統(tǒng)之間語言環(huán)境不同需要跨平臺的特性。
thrift可以支持多種程序語言，例如: C++, C#, Cocoa, Erlang, Haskell, Java, Ocami, Perl, PHP, Python, Ruby, Smalltalk. 在多種不同的語言之間通信thrift可以作為二進(jìn)制的高性能的通訊中間件，支持?jǐn)?shù)據(jù)(對象)序列化和多種類型的RPC服務(wù)。
Thrift適用于程序?qū)Τ?序靜態(tài)的數(shù)據(jù)交換，需要先確定好他的數(shù)據(jù)結(jié)構(gòu)，他是完全靜態(tài)化的，當(dāng)數(shù)據(jù)結(jié)構(gòu)發(fā)生變化時，必須重新編輯IDL文件，代碼生成，再編譯載入的流程，跟其他IDL工具相比較可以視為是Thrift的弱項，Thrift適用于搭建大型數(shù)據(jù)交換及存儲的通用工具，對于大型系統(tǒng)中的內(nèi)部數(shù)據(jù)傳輸相對于JSON和xml無論在性能、傳輸大小上有明顯的優(yōu)勢。
Thrift 主要由5個部分組成：
· 類型系統(tǒng)以及 IDL 編譯器：負(fù)責(zé)由用戶給定的 IDL 文件生成相應(yīng)語言的接口代碼
· TProtocol：實現(xiàn) RPC 的協(xié)議層，可以選擇多種不同的對象串行化方式，如 JSON, Binary。
· TTransport：實現(xiàn) RPC 的傳輸層，同樣可以選擇不同的傳輸層實現(xiàn)，如socket, 非阻塞的 socket, MemoryBuffer 等。
· TProcessor：作為協(xié)議層和用戶提供的服務(wù)實現(xiàn)之間的紐帶，負(fù)責(zé)調(diào)用服務(wù)實現(xiàn)的接口。
· TServer：聚合 TProtocol, TTransport 和 TProcessor 幾個對象。
上述的這5個部件都是在 Thrift 的源代碼中通過為不同語言提供庫來實現(xiàn)的，這些庫的代碼在 Thrift 源碼目錄的 lib 目錄下面，在使用 Thrift 之前需要先熟悉與自己的語言對應(yīng)的庫提供的接口。
Facebook Thrift構(gòu)架：
官網(wǎng)：http://thrift.apache.org/
集群管理
一、Nagios
簡介：Nagios是一款開源的免費網(wǎng)絡(luò)監(jiān)視工具，能有效監(jiān)控Windows、Linux和Unix的主機(jī)狀態(tài)，交換機(jī)路由器等網(wǎng)絡(luò)設(shè)置，打印機(jī)等。在系統(tǒng)或服務(wù)狀態(tài)異常時發(fā)出郵件或短信報警第一時間通知網(wǎng)站運維人員，在狀態(tài)恢復(fù)后發(fā)出正常的郵件或短信通知。
Nagios可運行在Linux/Unix平臺之上，同時提供一個可選的基于瀏覽器的WEB界面以方便系統(tǒng)管理人員查看網(wǎng)絡(luò)狀態(tài)，各種系統(tǒng)問題，以及日志等等。
官網(wǎng)：http://www.nagios.org/
二、Ganglia
簡介：Ganglia是UC Berkeley發(fā)起的一個開源集群監(jiān)視項目，設(shè)計用于測量數(shù)以千計的節(jié)點。Ganglia的核心包含gmond、gmetad以及一個Web前端。主要是用來監(jiān)控系統(tǒng)性能，如：cpu 、mem、硬盤利用率， I/O負(fù)載、網(wǎng)絡(luò)流量情況等，通過曲線很容易見到每個節(jié)點的工作狀態(tài)，對合理調(diào)整、分配系統(tǒng)資源，提高系統(tǒng)整體性能起到重要作用。
官網(wǎng)：http://ganglia.sourceforge.net/
三、Apache Ambari
簡介：Apache Ambari是一種基于Web的工具，支持Apache Hadoop集群的供應(yīng)、管理和監(jiān)控。Ambari目前已支持大多數(shù)Hadoop組件，包括HDFS、MapReduce、Hive、Pig、 Hbase、Zookeper、Sqoop和Hcatalog等。
Apache Ambari 支持HDFS、MapReduce、Hive、Pig、Hbase、Zookeper、Sqoop和Hcatalog等的集中管理。也是5個頂級hadoop管理工具之一。
Ambari主要取得了以下成績：
通過一步一步的安裝向?qū)Ш喕思汗?yīng)。
預(yù)先配置好關(guān)鍵的運維指標(biāo)（metrics），可以直接查看Hadoop Core（HDFS和MapReduce）及相關(guān)項目（如HBase、Hive和HCatalog）是否健康。
支持作業(yè)與任務(wù)執(zhí)行的可視化與分析，能夠更好地查看依賴和性能。
通過一個完整的RESTful API把監(jiān)控信息暴露出來，集成了現(xiàn)有的運維工具。
用戶界面非常直觀，用戶可以輕松有效地查看信息并控制集群。
Ambari使用Ganglia收集度量指標(biāo)，用Nagios支持系統(tǒng)報警，當(dāng)需要引起管理員的關(guān)注時（比如，節(jié)點停機(jī)或磁盤剩余空間不足等問題），系統(tǒng)將向其發(fā)送郵件。
此外，Ambari能夠安裝安全的（基于Kerberos）Hadoop集群，以此實現(xiàn)了對Hadoop 安全的支持，提供了基于角色的用戶認(rèn)證、授權(quán)和審計功能，并為用戶管理集成了LDAP和Active Directory。
官網(wǎng)：http://ambari.apache.org/
基礎(chǔ)設(shè)施
一、LevelDB
貢獻(xiàn)者：Jeff Dean和Sanjay Ghemawat
簡介：Leveldb是一個google實現(xiàn)的非常高效的kv數(shù)據(jù)庫，目前的版本1.2能夠支持billion級別的數(shù)據(jù)量了。 在這個數(shù)量級別下還有著非常高的性能，主要歸功于它的良好的設(shè)計。特別是LMS算法。LevelDB 是單進(jìn)程的服務(wù)，性能非常之高，在一臺4核Q6600的CPU機(jī)器上，每秒鐘寫數(shù)據(jù)超過40w，而隨機(jī)讀的性能每秒鐘超過10w。
Leveldb框架：
官網(wǎng)：http://code.google.com/p/leveldb/
二、SSTable
簡介：如果說Protocol Buffer是谷歌獨立數(shù)據(jù)記錄的通用語言 ，那么有序字符串表（SSTable，Sorted String Table）則是用于存儲，處理和數(shù)據(jù)集交換的最流行??的數(shù)據(jù)輸出格式。正如它的名字本身，SSTable是有效存儲大量鍵-值對的簡單抽象，對高吞吐量順序讀/寫進(jìn)行了優(yōu)化。
SSTable是Bigtable中至關(guān)重要的一塊，對于LevelDB來說也是如此。
三、RecordIO
貢獻(xiàn)者：Google
簡介：我們大家都在用文件來存儲數(shù)據(jù)。文件是存儲在磁盤上的。如果在一些不穩(wěn)定的介質(zhì)上，文件很容損壞。即時文件某個位置出現(xiàn)一點小小的問題，整個文件就廢了。
下面我來介紹Google的一個做法，可以比較好的解決這個問題。那就是recordio文件格式。recoidio的存儲單元是一個一個record。這個record可以根據(jù)業(yè)務(wù)的需要自行定義。但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.
詳細(xì)格式如下圖所示：
到這里，大家可能已經(jīng)知道，recordio之所以能對付壞數(shù)據(jù)，其實就是在這個MagicNumber（校驗值）。
四、Flat Buffers
貢獻(xiàn)者：Google
簡介：谷歌開源高效、跨平臺的序列化庫FlatBuffers。
該庫的構(gòu)建是專門為游戲開發(fā)人員的性能需求提供支持，它將序列化數(shù)據(jù)存儲在緩存中，這些數(shù)據(jù)既可以存儲在文件中，又可以通過網(wǎng)絡(luò)原樣傳輸，而不需要任何解析開銷。
FlatBuffers有如下一些關(guān)鍵特性——
訪問序列化數(shù)據(jù)不需要打包/拆包
節(jié)省內(nèi)存而且訪問速度快——緩存只占用訪問數(shù)據(jù)所需要的內(nèi)存；不需要任何額外的內(nèi)存。
靈活性——通過可選字段向前向后兼容
代碼規(guī)模小
強類型——錯誤在編譯時捕獲，而不是在運行時
便利性——生成的C++頭文件代碼簡潔。如果需要，有一項可選功能可以用來在運行時高效解析Schema和JSON-like格式的文本。
跨平臺——使用C++編寫，不依賴STL之外的庫，因此可以用于任何有C++編輯器的平臺。當(dāng)前，該項目包含構(gòu)建方法和在Android、Linux、Windows和OSX等操作系統(tǒng)上使用該庫的示例。
與Protocol Buffers或JSON Parsing這樣的可選方案相比，F(xiàn)latBuffers的優(yōu)勢在于開銷更小，這主要是由于它沒有解析過程。
代碼托管：https://github.com/google/flatbuffers
五、Protocol Buffers
貢獻(xiàn)者：Google
簡介：Protocol Buffers是Google公司開發(fā)的一種數(shù)據(jù)描述語言，類似于XML能夠?qū)⒔Y(jié)構(gòu)化數(shù)據(jù)序列化，可用于數(shù)據(jù)存儲、通信協(xié)議等方面。它不依賴于語言和平臺并且可擴(kuò)展性極強?，F(xiàn)階段官方支持C++、JAVA、Python等三種編程語言，但可以找到大量的幾乎涵蓋所有語言的第三方拓展包。
通過它，你可以定義你的數(shù)據(jù)的結(jié)構(gòu)，并生成基于各種語言的代碼。這些你定義的數(shù)據(jù)流可以輕松地在傳遞并不破壞你已有的程序。并且你也可以更新這些數(shù)據(jù)而現(xiàn)有的程序也不會受到任何的影響。
Protocol Buffers經(jīng)常被簡稱為protobuf。
官網(wǎng)：http://code.google.com/p/protobuf/
六、Consistent Hashing（哈希算法）
簡介：一致性哈希算法在1997年由麻省理工學(xué)院提出的一種分布式哈希（DHT）實現(xiàn)算法，設(shè)計目標(biāo)是為了解決因特網(wǎng)中的熱點(Hot spot)問題，初衷和CARP十分類似。一致性哈希修正了CARP使用的簡 單哈希算法帶來的問題，使得分布式哈希（DHT）可以在P2P環(huán)境中真正得到應(yīng)用。
一致性hash算法提出了在動態(tài)變化的Cache環(huán)境中，判定哈希算法好壞的四個定義：
1、平衡性(Balance)：平衡性是指哈希的結(jié)果能夠盡可能分布到所有的緩沖中去，這樣可以使得所有的緩沖空間都得到利用。很多哈希算法都能夠滿足這一條件。
2、單調(diào)性(Monotonicity)：單調(diào)性是指如果已經(jīng)有一些內(nèi)容通過哈希分派到了相應(yīng)的緩沖中，又有新的緩沖加入到系統(tǒng)中。哈希的結(jié)果應(yīng)能夠保證原有已分配的內(nèi)容可以被映射到原有的或者新的緩沖中去，而不會被映射到舊的緩沖集合中的其他緩沖區(qū)。
3、分散性(Spread)：在分布式環(huán)境中，終端有可能看不到所有的緩沖，而是只能看到其中的一部分。當(dāng)終端希望通過哈希過程將內(nèi)容映射到緩沖上時，由于不同終端所見的緩沖范圍有可能不同，從而導(dǎo)致哈希的結(jié)果不一致，最終的結(jié)果是相同的內(nèi)容被不同的終端映射到不同的緩沖區(qū)中。這種情況顯然是應(yīng)該避免的，因為它導(dǎo)致相同內(nèi)容被存儲到不同緩沖中去，降低了系統(tǒng)存儲的效率。分散性的定義就是上述情況發(fā)生的嚴(yán)重程度。好的哈希算法應(yīng)能夠盡量避免不一致的情況發(fā)生，也就是盡量降低分散性。
4、負(fù)載(Load)：負(fù)載問題實際上是從另一個角度看待分散性問題。既然不同的終端可能將相同的內(nèi)容映射到不同的緩沖區(qū)中，那么對于一個特定的緩沖區(qū)而言，也可能被不同的用戶映射為不同 的內(nèi)容。與分散性一樣，這種情況也是應(yīng)當(dāng)避免的，因此好的哈希算法應(yīng)能夠盡量降低緩沖的負(fù)荷。
在分布式集群中，對機(jī)器的添加刪除，或者機(jī)器故障后自動脫離集群這些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法，那么在有機(jī)器添加或者刪除后，很多原有的數(shù)據(jù)就無法找到了，這樣嚴(yán)重的違反了單調(diào)性原則。
七、Netty
貢獻(xiàn)者：JBOSS
簡介：Netty是由JBOSS提供的一個java開源框架。Netty提供異步的、事件驅(qū)動的網(wǎng)絡(luò)應(yīng)用程序框架和工具，用以快速開發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序。
也就是說，Netty 是一個基于NIO的客戶，服務(wù)器端編程框架，使用Netty 可以確保你快速和簡單的開發(fā)出一個網(wǎng)絡(luò)應(yīng)用，例如實現(xiàn)了某種協(xié)議的客戶，服務(wù)端應(yīng)用。Netty相當(dāng)簡化和流線化了網(wǎng)絡(luò)應(yīng)用的編程開發(fā)過程，例如，TCP和UDP的socket服務(wù)開發(fā)。
“快速”和“簡單”并不意味著會讓你的最終應(yīng)用產(chǎn)生維護(hù)性或性能上的問題。Netty 是一個吸收了多種協(xié)議的實現(xiàn)經(jīng)驗，這些協(xié)議包括FTP,SMTP,HTTP，各種二進(jìn)制，文本協(xié)議，并經(jīng)過相當(dāng)精心設(shè)計的項目，最終，Netty 成功的找到了一種方式，在保證易于開發(fā)的同時還保證了其應(yīng)用的性能，穩(wěn)定性和伸縮性。
官網(wǎng)：http://netty.io/
八、BloomFilter
簡介：Bloom filter 是由 Howard Bloom 在 1970 年提出的二進(jìn)制向量數(shù)據(jù)結(jié)構(gòu)，它具有很好的空間和時間效率，被用來檢測一個元素是不是集合中的一個成員。如果檢測結(jié)果為是，該元素不一定在集合中；但如果檢測結(jié)果為否，該元素一定不在集合中。因此Bloom filter具有100%的召回率。這樣每個檢測請求返回有“在集合內(nèi)（可能錯誤）”和“不在集合內(nèi)（絕對不在集合內(nèi)）”兩種情況，可見 Bloom filter 是犧牲了正確率和時間以節(jié)省空間。
Bloom filter 優(yōu)點就是它的插入和查詢時間都是常數(shù)，另外它查詢元素卻不保存元素本身，具有良好的安全性。
搜索引擎
一、Nutch
簡介：Nutch 是一個開源Java 實現(xiàn)的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具。包括全文搜索和Web爬蟲。
盡管Web搜索是漫游Internet的基本要求, 但是現(xiàn)有web搜索引擎的數(shù)目卻在下降. 并且這很有可能進(jìn)一步演變成為一個公司壟斷了幾乎所有的web搜索為其謀取商業(yè)利益.這顯然 不利于廣大Internet用戶.
Nutch為我們提供了這樣一個不同的選擇. 相對于那些商用的搜索引擎, Nutch作為開放源代碼 搜索引擎將會更加透明, 從而更值得大家信賴. 現(xiàn)在所有主要的搜索引擎都采用私有的排序算法, 而不會解釋為什么一個網(wǎng)頁會排在一個特定的位置. 除此之外, 有的搜索引擎依照網(wǎng)站所付的 費用, 而不是根據(jù)它們本身的價值進(jìn)行排序. 與它們不同, Nucth沒有什么需要隱瞞, 也沒有 動機(jī)去扭曲搜索的結(jié)果. Nutch將盡自己最大的努力為用戶提供最好的搜索結(jié)果.
Nutch目前最新的版本為version v2.2.1。
官網(wǎng)：https://nutch.apache.org/
二、Lucene
開發(fā)者：Doug Cutting（Hadoop之父，你懂的）
簡介：Lucene是apache軟件基金會4 jakarta項目組的一個子項目，是一個開放源代碼的全文檢索引擎工具包，即它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構(gòu)，提供了完整的查詢引擎和索引引擎，部分文本分析引擎（英文與德文兩種西方語言）。Lucene的目的是為軟件開發(fā)人員提供一個簡單易用的工具包，以方便的在目標(biāo)系統(tǒng)中實現(xiàn)全文檢索的功能，或者是以此為基礎(chǔ)建立起完整的全文檢索引擎。
官網(wǎng)：http://lucene.apache.org/
三、SolrCloud
簡介：SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案。SolrCloud是Solr的基于Zookeeper一種部署方式。Solr可以以多種方式部署，例如單機(jī)方式，多機(jī)Master-Slaver方式。
原理圖：
SolrCloud有幾個特色功能：
集中式的配置信息使用ZK進(jìn)行集中配置。啟動時可以指定把Solr的相關(guān)配置文件上傳
Zookeeper，多機(jī)器共用。這些ZK中的配置不會再拿到本地緩存，Solr直接讀取ZK中的配置信息。配置文件的變動，所有機(jī)器都可以感知到。另外，Solr的一些任務(wù)也是通過ZK作為媒介發(fā)布的。目的是為了容錯。接收到任務(wù)，但在執(zhí)行任務(wù)時崩潰的機(jī)器，在重啟后，或者集群選出候選者時，可以再次執(zhí)行這個未完成的任務(wù)。
自動容錯SolrCloud對索引分片，并對每個分片創(chuàng)建多個Replication。每個Replication都可以對外提供服務(wù)。一個Replication掛掉不會影響索引服務(wù)。更強大的是，它還能自動的在其它機(jī)器上幫你把失敗機(jī)器上的索引Replication重建并投入使用。
近實時搜索立即推送式的replication（也支持慢推送）。可以在秒內(nèi)檢索到新加入索引。
查詢時自動負(fù)載均衡SolrCloud索引的多個Replication可以分布在多臺機(jī)器上，均衡查詢壓力。如果查詢壓力大，可以通過擴(kuò)展機(jī)器，增加Replication來減緩。
自動分發(fā)的索引和索引分片發(fā)送文檔到任何節(jié)點，它都會轉(zhuǎn)發(fā)到正確節(jié)點。
事務(wù)日志事務(wù)日志確保更新無丟失，即使文檔沒有索引到磁盤。
四、Solr
簡介：Solr是一個獨立的企業(yè)級搜索應(yīng)用服務(wù)器，它對外提供類似于Web-service的API接口。用戶可以通過http請求，向搜索引擎服務(wù)器提交一定格式的XML文件，生成索引；也可以通過Http Get操作提出查找請求，并得到XML格式的返回結(jié)果。
Solr是一個高性能，采用Java5開發(fā)，基于Lucene的全文搜索服務(wù)器。同時對其進(jìn)行了擴(kuò)展，提供了比Lucene更為豐富的查詢語言，同時實現(xiàn)了可配置、可擴(kuò)展并對查詢性能進(jìn)行了優(yōu)化，并且提供了一個完善的功能管理界面，是一款非常優(yōu)秀的全文搜索引擎。
官網(wǎng)：https://lucene.apache.org/solr/
五、ElasticSearch
簡介：ElasticSearch是一個基于Lucene的搜索服務(wù)器。它提供了一個分布式多用戶能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java開發(fā)的，并作為Apache許可條款下的開放源碼發(fā)布，是第二最流行的企業(yè)搜索引擎。設(shè)計用于云計算中，能夠達(dá)到實時搜索，穩(wěn)定，可靠，快速，安裝使用方便。
官網(wǎng)：http://www.elasticsearch.org/
六、Sphinx
簡介：Sphinx是一個基于SQL的全文檢索引擎，可以結(jié)合MySQL,PostgreSQL做全文搜索，它可以提供比數(shù)據(jù)庫本身更專業(yè)的搜索功能，使得應(yīng)用程序更容易實現(xiàn)專業(yè)化的全文檢索。Sphinx特別為一些腳本語言設(shè)計搜索API接口，如PHP,Python,Perl,Ruby等，同時為MySQL也設(shè)計了一個存儲引擎插件。
Sphinx單一索引最大可包含1億條記錄，在1千萬條記錄情況下的查詢速度為0.x秒（毫秒級）。Sphinx創(chuàng)建索引的速度為：創(chuàng)建100萬條記錄的索引只需 3～4分鐘，創(chuàng)建1000萬條記錄的索引可以在50分鐘內(nèi)完成，而只包含最新10萬條記錄的增量索引，重建一次只需幾十秒。
官網(wǎng)：http://sphinxsearch.com
七、SenseiDB
貢獻(xiàn)者：linkedin
簡介：SenseiDB是一個NoSQL數(shù)據(jù)庫，它專注于高更新率以及復(fù)雜半結(jié)構(gòu)化搜索查詢。熟悉Lucene和Solor的用戶會發(fā)現(xiàn)，SenseiDB背后有許多似曾相識的概念。SenseiDB部署在多節(jié)點集群中，其中每個節(jié)點可以包括N塊數(shù)據(jù)片。Apache Zookeeper用于管理節(jié)點，它能夠保持現(xiàn)有配置，并可以將任意改動（如拓?fù)湫薷模﹤鬏數(shù)秸麄€節(jié)點群中。SenseiDB集群還需要一種模式用于定義將要使用的數(shù)據(jù)模型。
從SenseiDB集群中獲取數(shù)據(jù)的唯一方法是通過Gateways（它 沒有“INSERT”方法）。每個集群都連接到一個單一gateway。你需要了解很重要的一點是，由于SenseiDB本身沒法處理原子性 （Atomicity）和隔離性（Isolation），因此只能通過外部在gateway層進(jìn)行限制。另外，gateway必須確保數(shù)據(jù)流按照預(yù)期的方 式運作。內(nèi)置的gateway有以下幾種形式：
來自文件
來自JMS隊列
通過JDBC
來自Apache Kafka
官網(wǎng)：http://senseidb.com
數(shù)據(jù)挖掘
一、Mahout
簡介：Apache Mahout 是 Apache Software Foundation (ASF) 開發(fā)的一個全新的開源項目，其主要目標(biāo)是創(chuàng)建一些可伸縮的機(jī)器學(xué)習(xí)算法，供開發(fā)人員在 Apache 在許可下免費使用。該項目已經(jīng)發(fā)展到了它的最二個年頭，目前只有一個公共發(fā)行版。Mahout 包含許多實現(xiàn)，包括集群、分類、CP 和進(jìn)化程序。此外，通過使用 Apache Hadoop 庫，Mahout 可以有效地擴(kuò)展到云中。
雖然在開源領(lǐng)域中相對較為年輕，但 Mahout 已經(jīng)提供了大量功能，特別是在集群和 CF 方面。Mahout 的主要特性包括：
Taste CF。Taste 是 Sean Owen 在 SourceForge 上發(fā)起的一個針對 CF 的開源項目，并在 2008 年被贈予 Mahout。
一些支持 Map-Reduce 的集群實現(xiàn)包括 k-Means、模糊 k-Means、Canopy、Dirichlet 和 Mean-Shift。
Distributed Naive Bayes 和 Complementary Naive Bayes 分類實現(xiàn)。
針對進(jìn)化編程的分布式適用性功能。
Matrix 和矢量庫。
上述算法的示例。
官網(wǎng)：http://mahout.apache.org/
Iaas
IaaS（Infrastructure as a Service），即基礎(chǔ)設(shè)施即服務(wù)。
一、OpenStack
簡介：OpenStack是一個由NASA（美國國家航空航天局）和Rackspace合作研發(fā)并發(fā)起的，以Apache許可證授權(quán)的自由軟件和開放源代碼項目。
OpenStack是一個開源的云計算管理平臺項目，由幾個主要的組件組合起來完成具體工作。OpenStack支持幾乎所有類型的云環(huán)境，項目目標(biāo)是提供實施簡單、可大規(guī)模擴(kuò)展、豐富、標(biāo)準(zhǔn)統(tǒng)一的云計算管理平臺。OpenStack通過各種互補的服務(wù)提供了基礎(chǔ)設(shè)施即服務(wù)（IaaS）的解決方案，每個服務(wù)提供API以進(jìn)行集成。
6個核心項目：Nova（計算，Compute），Swift（對象存儲，Object），Glance（鏡像，Image），Keystone（身份，Identity），Horizon（自助門戶，Dashboard），Quantum & Melange（網(wǎng)絡(luò)&地址管理），另外還有若干社區(qū)項目，如Rackspace（負(fù)載均衡）、Rackspace（關(guān)系型數(shù)據(jù)庫）。
相關(guān)閱讀：
什么是OpenStack？
成功部署OpenStack的十大要點
** 官網(wǎng)**：https://www.openstack.org/
二、Docker
貢獻(xiàn)者：dotCloud
簡介：Docker 是一個開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個可移植的容器中，然后發(fā)布到任何流行的 Linux 機(jī)器上，也可以實現(xiàn)虛擬化。容器是完全使用沙箱機(jī)制，相互之間不會有任何接口（類似 iPhone 的 app）。幾乎沒有性能開銷,可以很容易地在機(jī)器和數(shù)據(jù)中心中運行。最重要的是,他們不依賴于任何語言、框架或包括系統(tǒng)。
官網(wǎng)：http://www.docker.io/
三、Kubernetes
貢獻(xiàn)者：Google
簡介：Kubernetes是Google開源的容器集群管理系統(tǒng)。它構(gòu)建Ddocker技術(shù)之上，為容器化的應(yīng)用提供資源調(diào)度、部署運行、服務(wù)發(fā)現(xiàn)、擴(kuò)容縮容等整一套功能，本質(zhì)上可看作是基于容器技術(shù)的mini-PaaS平臺。
Kubernetes從另一個角度對資源進(jìn)行抽象，它讓開發(fā)人員和管理人員共同著眼于服務(wù)的行為和性能的提升，而不是僅僅關(guān)注對單一的組件或者是基礎(chǔ)資源。
那么Kubernetes集群到底提供了哪些單一容器所沒有功能?它主要關(guān)注的是對服務(wù)級別的控制而并非僅僅是對容器級別的控制，Kubernetes提供了一種“機(jī)智”的管理方式，它將服務(wù)看成一個整體。在Kubernete的解決方案中，一個服務(wù)甚至可以自我擴(kuò)展，自我診斷，并且容易升級。例如，在Google中，我們使用機(jī)器學(xué)習(xí)技術(shù)來保證每個運行的服務(wù)的當(dāng)前狀態(tài)都是最高效的。
代碼托管：https://github.com/GoogleCloudPlatform/kubernetes/
四、Imctfy
貢獻(xiàn)者：Google
簡介：Google開源了自己所用Linux容器系統(tǒng)的開源版本lmctfy，讀音為lem-kut-fee。包括一個C++庫（使用了C++11，文檔可以參考頭文件）和命令行界面。目前的版本是0.1，只提供了CPU與內(nèi)存隔離。項目還在密集開發(fā)中。
mctfy本身是針對某些特定使用場景設(shè)計和實現(xiàn)的，目前擁有一臺機(jī)器上所有容器時運行情況最好，不推薦與LXC和其他容器系統(tǒng)一起使用（雖然也可行）。已在Ubuntu 12.04+和Ubuntu 3.3與3.8內(nèi)核上測試。
代碼托管：https://github.com/google/Imctfy/
監(jiān)控管理
一、Dapper
貢獻(xiàn)者：Google
簡介：Dapper是一個輕量的ORM(對象關(guān)系映射（英語：Object Relational Mapping，簡稱ORM，或O/RM，或O/R mapping）。并不單純的是一個DBHelper.因為在Dapper中數(shù)據(jù)其實就是一個對象。Dapper擴(kuò)展與IDbConnection上，所以事實上它的傾入性很低。我用了StructureMap。如果不喜歡可以自己更換，或者自己實現(xiàn)下。
代碼就一個SqlMapper.cs文件,主要是IDbConnection的擴(kuò)展方法，編譯后就40K的一個很小的dll。
特性：
Dapper很快。Dapper的速度接近與IDataReader。
Dapper支持主流數(shù)據(jù)庫 Mysql,SqlLite,Mssql2000,Mssql2005,Oracle等一系列的數(shù)據(jù)庫
支持多表并聯(lián)的對象。支持一對多 多對多的關(guān)系，并且沒侵入性。
原理通過Emit反射IDataReader的序列隊列，來快速的得到和產(chǎn)生對象
Dapper語法十分簡單。并且無須遷就數(shù)據(jù)庫的設(shè)計
官方站點 http://code.google.com/p/dapper-dot-net/
代碼托管：http://bigbully.github.io/Dapper-translation/
二、Zipkin
貢獻(xiàn)者：Twitter
簡介：Zipkin （分布式跟蹤系統(tǒng)）是 Twitter 的一個開源項目，允許開發(fā)者收集 Twitter 各個服務(wù)上的監(jiān)控數(shù)據(jù)，并提供查詢接口。該系統(tǒng)讓開發(fā)者可通過一個 Web 前端輕松的收集和分析數(shù)據(jù)，例如用戶每次請求服務(wù)的處理時間等，可方便的監(jiān)測系統(tǒng)中存在的瓶頸。
官方網(wǎng)站：http://twitter.github.io/zipkin/
代碼托管：https://github.com/twitter/zipkin/
End.
