微博广告 Hubble 系统:秒级大规模分布式智能监控平台架构实践

标签: dev | 发表时间:2017-07-03 00:00 | 作者:
出处:http://itindex.net/relian

关键词:微博广告 Hubble 监控平台 D+ 大数据 机器学习 LSTM Tensorflow


业务背景


Hubble(哈勃,其含义是数据如浩瀚宇宙之大,Hubble 如太空望远镜,能窥见璀璨的星辰,发现数据的真正价值)平台定位为 微博广告智能全景监控、数据透视和商业洞察


计算广告系统是集智能流量分发、投放、结算、CTR 预估、客户关系管理等为一体的大型互联网业务系统。随着微博业务的快速增长,广告系统复杂度越来越高,成千上万的模块需要不停地进行计算和通信,如何保证这么复杂的系统正常健康运行是一个巨大的挑战。


微博广告 Hubble 平台每日处理 TB 级别的监控数据和万级别的报警规则,Hubble 平台利用机器学习技术进行趋势预测和报警阈值的智能调整,保证商业产品上千台服务器和数百个系统及服务的正常运行。


下面我将详细介绍一下微博商业广告 Hubble 系统的设计原理及在智能全景监控实践中的一些思考。


核心问题


设计系统架构之前,应该首先从业务和系统等角度深度挖掘架构要解决的核心问题,对于监控平台而言,可以从平台化视角、业务视角及系统架构视角三个层面解析核心问题。


从平台化视角考虑,监控报警平台要解决的问题是


  • 是否能指导 RD 快速定位问题?

  • 是否为业务发展的预估提供参考?


从业务视角考虑,监控和报警平台所要解决的核心问题主要有以下几个方面


  • 监控指标:精准性和覆盖率(Accuracy and Coverage rate)

  • 报警:实效性和准确性(real-time performance and Accuracy)

  • 故障诊断(fault diagnosis)

  • 自动处理(Automatic processing)


从系统架构及设计视角考虑,监控报警平台要能解决:


  • 大数据分析处理能力,包括数据采集、ETL和数据抽象分析

  • 数据分析处理实时性

  • 大规模监控指标等时序数据存储、报警规则存储及报警触发

  • 高可用性

  • 数据聚合能力


简单的讲,Hubble 全景监控的核心功能包括提供基础监控、报警、预警服务,如图1所示。


图1 Hubble全景监控服务核心功能


整体架构


Hubble 平台的整体架构如图2所示。


图2 Hubble平台整体架构图


如图2,Hubble 整体设计包含三个层次


数据采集层(data collection layer)


数据采集层负责将系统日志、系统指标、业务日志、业务指标等数据进行实时采集。对于日志数据,支持 flume、scribe 等日志搜集工具,也支持 filebeat、metricbeat 等文件及指标搜集工具。


对于系统及业务指标,可以通过我们开发的 w-agent 客户端进行数据搜集,w-agent 是 Hubble 的轻量级、低资源消耗的数据采集工具,它作为微博广告标准基础工具集里的一部分,在服务器初始化时进行安装配置,通过 zookeeper 进行配置管理,支持远程更新数据采集配置和配置变更实时生效。同时,数据采集层支持通过 API 的方式直接提交数据,方便数据个性化定制以适应不同的业务需求。


数据分析层(data analyzation layer)


数据分析层负责将采集到的数据进行 ETL、预处理、分析和聚合。为了提高可用性,采集到的数据同时将写入 HDFS 进行持久化,数据分析层可以根据需要,从 HDFS 中 reload 并重新计算。另外,离线部分的监控预估模块会定时进行模型训练,并将训练后的模型存储在 HDFS 中。alert trigger 模块负责根据报警规则进行报警触发监测。


可视化层(visualization layer)


经过分析处理的数据写入到可视化层的存储系统中(Druid、ElasticSearch 和 MySQL),可视化层负责根据业务方需求,进行监控图表的展示、配置和管理,以及报警信息及规则的管理。另外,可视化层提供 APIs,允许第三方通过 API 的方式获取聚合分析后的数据以及对报警的管理。


三层各个模块相互协作,完成从数据搜集到可视化整个流程。


核心功能


监控指标


经常听到同学说系统处理百万级别的监控指标,以此来形容监控平台的处理能力,当然,这个数据在一定程度上可以反映监控平台的复杂度和能力,但是我们业务真的需要这么庞大的监控指标么?实际上,很大一部分的监控指标是毫无价值或多余的,这些指标要么根本无法真实反应系统或者业务的状态,要么可以直接被其他指标取代,要么是需要结合更多的信息来分析。


抽象出来,监控指标应该有以下几个分类。


机器(系统)指标


这部分指标,从机器资源角度,尤其是从硬件瓶颈相关的早期迹象并捕获硬件故障信号进行监控。抽象概括起来包括机器 CPU、Memory、Disk IO / Space、Net IO。


系统指标监测的目的是:


  1. 发现机器故障

  2. 限流与扩容


应用指标


应用指标分为基础应用指标和非基础应用指标。基础应用指标是指能被标准化和常见应用的监控,比如 Nginx / Apache 服务器的请求状态和 access 日志及端口、MySQL 数据库端口、Hadoop 集群运行状态等。非基础应用指标,指针对基础应用指标以外的应用指标,比如某个服务的端口号指标、进程个数等。另外,对于应用的日志抽取出来的指标,也可以归类于非基础应用指标。


业务指标


业务指标关注具体业务、产品的指标,如日收入走势、订单数、广告计划数等业务层面的。


智能化全景监控实践


基础监控


基础监控要求实时反应真实的指标波动情况,其中关键技术之一是对时序数据进行聚合,其聚合的粒度根据业务不同而有一定差异,当然也会因指标及数据处理量等因素制约。目前 Twitter、Facebook 等国外公司一般做的 30 秒甚至分钟级别聚合,大部分公司做到 10 秒级聚合已经满足业务需求。微博广告监控根据业务需求,对部分指标聚合粒度为 1 秒级。


基础监控底层使用 D+(Data Plus)平台提供实时的数据服务,其中 D+平台是微博广告商业数据基础设施,负责数据搜集、存储、监测、聚合及管理,提供高可用的实时流和离线数据服务,在 D+上可以对不同数据源及实时数据与离线数据的关联,关于 D+技术架构细节,后续文章会进一步分享。


D+的整体架构如图3所示。


图3 D+系统架构图


基础指标数据、日志数据会从 D+ 流出到 ETL 部分进行数据处理,然后输入到 Druid 提供上层 Graph 展示,同时输出一部分数据(日志)进入 ElasticSearch,以便后续查询,D+ 位于 Hubble 整体架构的 data collection layer 和 data analyzation layer,具体可结合参考图2。


趋势预测


目前很多企业都在尝试通过趋势预测的方式,提前预测系统或者业务的未来发展,以期望未雨绸缪,业内普遍的做法是通过统计学的方法,如 Holt Winter,ARIMA,3Sigma 等。


此类方法的特点是简单,能结合部分历史数据进行趋势预测,然而也有很多不足,如 ARIMA 算法的一个技术难点就是时间序列的平稳化,平稳化的时间序列对于预测结果的好坏起着至关重要的作用。另一个问题是滑动平均操作带来的结果如波动锯齿明显,容易造成误报干扰的化,则加大监控监测周期。


微博广告团队率先尝试通过机器学习的方法来预测系统指标的变化趋势,取得了一定的效果,目前已经应用于广告曝光量、互动量的趋势预测。


趋势预测的架构图4如下:


图4 基于机器学习的趋势预测架构图


主要分两部分:离线模型训练和在线计算。离线部分的数据来源是 HDFS 存储的历史指标数据,输出为模型;在线部分根据模型进行计算后导入到 Druid 进行存储和部分聚合,通过 dashboard 可以实时展示。


由于 LSTM(长短时记忆网络,RNN 变体)能很好抓住时间序列上下文可能存在的联系的特性,因此模型训练方面,我们选择了 LSTM 模型,Python 中有不少包可以直接调用来构建 LSTM 模型,比如 Keras,Tensorflow,Theano 等,我们选用 Keras 作为本文模型定义与算法实现的机器学习框架,选择 backend 为 TensorFlow,同时使用均方误差(mean squared error)作为误差的计算方式,并采用 RMSprop 算法作为权重参数的迭代更新方案。


图5展示了微博广告某产品曝光量(pv)趋势预测效果图。


图5 趋势预测曲线效果图


注:红色为训练数据;蓝色为实际值;绿色为测试输出


图6展示了微博某广告产品曝光量预测值与实际值偏差的占比分布。


图6 趋势预测效果图


可以看到,对于 pv 预测值与实际值小于 1000 的大概占比为 73%,小于 1500pv 的占比约为 96%,按照 1000 次曝光(pv量)转化为广告计量单位为 1CPM,1.5CPM 内的误差占比 96%。


然而,基于机器学习的趋势预测目前还不能很好支持对精度要求非常高的指标,如按点击收费的广告互动数指标。


动态阈值


系统报警往往结合监控来做,是指对于某个指标触发某一个设定阈值后向相关人员发送消息提醒。目前大部分的做法是固定阈值,这个阈值是根据经验设定,其优点是简单直接、操控性强,其缺点是经验值不准,设定的 GAP 太小,报警会增加,导致误报率增加,GAP 设置过大,又会导致漏报。另外,很多数据指标的波动成周期性变化,通过经验或者人工很难设定一个合适的 GAP。


对此,我们在趋势预测的基础上增加动态阈值,比如报警条件为趋势预测曲线上下10%,这个百分比可以根据业务进行调整。


服务全景图——两个维度


假设对监控平台的要求是只允许一到两个视图,来清楚的展现服务监控状态,把所有的需求和指标进行优先级排序,可以抽取出两个关键维度,即机器维度和服务维度。


机器维度


这个视图下,我们的核心是要清楚确定所有机器的基本状态,可以简化为:健康、亚健康和病态三种。健康的状态表示,机器资源使用(cpu、memory、netio、band、load 等)一切正常,可能未来一段时间(如 7 天)也会正常,机器使用者可以完全不用担心这部分机器;亚健康状态表示,机器资源存在一定风险,如高峰期网络 IO 太高,但仍然未达到影响机器正常运行的程度,机器使用者需要考虑机器 IO 类型或者扩容,以便应对短期可能产生的压力;病态是指机器已经出现某个资源的消耗上限,如磁盘满,需要机器使用者立即处理。


根据这样的需求,我们需要设计的是这样一个视图,如图7所示:


图7 服务全景图:机器维度


当某个机器有异常,能展示当前机器异常级别、时间及具体异常信息。


服务维度


在这个视图下,我们关心的核心问题是,业务应用运行是否正常,整个链路是否通畅,是否有异常和告警,影响了多少节点。能够查看命名空间下的所有关联服务上下游整体健康状态,针对异常节点可以展示异常原因和监控报表。


同时,结合自动化平台,将服务之间的上下游关系(拓扑图)进行展示,如图8所示。 


图8 服务全景图:服务维度


智能恢复触发器


恢复触发器的功能是在某条报警被触发时,由系统来进行一定程度的维护工作,比如降级或者迁移。其设定目标一定是要可扩展的,而且要能支持用户自定义触发器。


目前 Hubble 系统设计上只是简单支持了类似服务 restart、reload、stop 等标准触发器,还有不少的路要走。


后记


监控系统首要解决的问题是指标覆盖率,大而全,在此基础上做深耕,提高准确性,最后是精简和抽象,发现数据后面最本质的东西。微博广告基础架构团队在监控方面有一定的积累,并率先在监控中利用机器学习技术进行了一部分尝试,未来将在智能预测和服务自动化处理(降级、恢复等)方面进行更深入的尝试。


作者介绍


彭冬 Andrew(微博 @ AndrewPD,微信 justAstriver


新浪微博商业产品部架构师,目前负责广告核心引擎基础架构、Hubble 系统、D+ 商业基础数据平台建设及相关管理工作。关注于计算广告、大数据、人工智能、高可用系统架构设计。


IOTEP - 开放创新,崇尚技术,追求极致 Innovation and Open, Technical, Extremely Perfect


推荐阅读



本文作者彭冬,转载译文请注明出处,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构

改变互联网的构建方式


长按二维码 关注「高可用架构」公众号

相关 [微博 广告 hubble] 推荐:

微博广告 Hubble 系统:秒级大规模分布式智能监控平台架构实践

- - IT瘾-dev
关键词:微博广告 Hubble 监控平台 D+ 大数据 机器学习 LSTM Tensorflow. Hubble(哈勃,其含义是数据如浩瀚宇宙之大,Hubble 如太空望远镜,能窥见璀璨的星辰,发现数据的真正价值)平台定位为 微博广告智能全景监控、数据透视和商业洞察. 计算广告系统是集智能流量分发、投放、结算、CTR 预估、客户关系管理等为一体的大型互联网业务系统.

拭目以待,微博即将带来一场广告革命

- Elisa - 互联网的那点事
作者:互联网观察者欧阳俊 投稿. 许多人都会认为它是一种让任何人随时随地发布信息的平台,没错,其实创始人本意确实如此,不过现实远远走在了理想的前头,因为无论在东方或者西方,所有的微博平台都展现出同样的景象:人们都在微博上面寻找名人,关注名人,心甘情愿的成为名人的粉丝. 虽然人人都可以发布信息,但绝大多数的人发布的信息几乎无人在乎,而名人说的每一句话都有成千上万的人传阅,评论顷刻上千,转发动辄上万,因此,每一位名人都可以看作是布道者,而他们的微博就是名人们的布道台.

微博

- qianlaohu - 独立思考
无论名人在微博上讲什么,都能引起很大的“互动”. 王力宏说:“2011年过去一半了,7月了. 感觉就是这几百万人一起围在那里,紧张专注地看着,名人的微博一更新,至少挤在前排的几万人就激动拥抱:“动了. 说微博的迅速崛起会影响媒体,影响门户网站,影响SNS,其实都不对. 它首先威胁到蜡像馆,因为你在蜡像馆只能掏钱看不会动的,而在微博,不用掏钱都能看到会动的.

微博黑洞

- 洪涛 - 月光博客
  “黑洞”,光束经过它都会发生弯曲,甚至是被吸进去. 在我们已知的世界中,运行速度最快的光束也难逃黑洞的束缚,更不用说那些运行速度缓慢的物质. 从商业角度上讲,我们不妨把一束光理解为某个优秀品牌的数字营销行为(Digital Marketing). 如果这个品牌的数字营销做得够好,我们就可以用运行速度最快的光束来彰显其在行业中的领先地位,但这样的品牌毕竟是凤毛麟角,特别是在当今火热的微博营销领域中.

SNS OR 微博?

- ItTalks - 新媒体营销观察站
互联网的平台总是日新月异,在SNS还未开到荼靡时候,微博横空出世,如今已然后来居上,之前看到新生代调研机构关于SNS和微博的比对分析的结论,在此摘出部分并依据本人的想法调整后分享给大家:. 虽说微博目前发展迅速,很多用户尤其是圈子里的早已经从人人、开心转战,难免从心里忽视人人和开心,会忍不住怀疑那些曾经火热如今却觉得很SB的APP还有多少拥护者.

微博上市

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
昨日,市场上开始流传一则信息:新浪微博计划在纽交所 [i]上市,募集5亿美元的资金,上市预计在今年第二季度完成. 不过,由于当日MWC召开,市场又传闻阿里要收购整个盛大系,这则信息并不是各大科技频道或网站的头条. 微博早已从2011年的全社会关注热点顶峰位置跌下,的确是不争的事实. Twitter上市后,股价一路冲高,从40来元,直上70余高峰,然后开始回落,目前大致在55元处徘徊.

计算广告——广告定向实践

- - CSDN博客综合推荐文章
计算广告学涉及到很多的不同的学科知识,包括大规模搜索,文本分析,机器学习,信息检索以及经济学等等. 在计算广告中,其核心问题是在给定的环境下,找到用户和广告之间的最佳匹配,在斯坦福大学的计算广告学中如下的定义:. Computational advertising = A principled way to find the “best match” between a user in a context and a suitable ad..

Pepsi创意广告

- Homer - 设计|生活|发现新鲜
怎么样,看出广告的创意来了木有…………只是广告和现实总是风马牛不相及. 「设计,生活,发现新鲜」在新浪微博,更即时地获读更新,更直接地交流沟通. © 设计|生活|发现新鲜 | 原文链接 | 投稿 ! | 新浪微博 | 逛逛我们的在线商店. Creat: 佳洁士的创意广告. TOYO TIRES 系列创意广告.

微博八卦 3

- Melo - Never
文章标题:中微子超光速可以用量子弱测量解释嘛. 套餐窗口的食物每天都不同,有时印度,有时土耳其,有时德国. 很多时候我也不知道究竟是什么,就点了,吃的时候偶尔有小惊喜. 嗯,哥吃的不是午餐,是prediction error....... 随着fMRI数据大的量共享,最近搞了一个用静息态数据诊断孤独症的数据处理竞赛.

超雷人AV广告

- saiddy - 宅映像
由AV剪辑出来的视频片段,配上当前流行的各种广告的声音,要怎么YD就怎么荡漾,要怎么牛逼,就怎么花式……算了,我不解释了,大家自己看吧@. 一点小囧:今天我给电脑做体检了. 日剧山寨明星与范冰冰、刘德华、刘谦的那些事儿. 标签:AV, 囧, 广告, 恶搞, 搞笑, 艺术.