海量结构化日志分析系统

背景

日志，角色不同，出发点和认识的角度也不同

RD使用日志，首先是为了调试程序，当程序上线后，日志是为了记录err和trace。

PM可以通过日志分析，可以得出业务指标相关的统计情况。

日志的作用大致有三：异常、trace、统计。

日志使用的痛点

使用日志时大部分的场景或特点如下：

1.日志为纯文本，即可读。

2.日志分散在各个机器上，或者同步到某一台机器。

3.某某发现一个问题，让某某去查log。

这里有几个问题，或者说提高点

1.文本冗余度太大，浪费资源，如果转换为二进制，预估有5倍的收益。

2.日志分散，查找效率低，即使集中，在没有具体时间点情况下，扫描日志会很慢。

3.日志分析难度大，谁写的日志谁来查，查到和肉眼找到还差一步...

目标

所以，我们可以设计这样一个日志系统

1.支持海量数据的日志存储（TB二进制）

2.日志二进制、结构化

3.查询速度快，难度低

设计

读写日志

日志查询过程经分解和总结共性后，几乎是下边三种情况

1.K-V查询，比如基于某个消息ID，查询一条记录。

2.集合查询，比如查询某个用户的消息记录。

3.集合range查询，比如查询某个用户0点到1点消息记录。

那么，ssdb是非常适合这三个需求的。

日志系统具有写多读少的特定，再基于磁盘存储的业界主流方案，LSM是适合的，

而SSDB的存储依赖的leveldb正好属于LSM系。

日志二进制

一个大的日志是没办法人用肉眼扫描的，所以不如使用二进制代替以节约空间，但是日志

会随着需求的变化，格式也可能会变化，所以必须考虑二进制向文本反序列化时的

兼容性问题，那么protobuf是非常适合这个需求的。

海量日志

Sharding

业务的sharding，一个业务对应N个存储服务，N个业务对应N*N个存储服务，单一存储服务内只

承载一个业务。

磁盘的sharding，一块盘对应N个存储服务，N块磁盘对应N*N个存储服务。

        0    1      2     3     4

  db    |_____|_____|_____|_____|

        0      1t              4t

disk    |_______|_______________|

Resharding

扩容时增加存储服务即可。

缩绒时删除存储服务即可。

Failover

存储服务挂了后重启就可以。

由于存储的是日志，在机器发生故障后是允许丢的，所以数据不做迁移，只需将相应的服务等比例

迁走即可。