StarRocks 统一 OLAP 引擎在滴滴的探索实践

作者：余辉，滴滴出行 OLAP 团队负责人/专家工程师；李明皇，滴滴出行高级软件开发工程师

发展历程

滴滴的 OLAP 系统早期由用于实时监控系统的 Apache Druid （以下简称 Druid）和离线加速使用的 Apache Kylin（以下简称 Kylin）逐步发展起来。在 2018 年后开始全面发展，当时主要使用 Druid、Kylin 和 Presto 等引擎，用于承接实时监控、实时看板和数据分析等场景。随着业务使用量和业务复杂度的提升，原有的这些引擎由于性能、稳定性、易用性、维护成本等原因，已经无法满足各种复杂的使用需求，查询性能和稳定性难以满足。

在 2020 年后引入当时业界广泛使用的 ClickHouse 引擎。ClickHouse 是一款开源 OLAP 的列存数据库， 号称比 MySQL 快 100-1000 倍，最大的特色是高性能的向量化执行引擎，单机性能强悍。通过 ClickHouse，支持了当时网约车、 顺风车、青桔单车、橙心优选等多个业务线运营看板、实时分析等场景。经过长时间的发展和迭代， ClickHouse 和 Druid 成为当时滴滴内部主要的 OLAP 引擎，也初步让 OLAP 产品在滴滴内部发展壮大。

选型

随着在滴滴内部使用 OLAP 场景的不断增加，主要涵盖监控报表、日志分析、离线加速和实时数仓这四个场景。原有的基于 ClickHouse 和 Druid 建设的 OLAP 系统暴露的问题越来越多。主要有：

1. 维护困难：在 OLAP 场景中维护的引擎和组件有 5 个之多，每个引擎使用方式，运维方式不一样。导致难以维护， 难以发展。

2. 使用不便：不同引擎特点不同，它们针对的场景比较单一，用户难以根据业务场景正确选择引擎。另外，对于 ClickHouse 从能用到用好难度很大，经常出现查询性能未达预期。

3. 稳定性压力大：引擎多投入人力有限，问题频频发生，无有效解决方案。很多业务场景混合在一个集群中，缺少资源隔离机制，服务稳定性难保障。

4. 用户需求难以满足：部分用户有修改和删除数据的需求，现有引擎无法满足。对于高 QPS 场景，复杂度高查询场景、 Join 等场景，查询性能不能满足需要。

（上图为引进 StarRocks 之前的 OLAP 现状）

针对上面这些问题，我们于 2022 年开始引入 StarRocks。StarRocks 是新一代全场景 MPP 数据库，使用向量化、 MP