白山云科技基于StarRocks + Hudi 湖仓一体化实践分享

白山云科技基于StarRocks + Hudi 湖仓一体化实践分享

业务背景介绍

白山云的内容分发服务拥有1400+全球边缘节点，网络带宽容量60Tbps+，平台每日处理请求次数超过5000亿。
为了提升服务质量，业务人员经常需要提取这千亿级别的日志进行分析，因为日志量过于庞大，基于成本的考虑，数据不能直接进入到StarRocks中，而是流向了基于HDFS底层存储的Hudi集群。

原来的解决方案（SparkSQL）

Metabase + hudi + SparkSQL
由于SparkSQL查询有一定门槛限制，技术中台部门最初使用了Metabase图形化界面+SparkSQL引擎 + Hudi存储的架构。
业务人员有日志查询需求时，通过metabase的图形化节点，通过点击+一些下拉选择的形式，即可自动拼接出可执行的SparkSQL查询hudi集群。
弊端：
上面的架构虽然满足了业务方的查询需求，但是随着用户量的增多，发现了诸多问题：

1. 资源消耗严重，采用的是2个常驻在Yarn上的任务进行查询任务的执行，即使没有查询任务，也会长期占据大量资源。
2. 查询很慢，在多个使用方共同查询时，后续任务排队执行，导致一些很小的查询，浪费了大量的时间在排队上。
3. 稳定性较差，SparkSQL经常由于各种原因执行失败，要重试甚至人工介入才能得到正确结果。

基于StarRocks的解决方案

由于我们部门一直有用到StarRocks数据库，所以一直关注着社区的发展，在StarRocks 2.5版本发布后，StarRocks 支持了通过catalog的形式查询hudi集群，我们马上部署了一套StarRocks 2.5 环境与现有SparkSQL方案进行了对比。

引擎	环境内存	环境CPU	SQL首次执行时间	SQL再次执行时间	SQL内存消耗 * 时间	SQL CPU消耗* 时间	并发问题	稳定性问题	物化视图	存算分离
SparkSQL	720G	242core	90s	42-77s	32400G*s	10890core*s	单个SQL会拿全部资源计算，后续SQL排队	如果SQL故障，会将Yarn进行打挂	无	无
StarRocks	256G	64core	31s	7-10s	1742M*s	0.139core*s	支持多个SQL同时运行，无需排队	单个故障SQL不会影响服务	支持湖上物化视图加速查询	支持存算分离动态扩缩容
SparkSQL/StarRocks	2.8	3.78	2.9	6-8	19045	78345

测试结果非常惊艳，StarRocks在只使用了SparkSQL 1/3的资源的情况下，查询性能是SparkSQL的3-8倍。并且这一效果，在并发查询时效果更佳明显。

基于以上测试结果，我们很快使用了StarRocks的方案替代了SparkSQL的方案进行hudi查询，在架构升级完成后，由于StarRocks出色的性能，获得了业务方的一致好评。

业务收益

业务方反馈查询效率、稳定性提升显著。
在故障排查、资源调度、性能调优等多个场景下，更能满足业务方的使用需求了。
在服务器出现问题时，更快的查询意味着更早的定位到问题，从而更快的恢复服务，提升服务质量，减少客户投诉。

技术收益

我们有多个机房和多套hudi集群，在全面使用StarRocks替代SparkSQL查询hudi集群后，资源消耗节省70%，在无并发场景下，查询效率提升3-8倍，在并发执行场景下，查询效率提升10倍以上。
并且StarRocks的架构还支持湖上物化视图和存算分离动态扩缩容，为我们进一步提升查询效率夯实了基础。

踩过的坑

在StarRocks 2.5版本刚刚发布时，我就搭建了单独的集群用于hudi集群的查询，因此也踩了一些小坑。
StarRocks 在2.5的小版本对接hudi查询时发生过多次BE挂掉，FE挂掉，FE元数据丢失，部分Parquet文件查询失败问题。
在社区大佬的鼎力支持下，针对性的打了多个补丁，集群版本从2.5.1 -> 2.5.2 -> 2.5.4 -> 2.5.5 -> 2.5.6 。
最后终于在2.5.6版本更新后，集群不在发生任何查询失败及节点崩溃问题了，再次感谢社区大佬！
如果有其他小伙伴打算使用StarRocks接入hudi集群进行湖仓一体化查询，也建议选择版本为StarRocks2.5.6及以后的版本～