有数BI大规模报告稳定性保障实践

随着数据化管理思维的逐渐深入人心，无论是网易集团内部用户还是外部商业化客户，越来越多的人在大规模使用有数BI。以严选为例，日常有访问量的报告有5w+，这些报告覆盖了用户、商品、渠道、流量、营销、仓储、供应商、财务等几乎所有业务板块，有些报告嵌入在管理层用的app中，有些报告用在了业务周会或复盘会，有些报告嵌入业务系统辅助业务决策...，在日常工作中发挥着重要的作用，高峰期图表日查询量10w+，这给报告的稳定性保障带来很大的挑战。

报告的稳定性保障，不仅仅要保障平台的稳定性，更重要是要保障报告图表查询的可用性和性能。但是由于报告数量多，而且不同于普通业务服务，不同图表的查询耗时和耗资源差异非常大，底层资源始终是有限的，统一去保障难度很大，也无法保障业务核心报告的高可用性。

平台的稳定性保障是有成熟的方法的，不是本文的重点。报告查询的稳定性保障在我们实际工作中占了更多的精力，在实践中我们借鉴了服务分级保障的思想，不同的报告对业务重要性一定是有差别的，我们将重点报告标记出来，优先保障重点报告。当然这个重点、非重点是从要业务视角自上而下去看的。

保障对象明确之后，我们还要识别出重点报告依赖的数据产出链路和数据查询链路上的相关组件和任务，这些组件和任务也需要重点保障，比如重点报告依赖的ETL任务、数据查询依赖的impala引擎等等，我们需要为重点报告的表产出链路和数据查询链路的组件和任务分配独立的资源。

在数据查询链路上，由于OLAP引擎的隔离性不是太好，最好使用独立的集群资源，实际中还可以根据重点报告的应用场景再去细分，比如看板类的和分析类的场景也最好也能隔离开，减少相互影响。

有了独立的资源保障，我们还需要为重点报告制定核心指标去量化稳定性，这里重点看三个指标，分别是图表首访缓存命中率、图表查询错误率、图表慢查询比例。

重点报告图表首访缓存命中率，这个是缓存预加载效果的指标，保障用户首次打开报告的时候尽可能命中预缓存秒开。

重点报告图表查询错误率，这个是图表可用性的指标，相当于重点报告图表查询接口错误率，目前主要看整体的错误率，实际中也可以为不同的报告制定不同的错误率要求，这里的错误率主要是指用户浏览状态下的查询报错。

重点报告图表慢查询比例，这个是图表性能的指标，这个指标要先为图表制定一个性能基线，比如<5s算慢查询，实际中可以为不同的图表制定不同的性能基线。

核心指标明确之后，我们需要为这些指标做相应的系统报告去监控、诊断和优化，不断去改善这三个指标。我们主要通过事前（报告发布审核、报告压测）、事中（监控、诊断、干预）、事后（首访缓存命中率治理、查询错误率治理、慢查询治理）三部分来保障和优化，这里主要结合网易高性能查询引擎Impala的实践来说明。

3.1 报告发布审核

报告的开发本质上也是一种软件开发，要完成高质量的交付，报告发布也需要有审核流程，尤其是重点报告。审核主要是两方面，一方面要检查下报告依赖的表和模型、报告制作上是否符合规范，比如表的存储格式是否合理、表小文件是否合理、模型是否用了分区字段筛选、报告单个页面图表是否过多等等，这个有数BI报告上提供了“数据医生-性能诊断”功能，可以自动诊断检查；另一方面也要根据预估的并发数去压测报告，看看报告性能是否达到要求，资源占用上是否存在风险。

3.1 报告压测

报告发布和性能优化都需要通过压测来验证，压测分为两种类型，一种是单个报告压测，比如报告上线压测、报告优化后的压测验证；另一种是场景化压测，比如上班高峰期的流量压测，场景压测可以基于用户的访问日志，模拟用户的访问流量去压测。

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目标，严选环境治理也正在进行中。