正文
2014 年到 2015 年，EA 的数字平台初步形成，各游戏工作室及业务部门的数据均通过统一的数据管道进入以 Hadoop 为基础的大数据平台，有了统一的数据仓库、服务和算法来支撑业务部门分析、推荐及报表等诉求，此时的数据延迟从两到三天缩短为几个小时。
具体来说，大数据部门当时做的第一件事情是在全公司建立统一的数据标准和数据规范，不管是哪个游戏公司和业务部门都用同一套语言来讲同一件事情。
我们建立了游戏分析的指标分类 Taxonomy。以玩家分析为例，其需要统一的数据有玩家的消费行为分析、社交行为分析以及游戏行为分析，比如平均游戏时长等指标。在运营分析层面，新增用户分析、留存分析和渠道分析也需要进行统一。
在数据标准统一之后，我们开始建立统一的数据规范，那么，数据规范是什么意思？
游戏分析数据从客户端以及服务器发送到我们的大数据平台，看似对数据进行统一管理进而消除了烟囱，但实际上由于不同部门的数据格式不尽相同，数据本身并未统一。
我们建立了统一的数据来源 Telemetry，将客户端和服务器端发送的数据定义为一个事件，也就是上图提到的 Telemetry Evnet，我们定义了事件的两类属性：
在完成如上两个步骤之后，就可以具体聊聊数据中台的建设。
首先
，数据中台的建设肯定以业务为驱动，我们做数据中台是希望以数字化的方式来驱动业务发展，比如支持游戏设计和开发、支撑游戏在线服务、支持游戏的市场部门、支持玩家获取游戏广告推送等，这是整个数据中台的发展方向，建设步骤如下图所示。
起初，我们的大数据平台采用了快速迭代的方式，
逐步将数据从各游戏平台汇聚到大数据平台，并提供基础的数据浏览、查看和下载功能。
因为数据中台的建设投资是巨大的，所以一定要快速见效，这又是一个需要长期投入的过程。如果短期内没有任何效果，参与其中的大数据部门、业务部门，甚至公司高层都会对后续建设缺乏信心。
因此我们选择了快速迭代的方式，短期就可以看到初步成效，但这个数据中台的功能非常初级，效果是将从各游戏部门拉数据变成了从统一的平台拉数据。
第二步
进入工具开发阶段
，我们开发了一些自助分析工具，业务部门可以自主进行数据分析，他们的日常工作由原来的 Excel 换到了统一的大数据平台上，这个阶段让业务部门能够把数据用起来。
第三步是能力复用
，以当时 EA 营收的主要贡献者 FIFA 为例，我们开发了标签系统可以让 FIFA 快速地从几千万玩家中迅速锁定地区、年龄、日均游戏时长符合要求的玩家，并针对性地进行游戏推广、推送打折券等优惠活动，以促进更多营收。
类似的，我们也建立了反欺诈模型，对于一些积攒游戏币再高价售卖的玩家会有查封账号等处罚，这些能力都是可以复用的。
第四步是形成闭环
，就是把从游戏中获取的数据形成服务再反馈给游戏，最简单的是将用户的游戏行为反馈给游戏动态推荐的同学，可以优化推荐结果。
总结下来：
-
首先，我们基本每个季度都会推出一些新功能，逐步让游戏可以更好运行下去，各业务部门能够在每个季度都用到一些新功能，并感受到数据中台的建设效果；
-
其次，需要开发一些自助工具，让业务部门能够自助分析数据；
-
然后，尽可能将为某个业务部门开发的功能抽象出来进行能力服用；
-
最后，形成数据闭环反馈给业务，对业务有所促进。
在建设过程中，我们也有一些原则
，这些基本是硅谷的科技公司建设数据中台都在采用的：
-
一是拥抱开源，不重复造轮子
，比如大数据平台基本都基于 Hadoop 生态；
-
二是基于公有云的混合架构
，游戏服务器部署在私有云，但数据中台部署在 AWS 的公有云上面，两者打通可以快速扩展数据中台的规模；
-
三是汇聚所有游戏的统一平台
，对 EA 这样一个每年要发布数十款游戏的公司而言，要做到这一项的难点并不全在于技术，而在于说服每个业务部门用统一的平台来支撑他们的业务；
-
四是要重点投资“王冠”组件
，数据中台最终能够产生的价值一定是数据收集起来后经过处理、分析和人工智能机器学习算法让他在业务中产生更大的价值，这是整个平台的重点。
接下来，我们重点介绍技术层面的内容。
如上是 EA 的数字化驱动架构，最上面是 EA 的数据来源，包括手机、游戏机客户端、PC 等渠道，这些数据通过我们定义的 Telemetry 数据格式发送到数据采集层，也就是数据捕获层 River。
数据采集分为两部分：Lightning 实时采集和 Tide 批处理采集，后面会详细介绍这两者的架构。
采集过后的数据进入 Ocean 分布式存储，分布式存储又分为两部分：基于 HDFS 的分布式文件存储系统和 AWS S3 的面向对象存储。这里其实牵扯到冷热存储的问题，因为 S3 比较便宜，所以存储比较老的数据；而HDFS 主要存储比较新的业务数据。
在数据处理这一层，与 Ocean 匹配的 ETL 工作流是 Shark，不停的吞吐大量数据，我们当时对 Onzie 进行了一些改造，将其作为工作流管理工具。
数据处理再往下就是数据仓库，存储了一些实时玩家数据，主要用在数据科学领域，比如推荐算法等。我们的实时数据仓库基于 Couchbase 建立，Pond 是自助数据探索工具，我们的一些生产数据会从 Ocean Push 到 Pond 这一端，Pond 也可以直接对 S3 读取面向对象存储数据进行查询，Pond 也是各业务部门运行作业的小集群，每天支撑了四五百个作业。
再往后就是 Pearl 数据仓库，这是一个传统的数据仓库，我们刚开始用的是 Tide，后来因为 Tide 开销太大，我们就转移到 AWS 的 Redshift 数据仓库，可以给传统的 PI 工具提供支撑，数据仓库这一层也为下面的数据服务提供支撑。
接下来为大家具体介绍 Tide 批处理采集架构，因为整个批处理文件存放了从游戏服务器送过来的大量数据，由于当时业界没有特别合适的分布式系统，所以我们自己构建了一个分布式采集系统，解决的问题就是每个任务能够自主到文件系统里面拉取想要处理的文件。
那么，如何保证不同任务之间互不冲突呢？
我们通过任务锁的方式来实现：
任务锁通过 Hazelcast 分布式内存启动，如果对某一个文件加锁，那么其他任务是拿不到的。
在文件流处理部分，我们将采集上来的文件归为不同的文件流合并处理，然后发布到 Ocean。
当时没有选择 Flume，是因为 Flume 当时刚出来，我们又有太多定制化需求，因为我们不仅要把文件进行合并，还有很多小文件放在 Hazelcast 上面，会严重影响性能。如果按照现在的技术，我们可能会采用一些更新的系统来做整个事情。
