降本增效，StarRocks 在同程旅行的实践

作者：周涛 同程旅行数据中心大数据研发工程师

同程旅行是中国在线旅游行业的创新者和市场领导者。作为一家一站式平台，同程旅行致力于满足用户旅游需求，秉持 "让旅行更简单、更快乐" 的使命，主要通过包括微信小程序、APP、轻应用及其他渠道在内的线上平台，为用户提供几乎涵盖旅游所有方面的全面创新产品和服务选择，涵盖交通、住宿、景点门票预订及各种配套增值旅游产品及服务，旨在满足用户在整个旅途中不断变化的旅游需要。目前，同程旅行的月活跃用户已达到 2 亿多人。

为了提升数据分析查询性能，同时降低人力和硬件成本，公司的出行、住宿和公共等多个业务线都已接入并使用了 StarRocks 技术。

同程旅行有多年的 OLAP 使用经验，随着业务增长和变化，促使我们需要不断探索更合适的组件来满足需求。在这方面，StarRocks 作为一款优秀的数据库，在同程旅行的生产环境中得到了广泛应用，涵盖实时、离线和 Customer Data Platform（顾客数据平台，以下简称 CDP）等多个应用场景。

本文将从同程旅行 OLAP 平台演进、业务痛点和 StarRocks 是如何解决当前业务痛点这几个部分详细介绍 StarRocks 在同程旅行的生产落地实践。

同程旅行的 OLAP 平台演进

随着公司的业务变化和用户量的增加，数据量也在不断增加。数据分析场景变得越来越多样化，对实时分析的时效性要求也更高了。为了更好地满足这些需求，同程旅行的 OLAP 平台也在不断演进，整体的发展过程大致分为三个阶段：

第一阶段：以 Druid+Kylin 为基础构建的数据分析体系，满足了当时对于离线数据分析加速的需求，但在使用过程中也逐渐暴露出 SQL 分析、联邦查询、BI 兼容等方面能力不足与 CUBE 运维成本较高等一系列问题；

第二阶段（引入 StarRocks 前）：在这一阶段，我们采用 ClickHouse+Greenplum 支撑实时、离线业务的分析处理，在一定程度上解决了上一阶段存在的问题；

第三阶段：由 StarRocks 作为统一的 OLAP 组件，减少多组件的维护压力。同时注重在企业内部与相关数据平台的集成，提升用户使用体验，降低用户组件使用和切换成本。

在说明我们为什么选择 StarRocks 作为我们新一代的 OLAP 组件前，我们需要先了解原有平台架构的不足：

• ClickHouse：主要用于用户行为轨迹和订单实时数据存储和分析

• Greenplum：主要用于公司内部的灵动分析看板，做分析报表使用

如上图所示，在原始架构中，对于实时场景，业务数据通过 Kafka 传入 Flink，在 Flink 中进行清洗、打宽表等逻辑处理，之后将结果数据导入 ClickHouse 中；对于离线场景，数据统一存储在 HDFS 中，通过 Hive+Spark 进行清洗处理后，将结果数据传入 Greenplum 中。

实时场景

主要涉及业务订单数据，数据可以通过前端用户埋点到 Kafka，或者订阅业务订单数据库 Binlog，实时写入到 MQ，然后使用 Flink SQL，关联维度表，将数据打宽，最后写入到 ClickHouse 中。

离线场景

将实时的用户埋点数据或订单库离线同步数据写入到 HDFS 中，然后经过离线调度做 ETL 数据清洗，再搬运到 ClickHouse 或 Greenplum 中。然而，在使用过程中，我们发现实时和离线分离架构存在一些问题：

• 分离架构导致开发使用极度不方便，且浪费计算存储资源；

• 组件技术栈不统一，导致业务人员需要熟悉多种语法；

• 多组件造成了极高的运维成本。

为解决在使用 ClickHouse、Greenplum 过程中遇到的性能、运维和成本等各方面的问题，我们进行了一些调研，开始对比和了解一些新的 OLAP 组件。接下来，我们将进一步说明使用 ClickHouse 和 Greenplum 架构所带来的业务痛点。通过这些问题的阐述，我们可以更好地理解为何需要寻找新的解决方案。

01 ClickHouse + Greenplum 架构带来的业务痛点

目前，同程 OLAP 组件被广泛使用，并已集成到实时开发平台、离线开发平台、灵动分析、数据地图和快速取数等多个平台系统中。在业务方面，主要涉及以下三类场景：

1.1 实时数据分析

在使用实时数据分析的业务场景，我们主要针对用户行为埋点、用户实时订单等数据进行冷热存储。实时热数据需要存储 30 天至一年不等的时间数据，用于高性能要求的实时统计分析；历史离线数据存储在 HDFS。在查询实时数据时，如果涉及多表关联或者关联历史数据时，当前组件性能无法满足，需要提前离线清洗，导致数据时效性较低。

1.2 灵动数据报表

在使用灵动数据报表的业务场景，用户在离线数仓中清洗出 DWD 或 ADS 层表，通过离线开发平台导入到 Greenplum 中，然后在灵动分析中配置数据集，以拖拉拽的形式生成看板，提供给分析决策使用。然而，在高峰时期，我们经常遇到查询速度慢甚至查询超时等问题，这给业务带来了困扰。

1.3 用户画像 & CDP

在用户画像和 CDP 的场景中，我们会根据用户基本信息、消费数据和行为数据等生成对应标签数据，以创建用户画像，并进行人群圈选和漏斗分析等。

之前我们使用了 ClickHouse 作为存储分析引擎，但随着 CDP 需求的变化，业务场景更加复杂，涉及到多表关联场景以及宽表和 BitMap 关联场景，用户对实时分析的查询性能提出了更高的要求。经过测试，ClickHouse 已无法很好的满足。

针对当前 ClickHouse+Greenplum 体系存在的各种问题，我们开始了基于 StarRocks 构建分析体系 3.0 阶段的升级演变。

StarRocks 在同程旅行的应用与实践

01 选择 StarRocks 的原因

为了解决上述问题，我们追求在新的 OLAP 组件中实现简单、高速和统一的特点（包括支持联邦分析）。为此，我们进行了 StarRocks、ClickHouse、Greenplum 和 Presto 等 OLAP 组件的比较。我们比较了数据摄入速度、查询性能、内存占用率、维护成本和易用性等指标。通过这些比较，我们希望找到最适合我们业务需求的 OLAP 组件。

下图展示了这些组件的具体比较结果：

• 查询性能优异：

StarRocks 是一款分布式列式存储分析数据库，它具有非常高的查询性能，尤其适用于实时数据分析和查询场景。与 ClickHouse 相比，StarRocks 在多表联合查询方面表现更出色，尤其在 Primary Key 模型方面，其在实时动态更新和查询性能方面都表现优异。

​

• 维护难度低：

StarRocks 由 FE 和 BE 两类组件组成，不依赖于第三方组件，可以开箱即用。而且，StarRocks 具有良好的可扩展性，集群扩缩容方便，可以根据需求动态扩展集群规模，灵活提高系统性能。此外，数据可以在节点之间自动均衡，无需人为干预。

​

• 方便易用：

StarRocks 采用标准 SQL 协议且兼容 MySQL 协议，可以轻松集成到现有系统中。此外，在实时写入方面，官方也提供了 flink-connector-starrocks，写入可实现 exactly-once。另外，StarRocks 还具备方便的联邦查询功能，避免了数据搬运带来的资源消耗，从而提高了系统性能。

经过多方比较，我们最终选择了 StarRocks 作为统一的 OLAP 组件，并预计在未来逐步完成统一 OLAP 层的工作 。

02 StarRocks 的引入

同程旅行主要在以下三个场景中使用 StarRocks：实时数据分析、离线报表和 CDP 系统。

随着 StarRocks 的接入，新的数据应用流程架构如下：

​

2.1 使用 StarRocks 解决当前痛点

1）实时数据分析的整体时效性提升

在实时应用场景中，业务数据进入到 Kafka 或者 TurboMQ，然后通过 Flink 任务或 Flink SQL 任务进行业务计算转换，最终通过 flink-starrocks-connector 实时写入到 StarRocks，进行实时指标统计或者实时数据分析。实时链路中不再涉及关联打宽，缩短了链路，提升了整体的时效性。同时，StarRocks 采用星型模型组织数据，减少数据冗余存储。以下是我们实际中的一个 Flink SQL 案例：

​

通过将 StarRocks 集成到实时开发平台，用户可以轻松快速地将实时数据导入 StarRocks 并进行使用。

2）离线报表查询性能大幅提升

我们已经成功将 StarRocks 数据源集成到灵动分析系统中。现在可以将 StarRocks 中的表创建为灵动中的数据集，进行分析看板配置，并实时写入数据。此外，无需重复清洗，还可以直接进行报表配置。由于 StarRocks 支持标准 SQL 并兼容 MySQL 协议，因此系统集成 StarRocks 数据源非常便捷。切换引擎后，与 Presto 和 Greenplum 相比，报表查询性能大幅提升（在某些实际场景中，相较于 Greenplum，查询性能提升近一倍）。

下图是对 14 个 SQL 耗时进行统计对比：

​

3）CDP 系统查询效率提高

CDP 是一种数据管理平台，它可以集成多方数据，帮助企业更好地了解用户行为、喜好和需求，从而制定更加精准的运营策略。CDP 系统上线后，可以服务于公司各个事业部，对用户进行分层或保存人群进行运营，从而极大地提升了运营效率并降低了运营成本。

CDP 系统的具体工作流程如下：

1）数据导入：

当前先知系统有 1000 多个历史人群需要作为人群圈选的条件，而这 1000 多个人群数据的导入耗时较高，存在性能瓶颈。经过调研，使用以下方法可以很好的解决这个问题：

• 将 String 类型的用户 ID 转换成 Long 类型的 oneId；

• 然后通过 Spark 任务将 oneId 转换成 Java 代码的 BitmapValue 对象；

• 在所有的相同 key 的 BitMap 合并后，转换成 Base64string，这样将相同的 key 的数据合并成一条数据，导入到 StarRocks 中。

• 
  

经过验证，采用以上方法可以大大提高数据导入性能，将 1.5 亿条数据的 10 个任务同时导入的耗时从 10 分钟以上下降到 10s 以内，并且可以减少导明细数据的集群资源消耗。

​

如上图所示，根据数据监控显示，红框内时间段是明细导入的网络传输量，而其他时间段为 BitMap 合并 Base64 后的传输量。这两者之间的传输量相差约 10 倍。针对这个问题，我们正在努力优化导入代码，并将其整理成 Demo，以便提交给社区供大家参考使用。

2）人群圈选：

接下来我们需要通过 BitMap 的函数操作，对用户选择的条件进行人群圈选。通过将条件组合成 StarRocks 对应的 BitMap 的 and、or、union 等函数，简单的查询可以在 3 秒以内得出结果。即使是复杂的（例如涉及宽表与多个 BitMap 表的关联查询）且数据量大的查询，也都可以在 10 秒以内得到结果。

3）人群保存：

这一步将圈选的结果人群 BitMap 转换成一个明细表，然后再通过 export 语句方式，将表的数据导入 HDFS 进行输出应用。

下述是实际应用中的人群分层迁移桑基图的 SQL 示例：

对应结果图：

​

该 SQL 中包含了 BitMap 与普通宽表的关联操作，以及三个亿级别大表的关联操作，整体可以在 5 至 10 秒内计算完成。

未来规划

• 更多业务场景推广落地

在公司内，我们将继续扩大和推广 StarRocks 的使用，以替换其他业务中遗留的 ClickHouse 和 Greenplum 组件，减少多组件的维护压力。同时注重在企业内部与相关数据平台的集成，提升用户使用体验，降低用户组件使用和切换成本。

• 上云

将 StarRocks 部署在公司的 Kubernetes 私有云中，以提高集群的扩展性和灵活性，并且可以依赖于 Kubernetes 的容错机制，自动监测和替换故障节点，提升集群可靠性和稳定性。目前，我们已经完成了开发，进行到了测试验证阶段。后续我们也将持续跟进测试 StarRocks 提供的云原生能力。

• 存算分离特性的使用

在离线报表应用中，我们计划测试使用即将推出的 3.x 版本。根据其存算分离的能力，在不降低查询性能的条件下，可以大大减少离线数据同步的工作量。

• 与社区共赢

我们将持续保持与社区的沟通，积极地将使用体验和性能测试反馈社区。通过与社区的合作，实现双赢的目标。