作者：康伟豪 欢乐互娱数据中台负责人
欢乐互娱作为一家全球化的游戏研发与发行公司，业务涵盖 MMORPG 和 ACT 等多种品类，其产品在东南亚、日韩、美洲以及港澳台地区均有发行
随着业务的不断扩展，欢乐互娱面临着日益增长的数据体量和复杂度挑战。公司的数据量从最初的每日百万级增长到每日百亿级，最高峰值甚至达到每日 150 亿条，这使得数据分析的需求和复杂度显著提升，对底层数据平台提出了更高的要求。
四大核心场景驱动，日增 150 亿数据特点
欢乐互娱的业务场景主要围绕 Joydata-BI 报表平台、广告投放、游戏用户玩家行为分析以及 CRM（客户关系管理）四大核心模块。这些模块对数据的实时性、查询效率和稳定性有着极高的要求：
Joydata-BI 报表分析：BI 平台承载着公司内部多个部门的报表需求，包括财务、游戏策划和运营等。报表数量庞大，且业务人员对响应时延要求较高。核心 KPI 如日活、新增、留存、流水等指标的查询响应时间控制在 P99 的 5 秒内。
广告投放分析：涵盖国内外多个投放平台，包括巨量引擎、腾讯广告、小红书以及海外第三方归因平台。每日广告消耗高达数百万，需要近实时的效果分析来及时调整投放策略，避免无效投入。
游戏用户行为分析：作为 MMO 游戏，道具和货币流水占据了整体数据量的 70%，系统需支持用户标签、用户分群的即席查询和深度业务分析。
客服系统（用户维护）：针对付费充值玩家进行问题查询与维护响应，需要根据玩家 ID 或关键字进行明细查询，特别是付费道具流水的实时查询，要求 2 分钟内完成数据入库，确保客服人员能及时响应玩家问题。
数据架构演进：从 Hadoop 到 StarRocks 的飞跃
欢乐互娱的数据架构经历了三个关键阶段：
第一阶段：传统 Hadoop 生态，采用 Hive 进行数据处理，通过离线数仓文件回传的形式解析到 Hive。
第二阶段：接入第三方数据分析产品，基于 Hadoop + Trino 的架构进行数据处理。随着数据量从初期 10 亿（单地区）增长至全球日均 150 亿。原有架构的并行扩展能力和性能逐渐无法满足需求：
- 查询性能严重下降：随着数据量增长，查询时间动辄几十分钟甚至更长，严重影响业务决策效率。遇到年报生成时，系统需要处理一整年的数据，查询时间可能长达数小时。
- 实时性要求难以满足：广告投放需要近实时的数据反馈，传统离线数仓架构无法支撑此量级下 5-10 分钟级的数据更新需求。
- 资源争抢问题突出：不同业务场景共享计算资源，大查询会影响其他业务的正常运行，特别是客服系统的实时查询经常被阻塞。
第三阶段：经过调研对比 Doris、ClickHouse 等方案后，团队在 2020 年从 StarRocks 1.19 版本开始尝试，最终选择择 StarRocks 作为核心查询引擎。
欢乐互娱构建了基于 StarRocks 的底层数据平台，数据通过业务系统进入 Kafka 消息队列，Flink 进行实时清洗和转换，最终写入 StarRocks 进行存储和分析，绝大部分数据都在 StarRocks 上进行处理和存储，整个链路从数据产生到可查询的延迟控制在 2 分钟以内。
StarRocks：存算分离架构+高效分析性能优化
资源硬隔离与调度优化
考虑到不同业务场景的特点，团队采用镜舟数据库（StarRocks 企业版）的 Multi Warehouse 功能，实现精细化的物理资源硬隔离：
- BI 报表系统：独立的计算资源池，可以充分利用资源进行大查询，不影响其他业务；
- Flink 写入：专门的写入资源池，保证数据写入的稳定性；
- 默认资源池：处理客服查询、广告分析等日常业务，保证响应速度；
通过牺牲一定的资源利用率，解决业务查询间资源竞争问题，确保日常的关键业务能够稳定运行。
Flat JSON 优化，10 倍解析速度
MMO 游戏的用户行为数据呈现极强的动态特征，300 多种游戏行为包含大量扩展属性，如操作时间、设备信息、角色状态等，这些字段会随着版本迭代不断新增或调整。
团队最初采用传统 JSON 存储方案，主要考虑其灵活性优势：无需预设固定结构，当业务需要新增"副本难度"、"组队状态"等字段时，不用修改表结构，大大降低了 Schema 维护成本。然而随着数据量增长，JSON 的性能短板逐渐暴露：查询时需要扫描完整 JSON 串，包含大量冗余字段，导致用户行为路径分析、道具使用统计等核心查询耗时显著增加。
StarRocks 3.3 版本 Flat JSON 功能解决了这一难题。系统在数据导入时会自动识别行为数据中的高频公共属性，如"操作时间"、"角色等级"等，将其提取为标准数据类型单独存储，而低频或新增的动态属性仍保留在 JSON 结构中。
对于团队而言使用方式不变，无需修改业务代码。内部执行时，StarRocks 会直接调用提取出的标准字段，避免全 JSON 扫描，既保证了列式存储的查询性能，又提供了足够的灵活性来应对动态变化，JSON 解析速度可达原来的 10 倍。
Bitmap 索引，高效查询性能优化
针对游戏用户的复杂行为特征，团队构建了动态标签和固化标签相结合的用户画像体系，固定标签通过 T+1 的批处理任务计算存储在用户宽表中，支撑固定报表等日常需求。动态标签支持实时创建，用于应对临时性的分析需求。
在实际查询中，通过 Bitmap 索引技术，为每个用户标签创建 Bitmap 索引，利用位图压缩存储，使用bitmap_and()、bitmap_or()等函数动态组合标签条件，生成目标用户 ID 集合，对于一些高频使用的标签组合，通过物化视图进行预计算来加速查询。相比传统的 SQL 关联查询，通过 Bitmap 技术优化带来的性能提升可达数倍。
成效：查询性能提升 5-7 倍，业务响应更敏捷
相比之前的第三方产品和复杂的技术栈，新架构下组件数量减少，降低了维护成本，且各项性能指标都有了显著改善：
Joydata-BI 报表查询效率提升：通过实际的对比测试，相同的用户留存分析查询，在 StarRocks 上的执行时间相比原有 Trino 架构缩短了 5-7 倍。原本需要几十分钟的年度报表查询，现在可以在几分钟内完成，P99 查询延迟控制在 5 秒以内。
数据时效性提升：当前，欢乐互娱分析平台实现了准实时的数据处理能力，从数据产生到可查询的延迟缩短到 2 分钟以内。多个核心业务场景中发挥了关键作用：
- 客服系统：对于道具流水、预警信息等，客服系统需要极高的实时性，特别是付费道具的流水，需要及时查询以响应客户反馈，欢乐互娱利用 StarRocks 进行批处理，每 2 分钟触发一次统计，并通过聚合表或视图加工，能够及时发现异常情况，响应问题。
- 广告投放：广告业务对实时性要求也很高，投放人员希望能够每 5 分钟看到最新的转化数据。StarRocks 帮助欢乐互娱实现近实时的广告效果分析，如果广告数据不佳，也能够快速调整投放策略，及时止损或发现更优机会点。
未来展望
StarRocks 在极速查询、实时分析、资源隔离和灵活数据处理方面的能力，为欢乐互娱的数据平台提供高效性能支撑。欢乐互娱期待与 StarRocks 社区和镜舟科技团队持续合作，共同探索更多可能性。
随着业务进一步扩展，欢乐互娱将持续优化数据架构，为公司的全球化战略提供更强大的数据支撑，下一步规划如下：
探索湖仓一体：团队正在积极验证 Paimon 与 StarRocks 结合的技术方案。
计划将历史数据通过 Flink 归档到 Paimon 中，实现冷热数据分离，同时利用 StarRocks 的物化视图功能对热点数据进行查询加速。新游戏上线时，采用“先存储到 Paimon，根据查询频率动态决定是否在 StarRocks 中创建物化视图”的策略，来平衡成本和查询性能。
AI 辅助分析：团队正在探索多个 AI 应用场景。
通过为 AI 设定角色并结合知识库，让 AI 对报表结果进行解读，并给出结论性输出，帮助业务人员更快地理解数据异常和业务进展。未来，欢乐互娱还计划实现多轮对话，让业务人员能够基于 AI 的结论进行更深层次的下钻分析。
