作者：毕博，马蜂窝大数据平台专家
马蜂窝旅游网是中国领先的旅行玩乐平台，创立于 2006 年，从 2010 年正式开始公司化运营，十年来在旅游 UGC 内容领域累积了大量内容。马蜂窝是旅游社交网站，是数据趋动平台，也是新型旅游电商，提供全球 6 万个旅游目的地的交通、酒店、景点、餐饮、购物、当地玩乐等信息内容和产品预订服务。
马蜂窝大数据部门从 2021 年开始引入 StarRocks，OLAP 场景的查询性能提升 4 倍左右，无论是灵活查询还是固化查询都有超出预期的表现。在马蜂窝大数据部门的未来规划中，StarRocks 会支撑更多分析场景，实现 OLAP 引擎上的统一，在提升数据分析效率的同时降低多引擎的维护成本。
OLAP 场景的现状
如上图所示，马蜂窝大数据分析整体架构基本可以分为 4 层：存储层 、计算层、分析层、应用层。其中应用层覆盖了 OLAP 应用场景，包括 OLAP 多维分析、AdHoc 查询、明细数据钻取、自助报表、数据大盘(固化报表) 等。为了满足图中业务层多种查数看数的需求，在分析层架构上我们通过引进多种查询引擎，结合不同引擎的特性，去更高效的支持某一场景。
在离线 OLAP 场景下，为了支持灵活高效的数据探索需求，即 AdHoc 即席查询场景和 BI 自助报表场景，我们选择了 Presto 查询引擎作为底层支撑；多维分析场景和固化 BI 报表场景下，选用了 Apache Kylin（下文统一简称“Kylin”） 引擎；实时数据分析场景下，使用 Apache Druid （下文统一简称“Druid”）作支撑。Apache Hive（下文统一简称“Hive”）除了承担在计算层的数据 ETL 工作外，也作为分析层其他引擎发生故障后的最终兜底引擎。
下图为目前分析层不同分析引擎承载的查询请求的占比统计，其中 Kylin 的比重最大（来自数据银行及多维查询），有将近 80% 的日常查询是由 Kylin 承载。在设计上，查询路由根据元数据系统提供的指标上下文，可以判断指标模型是否配置了 Kylin 引擎，是的话尽可能优先下推到 Kylin 执行。我们希望 Kylin 在预计算后可以更快的返回查询结果，有更低的时延。
这个架构在前期运行良好，但随着公司业务不断发展，数据体量和用户的查询需求逐渐增多，一些问题也随之出现。
Kylin 的局限性
早期引进 Kylin 完美支撑了马蜂窝固化多维查询的场景。随着业务场景和需求的丰富，需要平台提供更加灵活的 OLAP 分析能力，显然这不是 Kylin 擅长的范围（非固化查询条件），局限性体现在：
-
Kylin 依赖预计算，当数据源发生变化时需要重新计算，无法自动同步更新。统计维度发生变化时，需要重新计算历史数据，耗费大量的计算资源和人力成本，并且指标在重算窗口期内不可查询，影响业务使用。
-
查询性能不稳定，目前马蜂窝使用的是 Kylin v3.1.2 ，底层使用 Apache HBase （下文统一简称“HBase”）作为数据存储。在新的需求下，查询条件的组合关系更为灵活复杂，常常不能命中 Kylin HBase 的前缀索引，导致查询性能会比较低下，甚至会出现全表 Scan。即便命中索引，查询维度在 Rowkey 中顺序不同 ，也会导致查询的时延有着很大波动。
-
由于业务场景涉及的维度比较多，常常一个 Cube 会有几十个维度、不同维度的组合，会导致 Cube 膨胀，占用过多存储资源。
多分析引擎共存，维护和使用成本高
为了满足不同场景下的查询需求，我们引入了不同的引擎。虽然支持了业务需求但也带来了更高的使用成本，一方面增加了这么多组件，集群需要平台运维方花费更多的精力去维护，另一方面不同引擎的 SQL 语法存在差异，增加了用户学习和查询服务适配的成本。多套分析引擎的存在，出现了数据同时写到多个地方的情况，因此在数据生产过程中需要保证相同指标数据下不同引擎的数据一致、口径一致，增加了数据链路建设的复杂度和数据开发的成本。
StarRocks 的引入
为了解决上面提到的痛点，我们积极探索寻求解决方案，开始对包括 StarRocks 在内的多个业界主流 OLAP 产品进行选型分析。
从上图的对比可以看出，StarRocks 和 ClickHouse 都能支持固化查询、灵活查询等分析场景，但是 ClickHouse 多表 Join 支持不好，在线扩缩容复杂，运维成本较高。相较而言，StarRocks 对数据查询灵活性和 SQL 复杂度高的场景支持很好，并且运维简单，兼容 MySQL 协议，易用性高，具备 OLAP 业务场景下统一技术解决方案的能力。
除了上面介绍的优势特点及适用场景，更重要的是 StarRocks 具有解决马蜂窝当前 OLAP 场景痛点的能力。我们希望引入新的引擎来支持 OLAP 灵活查询的场景，在查询维度条件命中索引时性能强悍，在未命中查询索引时，通过引擎现算也有较好表现。为了验证选型结论，我们对当前 OLAP 场景中的一些典型查询，使用 StarRocks 进行了尝试，取得了比较明显的效果。
单表聚合查询优化
对于多聚合指标的复杂 SQL，目前 Kylin 上卷查询性能不稳定，Presto 通过现场计算方式查询性能较差，使用 StarRocks 对这种查询进行优化：StarRocks 基于聚合模型设计，表定义与 Kylin Cube 事实表定义相同，同时 StarRocks 聚合模型的 Sort Key 与 Kylin Cube Rowkey 保持一致。经过优化，通过 StarRocks 查询平均耗时大幅下降，高效且稳定。
多表关联查询优化
在马蜂窝的交易场景中，Kylin Cube 模型共有 60 多个维度，为了减少 Cube 膨胀，衍生维度占了一半。这些维度每次查询都要用到，需要 Kylin 进行后聚合。随着数据量的增长，查询效率低下，我们针对这种场景使用 StarRocks 进行优化。
事实表使用 StarRocks 聚合模型，多个维表使用明细模型。同时 StarRocks 事实表聚合模型的Sort Key 与 Kylin Cube 的 Rowkey 保持一致。经过优化，StarRocks 多表关联查询平均耗时大幅降低。
精准去重下的用户行为分析优化
精准去重在用户行为分析很多场景都有使用，如分析访问 APP ⾸⻚的 1-7 ⽇内留存、漏斗等。这类需求都涉及对高基数列的精确去重计算，并且用户实际查询维度组合非常灵活。
针对 7 日内设备留存场景，目前在 Kylin 中通过预计算的方式基于 Bitmap 进行精确去重。同时，因为去重列为 String 类型，所以在 Kylin 中配置 Cube 添加度量，设计精确去重 Count Distinct 字段并配置全局字典。Presto 基于数据明细现场计算的方式通过表的自关联 Join 进行留存分析。StarRocks 将明细数据经由 Spark Load ，写入带有 Bitmap 类型字段的聚合模型。通过对比发现，基于 StarRocks 的方案，性能得到大幅提升，到达 1s 以内。
从以上真实业务场景的实际优化效果来看，StarRocks 各个方面的性能都有压倒性优势。综上，我们最终选择了 StarRocks，并且相信 StarRocks 最终能够成为马蜂窝 OLAP 平台的统一技术解决方案。
StarRocks 与马蜂窝大数据体系架构的整合
为了方便数据的管理和使用，马蜂窝数据中台建设了一整套完整的大数据产品体系。因此在引入 StarRocks 的同时，我们也做了一些将 StarRocks 与目前数据应用整合打通的工作。
统一元数据管理
目前平台维护和使用众多存储引擎，包括 Hive、HBase、Apache Kafka（下文统一简称“Kafka”）等。这些组件都统一由元数据系统进行管理和信息维护，包括表的归属方、生命周期管理等，因此需要将 StarRocks 的元数据信息纳入到平台中进行适配。
元数据系统除了上面提到的表元数据外，还包括指标元数据管理，指标元数据管理记录具体的物理存储来源，说明指标的数据来源是 Hive，或者是 Kylin、MySQL 、ES，以及新引入的 StarRocks。同一指标可以有不同引擎加工，在查询服务路由时，会通过智能路由策略选择当前最优引擎执行。
Hive to StarRocks 建设
之前平台为了提高数据加工效率，开发了不同数据源之间的数据同步平台，支持 Hive、MySQL、ES 的相互导入，当前也增加了 Hive to StarRocks 的同步方式，支持从 Hive 表通过 Broker Load 的方式导入到 StarRocks。
平台可以自定义选择同步字段、类型转换，并且支持目标数据源在同步之前在原数据的基础上，做预处理 ETL 和 StarRocks 目标端的预处理。最后程序会根据用户提交的上下文生成 Broker Load 任务，定时调度执行，将数据导入到 StarRocks。
StarRocks 运维管理和监控体系建设
关于 StarRocks 的运维，我们比较关注 BE CPU 使用过高导致该时段有大量查询超时的问题。主要原因是，在将 Kylin 历史模型迁移到 StarRocks 的过程，每天都会有大量的 Broker Load 任务，并且还要支撑在线查询，造成 CPU 和 IO 的资源吃紧。目前马蜂窝使用的 StarRocks 版本是 1.19.5，不支持资源隔离，我们的做法是 Load 任务尽量放到闲时，与在线查询错峰。同时，在监控告警方面也做了一些工作：
-
StarRocks 系统监控
基于 Prometheus + Grafana 的可视化监控方案，监控集群核心指标，如 BE 节点的 CPU 使用率，一旦超过设定的阈值，就进行告警，帮助运维同学及时发现问题。 -
审计日志分析
目前我们是通过 FileBeat 去采集 FE 上的审计日志信息，然后将数据回落到 StarRocks，形成结构化的日志明细和实时监控指标。数据使用包括如下：
-
通过监控慢 SQL 明细日志并结合 Profile 上报，从优化角度诊断分析慢 SQL。
-
SQL 审计面板，通过 FE 的 SQL 审计日志，统计历史查询耗时情况，常用的查询指标包括 P95 耗时、P99 耗时、异常查询走势等。
应用现状与收益
目前马蜂窝已经将大部分之前 Kylin Cube 模型迁移到了 StarRocks，并且从架构上将上层应用的查询入口由 Kylin 切换到 StarRocks，目前 StarRocks 承载数据分析应用中 93% 的查询流量。
经过上线后近半年的使用和观察， StarRocks 带来了极好的性能，非常契合马蜂窝的 OLAP 使用场景，带来收益如下：
1. 查询极速体验：
引入 StarRocks 后，根据官方文档给出的模型和参数优化建议，对比之前线上的长耗时查询，性能有了很明显的提升。在新架构下，近 7 日查询 P95 分位耗时稳定在 5s 左右，较之前查询性能提升了近 4 倍。
2. 运维成本降低： Kylin 对 Apache Hadoop 生态组件有很强的依赖，架构比较复杂，维护链路过长，排查问题难度较大。迁移到 StarRocks 后，由于 StarRocks 组件依赖较少且运维操作简单，大大降低了之前的维护成本。
3. 数据存储空间降低： Kylin 存算分离架构下 Hbase 存储为 400T，迁移到 StarRocks 后存储占用降低到了 50T 左右，极大降低了存储成本。
4. 数仓开发成本降低： 之前数仓建模过程需要在 Kylin 进行复杂配置，例如设置维度 Rowkey 的顺序，切换到 StarRocks 后简化了建模的流程，大大提升了开发效率，并且在建模时不再受限于 Kylin 的宽表模型，模型使用上，更加灵活，维度变更也不需要重刷历史。
总结与规划
在近半年的使用过程中，StarRocks 在稳定性和查询性能上表现很好，性能提升 4 倍左右，大幅改善了 OLAP 查询速度，并且在查询灵活性、可维护性、易用性方面也有很好的使用体验。
在后续规划中，一方面 StarRocks 会去承载更多的业务场景，另一方面希望通过构建统一的 OLAP 查询引擎体系，减少目前 OLAP 场景多套技术栈带来的维护成本，具体计划如下：
-
为了避免不同租户间的资源争抢，按业务及使用场景拆分多套集群，并持续关注 StarRocks 后续版本的资源隔离特性。
-
调研通过 StarRocks 外部表的方式接入数据，以降低目前数据导入和加工过程的链路成本；同时考虑与 AdHoc 平台进行整合，将原本 Presto 查询 Hive 的场景迁移到 StarRocks 上，在即席查询场景有更好的查询体验。
-
推广更多业务场景使用，尝试让 StarRocks 承接现有基于 Druid 实时 OLAP 架构无法覆盖到的需求，例如在某些精细化运营场景，用户既要查询聚合指标又要探查明细；广告业务尝试使用 StarRocks，提升数据分析能力。