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

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

　　分析数据入库。

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

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

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

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

　　数据分布式存储；

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

　　2.0版本的系统选择Google Cloud Platform来构建整个数据ETL系统，利用PubSub（类似Kafka）作为消息总线，任务被细化成多个Topic进行监听，由不同的Worker进行处理。

　　这样做，一方面减少了不同任务的耦合度，防止一个任务处理异常导致其他任务中断；另一方面，任务基于消息总线传递，不同的数据任务扩展性变得更好，性能不足时可快速横向扩展。

　　1、任务粒度细化

　　从任务粒度上看（如刚才的图3），数据处理分为基础数据处理与高阶数据处理两部分。

基础数据，即比赛的详情信息（KDA、伤害与补刀等数据）和录像分析数据（Roshan击杀数据、伤害类型与英雄分路热力图等数据），由Supervisor获取Steam数据触发，经过worker的清理后存入Google Bigtable；

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

联赛数据分析模块负责录像文件的拉取（Salt、Meta文件与Replay文件的获取）与比赛基本数据分析；

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

　　2、分布式存储

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

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

　　Bigtable与HBase的数据模型

　　在数据模型上，Bigtable与HBase通过RowKey、列簇列名及时间戳来定位一块数据（Cell，如图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。

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

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

　　Bigtable/HBase的数据读写

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

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

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

　　3、系统解耦

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

　　三、数据API层

　　1.0系统的数据API层为实现快速上线，在架构上未做太多的设计与优化，采用域名的方式实现负载均衡，并使用开源的DreamFactory搭建的ORM层，利用其RESTful的接口做数据访问。

　　该架构在开发和使用过程中遇到许多问题：

API层部署在国内阿里云上，数据访问需要跨洋；

　　针对上述问题，我们从两个方面重构了1.0数据API层，如图11：

　　1、链路的稳定性

　　全球链路上，我们使用CDN动态加速保证访问的稳定性。同时利用多云厂商CDN做备份容灾，做到秒级切换。

　　在调度能力和恢复能力上，我们搭建了自己的灰度系统，将不同维度的数据请求调度到不同的数据API，减少不同维度数据请求量对系统的影响；借助灰度系统，API服务更新的风险和异常时的影响面也被有效控制。依赖云平台可用区的特性，灰度系统也能方便地实现后端API服务跨可用区，做到物理架构上的容灾。

　　另外，为保证内部跨洋访问链路的稳定性，我们在阿里云的北美机房搭建数据代理层，利用海外专线来提升访问速度。

　　2、数据高可用性

　　接入分布式存储系统后，对外数据API层也根据扩展的数据维度进行拆分，由多个数据API对外提供服务，例如比赛数据和联赛赛程等数据访问量大，应该与英雄、个人及道具数据分开，防止比赛/赛事接口异常影响所有数据不可访问。

　　针对热点数据，内部Cache层会做定时写入缓存的操作，数据的更新也会触发Cache的重写，保障赛事期间的数据可用。

　　四、结语

　　本文介绍了FunData数据平台架构演进的过程，分析了旧系统在架构上的缺点，以及在新系统中通过什么技术和架构手段来解决。

　　FunData自4月10日上线以来，已有300多位技术开发者申请了API-KEY。目前也正着力于新数据点的快速迭代开发，如联赛统计数据、比赛实时数据等。

　　作者：肖丁

　　来源：