背景介绍
近些年来，大数据技术得到了很广的应用，支撑了业务的快速发展。作为大数据的平台部门，提供了大数据相关的基础能力，业务同学借助于大数据的底层赋能完成更偏向业务的需求开发。报表是大数据支撑最早最广的功能形态。先给大家介绍我们我们公司的报表产出组件图：
报表产出图
- 底层平台由HDFS、Yarn分别提供存储和计算支持
- 在这之上我们提供了一套支持MR、Spark任务开发、依赖执行的调度系统
- BI业务同学利用调度系统完BI任务的开发，最终这些BI任务完成后会把数据写到Hive中
- Tableau报表系统定时从Hive中读取数据完成报表的渲染
问题
平台部门的目标就是保证报表的按时产出，公司高层可以根据产出的报表进行决策和资源的合理分配。
接下来我们看看报表的稳定性面临哪些问题，哪些系统的会最终造成报表产出，让我们看一份大图。
报表全程图
tableau报表处于整个数据应用的最上层，下面依赖的数据源、数据仓库、调度任务任何一个环节延迟都会导致整个报表的产出延迟，我们来细分下
数据源
- 业务表计算延迟
- 数据同步任务本身缺陷
- 业务库字段变更，同步出错
数据仓库
- 数仓任务调度延迟
- 数据计算逻辑错误
- 数据量增大，数据计算产出时间变长
- 上游依赖变更，数据错误
调度系统
- yarn资源不足，大量任务等待
- 报表新增依赖，下游调度任务开始时间变慢
- 无用任务占用太多资源
- 用户使用不规范
- 大数据平台本身故障
- 误操作
- 不合理的上游依赖
Tableau
- 用户密码变换
- 队列资源不足
- 部门间任务相互影响，一个部门的超时任务会影响其他部门的
治理思路
上面的任务按照责任主体划分可以分为业务方和平台方。比如业务SQL逻辑错误、依赖新增等属于平台方责任，而队列资源设置不合理、平台工具逻辑错误、公共数仓产出延迟、集群变更导致延迟属于平台方问题。
- 大数据的思路治理大数据。分部门统计资源消耗量、报表数、错误报表数，数据透明清晰，便于沟通
- 驱动用户自运营。也可以从两方面考虑，一方面是一些给用户带来满足的手段，比如部门质量排名情况。一方面是恐惧的压力：限制最大资源数、最大报表数量
- 平台提供工具，报表的产出的准点负责方应该是业务方。
怎么做
我准备分三部分来介绍我们的方案，分别是问题预防、问题诊断、问题快修复。
问题预防
- 业务SQL修改后必须试跑成功后才能上线
- 依赖部门外任务必须要上游同学审批同意
- 用户名密码改编后及时知会用户修改相应的报表配置信息
- 核心报表的产出时间延迟趋势监控
- 复杂度、部门总体运行情况查看
- 队列划分合理，避免不同业务优先级之间相互影响
问题诊断
- 系统监控。监控整体的任务的整点的成功率、超时失败任务数
- 细粒度监控。提供功能让用户能针对高优先级的报表进行监控
问题快修复
- 统一地方查看报表延迟在哪一个环节
- 提供工具快速完成问题修复
