亿级用户百TB级数据的 AIOps 技术实践之路（增强版）

最新推荐文章于 2024-09-15 11:30:00 发布

高效运维

最新推荐文章于 2024-09-15 11:30:00 发布

阅读量4.4k

点赞数

本文链接：https://blog.csdn.net/Mes8Y62b6ogV207/article/details/80193083

版权

本文介绍了华为消费者BG云服务在应对亿级用户和百TB级数据运维时面临的三大挑战：业务多且形式多样、数据价值与成本平衡、数据规模大且增长快速。通过引入AIOps，华为构建了数据价值、数据平台和数据智能的实践路径。在数据价值方面，强调了精细化监控和业务监控的重要性；在数据平台上，利用Kafka、Spark、Druid等技术处理海量数据；在数据智能上，通过Z-score和Boxplot算法实现数据源异常检测，同时运用时间序列分解和多工况检测算法进行指标异常检测。

摘要由CSDN通过智能技术生成

640?wx_fmt=png&wxfrom=5&wx_lazy=1

作者简介

640?wx_fmt=png&wxfrom=5&wx_lazy=1

周荣，华为消费者BG云运维部 AIOps 负责人，GOPS 2018 深圳站金牌讲师，07年加入华为，先后分别负责下一代智能网、中间件平台、运维工具等产品的研发与规划，在分布式系统、大数据分析处理、高并发连接、运维工具等场景有丰富的实践经验；15年初起负责运营商领域的软件运维工具平台、17年初起加入消费者BG云服务部，负责云运维部运维大数据的研发与规划，倡导数据化精准化智能化运维理念，目前着力于AIOps 能力的运维实践提升；

说明

本文整理自 GOPS 2018 深圳站现场记录，第一稿发布后，各方反馈积极，为了促进大家在AIOps领域业务与技术交流，本文作者在此加强版本中，特别补充了第一版中的部分缺图，展示了更多华为消费者 BG 云运维部 AIOps 实践的直观内容。

前言

今天我给大家带来的分享议题是《亿级用户百TB级数据的AIOps技术实践之路》，主要有以下五个点：

1、华为消费者业务介绍
2、云服务运维面临的挑战
3、AIOps 实践之路：数据价值（业务监控）
4、AIOps 实践之路：数据平台
5、AIOps 实践之路：数据智能

一、华为消费者业务介绍

首先介绍一下华为的消费者BG业务，华为有三个BG，运营商、消费者、企业。17年华为6036亿元总收入中，消费者BG 2372亿，占比39.3%，其中手机发货量1.53亿台，全球份额已突破10%。

640?wx_fmt=png

图中列出了华为消费者BG的主要产品：华为&荣耀手机、笔记本&平板、穿戴设备、智能家居、软件应用。其中软件应用包含了操作系统EMUI 和各种应用业务，我所在的云服务部门主要负责各类应用业务。

今天我分享的主题中有一个描述是亿级用户，我们来看下一组数据，在这张图里，我们能够看到这个用户规模以及所带来的业务量量级。

和大家说明一下，这里提及的华为消费者BG云服务相关业务，并非华为云，而是服务于华为消费者BG终端产品（如手机、平板、穿戴、智能家居等）消费者的业务。

640?wx_fmt=png

截至17年底，华为帐号，注册用户3.3亿，到今天这个用户数还在不断增长。随着业务量的增长，云存储、PUSH、运动健康等业务量也随之保持着持续高速增长。PUSH 的并发能够直观体现用户使用情况，华为主题的杂志锁屏相信很多华为手机用户朋友都很喜欢，另外运动健康，虽然用户数是4600万多，但是数据活跃度很高，运维大数据处理量上，有近1/8是这个业务贡献的。在本图中下方，还列举了其他业务，总的来算，云服务运维部负责的内外部业务，有100余个。

二、云服务运维面临的挑战

随着用户量和业务量的持续高增长，如何维系上面提到的100余款内外部业务，快速发展下，我们面临着严峻挑战。除了传统的业务上线变更，站点可靠性、业务运营保障工作外，我们还需要做好业务用户体验质量的日常保障工作。

640?wx_fmt=png

综合来看，我们主要面临着三大挑战：

2.1 面临的三大挑战

2.1.1 业务多、形式多样

现在已有100余个内外业务，后续可以预见的是还会不断增加。而每个业务场景是不同的，比如帐号、应用市场、云相册、音乐、视频等。业务场景不同，带来的数据内容与格式都是多种多样的，这是我们面临的第一个实际挑战。

2.1.2 数据价值与数据成本间的平衡

第二个就是数据价值和数据成本之间的平衡，可以说这方面是数据团队一定要搞清楚的关键点，否则产品和团队都无法持续健康发展，这里我说下数据价值中的“熵”减问题。比如平时大家经常会碰到的成功率、转换率、到达率等指标，如果业务上报上来的数据就是这类“率”的指标，那么很不幸，熵减已经发生；比如想进一步看到业务版本分布、操作系统分布、地域分布等，比如以前想看到的是小时级数据，后续要提升到分钟级甚至秒级，是不是要重新做？这类数据变更成本要从源头来修改上报，成本是很高的。

另外，之前我们提到过用户体验保障工作，这里比如说，应用市场下载应用的时候，可能有一个总的下载成功率，但对于用户保障是远远不够的，比如总指标只降了0.5%不到，实际上对于某款应用上已经是10%等很高了；这也是所提到的监控指标的“煽”减问题。

随着大数据技术的发展，数据平台能力不断增强，这里必然会让我们在数据价值上做更多的事情，这背后就是技术变化带来理念和相关的变化。以前在采集端做统计的，一个数据的统计变更，意味着开发团队要出版本、运维要帮助上线，变更成本高、变现周期长，现在，这类变更落地在数据团队，其实已经是非常方便的。

2.1.3 数据规模大，增长速度快

这个挑战很好理解，业务增长速度快，运维数据价值变现程度高，那么带来的相关运维数据增长就会很快，比如去年底我们处理量已达到2000亿/天左右，现在一天处理数据量已增加到2600亿，而这这个增长只花费了三个月时间。17年3月开始做这套系统前，每天只有4T的数据，17年底已经是快120TB；不仅是对数据平台的处理能力要求越来越高，同时，随着数据的增加，这里还带来一个新的问题：以前数据量少，都是人去看数据的，随着数据越来越多，数据洪水带来的找价值数据成本也越来越高。这就是挑战三。