大数据稳定性体系建设

·  阅读 657

「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!

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:总结

稳定性建设是一个长期的过程。大家在做业务项目的同时,一定要思考技术的创新以及稳定性建设。每一个项目都是自己的招牌。只有自己不断的让大家觉得你靠谱,未来才能有更大的项目以及更大的挑战,反思与复盘一定会让你突飞猛进。

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改