上海品茶

您的当前位置:上海品茶 > 报告分类 > PDF报告下载

1-2 基于历史查询的 Impala 集群性能优化实践.pdf

编号:102386 PDF 36页 5.18MB 下载积分:VIP专享
下载报告请您先登录!

1-2 基于历史查询的 Impala 集群性能优化实践.pdf

1、基于历史查询的IMPALA集群性能优化实践温正湖 网易数帆-数仓技术负责人|01高性能数仓建设高性能数仓建设介绍网易大数据及高性能数仓建设方案03HBO优化实践优化实践介绍HBO在网易云音乐等业务场景使用实践02HBO实现方案实现方案介绍管理服务器实现和基于历史查询的集群优化04未来发展计划未来发展计划介绍未来一段时间Impala和产品化的开发计划目录目录 CONTENT|关于网易数帆 网易数帆源自网易杭州研究院,是网易数字经济的创新载体和技术孵化器,致力于成为领先的数字化转型技术与服务提供商,为企业数字化转型提供技术动力。依托网易集团二十余年互联网技术积累,网易数帆聚合云计算、大数据、人工智

2、能等新型数字化技术,聚焦提供开放、稳定、安全、高效的数据智能、软件研发、基础设施与中间件等基础软件,致力于帮助企业客户成功实现数字化转型。云原生软件生产力平台云原生软件生产力平台全链路大数据生产力平台全链路大数据生产力平台多媒体智能开放平台多媒体智能开放平台全维度质量效能平台全维度质量效能平台网易数帆:网易旗下数字化转型技术与服务提供商网易数帆:网易旗下数字化转型技术与服务提供商网易有数网易有数华夏银行音乐电商教育传媒办公邮箱物流农业零售金融教育能源工具产品平台公共数据建设数据建设方法论制造医药记忆科技网易有数-Impala的定位交互式查询:Impala批处理引擎:Spark+Kyuubi流计

3、算引擎:Flink/Sloth网易有数-Impala主要应用场景高性能数仓建设高性能数仓建设01|业务使用痛点分析|BI报表、Ad-Hoc、自助分析、取数和数据抽取共存时的SLA保障BI报表类业务追求实时性要求高,用户耐受程度不超过5秒查询的资源消耗预估不准确,执行计划不合理,如大表广播等元数据过旧导致查询出错,元数据未缓存导致查询性能下降HDFS NN波动导致文件句柄打开性能,DN波动导致数据扫描耗时变长随着业务的发展和新场景的引入,集群的SLA和性能变差,需反复治理高性能数仓-建设原则|收集和持久化impala历史查询信息,制作标准化图表进行可视化展示 多维度分析查询规律并进行基于历史查询

4、的优化HBO(History-based Optimization)更高的性能,更强的功能:版本升级、执行引擎增强、物化视图、虚拟数仓、数据缓存等 更好的产品化体验:元数据同步、集群管理自动化、集群信息可视化和可获得性等高性能数仓-建设原则|为有数BI报告的“数据医生”功能提供性能诊断数据 有数BI等组件通过SQL注解,反哺Impala进行更智能的查询分析 将物化视图能力集成到有数产品上 订阅和消费大数据血缘的数据产出消息,驱动统计信息计算、物化视图更新等 订阅和消费Hive Metastore(HMS)的DDL日志,驱动元数据同步、物化视图更新等 依托网易大数据NDH(Netease Dat

5、a Hub)进行存储优化,Z-Order、Page Index等高性能数仓-业务痛点解决方案|引入虚拟数仓虚拟数仓(virtual warehouse)对业务进行物理资源隔离 提供基于zookeeper namespace和基于query option的虚拟数仓路由 通过impalad多group name和coordinator多zk namespace来提高资源利用效率增强本地缓存本地缓存能力 优化DataCache性能和使用范围:LIRS算法、异步CacheFill、重启可用等 调优和扩大FileHandleCache来提高文件句柄缓存命中率提供统计信息自动计算统计信息自动计算能力 通过

6、分析历史查询summary日志输出待计算的表到配置可动态更新的白名单 通过数据产出消息、定时和DDL日志驱动统计信息计算高性能数仓-业务痛点解决方案|提升计算能力,使用预计算技术 升级Impala版本,提高性能基线 通过MT-DOP,服务器多节点部署提高计算资源利用效率 通过支持多表物化视图多表物化视图和透明改写技术提升查询性能支持缓存自动更新和异步加载 通过订阅HMS的DDL变更日志,高效驱动元数据缓存自动同步元数据缓存自动同步 通过配置动态白名单,对失效的缓存进行异步加载异步加载建立Impala集群标准化报表 统计集群每天的负载指标负载指标,包括查询量、耗时、资源消耗等 使用可视化报表(有

7、数BI产品)进行直观展示直观展示 多维度分析负载指标的随时间变化趋势变化趋势并作出相应决策HBO实现方案实现方案02|HBO信息来源-Impala管理服务器|1.1开启enable_manager参数的coordinator会向statestore的topic注册查询的hostname,query_id2.2manager从statestore的topic上获取注册的hostname,query_id3.3,4manager根据hostname向对应的coordinator发送http请求制定query_id的查询信息并保存到mysql中4.manager提供webui用于展示整个集群的查询情

8、况5.5manager异步解析profile、SQL注解等查询信息用于支撑HBO历史查询信息解析|新增查询的排队耗时、内存实际消耗、内存估算值、扫描的数据量等信息 结构化保存profile、timeline和summary中的信息历史查询信息解析|新增查询的排队耗时、内存实际消耗、内存估算值、扫描的数据量等信息 结构化保存profile、timeline和summary中的信息历史查询信息解析|新增查询的排队耗时、内存实际消耗、内存估算值、扫描的数据量等信息 结构化保存profile、timeline和summary中的信息历史查询信息解析|新增查询的排队耗时、内存实际消耗、内存估算值、扫描的

9、数据量等信息 结构化保存profile、timeline和summary中的信息历史查询信息解析|-By YouData(apiName:tableQuery)(userId:9349)(resourceId:c-1--kyqxpkt3)(timestamp:42)(isEdit:false)(trigger:User)(mvName:calcite_youdata21204_1653641141)(dataModelId:21204)(relatedResourceId:36080)(transId:nDTR74vZjm97Apa5WKzRd2)

10、-By UnciaDB(rewroteByMaterialization:calcite_youdata21204_1653641141,checkTime:3 ms,metadataLoadTime:7 ms,rewriteTime:25 ms)-By UnciaDB(HBOMemOpt:-1691677264,optimizeTime:1 ms,HBOEst:429.53 MB,HBOCoordEst:0.0 B)-By UnciaDB(table clipping optimization:0 ms)YouData为BI注解,UnciaDB为内部注解挖掘历史查询规律|按分钟粒度分析集群查

11、询次数、性能、内存和IO消耗等 识别集群繁忙和空闲规律,进行资源分时调度 分析队列的查询次数、排队情况和排队耗时 统计集群的查询耗时、查询成功率等指标挖掘历史查询规律|按分钟粒度分析集群的查询次数、性能、内存和IO消耗等 识别集群繁忙和空闲规律,进行资源分时调度 分析队列的查询次数、排队情况和排队耗时 统计集群的查询耗时、查询成功率等指标挖掘历史查询规律|按分钟粒度分析集群查询次数、性能、内存和IO消耗等 识别集群繁忙和空闲规律,进行资源分时调度 分析队列的查询次数、排队情况和排队耗时 统计集群的查询耗时、查询成功率等指标挖掘历史查询规律|挖掘同类型的SQL,关注次数、耗时和资源消耗 可为SQ

12、L模板创建物化视图和进行内存预估优化 通过解析SQL获取扫描次数TopN的热表及其分区 可作为DataCache缓存和元数据异步加载的白名单HBO优化实践优化实践03|基于HBO的本地缓存优化|表元数据缓存 表定义、分区信息、文件列表和统计信息等 远端:Hive Metastore 本地:Catalogd-CoordinatorHDFS文件缓存 文件句柄、文件块数据 远端:HDFS NameNode,DataNode 本地:Impalad FileHandle Cache,DataCache存在的问题存在的问题 元数据过旧导致查询错误 元数据未缓存导致性能变差 Impala DataCache

13、成熟度不够(3.4版本):重启失效,Miss代价大,可观测性差基于HBO的本地缓存优化|表元数据缓存 支持元数据自动同步(invalidate/refresh)过滤无效表、合并同类DDL、暴露同步进度 通过SQL注解收集指定查询涉及的表信息 通过动态白名单驱动表元数据异步加载DataCache增强 独立配置Footer Cache CacheMiss异步Fill Cache元数据持久化 服务器多节点部署场景优化 backport 4.0新特性(LIRS、Metrics等)通过SQL注解收集指定查询的热表/分区 通过动态白名单及时更新需要缓存的表/分区在网易云音乐自助取数场景下,使用本地缓存等优

14、化措施后,10秒内查询占总查询比例从65%提升到91%,提升超过25%基于HBO的多表物化视图|预计算是OLAP产品的传统性能加速手段(MOLAP)BI报表场景:SQL批量下发、对性能要求较高 查询规律性强、重复率高、T+1类型多1.生命周期管理生命周期管理:纯自研,以独立服务形式部署,元数据存mysql 通过数据产出消息、DDL变更日志和文件变更驱动更新2.SQL透明改写透明改写:基于Calcite物化视图实现,辅以二次开发 SQL-calcite AST-rewrite-back to SQL-impala AST 作为jar包集成到coordinator的FE端,拦截SQL请求 优化SQ

15、L匹配和改写效率 添加outer join、group by、limit等算子和各种UDF支持基于HBO的多表物化视图|1.获取优化对象:通过有数BI的报表历史查看记录 通过解析有数BI的SQL注解获取 不同粒度:慢图表、慢报告、慢模型2.创建物化视图:模型物化视图:基于查询所涉及数据分区范围+涉及字段 图表物化视图:非分区筛选器或聚合类图表基于HBO的多表物化视图|3.命中及效果评估:通过通过coordinator metrics 通过分析通过分析SQL注解注解 通过BI统计报表 通过有数BI数据医生-By UnciaDB(rewroteByMaterialization:calcite_y

16、oudata21204_1653641141,checkTime:3 ms,metadataLoadTime:7 ms,rewriteTime:25 ms)基于HBO的多表物化视图|3.命中及效果评估:通过coordinator metrics 通过分析SQL注解 通过通过BI统计报表统计报表 通过有数通过有数BI数据医生数据医生基于HBO的内存预估优化|提取SQL模板,分析内存预估值和实际值 选择偏差大的模板作为优化规则 计算用户查询的SQL模板并进行规则匹配 统计信息缺失、粒度不够细、维度不丰富 预估过大,导致内存实际利用率低 因可用内存不足导致查询排队虚拟数仓与资源动态调配|灵活高效的数

17、仓形态灵活高效的数仓形态 虚拟数仓位于同一个Impala集群,共用一份元数据 形态1:基于zookeeper namespace(主流)形态2:基于session的查询参数(类似snowflake)混合分组和负载均衡混合分组和负载均衡 解决物理资源隔离带来的资源利用率不高问题 混合分组模式:一个executor属于多个虚拟数仓 虚拟数仓多入口:coordinator分时多zookeeper地址 基于executor负载的分布式执行计划未来发展计划04|未来计划|已完成自研特性合并 添加hive 2.x版本支持 推进上线中 支持更多SQL语法和算子 提高物化视图创建的自动化程度 与有数BI产品进一步融合 进一步提升HBO内存估算能力 支持更多场景的查询透明重试 支持向量化执行模式 支持通过K8S进行Impala集群部署 资源动态调度和负载均衡 集群健康状态诊断系统非常感谢您的观看|

友情提示

1、下载报告失败解决办法
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站报告下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。

本文(1-2 基于历史查询的 Impala 集群性能优化实践.pdf)为本站 (云闲) 主动上传,三个皮匠报告文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三个皮匠报告文库(点击联系客服),我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。
会员购买
客服

专属顾问

商务合作

机构入驻、侵权投诉、商务合作

服务号

三个皮匠报告官方公众号

回到顶部