割工作谁做？研发还是运维。日志切割按什么规则？大小还是日期？
2、使用什么工具进行日志收集？scribe 还是flume 还是 sls？
3、数据的准确性谁来保证？日志内容不对、切割不对、传输丢失、入hadoop过滤
4、数据ETL过程监控，如果出现数据丢失怎么办？
5、数据采集怎么样尽可能的保证并发的采集，缩短时间。
6、数据的出现丢失或错误，整体数据回滚。谁来保证？怎么保证？
7、大量数据下，核对数据丢失情况怎么样核对？用什么方法？
那大掌门又是如何解决这些问题的呢：
1、 将数据日志进行切割（按照业务打包日志）并合理命名。比如A登陆日志，B充值日志，C消费日志。分门别类进行打包后，对数据每5分钟切割1次，并生成md5包。
2、 按照划分IDC Region。原来从本机向外传输数据会占用大量带宽，对于本身CPU的消耗大的话都会影响游戏的运行。现在按照IDC region做出划分，每个区域中会有1-3个中心存储服务器。将切割下来的数据放到中心存储上，划分成Aip1、Aip2、Aip3等md5压缩包，此处无需做合并（原因见3）。
3、 建立下载任务。建立好任务列表后，对每5分钟的压缩包进行下载。考虑到如果上面的步骤做了合并的话就可能会产生在传输的时候丢数据却无法确定的情况，因此2步骤无需对数据进行合并。
4、将下载后的任务加到Hive数据仓库里。将当天的数据放到MySQL中，之前的数据放到Hive里。当运营提出数据需求时便可以到Hive中下载数据。即使数据出现错误，按照上面建立的每5分钟的任务列表也可以重新以规定时间点将数据压缩包重新拉回来。并且该流程可以按照正向、反向双向进行。
采用5分钟压缩包的另外一个原因在于每台服务器每天产生业务日志大概有5-6G的数据，分到5分钟后，切割完每个文件就是20M－30M，压缩后只占用很少的空间。这样就解决了占用大量带宽的问题。
5、数据传输后需将数据放到数据仓库（DW）中，数据下载完毕后会根据文件进行存储，当天的数据按照5分钟1个压缩包进入MySQL，MySQL则进入当天的查询。在数据仓库中，数据包按游戏及平台进行分类，这种格局的安排为了在并发时更好的运行。由于游戏与游戏之间是隔离的，因此按照这种模式是为了保证数据进行顺利并发。
