摘要
行为日志在这个大数据时代的作用日益重要，怎样更好的收集、存储、管理日志也是值得研究的一个问题，大型互联网公司一般都有成熟的日志聚合方案，但是每个公司尤其是中小型公司都要针对自己的应用场景来做技术选型，本文主要针对中小型公司如何以较小的成本快速构建一个行为日志聚合体系以及在建立日志聚合过程中要处理哪些问题。
关键字
日志收集，消息队列，数据仓库，生产者，消费者
原始阶段
最初公司使用日志收集的方式极其简单粗暴，数据量大的以文本文件形式存在本地磁盘，数据量小的存在各个数据库（比较重要的日志）。这种方式实现起来简单，但是存在诸多问题：查询极为不便，需要到到各服务器去查找日志；一般数据库的存储量级有限，如果要存大量数据需要水平分表，给运维和开发带来额外的负担；各个子系统的日志处理不统一，还要额外维护日志处理程序；日志分散会对后续的数据分析造成不便。所以作为互联网的分布式系统或微服务架构，日志是需要中心化管理的，需要集中统一的收集处理，才能降低开发和运维复杂度。
初级阶段
大型互联网公司应用比较多的方案是Flume+Kafka+Hadoop，当时觉得实现这个对小公司来说会增加额外的运维成本而且只有两个人在做调研。Kafka作为日志队列应该说是比较适合的，既能作为离线存储，又能用来实时计算。日志数据仓库选择了GreenPlum，原因是使用简单且高性能，因此先采用Kafka+GreenPlum方案，这样中间环节比较少。然后开始使用Kafka生产者SDK开发我们自己封装的日志发送SDK，还要使用Kafka消费者SDK开发日志投递中间件，这样从服务的日志输出到Kafka消息队列再到落地GreenPlum就完成了日志聚合过程。在考虑方案时要注意几个问题：整个方案必须支持在线扩容，无论是日志发送、消息队列、中间件、数据仓库中间哪个环节出现异常都要基本保证不丢失数据，这些服务在维护期间日志需要缓存，小团队在技术选型时尽量使用云商提供的产品从而降低运维成本。向Kafka发送数据时有两种模式：至少发一次、仅发一次，至少发一次确保数据不丢失但是可能有重复，仅发一次可能会丢失数据。我们希望尽量不丢失数据所以选择至少发一次，这样需要做去重处理，我们对每条日志做MD5缓存到Redis，Redis设置缓存时间。
演化阶段
使用Kafka+GreenPlum方案时发现一些问题：Kafka生产者SDK在日志量大的情况下占用较多CPU；Kafka生产者SDK将日志缓存到内存批量发送的，缓冲区有大小限制，这样在异常状态下可能丢失数据：Kafka修改有些配置需要重启集群，这样对线上维护就有影响了；Kafka不能同时使用公网地址和私网地址，我们有跨地区传输日志的特殊需求。基于这些考虑我们给消息队列增加了二级缓存Flume，Flume支持扇入扇出、支持各种网络协议、包含Kafka功能插件，这样我们在开发基于Flume的日志发送SDK时可以比较灵活的控制。因为我们有跨地区发送日志的情况，所以在网络不稳定时日志发送SDK需要持久化数据到本地，使用退避算法检测网络状态，网络恢复时批量发送本地日志。由于Flume支持持久化并且可以用负载均衡器实现高可用，Kafka也就能更灵活的维护。对于跨地域传输，我们通过自己建立隧道、一个负载均衡器挂接多个Flume可以实现。到此为止整个方案演变成Flume+Kafka+GreenPlum，日处理日志记录2亿条、产生100G数据。
最终阶段
GreenPlum一个表亿级数据能达到秒级返回，但是如果一个表的数据量达到几十亿级查询速度就是分钟级返回了。GreenPlum虽然有分区表，但是分区表不宜过多，过多会影响查询速度，而我们的日志是按时间记录，最适合的分区字段就是时间，时间又是无限的，这样势必造成分区问题，如果按月分区一个分区数据量过大导致查询速度慢，如果按日分区分区数太多导致查询速度慢。因此最终决定将日志迁移到Hadoop集群，Hadoop是以HDFS文件目录来做分区索引，这种模式非常适合以日期作为分区的场景。Hadoop查询一个分区的数据，速度确实会比较快，但是复杂查询需要聚合多个分区数据的时候性能比GreenPlum差很多，只有依赖于投入更多计算资源提高并行计算能力，GreenPlum适合存储报表数据以便快速查询在前端展示。最终方案演变成Flume+Kafka+Hadoop+GreenPlum，Hadoop作为行为日志数据仓库，GreenPlum作为报表数据仓库，Kafka作为实时计算和离线存储的日志消息队列。
总结
本文描述了行为日志聚合从零到壹、从量小到量大、从简单到复杂的演变过程，适合小团队参考。
