运营商关注光网的发展与客户的使用体验，客户的互联网使用体验提质一般采用两种方式进行处理。一是观注在OLT上每个用户的光衰进行主动处理，二是通过客服热线或用户测试网站进行被动处理。但这种方式仍存在问题，通过OLT主动查看用户的光衰只关注了最后一公里，而客户是观注端到端的使用体验，该方式仍存在弊端。今天我们来探讨，有什么办法可以做到端到端的互联网业务主动改善？
一、要想知道鱼在想什么，就需要做一条鱼。我们需要变成用户来进行业务体验。
建议从离用户最近地方主动发起端到端的业务使用体验探测。理论上光猫是一台小型的Linux服务器，可以在光猫上预置模拟http等访问的程序，并通过log日志的方式进行数据的记录。这样可实现用户体验信息的主动检测。
二、如何将光猫上的log文件进行大数据分析，以实时呈现故障预警、或应用于指导网络扩容。
1、整个系统的架构分为两部分。上面部分用于离线计算，指导扩容。下面部分用于实时流式计算，指导故障预警。
2、首先我们来讲实时流式计算部分。光猫不断产生http探测日志, 然后使用Flume去监听探测日志，并实时把每一条日志信息抓取下来存储集中式Flume agent中。Flume agent的数据存进Kafka消息系统中, 接着由Storm系统消费Kafka中的消息，同时消费记录由Zookeeper集群管理，这样即使Kafka宕机重启后也能找到上次的消费记录，接着从上次宕机点继续从Kafka的Broker中进行消费。但是由于存在先消费后记录日志或者先记录后消费的非原子操作，如果出现刚好消费完一条消息并还没将信息记录到Zookeeper的时候就宕机的类似问题，或多或少都会存在少量数据丢失或重复消费的问题, 其中一个解决方案就是Kafka的Broker和Zookeeper都部署在同一台机子上。接下来就是使用用户定义好的Storm去进行日志信息的分析并输出到HBase，最后用Web APP去读取HBase中信息并展示给监控中心。之所以在Flume和Storm中间加入一层Kafka消息系统，就是因为在高并发的条件下, 日志的数据会井喷式增长，如果Storm的消费速度慢于日志的产生速度，加上Flume自身的局限性，必然会导致大量数据滞后并丢失，所以加了Kafka消息系统作为数据缓冲区，而且Kafka是基于log File的消息系统，也就是说消息能够持久化在硬盘中，再加上其充分利用Linux的I/O特性,提供了可观的吞吐量。
如果数据量较大，可以在HBase旁再旁挂一个Redis数据库，这样Web App的数据呈现效率会更高。Redis是内存数据库，但也可以进行数据的持久化存储，同时具有很高的数据读写速度。
3、首先我们来讲离线计算部分。通过Flume的多个Sink，将日志文件同时写入HDFS中。通过Spark的定期离线任务处理，将HDFS中的文件进行分析处理，因Spark基于mapreduce，处理效率较低，适用于离线处理。将非实时的数据按周、按月处理后，提供给管理人员，供升级扩容等建设使用。之所以采用HBase存储输出数据，是为了简化本项目中的数据库类型，目前HDFS进行文件存储、HBase进行类结构化数据的存储足够。
