共计 7743 个字符，预计需要花费 20 分钟才能阅读完成。
如何解析基于 Serverless 的高可用大数据服务 MaxCompute，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
一、什么是 MaxCompute
Big Data in Alibaba
首先为大家介绍阿里巴巴大数据技术的一些相关背景。正如下图所示，阿里巴巴其实在很早的时候就开始布局大数据技术，甚至可以说阿里云的成立就是为了帮助阿里巴巴解决大数据相关的技术问题。如今，阿里巴巴几乎所有的 BU 都在使用大数据技术。而在阿里巴巴内部，大数据技术不仅应用范围非常广，同时也非常深入。此外，整个集团的大数据体系最终都会汇集到一起。
Overview of Computing Platform
阿里云计算平台事业部的职责就是将阿里巴巴的大数据体系汇集到一起，并且负责整个集团的存储、计算相关的研发工作。如下图所示的就是阿里巴巴大数据平台的简单架构图，最底层的是统一存储平台盘古，其负责存储大数据。存储时静态的，而为了挖掘数据的价值就需要依靠计算能力实现，因此阿里巴巴大数据平台也提供了各种计算资源，比如 CPU、GPU、FPGA 以及 ASIC 等。为了更好地利用上述这些计算资源，需要将他们统一地进行抽象，并有效地进行管理，而在阿里云内部，统一的资源管理系统称为伏羲。基于资源管理和调度系统，阿里云还开发了各种各样的计算引擎，比如通用计算引擎 MaxCompute、流计算 Blink、机器学习 PAI 以及图计算平台 Flash 等。在这些计算引擎之上，平台还提供了各种各样的开发环境，并基于这些开发环境实现了各种业务。
下面将为大家重点介绍通用计算引擎 MaxCompute。MaxCompute 是一个通用分布式大数据处理平台，其一方面可以存储海量数据，另一方面还可以基于数据进行通用计算。
首先看两个数字，目前，阿里巴巴内部 99% 的数据存储和 95% 的计算任务都由 MaxCompute 承载。其实，MaxCompute 就是阿里巴巴的数据中台，集团的各个 BU 所产生的数据最终都会汇总到 MaxCompute 上面，使得集团的数据资产得以不断增加。其次，再看几个指标。MaxCompute 在 BigBench 测试中的表现是一般开源系统的 2.5 倍。在阿里巴巴集团内部，MaxCompute 集群的机器数量达到了几万台，每天所承载的作业量更是达到了百万级别。目前，MaxCompute 集群所存储的数据量也非常大在很久之前就已经达到了 EB 级别，这在全球范围内都处于领先水平。此外，MaxCompute 不仅对集团内部提供服务，也开放给了外部企业使用，目前所提供的行业解决方案已经达到了 50 多套。如今，MaxCompute 的存储量和计算量每年都在以极高的速度增长，而借助阿里云的能力，使得 MaxCompute 不仅能够在国内进行部署，还能够部署到海外的很多国家和地区。
MaxCompute 系统架构
MaxCompute 的系统架构与业界的大数据计算引擎架构比较类似。如下图所示，用户能够通过一些客户端进行接入，通过接入层就可以将数据传输到 MaxCompute 里面。而在中间存在一个管理层，可以管理各种各样的用户作业，同时也会承载各种各样的功能，比如大数据里面最基本的 SQL 编译、优化和运行等功能。此外，MaxCompute 提供了分布式元数据服务，因为如果没有元数据管理，那么就无法知道数据存储的究竟是什么。在 MaxCompute 架构的最下面一层就是实际的存储和计算发生的地方。
二、MaxCompute Serverless 与背后的奥秘
如今 Serverless 这一概念非常火爆，而当站在 MaxCompute 开发者的角度，Serverless 的火爆既令人高兴，也令人郁闷。值得高兴的是：MaxCompute 技术团队早在 Serverless 概念提出之前的很多年就开始研发类似功能了，并且设计理念也完全符合 Serverless，这可以说明 MaxCompute 在 Serverless 方面的布局较早，并且技术具有一定的先进性。但令人郁闷的是：虽然 MaxCompute 团队很早就被提出了 Serverless 的相关概念，也认可这种技术路线的价值，但是却没有能够及早地将这样的能力包装起来。
在 Serverless 概念提出之前，大家进行大数据实践的时候基本都是按照下图的步骤，首先购买服务器，搭建集群，有了硬件之后就可以在上面安装大数据处理软件“全家桶”，之后导入数据，编写业务所需要的查询并做计算，最终获取结果。当然了，上述的每个步骤都离不开运维相关工作。如果自行搭建大数据系统，那么运维工作将会贯穿始终的，而对于运维同学而言，也需要时时刻刻待命，以防系统出现问题。
但是，如果回顾上述的步骤，真正能够产生业务价值就是第四步的编写查询和进行实际的计算，但是其他的步骤会消耗很多的资源和人力，而这对于偏向于业务型的公司而言，都是额外的负担。而如今，Serverless 就提供了帮助企业消除这些额外负担的机会。
以 MaxCompute Serverless 为例，只需要经过四个步骤就可以实现所需的业务价值。第一步开通账户并创建项目，这个项目既是数据存储载体，也是计算的载体；第二步上传数据；第三步编写查询语句并进行计算；第四步就可以获取计算结果。在整个过程中，无需任何运维工作，因此开发团队可以将精力集中在最为核心并且能够产生业务价值的地方，这也就是 Serverless 的优势所在。其实，这也代表了新技术对日常工作所带来的变化，新的技术使得大家能够更加专注于能够产生核心价值的部分，而无需关心额外的或者辅助性的工作。
和其他的开源软件或者大数据公司直接为客户提供一个大数据软件包的做法不同，MaxCompute 所提供的是大数据服务，而且所提供的服务能够实现 365（天）X 24（小时）的高可靠，既提供了大数据计算的能力，也同时提供了数据存储的能力，并且使得用户可以真正实现大数据技术的开箱即用。
在实现大数据平台 Serverless 服务的过程中需要面对很多挑战，丸趣 TV 小编将会主要聚焦以下三个问题：
大数据服务如何持续迭代和升级
大数据服务的趋势：自动化、智能化
数据安全
持续改进和发布中的挑战和方案
如果想要实现一套大数据系统，那么持续改进和发布的话题是绝对无法脱离。这是因为用户总会提出各种各样的新需求，而为了满足这些需求就需要不断地升级和改进大数据平台，而在改进的同时，还需要面对每天平台之上运行的百万级作业，并保证 7 *24 小时的服务不间断。那么，如何实现平台升级过程的平稳安全，并且使得用户对于新功能发布无感知，此外还需要保证新版本的稳定性，没有 Bug 和性能回退问题，以及在出现问题之后能够快速止损等，这些都是需要考虑的问题。此外，在持续改进和发布的过程中，还需要考虑测试和数据安全性之间的矛盾。总而言之，在大数据平台之上实现持续改进和发布，就如同在飞行的飞机上面更换引擎。
面对上述的问题和挑战，阿里云 MaxCompute 团队做了大量的工作。目前，在大数据领域，MapReduce 对于用户不够友好已经成为了业界的共识，类 SQL 的大数据引擎已经成为了主流。而对于类 SQL 的处理而言，最关键的就是三个步骤：编译、优化和执行。因此，MaxCompute 也抓住了问题的关键，针对编译和优化开发了 Playback 工具，针对执行则开发了 Flighting 工具。除了上述比较偏向于测试验证阶段所使用的两种工具之外，在真正上线的时候，MaxCompute 还提供了灰度上线等工具。
Playback 工具
Playback 诞生的背景就是 MaxCompute 需要快速地提高编译器和优化器的表达能力和性能优化水平。而在对编译器和优化器进行了重大改动之后，如何保证编译器和优化器没有问题就成为了一个挑战。最为原始的做法就是通过将一些已有的 SQL 放到编译器和优化器上执行，并通过执行结果的人工分析来发现编译器和优化器的改进中存在的问题。但是通过人工方式进行分析，可能需要一百年才能完成，这显然是无法容忍的。因此，MaxCompute 团队希望借助大数据计算平台的运算能力来自我验证新的编译优化器。
其原理就是利用 MaxCompute 本身强大且灵活的能力，把所有真实的用户查询收集起来并放到 MaxCompute 系统里面，将用户查询以大规模、分布式的方式运行起来，并通过新版的编译优化器来完成这些作业的编译和优化。而由于 MaxCompute 采用了业内通行的模式，因此能够很容易地将作业插件插入到任务之中，进而对编译优化任务进行校验，如果存在问题也能够很容易地暴露出来。
总结而言，Playback 一方面利用 MaxCompute 灵活且强大的计算能力来分析海量用户任务，另外一方面还借助对于 UDF 的支持和良好的隔离方案来进行编译优化和验证。这就使得对于新版本编译优化器的验证变得非常容易，对于之前想要实现但是却无能为力的任务，如今借助于大数据平台的强大能力得以实现。
Flighting 工具
Flighting 是针对于运行时的工具。其实，对于改进的优化器进行测试优化的常规做法就是搭建一个测试集群进行测试，这是最常规并且最自然的做法，但是也会造成极大的资源浪费，因为测试集群的成本非常大。由于测试环境与真实环境的任务复负载情况不同，因此，测试集群也无法真实地模拟出实际场景。此外，为了在测试环境中进行验证，需要测试人员来创造出一些数据，但是这些被创造出来的数据可能过于简单。否则就需要从真实场景中拿一些数据，但是这样做不仅需要经过用户的同意，还需要进行数据脱敏，这也是一件极其麻烦的事情。不仅可能产生数据泄露的风险，而且最终数据和真实数据也会存在一定的差异，很多情况无法验证出新功能所存在的问题。
而 MaxCompute 的运行时验证工具 Flighting 所使用的就是线上真实的集群和环境。借助于资源隔离的能力，使得 MaxCompute 集群中 99% 的计算资源交给用户来运行作业，而剩下的 1% 的资源交给 Flighting 工具进行执行器的新功能验证测试。这样的做法非常高效，不仅不需要拖取数据，还可以在生产环境中直接运行，可以容易地暴露出真实执行器所存在的问题。
灰度上线
MaxCompute 平台具有灰度上线的能力，可以将任务按照重要性进行分级，进行细粒度发布，并且支持瞬时回滚，这样就可以将风险降到最低。
MaxCompute 平台的持续开发验证迭代流程
如下图所示的是 MaxCompute 平台的持续开发验证迭代流程，其结合了针对编译优化器的 Playback 工具、针对运行器的 Flighting 工具以及灰度上线的能力。在这样的流程中，第二个周期并不需要等待第一个周期完成再开始，这样就使得整个研发流程更加高效。目前，MaxCompute 的持续开发和交付过程在编译优化、执行以及灰度等都具有较强的技术优势，在整个行业内也具有较强的技术竞争力，这就使得 MaxCompute 能够更好地向前演进，为客户带来更多更好的功能，同时也保证了 MaxCompute 平台在升级的过程中不会影响用户的正常使用。
自动化、智能化
随着人工智能和大数据技术的不断发展，如今对于服务而言，不仅需要实现高可用，还需要实现自动化。针对于这样的思想，可以从两个角度来看，即服务本身的角度和用户运维的角度。针对于服务本身，首先需要实现自动化，更进一步可以实现人工智能化。
任何服务都会出现各种各样的问题，存在各种各样的 Bug，在出现问题的时候，传统解决方案中需要依靠人力来解决。而服务自动化和智能化的终极目标就是在系统出现问题的时候，不需要人工来修复，而完全通过系统的自愈能力来发现并解决问题。而服务自动化和智能化的目标需要一步步实现，从用户运维的角度来看，就是从原本用户自身负责的运维工作，转交给完成大数据任务的云上大数据平台，比如阿里云 MaxCompute，这时候就相当于将客户的运维工作转移给了 MaxCompute 团队。而第三步就是 MaxCompute 团队也希望从大数据平台繁琐的运维任务中解脱出来，实现服务的自动化和智能化运维，进一步释放 MaxCompute 团队的精力，将全部的精力投入到更加有价值的工作上。而实现大数据服务自动化和智能化的目的在于提高服务可靠性，解放生产力，通过做更有价值的事情来回馈用户。基本思想就是定时地收集和监控服务的各项指标，针对异常指标及时作出应对措施。
除了大数据服务的自动化和智能化之外，对于用户查询而言，自动识别出可优化的查询并提供优化建议也非常关键。大家所写的 SQL 查询未必是最高效的，可能存在一些更加有效的方式或者更好的技术，因此需要自动识别出用户查询中可优化的部分，并给出相应的优化建议。对于这部分而言，也是业内的发展方向，目前 MaxCompute 团队也正在进行相应的研究工作。
三、MaxCompute 低成本的奥秘
低成本使得 MaxCompute 更加具有竞争力，而在低成本的背后，是 MaxCompute 发挥出技术红利使得成本确确实实地降低下来。为了使得大数据任务的成本更低，MaxCompute 主要在计算、存储和调度这三个方面进行改进和提高。
在计算方面，MaxCompute 优化了自身的计算引擎，能够提高性能，降低作业占用资源的数量，这两种做法都可以使得平台能够承载更多计算任务，每个任务要么能够减少计算时间，要么可以减少作业大小，最终降低计算任务所占用的资源，这样就能够使得更多的资源得以空出来，承载更多的计算任务。
在存储方面，也有各种各样的优化方式。比如优化压缩算法，使用比较先进的列式存储，对于数据存储进行分级，对于冷数据进行归档，对于没有价值的数据进行及时回收等。
在调度方面，为了降低成本进行优化方式主要包括集群内调度和跨集群全局调度。
对于集群内部调度而言，所需要解决的问题非常多。一方面，每时每刻都有很多的作业实例在等待调度，另外一方面还有很多资源等着运行作业。
集群内调度
那么如何将两者结合起来就显得非常关键，也非常考验调度能力。目前，MaxCompute 大数据平台的调度决策频率达到了 4000+/s，这里所作出的调度决策是将一定大小的作业放入到相应的资源中去，尽可能做到既能满足作业所需资源，又不能浪费资源。
在性能方面，需要支持增量式调度，使得资源能够得到很好地利用；此外，还提供了弹性配额能力，使得多用户在运行计算任务的时候可以实现削峰填谷。因为在真正使用大数据平台的时候，大家不可能同时提交任务，在绝大多数情况下往往会错峰提交任务，因此就会出现资源使用的峰和谷，而通过弹性配额能力可以尽量实现削峰填谷，使得资源能够充分利用。对于任务的最优化调度而言，则需要考虑延迟与吞吐之间的平衡。在负载均衡方面，需要规避一些热点。此外，MaxCompute 的调度决策系统还支持任务优先级和抢占，能够实现实时性和公平性。
此外，针对于复杂任务调度而言，还进一步划分了服务和作业的调度。这里所谓的任务就是一次性作业，而对于服务而言，在启动之后则会在一段时间之内一直不间断地处理数据作业。其实，服务和作业的调度存在着很大的差异，服务调度要求较高的可靠性，不能被打断，因为一旦被打断，重新恢复起来的成本将会非常高；而作业对于间断的容忍程度则要高一些，即使被打断，后续也可以拉起来继续运行。
二级配额组
对于单集群内的调度而言，重点介绍一下在一般的大数据平台中比较少见的二级配额组概念。在介绍二级配额组之前，首先介绍关于配额组的相关内容。简单而言，将物理集群的各种资源做成资源池之后，将一些资源整合到一个组里面就称之为配额组。在大数据平台上，作业就运行在配额组里面，而同一个配额组中的作业将会共享该配额组中的所有资源。而常见的一级配额组策略，存在着很多的问题。举例而言，如果一级配额组具有 1000 个 CPU 内核，而有 100 个用户在共同使用该配额组，某一时刻某一用户提交了一个非常大的作业，于是占满了整个配额组的 1000 个 CPU 内核，进而导致其他用户的作业全部需要等待。
为了解决上述情况中所出现的问题，就需要使用二级配额组。二级配额组在一级配额组的基础之上进行了进一步细分，设定了每个用户所能够使用的资源上限。每个一级配额组可以分为多个二级配额组，这样做的目的就是为了更好地利用资源。在二级配额组中，资源可以实现共享，但是即便某个用户需要使用的资源很多，也无法超过该二级配额组资源上限，因此可以比较好地保证用户体验。
与一般的大数据系统不同，MaxCompute 除了能够实现单集群内部调度之外，还可以实现多集群之间跨集群的全局调度，这也是 MaxCompute 强大能力的体现。单个集群可能会受制于各种因素而无法实现扩容，因此需要实现集群级别的水平扩展。
对于业务量巨大的应用而言，为了保证当单个集群发生宕机的时候业务依旧能够正常运行，所以需要让业务在多个集群上运行，来保证保证业务的高可用。这时候就需要全局的跨集群调度能力，当一个作业进来之后，需要分析该作业可以向哪些集群上进行调度，以及目前哪些集群可供使用并且比较空闲。而此时还会涉及数据多版本的问题，因为同一份数据存储在不同的集群之中，就会带来数据不一致的问题。此外，对于同一份数据的不同版本，也需要考虑应该具体的计算和数据复制策略，而阿里云 MaxCompute 也是经过了大量经验的积累才使得上述策略更加完善。
四、数据安全
对于一个企业而言，使用大数据计算平台时最为关心的就是数据安全问题。从阿里巴巴的经验来看，在数据安全方面，用户最为担忧的主要有三点，第一点：将数据放在平台之上，其他人能否看到；第二点：将数据放到平台或者服务之上，提供服务的人是否会看到数据。第三点：将数据托管到大数据平台之上，如果平台出现了问题，那么数据怎么办。
对于用户的这些忧虑，MaxCompute 都能比较完善地进行处理，用户基本上无需担心数据的安全性。首先，MaxCompute 平台具有完善的鉴权和授权机制，数据是属于用户的，而不是平台的，虽然平台帮助用户进行存储和计算，但是却不具有数据所有权，无论是对数据进行访问还是计算都需要鉴权和授权。无论是其他用户还是平台方，在没有授权的情况下，都无法看到数据。此外，授权的维度也比较多样，包括表级别、列级别和作业级别。而因为 MaxCompute 是云上大数据平台，天然地具备多租户的特点，因此需要实现各个租户之间的数据和计算隔离。对于数据而言，MaxCompute 平台实现了物理隔离，从根本上消除了数据的安全性问题。此外，平台还提供了严格的权限控制策略，用户无法查看其他用户的数据。此外，MaxCompute 还提供了 E2E 全链路存储加密，这对于金融机构显得尤为重要；还提供了 CRC 校验，保证了数据正确性，而且这部分能力已经在阿里巴巴内部使用了多年，已经非常完善；最后 MaxCompute 平台还为用户提供了数据脱敏等功能，方便用户使用。
关于如何解析基于 Serverless 的高可用大数据服务 MaxCompute 问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
