[冰山峰会回顾] 腾讯游戏利用 Apache Iceberg 整合 PB 级孤立数据

腾讯游戏成功地将分散在子公司和产品中的宝贵数据整合在一起，得益于Apache Iceberg的帮助。在这次演讲中，腾讯游戏的后台软件开发工程师张洪力将带领参会者了解腾讯游戏的工程团队如何统一游戏数据的技术历程，以及Apache Iceberg结合StarRocks是如何实现这一壮举的湖仓架构。

最初，腾讯的游戏日志数据存储在Hadoop文件系统中，而应用层数据则分散在传统的数据库如MySQL、PostgreSQL中。实时数据存储在Druid中。这种存储方案使得数据使用变得复杂，并常常导致数据访问瓶颈。

管理实时和批量处理的两个独立数据管道既复杂又昂贵。查询时，所有数据需先在Hive中预处理，包括预聚合和反规范化，之后再移至PostgreSQL用于报告和仪表板。这不仅增加了计算和存储资源的消耗，还让数据被固定在不可变的单一视图格式里：任何模式变更都需要重新调整管道并进行数据回填。

面对每天增长的数万亿个数据点，数据规模与集群容量之间的差距扩大了。一个新的系统亟需。新的系统需要满足以下条件：

• 亚秒级查询延迟
• 能够存储和管理 PB 级别的数据
• 低运维成本：操作简便，易于维护

经过调研不同的解决方案后，腾讯发现Iceberg能满足他们的需求。Iceberg是一种开放的用于分析的表格格式，它支持模式演进、隐式分区、时间点查询和版本恢复。这些特性使得数据仓库工作负载可以在单一的开放数据副本上统一，从而实现简单易治理的数据管理和架构。

为了实现二级查询功能和数据的新鲜度，腾讯使用StarRocks作为查询引擎来实时摄入层。StarRocks是一款超快的、大规模并行处理查询引擎，具备以下功能：

• 完全采用向量化的引擎
• 支持高并发
• 实时分析可变数据
• 架构简单：仅包含两种类型的进程——FE（前端）和CN（计算节点）

借助 Apache Iceberg 和 StarRocks，腾讯游戏能够开发出具备以下功能的湖仓体系：

• 简单且可扩展的架构，每天可处理万亿条新的数据记录
• 秒级查询延迟，支持PB级数据
• 数据更新秒级响应，支持可变数据，持久化在 Apache Iceberg 中

腾讯游戏团队为了取得这些令人瞩目的成果，构建了一些额外的功能和优化。

腾讯游戏开发了一个无状态的CN（计算节点）和一个Kubernetes运算符。因为它们无状态，CN可以动态扩展以适应工作负载变化，从而大大节省了腾讯游戏动态工作负载所需的计算资源。

所有数据都存储在Iceberg中，CN用来实现系统的弹性和资源隔离。热数据暂时存放在StarRocks BE节点，并定期同步到Apache Iceberg，以实现数据持久化；这两个动作确保了数据的更新。借助StarRocks的存储引擎（BE节点），腾讯游戏可以轻松实现秒级数据更新，即使处理可变数据也毫不费力。所有数据都持久化在Apache Iceberg中，确保了单一数据源的真实一致性。

在查询时，StarRocks 表作为访问 StarRocks 和 Iceberg 数据的单一入口。用户的查询会自动由 RBO（成本基础优化器）重写，从而可以无缝查询 StarRocks 和 Iceberg 中的数据。

在运行上述湖仓架构之后，腾讯游戏遇到了几个挑战：

• 资源浪费：高峰期的大查询请求需要大量的计算资源，而在低峰期则会出现资源浪费。
• 资源隔离不佳：Iceberg中处理大量数据时的SQL查询消耗了大量的CPU和内存资源，导致其他请求或数据导入失败或变慢。
• 执行计划生成慢：持续的实时摄入生成了数以百万计的数据文件，使得查询计划生成过程变得缓慢。查询扫描两个月数据时，生成计划需要超过65秒。

为了应对这些挑战，腾讯游戏团队实施了以下优化措施：

弹性扩展
腾讯公司开发了一个无状态计算节点（CN）的Kubernetes操作符。让计算节点作为Kubernetes中的容器运行，实现了轻松部署、维护和动态扩展功能，从而减少资源浪费。

物理资源隔离
使用 Kubernetes，腾讯游戏可以按需创建具有相同标签但不同规格的计算节点（CN）组 — 例如，一组具有 4 核和 8GB 内存，另一组具有 24 核和 64GB 内存。这种设置允许每个组的 CN 数量自定义，并提供独立的生命周期管理，任务结束后可以销毁这些组。重要的是，这种架构为腾讯游戏的异构负载提供了物理资源的隔离。

**不可变元数据文件缓存
腾讯游戏还在自定义的Hive目录中添加了一个LRU文件IO缓存机制，以更高效地访问包括元数据文件、清单列表以及单个清单文件在内的不可变元数据文件。这一步优化显著减少了I/O开销，加快了元数据访问。

优化Iceberg执行计划
当数据文件过多时，读取所有列的统计信息是一项非常耗资源的任务，特别是在查询规划阶段。腾讯游戏预先计算并缓存StarRocks表中的数据文件列统计信息，这些信息可以由CN和BE节点并行读取，从而进一步加快执行计划的生成。

这些优化带来了显著的好处，例如——一个过去需要65秒生成的查询计划现在只需6秒；无状态的CN节点也节省了数万个计算核心的节省。Apache Iceberg的其他优化，如快照清理和数据文件压缩，进一步提升了湖仓架构的性能和可管理性。

根据XML标签的提示，最终翻译应为：

Q: 什么样的技术能实现复杂查询的亚秒级响应时间？
A: 红丽：可以用StarRocks作为仓库，并缓存湖中热点数据。对于湖查询，可以利用弹性计算资源。

Q: 您将什么样的工作负载分配给 StarRocks、Spark 和 Trino？为什么？您有什么关于 StarRocks、Spark 和 Trino 之间性能的比较想分享的吗？
A: Hongli: 由于需要一个仓库来缓存数据，所以无法与 Spark 进行比较。在我们的场景中，将 StarRocks 与 Trino 在数据湖上进行比较，性能提升了10倍。这非常令人印象深刻。新增的灵活计算节点（CN）让 StarRocks 相比 Trino 更加灵活。

Q: 你是否使用了 Velox 开源的 C++ SIMD 向量化引擎？
A: Hongli：我们自己做的。（StarRocks 的 SIMD 向量化引擎是我们从头开始开发的）

Q: 统计信息是按分区来计算的吗？
A: 洪利：每个数据文件单独统计。

Q: 预计算并缓存的数据是否存放在你自己的元数据集中？
A: Hongli: 我们把数据文件的统计信息存入一个表中（即 StarRocks 表），该表位于仓库中。

Q: 你在保持列统计信息的物化以优化查询计划方面遇到了困难吗？
A: Hongli: 还算顺利。实时数据还需要计算。

Q: Trino和StarRocks的维护成本相比如何？
A: Hongli: 简单来说只有两个组件。这些弹性节点部署在Kubernetes上，维护起来也很方便。

Q: 大多数这里提到的功能是开源 StarRocks 中可用的，还是仅在腾讯内部可用？
A: Hongli: 我们开发的功能，比如弹性节点CN，也已经贡献给了社区。数据同步到（Iceberg）湖的功能还在社区贡献的过程中。

加入我们的 Slack 社区

如果你对StarRocks项目感兴趣，有疑问，或者只是想了解更多解决方案和最佳实践，可以加入我们的StarRocks社区在Slack。这是一个与项目专家和来自你行业的伙伴结识的好地方。你也可以访问StarRocks论坛了解更多资讯。