狠狠撸

基于 MySql 的日志分析系统设计 ?? ??? ??? ??? ??? ??? ??? ? 漆兴 [email_address]

主要内容日志分析系统查询需求分析访问特点分析基于性能考虑的系统体系架构基于需求的 mysql 优化及表设计基于需求的 memcache 使用其他开源工具的使用总结

系统介绍分析各大产物线的访问情况，以图形和图表的方式，提供各种监控及访问信息，为决策者提供可靠的数据支持系统目前支持的分析指标有， Hits 、带宽、 UIP （独立用户 IP ）、下载速度、下载时长、响应时间、受访 URL 、受访域名、来路 URL 、来路域名、全国用户分布统计、运营商分布统计、受访文件大小、文件类型、 Squid 命中率、请求响应类型、异常用户统计系统基础工作 : 各业务部门统一 web 服务器的日志格式

系统需求特点海量数据实时性写多读少系统现状 : 天表每天增量千万级 , 每天入库上 1 亿条。数据库增量 400G ， www 日志存储增量近 2TB

系统架构说明该系统架构根据功能模块可分为如下节点 : A(Agent) B(Bee) D(Data) M(Manger) R(Relay)

采集节点功能：负责推送日志到 B 点实现过程：利用 Rsync 实现推送，以接口方式访问 M 点获取 Rsync 的目标地址动作：在每五分钟内切割完日志并推送。每小时获取 M 点更新的配置完成自更新数据格式：压缩后的统一规范定义的标准日志格式

运算节点功能：根据需求分析日志并推送到 D 点运算机制：逐行分析日志 + 多进程工具 : 使用 FaceBook 的 HipHop 加快运算速度频率：每两分钟调度分析脚本分析结果：保存为文本，格式为 sql 语句。如 insert into table values ( ),( ),( )

Relay 点存在的意义 : 保障数据传输的速度及效率，减少网络问题导致的数据阻塞及不完整性问题重现 : 电信和网通之间的互相访问问题，导致日志传输丢失或不能在规定时间内到达指定节点解决方法 : 电信服务器访问电信，网通服务器则访问网通

数据节点功能：负责将接收到的 sql 文本入库动作：在每两分钟运行入库脚本。每天定时创建分钟表 (m_ 表 ) ，每小时将分钟表中过去一小时的数据聚合 , 即 h_ 表，每天聚合前一天的小时表数据，即天表 d_ ，以及触发器及存储过程的调用。将最近三天的分钟表，最近三个月的小时表，定义为热数据，并定期创建为 merge 类型，方便程序的编写。

展示节点数据访问接口 : 通过增加数据中心层来封装对数据库及缓存等数据的读取，方便程序员编写代码，减少业务逻辑数据库代理 :Amoeba 展示方式 : 图形 + 报表 +Flash 使用工具 : Mysql5.1+Php5.3+Amoeba+Fushionchart+Apache +Memcache 等

管理节点功能 : 掌握各大节点的系统运行状况，资源使用情况任务列表 : 负责管理调度系统其他节点 , 管理各节点的 Rsync 地址，分析 B 点的运算结果，健康检查，日志传送数据的完整性及过期信息处理等工作工具 :Gearman 好处 :Gearman 使任务的分发变的更加灵活，避免登录多个节点获取信息，提高运维效率 , 方便多服务器管理。

Gearman 介绍 Gearman 流 : Client: 请求的发起者 Job: 请求调度人，负责把 Client 的请求转发给相关的 Worker Worker: 请求的处理人，

Gearman 实例具体实例 : 在各大分析点起守护进程 worker.php 监听指定的端口在 M 点命令行下运行 client.php cmd 来执行各种工作 cmd 相关安全性检查

数据节点—瓶颈分析 Vmstat 下 bo ， wa 的值都很大，磁盘随机访问量大 2. IO 瓶颈 :insert 频繁且量大，造成磁盘写 IO 增大 3. cpu 瓶颈 :sum,order by,group by 操作比较多， cpu 容易出现瓶颈 4. select: 量大 sending data 比较耗时，索引失效，全表遍历造成磁盘读 IO 量大，造成读等待 5. 累积伤害值 :cpu 过度使用造成大量进程的等待，系统响应变慢进程数累积增加，导致内存使用增加，内存耗尽则导致虚拟内存的使用，最终又导致磁盘 IO 和 cpu 的超负荷使用，其他系统开销增多，系统平衡被打破

数据节点 - 展示相关表引擎 : 使用 MyISAM,Memory 表操作 : 多为 insert ，无 delete ,update Query 分析 :Select 操作及 sum,avg,group by ,order by,limit Where 定向 : 多为时间粒度及产物线等多角度混合查询。时间粒度 : 最近五分钟 , 最近一小时，最近 25 小时等查询条件 : 按产物线 , 运营商，城市，机房，服务器

数据节点—表的设计考虑到需求上涉及到的操作时间相关 , 如最近五分钟，最近一天，最近一小时等 , 从数据库中读取的数据大且更新频繁，所以采用按时间拆表及对时间建立索引的方案 , 使用引擎 MyISAM 具体如下 : 1. 对各种时间粒度建立索引应对复杂的组合查询，按天，小时，每五分钟 ( 一天 288 个点 ) 建立索引。采用整形如选择 2010 年 04 月 03 的 128 个五分钟 ,where minf=20100403128, 这种方式虽然增大了字段长度，但是对索引的查找及索引的基数的扩大都是有帮助的，属于用空间换时间。 2. 使用分区特性，在每天建立的 m_ 分钟表中按小时建子分区 3 ，在 MyISAM 表中尽量使用定长类型

数据节点—表的设计续 4. 将 IP 字段存储为整形 5. 大数据量表按时间拆表 6. 规范表命名 m_20100317_www_top_refere,h_,d_ 7. 使用 merge 表 8. 对于过期的只读表进行 myisampack 9. 使用 enum 使 PROCEDURE ANALYSE() 10. 根据业务需求将产物线及时间建立联合索引

数据节点的优化— Mysql 架构优化增加数据库节点按产物线分库按时间拆表

数据节点的优化—单 D 点的优化瓶颈 : 磁盘 IO 优化方式 : 初期 : 1. 将 m,h,d 表的索引文件及数据文件分布到不同磁盘 2. 将数据库指向不同的磁盘 3. 禁止系统更新文件的 atime 属性

数据节点的优化—单 D 点的优化瓶颈 : 磁盘 IO 是主要问题优化方式 : 硬件升级后期 : 操作系统及文件系统调优 raid0 或 lvm 条带化修改相关 mysql 参数 sql 语句的慢查询分析及索引调优

数据节点的优化—单 D 点性能分析没优化前 : 负载比较高，时常会超过 10 ， CPU Idle 经常会小于 30% ，有时 Idle 为 0 ， CPU io wait 比较大优化后 : CPU 的负载降了一半左右，同时磁盘写入性能比之前提升了一倍之多

数据节点的优化—特殊需求优化使用 tmpfs 作 cache 磁盘 (ramdisk ）优点 : 内存操作，没有磁盘 IO 消耗，不用修改应用程序缺点 :cache 空间有限 Mount –bind /dev/shm /var/www/cache 写一个清 cache 的脚本程序，配置在 cron 中， 3 每小时执行一次，检查 /dev/shm 的使用率超过 60% 时，使用 find 命令找出太旧的 cache 文件删除掉

数据节点的优化— infobright 使用 1. 采用开源 ICE 版进行相关日志分析 2. 将涉及到跨天及跨小时的非实时数据，导入到 infobright 3. 充分利用列数据的特点，提搞了 select 速度及减少了预处理的量，和相关统计报表工作 4. 效果 : 千万级表，包含 sum,group by,order by 操作 ICE 比 MyISAM 快几倍

数据节点的优化— infobright 特点列存储适合范围查询及群组操作，查询高效服务形式及接口跟 mysql 一样，学习成本低高压缩比列，减少磁盘空间无需建索引，避免索引的维护及增长问题缺点： ICE 版无 DML 操作，但支持 load data infile

数据节点的优化—硬件 Scale up 方案目的 : 增大系统的 I/O 吞吐量 Raid 或 LVM 条带化

数据节点的优化— Mysql 应用优化适当的数据冗余，尽量避免数据库的 join 操作几个时间段对比操作，使用 union 的效率高于 in 和 or 的连表操作对热数据进行预处理 , 避免用户引发计算 , 所有计算结果尽可能提前生成 , 后台程序生成结果 --> 直接调用频繁更新的表，使用 Memory 表对于不定长的字段类型可指定前缀长度

MySQL 参数设置 1. 提高 read_buffer_size 的值 2. 高并发插入优化 Concurrent-insert =2 3.delay_key_write 4. bulk_insert_buffer_size, max_allowed_packet 5. 关闭 query_cache 6. key_buffer 及 key_buffer_size 的值增大 7.sort_buffer_size ，并不是越大越好 8. 加大 max_length_for_sort_data, 对于 big result 让其采用改进版的排序算法

MySQL 相关设置 1. 增大 tmp_table_size 2. 增大 table_cache 及 thread_cache 的值，避免频繁建立和断开链接 3. 用 mysql_unbuffered_query 取代 mysql_query, 4. 用 mysql_pconnect 取代 mysql_connect 5. 使用 SQL_BIG_RESULT 来提示 mysql 优化引擎更好的处理大数据量 sql 6. 使用 MyISAM 表可使用索引数据的预加载功能

数据节点的优化—多 D 点的架构展现层向 Proxy 发起 Query 请求， Proxy 将请求分发到多个 DB ，然后将结果合并后返回当单个 Proxy 负载过高的时候，可以启用多个 Proxy ，展现层通过简单的取模来连接不同的 Proxy

数据节点的优化—多 D 点的设计启用多个 D 点 ( 比如分静态池和动态池 ) ，单独产物线的从某个 D 点取数据，跨产物线的时候从多个 D 点取数据并进行合并。测试了如下方案 : 1. 基于 php5.3 的 Mysqlnd 2.Ameoba

多 D 点方案测试 :mysqlnd 如图 :mysqlnd 少了从 mysql 驱动中复制数据到 php 扩展这一步。更亮的特点是 : 异步获取数据的能力

多 D 点方案测试 :mysqlnd 吸引力 : 除了性能上的提升 ,mysqlnd 支持异步获取数据困难 : 需要改动应用层的取数据函数，因为之前这部分代码不统一，所以需要改动不少从测试来看，异步取多个数据库的结果时，可能会出现返回数据不正确，以及执行顺序错误等状况 ( 怀疑是和 Apache 在一起使用的问题， CLI 下正常 )

多 D 点方案测试 :Amoeba Amoeba 测试结果 : 支持高可用性，负载均衡。对多数据库读取的结果只是分别执行然后直接拼接 ? 高并发情况下，有时会出现到 Amoeba 的连接无响应高版本下高并发的性能表现已经改善不少

数据节点的优化—结果通过上面几个方案的测试 , 架构调整选择 Amoeba Proxy 是目前比较合适的方案，数据切分可以通过 XML 灵活配置，对应用层的改动比较小，也相对比较稳定 . 由于磁盘做 radio0 ，对数据的保护不够，所以要加入备份的考虑及产物线增多后数据缓存的利用率

数据节点的优化—缓存 Memcache 客户端缓存数据页面静态化 Php 级 opcode 缓存 xCache

数据节点的优化— Memcache

数据点的优化— Memacahe 应用 memcache 有 1m 限制。如果列表太大 , 采取拆分数据，用 key+ 特殊标识来保存整个序列。在获取的时候批量 get 来一次性得到这个列表。预处理 : 提前生成需求数据到 cache 中写库 : 进行数据的预处理 , 写入到 memcache 服务器中读库 : 根据时间选择应该已在 cache 中的数据 + 最近生成的数据拼成最新数据展现缺点 : 维护多个存储操作增加了应用层逻辑复杂度优点 : 减少从数据库读取海量数据的问题及避免重复计算

数据节点的优化— Memache 应用优化 Memcache 自重启 deamon tools 监控程序，让其在挂掉时重启开启数据压缩功能 $memcache>setCompressThreshold 根据数据量大小修改 slab 及 factor 的值提高内存利用率使用类似 get_multi 方法发送请求减少客户端和服务端的通信

使用到的工具 Gearman 用于分布式节点的管理 Memcached 缓存数据 Amoeba 展示层数据库代理 Php 5.3 FACEBOOK 的 HIPHOP INFOBRIGHT 的 ICE 版

对业务需求了解透彻是技术架构的基础标准化，减少错误的发生根据业务形态、网络情况选择适合的技术架构方案用合适的数据库做适合的事情以组分布 , 各组之间架构一致，便于横向扩展及管理最大化减少客户端到网络端的网络延时为系统中不同应用选择适合的硬件根据情况选择开发环境、开发语言及工具等总结

狠狠撸

海量日志分析系统实践,顿产补

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 海量日志分析系统实践,顿产补 (20)

More from Cevin Cheung (7)

海量日志分析系统实践,顿产补

Editor's Notes