从 Snowflake 到 StarRocks + Iceberg：Fanatics 在 6PB 规模下实现 90% 成本优化！

导读：

开源无国界。在本期「StarRocks 全球用户精选案例」中，我们走进全球领先的数字化体育平台——Fanatics。

作为各大体育联盟（如 NFL、NBA、MLB）的官方合作伙伴，Fanatics 运营着 900 多家在线商店，服务全球超 1 亿用户。在这些业务背后，Fanatics 每天需要处理约 10 亿条事件数据，涵盖 800 多种事件类型。从个性化推荐到实时库存决策，高效的数据处理能力已成为其核心业务线的底层支撑。

本文将详细介绍 Fanatics 如何将原本分散的技术栈，整合为基于 StarRocks 与 Apache Iceberg 构建的统一、开放的 Lakehouse 架构。该架构在 PB 级数据规模下，为数百名内部用户提供了亚秒级的仪表盘查询体验，在显著压降成本的同时，大幅提升了数据分析与业务迭代的效率。

随着数字化体验不断向个性化与数据驱动演进，企业对数据分析能力的要求也在持续提高：既要提供快速、可自助的分析能力，又不能显著增加成本或架构复杂度。然而，当历史数据与实时数据分散在不同系统时，这种平衡往往很难实现。

原有架构与挑战

Fanatics 原有的数据架构由多个计算引擎和存储层组成：

• 数据仓库：Amazon Redshift 与 Snowflake

• 数据湖：存储在 S3 上，通过 Athena 查询（查询延迟通常超过 30 秒）

• 实时分析层：Druid，用于支撑实时仪表盘

这种多系统并行的架构逐渐带来了性能瓶颈、成本上升以及运维复杂度增加等问题：

• Athena 的交互式查询性能难以满足实时场景需求（中位延迟通常超过 30 秒）。

• 跨数据仓库的 Join 操作难以实现，团队不得不维护多份冗余数据副本。

• Druid 难以支持更复杂的分析需求，例如事实表之间的 Join、主键更新以及点查询等。

• 由于不同系统承担重叠的工作负载，且数据归属分散，数据仓库和数据传输成本持续上升。

• 不同工具和团队之间缺乏统一的数据治理机制，也缺少清晰的数据归属与责任划分。

• 强制反规范化：由于底层引擎在 Join 能力上的限制，数据在写入前往往需要提前进行反规范化处理。这不仅导致数据在多个系统中重复存储，还需要构建复杂且成本高昂的数据预处理与数据管道。

技术选型与方案评估

Fanatics 在选型初期评估过 ClickHouse 在内的多种 OLAP 引擎，但在多表 Join 和运维集成方面，这些引擎仍难以完全满足需求。

最终，他们选择了 StarRocks：高性能且功能完善的查询引擎、对 AWS Glue Catalog 的原生支持，以及支持自动查询改写的异步物化视图，使其能够更好地支撑统一的分析平台。

新一代数据架构

为解决原有架构的问题，Fanatics 构建了一套现代 Lakehouse 架构，整体技术栈包括：

• 存储层： 以 S3 作为数据源（Source of Truth），并采用 Apache Iceberg 开放表格式；

• 计算层： 选用 StarRocks 作为高性能查询与分析服务引擎；

• 元数据管理： 统一接入 AWS Glue Catalog；

• 转换与应用： 通过 dbt Core 进行数据建模，并利用 Superset 和基于 Bedrock 的 Text-to-SQL 智能体实现数据可视化与自助访问。

数据导入与表设计

Fanatics 支持多种 StarRocks 数据导入模式：

在表结构设计上，Fanatics 会根据实际的查询工作负载进行优化：

• Primary Key ：用于需要快速查询并支持实时更新的场景

• Duplicate Key ：用于高吞吐的追加写入（append-only）数据

• Tablet 大小经过优化（约 1 GB），同时通过 tenant-aware 分区设计，避免数据倾斜以及产生大量小文件

性能优化

为了进一步提升查询速度和并发能力，Fanatics 采取了以下优化手段：

• 异步物化视图 (AMV)： 针对高频访问的业务场景，通过精细化配置刷新窗口和分区对齐，并利用自动改写功能，避免了手动重写 SQL 的麻烦。

• 结合 EXPLAIN 和 ANALYZE 工具验证执行计划，确保分区裁剪（Pruning）和谓词下推（Pushdown）生效，提升查询效率。

• 持续监控并优化 Colocate Join 和 Shuffle Join，最大限度减少节点间的 I/O 开销。

• 针对高基数指标（High-cardinality metrics）配置多级聚合。

缓存与存储

Fanatics 在性能优化上采取了分层治理的策略：

• 大部分查询直接访问 Iceberg 原表。通过开启 Data Cache，将热点数据块缓存在本地。

• 仅当原表查询性能无法满足业务需求时，才会针对性地引入异步物化视图。

• 目前 StarRocks 部署在基于 EBS 存储的 EC2 集群上（存算一体架构），未来计划向存算分离架构演进，以实现更灵活的弹性扩缩容。

收益

• 成功替代了 Apache Druid 处理实时仪表盘业务。在大幅降低成本的同时，实现了在同一平台上兼顾 Join 、主键（PK）更新及高性能点查的能力。

• 随着业务场景的整合迁移，Snowflake 的使用量下降了 95%，相关成本缩减了约 90%。

• 针对 Iceberg 的即时查询（Ad-hoc）速度比原有的 Athena 快了 10 倍。

• 单个 StarRocks 集群目前承载着数千张表及物化视图，支持通过统一查询层访问 PB 级的 Iceberg 数据。

• 过去需要数天甚至数周才能完成配置的仪表盘，现在仅需几分钟即可上线。

未来规划

• 深化 AI 应用： 探索跨数据集的对话式分析（Conversational Analytics）

• 基于现有平台广泛接入 Streamlit，快速构建并交付轻量级数据应用。

• 提高自动化程度： 实现新数据库与表资产的“无感接入” (Touchless Onboarding)

• 强化灾备能力： 完善集群元数据的备份与恢复机制。

• 以 StarRocks 为统一服务底座，整合并标准化公司的 BI 工具。

StarRocks+Apache Iceberg

Fanatics 的实践证明，通过将开放表格式与高性能查询引擎相结合，大型企业能够有效简化架构、压降成本，并大幅提升数据洞察的交付效率。

通过构建“流批一体”的统一技术栈，Fanatics 实现了对实时与历史数据的协同分析，不仅提升了运行效率，也让架构更加灵活可控。

如想进一步学习与交流，欢迎添加小助手，加入 StarRocks 社区群，与更多开发者共同探索交流。

推荐阅读：StarRocks全球用户精选案例