总的来说，游戏数据平台的工作内容就是围绕“数据”+“服务”。现在专注独立运营游戏之后，数据平台的重要性就更加突出了。但是，目前的各个系统还不能很好地支撑这次业务上的重大转变，我们需要一个全局的思维来重新规划整个数据平台，包括怎么收集和处理数据、怎么更好地对外提供服务等等。
一、从数据的角度来看，数据包括：收集、存储、分析（挖掘）、展示、提取。兼顾目前的系统，收集、存储、挖掘、提取，这几个环节的系统需要加强。特别是收集和提取这块。
由于历史的原因，加之没有系统规划过，之前的数据收集来源比较零散，这样导致分析数据时需要从各个地方来同步数据。当业务多了之后，这些乱七八糟的来源就够让人头疼了。这次规划的一个重点就是，建立一套游戏数据收集系统。游戏分析涉及的数据（日志类）都从这个系统中获取，不再单独分析各自的业务数据。业务系统采用数据上报的方式，按照固定的格式来上报数据。例如：登录、注册、充值、消耗等等。
采用这套游戏数据收集系统，还有一个重要的原因。现在我们的游戏都是独立运营游戏（我们是甲方），那么我们就可以采用类似腾讯的办法，事先定义好数据规范，要求游戏方按照我们的格式上报相关数据给我们。这样我们的数据分析系统就可以做到非常通用。不管接多少游戏，分析和展示系统都统一。
数据提取，这里主要是指临时数据。这是我们这边的一个顽疾。临时数据其实包括两个部分：数据来源和数据分析。一个常见的需求就是：分析一堆帐号（数据来源）的后续行为（数据分析）。因为临时数据的业务规则复杂，并且数据来源千奇百怪，之前采用过全手工、全自动的方式来实现，但是都失败了。现在想到的一个解决方案就是，基于游戏数据收集系统之上，再开发一个临时数据分析系统。
游戏数据收集系统统一了数据的来源和格式，方便存储和提取原始数据。这基本解决了数据来源的问题。临时数据分析系统，可以事先实现常见的分析逻辑（例如：登录、留存、保有、付费人数、付费金额、消耗等等），然后采用过滤器模式或包装器模式来实现。这其实是一个半自动化的方案。系统的用户是开发人员和产品人员。开发完这套系统应该可以省掉60%以上的临时数据任务。
另外，只要数据都是来自这套游戏数据收集系统，存储、分析，包括挖掘都会简单很多。存储都会在HDFS上，分析基本都使用Hive，挖掘用Mahout。
游戏数据挖掘是需要单独发展的一块业务，特别是现在专注独立运营之后。目前这块我们还需要更多的时间来积累经验。
二、从服务的角度来看，服务包括：服务框架、服务管理、服务监控。
服务也是一个大范畴。服务化框架、页面登录服务器、GM接口，这些都属于服务相关的内容。兼顾目前的系统，这些内容都已经基本实现，这次只是做比较大的版本改进。
（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）