1：大数据稳定性建设
大数据平台承载着公司（推荐、搜索、bi、渠道推广）等多条核心业务线。一旦某环节出现问题，可能影响很多线上用户。基于以上情况联合运维一起做线上稳定性建设，把各个体系的监控、预警提升到一个新高度。
2：如何构建线上稳定性
我们的组件监控在1.0版本中已上prometheus+grafana，线上各种组件监控已经有初步的保障。但是线上很多业务细节的监控缺乏保障，监控的颗粒度不够。到真正出现问题，所有人手忙脚乱。大数据平台一定需要业务赋能+稳定性治理，在业务赋能的的同时，逐步完善保障体系。
| 稳定性建设模块 | 具体的预案 | | 线上服务治理 | 1：大数据数据块预警 2：监控application，做到保活、c端服务支持弹性扩容3:线上依赖的jar管理。 | | ?组件稳定性建设 | 1：kylin,clickhouse,hbase,redis,elasticsearch 存储优化、组件监控、保活。 | | ETL链路检查 | 1：核心数据异常指标监控2：数据空洞、重跑、补充等。 | | 埋点链路数据检查 | 1：埋点收集异常检测2：线上问题追踪，反查，数据补充。 | | 推荐服务检查? | 1：推荐核心链路执行情况监控，异常、任务执行失败通知 2：线上常用key数据检查。 | | 线上hot key检查 | 1：梳理核心业务hotkey,ttl以及命名规范。2：hotkey value 数据备份，以及数据更新。 | | 发布管理 | 1:代码review 2:压测 3：发布公约 4：发布的节点以及流程 5:跟踪发布以及复盘。 | | 线上灰度 | 1:线上灰度制定以及监控 2：线上问题跟进 3：数据复盘，反推业务优化。 |
3：组件稳定性建设
1:dolphinscheduler任务执行检查
线上所有的任务都是基于dolphin提交flink、spark、shell 、http等，定时检查任务的执行状态来决定是否报警。通过查询dolphinscheduler数据库，所有的任务的命名严格规定。只允许TEMP打头的任务可以不上线，其他任务必须上线（如果有人下线任务，5分钟内就会有相关的报警）。 定时轮序一定时间段内的任务执行状态，把超时、失败的任务发出。让相关人员跟进处理。
2：etl 链路检查
1：检测所有sql的录入格式，sql依赖的source、sink 以及format sql。把录入不合理的sql第一时间报警出来(推荐使用sql-table-name-parser 或 ?alibaba druid)。
2：spark sql执行所有数仓分层数据，我们会记录任务的执行时间。单条sql执行的时间过长，会提醒相关人员跟进优化。把一些slow sql 扼杀在摇篮之中。
3:任务重试，如果单条任务执行失败。把该条sql依赖的链路重新执行，确保相关数据的准确性以及可靠性。
3：kylin 数据检查
1:kylin是bi系统的核心，我们针对cube segment回刷、cube膨胀率检查、segment auto merge、segment构建时长检查、segment空洞检查、cube构建历史检查并重跑失败job 等（7070是kylin 端口，直接模拟相关页面请求，即可完成相关逻辑）
2：kylin 系统提供相关的api，只需要发起相关的http请求。在请求的时候把相关的header信息带上，即可绕过相关验证。（使用ejlchina 实现相关http请求，支持websocket、http。使用比较轻便）
4：推荐相关数据检查
推荐相关的数据我们主要通过定时备份数据，把hotkey数据备份到数据库。万一遇到冷启动任务执行失败，我们可以立即回写最近一天的数据到hbase或redis
5：链路数据检查
主要检查kylin、elasticsearch、clickhouse 的数据同环比数据检测，以及数据条数检测。确保核心数据出现差异，第一时间预警跟进。
6：hdfs 文件快治理
hdfs文件管理是一个长期建设的过程，1：历史的埋点数据归档 2：迁移历史ods数据 3：每天新增的分区数据合并4：hive表健康检查 5：原始埋点数据压缩。
4：总结
稳定性建设是一个长期的过程。大家在做业务项目的同时，一定要思考技术的创新以及稳定性建设。每一个项目都是自己的招牌。只有自己不断的让大家觉得你靠谱，未来才能有更大的项目以及更大的挑战，反思与复盘一定会让你突飞猛进。
|