网易游戏的基础数据主要日志方式采集，这些日志通常是非结构化或半结构化数据，需要经过数据集成ETL才可以入库至实时或离线的数据仓库。此后，业务用户才可以方便地用SQL完成大部分数据计算，包括实时的FlinkSQL和离线的Hive或Spark。
网易游戏数据集成的数据流与大多数公司大同小异，主要有游戏客户端日志、游戏服务端日志和其他周边基础的日志，比如Nginxaccesslog、数据库日志等等。这些日志会被采集到统一的Kafka数据管道，然后经由ETL入库服务写入到Hive离线数据仓库或者Kafka实时数据仓库。
这是很常见的架构，但在我们在需求方面是有一些比较特殊的情况。
网易游戏流式ETL需求特点
首先，不同于互联网、金融等行业基本常用MySQL、Postgres等的关系型数据库，游戏行业常常使用MongoDB这类schema-free的文档型数据库。这给我们ETL服务带来的问题是并没有一个线上业务的准确的schema可以依赖，在实际数据处理中，多字段或少字段，甚至一个字段因为玩法迭代变更为完全不同的格式，这样的情况都是可能发生的。这样的数据异构问题给我们ETL的数据清洗带来了比较高的成本。
其次，也是由于数据库选型的原因，大部分业务的数据库模式都遵循了反范式设计，会刻意以复杂内嵌的字段来避免表间的join。这种情况给我们带来的一个好处是，在数据集成阶段我们不需要去实时地去join多个数据流，坏处则是数据结构可能会非常复杂，多层嵌套十分常见。
然后，由于近年来实时数仓的流行，我们也同样在逐步建设实时数据仓库，所以复用现有的ETL管道，提取转换一次，加载到实时离线两个数据仓库，成为一个很自然的发展方向。
最后，我们的日志类型多且变更频繁，比如一个玩法复杂的游戏，可能有1,个以上的日志类型，每两周可能就会有一次发版。在这样的背景下ETL出现异常数据是不可避免的。因此我们需要提供完善的异常处理，让业务可以及时得知数据异常和通过流程修复数据。
日志分类及特点
为了更好地针对不同业务使用模式优化，我们对不同日志类型的业务提供了不同的服务。我们的日志通常分为三个类型：运营日志、业务日志和程序日志。
运营日志记录的是玩家行为事件，比如登录帐号、领取礼包等。这类日志是最为重要日志，有固定的格式，也就是特定header+json的文本格式。数据的主要用途是做数据报表、数据分析还有游戏内的推荐，比如玩家的组队匹配推荐。
业务日志记录的是玩家行为以外的业务事件，这个就比较广泛，比如Nginxaccesslog、CDN下载日志等等，这些完全没有固定格式，可能是二进制也可能是文本。主要用途类似于运营日志，但更加丰富和定制化。
程序日志记录是程序的运行情况，也就是平时我们通过日志框架打的INFO、ERROR这类日志。程序日志主要用途是检索定位运行问题，通常是写入ES，但有时数量过大或者需要提取指标分析时，也会写入数据仓库。
网易游戏ETL服务剖析
针对这些日志分类，我们具体提供了三类ETL入库的服务。首先是运营日志专用的ETL，这会根据运营日志的模式进行定制化。然后是通用的面向文本日志的EntryXETL服务，它会服务于运营日志以外的所有日志。最后是EntryX无法支持的特殊ETL需求，比如有加密或者需要进行特殊转换的数据，这种情况下我们就会针对性地开发ad-hoc作业来处理。
