读数据自助服务实践指南：数据开放与洞察提效16查询优化服务

1. 查询优化服务

1.1. 好查询和坏查询之间的差别非常明显
1.2. 重复且长时间运行的查询是需要调优的
1.3. 痛点

• 1.3.1. 像Hadoop、Spark和Presto这样的查询引擎有太多的旋钮
  
  
  
  • 1.3.1.1. 对于大多数数据用户来说，理解这些旋钮的功能和影响需要深入了解查询引擎的内部工作原理
    
  
  
• 1.3.2. 鉴于数据的PB级规模，对于大多数数据用户来说，编写针对分布式数据处理最佳实践的优化查询方案极具挑战性
  
  
  
  • 1.3.2.1. 大多数查询引擎和数据存储在应用过程中都有专用查询原语，使用这些功能需要不断学习曲线，并了解越来越多的技术
    
  
  
• 1.3.3. 查询优化工作不是一次性的，而是基于执行模式持续进行的
  
  
  
  • 1.3.3.1. 查询调优是一个迭代过程，在针对低悬垂优化的最初几次迭代之后，这种优化的收益会随着迭代逐渐减少
    
  
  

1.4. 优化耗时指用户优化查询所花费的时间

• 1.4.1. 数据用户在调优方面花费的时间
  
• 1.4.2. 完成查询处理的时间
  

1.5. 在生产环境中，经过调优的查询可以更快地运行，从而显著减少洞察耗时
1.6. 理想情况下，查询优化服务应该自动优化查询，而不需要数据用户了解细节
1.7. 查询优化是一种平衡行为，既确保用户的生产效率，又考虑用户的优化耗时、运行查询所需的时间以及在多租户环境中怎样处理底层资源的分配等方面
1.8. 查询调优已成为数据团队的必备条件

• 1.8.1. 更快的执行速度和严格的SLA
  
  
  
  • 1.8.1.1. 考虑到数据量不断增长，优化查询以及时完成查询非常重要，尤其是当查询因业务原因需要在严格的时间窗口内完成时
    
  
  
• 1.8.2. 更高的资源利用率
  
  
  
  • 1.8.2.1. 能够在分布式硬件资源上进行扩展处理是关键
    
  • 1.8.2.2. 在云端运行查询时，这在节约成本方面也起到了重要作用，因为云端查询的成本可能相当高
    
  
  
• 1.8.3. 性能隔离
  
  
  
  • 1.8.3.1. 在多租户部署中，处理集群由多个团队共享，编写不当的查询可能会导致系统崩溃
    
  • 1.8.3.2. 在生产过程中，必须对影响完成时间的低效查询进行过滤
    
  
  

2. 路线图

2.1. 避免集群阻塞

• 2.1.1. 写得不好的查询会阻塞集群并影响其他生产作业
  
• 2.1.2. 问题可以在代码评审过程中被发现，特别是在生产阶段
  
  
  
  • 2.1.2.1. 代码评审并不是万无一失的，跟团队的知识专业度有关
    
  
  

2.2. 解决运行时查询问题

• 2.2.1. 现有查询可能会因内存不足（OOM）问题而停止工作，从而导致失败
  
• 2.2.2. 持续分析查询的优化服务可以帮助发现问题，并在生产中避免出现这些问题
  

2.3. 加速应用程序

• 2.3.1. 越来越多的应用程序部署在生产环境中，它们依赖于数据查询的性能
  
• 2.3.2. 工程团队目前采用的方法是每周审查生产中消耗资源最多、运行时间最长的10个查询
  
  
  
  • 2.3.2.1. 然后针对这些查询进行优化，并与数据用户合作，在需要时负责重写这些查询
    
  
  

3. 最小化优化耗时

3.1. 聚合统计数据

• 3.1.1. 基础设施级（计算、存储、网络、内存）性能
  
• 3.1.2. 操作系统运行状况
  
• 3.1.3. 来自资源管理器的容器级统计数据
  
• 3.1.4. 查询集群资源分配和利用情况
  
• 3.1.5. 文件访问
  
• 3.1.6. 管道和应用程序性能
  
• 3.1.7. 以性能计数器和日志的形式记录和维护监控细节，以便进行历史趋势分析和异常分析
  
• 3.1.8. 记录配置和数据模式中的变更管理，以帮助调试问题
  

3.2. 分析统计数据

• 3.2.1. 需要对聚合的统计数据进行分析，以确定对提高查询性能最有效的旋钮和优化的优先级
  
• 3.2.2. 对于Terasort作业，数据压缩旋钮是提高性能最有效的方法
  
• 3.2.3. 分析方法
  
  
  
  • 3.2.3.1. 查询分析
    

    3.2.3.1.1. 涉及语言结构的检查、相关表的基数检查以及索引/分区的适当使用
    

    
    
  • 3.2.3.2. 作业分析
    

    3.2.3.2.1. 涉及检查与数据配置、任务并行性、数据压缩、运行时执行阶段分析、数据处理中的偏差、映射和reduce执行器的效率等相关的统计信息
    

    
    
  • 3.2.3.3. 集群分析
    

    3.2.3.3.1. 涉及与作业调度、大小调整（硬件、缓冲池等）​、容器设置、执行内核数、利用率等相关的统计信息
    

    
    
  
  
• 3.2.4. 关键的挑战是需要专业知识将集群、作业和查询属性关联起来，以确定给定设置中重要旋钮的优先级和排名
  
• 3.2.5. 分析还包括数据模式设计，如定义正确的分区键以适当进行数据的并行处理
  

3.3. 优化作业

• 3.3.1. 优化是一个迭代的过程，决定各作业的新值具有挑战性且耗时
  
• 3.3.2. 旋钮对性能有非线性影响，需要一定的专业知识
  
• 3.3.3. 考虑到一定数据周期下的数据量是TB级的，因此迭代过程需要时间来评估查询优化的更改有效性
  

4. 定义需求

4.1. 因素

• 4.1.1. 现有的查询工作负载
  
  
  
  • 4.1.1.1. 现有的查询工作负载要考虑很多关键方面，包括生产中运行的即席查询/计划查询/事件触发的查询的百分比
    
  • 4.1.1.2. 对于计划查询和触发查询，典型频率是潜在改进的一个重要指标
    
  
  
• 4.1.2. 未优化查询的影响
  
  
  
  • 4.1.2.1. 要评估的关键指标包括未达到SLA的数量、处理集群的利用率水平、失败查询的数量、在集群上调度查询的等待时间以及查询完成时间（即完成重复查询的持续时间）的差异
    

    4.1.2.1.1. 实现查询优化服务的潜在改进的领先指标
    

    
    
  
  
• 4.1.3. 现有优化过程
  
  
  
  • 4.1.3.1. 优化查询的主动式方法与被动式方法、代码审查、了解底层系统的专业知识以及对消耗资源的查询的定期审查
    
  
  

4.2. 互操作需求

• 4.2.1. 查询优化需要与编写查询的编程语言（Python和Scala）​、后端数据存储（Cassandra、Neo4j、Druid等）​、流式处理引擎和批处理引擎（Spark、Flink和Hive）以及云端和本地部署环境（EC2和Docker）等进行互操作
  

4.3. 功能性需求

• 4.3.1. 静态查询洞察
  
  
  
  • 4.3.1.1. 基于正确的原语、表的基数和其他启发式方法提供改进查询的建议
    
  • 4.3.1.2. 理想情况下，不允许运行那些会影响集群处理的低效查询
    
  
  
• 4.3.2. 动态查询洞察
  
  
  
  • 4.3.2.1. 基于运行时分析、评测整个堆栈的单窗格，以及关于调整旋钮的建议
    
  • 4.3.2.2. 作业分析是持续的，并使用每次运行查询的统计数据
    
  
  
• 4.3.3. 自动调优查询
  
  
  
  • 4.3.3.1. 对于常见场景，可以自动对查询进行调优，而不是显示建议
    
  
  

4.4. 非功能性需求

• 4.4.1. 可解释性
  
  
  
  • 4.4.1.1. 服务应该能够理解优化服务生成建议的原因
    
  
  
• 4.4.2. 最小干扰
  
  
  
  • 4.4.2.1. 在使用自动调优时，服务应尽量减少误报，并确保不会因优化而产生其他负面影响
    
  
  
• 4.4.3. 成本优化
  
  
  
  • 4.4.3.1. 考虑到云计算中查询处理产生的巨大开销，优化服务应该能降低总成本
    
  
  

5. 实现模式

5.1. 回避模式

• 5.1.1. 防止错误查询阻塞处理集群并影响其他查询
  
• 5.1.2. 作用是防止写得不好的查询阻塞处理集群
  
• 5.1.3. 两种类型的错误
  
  
  
  • 5.1.3.1. 防止由于对数据模型和基数缺乏理解而导致的意外错误
    
  • 5.1.3.2. 防止错误使用与不同数据存储关联的查询构造和最佳实践
    
  
  
• 5.1.4. 适用于编写查询以及在提交执行之前对查询进行静态分析期间
  
• 5.1.5. 工作原理
  
  
  
  • 5.1.5.1. 在数据集中聚合元数据
    

    5.1.5.1.1. 利用元数据服务收集统计数据（基数、数据质量等）和数据类型
    

    
    
  • 5.1.5.2. 解析查询
    

    5.1.5.2.1. 将查询从原始字符串转换为抽象语法树（AST）表示
    

    
    
  • 5.1.5.3. 提供建议
    
  
  
• 5.1.6. Apache Calcite
  
  
  
  • 5.1.6.1. 为许多流行的开源数据处理系统（如Apache Hive、Storm、Flink、Druid等）提供了查询处理、优化和查询语言的支持
    
  • 5.1.6.2. 能够处理多种查询语言的查询处理器
    
  • 5.1.6.3. 一种适配器类型的体系结构，旨在扩展和支持异构数据模型和存储
    
  • 5.1.6.4. 一个模块化和可扩展的查询优化器，具有数百个内置优化规则，以及一个统一的框架，让工程师开发类似的优化逻辑和语言支持，避免浪费工程资源
    
  
  
• 5.1.7. Hue
  
  
  
  • 5.1.7.1. 通过IDE可以避免编写错误的查询
    
  • 5.1.7.2. 元数据浏览，它自动列出并过滤表和列以及基数统计信息
    
  • 5.1.7.3. 使用任何SQL方言的自动补全功能进行查询编辑，仅显示有效语法，语法突出显示关键字、可视化、查询格式化和参数化
    
  
  
• 5.1.8. 该模式的优点是节省了大量的生产调试时间，并防止了生产部署中的意外情况
  
• 5.1.9. 该模式的缺点是很难统一实施，并且通常会随团队工程文化的不同而变化
  

5.2. 操作洞察模式

• 5.2.1. 提供查询运行时的分析统计数据洞察
  
• 5.2.2. 操作洞察范围从用于监控整个堆栈的单个玻璃面板到关于旋钮的建议
  
• 5.2.3. 侧重于分析从技术栈的多个层收集的指标，并为数据用户提供一组丰富的可操作的洞察
  
  
  
  • 5.2.3.1. 将数百个指标关联起来以提供可操作的洞察
    
  
  
• 5.2.4. 该模式是收集的统计数据上相关模型的集合，用于建议调整旋钮值
  
• 5.2.5. 通过分析两个时间段之间的集群活动、聚合集群工作负载、集群使用情况的总结报告、退款报告等来关联集群利用率
  
• 5.2.6. 工作原理
  
  
  
  • 5.2.6.1. 收集统计数据
    

    5.2.6.1.1. 从大数据栈的所有层获取统计数据和计数器
    

    
    
  • 5.2.6.2. 关联统计信息
    

    5.2.6.2.1. 将堆栈中的统计信息关联起来，为管道创建一个E2E视图
    

    
    
  • 5.2.6.3. 应用启发式方法
    

    5.2.6.3.1. 一旦所有的统计信息被聚合，它就会运行一组启发式算法，以生成关于单个启发式方法和作业整体表现的诊断报告
    

    
    
  
  
• 5.2.7. Sparklens
  
  
  
  • 5.2.7.1. 针对Spark应用程序的分析工具，用于分析应用程序使用提供给它的计算资源的效率
    
  
  
• 5.2.8. Dr. Elephant
  
  
  
  • 5.2.8.1. Spark和Hadoop的性能监控和调优工具
    
  • 5.2.8.2. 自动收集作业的指标并进行分析，以一种简单的方式呈现出来以便于使用
    
  • 5.2.8.3. 目标是通过更容易地调整作业来提高开发人员的生产力并提升集群效率
    
  
  

5.3. 自动调优模式

• 5.3.1. 采取措施自动调优作业的旋钮值
  
• 5.3.2. 目标是开发一个优化器，自动调优操作来提高查询的性能
  
  
  
  • 5.3.2.1. 类似于自动驾驶汽车，操作不需要数据用户的干预
    
  
  
• 5.3.3. 自动调优考虑了整个技术栈的配置和统计信息
  
• 5.3.4. 优化器将当前旋钮值、当前统计数据和性能目标作为输入
  
• 5.3.5. 优化器对不同旋钮值的预期性能结果进行建模，以确定最佳值
  
• 5.3.6. 自动调优模式的优点是提高了生产力，因为它能帮助对系统内部了解很少或根本不了解的数据用户提高查询性能
  
• 5.3.7. 缺点是不正确的调优有可能造成负面影响或导致生产中断
  
• 5.3.8. 部署机器学习模型需要大量的训练
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！