本章主要说下搭建网络游戏企业数据平台所存在的技术难点。总的来说，网络游戏的数据相较于银行/电信的数据，主要难点在于采集困难，变数大的问题。
数据采集难点
l 数据分散
网络游戏存在一个特定，存在大量的区组，各个区组可能部署在不同的机房；同时，现代网游都是分布式架构，即使同一个区组，也许数据也分布在不同的服务器中；更有一些特殊的内测服之类，也许架构和其他区组还不太一样。这种情况下，需要针对不同的数据采用不同的策略进行数据采集，采集系统及其复杂。
l 数据源模式复杂
由于网游开发不可能按照数据采集需求进行，所以采集程序必须适应游戏服务器数据访问模式。有些数据也许在数据库中，有些数据采用文本存放，有些数据可能就在内存中放着；同时，在访问游戏服务器过程中，有些可以直连，有些需要用代理，有些又是SSH+SOCKET5模式。一个好的采集程序能够通过简单的配置满足这些不同的数据源模式。
l 网络受限
网络游戏服务器都是7×24小时运转，保证游戏顺畅是游戏运营公司第一要务。但是在数据采集过程中，必然需要对游戏服务器带宽资源产生一些影响，没有任何一家公司允许牺牲玩家体验来满足数据采集的需求。同时，由于游戏数据量一般都十分巨大，在到达采集服务器时，也对采集服务器的带宽有很大的压力。对于那些采集服务器架在电信机房，可是游戏数据源在网通机房的情况更是存在一些麻烦。因此，如何想尽办法降低网络传递消耗也是一个重点问题。
l 资源受限
和上面谈到一样，在采集数据过程中，必然会对游戏服务器的CPU/IO等资源产生一些影响，为了不影响游戏玩家体验，必须要把采集过程中所产生的资源消耗降到最低。对于某些游戏服务器，数据库设计过程中不尽合理，必须要想办法避免表死锁问题。因此，必须合理规划数据采集时段/采集模式/采集语句，避免影响游戏服务器正常运转。
l 数据稳定性差
在处理数据的过程中，多次碰到这样的情景：游戏服务器故障，数据回档，今天的数据丢了；网络传输过程中，莫名其妙的原因采集回来的数据和游戏服务器不一致。因此，对某些数据采集策略必须是实时采集，某些可以是T+1；同时，对任意采集回的数据必须进行多重校验确保数据准确。
数据存储难点
l 数据量大
网络游戏数据由数十万玩家甚至数百万玩家产生，且不间断的产出数据。因此网络游戏数据平台每日所面对都是数十或者数百G的数据量。由于数据中心的特性，数据需要进行长期的存储。假如每日处理50G的数据，每个月就需要存储1.5TB；每年就是18TB数据，这对于任何一个数据处理平台都不是一件简单的事情。
l 采集过程复杂
采集程序所返回的数据是多种多样，一般情况下会按照不同的区组分别存储。数据存储时需要考虑不同的数据模式，并且能够很好对各种数据模式的后续归一化处理提供支持。
l 需求复杂
在上一章，提到数据平台存在查询/统计/分析/挖掘/审计/预警六大职能，每个职能对数据需求是不一致的。例如查询可能需要精确定位到明细数据，但是对查询效率要求不高；统计也许只需要数据某些范围的合计数，但是作为报表的数据源，查询效率必须很高。一个好的数据平台能够采取合理的存储层次满足各式各样的数据需求。
数据处理难点
l 数据量大
如上所述，网游数据处理面向都是TB级的数据，如果保证数据处理效率是重点需要考虑的问题。一般的程序也许面对的是CPU/内存的压力；而在大数据处理过程中，面临最大压力在IO/网络。如何在有限的硬件资源下，将硬件资源利用率最大化；满足海量数据处理需求是数据平台在设计过程中必须面对的问题。当然，如果公司肯投入当我没说，有钱总归是好办事的。
l 存在大量复杂计算
网络游戏一些数据指标都是极其难算的，比如月流失率，要算上个月登录的，这个月没登录的帐号数。在sql上，简单的not in就可以了；但是当你面对的是数十万帐号，几千万或者上亿的登录记录，not in跑起来估计很难，至少我在我们服务器上直接跑没跑成功过。还有某些更变态的指标，需要在几十亿的数据中逐条比对。因此在数据平台设计过程中，根据指标特定，预留一定的空间满足这些复杂计算的需求。
总而言之，搭建一个能够处理网游数据的数据平台在技术上不是一件很容易的事情，需要在设计之初预留一定的处理冗余，并且在实施过程中不断的进行调整，满
<!--EndFragment-->