创意产品网站,雅式机械加工网,北京时事新闻,多少钱翻译背景
随着每天万亿级别的业务数据流向数据湖#xff0c;数据湖的弊端也逐渐凸显出来#xff0c;例如#xff1a;
数据入湖时效性差#xff1a;数据湖主要依赖于离线批量计算#xff0c;通常不支持实时数据更新#xff0c;因此无法保证数据的强一致性#xff0c;造成数…背景
随着每天万亿级别的业务数据流向数据湖数据湖的弊端也逐渐凸显出来例如
数据入湖时效性差数据湖主要依赖于离线批量计算通常不支持实时数据更新因此无法保证数据的强一致性造成数据不及时、不准确查询性能差在传统架构下数据湖的查询速度较差小时粒度的数据查询往往需要数分钟才能得到响应在多个业务方同时执行数据湖查询任务时查询响应慢的劣势更加明显查询体验差数据存储在多个地方在进行联邦分析时需要将数据从数据湖中搬迁到数据仓库平台这会增加分析链路的长度同时导致数据的冗余存储。在进行常规查询时需要熟练查询多种数据库学习成本极高场景融合不足数据湖单一组件无法满足目前的海量数据处理诉求例如在批处理和流处理等场景下的融合能力有限。 技术选型思考
在旧架构中数据湖组件选择的是Hudi查询层使用Hive on Spark进行查询所有业务方的查询上层封装了Metabase在Metabase平台上编写Hive SQL即可通过Spark引擎执行计算获取数据湖中的计算结果。 这个架构的缺点很明显
数据湖和数据仓库是分开的两个东西没有办法关联查询业务方需要同时掌握SparkSQL和MySQL两种能力学习成本高SparkSQL查询效率慢稳定性差资源占用高Spark引擎在跑Hive SQL时会偶发触发BUG导致查询失败需要手工重试才能得到结果用户体验较差。
白山云大数据团队在寻找新的架构方案时主要关注以下几个方面
在数据查询方面查询效率、查询体验要显著高于传统的Spark引擎在资源利用上查询数据使用的CPU和内存要远低于传统的Spark引擎可拓展性高支持动态扩缩容在学习成本上传统的Hive SQL相较MySQL语句有较高门槛如果能兼容MySQL协议来检索数据湖的查询可以极大降低数据湖的查询门槛。 基于以上需求大数据团队选择了多个数据湖相关的查询组件对性能、资源、稳定性等方面进行测试比对最终选择了StarRocks作为数据湖的查询引擎。 如何实现架构落地
在确定了技术选型后接下来就要考虑如何平滑地将架构落地
StarRocks 数据湖专用集群建设
白山云大数据团队有多个数据湖Hudi集群并且数据湖Hudi组件使用HDFS作为底层存储。StarRocks 如果要连接数据湖则需要将core-site.xml等配置文件放到conf目录并且对文件名有强依赖因此不能做到一个StarRocks集群连接多个HDFS集群。
所以在StarRocks建设时大数据团队针对每一个Hudi集群都建设了一个单独的StarRocks集群作为查询引擎。在节点选择上由于Hudi专用的StarRocks集群不存储数据因此不挂载硬盘。为了提高资源利用率并减少一些数据传输时网络IO的消耗大数据团队选择了和HDFS的Data Node节点混合部署。
新旧架构并行运行
在StarRocks集群建设完成后大数据团队基于以下考虑选择了新旧架构并行运行的方案来保障整个架构的平缓更替。
由于新旧架构并行可以使用相同的查询语句分别在新旧架构中运行从而精准得到新旧架构的性能和资源消耗对比有了充足的时间推广新架构在内部开展新架构的使用培训并在运行过程中让业务方充分感受到新架构的高性能优势自主切换到新架构中并行运行期间如果新架构发生了预期之外的问题导致故障可以快速回退到旧架构中保证了线上服务不受影响。 此时的架构如下 在运行过程中新架构的优点也集中展露
用户无需再学习SparkSQL的语法只需掌握MySQL协议即可访问两种数据源数据湖和数据仓库的连接更加紧密通过StarRocks湖上物化视图的功能数据湖的数据可以将聚合结果存入StarRocks进行物化加速提供了联邦分析能力由于数据湖和数据仓库都是使用StarRocks进行查询因此可以实现同一条语句将两种数据源的数据混合计算的联邦查询StarRocks在查询Hudi时不论是性能、稳定性还是资源占用方面都有很大的优化一些StarRocks数据仓库写入、查询压力较大的表可以挪到数据湖中存储然后继续通过StarRocks对外提供查询实现业务方无感知的平滑迁移。
我们使用相同的查询语句在不同架构中多次执行性能对比结果十分明显在环境内存资源占用上SparkSQL是StarRocks2.8倍在环境CPU利用上SparkSQL是StarRocks3.78倍对于SQL内存消耗、SQL CPU消耗时间上SparkSQL也要比StarRocks高出许多对于SQL首次执行时间StarRocks要比SparkSQL快近3倍SQL再次执行时间StarRocks的速度也要比SparkSQL快近6-8倍。 引擎 环境内存 环境CPU SQL首次执行时间 SQL再次执行时间 SQL内存消耗*时间 SQL CPU消耗*时间 并发问题 稳定性问题 物化视图 存算分离 SparkSQL 720G 242c 90s 42s-77s 32400G*s 10890core*s 单个SQL会拿走所有资源计算后续SQL排队 如果SQL故障会将Yarn任务打挂 无 无 StarRocks 256G 64c 31s 7s-10s 1742M*s 0.139core*s 支持多个SQL同时运行无需排队 耽搁故障SQL不会影响服务 支持湖上物化视图聚合结果自动落到高性能的StarRocks中 支持存算分离动态扩缩容 滚动裁撤旧架构资源
在新旧架构长达数周的并行运行后新架构的性能、稳定性、资源消耗等方面优势已经体现出来了此时开始滚动裁撤旧架构的资源让业务方只能使用StarRocks这一种查询引擎查询Hudi集群。 新数据入湖
在StarRocks作为数据湖的查询引擎得到大范围推广后下一步的操作就是进一步将湖仓一体的架构体现将其他StarRocks集群中对延迟要求低或者数据体量大的表写入数据湖。
对于业务方通过StarRocks进行数据查询的整个流程无需改变依旧使用MySQL协议查询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正式发布了存算分离CNCompute Node节点未来我们在湖仓一体的StarRocks集群中计划正式引入CN节点在执行大查询时快速扩容多个CN节点加速查询在没有查询时将CN节点释放减少资源占用。
湖上物化视图探索StarRocks支持湖上物化视图功能针对数据湖的数据可以做到原始数据存储在数据湖中同时聚合结果存储在StarRocks中。当查询条件满足物化结果可以直接将查询改写到物化视图中实现极速查询。
更多数据源探索StarRocks 的Catalog模块除了Hudi等数据湖组件外在3.1版本正式接入了ES数据库。白山云大数据团队计划构建ES专用的StarRocks集群来将StarRocks的极速查询能力赋能到更多数据库中。
