引子
半夜三点，睡梦中被一阵没人接听誓不罢休的电话铃吵醒。睡眼惺忪的接听了电话，电话那头传来了不用听清任何人类语言就能感受的焦急。让我赶快打开电脑，说服务整个不工作了！
打开监控看到线程池被打满。本着“先恢复现场再排查原因”的基本原则，重启并扩容了一倍的服务器。服务又正常了。完美的做到了“三分钟定位，十分钟解决”。但是现场不在了，怎么排查根因呢？答案是：历史记录。
为什么要做历史记录
历史记录是大数据的最重要数据源。通过历史记录可以进行事件追溯、未来预判和推荐。举个例子：
静儿在网上搜索了“稳定性三十六计”这个词，找到自己想要的内容了。然后去做别的事情，再打开浏览器的时候，发现旁边的小弹出框里推荐我《稳定性宝典》这本书。
这个推荐效果很多种算法都能实现，比如最近比较火的“协同过滤推荐算法(Collaborative Filtering Recommendation)”。啥是协同过滤推荐算法呢？协同过滤推荐算法简而言之，就是找到相同兴趣的群体，将这个群体中感兴趣的其他信息推荐给用户。
实施的时候可以先建立一个大表，X轴是所有的推荐内容，Y轴是所有的用户。
然后我们将每个用户感兴趣的XY交叉点都标出来。如图可以看到对“稳定性三十六计”感兴趣的对“稳定性宝典”感兴趣的概率也很高。
历史记录对于稳定性，也可以将其他同类系统作为用户，将他们的问题作为推荐项进行协同过滤分析，找到自身的可优化点。系统出了问题需要分析原因时，事件追溯更是必不可少。
怎么做历史记录
日志
最常用的事件维度记录是日志。有存于本地磁盘和集中式日志两种。
本地磁盘日志就是将日志在程序中控制直接写入本地磁盘。
集中式日志的架构大同小异，基本结构如下：
- 采集器负责采集数据，并发送给收集器。
- 收集器负责收集采集器发送过来的数据，并定时写入集群。
- 存储中心负责对数据分类、排序、去重，把同类型的数据合并。
- 分析和可视化平台负责数据的展示。
以下是常用的数据收集系统的比较
| 产品 | 公司 | 优势 | 劣势 |
| Flume NG | Cloundera |
1.支持故障转移和负载均衡
2.容易水平扩展
3.社区活跃、文档丰富
4.依赖第三方类库少
5.通过事务保证数据一致性
6.支持多种存储
|
1.需要自己实现客户端代码
2.对数据的过滤能力差
|
| Scribe |
1.具有很高的容错性
2.支持水平扩展
|
1.依赖zookeeper或Hash等工具
2.需要自己实现客户端代码
3.社区活跃度低、文档少
3.依赖第三方库多
4.部署复杂
5.存储系统类型少
6.数据过滤解析能力差
7.官方已经停止更新和维护
|
|
| Chukwa | Apache |
1.高可靠
2.易扩展
3.社区活跃度较高
4.文档资料丰富
|
1.依赖hadoop |
| ELK | Elasic.co |
1.提供完整的解决方案
2.支持集群部署和水平扩展
3.社区活跃度高、文档丰富
4.部署简单
|
1.占用资源比较高 |
ELK不是一款软件，而是Elasticsearch、Logstash和Kibana首字母的缩写。这三者是开源软件，通常配合一起使用。而且先后归于Elasic.co公司的名下，所以简称ELK Stack。根据Google Trend的信息显示，ELK已经成为目前最流行的集中式日志解决方案。
Nosql
除了日志，任何有价值的历史信息都是应该存储起来做分析的。这时候存储就是关键。因为数据量大，对强一致性没有苛刻的要求。所以从成本上传统的关系型数据库不是首选。一般选择Nosql数据库。Nosql数据库主要有四类：
1.key-value数据库
| 项目 | 说明 |
| 典型应用场景 | 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统 |
| 数据模型 | Key指向Value的键值对，通常用hash table实现 |
| 强项 | 查找速度快 |
| 弱项 | 数据无结构，通常被当做字符串或者二进制数据 |
| 例子 | Redis、Memcached |
2.列式数据库
| 项目 | 说明 |
| 典型应用场景 | 分布式的文件系统 |
| 数据模型 | 以列簇式存储，将统一列数据存在一起 |
| 强项 | 查找速度快，可扩展性强，更容易进行分布式扩展 |
| 弱项 | 功能相对局限 |
| 例子 | Cassandra、HBase |
3.文档型数据库
| 项目 | 说明 |
| 典型应用场景 | Web应用，Value是结构化的，容易被解析 |
| 数据模型 | KeyValue的键值对，Value为结构化数据 |
| 强项 | 数据结构要求不严格，表结构可变、不需要预先定义表结构 |
| 弱项 | 查询性能不高，缺乏统一的查询语法 |
| 例子 | CouchDB、MongoDB、Elasticsearch |
4.图结构数据库
| 项目 | 说明 |
| 典型应用场景 | 社交网络，推荐系统等。专注于构建关系图谱 |
| 数据模型 | 图结构 |
| 强项 | 利用图结构相关算法，比如最短路径寻址，N读关系查找等 |
| 弱项 | 需要再次计算出所需信息，不容易做分布式集群方案 |
| 例子 | Neo4j、InfoGrid、Infinite Graph |
时序数据库
时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签的数据。带时间标签的数据也称为时间序列数据。
基于时间序列数据的特点，关系型数据库无法满足对时间序列数据的有效存储与处理，因此迫切需要一种专门针对时间序列数据来做优化的数据库系统，即时间序列数据库。
目前行业内比较流行的开源时序数据库产品对比如下：
| InfluxData | Prometheus | Graphite | OpenTSDB | |
| 数据模型 | labels | labels | dot-separated | label |
| 按时间分段管理数据 | ✔️ | ✔️ | ✔️ | 手动 |
| 分布式 | ✔️商业版 | 单机 | 单机 | ✔️ |
| 聚合分析 | 弱 | 弱 | 弱 | 弱 |
| 权限管理 | ✔️商业版 | × | × | × |
| 接口 | 类SQL | REST | REST | REST |
| 社区生态 | +++ | ++ | ++ | ++ |
| 时间序列分析 | 无 | 无 | 无 | 无 |
| 抽取日志指标 | × | × | × | × |
| Rollup | ✔️ | × | ✔️ | × |
总结
Talk is cheap, show me the data!
推荐阅读
关于作者
一线开发十二年，有日本东京和美国硅谷研发经验。有百余项技术发明专利，目前任美团点评技术专家。有自己的技术公众号「编程一生」。如果您在阅读本书时有什么疑问或者发现本书的错误，欢迎在公众号里给我留言。
