导读：
开源无国界。在本期「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全球用户精选案例
