本文次要联合实际总结了大规模报告稳定性保障办法。
我的项目背景
随着数据化治理思维的逐步深入人心，无论是网易团体外部用户还是内部商业化客户，越来越多的人在大规模应用无数 BI。以严选为例，日常有访问量的报告有 5w+，这些报告笼罩了用户、商品、渠道、流量、营销、仓储、供应商、财务等简直所有业务板块，有些报告嵌入在管理层用的 app 中，有些报告用在了业务周会或复盘会，有些报告嵌入业务零碎辅助业务决策 …，在日常工作中施展着重要的作用，高峰期图表日查问量 10w+，这给报告的稳定性保障带来很大的挑战。
报告的稳定性保障，不仅仅要保障平台的稳定性，更重要是要保障报告图表查问的可用性和性能。然而因为报告数量多，而且不同于一般业务服务，不同图表的查问耗时和耗资源差别十分大，底层资源始终是无限的，对立去保障难度很大，也无奈保障业务外围报告的高可用性。
摸索布局
平台的稳定性保障是有成熟的办法的，不是本文的重点。报告查问的稳定性保障在咱们理论工作中占了更多的精力，在实践中咱们借鉴了服务分级保障的思维，不同的报告对业务重要性肯定是有差异的，咱们将重点报告标记进去，优先保障重点报告。当然这个重点、非重点是从要业务视角自上而下去看的。
保障对象明确之后，咱们还要辨认出重点报告依赖的数据产出链路和数据查问链路上的相干组件和工作，这些组件和工作也须要重点保障，比方重点报告依赖的 ETL 工作、数据查问依赖的 impala 引擎等等，咱们须要为重点报告的表产出链路和数据查问链路的组件和任务分配独立的资源。
在数据查问链路上，因为 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%，往年和云音乐一起制订了重点报告查问错误率 SLA 指标，严选环境治理也正在进行中。
作者简介
雪亮，网易技术专家，无数 BI 技术负责人，曾负责严选数据中台、数据产品及服务研发，曾负责《成为前端开发工程师》和《前端微业余》的 JS 课程讲师，十多年互联网产品研发和治理教训。