数据|EA、Twitter、Airbnb、Uber，怎么建数据中台( 三 ) airbnb|中台|数据|twitter|硅谷|u

这里其实牵扯到冷热存储的问题，因为 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 测试，推荐系统可以根据推荐请求的不同性质（生产环境还是测试环境）发送到不同的服务器上，后续会跟后面的一系列推荐请求数据进行捆绑来评价整个结果是不是符合预期。