讲锋刃大数据方案之前，我们先整体看看大数据平台架构，有诸形于
内必形于外，很多局部状况的问题，需要从整体来看，为此，我们按照集
群状况，典型业务流程和数据流、系统架构瓶颈点的思路顺序，以表知里
的进行一下梳理。
一、集群状况的反馈
当前 Hadoop 集群系统性能繁忙（3 大区域 7 大机房）， 1000 多存储
机器对应 4000 多计算机器， cpu 平均值 70%-80%（晚 20 点到 0 点较低），
分钟负载很高，任务积压重； ech1 几百兆，峰值几个 g；磁盘 io 约几
百兆，峰值几 g，读写 iops3000。存储计算比为 1： 2，业务 job 还在增长之势，
： 3 到 1： 4 将达到集群瓶颈。
很多时候我们看到集群繁忙，只当作运维问题去解决，扩容集群机器，
调整机房部署，优化调度能力和虚拟化，增强任务监控管理等。却很少关
心集群上跑的都是些什么任务，为什么会给集群造成这么大的压力，我们
接下来通过梳理业务流程和数据流来搞清楚这个问题。
过对集群、采集、通道、统计、存储、数据治理、
idc、业务场景的全链路架构分析，归纳出以下瓶颈点：
1. Hadoop 集群的繁忙压力
2. 所有业务全部依赖离线 m/r 计算和 Hive SQL
3. log 采集的大量重复内容
4. MQ 集群每日消息总量万亿但无法提供内容过滤
5. 冷热存储、短期存储（天内）、长期存储（T+1，周、月、年）
混一起
6. 做到小时和分钟级别统计很难。
7. 没有一个统一精简的数据模型形成标准。
8. 业务的存储和计算还在迅速增长……
但是不可能所有的架构瓶颈都能在短时间内进行优化改进，我们需要
寻找一个最合适的切入点，先解决最迫切的问题
迁入实时计算进行优化的考虑
1. 经过分析了灯塔、应用宝、手机浏览器和手机管家，业务的相似主
线模式如下，更适合实时处理。
2. 清洗部分实时处理 DEMO 验证：相对于离线计算 MAP/REDUCE
的时间消耗换算，耗用机器数从 84 台降低到 15 台 m10，完成了 90% 的
数据量进行流式清洗，包括：从 kafka 拉数据 -> 解包 ->byte2string-> 清洗
->string2byte->， 5 分钟处理 10 亿消息数据， 333w/s，接近 mq 纯拉取消
费的 360w/s。
3. 清洗转换步骤，采用实时流处理架构如 Storm，通过 spout 从 MQ
获取输入流，自定义多个 bolt 并行处理输入流，再依此组合设计。