今天终于又能抽出一点时间来写文章了，接着前一篇继续写。前一篇文章有博友就评论说写了很多废话，其实本身就是一些工作中的点点滴滴，自己想到什么就写什么，没有太多的构思文章的内容和结构，就算自己回顾自己工作的这五年吧。
上篇博客提到自己主要支持各个团队使用scribe归集日志，这也包括归集日志到hadoop系统里面。所以这时的自己开始接触hadoop生态系统了，刚开始也是从网上找各种安装使用教程，遇到各种问题也基本上都是通过google解决。通过安装和使用hadoop，对hadoop大部分概念也有了清晰的认识，为了加强对hadoop的深入理解，按照网上很多人的建议去看了Google的论文。从论文里面了解了很多系统的设计原理，这样就更加清晰的知道了hadoop为什么能够这么强大。后面也逐步接触了hive、hbase、zookeeper等，当然也对应的看了Google论文。因为兴趣，开始想深入的学习hadoop生态系统里面的实现原理，所以看了一部分源码，后面为自己深度改造hdfs提供了一些基础。工作中使用到hadoop，hive和hbase。hadoop当时主要就是为了做一些统计分析数据，也就是把各个系统需要统计分析的数据归集到hadoop系统里面，然后使用hive来做查询和统计，可能把每天的统计结果又写入到MySQL里面，最后通过web界面来展示这些结果。不过这些当时主要处理的是离线数据，数据量也不是很大，所以还是很轻松的完成这些功能。不过当时比较麻烦的就是怎么去把各个系统散落在各个服务器上的日志归集起来，这些日志数据基本上都是以文件的方式存在，而且还是在不断的增长。所以必须要有一种机制去实时增量的抓取，当时自己就简单的写了一个Python脚本去实时tail文件，每间隔一段时间就去增量tail一次（可以配置，基本上是1秒的间隔），需要采集哪些文件也是通过配置文件配置。如果采集的文件很多，那么配置文件都很麻烦，一旦配置错误还会采集不了。不过这些工作都为自己后面设计和架构统一日志平台积累了经验。最终完成了使用Python客户端去实时抓取增量日志，然后发送到scribe集群，最后根据scribe的配置信息将数据写入到hdfs中。散落在各个服务器上的日志数据通过上面的方案归集到hdfs以后，各个业务团队就可以根据自己的需要使用hive去统计和分析数据了。那个时候大家的业务统计分析都很简单，要不要求实时，所以基本上不用去考虑像目前很流行的实时计算框架和流式计算，但是随着以后业务的发展肯定会涉及到，所以当时也偶尔关注一下当时比较流行的storm（那个时候还没有spark这一套系统）。这一个项目基本上就是做了这些事情，特点就是技术支持和基础环境搭建，目标就是把各种散落的数据归集到hdfs当中去。不过随着业务的增多，如果还是按照这种思路去解决问题，那么可能需要搭建上千套数据归集系统，不论从人力资源还是服务器资源都是不划算的，而且都是重复的工作。为了解决这个问题，我们后面重新开发了统一日志平台，通过只一套系统解决所有业务的数据采集、传输、转发和归集等功能。不过在做这个统一日志平台loghub之前，我还做了另一个项目，那就是云存储系统。
有一段时间国外的dropbox非常的火，火的原因是一个比较新颖的产品和它当时所获得的融资。由于dropbox火了，国内各大公司都开始模仿这个产品，做出了很多各种网盘，当时我们的老板也敏锐的发现了这样一个产品，然后就快速成立项目组调研分析。经过快速的调研分析，最终这个项目也落实到我所在的技术团队。不过由于这个项目比较庞大，我们内部还是分成了三个项目组，分别负责不同的功能。当然我们的功能是按照层划分的，最终划分的是三层，所以就是三个项目组。最上层的是现在大家可以直观看到的网盘，就是最终的应用层，中间层我们叫做boss层，负责提供元数据的管理和权限控制等功能；最后一层也是最底层的数据存储层，我当时就是负责这一层的技术。当然我是后面加入的，因为这个项目组成立的时候，我正好在外面长期出差支持上面我提到的项目。当然数据存储是计算机领域最难的技术领域之一，它的难点是保证数据的可靠性、一致性和对外提供高性能的读写等。当时团队的所有成员都没有任何这方面的经验，所以大家就需要在网上寻找各种资源学习相关知识，在对基本知识有所了解以后就开始调研是否有合适的开源系统可以作为基础来开始搭建系统。当时经过各种调研和讨论，选择了glusterfs分布式文件系统作为我们数据存储的系统，选择这个的原因非常多，当然由于当时我们的经验和专业知识都不是非常的优秀，一般在调研的时候都只看到这些开源系统的优点和它的热度。在当时的情况下，glusterfs确实满足了大部分我们所需要的特性，而且当时也比较的火，关注的人多。现在其实glusterfs也是很不错，发展也挺好的。不过当时我们没有能力去判断它的缺点，以及如果数据量达到一定程度为出现什么样的瓶颈，还有在一些特殊场景下是否能够很好的支持我也是没有办法去判断。虽然有了存储系统的软件系统，但是作为最早数据的存储还是需要真正的硬件存储设备的。当时我们也花了很多时间调研各个厂商的硬件存储设备，而且还真实的测试了很多硬件存储设备的性能。不过最后还是没有使用专业的硬件存储设备，还是选择了一般普通的pc server加企业级硬盘。所以都准备就绪就开始真正的研发系统了，我们开始对glusterfs进行各种性能测试，各种源码研究，然后考虑对它进行源码改造以及优化。整个源码研究期间其实就是最爽的，因为可以通过源码学习到很多知识，包括各种编程技巧和架构设计。我们也通过定期的分享和讨论每一个人研究源码的进展和成果，当然有一些不明白的也提出来大家一起想办法弄清楚，有很多有争议的地方大家通过不断的讨论最终确定。当然定期分享和讨论主要是让大家对各个模块都有清晰的认识，因为模块之前本来就是关联很密切和相互依赖的。通过讨论和分享也可以增强大家对所掌握知识的加深。这个时候的团队就想一个创业团队，为了达成最终的项目目标全身心的投入到其中，当然每一个人的能力随着自己投入的多少也是成正比例提升的。除了和项目组内容本身进行讨论之外，我们也会和其他两个团队进行交流和开会，因为我们最终才会形成一个完整的产品。当然后面存储层和boss层不仅仅支持网盘，还支持了其他很多项目组的数据存储任务。我除了支持本项目组的开发和研究任务以为，也会支持其他两个项目组的技术方案讨论和研究。这个项目本身和其他项目一样，就是按照计划不停的往前推进，在这期间也经历过很多的加班，甚至通宵。因为面对的是全新的技术和产品，所以大家都是十分的投入，一是相信这个产品，二是相信使用到的技术对自己能力的提升以及未来技术的发展都是充满信心和期待的。任何一个项目在真正使用期间都会遇到各种问题，有些问题可能是很简单的bug，简单修复一下就ok了，但是有点的问题可能已经超出所有项目组能力范围了。其中遇到一个问题就是由于linux内核的bug导致了线上多台服务器挂起假死，当然最开始我们并不知道是由于linux内核bug造成的，是通过各种问题的定位和排查确定的，当时经过了无数个通宵去排查和解决问题。当然最后确定是linux内核bug问题以后，这个问题就全部交给我了。从我以前的博客文章可以看到我对linux内核bug问题的排查，当然这些问题的排查都是利用业余时间，正常上班的时间还是继续正常的工作任务。每一个项目都有共性，当然也有很多它独特性，对于技术人员来说，唯一不同的就是使用到了不同的技术。在研究一个新技术的时候我自己喜欢不停的总结和跟踪发展，总结一般就是通过博客进行，可以看到我在工作中使用的很多技术，只要不涉及公司秘密的技术，我一般都喜欢总结分享，因为只有总结分享了才使自己进步更快一些。这个项目最终以移交给其他团队作为我在这个项目中的工作结束，虽然有各种不舍但是也能够顺其自然，因为也可以去全新开始另外一个项目和研究一些新的技术。
云存储项目的工作结束以后，我就开始了统一日志平台的工作，前面也提到了。具体这一部分的经历和总结等下一篇继续介绍。
