一、整体设计
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入库的效率,后续要持续优化。