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

摘要：每秒实时处理超过万项监控指标，让异常无所遁形。此外，对于复杂数据库故障事后排查故障根源现场还原历史事件追踪也迫使我们建设一个覆盖线上所有环境数据库实例事件的监控系统，做到覆盖阿里全球子公司所有机房。所有性能指标做到秒级连续不间断监控。

摘要： 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的特性可以性能指标扩展性问题。

随着监控系统持续运行，数据库实例规模扩大，性能指标持续增加，监控系统用户扩大，又遇到新的问题。第一，DBA同学常常需要查看数据库跨越数月的性能趋势，以预估数据库流量未来趋势，这时系统查询速度基本不可用。第二，存储长达一年的全量性能数据，成本变得越来越不可承受，每年双11压测时，DBA同学总会问起去年双11的性能趋势。第三，DataHub存在丢失采集数据的隐患，由于采集原始数据是先buffer在DataHub内存中，只要进程重启，内存中的采集数据就会丢失。

第三代监控系统
关于查询速度慢的问题，文档型数据库和关系型数据库一样，都是面向行的数据库，即读写的基本数据，每一秒的性能数据存储一行，一行N个性能指标，性能指标被存储在以时间为key的一个表格中。虽然同一时刻的所有性能指标被存在同一行，但是它们的关系却没那么紧密。因为典型的监控诊断需求是查同一个或几个指标在一段时间的变化趋势，而不是查同一时刻的指标（瞬时值），比如这样的：

数据库存储引擎为了查出某个指标的性能趋势，却要扫描所有指标的数据，CPU和内存都开销巨大，显而易见，这些都是在浪费。虽然Column Family技术可以在一定程度上缓解上面说的问题，但是如何设定Column Family是个巨大挑战，难道要存储层的策略要和监控诊断层的需求耦合吗？这看起来不是好办法。

所以，我们把目光投向列式数据库，监控性能指标读写特征非常合适列式数据库，以OpenTSDB为代表的时序数据库，进入我们考察视野。OpenTSDB用时间线来描述每一个带有时间序列的特定对象，时间线的读写都是独立的。

毫无疑问，OpenTSDB成为第三代监控系统架构的一部分。

为了消除DataHub稳定性隐患，引入分布式消息队列，起到削峰填谷作用，即使DataHub全线崩溃，也可以采用重新消费消息的方式解决。分布式消息队列，可以选择Kafka 或 RocketMQ，这些分布式消息队列已经具备了高可用能力。

第三代架构相比过去有巨大的进步，在2016年双11实现了全网数据库10秒级监控，核心数据库集群1秒级监控。

随着阿里生态扩大，全球化深入，各类全资子公司业务全面融合到阿里体系，除了中国大陆，还有美国、欧洲、俄罗斯、东南亚的业务。同时在阿里数据库领域的新技术应用层出不穷，单元化部署已经成为常态，容器化调度正在覆盖全网，存储计算分离正在不断推进，同一个业务数据库集群，在不同单元的部署策略可能也不同。与之对应的，DBA团队的规模并没有相应扩大，一个DBA同学支持多个子公司业务是常态，有的DBA还要兼任新技术推广等工作。在数据库性能诊断这个环节，必须为DBA争效率，为DBA提供从宏观到微观到诊断路径显得越来越迫切：从大盘到集群、到单元、到实例、到主机、容器等一站式服务。

在这样的诊断需求下，第三代监控架构有点力不从心了，主要表现在查询：

高维度的性能诊断查询速度慢，以集群QPS为例，由于OpenTSDB里存储的每一个实例的QPS数据，当需要查询集群维度QPS就需要对扫描集群每一个实例的QPS，再group by 时间戳 sum所有实例QPS。这需要扫描大量原始数据。
OpenTSDB无法支持复杂的监控需求，比如查看集群平均RT趋势，集群平均RT并不是avg(所有实例的RT)，而是sum(执行时间)/sum(执行次数)。为了实现目标只能查出2条时间线数据，在监控系统内部计算完后再展现在页面中，用户响应时间太长。
长时间跨度的性能诊断速度慢，比如1个月的性能趋势，需要扫描原始的秒级2592000个数据点到浏览器中展现，考虑到浏览器展现性能，实际并不能也没必要展现原始秒级数据。展示15分钟时间精度的数据就够了。
上述提到的预计算问题，OpenTSDB也意识到，其2.4版本开始，具备了简陋预计算能力，无论从功能灵活性还是系统稳定性、性能，OpenTSDB都无法满足DBPaaS秒级监控需求。

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数据传输，尽量使用批量传输，并对传输的数据结构进行复用、裁剪，少传输重复数据，减少序列化、反序列化压力。
未来展望
阿里DBPaaS全网秒级监控让数据库管控实现了数字化，经过这一年，我们积累了许多有价值的结构化数据。随着大数据技术、机器学习技术的发展，为数据库管控进入智能化提供了可能性。

智能诊断，基于现有全方位无死角的监控，结合事件追踪，智能定位问题。
调度优化，通过分析每个数据库实例的画像特征，让资源互补性的几个数据库实例调度在一起，最终节省成本。
预算估计，通过分析数据库历史运行状况,在每次大促前，根据业务交易量目标，确定每一个数据库集群容量需求，进而为自动化扩容提供依据。
点击查看原文