干货 | 提速10倍+，StarRocks 指标平台在携程火车票的实践

作者简介

Kane，携程高级数仓经理，专注数仓建设、数据应用和分析；

Wn，大数据平台开发专家，专注大数据领域。

携程火车票事业群运营着铁友、携程火车票和去哪儿火车票等重要的业务和品牌，目前正在积极地拓展海外市场。火车票的指标平台旨在为业务人员提供便捷的指标查询服务，让业务人员能够快速灵活地获得这些业务和品牌相关的指标数据。

一、早期 OLAP 架构与痛点

火车票事业群的业务涵盖了火车票、国际火车票、汽车票（含船票）等产品，错综复杂的业务也产生了多种多样订单和行为数据，通过对这些数据的分析可以揭示当前业务的发展现状，也可以为未来的发展提供方向指引。

早些时候事业群开发过一套指标平台，根据不同的指标类型使用了 3 套数据库引擎，分别是 ClickHouse，Apache Kylin （以下简称 Kylin）和 Presto，如下图所示。

图 1

在旧版的指标平台中，为了提升查询性能使用了 ClickHouse、 Kylin 和 Presto 等多种存储和查询引擎，数据层混合使用了明细层和轻度汇总层，由此带来的问题有：

• 指标数据源混乱，容易造成口径不一致，维护成本大。

• 学习成本高，BI 同学录入指标不仅需要了解不同存储的区别，还需要掌握不同引擎的数据同步方法。

• 架构不合理，指标平台将查询的中间结果通过 jdbc 写入 mysql 后再到服务端用 java 做汇总计算，处理链路过长，整体性能非常差，导致部分指标查询需要半小时以上的等待时间。

鉴于这些原因，无论是用户（运营人员）还是指标开发人员，都面临着使用极差的问题。在这种情况下，我们决定使用基于一种查询速度快和使用简单的分布式数据库来重构指标平台。

二、指标平台重构整体设计

首先，重构指标平台我们首先考虑的是将多套存储合并成一套，虽说 ClickHouse 和 Kylin 已经足够强大，但是不足也很明显。比如 ClickHouse 的 join 性能不尽如人意，并发性能差，SQL 语法是非标准的，使用起来不方便，大量的查询很容易将 CPU 打满；Kylin 是一个分析引擎，不支持增删改操作，修改数据需要重新导入，修改 schema 需要重建 Cube（ETL成本很高），其次 Kylin 需要预先创建模型加载数据到 Cube 后才可进行查询，使用上需要具备一定的数仓知识。

于是我们将目光投向 StarRocks，StarRocks 是一款全场景的 MPP 数据库，相比 ClickHouse 等具有以下优点：

• 性能强悍：查询速度快，多张亿级表 join 也能秒级响应；