背景
数据入湖时效性差：数据湖主要依赖于离线批量计算，通常不支持实时数据更新，因此无法保证数据的强一致性，造成数据不及时、不准确； 查询性能差：在传统架构下，数据湖的查询速度较差，小时粒度的数据查询往往需要数分钟才能得到响应，在多个业务方同时执行数据湖查询任务时，查询响应慢的劣势更加明显； 查询体验差：数据存储在多个地方，在进行联邦分析时需要将数据从数据湖中搬迁到数据仓库平台，这会增加分析链路的长度，同时导致数据的冗余存储。在进行常规查询时，需要熟练查询多种数据库，学习成本极高； 场景融合不足：数据湖单一组件，无法满足目前的海量数据处理诉求，例如在批处理和流处理等场景下的融合能力有限。
技术选型思考
在旧架构中，数据湖组件选择的是Hudi，查询层使用Hive on Spark进行查询，所有业务方的查询上层封装了Metabase，在Metabase平台上编写Hive SQL，即可通过Spark引擎执行计算，获取数据湖中的计算结果。
数据湖和数据仓库是分开的两个东西，没有办法关联查询； 业务方需要同时掌握SparkSQL和MySQL两种能力，学习成本高； SparkSQL查询效率慢，稳定性差，资源占用高； Spark引擎在跑Hive SQL时，会偶发触发BUG导致查询失败，需要手工重试才能得到结果，用户体验较差。
白山云大数据团队在寻找新的架构方案时，主要关注以下几个方面：
在数据查询方面，查询效率、查询体验要显著高于传统的Spark引擎； 在资源利用上，查询数据使用的CPU和内存要远低于传统的Spark引擎； 可拓展性高，支持动态扩缩容； 在学习成本上，传统的Hive SQL相较MySQL语句有较高门槛，如果能兼容MySQL协议来检索数据湖的查询，可以极大降低数据湖的查询门槛。
如何实现技术落地
在确定了技术选型后，接下来就要考虑如何平滑地将架构落地：
1、StarRocks 数据湖专用集群建设
用户无需再学习SparkSQL的语法，只需掌握MySQL协议即可访问两种数据源；
数据湖和数据仓库的连接更加紧密，通过StarRocks湖上物化视图的功能，数据湖的数据可以将聚合结果存入StarRocks进行物化加速；
提供了联邦分析能力，由于数据湖和数据仓库都是使用StarRocks进行查询，因此可以实现同一条语句将两种数据源的数据混合计算的联邦查询；
StarRocks在查询Hudi时不论是性能、稳定性还是资源占用方面都有很大的优化；
一些StarRocks数据仓库写入、查询压力较大的表，可以挪到数据湖中存储，然后继续通过StarRocks对外提供查询，实现业务方无感知的平滑迁移。
带来的价值
资源节约：我们有多个机房和多套Hudi集群，在全面使用StarRocks替代SparkSQL查询Hudi集群后资源消耗节省70%；
查询性能提升：在无并发场景下，查询效率提升3-8倍；在并发执行场景下，查询效率提升10倍以上；
学习成本降低：旧架构查询数据湖需要掌握HiveSQL语法，新架构只需了解MySQL语法；
湖仓一体的深入融合：在旧架构中一些无法满足的业务需求可以得到满足，例如量级无法承接的数据可以转存到数据湖中，通过StarRocks集群进行查询；
联邦分析：通过StarRocks统一数据查询引擎，可以实现跨数据源的联邦分析场景，例如一半在Hudi一半在StarRocks中聚合到一起进行联邦分析。
未来探索方向
在湖仓一体方案稳定运行后，大数据团队针对StarRocks数据库开始了新一步的探索：
统一StarRocks集群：前面提到了目前受限于配置文件问题，一个StarRocks集群只能连接一个Hudi集群。和StarRocks社区沟通后了解到，未来StarRocks 中Catalog的配置不再局限于物理机的配置文件，而是在Catalog的创建语句中动态传入，一旦这个方案上线，就可以实现一个StarRocks集群连接多个HDFS/Hudi集群，甚至可以实现跨Hudi集群的联邦查询。
存算分离探索：StarRocks 3.0正式发布了存算分离CN（Compute Node）节点，未来我们在湖仓一体的StarRocks集群中计划正式引入CN节点，在执行大查询时，快速扩容多个CN节点加速查询，在没有查询时将CN节点释放，减少资源占用。
湖上物化视图探索：StarRocks支持湖上物化视图功能，针对数据湖的数据可以做到原始数据存储在数据湖中，同时聚合结果存储在StarRocks中。当查询条件满足物化结果，可以直接将查询改写到物化视图中，实现极速查询。
更多数据源探索：StarRocks 的Catalog模块除了Hudi等数据湖组件外，在3.1版本正式接入了ES数据库。白山云大数据团队计划构建ES专用的StarRocks集群，来将StarRocks的极速查询能力赋能到更多数据库中。
