ksxz
AutoMQStarRocksKafka数据架构实时分析

AutoMQ x StarRocks：英国美容健康领导者 Fresha 如何构建现代化实时分析数据栈

InfoQ··原文链接
收录于 2026/5/17 12:57:46

背景与挑战

Fresha 总部位于英国，服务全球数百万消费者与商家。每天商家打开首页查看经营数据时，背后是每日 60 万笔预约、数十亿条数据库变更事件，以及峰值每秒 3000 次请求共同支撑的实时数据管道。

随着实时链路压力持续上升，单点优化已无法解决根本问题，必须重新设计整套架构。

旧架构的困境

消息层：Kafka 的数据中心架构遇上云

Fresha 的数据管道构建在 Apache Kafka 之上，约 100 个 Postgres 数据库的变更事件通过 Debezium CDC 写入 Kafka，下游 Flink、Spark、StarRocks、Snowflake 等系统再从 Kafka 消费数据。

团队运行两个 MSK 集群：

  • CDC/Warehouse 集群：承载全部 CDC 流量，每天流转数十亿条事件
  • Outbox 集群：微服务之间的事件驱动集成层，对延迟要求远高于 CDC

Kafka 上云的四大问题：

  1. 存储成本高：EBS 按容量和 IOPS 收费，三副本机制意味着接近三倍的存储成本
  2. 跨 AZ 流量费用高：Broker 之间跨可用区复制副本，数据规模越大成本越明显
  3. 扩容粒度粗：扩容往往意味着增加整台 Broker，CPU、内存、网络和存储一起扩，容易造成资源浪费
  4. 弹性受限：分区绑定在特定 Broker 上，新增 Broker 后需要物理搬迁分区数据，过程持续数小时甚至更久

Fresha 的流量还呈现明显的尖峰特征：每天早晚高峰请求量可能达到平时的数倍。但在存算耦合架构下，必须按峰值流量预留整台 Broker 的容量，导致大部分时间资源处于闲置状态。同时，MSK 的成本随分区数量增长而上升，新增 Flink 作业往往需要引入新的中间 Topic，费用压力持续增加。

分析层：从 Postgres 到 Snowflake，瓶颈仍在继续

最初分析需求直接由 Postgres 承担，商家首页的实时分析组件查询直接打到 OLTP 数据库上。但访问流量具有明显的尖峰特征：早晚大量商家集中打开首页查看经营数据，形成请求高峰。

高峰期分析查询会加载大量历史数据页，直接挤占 buffer cache 中的事务热数据。结果是：第一个冷查询往往因拉取大量数据页而超时；后续请求虽然可能命中缓存，但 OLTP 事务所需的热数据已被挤出缓存，连下单接口也会受到影响，出现响应变慢。对于最重要的大商家，P99 延迟一度飙升到 4 秒以上，大量请求直接返回 500 错误。

团队尝试将分析负载剥离到 Snowflake：通过 Debezium CDC 同步数据，再用 dbt 批量建模。但 Snowflake 只能做到约 20 分钟刷新一次，离真正的实时仍有明显距离。尝试 Lambda 架构可将延迟降到几十秒，但架构复杂度迅速上升；ClickHouse 面对 20-30 个 Join 的复杂场景需要预建模成宽表，前期投入过重。

新架构全景

核心理念：构建一条统一的数据摄取主干（Ingestion Spine），并在其上延伸出多条面向不同业务需求的数据链路。

约 100 个 Postgres 数据库通过 Debezium 捕获 CDC 事件，经 Schema Registry 以 Avro 格式序列化后写入 AutoMQ；随后由 Flink 和 Spark 将数据分发到不同下游系统：

  • StarRocks：支撑实时 Dashboard
  • Iceberg / Paimon：Lakehouse 长期存储
  • Elasticsearch：全文搜索

在新架构中，StarRocks 作为统一的 SQL 查询入口，通过 MySQL 协议对外提供服务。工程师可以用一条 SQL，将实时数据、历史数据与搜索索引关联起来完成分析查询。

为什么选择 AutoMQ

Diskless Kafka 的核心思路

将数据从 Broker 本地磁盘迁移到云对象存储（如 S3），让 Broker 变成无状态计算单元，存储交给云基础设施。S3 本身已提供 11 个 9 的持久性和跨 AZ 冗余，应用层不再需要通过多副本复制来保证数据可靠性。

传统 Kafka 在云上的核心问题（三副本存储成本、跨 AZ 流量费用、扩容必须增加整台机器、分区迁移需要物理搬运数据）都能在这一架构下被同时化解。

WAL 层的创新

纯 S3 架构的 Diskless Kafka 方案，写入延迟受对象存储响应时间限制，往往在数百毫秒级别。对 Fresha 的 Outbox 集群（延迟敏感）来说无法承受。

AutoMQ 在 Broker 与 S3 之间引入了 WAL（Write-Ahead Log），将其作为存储引擎的核心组件。数据写入时，先落到 WAL 完成持久化并立即返回 ACK，再由后台异步批量刷入 S3。

这一设计既保留了 Diskless Kafka 的核心优势（Broker 无状态、存储交给 S3、无需应用层副本复制），又通过不同 WAL 后端覆盖不同场景下的延迟需求：高吞吐、低成本场景可使用 S3 WAL；延迟敏感场景则使用低延迟 WAL。两类负载不再需要拆成两套系统。

迁移收益

  1. 架构驱动的成本降低：S3 存储成本比 MSK 低 17-20 倍；定价模型不与分区数绑定，Flink 中间 Topic 可按需创建
  2. 一套先进的 Diskless 架构覆盖多类场景：Broker 无状态实现秒级弹性伸缩；WAL 层的不同后端让 CDC 和 Outbox 集群运行在同一套 AutoMQ 架构之上
  3. 100% Kafka 兼容，零代码改动无缝迁移：内置的 Kafka Linking 零停机迁移工具让团队在一周内完成了近 1000 个 Topic 的迁移

为什么选择 StarRocks

Fresha 需要的并不只是一个"更快"的分析引擎，而是一套能够真正承接实时业务分析的查询层。其查询模式的两个特点：

  1. Join 多且复杂：首页分析通常涉及 3-5 个 Join，支付日志分析经常达到 20-30 个 Join，且跨多个数据库
  2. 实时性要求高：直接服务商家首页，既要求低延迟，也要求分钟级的数据新鲜度

StarRocks 能够在不依赖重度预建模的情况下支撑复杂 Join 查询，同时兼容 MySQL 协议，工程师可直接复用现有的客户端和接入方式。

迁移实战经验

关键挑战：Offset 一致性

Fresha 的 CDC 集群承载着近 1000 个 Topic，下游连接着 Flink 作业、各类 Connector、StarRocks Routine Load 以及 Snowflake 数据管道。每个 Topic 背后都有下游消费者依赖对应的 offset 来维护消费位点。

一旦 offset 不一致，就可能导致 Flink checkpoint 失效、Consumer 消费位点丢失——成本几乎等同于重建整条数据管道。

传统迁移工具 MirrorMaker2 会重新序列化消息，导致目标集群中的 offset 与源集群无法保持一致。

解决方案：Kafka Linking

AutoMQ 内置的 Kafka Linking 专门解决迁移过程中最关键的两大问题：业务不中断、消费位点不丢失。

团队采用分阶段切换策略：

  1. 先迁移非关键负载：优先将监控、日志类 Topic 迁移到 AutoMQ，验证数据完整性和延迟表现
  2. 再迁移关键业务 Topic：验证完成后，逐步迁移核心业务 Topic

通过 Kafka Linking 的能力，一周内完成了近千个 Topic 的零停机迁移。

总结

Fresha 的数据平台升级证明了现代实时分析架构的核心特征：

  • 云原生：利用 S3 等云基础设施的持久性和弹性，摆脱传统存算耦合的束缚
  • 统一平台：一套架构覆盖高吞吐和延迟敏感两类负载，降低运维复杂度
  • 兼容与无缝迁移：100% 协议兼容 + 内置迁移工具，让大规模系统升级可以在业务不感知的情况下完成
  • 实时与灵活：StarRocks 提供的复杂 Join 能力和 MySQL 协议兼容，降低了实时分析场景上线的门槛

对于正在经历数据规模快速增长、同时面临成本控制压力的技术团队，Fresha 的实践提供了一个可参考的范本。

返回首页