Lily系统调查

 1、架构

      Lily系统是由客户端、LilyNode、Hadoop、HBase、Solr、Zookeeper共同组成的一个复杂系统，利用HDFS存储blob、HBase存储元数据和表记录、Zookeeper来存储表schema和节点信息、Solr提供查询功能。

     

     HBase：存储表数据。

     HDFS：存储blob。但也会把过小的文件直接存储在HBase中，以降低namenode内存的限制。

     repository：Lily系统的抽象层，提供记录的CRUD操作。客户端使用avro与repository沟通，repository使用ipc与hbase沟通。

     SEP：The Side Effect Processor，用来保障HBase和Solr操作的原子性。使HBase操作后可以给索引器发通知，索引器异步处理。

     Indexer：当数据被创建、更新、删除时，索引器会更新Solr，索引要监听SEP事件。如果是blob，solr会使用Tika库做内容解析。

     Solr：全文检索引擎。

     Zookeeper：为分布式应用的协作提供基础服务，比如分布式同步、leader选举、配置等。

2、库模型

    

     库模型与HBase对应关系：

            Lily table == HBase Table

            Record == HBase Row

            Record Id == Row Key

             fields == columns

     表：由多个记录组成，可以存储多种类型的数据（有继承关系）。（可以把Lily中的数据类型想象成java的类、类的变量、基础类型和复杂类型等...并且也具有继承关系。

     记录：

          由id来唯一标识，可以由用户指定，也可以系统生成。

          记录存储在表中，通过id来排序，可以按照id来迭代获取。

          记录id由两部分组成，一是主id（master record id），二是一个可变的属性集合。其中第二部分是可选的。

          如果一条记录被删除，会在这条记录删添加标志位，并在后期物理删除数据。如果有相同id的数据被建立，那么会延续之前记录的版本号。

          

          Lily只用一个column family来存储数据，叫做“data”

          系统表和用户表的field通过不同的前缀来区分： LilyHBaseSchema.RecordColumn.SYSTEM_PREFIX and DATA_PREFIX

           数据分为有版本和无版本的，无版本的数据版本号始终都是1

           如果版本号升级而值没有变，就会继承之前版本的值。如果版本号升级，数据被打上了“deleted”标志位，则不能再继承之前的值。但针对field的删除也是打标记，就是把DELETE操作隐含在PUT里，做到了PUT和DELETE操作的原子性。

           一条记录的一次操作是原子的

          记录类型由以下组成：

               一组（set）field类型

               一组（list）supertypes，跟java超类一样，具有“is a”关系

               id，与field id一样

               命名空间

               版本号

          记录是可以被修改的，这点跟field不太一样，不用担心值类型变换的问题，可以删除或者添加field。

          当更新一条记录的时候，默认操作是把旧版本的记录删除

          记录类型的超类型是一组（list）其他指向其他record类型的引用。

          一个记录可以继承自多个记录，重复的会被忽略

          记录的校验是可选的，如果开启，会根据field可装载的数据类型来校验，如果关闭，会接受任何值插入field。（关闭校验功能目前还没有实现...）

          记录id由两部分组成：1）master record id；2）一组变量。变量时一组name-value对。这么做的初衷是为了多语言环境，不同语言的同一份文档可以被标识为同一个master id的不同版本。

          

     field：

          field的类型，包括：1）所在scope（版本）；2）值类型（java）；3）id；4）全名：命名空间名称+真实名称。

           基本值类型：

Name	Java Type
STRING	java.lang.String
INTEGER	java.lang.Integer
LONG	java.lang.Long
DOUBLE	java.lang.Double
DECIMAL	java.math.BigDecimal
BOOLEAN	java.lang.Boolean
DATE	org.joda.time.LocalDate
DATETIME	org.joda.time.DateTime
BLOB	org.lilyproject.repository.api.Blob
URI	java.net.URI
BYTEARRAY	org.lilyproject.bytes.api.ByteArray

  

                   

                   

          

          

   

       参数化类型包括：

                  List<xxx>

                  PATH：层级路径

                  LINK：可以指向别的record

                  RECORD：可以装载到field中的记录类型

          field的名称在repository中必须是唯一的。同一个field可以被放进多个record中。

          field能够存在于三种区域内：versioned、non-versioned、versioned-mutable
           如果一条record的所有field都是没有version的，那这条record就是没有version的。如果有version的record包含non-version的field，那么这儿field就是一个跨版本field。修改non-versioned field不会创建新版本。

           field不能单独存储。在record版本更新时，field版本会集体更新。

           如果改变了field的类型，那么读现有field值的时候可能失败。如果需要更改值类型，最好新建一个field，把之前的值都拷贝到新field中。

          伴随着field，还可以保存field的metadata，metadata不用记录在schema中。

          metadata只能记录在top-level field values中，不能记录在List-type的field中。

          操作时在记录级的，一条记录可以被原子的CRUD。一个update操作可以一次性更新所有scope中的field，可以只读取感兴趣的field，update时，只需要与相关的field通信即可。

3、索引

     索引器会保持Solr中的索引持续更新。记录更新后，有一个叫indexer的模块异步的通过lily repository拿出来，然后放到solr里去。这个模块除了索引数据的功能外还有以下功能。

     1）Denormalization（反向规范化...）：把一条记录的索引条目添加到另一条记录中，弥补Solr不能做join的缺陷。

     2）一条记录不同版本的索引

     3）数据的更新会到一个队列中，由indexer处理。如果有多个Lily nodes，indexer会在每个节点运行，每个节点中，还有会多线程运行。

     4）可以通过mapreduce重新构建索引。（batch index building）

     5）Blob内容解析，通过Tika library，可以解析诸如HTML、PDF、Micrsoft office、openoffice、RTFand more...

     6）支持多Solr实例（非Solr group）

4、Blob

     在将来...Blob只能被当成一行数据中的一个field来使用

     当一个Blob能被在行中使用前，必须先被上传到blobstore中。在一定时间后才能在行中被使用（创建或更新行时被引用）。如果这段时间内（默认是1小时）没有被使用，就会变为“不可用”，并且在将来被删除。

     写blob：在上传和关闭流后，repository就可以查找到并获得blob了。

Repository : OutputStream getOutputStream(Blob blob) throws BlobException, InterruptedException;

     读blob： Blob BlobInputStream.getBlob()方法用来获取元数据

Repository : BlputStream getInputStream(RecordId recordId, QName fieldName, Long version, Integer multivalueIndex, Integer hierarchyInobIndex); 

     引用：在行创建或更新操作中可以被引用。

     删除：blob不能被显示的删除。在以下三种情况下被删除：

           1）在上传到blobstore后，没有在定义的时间内被行引用

          2）在行上进行的更新和删除操作，是blob不再被引用。注意，如果有旧版本的行引用着blob，也不会被删除。

          3）当一行被删除，所有的field也会被清空，相关的blob也会被删除。

     有关blob的设计

          Reposity：提供getInputStream和getOutputStream来读写blob。已经被行引用的blob，可以通过普通的CRUD操作被repository使用。

          BlobManager：Repostory使用BlobManager来管理blobs的状态，这些状态存在于一张HBase表里 - BlobIncubatorTable。

          Blob Incubator Table：当blob被上传后，会在这个表里记录状态。当一条记录引用了它，它的引用就会在这个表中被删除。防止其他记录在同一时间使用。

          Blob Incubator Monitor：如果blob在定义的时间内没有被行使用，就会被Monitor物理删除。

     相关流程：

          创建记录：

               1）blob被repository使用outputstream上传到

               2）关闭outputstream时，BlobManager请求向BlobIncubatorTable表中增加blob的引用

               3）在有记录关联请求过来时，检查BlobIncubatorTable表中是否有blob的引用，如果没有，关联请求失败，如果有，在incubator表的记录中增加record id

               4）在HBase中创建record，在incubator表中删除blob的引用。

          更新记录：

               1）当一个新blob被上传，或者被一个field的其他版本使用时，触发更新操作

               2）BlobManager发出请求准备（reserve）blob：如果incubator表中有或查到已经被同一条记录的同一个field引用，则返回成功，否则返回失败。

               3）执行record的更新操作

               4）BlobManager请求删除所有的准备（reservations）

               5）如果blob不被引用了，BlobManager会请求删除blob - 通过向BlobDeleteTable加入一条标记，monitor会稍后删除。

               注，还有一种叫做inline blob，可以被多行记录的多个field引用。

          删除记录，每个field引用的blob都会被BlobManager标记为删除（向BlobDeleteTable中添加一条记录）

5、其他

     索引配置存储在zookeeper中

     SEP（ Side Effect Processor） - 监听HBase变化事件（PUT&DELETE）

     可以通过java api、rest api和命令行工具等三种方式访问Lily

     通常，Lily可以通过监听存储库的事件（HBase）来更新索引，也可以使用手工来重建索引，可以完全去掉增量索引，而使用批量构建。在“配置更改”、“Lily里已经有数据了，才定义配置”、“索引丢失”等三种情况下重新构建索引。

     索引构建使用MapReduce（Hadoop Job）