本文为WOT2016互联网运维暨开发者大会现场干货。JW万豪三角酒店盛大举行！黄慧攀表示，优拍云主要做CDN，所以网络中会有大量的日志输出，量级超乎想象。通常在处理这种规模的大数据时，会使用Hadoop、Spark等流行的解决方案，但排云并没有选择这些流行的算法。接下来，让我们深入了解一下云端，感受一下这种执行成本高但运行成本低的独特海量日志处理系统架构。有拍云业务架构概述业务架构黄惠攀表示，有拍云的业务架构非常简单原始。打印出所有NGS日志后，CDN边缘有100多个节点，每个节点有几十台服务器，是几千倍。服务器日志。每隔五分钟，边缘的每台服务器的日志都会被收集到原始日志服务器，然后从原始日志服务器提供给Work。Work可多可少，多为横向扩展。然后分析日志，最后生成统计数据，截取一些下载日志给客户。NGS上的一个CDN节点提供给所有用户访问，不管是大客户还是小客户，很可能你们都在使用同一个NGS，这意味着它的日志会混杂很多域名。那么日志处理系统将面临如何根据域名拆分这些日志呢？在拆分数据的基础上，如何做必要的数据统计和分析？原始日志的收集和存储黄慧攀表示，优拍云原始数据的收集经历了三个阶段，分别是2011~2014年、2015年、2016年。2011~2014V12011~2014年第一阶段。在中心设置一个FTP服务器，其他边缘服务器直接将日志上传到FTP，然后以简单的结构存储。黄惠攀表示，这种架构在等效层级较小的情况下，简单易用、简单成熟。但是一旦数据量变大，就会出现瓶颈。排云2014年开始做云存储，CDN销量不多，流量也不算大，数据量小，这个架构可以搞定。2015年，V1短板显现。随着这项业务的扩大，排云在市场上做了很多工作，对接了很多大客户，导致原木量翻了10多倍。那么之前2011年设计的系统只考虑了10倍的处理能力，所以FTP服务器的弊端和瓶颈都暴露无遗。比如FTP服务器接收不到那么多的客户端上传，边缘节点太多，FTP服务器连接的FTP进程有几千个。如上图所示，下面的Raid0非常不安全，一块磁盘损坏，数据全部丢失。虽然边缘日志缓存了7天，但边缘再次上报，及时修复不影响业务。但是导致人有点乱，不太好听。2016V22016年初第二阶段，对原有系统进行改造。将FTP服务器替换为Nginx服务器。NginxServer文件上传基于DAVModule，二次开发后可以接受文件请求。因为native模块只支持配置一个路径，即日志只能固定写入一个磁盘。但是，服务器不可能使用单个磁盘来存储它。每天有几百GB或者几TB的数据要存储，磁盘肯定会爆炸。当时还没有这么大的磁盘。因此，对DAVModule进行二次开发。比如按照日期，存储机一个6T的盘可以存储一天的日志。第一天使用1号盘，第二天使用2号盘模式。2016年V2.1第二版推出后，发现写盘成为瓶颈，而且由于是SATA盘，磁盘速度不够快，写不下那么多数据。此时，第三个版本（2.1版本）正在诞生实用版。将DAV模块从原始日期更改为文件名。此外，在此基础上进行了改进。上传过程中，同时将原始日志复制到下一个磁盘，这样可以避免因单盘故障而导致服务，不会有数据丢失的问题。尽可能多地尝试。担保业务可24小时不间断运行。该方案完美解决了原始数据采集问题。Cut-sort-mergecut-sort-merge对大量数据进行切割。一个用C语言编写的日志切割程序，每隔5分钟将每台服务器的日志按照域名切割成多个小文件，暂存在SSD盘上。切割完成后会有线程查看前一个小时切割是否完成。种类。想要让整理更简单，就需要在前期做好日志收集的规划。如果每五分钟有一个文件要上传，可以处理文件名（日期时间点，哪五分钟的数据）。比如一个小时有一千个小文件，在这千个中，肯定有一百个是属于某个五分钟的文件，直接对这一百个文件进行排序。排序时，无需将数据解压后放到其他地方暂存排序。就是打开这百个文件，把里面的每个文件都读一遍，第一秒读完，然后再问有没有其他文件，下一秒没有其他文件就跳过，这样一个一个读进去timeorder日志合并到一个特定的文件输出，这种模式是最高效的。因为在处理的过程中，不需要将特定的文件解压成文本。如果要解压，什么样的机器能保存原始日志是个问题，因为太大了。合并。切割整理完成后，每小时将12*N个小文件按顺序组合成一个1小时的日志文件，供客户下载。对大量数据进行统计分析。午夜合并的最后一个文件会启动统计分析的业务流程，可以综合得到一些有用的指标，比如热门IP分布、URL分布、客户端、来源、状态码统计等数据。系统架构演进过程中踩过的坑黄惠攀表示，自己在系统架构演进过程中遇到了一些坑，分享出来，希望大家不要踩坑。第一：SSD的inode数量不足，每隔5分钟就会有很多小文件被切出来，所以要格式化成最小的blocksize。第二：跨网上传很慢，需要多线支持；小运营商会改写内容，使用HTTPS。第三：日志存储盘SATA容易坏，需要写两块盘（SSD也会坏）。第四：服务器也不稳定，所以需要双集群的方式处理，保证业务不中断。存储服务器和处理服务器监控图最后，黄惠攀展示了存储服务器和处理服务器的监控图。他表示，目前海量日志处理系统架构基本非常稳定，集群状态正常健康，冗余度比较高。讲座视频：http://edu.51cto.com/lesson/id-100758.html【讲师简介】黄惠攀，排云CTO。他是aLiLuaWeb开发框架的作者。拥有14年互联网行业从业经验，技术经验涉及面广。早期专注于Web前端开发，后来逐渐转向底层研发方向。QCon、ArchSummit、中国架构师大会讲师，对高性能网络服务、分布式存储系统等有深入研究。
