在线网络游戏数据分析的架构及优化在游戏以及其他应用的研发和运营过程中，如何了解应用的运行状况成了一个问题。为了解决这个问题，我们像大多数公司一样，开始组建自己的数据分析团队。到目前为止，行云数据分析平台每日接收和处理的原始日志有200GB左右，集群规模在20台服务器上下，每天为数十个产品的日常运营提供数据支持。在这个过程中，我们在数据处理技术方面做了很多的探索，在此也希望和大家分享一下。系统架构数据处理系统的架构和流程，最基本的框架流程如下图所示：每天，来自各个项目的数据每时每刻都在打入数据分析系统。这些数据通过数据采集环节，被初步整理成一定的格式，然后录入集中的数据存储系统中。当然，我们系统呈献给用户的是各种统计指标。所谓统计指标，即对原始数据的聚合，形成一定的统计结论。所以，我们需要有查询系统，基于海量的数据进行。在我们的系统中，各个部分的技术选型如下：紫色的部分即为各个部分的技术实现客户的应用数据，通过RESTAPI打入数据处理系统中。这部分我们考虑使用PHP来实现，主要考虑其实现简单，便于水平扩展；处理速度也可以接受。RestAPI接收到的原始数据，在进入存储之前，还需要进一步整理，主要有两方面的原因：一是一些不合理的日志需要筛选出去；二是我们在这一步，有时候需要把接收到的数据转换成更基本的数据。一个例子是应用程序可能会打入一个应用加载事件visit。那么，我们收到visit的时候，还需要判断这个用户是不是第一次出现；以及用户加载的时候的一些refer信息，等等。所以，这一步的逻辑比RestAPI要复杂，做这些逻辑判断所需要的信息也更多，因此我们选用java开发了这一模块。我们收集到的大量数据，有两方面的信息：一是事件信息，记录发生过的事件：用户A在某个时刻登录了一次；用户B在另一个时刻进行了一次购买，等等。这种事件信息占了系统所存储信息的大部分，而且绝大部分是不断新增的数据。我们采用HBase来存储这部分信息，一方面，HBase对于批量的写入性能很好；另一方面，在rowkey设计合理的情况下，其索引和查询性能也不错。除事件信息外，还有用户的属性信息，比如用户A所在地区位于中国，用户B首次充值的时间为2013年1月1日，等等。这种信息的访问特点是插入和更新都比较多；在查询的时候，既要按照主键（用户ID）来查询，也要按照属性值（例如前面提到的充值时间）来查询。这就要求同一个表有多列的索引能力，所以，我们目前采用了MySQL来存储用户属性信息。当数据都导入了以后，我们就需要一种系统，具有从HBase和MySQL这种异构存储之上进行查询计算的能力。基于原始数据的聚合计算是一个相对来说比较耗资源的过程，在去年，我们主要使用MapReduce进行这个计算过程，当计算完成后，把结果保存起来，用于展示。这样做的限制在于，系统所展示的数据只能是预先算好的；用户无法动态地对报告进行修改。基于这个问题，我们很早就开始关注交互式查询技术的进展。今年，分布式环境下的SQL查询系统成为一个发展中的热点技术，有若干个这样的系统陆续浮出水面。目前来看，Drill属于发展较晚的一个项目，但其开放、可扩展的架构能很好的满足我们的需求。所以，我们围绕Drill，构建了我们的SQL查询系统。这样，任何能通过SQL表达的数据报告，都可以通过我们的系统来实现了。现在，用户可以通过界面构建任何他想要看到的报告，然后就能在比较短的时间内得到他想要的结果。上面提到，聚合计算是一个耗资源的过程，即使是现在我们采用了基于drill的查询系统缩短了响应时间，计算后的结果也需要保存下来，以应对用户的查询。我们使用Redis来保存我们的计算结果，主要考虑Redis优秀的随机查询性能。作为系统的展示层，我们使用了RoR+backbone+coffeescript的组合。这个层面选择的自由度就比较大了，coffeescript应该说是作为python爱好者的首选，用来配合backbone构建富客户端程序；RoR用来完成各种界面操作的RestAPI以支持客户端的运行。总体感觉，这个组合还不错，开发起来也快，同时界面表现也不错。相关调优理论上来说，性能调优是一件永无止境的工作。在大数据的背景下，似乎很多问题都可以通过加机器来解决，调优的重要性看起来更低了。但事实上，调优是我们的重要工作之一，原因有以下几点：首先，作为小公司，资源毕竟有限，在集群环境下，调优的成果也具有集群效应；其次，由于我们的系统基于交互式查询技术，那么系统各个环节性能的提升无论对于数据响应的速度还是数据生效的实时性，都会有直接的影响。所以，我们在系统的各个环节、各个层面都进行了调优。如果用一句废话来解释的话，数据处理系统的特点是（顾名思义）需要处理的数据有很多，所以调优的核心目标只