本文主要总结了大规模报告稳定性保证方法与实践结合。
随着数据管理思维的逐步深度，无论是内部用户还是外部商业客户，越来越多的人大规模使用多个bis。以严格的选择为例，每天都有5W+报告。这些报告涵盖了几乎所有业务领域，例如用户，商品，渠道，交通，营销，仓储，供应商，金融等。辅助业务决策...并在日常工作中发挥重要作用。性质保证带来了巨大的挑战。
报告的稳定性保证不仅必须确保平台的稳定性，而且还必须确保报告查询的可用性和性能。不同图表的时间消耗和资源消耗非常大。基础资源始终受到限制。很难确保业务核心报告的高可用性。
该平台的稳定性保证是成熟的，而不是本文的重点。报告查询的稳定性保证在我们的实际工作中提供了更多能量。实际上，我们已经了解了服务分级保证的想法。不同的报告必须不同于业务的重要性。
保证对象清晰后，我们还需要确定关键报告依赖性依赖的数据输出和数据查询链接的相关组件和任务，Impala Engine等，我们需要为组件和任务分配独立的资源和任务键报告的表输出和数据查询链接。
在数据查询链接中，由于OLAP引擎的隔离不是很好，因此最好使用独立的群集资源。实际上，您还可以根据关键报告中的应用程序场景（例如查看类和分析场景的场景）对其进行细分。最好是隔离以减少相互影响。
有了独立的资源保护，我们还需要制定核心指标来量化关键报告的稳定性。在这里，我们关注三个指标，即首次访问缓存率，图表查询错误率和图形查询比率。
关键报告图首先访问缓存命中率。这是缓存预加载效果的指标，以确保用户在首次打开报告时尽可能多地击中预储备秒。
关键报告图表查询错误率。这是图表的可用性的指标，该图表等同于关键报告图表查询接口错误率。目前，这主要取决于总体错误率。实际上，该比率主要是指浏览状态的查询报告。
关键报告图表慢慢查询比率。这是图表性能的指标。<5s算慢查询，实际中可以为不同的图表制定不同的性能基线。
核心指标明确之后，我们需要为这些指标做相应的系统报告去监控、诊断和优化，不断去改善这三个指标。我们主要通过事前（报告发布审核、报告压测）、事中（监控、诊断、干预）、事后（首访缓存命中率治理、查询错误率治理、慢查询治理）三部分来保障和优化，这里主要结合网易高性能查询引擎Impala的实践来说明。
3.1 报告发布审核
报告的开发本质上也是一种软件开发，要完成高质量的交付，报告发布也需要有审核流程，尤其是重点报告。审核主要是两方面，一方面要检查下报告依赖的表和模型、报告制作上是否符合规范，比如表的存储格式是否合理、表小文件是否合理、模型是否用了分区字段筛选、报告单个页面图表是否过多等等，这个有数BI报告上提供了“数据医生-性能诊断”功能，可以自动诊断检查；另一方面也要根据预估的并发数去压测报告，看看报告性能是否达到要求，资源占用上是否存在风险。
3.2 报告压测
报告发布和性能优化都需要通过压测来验证，压测分为两种类型，一种是单个报告压测，比如报告上线压测、报告优化后的压测验证；另一种是场景化压测，比如上班高峰期的流量压测，场景压测可以基于用户的访问日志，模拟用户的访问流量去压测。
3.3 监控和诊断
除了平台常规的基础监控和应用监控外，我们还要给重点报告核心指标添加相应业务监控，比如缓存预加载数量监控、重点报告查询错误监控、重点报告抽取任务出错监控、重点报告慢查询监控等等，有了核心指标监控我们可以发现问题及时处理。
针对某些特定的错误，可以提供诊断的能力，比如持续出现“图表查询高峰”错误，可以诊断下是因为哪些报告的影响，紧急情况下也可以根据需要暂时禁用报告来保障整体稳定性。
3.4 报告治理
要持续提升重点报告的稳定性和性能，定期的治理和优化必不可少，因为报告访问量、表的数据量、表结构、表产出时间都存在一些不确定的变化。报告治理主要分为首访缓存命中率治理、报告查询错误率治理、慢查询治理三大块。
要提升重点报告首访缓存命中率，核心是要提高重点报告缓存预加载的完成比例，可以从以下三个方面优化：
（1）优化重点报告的表产出时间，重点报告依赖的表产出时间提前，才有更多的时间buffer去做缓存预加载，这个需要数据开发和分析师同学一起从数据产出链路上去优化。
（2）提升重点报告缓存预加载的优先级，这个可以提升重点报告相较于普通报告缓存预加载的先后顺序，从而提升重点报告缓存预加载完成率，同时重点报告也会根据最近访问量等指标再去细分优先级。
（3）对于一些缓存预加载超时或出错次数比较多的报告可以降低优先级。
要降低重点报告查询错误率，要对图表查询错误做分类治理：
（1）查询超时的图表要做慢查询优化治理（见图表慢查询优化部分）。
（2）图表查询高峰错误需要诊断出可疑的报告/图表进行优化。
（3）系统错误要通过系统优化来解决，比如元数据错误可以增加元数据刷新重试，服务重启错误可以增加查询重试等等。
（4）业务错误要推进报告作者治理，比如原表被删除、原表变更导致某些字段不存在、数据源连接不上等等。
图表慢查询治理方面，统一的治理有以下几类：
（1）耗时耗资源图表治理：top耗资源、top耗时图表往往严重影响集群整体性能和稳定性，多个慢图表并发查询时更容易出现查询高峰，所以这部分治理是重中之重。当然这个治理也要结合图表的访问量去看的，访问量大的图表影响也越大。
（2）小文件治理：小文件过多会导致元数据比较大，增加元数据同步压力，而且也会影响HDFS的性能。
（3）定时刷新治理：耗时耗资源的图表定时刷新频率过快，也会显著增加集群负载，可以降低频率或者关闭定时刷新。
具体到单个慢图表，常见的性能优化思路有：
（1）模型强制分区筛选：大表全表扫描对性能影响较大，百万以上大表建议使用分区表，同时在模型上设置强制分区筛选，减少数据扫描范围，也从源头控制全表扫描的可能。
（2）抽取到MPP：自定义SQL如果有筛选或聚合使得结果集减少可以抽取到MPP，通过MPP去查询，减少复杂SQL实时计算；后续产品上也支持抽取宽表模型到MPP，这在CK引擎上会有比较大的性能提升。
（3）物化模型：模型中关联的表过多导致性能差，可以使用数据任务预计算或者使用网易impala物化视图物化模型。
（4）列表筛选器使用独立维表：列表筛选器的数据需要从模型宽表明细对应列上去重计算得到，数据量大时性能较慢。如果列表筛选器成员比较固定的情况，可以列表筛选器走独立维表，通过跨模型关联筛选图表。
（5）刷新表统计信息：Impala是基于代价模型进行执行计划优化，表统计信息缺失会对执行计划的优劣产生重要影响，可以提前刷新表统计信息。
（6）时间/日期转换：将“字符串”类型的字段转换为“日期、日期时间”类型时，使用原始类型（即字符串类型）进行比较则不需要在SQL中进行字段类型转换，可提高查询性能。
（7）表存储格式治理：text存储格式数据过滤能力差，建议尽量使用高性能列式存储格式Parquet。
报告稳定性和性能保障是BI最重要的用户体验之一，方法上还需要不断实践总结，目前产品上已经有重点报告功能支持，后续还会有更多稳定性保障相关的系统报告和治理产品功能支持。
目前在集团内部云音乐的治理已经颇具成效，核心指标方面，首访缓存命中率大于90%，重点报告日查询错误率低于0.5%，重点报告图表查询>5s的比例小于5％。今年，借助Yun Music，它制定了一个关键的报告询问错误率SLA目标，并且还在进行严格的环境治理选择。
关于作者
NetASE技术专家Xueliang拥有一些BI技术领导者。他严格严格地研究了台湾，数据产品和服务的数据的研究和开发。他曾在JS课程中担任“成为前端开发工程师”和“ Front -End -End Micro -Professional”的讲师。十多年来，互联网产品超过十年，以及管理经验。
原始：https：//juejin.cn/post/7098270420888977438