介绍阿里巴巴集团拥有庞大的数据库实例规模。在快速发展的过程中，我们也在不断面临运维管理的变革，从物理机到容器，从混合分布，从本地盘到存储计算分离，从集团内部到推广云资源，从开源MySQL到自研分布式数据库，运维管控进行了自我创新和进化。作者——谭宇（花名：毛奇），阿里巴巴资深技术专家。2009年加入阿里，对分布式系统和数据库领域有着浓厚的兴趣。目前负责阿里巴巴集团数据库中台建设，支撑集团数据库容器化、存储计算分离、离线混合、大规模迁移建站、智能运维等数据库技术的探索和落地。本文梳理了阿里巴巴数据库运维的发展历程，以及对未来数据库自治时代的看法。期待与您探讨。Text我在阿里已经快十年了。前五年，我做了一些分布式系统开发相关的工作。我参与的系统有TFS/Tair/OceanBase。在接下来的五年里，我专注于数据库运维平台和服务的建设，从搭建数据库集群开始。、数据采集等底层运维到外部客服、POC支持等，好的idea一直都是优秀的，再加上个人天赋平淡，不敢说有什么最好的idea，都在实践过程中的一些感悟，分享给大家，也是对过去一段时间的总结。你可能听说过很多关于阿里巴巴的数据库。阿里巴巴数据库技术的发展与整个集团的发展大同小异，从商用到开源再到自主研发。早在2009年，阿里巴巴的数据库或DBA团队就已经在业界小有名气，拥有多名OracleACE/ACEDirector，再加上自发的与业界交流、分享和撰写，建立了非常强大的影响力，很多人都是荣耀的时候我就被吸引加入了。当时，一些知名人士正在创业，也有一些还在集团的不同领域奋斗。他们的传说至今仍能在江湖中找到。后来有一股轰轰烈烈的去IOE的运动。刚进公司的时候，经常在内部BBS上看到各种成功除掉Oracle的帖子。基本套路就是配合DBA和业务开发，通过各种脚本把数据迁移到MySQL。在这个过程中遇到了很多问题，也在积极寻求各种新技术。比如为了突破磁盘性能问题，在主流还是机械硬盘的时候就使用了Fusion-IO，而且也是在MySQL内核上。各种改进开始了，AliSQL就形成了。关于IOE，他们各自的数据库核心技术，支持的业务的讨论很多。你可以找到他们各自技术相关的文章，但很少有人谈到他们背后有什么样的平台来支持这些业务变革和技术。迭代。过去5年，我和我的团队一直在做数据库运维或者服务。这个非常困难。相信如果你做过这种体验，你也会有同感。一方面，这是运维或服务系统的“原罪”。在此类系统形成的初期，它只是一个工具或平台。它的使命是很好地支持业务，实际上它本身并不产生价值。所有的技术都要在这里实现，而且实现之后好像跟你没关系，价值感比较弱。今天K8S等系统的出现，说明这也是可以做好的，但是相对来说，这是一个比较难做好的领域。另一方面，业务的复杂性，技术栈的多样性，以及它所依赖的组件，使得这个系统的实现难度很大。您需要逐层连接各个组件。从业务接入到数据库核心，再到底层网络、存储、OS、硬件等，任何一个层面的问题都会反映到你的系统中，实施人员将面临从上到下的各个层面的理解和异常问题到底部。处理需要极高的团队和个人能力。一个很具体的例子，我们的运维系统涉及前端、大数据处理、算法、数据库、底层软硬件等各个技术领域。在起步阶段，团队不可能拥有各个领域的专家，每个学生都需要了解和解决不同领域的问题。我想系统地介绍一下我们在这些方面所做的一些工作。主要包括三个方面：***，我们整个系统的发展过程，所谓以史观未来，不了解过去，就无法推断未来的自己会是什么样子。第二，现在的技术和产品，比如我们如何支持我们现有的工作，双11的推广等等。第三，从过去和现在出发，未来我们要做到什么。1、从历史看阿里巴巴数据库运维的未来发展，主要有这几个阶段。2009年之前，商业数据库为主，IOE才刚刚起步。之前没有整体的运维规划和运维平台。使用了各种脚本和工具。2009年以后，由于规模迅速扩大，这时候自然而然的出现了一些工具团队，把各种脚本拼凑起来，做一个界面，形成了最初的产品。然后，随着复杂性的进一步增加，以及云计算的推广。在交付方面有更高的要求，形成一个服务，比如DBaaS。近年来，随着大数据、机器学习等技术的发展，AIOPS催生了智能。在智能化的基础上，对各服务平台的服务质量提出进一步要求，即自治性。总的来说，有两大创新。第一次是从产品化到服务化。最初，我们的产品形成非常简单。没有平台，没有系统，大家工作的时候存一些脚本，到处分发。随着规模的增长，需要对原始脚本集进行管理。相信很多团队一开始都会成立一个工具组来做这件事。这会演变成一个团队制作工具，另一个团队使用工具，逐渐就会出现两者之间的差距。工具组有工具组的KPI，业务组有业务组的KPI，差异会逐渐变大。另一个问题是每个人都在节省工具和平台。因此，这些平台无法相互通信。例如，一个应用程序的开发需要数据库、搜索、分布式存储等各种系统。开发者需要一个一个申请，效率不高。正是在这种背景下，面向服务的转型发生了。我们提供的不是工具、平台，而是服务。这些服务是相互关联的，我们对所提供的服务有相关的SLA保证。这种创新可以说是云计算的基础。云计算的本质是IT资源交付技术的进步，这是云计算给我们带来的最大价值。第二次革命是自治，我们目前正处于这场革命中。对SLA或服务质量的追求是无止境的。现在很火的CloudNative和Serverless，本质上都是对更高服务质量的追求。提高服务水平，有两个关键点。一是规模。只有规模大了，才能做更多的事情。比如混合部署、智能调度、机器学习等，都需要一定的规模和海量的数据。这也符合当前云计算提供基础服务趋于中心化的趋势。规模也是问题的根源。管理1000个实例和管理100000个实例所需要的技术是完全不同的，所以还有一个关键点就是技术层面。有了规模，就要有相应的技术，比如容器化、机器学习、存储计算分离的改进、RDMA网络等技术。2、把理想变成现实当然，技术的积累是一个长期的过程，积累到一定程度就会产生质的变化。多年来我们在系统建设和技术积累方面做了大量工作。先来看一组数据，是刚刚过去的双十一数据库相关的一些情况。您可能已经看到一些数据，例如营业额和交易高峰。对于其背后的数据库，每秒有超过5000万次访问。特别是在高峰时段，读写比与平时不同。通常一般的系统读写比约为9:1或7:1。但是在双11高峰期，数据库的读写比可能是2:1。在写入比例很高的情况下，要求数据库不会出现任何抖动或延迟。我们对任何新技术的引进都非常严格。另外，阿里巴巴大促的场景非常复杂，包括线上和线下，还有国内外各种场景。基础设施分布在全球多地，同时由数十个机房支撑，系统复杂度非常高。综上所述，我们的业务场景一般具有以下特点：业务多样性。数据库团队作为数据库的中台，必须支撑集团的所有业务。包括核心电商、线下新零售场景和各独立子公司。不同的场景对数据库有不同的要求。比如线上场景要求高并发、低延迟、故障快速恢复。离线场景要求绝对可用性，访问和使用数据库的方式不受控制。但是，新加入阿里系统的收购公司，原有的运维体系，要求他们进行改动不太现实。总之，需求的多样性对数据库提出了很高的要求。基础设施多元化，数据中心遍布全球。有的用公有云，有的自建机房，有的用物理机，有的用Docker，弹性计算。整个集团就是一个超大的混合云。双11是一个超级热点。除了成本和性能，双11在灵活性方面也有很高的要求。我们也不可能为了双十一买那么多机器，太浪费了。早期会在不同业务线之间进行借用，比如从云端借机或者线下借机，大促后归还，都是靠人肉来搬机器。整个推广周期很长，人工和机器成本高。鉴于以上情况，我们形成了如下结构。主要思想是对下层屏蔽差异，向上层提供多样化的服务能力，中层围绕灵活、稳定、智能构建。由于种种原因，早期的运维系统没有设计好的架构，导致难以扩展，***越来越臃肿，推倒重构的情况屡见不鲜。今天，我们设计了面向服务的运维系统的总体架构：首先，我们可以清晰地组织和规范系统各个模块之间的交互，彻底解决原始工具时代遗留的问题，其中每个功能分散在不同的地方。整个系统的发展不再是历史的包袱；其次，它可以解决技术栈中太多的问题，从前端到底层的集合，算法分析，我们无法统一到一个框架和一种语言中。使这些模块相互独立，又相互影响，是整个系统加强的基础；第三，可以将整个系统的数据汇聚在一起，为后续智能化所需的统一数据和统一算法提供基础要素。四是可以对外提供形式统一、功能多样化的服务。服务化是强化服务体系的第一步。在底层，我们构建了统一的资源调度层，屏蔽底层计算、存储、网络资源的差异，向上交付标准容器。中间是数据库层。由于业务的多样性，各种类型的数据库运行在不同的环境中。我们通过统一的命令通道和采集通道的抽象来屏蔽这些差异。再往上就是传统的数据库运维层，包括常用数据库的生命周期管理，我们称之为乐高。我们希望像OPS这样的基础功能可以像乐高一样通过多种方式组合，快速搭建出我们想要的功能。它还包括用于数据收集、处理和存储的模块Kepler。我们希望实时收集所有运营数据，然后通过大数据处理、机器学习等手段发现深层价值。收集的数据包括操作系统、网络、存储和数据库的SQL。pipeline、性能指标等，处理的数据量非常大，要求所有指标都在秒级。每秒处理超过100G的原始数据包。再往上是智能决策层，完成预期故障、异常处理等自动修复和优化工作。也通过收集到的数据，做一些分析和决策。我们以服务的形式提供整个系统的功能，您可以在此基础上定制您想要的功能。过去几年，我们在架构实现上始终坚持“一个平台，一套架构，集团孵化，云输出”的策略。集团内部数据库管控平台提供服务，所有模块在一套架构下实现，产品由集团测试。然后开始在云上导出。不同的时代有不同的坚持。在智能化时代，我们也对这个结构和策略进行了调整，后面会提到。解决了架构问题后，这两年我们构建了几个能力，一个是容器化和存储计算分离，一个是快速弹性和混合部署的能力，第三个是大规模交付和智能化运营和维护。这些任务，都是能够发展成为集团数据库中台，支撑今天双十一的关键能力。最后，容器化是技术的量变到质变。容器的开创性技术并不多，各种技术的结合开辟了新的思路。所以，在把数据库放到容器里的时候，首先要突破我们的运维思维，坚信数据库是可以放到容器里的。当然，在这个过程中也遇到了稳定性和性能问题。比如当网络使用桥接模式时，CPU会有一定的提升。最终经过网络团队的不断优化，基本可以和实体机持平。容器化一方面解决了很多环境问题，另一方面也为数据库调度提供了可能。我们从2016年开始做数据库容器化，今年大部分数据库都跑在容器里了。第二，存储和计算分离。其实数据库本来就是一个存储和计算分离的架构。在互联网时代，这个架构一开始就遇到了瓶颈，因为互联网时代的扩容非常快。然后出现了分布式系统，将计算转移到数据所在的位置。但是随着技术的发展，尤其是云交付方式的发展，存储计算分离的交付更加便捷。交付多少计算能力和存储空间一目了然。此外，存储和计算的发展也不平衡。比如双11的时候，我要求算力，但是存储并没有增加多少。所以随着技术的发展，我们的圈子基本上已经倒退了。当然，要不要把存储和计算分开，我们讨论了很久。今天，存储和计算分离的决定是正确的。这个过程中遇到的问题也很多，主要是延迟的问题。毕竟经过一层网络后，IO时间会增加。我们从左边的架构开始，在本地挂载远程存储。这个延迟远大于本地盘，核心业务无法接受。在此基础上，我们大规模引入了RDMA网络，通过DBFS bypass如果去掉内核，延迟基本可以和本地盘相当，所以今年所有核心业务都会跑在这个架构上.在容器化和存储计算分离的基础上，可以更好的解决弹性问题。以前我们的灵活性主要靠搬数据、搬机器，现在不需要搬数据了。我们这次大促用的机器主要来自两个地方，一个是线下资源，一个是云端资源。我们把云资源用完了，还可以继续对外卖。众所周知，双11的高峰期主要在午夜。所以，我们在高峰期弹性扩容，高峰期结束后立即缩容，把机器还给别人。结合集团调度，我们构建了混合部门调度系统，可以实现数据库的快速升降。今年我们的核心集群可以在10分钟内完成弹性伸缩，我们的最终目标是1分钟内完成。三、分娩诊断。我们说云计算是IT资源交付能力的提升。我们已经基本完成了数据库资源对用户的交付，开发者可以通过系统自行完成数据库资源的申请和使用。如果我们只把交付理解为用户自助获取数据库资源，就已经做得很好了。但该集团有更苛刻、更复杂的交付任务。比如下面两个例子：大促期间需要扩容几千甚至几万个数据库实例，大促结束后需要缩容。每年都有固定或临时的建址和搬迁作业。比如今年的一路北上和张北多站点建设，可能涉及数万个数据库实例，数十PB的数据。这些都非常考验我们的交付能力。之前的套路是让人评估，确定要操作的数据库范围，计算需要多少机器资源，如何安排等等，然后通过我们提供的迁移操作完成迁移。人类需要控制每一个步骤，这是一项相当繁琐的工作。一年要做几次，在我们要求快上快下的今天显得特别无能为力。因此，我们提出了软件定义部署的概念，类似于我们常说的编排。有两件事要做。一是准确定义和记录我们的操作，线上的操作环境也可以用代码准确定义。二是将中间的机动步骤交给系统。人们只需要描述最终状态。当我们的预测准确到一定程度后，这个最终的描述状态也可以由系统来完成，真正完成大促的自动投放。可以看出我们的环节其实很长，中间各个组件的问题很难诊断出来。Gartner有一个术语叫做AIOPS。相信大家都听说过。其实Gartner很早就提出了AIOPS。起初，它指的是基于算法的运维。随着人工智能技术的发展，他改变了这个词的措辞。但本质没有变。还是靠大数据和算法来改变OPS。应该说这也是一个简单的概念。大约在同一时间，我们也提出了这个想法。最开始叫data-driven，后来改名为operationaldata，dataoperation。它还使用各种算法，例如基线、异常检测、关联分析、趋势预测等来自动做出决策或协助我们进行决策。这就是CloudDBA的初衷。首先，对收集到的各类数据进行聚合、预处理，加入领域知识和算法，打通用户到DB、DB到底层硬件的两条链路。双11期间也可以实时诊断接入链路，当然这里还有很多东西有待发现，现在可以说应用的只是非常少的一部分。***，我把以上都集成到一个产品HDM中，全称是混合云数据库管理平台。根据Gartner的一份报告，到2020年，85%的企业将使用混合云架构。这与我们的判断是一致的。前面提到阿里巴巴集团是一个超大型的混合云，所以我们推出了HDM来帮助企业整合混合云数据库架构。HDM主要提供两大功能。一是统一管理，无论是云上云下还是其他云上的数据库，都可以统一管理、统一诊断。二是弹性扩张。一键上传数据库到云端不再是梦想。在数据库层消除本地IDC和云端的区别。HDM提出后有一段时间，我认为它基本上是数据库服务的未来。但是近几年无论是数据库领域还是运维领域都在飞速发展，我们似乎已经到了一个技术集中度爆发的时间点。一方面，新的软硬件技术，如容器、高速网络、机器学习等，另一方面，云计算的发展也在不断推动我们提供更好的交付和服务。3、智能化之路：自治数据库平台包括数据库领域的自治数据库和智能数据库，以及运维领域的AIOPS。这对数据库运维意味着什么？结合过去和现在的情况，我们提出了一个自治的数据库平台。这个定义已经被很多人讨论了很长时间。首先是平台的能力和目标。我们希望实现自动驾驶。简单地说，它不需要人类参与。要做到这一点，就需要具备自感知、自决策、自恢复、自优化四大能力。二是平台可以为数据库赋能。今天的现状是，我们使用的数据库种类繁多，我们不能为了自治而对每一个数据库都有很高的要求。我们可以对能力进行分类。我们还有一个非常明确的业务目标，就是阿里巴巴数据库事业部负责人公开的目标：到2020财年年底，阿里巴巴集团85%的数据库实例要实现自动驾驶。我为此设置了两个评价指标。一是没有人收到这些数据库的告警，二是稳定性要达到99.995%。有了目标，如何实现呢？首先，自主是技术从量变到质变的过程。过去一段时间，我们应用了大量的新技术，包括存储计算分离、大数据处理和机器学习等，掌握这些技术是实现自主化的基础。有了这些技术，我们仍然需要创新思维，就像今天的电动汽车或自动驾驶，由传统制造商制造的，似乎并不尽如人意。一方面是固定思维，另一方面也有其历史包袱。我们需要摆脱这些。比如我们以前的数据、运维、资源都是分离的。所谓自动处理就是先接收到一个告警，然后根据告警的内容进行自动化处理。显然，没有办法形成一个统一的整体。今天我们需要先搭建整个框架，然后让数据和算法来丰富和润滑整个系统。此外，还需要专业知识。数据库是一个专业性很强的系统，之前可能是DBA和内核开发人员调整过的，靠的是数据、试错、经验。如何把这些知识精确化、数字化，让系统也能具备这些能力，是我们要努力的方向。***，重点是不断提升原有的基础能力。这并不意味着我们今天的智能和自主权是数据和算法。其他基础能力同样重要，比如OPS。我们提出一个ad-hoc的实现：如果决策模块决定对全网内存水平高于95%的数据库实例执行一个动作，你需要能够快速执行。我们目前正朝着这个方向前进。预计我们将很快实现一些数据库实例的自治。欢迎有兴趣的同学加入建设，共同迎接自治时代。
