2017年双11再次创下每秒32.5万笔交易记录。这个数字的背后是每秒数千万次的数据库写入。如何实现大规模操作的自动化，保证数据库的稳定性，快速发现问题是一个巨大的难题，也是数据库管控平台要完成的任务。随着阿里巴巴数据库规模的不断扩大，我们在数据库管控平台建设上也经历了很多阶段。从脚本化、工具化、平台化到现在的DBPaaS，DBPaaS在今年的双11全面覆盖了集团及子公司下的本地数据库、公有云、混合云等各种场景。今年双11，数据库已经全面落地在容器化部署、线下资源灵活使用、公有云资源支持上有较大提升。全面优化的监控采集链路，实现全网所有数据库实例的秒级采集、监控、展示、诊断，每秒实时处理超过1000万个监控指标，让异常隐形。DBPaaS也在数据库管理的自动化、规模化、数字化、智能化等方面不断取得突破。其中，数据库监控系统的建设较为典型。在业务正常运行状态下，当线上系统出现故障时，如何在数以万计的数据库中发现异常并快速诊断，也是一项极具挑战性的工作。双11全链路压测期间，系统吞吐量未达到预期或业务出现RT抖动。快速诊断和定位数据库问题是一个实际问题。此外，对于复杂的数据库，如何在故障发生后查找故障根源、恢复现场、跟踪历史事件也迫使我们构建一个覆盖所有在线环境、数据库实例和事件的监控系统，以便至：覆盖阿里巴巴全球子公司所有机房。覆盖阿里巴巴生态圈，包括新零售、新金融、新制造、新技术、新能源的所有业务。涵盖所有数据库主机、操作系统、容器、数据库、网络。所有性能指标可在1秒级持续监控。全天候连续稳定运行。DBPaaS监控双11运行概览2017年双11期间，DBPaaS平台二级监控系统平均每秒处理1000万个性能指标，峰值1400万个性能指标。是分布在中国、美国、欧洲、东南亚的在线数据库，为实例的健康运行保驾护航。系统实现实时秒级监控，即任何时候，DBA同学都可以看到任何一个数据库实例在一秒前的所有性能趋势。DBPaaS监控系统仅使用数据库资源池中0.5%的机器就可以支撑整个采集链路、计算链路、存储、展示诊断系统。监控系统完整记录了今年的每一次全链路压测、每一次RT抖动站点，帮助DBA快速诊断数据库问题，为后续系统优化提供建议。双11大促保障期间，我们保证机器不扩容，服务不降级，让DBA同学喝茶过双11。在日常业务运营保障方面，我们也有7*24项服务能力。喝茶如何度过双十一要实现一个支持数万数据库实例的实时秒级监控系统，需要解决很多技术难题。据说已经演化出一个优秀的架构，随着规模和复杂度的增加，监控系统的建设也不断迭代。截至2017年，监测体系经历了四个阶段的完善。***代监控系统***代监控系统的架构非常简单。采集代理直接将性能数据写入数据库，监控系统直接查询数据库。随着数据库集群规模的扩大，简单架构的劣势也非常明显。首先，单机数据库容量的可扩展性不足。随着监控数据库规模的扩大，每天的性能指标写入量非常大，数据库容量捉襟见肘。长期积累的监控历史数据经常会触发磁盘空间警告，我们经常被迫删除前向数据。二是监测指标可扩展性不足。一开始，数据库监控项只有十几个，但很快就发现不够用了。因为经常有人拿MySQL文档说，我要看这个，我要看那个，能不能放到监控系统里。表现性能指标的前提是存储，而存储层的可扩展性缺陷让我们很头疼。对于这种功能需求，无论是宽表还是窄表，都有明显的缺陷。如果使用宽表，每次添加一批性能指标都需要执行DDL。预定义的扩展字段虽然可以缓解问题，但最终还是限制了产品的想象力。窄表在结构上解决了任何性能指标的存储问题，但也带来了增加写入数据量和扩展存储空间的弊端。***，系统整体读写能力不高，不具备横向扩展能力。以上种种原因催生了第二代监控系统的诞生。第二代监控系统第二代监控系统引入了DataHub模块和分布式文档数据库。数据链路从采集Agent到DataHub到分布式文档数据库，从分布式文档到监控系统。采集代理侧重于性能数据采集逻辑，构建统一的数据格式，调用DataHub接口将数据传输到DataHub。收集代理不需要关心性能数据存在于何处。DataHub作为连接节点，实现了采集和存储的解耦：对采集Agent屏蔽了数据存储细节，只暴露最简单的数据传递接口。DataHub根据存储引擎的特点，采用最佳的写入模型，如批量写入、压缩等。DataHub的水平扩展可以通过使用LVS和LSB技术来实现。分布式文档数据库部分解决了可扩展性问题，水平扩展用于解决存储容量不足的问题，schemafree的特性解决了性能指标可扩展性问题。随着监控系统的不断运行，数据库实例规模不断扩大，性能指标不断提升，监控系统的用户不断扩大，遇到了新的问题：DBA同学经常需要查看数据库的性能趋势跨越数月的数据库来预测数据库流量的未来趋势。这个时候系统查询速度基本就达不到了。存储完整性能数据一年的成本越来越难以承受。每年双11压测，DBA同学总是会问去年双11的性能趋势，DataHub存在采集数据丢失的隐患。由于原始数据先缓存在DataHub内存中，只要重启进程，内存中采集到的数据就会丢失。关于第三代监控系统查询速度慢，文档数据库和关系数据库一样，都是面向行的数据库，即读写的基础数据。性能数据每秒存储一行，一行有N个性能指标。性能指标存储在按时间键控的表中。虽然所有性能指标同时存储在同一行中，但它们之间的关系并不是那么密切。因为一个典型的监控诊断需求是查看同一个或几个指标在一段时间内的变化趋势，而不是同时查看指标（瞬时值），比如这样：为了找出性能某一个指标的趋势，数据库存储引擎，但是去扫描所有指标的数据，CPU和内存的成本是巨大的，很明显这些都是浪费。虽然ColumnFamily技术可以在一定程度上缓解上述问题，但是如何设置ColumnFamily是一个巨大的挑战。存储层的策略是否应该与监控诊断层的需求耦合？这看起来不是个好主意。因此，我们将目光投向了列式数据库。监控性能指标的读写特性非常适合列式数据库。以OpenTSDB为代表的时序数据库进入了我们的视野。OpenTSDB使用时间线，用时间序列描述每一个具体的对象，时间线的读写是独立的。毫无疑问，OpenTSDB成为第三代监控系统架构的一部分。为了消除DataHub稳定性的隐患，引入了分布式消息队列来削峰填谷。即使DataHub全线崩溃，也可以通过重新消费消息来解决。分布式消息队列，可以选择Kafka或者RocketMQ，这些分布式消息队列已经具备了高可用的能力。与过去相比，第三代架构有了很大的进步。2016年双11，实现全网数据库10秒级监控，核心数据库集群1秒级监控。随着阿里生态的扩大和全球化的深入，各全资子公司的业务已全面融入阿里体系。除中国大陆外，在美国、欧洲、俄罗斯、东南亚等地也有业务。与此同时，新技术在阿里巴巴数据库领域的应用层出不穷。部队部署已成为常态。容器化调度正在覆盖全网。存储和计算的分离在不断推进。同一个业务数据库集群在不同单元可能有不同的部署策略。相应的，DBA团队的规模也没有相应扩大。一个DBA同学支持多家子公司的业务很正常，有的DBA还负责新技术推广等工作。在数据库性能诊断方面，DBA需要力求效率，越来越迫切需要为DBA提供一条从宏观到微观到诊断的路径：从大磁盘到集群，到集群的一站式服务，units，toinstances，tohosts，tocontainer等等。在这样的诊断需求下，第三代监控架构有点力不从心，主要表现在查询上：高维性能诊断查询速度慢。以集群QPS为例。由于每个实例的QPS数据都存储在OpenTSDB中，当需要查询集群维度QPS时，需要扫描集群中每个实例的QPS，然后按时间戳分组，对所有实例的QPS求和，这就需要扫描一个大量的原始数据。OpenTSDB无法支持查看集群平均RT趋势等复杂的监控需求。集群的平均RT不是avg（所有实例的RT），而是sum（执行时间）/sum（执行次数）。为了达到目的，只能检测到2条时间线数据，在监控系统中计算出来，然后显示在页面上。用户响应时间过长。长期性能诊断缓慢。例如，要查看一个月的性能趋势，需要每秒扫描原始2,592,000个数据点并显示在浏览器中。考虑到浏览器的显示性能，实际上不可能也没有必要显示原始的秒级数据，显示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万个性能指标，平均写入600万TPS，峰值1400TPS万，下图是双11期间HiTSDBTPS趋势曲线，关键优化点用这么少的计算资源做到这么高的吞吐量，难免用了很多黑科技:在预计算中，我们采用增量迭代计算，无论是5秒精度的数据还是15分钟精度的数据，我们都不需要等时间窗口内的所有性能指标都采集完再开始计算；相反，我们只保留与性能数据一样多的中间结果，这大大节省了内存。与传统的计算方法相比，这种优化至少节省了95%的内存。在采集端，对性能数据包进行合并，将相似、相邻的数据包合并上报给Kafka，让JStorm程序对数据进行批量处理。利用流计算的特性实现数据局部性，同一集群单元的实例采集的数据在同一个Kafka分区中。这减少了计算期间的网络传输和Java序列化/反序列化。这个可以减少50%的网络传输。有兴趣的朋友可以想想为什么不能按实例分区，也不能按集群分区。会有什么问题？使用JStorm的自定义调度特性，可以让数据依赖的计算bolts在同一个JVM中被调度。这是为了配合上面的第二步，实现数据尽可能在同一个JVM中流转。对于不得不发生的Map-Reduce数据传输，尽量使用批量传输，对传输的数据结构进行复用和裁剪，减少重复数据的传输，减轻序列化和反序列化的压力。未来展望阿里DBPaaS的全网秒级监控，让数据库管控实现数字化。经过这一年，我们积累了很多有价值的结构化数据。随着大数据技术和机器学习技术的发展，为数据库管控走向智能化提供了可能：智能诊断，在现有全方位无死角监控的基础上，结合事件跟踪，智能定位问题。调度优化，通过分析每个数据库实例的profile特征，将多个资源互补的数据库实例调度在一起，最终节省成本。预算估算，通过分析数据库的历史运行状态，在每次大促前，根据业务交易量目标确定各数据库集群的容量需求，为自动扩容提供依据。吴必亮，姓名不详，阿里巴巴技术专家。2014年加入阿里巴巴，2015年开始关注数据库领域，目前负责阿里巴巴混合云数据库管控平台建设。从几分钟见证和推动阿里巴巴数据库监控系统的实现，对系统诊断和实时计算的深入研究。我对探索管控平台的数字化、智能化非常感兴趣。希望通过在这方面的深入研究，不断提升数据库在大规模场景下的稳定性，降低成本。欢迎志同道合的同学加入。
