基于hbase+flume的日志云服务平台

一、整体设计

1. 用户定时scp日志数据到指定目录，解压并将日志数据进行分类。

2. flume以spooldir方式监控各类型的日志文件，异步导入到hbase中。

3. 以web形式将用户搜索的数据进行展现。

二、实现细节

（一） hbase表

将所有日志分成5类，每类日志对应一张hbase表，包含一个列族。为什么要存储于多个表呢？原因在于每种类型的日志搜索条件都不一样，设计成一个表的话，会导致hbase表RowKey设计过于复杂。

（二）RowKey设计

前缀：日志时间戳+后缀：其他查询字段．．．

备注：

前缀：用于区分不同业务系统，如01、02等。

日志时间戳+后缀：时间戳是(Long.maxValue - 日志打印时间)，这样能保证最新的日志排在前面；后缀(000000-999999)，保证相同日志打印时间不被覆盖，以999999开始，相同日志打印时间的日志记录依次减1。

其他查询字段：按照不同日志类型提供不同查询条件。

（三）flume设计

1. 监控日志的agent对每一类日志配置一个source，以avro协议传输到collector集群，集群配置负载均衡。

2. 监控日志的source扩展拦截器，实现将多个event合并成一个event。因为spooldir以LINE作为一个event，而日志有可能会打印多行，此拦截器的作用即合并多个原始event为一个。

3. 扩展deserializer，将每一类日志分成多个字段，写入对应hbase表。

4. collector的channal采用file形式，memory会出现数据丢失现象。

三、后续改进

1. 构建hbase二级索引。目前由于没有二级索引导致了很多问题：

a) 必须对每一种类型的日志创建一张表，而不同类型的日志数据量不一，会有资源的浪费；

b) RowKey设计优先考虑日志时间戳，并按时间戳倒序排序，会导致Region热点问题，Region在分裂的时候会导致左子Region一半空间的浪费（很严重的问题）；

c) 不能支持多条件查询。

2. collector生产者和消费者两端速率不对等，原因在于hbase入库的效率，后续要持续优化。