作者
马蜂窝大数据部门从 2021 年开始引入 StarRocks,OLAP 场景的查询性能提升 4 倍左右,无论是灵活查询还是固化查询都有超出预期的表现。在马蜂窝大数据部门的未来规划中,StarRocks 会支撑更多分析场景,实现 OLAP 引擎上的统一,在提升数据分析效率的同时降低多引擎的维护成本。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
如图 1 所示,马蜂窝大数据分析整体架构基本可以分为 4 层:存储层 、计算层、分析层、应用层。其中应用层覆盖了 OLAP 应用场景,包括 OLAP 多维分析、AdHoc 查询、明细数据钻取、自助报表、数据大盘(固化报表) 等。为了满足图中业务层多种查数看数的需求,在分析层架构上我们通过引进多种查询引擎,结合不同引擎的特性,去更高效的支持某一场景。
在离线 OLAP 场景下,为了支持灵活高效的数据探索需求,即 AdHoc 即席查询场景和 BI 自助报表场景,我们选择了 Presto 查询引擎作为底层支撑;多维分析场景和固化 BI 报表场景下,选用了 Apache Kylin(下文统一简称“Kylin”) 引擎;实时数据分析场景下,使用 Apache Druid (下文统一简称“Druid”)作支撑。Apache Hive(下文统一简称“Hive”)除了承担在计算层的数据 ETL 工作外,也作为分析层其他引擎发生故障后的最终兜底引擎。
图 2 为目前分析层不同分析引擎承载的查询请求的占比统计,其中 Kylin 的比重最大(来自数据银行及多维查询),有将近 80% 的日常查询是由 Kylin 承载。在设计上,查询路由根据元数据系统提供的指标上下文,可以判断指标模型是否配置了 Kylin 引擎,是的话尽可能优先下推到 Kylin 执行。我们希望 Kylin 在预计算后可以更快的返回查询结果,有更低的时延。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
Kylin 的局限性
早期引进 Kylin 完美支撑了马蜂窝固化多维查询的场景。随着业务场景和需求的丰富,需要平台提供更加灵活的 OLAP 分析能力,显然这不是 Kylin 擅长的范围(非固化查询条件),局限性体现在:
3. 由于业务场景涉及的维度比较多,常常一个 Cube 会有几十个维度、不同维度的组合,会导致 Cube 膨胀,占用过多存储资源。
多分析引擎共存,维护和使用成本高
多套分析引擎的存在,出现了数据同时写到多个地方的情况,因此在数据生产过程中需要保证相同指标数据下不同引擎的数据一致、口径一致,增加了数据链路建设的复杂度和数据开发的成本。
为了解决上面提到的痛点,我们积极探索寻求解决方案,开始对包括 StarRocks 在内的多个业界主流 OLAP 产品进行选型分析。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
从图 3 的对比可以看出,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 查询平均耗时大幅下降,高效且稳定。
图 4
多表关联查询优化
在马蜂窝的交易场景中,Kylin Cube 模型共有 60 多个维度,为了减少 Cube 膨胀,衍生维度占了一半。这些维度每次查询都要用到,需要 Kylin 进行后聚合。随着数据量的增长,查询效率低下,我们针对这种场景使用 StarRocks 进行优化。
事实表使用 StarRocks 聚合模型,多个维表使用明细模型。同时 StarRocks 事实表聚合模型的Sort Key 与 Kylin Cube 的 Rowkey 保持一致。经过优化,StarRocks 多表关联查询平均耗时大幅降低。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
图 5
精准去重下的用户行为分析优化
针对 7 日内设备留存场景,目前在 Kylin 中通过预计算的方式基于 Bitmap 进行精确去重。同时,因为去重列为 String 类型,所以在 Kylin 中配置 Cube 添加度量,设计精确去重 Count Distinct 字段并配置全局字典。Presto 基于数据明细现场计算的方式通过表的自关联 Join 进行留存分析。StarRocks 将明细数据经由 Spark Load ,写入带有 Bitmap 类型字段的聚合模型。通过对比发现,基于 StarRocks 的方案,性能得到大幅提升,到达 1s 以内。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
统一元数据管理
目前平台维护和使用众多存储引擎,包括 Hive、HBase、Apache Kafka(下文统一简称“Kafka”)等。这些组件都统一由元数据系统进行管理和信息维护,包括表的归属方、生命周期管理等,因此需要将 StarRocks 的元数据信息纳入到平台中进行适配。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
Hive to StarRocks 建设
平台可以自定义选择同步字段、类型转换,并且支持目标数据源在同步之前在原数据的基础上,做预处理 ETL 和 StarRocks 目标端的预处理。最后程序会根据用户提交的上下文生成 Broker Load 任务,定时调度执行,将数据导入到 StarRocks。
StarRocks 运维管理和监控体系建设
-
StarRocks 系统监控
-
审计日志分析
目前我们是通过 FileBeat 去采集 FE 上的审计日志信息,然后将数据回落到 StarRocks,形成结构化的日志明细和实时监控指标。数据使用包括如下:
1. 通过监控慢 SQL 明细日志并结合 Profile 上报,从优化角度诊断分析慢 SQL。
2. SQL 审计面板,通过 FE 的 SQL 审计日志,统计历史查询耗时情况,常用的查询指标包括 P95 耗时、P99 耗时、异常查询走势等。
应用现状与收益
目前马蜂窝已经将大部分之前 Kylin Cube 模型迁移到了 StarRocks,并且从架构上将上层应用的查询入口由 Kylin 切换到 StarRocks,目前 StarRocks 承载数据分析应用中 93% 的查询流量。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
1. 查询极速体验:引入 StarRocks 后,根据官方文档给出的模型和参数优化建议,对比之前线上的长耗时查询,性能有了很明显的提升。在新架构下,近 7 日查询 P95 分位耗时稳定在 5s 左右,较之前查询性能提升了近 4 倍。
![马蜂窝×StarRocks:OLAP 架构升级,开启极速统一新旅程](https://lrting.top/wp-content/themes/justnews/themer/assets/images/lazy.png)
2. 运维成本降低:Kylin 对 Apache Hadoop 生态组件有很强的依赖,架构比较复杂,维护链路过长,排查问题难度较大。迁移到 StarRocks 后,由于 StarRocks 组件依赖较少且运维操作简单,大大降低了之前的维护成本。
3. 数据存储空间降低:Kylin 存算分离架构下 Hbase 存储为 400T,迁移到 StarRocks 后存储占用降低到了 50T 左右,极大降低了存储成本。
4. 数仓开发成本降低:之前数仓建模过程需要在 Kylin 进行复杂配置,例如设置维度 Rowkey 的顺序,切换到 StarRocks 后简化了建模的流程,大大提升了开发效率,并且在建模时不再受限于 Kylin 的宽表模型,模型使用上,更加灵活,维度变更也不需要重刷历史。
在近半年的使用过程中,StarRocks 在稳定性和查询性能上表现很好,性能提升 4 倍左右,大幅改善了 OLAP 查询速度,并且在查询灵活性、可维护性、易用性方面也有很好的使用体验。
在后续规划中,一方面 StarRocks 会去承载更多的业务场景,另一方面希望通过构建统一的 OLAP 查询引擎体系,减少目前 OLAP 场景多套技术栈带来的维护成本,具体计划如下:
1. 为了避免不同租户间的资源争抢,按业务及使用场景拆分多套集群,并持续关注 StarRocks 后续版本的资源隔离特性。
2. 调研通过 StarRocks 外部表的方式接入数据,以降低目前数据导入和加工过程的链路成本;同时考虑与 AdHoc 平台进行整合,将原本 Presto 查询 Hive 的场景迁移到 StarRocks 上,在即席查询场景有更好的查询体验。
3. 推广更多业务场景使用,尝试让 StarRocks 承接现有基于 Druid 实时 OLAP 架构无法覆盖到的需求,例如在某些精细化运营场景,用户既要查询聚合指标又要探查明细;广告业务尝试使用 StarRocks,提升数据分析能力。
最后要特别感谢 StarRocks 社区的大力支持,在 StarRocks 升级、场景优化、问题追踪等方面给了很多建议和帮助,后面我们会持续跟社区保持密切交流,积极参与社区共建。
关于 StarRocks
StarRocks成立两年多来,一直专注打造世界顶级的新一代极速全场景 MPP 数据库,帮助企业建立“极速统一”的数据分析新范式,助力企业全面数字化经营。
当前已经帮助腾讯、携程、顺丰、Airbnb 、滴滴、京东、众安保险等超过 110 家大型用户构建了全新的数据分析能力,生产环境中稳定运行的 StarRocks 服务器数目达数千台。
本文转载自毕博 StarRocks,原文链接:https://mp.weixin.qq.com/s/yzwig6Fv8QiNsY6ARDxgvA。