《有数BI大规模报告稳定性保障实践.docx》由会员分享，可在线阅读，更多相关《有数BI大规模报告稳定性保障实践.docx（8页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、有数BI大规模报告稳定性保障实践导读：本文主要结合实践总结了大规模报告稳定性保障方法。1项目背景随着数据化管理思维的逐渐深入人心，无论是网易集团内部用户还是外部商业化 客户，越来越多的人在大规模使用有数BI0以严选为例，日常有访问量的报告有 5w+ ,这些报告覆盖了用户、商品、渠道、流量、营销、仓储、供应商、财务等 几乎所有业务板块，有些报告嵌入在管理层用的app中，有些报告用在了业务周 会或复盘会，有些报告嵌入业务系统辅助业务决策，在日常工作中发挥着重要 的作用，高峰期图表日查询量10w+ ,这给报告的稳定性保障带来很大的挑战。报告的稳定性保障，不仅仅要保障平台的稳定性，更重要是要保障报告图
2、表查询 的可用性和性能。但是由于报告数量多，而且不同于普通业务服务，不同图表的 查询耗时和耗资源差异非常大,底层资源始终是有限的，统一去保障难度很大， 也无法保障业务核心报告的高可用性。2探索规划平台的稳定性保障是有成熟的方法的,不是本文的重点。报告查询的稳定性保障 在我们实际工作中占了更多的精力，在实践中我们借鉴了服务分级保障的思想， 不同的报告对业务重要性一定是有差别的，我们将重点报告标记出来，优先保障 重点报告。当然这个重点、非重点是从要业务视角自上而下去看的。保障对象明确之后，我们还要识别出重点报告依赖的数据产出链路和数据查询链 路上的相关组件和任务，这些组件和任务也需要重点保障，比如
3、重点报告依赖的 ETL任务、数据查询依赖的impala引擎等等，我们需要为重点报告的表产出链路 和数据查询链路的组件和任务分配独立的资源。在数据查询链路上，由于OLAP引擎的隔离性不是太好，最好使用独立的集群资 源，实际中还可以根据重点报告的应用场景再去细分，比如看板类的和分析类的 场景也最好也能隔离开,减少相互影响。事前思想：报告分级核心呼旨标缓存：重点报告首访缓存命中率 可用性：重点报告查询错误率 性能：重点报告慢查询比例事中事后有了独立的资源保障，我们还需要为重点报告制定核心指标去量化稳定性，这里重点看三个指标，分别是图表首访缓存命中率、图表查询错误率、图表慢查询比 例。 重点报告图表首
4、访缓存命中率，这个是缓存预加载效果的指标，保障用户首次打 开报告的时候尽可能命中预缓存秒开。重点报告图表查询错误率，这个是图表可用性的指标，相当于重点报告图表查询 接口错误率，目前主要看整体的错误率，实际中也可以为不同的报告制定不同的 错误率要求，这里的错误率主要是指用户浏览状态下的查询报错。重点报告图表慢查询比例，这个是图表性能的指标，这个指标要先为图表制定一 个性能基线，比如5s算慢查询，实际中可以为不同的图表制定不同的性能基线。3实践方案核心指标明确之后，我们需要为这些指标做相应的系统报告去监控、诊断和优化， 不断去改善这三个指标。我们主要通过事前（报告发布审核、报告压测）、事中 （监控
5、、诊断、干预）、事后（首访缓存命中率治理、查询错误率治理、慢查询 治理）三部分来保障和优化，这里主要结合网易高性能查询引擎Impala的实践 来说明。3.1报告发布审核报告的开发本质上也是一种软件开发,要完成高质量的交付，报告发布也需要有 审核流程，尤其是重点报告。审核主要是两方面，一方面要检查下报告依赖的表 和模型、报告制作上是否符合规范，比如表的存储格式是否合理、表小文件是否 合理、模型是否用了分区字段筛选、报告单个页面图表是否过多等等，这个有数BI报告上提供了 数据医生性能诊断”功能，可以自动诊断检查；另一方面也要 根据预估的并发数去压测报告，看看报告性能是否达到要求，资源占用上是否存
6、在风险。3.1 报告压测报告发布和性能优化都需要通过压测来验证，压测分为两种类型，一种是单个报 告压测，比如报告上线压测、报告优化后的压测验证；另一种是场景化压测，比 如上班高峰期的流量压测，场景压测可以基于用户的访问日志，模拟用户的访问 流量去压测。3.3 监控和诊断除了平台常规的基础监控和应用监控外，我们还要给重点报告核心指标添加相应 业务监控，比如缓存预加载数量监控、重点报告查询错误监控、重点报告抽取任 务出错监控、重点报告慢查询监控等等，有了核心指标监控我们可以发现问题及 时处理。针对某些特定的错误,可以提供诊断的能力,比如持续出现图表查询高峰“错 误，可以诊断下是因为哪些报告的影响，
7、紧急情况下也可以根据需要暂时禁用报 告来保障整体稳定性。3.4 报告治理要持续提升重点报告的稳定性和性能，定期的治理和优化必不可少，因为报告访 问量、表的数据量、表结构、表产出时间都存在一些不确定的变化。报告治理主 要分为首访缓存命中率治理、报告查询错误率治理、慢查询治理三大块。要提升重点报告首访缓存命中率，核心是要提高重点报告缓存预加载的完成比例， 可以从以下三个方面优化：(1)优化重点报告的表产出时间，重点报告依赖的表产出时间提前，才有更多的 时间buffer去做缓存预加载，这个需要数据开发和分析师同学一起从数据产出链 路上去优化。(2 )提升重点报告缓存预加载的优先级，这个可以提升重点报
8、告相较于普通报告 缓存预加载的先后顺序，从而提升重点报告缓存预加载完成率，同时重点报告也 会根据最近访问量等指标再去细分优先级。(3)对于一些缓存预加载超时或出错次数比较多的报告可以降低优先级。要降低重点报告查询错误率，要对图表查询错误做分类治理：(1 )查询超时的图表要做慢查询优化治理(见图表慢查询优化部分)。(2 )图表查询高峰错误需要诊断出可疑的报告/图表进行优化。(3 )系统错误要通过系统优化来解决，比如元数据错误可以增加元数据刷新重试， 服务重启错误可以增加查询重试等等。(4)业务错误要推进报告作者治理，比如原表被删除、原表变更导致某些字段不存在、数据源连接不上等等。 图表慢查询治理
9、方面，统一的治理有以下几类：(1 )耗时耗资源图表治理：top耗资源、top耗时图表往往严重影响集群整体性 能和稳定性，多个慢图表并发查询时更容易出现查询高峰，所以这部分治理是重 中之重。当然这个治理也要结合图表的访问量去看的，访问量大的图表影响也越 大。(2)小文件治理：小文件过多会导致元数据比较大，增加元数据同步压力，而且 也会影响HDFS的性能。(3)定时刷新治理：耗时耗资源的图表定时刷新频率过快，也会显著增加集群负 载，可以降低频率或者关闭定时刷新。具体到单个慢图表，常见的性能优化思路有：(1 )模型强制分区筛选：大表全表扫描对性能影响较大，百万以上大表建议使用 分区表，同时在模型上设
10、置强制分区筛选，减少数据扫描范围，也从源头控制全 表扫描的可能。(2 )抽取到MPP :自定义SQL如果有筛选或聚合使得结果集减少可以抽取到 MPP ,通过MPP去查询，减少复杂SQL实时计算；后续产品上也支持抽取宽表 模型到MPP,这在CK引擎上会有比较大的性能提升。(3)物化模型：模型中关联的表过多导致性能差，可以使用数据任务预计算或者 使用网易impala物化视图物化模型。(4 )列表筛选器使用独立维表：列表筛选器的数据需要从模型宽表明细对应列上 去重计算得到，数据量大时性能较慢。如果列表筛选器成员比较固定的情况，可 以列表筛选器走独立维表，通过跨模型关联筛选图表。(5 )刷新表统计信息
11、：Impala是基于代价模型进行执行计划优化,表统计信息 缺失会对执行计划的优劣产生重要影响，可以提前刷新表统计信息。(6 )时间/日期转换：将字符串类型的字段转换为日期、日期时间”类型 时，使用原始类型(即字符串类型)进行比较则不需要在SQL中进行字段类型转 换，可提高查询性能。(7 )表存储格式治理：text存储格式数据过滤能力差，建议尽量使用高性能列式 存储格式Parquet,4小结报告稳定性和性能保障是BI最重要的用户体验之一方法上还需要不断实践总结, 目前产品上已经有重点报告功能支持，后续还会有更多稳定性保障相关的系统报 告和治理产品功能支持。目前在集团内部云音乐的治理已经颇具成效，核心指标方面，首访缓存命中率大 于90%，重点报告日查询错误率低于0.5%，重点报告图表查询 5s比例低于5% , 今年和云音乐一起制定了重点报告查询错误率SLA目标，严选环境治理也正在进 行中。