介绍

Pinterest 是一个图片发现平台，用户可以在这里找到各种创意，比如食谱、家居和风格灵感等。平台不仅为合作伙伴提供购物功能，还为广告商提供了一个重要的广告机会，拥有超过 5 亿的月活跃用户。广告商可以直接在 Pinterest 上购买广告，或者通过广告代理机构合作购买广告。由于 Pinterest 的用户规模庞大，广告商可以从分析数据中了解他们的 Pins 和与 Pinterest 用户的互动情况，从而优化广告效果。

在 Pinterest，实时洞察对于帮助广告商和团队成员做出数据驱动的决策至关重要。这些决策会影响广告活动的表现、实验结果以及政策制定（例如垃圾邮件检测规则）。此前，他们一直依赖 Druid 来存储和提供这些实时洞察，但随着业务规模和需求不断变化，Pinterest 开始评估不同的技术栈，并最终决定将这些数据迁移到 StarRocks。

在本文中， Pinterest 将详细探讨 Pinterest 在 StarRocks 上进行分析应用构建的经历，以及为何 Pinterest 需要一个新的系统。

Pinterest 的需求

之前的系统在几年前运行得很顺利，并且能够扩展到数百台机器。但随着时间的推移， Pinterest 的规模和需求不断增加，因此 Pinterest 对企业分析端需求进行了梳理：

在规模不断扩大的同时保持低成本，以确保为内部团队提供高效的解决方案。支持标准的 SQL 类型和模式，这是用户最喜欢的接口。支持连接、子查询和物化视图，为用户提供更多选择。通过移除 MapReduce 作业等外部依赖简化数据导入过程，使得入门和使用更加方便。

在评估了多个数据分析技术栈后， Pinterest 最终选择了 StarRocks，因为它弥补了当前系统的许多不足。

StarRocks 是一个实时 OLAP 数据库，能够处理高并发的 OLAP 工作负载，非常适合面向客户的分析。由于它兼容 MySQL， Pinterest 可以轻松地将 StarRocks 与现有工具集成。StarRocks 将数据存储在本地磁盘上，还可以查询 HDFS 或 S3 中的外部数据。它由两个组件组成：前端和后端。前端将 SQL 编译成执行计划，后端执行这些计划。

StarRocks 开源社区有数千名成员参与维护和开发，社区活跃且支持良好，这也确保产品持续迭代能力和稳定性。在 Pinterest 的测试中，StarRocks 相较于当前系统 Druid 及其他方案，在性能和成本上有明显优势。它能够在大规模下即时执行快速的 JOIN 查询，有效降低对复杂去规范化管道的需求。

场景迁移应用

Pinterest 决定将 Partner Insights 作为迁移到 StarRocks 的第一个应用场景。Partner Insights 是一个为广告商提供实时洞察的工具，广告商可以通过可定制的仪表板获取这些洞察。

广告商可以登录 Partner Insights，并根据各种定制指标了解他们广告的表现。这些洞察帮助营销人员理解广告策略的有效性，并做出快速、数据驱动的调整。广告活动越有效，广告商在 Pinterest 平台上的投资回报率 （ROI） 就越高。

应用场景挑战

提供 Partner Insights 面临多方面的挑战。一方面，Pinterest 服务于大量广告商，每个广告商都有其独特的需求和指标。另一方面，这些指标不仅仅是单一维度的数据点，而是跨越多个维度，需要实时聚合。由于平台的高度可定制性，广告商可以从众多指标中选择，并根据具体目标定制仪表板。这种定制能力带来了复杂性——每个仪表板可能包含多个需要实时聚合的指标，跨越各种维度。

Partner Insights 的灵活性既是优势也是挑战，这要求数据库解决方案能够处理大量复杂的多维查询，同时保持速度和准确性。

架构与实施过程

图 3 展示了使用 StarRocks 的 Partner Insights 内部架构。架构包括：

前端 （FE） 节点：StarRocks FE 节点负责元数据管理和查询规划。后端 （BE） 节点：StarRocks BE 节点负责数据持久化、数据扫描及查询执行。Archmage：一个 Pinterest 服务，旨在屏蔽用户免受 StarRocks 集群的部署、版本升级和其他操作的复杂性，同时将 thrift 调用转换为 StarRocks 的 SQL 调用。这个服务为不同的分析存储系统提供统一的接口。负载均衡器：通过轮询方法将查询分配给四个 StarRocks FE followers，而不是过载单个follower，以最大化并发性。

Pinterest 在 Archmage 中使用连接池来减少每个连接的成本，通过维护一个固定的连接池来最小化 JDBC 连接的设置时间，从而为每个用户请求提供即时访问连接的能力。这一优化为每个 JDBC 连接节省了平均 50 ms。目前，每个集群配置有 70 个后端引擎和 11 个前端引擎和观察者，运行在 AWS R6id.8xlarge 实例上，每个实例配备 32 核心、256GB 内存和 1900 GB SSD 存储。

结果与收益

迁移到 StarRocks 后， Pinterest 发现应用端分析体验到了多项改进。迁移将 p90 延迟减少了 50%，只需要之前系统的 32% 的实例。这使得成本性能效率提高了 3 倍。数据导入过程也得到了简化，实现了仅 10 秒的数据新鲜度。

此外， Pinterest 能够消除数据导入过程中使用的 JSON 配置，因为 Pinterest 使用了 SQL 进行导入（在 StarRocks 中是可能的）。这简化了客户入门过程，节省了大量人工资源。

未来工作

目前，所有操作完全依赖于 StarRocks 的原始查询性能，Pinterest 也正在探索而查询缓存或物化视图等功能，以进一步优化系统应对高并发工作负载