背景：
某某游戏公司的业务逻辑图，其实可以从中发现这基本上跟大多数的游戏公司一样，通过阿里云作数据分析，其他云作数据接入。原因在于阿里云的数据产品比较贴合使用习惯、全面丰富的良好产品体验。
但是，接入的通路问题，采集问题，甚至集成问题，都是困扰一大部分用户的。这篇文章，就是希望打开这方面的脑洞。细化到网络层面，组件层面，使用方式等，做一次分析。
网络层：
一般游戏发行商，会接入到各个地区。因为不同类型的游戏都有主打开拓市场的区域。那这个时候不同游商在某些区域有数据中心，这个就显得很重要。
但是某一家云商不可能在全世界任何一个地方都有数据中心，所以当某家云不在某某区域有数据中心，他的网络接入能力就显得尤为重要。这个时候，可以分别借力阿里云的网络能力，比如没有点的地方采用全球加速，有点之间的连接就采用云企业网（cen）。
如果用户还是不满意网络覆盖情况，可以退而求其次，只是数据分析类的场景，才采用网络接入。因为一般数据分析类场景是准实时或者离线批量，对延时的苛刻度没那么高。只要接上一次，这条通路可以长期使用，以备下次搬迁作准备。
数据组件集成：
服务端的数据，通过Kafka作为与外界云的收集载体，内部自建CDH,把数据分流为离线数据和实时数据。离线部分，以flume作离线数据入库，然后经过拦截数据规则，通过Phoneix agent实时入库到云HBASE中。实时部分，采用Sparksteaming或Flink接入云hbase。
移动端的数据，通过sls的sdk接入到app中，收集玩家数据。sls还承担了数据可视化的数据源。在报表类的展示和大屏类的展示，也会抽取云hbase 的部分数据。
大数据方案主要参考阿里巴巴大数据方案并结合自身特点量身定做，像阿里巴巴大数据体系架构一样也分四层，只是内容有所简化和差异。其实多数大数据架构方案都略同，只是在细节上有所差异。
- 数据采集层：数据来源有两种——客户端埋点日志和服务端请求处理日志。最终这些日志都是以日志聚合的形式，经过消息队列中间件缓存，最终汇总到数据湖。
- 数据计算层：市面上有多种离线和实时计算引擎，从技术生态成熟度来说Spark相对完善，我们选择了Spark生态技术栈。数据加工链路与阿里巴巴数据计算层类似分为操作数据层(Operational Data Store, ODS)、明细数据层(Data Warehouse Detail, DWD)、汇总数据层(Data Warehouse Summary, DWS)和应用数据层(Application Data Store, ADS)，元数据管理和数据质量处理还有待完善。
- 数据服务层：数据服务层对底层数据存储透明，面向数据应用层开放海量数据，并对外提供统一的数据服务平台，通过接口提供数据查询服务和实时数据推送服务。
- 数据应用层：以应用的形式提供数据可视化，支持各种应用场景的数据分析，为运营、发行、策划提供宏观决策支撑。
望这篇文章对以阿里云数据产品的切入，对读者有所帮助。