观远数据云巡检最佳实践

版权所有©杭州观远数据有限公司2022。保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。 商标声明 和其他观远数据商标均为杭州观远数据有限公司的商标。本文档提及的其他所有商标或注册商标，由各自的所有人拥有。 注意 您购买的产品、服务或特性等应受观远数据商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。除非合同另有约定，观远数据对本文档内容不做任何明示或暗示的声明或保证。 由于产品版本升级或其他原因，本文档内容会不定期进行更新。除非另有约定，本文档仅作为使用参考，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。 目录 1.概述5 2.前置条件7 3.系统运维最佳实践9 3.1问题场景9 3.2整体思路9 3.3具体实践12 3.3.1标准配置12 3.3.2资源水位持续高12 3.3.3特定时段异常14 3.3.4单点异常16 3.4优化方式18 3.4.1系统资源告警18 3.4.2任务运行控制19 4.业务治理最佳实践20 4.1问题场景20 4.2整体思路20 4.3具体实践21 4.3.1低价值业务识别与治理21 4.3.2高价值业务识别与保障22 4.4业务优化25 4.4.1定位问题作业25 4.4.2判断清理与否26 4.4.3灰度下线26 5.运营管理最佳实践28 5.1风险管理28 5.1.1系统风险-系统运维28 5.1.2安全风险28 5.2用户运营29 5.2.1用户License管理29 5.2.2不活跃用户处理29 5.2.3企业数字文化推广30 附常见问题解决方案32 1.概述 随着BI平台逐渐深入企业的运营流程，BI平台的运维或管理的负责人通常会面临一个繁复且艰难的问题，就是对系统运行指标的监控、告警及问题处理。对此，观远数据提供了「云巡检」这一云端智能巡检服务，帮助用户基于云巡检的自动巡检与诊断，对BI系统进行主动运维，排除问题，提高系统稳定性和业务效率。为了帮助用户更好地理解并使用云巡检，利用云巡检来找到关键的问题发生时间、涉及资源、关联业务场景等，进而采取解决方案，观远数据特此提供最佳实践，为用户带来行动参考。具体常见问题部分如下： 系统资源水位是否异常？不同异常该如何应对? ETL运行任务总是跑不出来是为什么？ BI看板数据加载慢的可能原因是什么？该如何定位问题原因？ BI系统内的业务，都是有效业务么？都是有价值的么?该如何判断？ 云巡检（也称云端诊断、智能运维），是观远数据提供的智能运维服务，以产品形式分享观远数据多年沉淀的数字化管理技术，一站式全联接，让IT运维更智能。通过云巡检，用户无须通过人力去拉取BI系统的集群资源、运行情况相关数据，根据云巡检自动生成的可视化分析结果报告，可以快速发现相关问题，并快速获取可优化/解决方案建议，减少日常运维工作的成本，并提前计划好容量规划。 本文将从三个方面分享关于「云巡检」使用的最佳实践： ■对系统风险进行诊断，按需进行合理的容量规划 基于系统监控指标，对系统性能进行巡检、诊断、预警；对于风险预警，根据行动建议做及时处理。 基于系统监控指标，如系统整体性能、水位情况等，以及业务发展情况，做扩容规划。 ■对业务资产及其使用情况进行诊断，进行治理和优化 基于系统监控指标，识别低价值业务资产，对无价值或低价值的业务资产进行治理，有效回收资源。 基于系统监控指标，识别业务作业潮汐，对业务作业高峰进行合理规范与调度。 ■对于系统运行与用户行为情况进行诊断，识别系统与数据安全风险，提前防范 基于监控指标，识别异常行为，对高风险行为进行规范，有效避免安全问题。 基于监控指标，识别异常用户与核心用户，针对性采取运营措施。 2.前置条件 在执行本实践前，您需要完成以下准备工作： ■产品基础 首先，已经开通了观远数据服务，并完成部署实施流程。 其次，开通了云巡检功能模块，并完成云巡检报告生成流程。 ■账号角色 注册观远数据BI账号，成为“管理员”，确认您可以进入“管理员设置”与“云巡检”功能板块。 ■概念须知 为了让您更好地实践，请先了解以下概念： 云巡检：也称云端诊断、智能运维，是观远数据提供的智能运维服务，以自动获取系统运行数据的方式进行系统诊断，通过可视化报告为用户呈现系统运行状况，帮助用户识别系统与数据安全相关风险，积极应对与决策。 系统性能：也称计算机系统性能，计算机系统由计算机硬件和软件两部分组成。硬件包括中央处理机（CPU）、存储器和外部设备等；软件包括计算机的运行程序和相应的文档。系统性能有多种衡量尺度，一般是指系统资源利用率、系统吞吐量以及响应时间等指标。 资源容量：包含CPU、内存算力资源，及磁盘的用量，精准的容量规划，可以帮助业务的快速发展，避免算力支持成为业务发展的瓶颈、阻碍项。 ETL：指观远数据业内首创智能数据准备（SmartETL，也称智能ETL、ETL），可达到专业级的数据处理效果，旨在让用户在数据分析、数据可视化制作前，能 够对数据集进行易操作、低门槛、智能化的高效数据处理，使数据经过清洗、转换、装载后得到对终端业务人员更有效的数据集。 CPU负载：指CPU的承载能力，通常可理解为一段时间内的总任务数/CPU 核数。CPU是电子计算机的主要设备之一，电脑中的核心配件，负责读取指令，对指令译码并执行指令。 ■实践路径 说明：诊断目标可以分为系统运维、业务治理、运营管理三大类，首先明确诊断目标，更有利于对症下药。 3.系统运维最佳实践 3.1问题场景 随着企业中使用BI的用户增加，业务分析工作量在BI平台上的承载增多，BI平台在数据接入-数据开发-数据可视化-数据应用等方面的效率上具备先进性，但也给平台的监控、运维、诊断带来了巨大挑战。经过总结，BI管理员常遇到的挑战有： 定位问题难 发现瓶颈难 运维改善难等 我们可以从基于云巡检的可视化报告，结合多个指标具体诊断，定位根因，进而采取优化措施，合理解决资源紧张、性能下降、容量不足、配置不足等问题。 3.2整体思路 说明 以上所提及的多项指标，在云巡检报告中分布在仪表板/卡片、数据集、ETL等模块中，并非集中展示，为集中分析系统性能和容量的诊断实践，本文将进行结合阐述。 基于云巡检系统性能/容量的诊断，对BI平台运行情况做整体判断。 （图例，仅供参考） 如上图所示，云巡检报告针对不同模块，已经给出了诊断汇总，主要分为指标名称、问题、行动建议，在实际的运维分析中，我们可以按照此思路，结合具体的巡检指标，识别风险根因，并采取对应的措施。 ■常见问题分析思路 1.当出现持续的高水位时： 结合ETL和卡片的运行情况，排除非预期的作业因素后，根据容量规划指导，做扩容安排。 2.当在特定时间中出现水位较高时： （1）结合卡片和ETL的运行/排队时间，排除非预期的作业因素后，来判断是否应该错峰运行； a.非预期的作业因素是什么？主要指不合理的作业和意外出现异常的作业，导致作业长时间运行强占系统资源 b.如何识别非预期的作业因素？主要根据排在前列的运行时间与运行次数(频率)是否合理来识别 c.对这类情况如何预防？可以结合BI产品能力，设置限制和预警，具体设置可在第5章查看。 （2）结合9分位性能、资源水位，明确带来性能问题的原因，常见问题有资源紧张，或者业务使用情况不合理；进而可以判断是否需要进行业务设计优化； （3）对比平均值和最大值的差距，判断是否需要扩容 首先看业务调整的可能性，如果可以通过分散业务高峰的作业任务来避免水位高，那么可以不扩容。因为如果平均值与最大值的差距过大，意味着扩容成本较高。举例：当基础配置为8核64G，日常水位为10%左右，而在9:00-10:00这一个小时中出现最高水位达到90%。 那么如果扩容，可能要扩到32核，来应对这一个小时的高峰，扩容的性价比不高。 3.3具体实践 3.3.1标准配置 如图所示，根据系统运行情况，云巡检诊断出“当前服务器CPU核数、内存、磁盘未达到最低配置（8核64G）”。因此给出行动建议，参照观远数据容量规划，升级到标准配置，具体容量规划指南可从观远数据的官网进行下载，或向观远数据工作人员获取。 （图例，仅供参考） 3.3.2资源水位持续高 如果云巡检诊断出最近7天服务器CPU负载在绝大部分时间中都超过警戒线 （如下图所示）。常见原因为：业务并发量大，作业计算量大。然后，可以结合卡片排队时长、卡片运行时长、数据集运行时间分布等指标进行具体分析。 （图例，仅供参考） ■具体分析 从CPU使用率和CPU负载来看，整体水平为持续走高的状态。 （图例，仅供参考） （图例，仅供参考） 结合下图中的卡片运行情况看，卡片运行时长也有持续高于预期的情况。如：Guan-Index类型卡片的9分位性能已接近10s，属于较慢的水平。通常情况下，维持在3s是相对健康的状态。 （图例，仅供参考） （图例，仅供参考） ■优化方案 综合以上具体分析，最终建议结合业务增长情况规划扩容。扩容测算依据如下，具体情况可咨询观远数据工作人员。 A.统计该时间段内卡片运行情况：卡片请求数x,确认当前卡片Spark分配资源CPU核数n。 B.统计其他时间该时间段卡片运行情况：卡片请求数y。 C.通过计算扩容后卡片的CPU资源为t=x/y*n，t向上取整数。 3.3.3特定时段异常 如果云巡检诊断出最近7天服务器CPU负载只在特定较短的某时间段超过警戒线，即资源水位高。常见原因为：特定时间段的业务并发量大，作业计算量大。那么，可以结合卡片排队时长、卡片运行时长、ETL运行时间分布等指标进行具体分析。 ■案例说明 某大型集团每天6:00-13:00ETL任务排队特别多，导致任务执行完成时间较晚，集团需求为早上9点前所有ETL执行完成。现资源情况为：16核128G。此时则可以结合业务情况与资源情况选择优化方案。 （图例，仅供参考） （图例，仅供参考） ■具体分析 结合ETL执行时间看:业务高峰时间与ETL执行时间重和，因此会影响业务人员进行数据查询与分析的体验。 （图例，仅供参考） ■优化方案 方案一、优化业务 如果业务允许，可安排ETL错峰运行，例如0点开始逐步调度ETL运行任务，保证上午时间段不再形成ETL运行高峰，不再影响业务看数分析体验。 方案二、资源扩容 资源从16核128G扩容到24核192G，Spark资源从8核32G增加到16核64G，保证ETL任务在早上9点执行完成。 3.3.4单点异常 如果云巡检诊断出最近7天服务器CPU负载在某个特定时间点上超过警戒线，即资源水位高、负载异常（如下图所示：5月7日17点，CPU负载异常）。常见原因为：突发的作业并发或者某个(些)非预期的大作业。那么，可以查看下当时的运行作业情况进行具体分析。 （图例，仅供参考） ■具体分析 对照CPU使用和内存使用的指标情况来看，17点系统基本处于满负荷状态。 （图例，仅供参考） （图例，仅供参考） 因此查看该时间点的运行作业情况：在Galaxy的管理员设置-运维管理中，选择对应的时间段查看，并可以根据运行时长从大到小排序，找到运行时长异常的具体作业。 （图例，仅供参考） 云巡检中的卡片/数据集/ETL的“更新情况”指标也能帮助排查问题。如下图案例中的数据集更新情况，5月7日17点前，有多个长时运行作业，因此可对这几个作业做优先排查。 （图例，仅供参考） ■优化方案 对排查出来的具体作业，进行优化。优化方式参考如下： 如果是超复杂ETL，可以分拆为多个ETL，避免在一个ETL中设置大量节点。 如果是行数上亿的超大数据集，可以尽量避免创建如此大的数据集。 对于较大的数据集，在数据更新方式上，尽量设置增量更新的方式，避免全量更新的方式带来任务运行过