日誌收集系統

　　一、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 的主要特性包括：

　　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），即基礎設施即服務。

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

　　特性：

　　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/

　　二、Zipkin

　　貢獻者：Twitter

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

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

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

　　End.