EA怎么建数据中台？ 数据标准和数据规范怎么定义

EA的数据中台建设

 

1、EA的游戏家族 

 

如下图，EA 的游戏分为几大类：

 

 

• 第一类是体育，比较有名的包括 FIFA 足球游戏、MADDEN 橄榄球游戏以及 NBA 游戏等；

• 第二类是射击，比如 BATTLEFRONT；

• 第三类是社交类的游戏，类似 SIMS4。

 

在 Moblie 方面，手机游戏比较有名的比如植物大战僵尸，很多人应该都玩过。还有 RealRacing，在某一年 iPhone 手机的发布会上将 RealRacing 作为展示 iPhone 手机强大硬件功能的游戏。

 

2、EA的游戏数据 

 

EA 的大数据部门成立于 2012 年，下图展示了游戏玩家玩游戏的过程中在数据层面发生的变化，从左边往右边看：

 

 

• 首先需要通过 Facebook 或者电子邮件获取玩家信息，通过数据来发现潜在玩家，包括 Push  Notification 通知玩家来邀请他进入游戏；

• 进入游戏以后，数据发挥重要价值的地方就是应用内的广告显示，包括 In-game Banner，会有一些个性化在里面；

• 最后就是玩家的体验，包括游戏体验、客服体验等，这是整个 EA 后台数据发挥作用的地方。

 

 

 

以 FIFA 为例，FIFA 在 2019 财年拥有 4 千 5 百万 Unqiue  player，这些玩家在 90 分钟内可完成将近 50 万场比赛，300 多万脚射门。

 

考虑到 EA 有将近一百个游戏，这些游戏总和加起来的数据量还是很大的。

 

3、EA的游戏平台建设 

 

 

1）早期的数据分析状态

 

面对这么庞大的数据量，EA 早期的数据分析是怎么做的呢？

 

 

EA 的特点是很多游戏工作室分布在全国各地，且大部分是收购而来。那么每个游戏工作室按业务部门就会在早期形成自己的烟囱式数据分析管道，每个游戏都有一套数据分析流水线，这就导致数据延迟较大。

 

如果希望得到整个公司的数据全貌需要花费两到三天的时间才能梳理出来，因为要到各个烟囱里面收集数据。这就导致在 2012 年的时候，整个 EA 的游戏体验不是特别好，游戏发布经常出现宕机，客服也很糟糕，并且当年的美国消费者杂志还将其评为最差劲的公司之一。

 

 

这促使 EA 的领导层决心改变现状，开始成立数字平台部门，我就是在那个时候加入 EA，从 0 到 1 打造整个数据平台。

 

2）数字平台初步形成

 

 

2014 年到 2015 年，EA 的数字平台初步形成，各游戏工作室及业务部门的数据均通过统一的数据管道进入以 Hadoop 为基础的大数据平台，有了统一的数据仓库、服务和算法来支撑业务部门分析、推荐及报表等诉求，此时的数据延迟从两到三天缩短为几个小时。

 

 

3）统一的数据标准（术语）

 

具体来说，大数据部门当时做的第一件事情是在全公司建立统一的数据标准和数据规范，不管是哪个游戏公司和业务部门都用同一套语言来讲同一件事情。

 

 

我们建立了游戏分析的指标分类 Taxonomy。以玩家分析为例，其需要统一的数据有玩家的消费行为分析、社交行为分析以及游戏行为分析，比如平均游戏时长等指标。在运营分析层面，新增用户分析、留存分析和渠道分析也需要进行统一。

 

4）统一的数据规范

 

在数据标准统一之后，我们开始建立统一的数据规范，那么，数据规范是什么意思？

 

游戏分析数据从客户端以及服务器发送到我们的大数据平台，看似对数据进行统一管理进而消除了烟囱，但实际上由于不同部门的数据格式不尽相同，数据本身并未统一。

 

 

我们建立了统一的数据来源 Telemetry，将客户端和服务器端发送的数据定义为一个事件，也就是上图提到的 Telemetry  Evnet，我们定义了事件的两类属性：

 

• 一类是通用属性，所有平台游戏都要上报数据，包括玩家 ID、游戏运行设备、游戏名称、事件编号、事件时间等，在定义了数据规范后，所有数据就可以很方便的统计，并计算一些公司需要的共性指标，比如日活、月活等；

• 另一类是特殊属性，根据不同的业务也会有一些特殊属性，整个过程只需要将 Telemetry SDK 植入游戏客户端即可完成。

 

5）“数据中台”建设

 

 

在完成如上两个步骤之后，就可以具体聊聊数据中台的建设。

 

首先，数据中台的建设肯定以业务为驱动，我们做数据中台是希望以数字化的方式来驱动业务发展，比如支持游戏设计和开发、支撑游戏在线服务、支持游戏的市场部门、支持玩家获取游戏广告推送等，这是整个数据中台的发展方向，建设步骤如下图所示。

 

 

起初，我们的大数据平台采用了快速迭代的方式，逐步将数据从各游戏平台汇聚到大数据平台，并提供基础的数据浏览、查看和下载功能。

 

因为数据中台的建设投资是巨大的，所以一定要快速见效，这又是一个需要长期投入的过程。如果短期内没有任何效果，参与其中的大数据部门、业务部门，甚至公司高层都会对后续建设缺乏信心。

 

因此我们选择了快速迭代的方式，短期就可以看到初步成效，但这个数据中台的功能非常初级，效果是将从各游戏部门拉数据变成了从统一的平台拉数据。

 

第二步进入工具开发阶段，我们开发了一些自助分析工具，业务部门可以自主进行数据分析，他们的日常工作由原来的 Excel 换到了统一的大数据平台上，这个阶段让业务部门能够把数据用起来。

 

第三步是能力复用，以当时 EA 营收的主要贡献者 FIFA 为例，我们开发了标签系统可以让 FIFA 快速地从几千万玩家中迅速锁定地区、年龄、日均游戏时长符合要求的玩家，并针对性地进行游戏推广、推送打折券等优惠活动，以促进更多营收。

 

类似的，我们也建立了反欺诈模型，对于一些积攒游戏币再高价售卖的玩家会有查封账号等处罚，这些能力都是可以复用的。

 

第四步是形成闭环，就是把从游戏中获取的数据形成服务再反馈给游戏，最简单的是将用户的游戏行为反馈给游戏动态推荐的同学，可以优化推荐结果。

 

总结下来：

 

• 首先，我们基本每个季度都会推出一些新功能，逐步让游戏可以更好运行下去，各业务部门能够在每个季度都用到一些新功能，并感受到数据中台的建设效果；

• 其次，需要开发一些自助工具，让业务部门能够自助分析数据；

• 然后，尽可能将为某个业务部门开发的功能抽象出来进行能力服用；

• 最后，形成数据闭环反馈给业务，对业务有所促进。

 

在建设过程中，我们也有一些原则，这些基本是硅谷的科技公司建设数据中台都在采用的：

 

• 一是拥抱开源，不重复造轮子，比如大数据平台基本都基于 Hadoop 生态；

• 二是基于公有云的混合架构，游戏服务器部署在私有云，但数据中台部署在 AWS 的公有云上面，两者打通可以快速扩展数据中台的规模；

• 三是汇聚所有游戏的统一平台，对 EA 这样一个每年要发布数十款游戏的公司而言，要做到这一项的难点并不全在于技术，而在于说服每个业务部门用统一的平台来支撑他们的业务；

• 四是要重点投资“王冠”组件，数据中台最终能够产生的价值一定是数据收集起来后经过处理、分析和人工智能机器学习算法让他在业务中产生更大的价值，这是整个平台的重点。

 

接下来，我们重点介绍技术层面的内容。

 

 ① 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批处理采集架构

 

接下来为大家具体介绍 Tide 批处理采集架构，因为整个批处理文件存放了从游戏服务器送过来的大量数据，由于当时业界没有特别合适的分布式系统，所以我们自己构建了一个分布式采集系统，解决的问题就是每个任务能够自主到文件系统里面拉取想要处理的文件。

 

 

那么，如何保证不同任务之间互不冲突呢？我们通过任务锁的方式来实现：

 

任务锁通过 Hazelcast 分布式内存启动，如果对某一个文件加锁，那么其他任务是拿不到的。在文件流处理部分，我们将采集上来的文件归为不同的文件流合并处理，然后发布到 Ocean。

 

当时没有选择 Flume，是因为 Flume 当时刚出来，我们又有太多定制化需求，因为我们不仅要把文件进行合并，还有很多小文件放在 Hazelcast 上面，会严重影响性能。如果按照现在的技术，我们可能会采用一些更新的系统来做整个事情。

 

③ Lightning实时采集架构

 

 

在实时采集服务部分，我们有一个整体检查采集节点是否工作的设置，我们叫 Liveness-Check。

 

如果有一个节点不工作，它会通知负载均衡拿掉，如果生成一个新的采集服务，它会把这个节点加到负载均衡里面，也就是动态调整负载均衡，保证服务的高可用。

 

在这套架构中，我们使用了 Flume 服务，因为文件的方式比较直接。Flume 作业一份发送到 Oceam 里面做备份，另外一份发送到 Kafka 集群，这里面更多的考虑是容错，就是在采集服务节点挂掉以后，如何保证数据不丢失：一方面是通过 Ocean 进行备份，另一方面是在这个挂掉之后把它切断，使数据不被破坏。

 

④ 游戏异常检测

 

至于游戏的异常检测，我们主要完成了自动配置游戏指标检测。

 

 

EA 的游戏有上百个，每年发布新游戏或版本的同时还需要维护历史版本，游戏指标体系里有接近上万个指标，所以异常检测必须智能化，而不是每一个指标都手工配置。

 

此外，我们通过拉取历史数据进行机器学习建模来分析异常情况。

 

⑤ 游戏推荐系统

 

接下来重点介绍游戏的推荐系统，也就是数据中台的第四个部分，最终形成数据闭环的部分。

 

 

EA 的游戏推荐系统作为典型的数据能力首先请求从游戏客户端和服务器端向推荐系统发出，但在之前有一个建模的过程，这个过程是客户端和服务器的数据都会发送到数据仓库，数据仓库将数据发送到模型及服务板块。

 

当然这个模块也会存储一些代码，因为 EA 不仅能够支撑各种系统，比如推荐系统，也可以支撑异常检测和反欺诈等，这其中的模型和代码都可以复用到其他部门。

 

那么在整个推荐系统里面，推荐系统会拉取数据仓库最近 24 小时的数据，然后结合向模型及服务发出请求，模型及服务根据这些参数进行计算来匹配并将结果返回到推荐系统，推荐系统又会把结果返回给客户端以及服务器端，形成整个推荐机制。

 

整个后台还有一个比较重要的部分就是 AB 测试，推荐系统可以根据推荐请求的不同性质（生产环境还是测试环境）发送到不同的服务器上，后续会跟后面的一系列推荐请求数据进行捆绑来评价整个结果是不是符合预期。

 

 

EA 推荐系统的逻辑大致如此，整个系统上线后对业务的推动作用还是很明显的，比如广告点击率提升了 80%，游戏玩家的参与度提升了 10% 等。