越大的游戏企业,内耗越严重?

科技   2024-05-30 11:00   上海  

《技术HardCore》栏目由数数科技的技术老炮(儿)们联合「开发」。

在这里,实践与真知齐飞,技术与业务共舞~你可以通过用代码思维敲出来的硬核文字,轻松 get:

· 千亿级多源异构数据怎样做到快速即席查询

· 怎样用一个平台服务实时、即席、离线数据应用?

……等诸多专业难题。

让我们一起来畅想你的游戏数据平台明(儿)个要做点(儿)啥~


温馨提示:

本篇阅读时长:7 mins

适宜阅读人群:游戏公司 CTO、数据中台负责人、数据研发工程师

硬核指数:


越大越成熟的游戏企业,往往业务的复杂程度越高。


而在企业经营、发展的过程中,为了解决复杂的业务问题,内部架构也在不断调整、迭代,使得内部架构的复杂度也在呈几何级增长。


因此,当游戏企业发展到一定阶段,底层相关的内部建设,如数据中台,往往承载了太多的历史包袱,运转效率开始变低,而一些看不见的成本开销,却水涨船高。


“看不见”的成本


数数所服务的一家老牌游戏公司,早在几年前就搭建了一套比较成熟的基于 Lambda 架构的离线+实时数仓平台,但是随着业务的演进,在处理业务侧埋点的过程中逐渐有点「力不从心」。


  • 数据治理成本


该企业的业务方很多,其数据的流转还涉及到合作的 CP 方,导致每一次业务端的埋点新增和调整,都带来了很高的沟通成本。业务方如果忘记同步埋点调整,就会导致入库的数据错误,造成数据清洗和重导的成本极高


  • 内部资源消耗


部分业务对于数据的时效性要求很高,为了满足时效性的要求,该企业的数据平台在离线数据平台之上,单独拉出来了一条实时数据处理流,但是却需要花费大量的精力去对齐离线统计的数据结果和实时指标结果,而如果无法对齐,数据结果的准确性则会遭到质疑和挑战,使得数据平台的价值无法被衡量甚至体现。


而无论是数据本身的治理成本,还是内部资源的过度消耗,这种不健康的游戏企业数据平台业务状态,虽不如一些显性开支,会在企业经营层面直接产生“痛感”,却一如慢性毒药,在慢慢腐蚀着游戏企业内部的数据基建,长此以往下去,终将在某一时间点爆发,直接危及游戏企业经营



如何“未雨绸缪”?


数据处理引擎作为数据平台中最为核心的组件之一,也是保障数据质量的核心环节。本身其架构演进也经历了 Lambda 架构→Kappa 架构以及流批一体的计算框架。


想要从根本上解决这些隐患,我们可以从数据处理引擎如何提升数据质量的设计思路入手。


 松耦合架构(loosely coupled architecture)


游戏数据业务变化很快,数据平台的架构需要具备足够的灵活性和扩展性,以适应不断变化的业务调整,同时在现代数据平台的设计理念上,松耦合也已经成为标准架构思路。每一个数仓分层,每一个组件都需要清晰地定义好其负责的核心功能,并通过解耦、标准化的 API 向外暴露能力。


 Exactly-Once 特性


从数据采集层上报上来的数据,由于网络抖动等无法避免的原因,必然会导致数据网关写入 Fast Storage 的数据存在重复,因此数据处理引擎有义务去处理掉这部分重复的数据,保证数据的准确性。


 Schema-Free 特性


游戏业务变化很快,版本迭代、活动发布等都会对数据埋点进行新增调整,这会导致流入到 Fast Storage 中的数据结构是经常性变化的。而在传统的数仓设计中,一般都是先定义好表的 schema,然后数据处理引擎将 Fast Storage 中的数据按照定义好的 schema 写入到表中。


这种方式会导致每次埋点逻辑的调整,都需要去重新调整表 schema,而这个动作一般都不是自动化的,需要人工介入,成本很高;同时如果一旦忘记处理,就会导致数据入库异常或信息丢失,无法满足业务需求。


因此数据处理引擎的设计需要能够自适应这些变化,否则数据埋点的变化,将会带来大量的数据质量问题。


而想要解决这一问题,我们则需要尽可能地将数据治理动作「左移」,在离数据源更接近的地方解决数据质量问题,数据处理引擎在识别到数据质量问题后,可以由业务驱动在采集层提升整体的数据埋点质量。


数数的游戏大数据引擎 TE 系统严格秉持了这一数据治理的思路,可以帮助游戏企业尽早识别发现数据质量问题出现的阶段,并通过产品的手段进行数据治理「左移」。同时,TE 系统集成了数据验收的功能,结合数据质量预警,可以帮助游戏企业清晰、即时地发现数据质量问题。


 横向扩展性


数据处理引擎需要流式的处理海量明细数据,还会涉及到数据逻辑解析、去重、ID-Mapping、meta-sync 等各种复杂操作,对于算力和内存消耗很大,在上游数据上报吞吐量突增的情况下,很有可能会导致数据来不及消费,积压在 Fast Storage 中,引起数据 delay 等质量问题。因此数据处理引擎相比于网关,会更依赖原生化的动态伸缩能力,来实现数据处理能力的弹性扩展。


数数服务了上千家游戏企业,而每一家游戏企业之间的数据量都差异非常大,单日流入的数据量从百万条量级到几百亿条,同时我们也遇到过游戏开服上线当日数据量暴增的情况。


为了应对不同公司的数据体量差异以及可能的流量突增,TE 系统严格按照横向扩展的特性设计了数据处理引擎的架构,能够自适应地满足不同的数据量下的数据处理能力,保证数据处理的时效性


对于自建数据平台的游戏企业来说,可以对自身的游戏业务有更充分的业务预测,优先做到数据处理引擎的「横向扩展」特性,如下图所示通过不断增加 DataProcessor 来扩展数据处理性能,再基于实际情况来构建「自动」弹性伸缩能力。



前文所提到的老牌游戏公司在接入数数之后,摈弃了原来的 Lambda 架构,采用了数数提供的流式处理框架,将离线和实时处理流统一了起来,实时处理、实时计算所有数据,再也不存在离线和实时对数的问题。

同时基于数数流式引擎 Schema-Free 的框架,游戏企业数据平台中表的 meta 会自动随着业务方上报的埋点进行动态调整,数据平台只需提供好埋点规范给到业务方即可,无需再与各个业务方进行大量的沟通,极大地提升了数据处理的效率和质量,从数据平台建设的角度防微杜渐,避免那些“看不见”的成本支出,保障游戏企业长线健康发展。





END

数数科技
数数科技,全球游戏数据基础设施开创者。目前已服务1200+家游戏企业,旗下产品已接入6000+款游戏。
 最新文章