Lily是什么

Lily是一個可擴(kuò)展的數(shù)據(jù)倉庫。用于數(shù)據(jù)的存儲和搜索。Lily是一個分布式系統(tǒng)，她并不是白手起家的，她依賴于兩個已有的OpenSource軟件，一個是HBase, 另一個是SOLR. 同時Lily對于使用者提供自己的操作接口，稱作Lily API.

Lily的優(yōu)勢在于她強(qiáng)大的搜索能力，無論是文本匹配還是全文索引，通通都能搞定。 但我覺得Lily在獲取這些優(yōu)勢的同時付出了相當(dāng)大的代價，最主要的代價就是系統(tǒng)的復(fù)雜性。想想看，為了能夠使用Lily，你需要安裝并維護(hù)以下系 統(tǒng)：HDFS, HBase, Zookeeper, SOLR, Lily. 這些系統(tǒng)任何一個都可能讓Operation Team抓狂，更不用說他們混在一起了。

Lily的架構(gòu)

1.總體架構(gòu)

Lily使用分布式的架構(gòu)，這包括兩方面：1) Lily擁有多個Node，不同的Node完成不同的工作，相互合作共同完成任務(wù)。2) Lily擁有多個Node，每個Node都完成一樣的工作，這樣可以保證可擴(kuò)展性和容錯性。

Lily的大致架構(gòu)可用這張圖來表示：

先將這張圖分成左右兩邊，左邊是Lily的系統(tǒng)，右邊是Lily依賴的系統(tǒng)，從上至下是HBase, HDFS, SOLR, Zookeeper. 后面我們會分析每個Lily Node的內(nèi)部結(jié)構(gòu)，現(xiàn)在我們先來分析一下Lily的每個依賴:

Zookeeper, 每個Lily Node用Zookeeper來發(fā)布自己的存在，就好像HBase RegionServer一樣。Client可以從Zookeeper獲取當(dāng)前有多少個Lily Node在提供服務(wù)。

SOLR，為全文索引提供服務(wù)，具體的使用方法是Lily Node將插入的內(nèi)容同步輸出到SOLR Node，SOLR自己生成全文索引，Client直接call SOLR(不經(jīng)過Lily Node)獲取搜索結(jié)果。

HDFS，它和Lily Node其實(shí)沒有直接聯(lián)系，換句話說Lily可以忽視他的存在。HDFS的作用就是存儲HBase的數(shù)據(jù)，或者直接供Client使用，但這和Lily沒什么關(guān)聯(lián)。

HBase，和Lily Node的聯(lián)系最為緊密，Lily Node作為中間層，接到Client的寫入請求以后將數(shù)據(jù)寫入HBase，并加上自己的數(shù)據(jù)以實(shí)現(xiàn)Secondary Index. 這個實(shí)現(xiàn)可以說和GMS很相似，但Lily的設(shè)計(jì)更為復(fù)雜。

2. Lily Node的內(nèi)部結(jié)構(gòu)

多個Lily Node組成了Lily的系統(tǒng)，我們通過觀察每個Node內(nèi)部的結(jié)構(gòu)來了解Lily的工作原理。這張圖描述了每個Lily Node的內(nèi)部結(jié)構(gòu)：

這張圖稍微有點(diǎn)復(fù)雜，我們略過依賴的module，看看Lily Node內(nèi)部有哪些module: Repository, WAL, MQ(Message Queue), Indexer, LinkIndex.

Repository:

這個是Client操作的入口，Client使用基于Avro的協(xié)議(類似于PB)操作Repository，而Repository使用 HBase標(biāo)準(zhǔn)的java API操作HBase. 除了基本的HBase操作，Repository還有添加Secondary Index信息的任務(wù)。為了保證Index信息和原始信息的最終一致性，需要用到WAL. Repository在每次操作的最開始寫WAL log, 然后原始操作，寫WAL, 再Index操作，寫WAL. 一步一標(biāo)記，失敗了就把沒做的事情重做一遍. 都做完了寫入MQ, 將任務(wù)轉(zhuǎn)交個后續(xù)處理模塊.

WAL：

前面已經(jīng)介紹過了，這個模塊是保證最終一致性用的. 它和HBase的WAL沒什么聯(lián)系，實(shí)現(xiàn)方式也不同。不過我覺得如果想讓W(xué)AL有保證的化應(yīng)該將log寫入分布式文件系統(tǒng)中，比如HDFS. 但Lily的做法貌似更絕，使用HBase的一個Table來存儲WAL，簡單，但是加大了依賴性，而且可能會產(chǎn)生更多相互依賴的問題。

Message Queue:

為什么要有Message Queue?因?yàn)橛行┎僮鞑恍枰?dāng)時完成，丟到MQ里面由后續(xù)模塊異步慢慢完成好了, 比如說將新的內(nèi)容同步到SOLR. 因此MQ產(chǎn)生了，如何實(shí)現(xiàn)？還是老辦法，用HBase里面的一個Table來實(shí)現(xiàn)。

Indexer:

Indexer的主要功能是同步SOLR，進(jìn)而實(shí)現(xiàn)全文索引。因?yàn)椴僮鱏OLR使用的是公開的API，且Lily不管查詢工作，所以Indexer也不會很復(fù)雜。

LinkIndex：

根據(jù)Index來查找具體類容的模塊，Repository和Indexer都會用到，具體實(shí)現(xiàn)細(xì)節(jié)還需要研究源碼才能得知.

總結(jié)

說到這里大家對于Lily因該已經(jīng)有大概的認(rèn)識了. 我這里總結(jié)一下Lily的優(yōu)缺點(diǎn).

優(yōu)點(diǎn)：支持多種搜索，設(shè)計(jì)上沒有大的缺陷.

缺點(diǎn)：復(fù)雜，管理困難，client必須使用Lily的API才能享受其功能，對于HBase相當(dāng)依賴卻又不能融入其中。

對于我們來說也許做一個輕量級的Secondary Index真的有些意義。

?

轉(zhuǎn)自：http://www.spnguru.com/?p=548

Lily架構(gòu)簡介