生活宝|商城|团购|房产|招聘|外卖|交友|微博|汽车|同城|游戏|贷款|发稿|建站|软件|客服
上海论坛

2017双11技术揭秘—阿里数据库进入全网秒级实时监控时代

更新于 2018-1-2 15:12:22 507人阅读 0人回复 显示全部楼层 倒序浏览

a
0 0
  @ME:   
  • TA的每日心情
    慵懒
    昨天 11:58
  • 签到天数: 13 天

    连续签到: 1 天

    [LV.3]偶尔看看II

    发表于 2018-1-2 15:12:22 | 显示全部楼层 |阅读模式
    53快服 销量提升50%

    马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

    您需要 登录 才可以下载或查看,没有帐号?快速注册

    x
    摘要:
    2017双11再次创下了32.5万笔/秒交易创建的纪录,在这个数字后面,更是每秒多达几千万次的数据库写入,如何大规模进行自动化操作、保证数据库的稳定性、快速发现问题是一个巨大的难题, 这也是数据库管控平台要完成的任务。
    作者:吴必良(未立)
    前言
    2017双11再次创下了32.5万笔/秒交易创建的纪录,在这个数字后面,更是每秒多达几千万次的数据库写入,如何大规模进行自动化操作、保证数据库的稳定性、快速发现问题是一个巨大的难题, 这也是数据库管控平台要完成的任务。
    随着阿里巴巴数据库规模的不断扩大,我们建设数据库管控平台也经历了很多阶段,从脚本化、工具化、平台化到目前的DBPaaS,DBPaaS在今年双11中, 首次全面覆盖集团、各子公司下的本地数据库、公有云、混合云等多种场景。今年双11,数据库已经全面实现容器化部署,弹性使用离线资源、公有云资源支持大促。全面优化的监控采集链路,实现了全网所有数据库实例的秒级采集、监控、展现、诊断。每秒实时处理超过1000万项监控指标,让异常无所遁形。DBPaaS也持续在数据库管理的自动化、规模化、数字化、智能化等方向进行突破。
    在这其中,关于数据库监控系统建设比较典型。
    在业务平时运行态,线上系统出现故障,在数万数据库中,如何发现异常、快速诊断亦是一件非常具有挑战的事情。在双十一全链路压测中,系统吞吐量未达预期或业务出现了RT抖动,快速诊断定位数据库问题是一个现实课题。此外,对于复杂数据库故障事后排查故障根源、现场还原、历史事件追踪也迫使我们建设一个覆盖线上所有环境、数据库实例、事件的监控系统,做到:
    • 覆盖阿里全球子公司所有机房。
    • 覆盖阿里生态包含新零售、新金融、新制造、新技术、新能源所有业务。
    • 覆盖所有数据库主机、操作系统、容器、数据库、网络。
    • 所有性能指标做到1秒级连续不间断监控。
    • 全天候持续稳定运行。
    DBPaaS监控双11运行概况
    2017年双11,DBPaaS平台秒级监控系统每秒平均处理1000万项性能指标,峰值处理1400万项性能指标,为线上分布在中国、美国、欧洲、东南亚的、所有数据库实例健康运行保驾护航。做到了实时秒级监控,也就是说,任何时候,DBA同学可以看到任何数据库实例一秒以前的所有性能趋势。
    DBPaaS监控系统仅使用0.5%的数据库资源池的机器,支撑整个采集链路、计算链路、存储、展现诊断系统。监控系统完美记录今年每一次全链路压测每个RT抖动现场,助力DBA快速诊断数据库问题,并为后续系统优化提供建议。
    在双11大促保障期间,我们做到机器不扩容、服务不降级,让DBA同学们喝茶度过双11。在日常业务运行保障,我们也具备7*24服务能力。
    我们是如何做到的
    实现一个支持数万数据库实例的实时秒级监控系统,要解决许多技术挑战。都说优秀的架构是演进过来,监控系统的建设也随着规模和复杂性增加不断迭代,到2017年,监控系统经历了四个阶段改进。
    第一代监控系统
    第一代监控系统架构非常简单,采集Agent直接把性能数据写入数据库,监控系统直接查询数据库即可。
    随着数据库集群规模扩大,简易架构的缺点也非常明显。
    首先,单机数据库容量扩展性不足,随着监控的数据库规模扩大,日常性能指标写入量非常大,数据库容量捉襟见肘,长时间积累的监控历史数据经常触发磁盘空间预警,我们经常被迫删除远期数据。
    其次,监控指标的扩展性不足。一开始数据库监控项只有十几项,但是很快就发现不够用。因为经常有人拿着MySQL的文档说,我想看这个,我想看那个,能不能放到监控系统里。性能指标展现的前提是存储,在存储层的扩展性缺陷让我们头痛不已。对于这种功能需求,无论是宽表还是窄表,都存在明显的缺陷。如果用宽表,每新增一批性能指标,就要执行一次DDL,虽然预定义扩展字段可以缓解,但终究约束了产品想象空间。窄表在结构上解决了任意个性能指标的存储问题,但是它也带来了写入数据量放大和存储空间膨胀的弊病。
    最后,系统整体读写能力也不高,而且不具备水平扩展性。
    以上所有原因催生了第二代监控系统的诞生。
    第二代监控系统
    第二代监控系统引入了DataHub模块和分布式文档数据库。数据链路变成由采集Agent到DataHub到分布式文档数据库,监控系统从分布式文档。
    采集Agent专注于性能数据采集逻辑,构造统一数据格式,调用DataHub接口把数据传输到DataHub,采集Agent不需要关心性能数据存在哪里。DataHub作为承上启下的节点,实现了采集与存储的解耦。第一,它对采集Agent屏蔽了数据存储细节,仅暴露最简单数据投递接口;第二,DataHub收到根据存储引擎特性使用最优写入模型,比如使用批量写入、压缩等方式;第三,使用LVS、LSB技术可以实现DataHub水平扩展。分布式文档数据库部分了解决扩展性问题,水平扩容用于解决存储容量不足的问题,schema free的特性可以性能指标扩展性问题。
    第三代监控系统
    关于查询速度慢的问题,文档型数据库和关系型数据库一样,都是面向行的数据库,即读写的基本数据,每一秒的性能数据存储一行,一行N个性能指标,性能指标被存储在以时间为key的一个表格中。虽然同一时刻的所有性能指标被存在同一行,但是它们的关系却没那么紧密。因为典型的监控诊断需求是查同一个或几个指标在一段时间的变化趋势,而不是查同一时刻的指标(瞬时值),比如这样的:
    数据库存储引擎为了查出某个指标的性能趋势,却要扫描所有指标的数据,CPU和内存都开销巨大,显而易见,这些都是在浪费。虽然Column Family技术可以在一定程度上缓解上面说的问题,但是如何设定Column Family是个巨大挑战,难道要存储层的策略要和监控诊断层的需求耦合吗?
    所以,我们把目光投向列式数据库,监控性能指标读写特征非常合适列式数据库,以OpenTSDB为代表的时序数据库,进入我们考察视野。OpenTSDB用时间线来描述每一个带有时间序列的特定对象,时间线的读写都是独立的。
    毫无疑问,OpenTSDB成为第三代监控系统架构的一部分。
    为了消除DataHub稳定性隐患,引入分布式消息队列,起到削峰填谷作用,即使DataHub全线崩溃,也可以采用重新消费消息的方式解决。分布式消息队列,可以选择Kafka 或 RocketMQ,这些分布式消息队列已经具备了高可用能力。
    第三代架构相比过去有巨大的进步,在2016年双11实现了全网数据库10秒级监控,核心数据库集群1秒级监控。
    随着阿里生态扩大,全球化深入,各类全资子公司业务全面融合到阿里体系,除了中国大陆,还有美国、欧洲、俄罗斯、东南亚的业务。同时在阿里数据库领域的新技术应用层出不穷,单元化部署已经成为常态,容器化调度正在覆盖全网,存储计算分离正在不断推进,同一个业务数据库集群,在不同单元的部署策略可能也不同。与之对应的,DBA团队的规模并没有相应扩大,一个DBA同学支持多个子公司业务是常态,有的DBA还要兼任新技术推广等工作。在数据库性能诊断这个环节,必须为DBA争效率,为DBA提供从宏观到微观到诊断路径显得越来越迫切:从大盘到集群、到单元、到实例、到主机、容器等一站式服务。
    在这样的诊断需求下,第三代监控架构有点力不从心了
    DBPaaS新一代架构
    新一代架构,我们把OpenTSDB升级为更强劲的HiTSDB,同时基于流式计算开发的实时预聚合引擎代替简单的DataHub,让秒级监控飞。
    在职责界定上,监控诊断需求的复杂性留给实时预聚合引擎来解决,对时序数据库的查询需求都限定在一条时间线内。这要求时序数据库必须把单一时间线性能做到极致,由兄弟团队开发的阿里巴巴高性能序数据库HiTSDB做到了极致压缩和极致读写能力,利用时序数据等距时间戳和数值小幅变化的特征,它做了大量压缩。同时它全面兼容OpenTSDB协议,已经在阿里云公测。
    新架构让我们放开双手专注思考监控与诊断需求,不再受存储层的束缚。第一,为了高维度性能趋势查询性能,预聚合引擎做到了预先按业务数据库集群、单元、实例把性能指标计算好,写入HiTSDB。第二,建立性能指标聚合计算函数库,所有性能指标的聚合计算公式都是可以配置的,实现了自由的设定监控指标。第三,事先降时间精度,分为6个精度:1秒、5秒、15秒、1分钟、5分钟、15分钟。不同时间精度的性能数据,才有不同的压缩策略。
    实时计算引擎
    实时计算引擎实现了实例、单元、集群三个维度逐级聚合,每一级聚合Bolt各自写入HiTSDB。流式计算平台的选择是自由,目前我们的程序运行在JStorm计算平台上,JStorm让我们具备天生的高可用能力。
    实时计算引擎性能
    实时计算引擎使用了数据库总机器规模0.1%的资源,实现了全网秒级监控数据的计算,平均每秒处理超过1000万项性能指标,平均写入TPS 600万,峰值TPS 1400万,下图是双11期间HiTSDB TPS趋势曲线。
    关键优化点
    用这么少的计算资源就实现了这么高吞吐量,必然用上了许多黑科技。
    • 在预计算中,我们使用增量迭代计算,无论是5秒精度的数据,还是15分钟精度数据,我们不需要等时间窗口内所有的性能指标收集满了,再开始计算,而是来多少性能数据,就算多少,仅保留中间结果,极大的节省内存。这项优化,相比常规计算方法至少节省95%内存。
    • 采集端,针对性能数据报文进行合并,把相似和相邻的报文合并在一起上报到kafka,这样可以让JStorm程序批量处理数据。
    • 利用流式计算的特性实现数据局部性,同一个集群单元的实例采集到的数据在同一个kafka分区。这样可以减少计算过程的网络传输及java 序列化/反序列化。这一项可以减少50%的网络传输。有兴趣的朋友可以想想为什么不能按实例分区或按集群分区,会有什么问题呢?
    • 使用JStorm自定义调度特性,让具有数据相关性的计算Bolt调度在同一个JVM中,这个是为了配合上面第二步,实现数据流转尽量发生在同一个JVM里。
    • 对于不得不发生的Map-Reduce数据传输,尽量使用批量传输,并对传输的数据结构进行复用、裁剪,少传输重复数据,减少序列化、反序列化压力
    • 点击查看原文


    您需要登录后才可以回帖 登录 | 快速注册

    本版积分规则

    品牌广播台 更多>>
    便民工具
    返回顶部快速回复返回列表联系客服手机访问
    关于我们 | 联系我们 | 广告服务 | 网站导航 | 诚聘英才 | 友情链接 | 免责申明 |  帮助中心 | 手机访问 | 排行榜 | 小黑屋 | 设首页 | 加收藏
    © 2011-2017 上海论坛 版权所有 沪ICP备11017971号-7    在线客服 举报 郑重声明:本站只提供网上自由交流讨论,所有个人言论并不代表本站立场
    快速回复 返回顶部 返回列表