Lily架构简介.docx

Lily是什么Lily是一个可扩展的数据仓库。用于数据的存储和搜索。Lily是一个分布式系统，她并不是白手起家的，她依赖于两个已有的OpenSource软件，一个是HBase, 另一个是SOLR. 同时Lily对于使用者提供自己的操作接口，称作Lily API.Lily的优势在于她强大的搜索能力，无论是文本匹配还是全文索引，通通 都能搞定。但我觉得Lily在获取这些优势的同时付出了相当大的代价，最主要的代价就是系统的复杂性。想想看，为了能够使用Lily，你需要安装并维护以 下系统：HDFS, HBase, Zookeeper, SOLR, Lily. 这些系统任何一个都可能让Operation Team抓狂，更不用说他们混在一起了。Lily的架构1.总体架构Lily使用分布式的架构，这包括两方面：1) Lily拥有多个Node，不同的Node完成不同的工作，相互合作共同完成任务。2) Lily拥有多个Node，每个Node都完成一样的工作，这样可以保证可扩展性和容错性。Lily的大致架构可用这张图来表示：先将这张图分成左右两边，左边是Lily的系统，右边是Lily依赖的系统，从上至下是HBase, HDFS, SOLR, Zookeeper. 后面我们会分析每个Lily Node的内部结构，现在我们先来分析一下Lily的每个依赖:Zookeeper, 每个Lily Node用Zookeeper来发布自己的存在，就好像HBase RegionServer一样。Client可以从Zookeeper获取当前有多少个Lily Node在提供服务。SOLR，为全文索引提供服务，具体的使用方法是Lily Node将插入的内容同步输出到SOLR Node，SOLR自己生成全文索引，Client直接call SOLR(不经过Lily Node)获取搜索结果。HDFS，它和Lily Node其实没有直接联系，换句话说Lily可以忽视他的存在。HDFS的作用就是存储HBase的数据，或者直接供Client使用，但这和Lily没什么关联。HBase，和Lily Node的联系最为紧密，Lily Node作为中间层，接到Client的写入请求以后将数据写入HBase，并加上自己的数据以实现Secondary Index. 这个实现可以说和GMS很相似，但Lily的设计更为复杂。2. Lily Node的内部结构多个Lily Node组成了Lily的系统，我们通过观察每个Node内部的结构来了解Lily的工作原理。这张图描述了每个Lily Node的内部结构：这张图稍微有点复杂，我们略过依赖的module，看看Lily Node内部有哪些module: Repository, WAL, MQ(Message Queue), Indexer, LinkIndex.Repository:这个是Client操作的入口，Client使用基于Avro的协议(类似于PB)操作Repository，而Repository使用 HBase标准的java API操作HBase. 除了基本的HBase操作，Repository还有添加Secondary Index信息的任务。为了保证Index信息和原始信息的最终一致性，需要用到WAL. Repository在每次操作的最开始写WAL log, 然后原始操作，写WAL, 再Index操作，写WAL. 一步一标记，失败了就把没做的事情重做一遍. 都做完了写入MQ, 将任务转交个后续处理模块.WAL：前面已经介绍过了，这个模块是保证最终一致性用的. 它和HBase的WAL没什么联系，实现方式也不同。不过我觉得如果想让WAL有保证的化应该将log写入分布式文件系统中，比如HDFS. 但Lily的做法貌似更绝，使用HBase的一个Table来存储WAL，简单，但是加大了依赖性，而且可能会产生更多相互依赖的问题。Message Queue:为什么要有Message Queue?因为有些操作不需要当时完成，丢到MQ里面由后续模块异步慢慢完成好了, 比如说将新的内容同步到SOLR. 因此MQ产生了，如何实现？还是老办法，用HBase里面的一个Table来实现。Indexer:Indexer的主要功能是同步SOLR，进而实现全文索引。因为操作SOLR使用的是公开的API，且Lily不管查询工作，所以Indexer也不会很复杂。LinkIndex：根据Index来查找具体类容的模块，Repository和Indexer都会用到，具体实现细节还需要研究源码才能得知.总结说到这里大家对于Lily因该已经有大概的认识了. 我这里总结一下Lily的优缺点.优点：支持多种搜索，设计上没有大的缺陷.缺点：复杂，管理困难，client必须使用Lily的A