电竞大数据平台 FunData 的系统架构演进

2018-06-23 来源：

电竞大数据时代，数据对比赛的观赏性和专业性都起到了至关重要的作用。同样的，这也对电竞数据的丰富性与实时性提出了越来越高的要求。

电竞数据的丰富性从受众角度来看，可分为赛事、战队和玩家数据;从游戏角度来看，维度可由英雄、战斗、道具以及技能等组成;电竞数据的实时性包括赛前两支战队的历史交战记录、赛中的实时比分、胜率预测、赛后比赛分析和英雄对比等。

因此多维度的数据支持，TB到PB级别的海量数据存储与实时分析都对底层系统的架构设计有着更高的要求，亦带来了更严峻的挑战。

本文将介绍电竞数据平台FunData架构演进中的设计思路及相关技术，包括大数据流处理方案、结构化存储转非结构化存储方案和数据API服务设计等。在其v1.0 beta版本中，FunData为顶级MOBA类游戏DOTA2(由Valve公司出品)提供了相关的数据接口。

1.0架构

项目发展初期，依照MVP理论(最小化可行产品)，我们迅速推出FunData的第一版系统(架构图如图1)。系统主要有两个模块：Master与Slave。

图1 1.0ETL架构图

Master模块功能如下：

• 定时调用Steam接口获取比赛ID与基础信息;

• 通过In-Memory的消息队列分发比赛分析任务到Slave节点;

• 记录比赛分析进度，并探测各Slave节点状态。

Slave模块功能如下：

• 监听队列消息并获取任务，任务主要为录像分析，录像分析参考GitHub项目Clarity与Manta;

• 分析数据入库。

系统上线初期运行相对稳定，各维度的数据都可快速拉取。然而随着数据量的增多，数据与系统的可维护性问题却日益突出：

• 新增数据字段需要重新构建DB索引，数据表行数过亿构建时间太长且造成长时间锁表;

• 系统耦合度高，不易于维护，Master节点的更新重启后，Slave无重连机制需要全部重启;同时In-Memory消息队列有丢消息的风险;

• 系统可扩展性低，Slave节点扩容时需要频繁的制作虚拟机镜像，配置无统一管理，维护成本高;

• DB为主从模式且存储空间有限，导致数据API层需要定制逻辑来分库读取数据做聚合分析;

• 节点粒度大，Slave可能承载的多个分析任务，故障时影响面大。

在开始2.0架构设计与改造前，我们尝试使用冷存储方法，通过迁移数据的方式来减轻系统压力(架构设计如图2)。由于数据表数据量太大，并发多个数据迁移任务需要大量时间，清理数据的过程同样会触发重新构建索引，方案的上线并没有根本性地解决问题。

图2 冷存储方案

2.0架构

吸取1.0系统的经验，在2.0架构设计(架构图如图3)中，我们从维护性、扩展性和稳定性三个方面来考虑新数据系统架构应该具备的基本特性：

• 数据处理任务粒度细化，且支持高并发处理(全球一天DOTA2比赛的场次在120万场，录像分析相对耗时，串行处理会导致任务堆积严重);

• 数据分布式存储;

• 系统解耦，各节点可优雅重启与更新。

图3 2.0ETL总架构图

2.0系统选择Google Cloud Platform来构建整个数据ETL系统，利用PubSub(类似Kafka)作为消息总线，任务被细化成多个Topic进行监听，由不同的Worker进行处理。这样一方面减少了不同任务的耦合度，防止一个任务处理异常导致其他任务中断;另一方面，任务基于消息总线传递，不同的数据任务扩展性变得更好，性能不足时可快速横向扩展。

任务粒度细化

从任务粒度上看(如图3)，数据处理分为基础数据处理与高阶数据处理两部分。基础数据，即比赛的详情信息(KDA、伤害与补刀等数据)和录像分析数据(Roshan击杀数据、伤害类型与英雄分路热力图等数据)由Supervisor获取Steam数据触发，经过worker的清理后存入Google Bigtable;高阶数据，即多维度的统计数据(如英雄、道具和团战等数据)，在录像分析后触发，并通过GCP的Dataflow和自建的分析节点(worker)聚合，最终存入MongoDB与Google Bigtable。

从Leauge-ETL的细化架构看(如图4)，原有的单个Slave节点被拆分成4个子模块，分别是联赛数据分析模块、联赛录像分析模块、分析/挖掘数据DB代理模块和联赛分析监控模块。

• 联赛数据分析模块负责录像文件的拉取(Salt、Meta文件与Replay文件的获取)与比赛基本数据分析;

• 联赛录像分析模块负责比赛录像解析并将分析后数据推送至PubSub;

• 分析/挖掘数据DB代理负责接收录像分析数据并批量写入Bigtable;

• 联赛分析监控模块负责监控各任务进度情况并实时告警。

同时所有的模块选择Golang重构，利用其“天生”的并发能力，提高整个系统数据挖掘和数据处理的性能。

图4 League-ETL架构

分布式存储

如上文提到，1.0架构中我们使用MySQL存储大量比赛数据及录像分析数据。MySQL在大数据高并发的场景下，整体应用的开发变得越来越复杂，如无法支持schema经常变化，架构设计上需要合理地考虑分库分表的时机，子库的数据到一定量级时面临的扩展性问题。

参考Google的Bigtable，作为一种分布式的、可伸缩的大数据存储系统，Bigtable与HBase能很好的支持数据随机与实时读写访问，更适合FunData数据系统的数据量级和复杂度。

图5 Hadoop生态

在数据模型上，Bigtable与HBase通过RowKey、列簇列名及时间戳来定位一块数据(Cell，如图6)。

图6 数据索引

例如，在FunData数据系统中，比赛数据的RowKey以hash_key+match_id的方式构建，因为DOTA2的match_id是顺序增大的(数值自增量不唯一)，每个match_id前加入一致性哈希算法算出的hash_key，可以防止在分布式存储中出现单机热点的问题，提升整个存储系统的数据负载均衡能力，做到更好的分片(Sharding)，保障后续DataNode的扩展性。

如图7，我们在hash环上先预设多个key值作为RowKey的前缀，当获取到match_id时，通过一致性哈希算法得到match_id对应在hash环节点的key值，最后通过key值与match_id拼接构建RowKey。

图7 一致性hash构建RowKey

时间戳的使用方便我们在聚合数据时对同一个RowKey和Column的数据重复写入，HBase/Bigtable内部有自定的GC策略，对于过期的时间戳数据会做清理，读取时取最新时间节点的数据即可。

这里大家可能会有个疑问，Bigtable与HBase只能做一级索引，RowKey加上hash_key之后，是无法使用row_range的方式批量读或者根据时间为维度进行批量查询的。在使用Bigtable与HBase的过程中，二级索引需要业务上自定义。在实际场景里，我们的worker在处理每个比赛数据时，同时会对时间戳-RowKey构建一次索引并存入MySQL，当需要基于时间批量查询时，先查询索引表拉取RowKey的列表，再获取对应的数据列表。

在数据读写上，Bigtable/HBase与MySQL也有很大的不同。一般MySQL使用查询缓存，Schema更新时缓存会失效，另外查询缓存是依赖全局锁保护，缓存大量数据时，如果查询缓存失效，会导致表锁死。

如图8，以HBase为例，读取数据时，client先通过zookeeper定位到RowKey所在的RegionServer，读取请求达到RegionServer后，由RegionServer来组织Scan的操作并最终归并查询结果返回数据。因为一次查询操作可能包括多个RegionServer和多个Region，数据的查找是并发执行的且HBase的LRUBlockCache，数据的查询不会出现全部锁死的情况。

图8 HBase架构

基于新的存储架构，我们的数据维度从单局比赛扩展到了玩家、英雄、联赛等，如图9。

图9 数据维度

系统解耦

上文我们提到1.0架构中使用In-Memory的消息队列做数据传递，由于内存中队列数据没有持久化存储并与Master模块强耦合，Master节点更新或者异常Panic后会导致数据丢失，且恢复时间冗长。因此，在2.0架构中采用了第三方的消息队列作为消息总线，保障系统“上下游”节点解耦，可多次迭代更新，历史消息变得可追踪，基于云平台消息堆积也变得可视化(如图10)。