当前位置：首页 > news >正文

StarRocks 助力印度领先即时零售平台 Zepto 构建实时洞察能力

news 2025/9/25 15:16:48

导读：

开源无国界，在本期 “StarRocks 全球用户精选案例” 中，我们走进印度即时零售品牌 Zepto。

这家以 “10 分钟送达” 闻名的公司，业务已覆盖 50+ 城市、45,000+ 商品，品类横跨生鲜杂货、电子产品、美妆个护、服饰、玩具等。凭借前沿技术与战略布局的前置仓网络，Zepto 在短短几年间彻底改变了印度的即时零售格局。

随着规模扩张，Zepto 借助 StarRocks 从 Postgres MVP 升级为生产级实时分析平台，单表每日导入 3000 万+ 行数据，在品牌看板上实现亚秒级查询，帮助品牌合作伙伴从“日报表”迈向准实时洞察，快速响应市场、智慧决策。

在 Zepto 的用户体验中，品牌始终占据着核心位置。我们依托丰富多元的商品目录，不仅满足了消费者的多样化偏好，也为品牌提供了跨城市的广泛触达。每天，Zepto 处理着数百万条数据，从商品浏览到城市级销售，全方位呈现产品在不同区域的表现。

然而，真正的挑战不是“有没有数据”，而是“如何把数据转化为可执行的洞察”。这正是 Zepto Brand Analytics 发挥作用的地方。它专为快节奏的即时零售场景而生，能够快速、直观地帮助品牌识别趋势、优化表现，并实时做出更明智的决策。在瞬息万变的市场里，唯有敏捷才能赢得先机。

“如何在不让合作品牌久等、又不对数据过度简化的情况下，提供实时、可执行的洞察？”

基于这个问题，Zepto 推出了 Brand Analytics —— 一个专为品牌打造的数据看板，提供丰富的数据，包括：

销售走势
库存情况
搜索趋势与用户转化
子品类层面的表现

MVP 阶段：用 PostgreSQL 快速起步

就像大多数初创团队一样，我们在起步阶段选择了轻量灵活的方式。Brand Analytics 的第一个版本搭建在 PostgreSQL 上，让我们能够快速上线产品，并从一批早期合作品牌中收集反馈。

当时，我们已经能在品牌、城市、商品等维度上追踪 GMV、销量等核心指标。彼时的核心销售表仅有几百万行数据，PostgreSQL 能轻松应对。

我们的分析团队选择了 Databricks 来管理和维护数据表。它既具备笔记本的灵活性，又拥有大数据处理的强大扩展能力，能轻松应对复杂查询和高效管道的构建。同时，Databricks 与 Delta Lake 深度集成，为 Lakehouse 架构提供了坚实的基础。

在最初阶段，我们的架构设计十分简洁：将订单、曝光、商品信息等多张表在 Databricks 中进行关联，生成一张统一的销售表，类似星型模型。随后，通过每日定时任务把数据同步至 Postgres。我们的首要目标是快速上线验证概念，以便第一时间收集品牌的使用反馈。对于早期需求来说，每日同步已经足够。

不过，直接让 Databricks 驱动前端界面并不可行 —— 它的响应时间过长，并发能力有限，难以保障用户体验。即便只是阶段性的过渡方案，Postgres 满足了我们对快速响应的需求。

快进：成长的阵痛

短短一段时间里，业务发生了翻天覆地的变化：

加入平台的品牌越来越多
合作伙伴高度依赖分析看板来做业务决策，使用量激增
商品目录急速扩张，SKU 和品类呈指数级增长

很快，我们的数据量突破了 2 亿行交易记录，并且仍在快速增加。这时候，Postgres 开始力不从心。

作为主要面向 OLTP 工作负载的数据库，Postgres 在应对品牌伙伴需要运行的那类复杂、大规模分析查询时，逐渐表现吃力。

所以，我们需要一个专为大规模数据分析而构建的 OLAP 系统，来支撑高速、复杂的查询场景。

分析愿景清单

在转型之际，我们清楚地意识到必须升级架构，并明确了几项关键要求：

能够支持复杂的多表关联，而不必牺牲数据模型的规范化
面向外部用户看板，提供亚秒级响应速度
与 Kafka 和 Databricks 等上游数据管道实现无缝衔接

候选方案：ClickHouse、Apache Pinot 与 StarRocks

在选择新一代 OLAP 数据库时，我们对几款热门方案进行了基准测试。结果发现：

ClickHouse 的查询速度很快，但在复杂的多表关联上显得吃力
Apache Pinot 在低延迟写入方面表现出色，但在我们需要的复杂查询场景下存在局限
StarRocks？它不仅满足了所有核心需求，还带来了更多惊喜

为什么选择 StarRocks？

StarRocks 之所以在众多候选中脱颖而出，原因在于：

Join 性能极快：StarRocks 在多表 Join 的优化上表现惊艳，能够高效处理复杂查询。这正是我们核心场景的关键胜负手。
在 3 亿+ 行数据上实现 P99 < 500ms：在模拟实际业务场景的基准测试中，StarRocks 即使在大规模数据下，也能持续保持亚秒级的查询性能
原生支持 Kafka 与 S3（Parquet）：StarRocks 与我们现有的数据生态无缝衔接。无论是 Kafka 的 Routine Load，还是 S3/Parquet 的支持，都让我们几乎无需对数据管道做大幅调整，就能从原型快速切入生产环境。

StarRocks 在生产环境中的落地实践

选择 StarRocks 只是开始，要真正发挥它的价值，我们需要在架构层面做出关键抉择。

两种架构模式：存算一体与存算分离

StarRocks 提供两种存储架构选项：

存算一体：数据由 StarRocks 本地存储和管理
存算分离：StarRocks 可直接从对象存储（如 S3）中查询数据
📖 延伸阅读：Architecture Deep Dive

在充分评估之后，我们决定采用存算一体架构 —— 让 StarRocks 完全负责数据的本地存储与管理。

为什么选择存算一体

性能优先 —— 我们的分析看板面向品牌用户，响应速度直接决定用户体验。本地存储意味着更快的查询响应。
数据规模可控 —— 当前数据量还在数十 TB 以内，使用本地存储并未遇到容量或扩展瓶颈。

当然，如果业务已经达到 PB 级数据量，并且更看重弹性与计算/存储分离，那么存算分离架构或许是更好的选择。

将数据导入 StarRocks

为了支撑分析看板，我们需要将多源数据导入 StarRocks。随着产品不断成熟，我们的导入方式也逐步演进，目前主要依赖两条数据管道：

1. 通过 Pipe Load 从 Databricks 加载数据（S3 / Parquet）

在早期，我们的数据流非常简单：每天从 Databricks 表批量同步到 Postgres。

而在引入 StarRocks 后，借助 Pipe Load，我们能够让系统持续扫描指定的 S3 路径，并自动加载新生成的 Parquet 文件。（补充说明：Databricks 会将数据以 Parquet 文件的形式存储在 S3 的文件夹中）

下面是一条典型的 CREATE PIPE 命令示例：

CREATE PIPE <pipe_name>  
PROPERTIES (        "AUTO_INGEST" = "TRUE" 
)  AS  
INSERT INTO <tablename>  
SELECT * FROM FILES (        "path" = "s3://<bucket-name>/<folder-name>/*.parquet",        "format" = "parquet",        "aws.s3.region" = "<region>",        "aws.s3.access_key" = "<>",        "aws.s3.secret_key" = "<>"  
);

PIPE 使用小技巧