作业仍是游戏？程序员：我挑选边玩游戏边作业！

“什么样的游戏才算电子竞技？

——我心里只要DOTA！

场主以为，电竞数据尽管生长多年，但在大环境下仍是处在初级阶段。

一方面体现在

“数据”结构

上仍有宽广的待开发空间，另一方面则是

运用场景

因而，当场主发现了这篇文章：

一文带你了解电竞游戏渠道的大数据玩法儿！

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

电竞数据的丰富性从受众视点来看，可分为赛事、战队和玩家数据；从游戏视点来看，维度可由英豪、战役、道具以及技能等组成；电竞数据的实时性包含赛前两支战队的前史交兵记载、赛中的实时比分、胜率猜测、赛后竞赛剖析和英豪比照等。

因而多维度的数据支撑，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（https://github.com/skadistats/clarity）与Manta（https://github.com/dotabuff/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）。

例如，在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，数据的查询不会呈现悉数锁死的状况。