多租的安全性怎么保障？揭秘阿里云MaxCompute在多租上的实现--粉丝服务平台-粉丝头条-fensifuwu.com

多租的安全性怎么保障？揭秘阿里云MaxCompute在多租上的实现

科技 08-20 来源： DataFunTalk

本文配套PPT：https://pan.baidu.com/s/1koWishTDeMGkdOyiAPB5Ug（提取码: 0000）

导读：公有云大数据平台在多租户的设计和实现方式上有所差异。本文主要介绍在公有云大数据平台的多租实现方案中需要考虑的问题和挑战，重点介绍了MaxCompute在计算和存储多租实现上的特点。期望通过这些介绍来让大家了解大数据云平台多租方案需要关注的技术点和MaxCompute在多租实现上的产品特色。

全文将按照以下四部分内容展开：

大数据平台多租户形态
强多租的优势与挑战
MaxCompute多租实现
Why & 后续演进

大数据平台多租户形态

首先我们看下多租户形态，多租的概念大家可能有不同的理解，可以简单分为三类：

第一类，用户独享一个数据库实例，支持基本的基于角色的权限控制，比如云上的传统数据库，通常就是这种模式。在这种场景下从云平台的角度来看是支持多个租户的，但是每个租户购买的是独立的实例，在实例内部做角色划分，但是实例之间的数据是完全独立的。
第二类，是控制平面的多租，比如元数据和权限管控是多租的，但是计算资源是相对独立的，大数据的场景因为需要支持复杂的计算，通常会将计算资源单独拿出来管理。
第三类，是更广泛意义上的多租，share everything。从管控、计算到存储使用的都是多租的资源，也可以称之为强多租。

随着多租程度的提升，从用户的角度来看，系统的可扩展性越好，可以很方便地进行资源的扩缩容。但是云平台自身的系统复杂度会更高，而系统复杂度更高，可能会带来更多的稳定性问题。由于不同用户的作业运行在一起，安全性上的要求也更高，特别是在公有云的场景。

今天我的分享更多关注的是计算和存储的多租实现。关于管控方面，基于RBAC或者基于权限表的权限管理，行级列级权限也是大数据平台多租实现的一部分，但不是今天分享的重点。回到计算和存储的多租上，实现上会有不同的组合方式。

一种典型的形态是单租计算加开放存储的模式，比如AWS EMR和Databricks等。上图右边有一个databricks的架构图，我们可以看到，管控层面是多租的，而不同用户的计算资源是单租的，存储则用的类似AWS S3的开放存储。管控使用的是databricks的账号，而计算是跑在用户自己的vpc。

这种模式的优势在于：

由于计算资源是单租的，所有可以支持复杂的UDF，而不用太考虑安全的问题。
同时因为存储是开放的，可以很方便地将计算迁到其他云上，支持多云。

面临的挑战在于：

资源的粒度是租户级别的，需要提前购买，弹性扩缩容的能力依赖云平台的弹性。
多租云存储的读写效率问题，计算与存储的物理位置相对较远，可能还要经过网关，可能需要进行数据的预取和缓存。
计算过程产生的中间数据，因为性能的考虑，不能完全依赖云存储，需要考虑其他方式，比如内存或者本地存储的方式来保存。

BigQuery 和 MaxCompute 的实现比较类似，采用的是多租计算+内部存储的模式。计算和存储的资源都是多租的，计算和存储可以位于同一个机房内，物理位置比较接近。优势在于：

极致弹性，用户可以在不持有物理资源的情况下，运行大规模的任务，并且可以按照用户作业实际使用的资源收费。
内部存储的实现，计算和存储之间可以有大容量的带宽，可以充分利用底层存储特性来做优化。

这种模式的挑战在于：

UDF的支持：UDF是大数据场景经常会提供的一个功能，利用自定义函数的形式来支持复杂的计算。我们需要避免一个恶意用户的代码威胁到平台和其他租户的安全。这方面BigQuery和MaxCompute有不同的实现，BigQuery在udf的支持上相对比较克制，提供了js的udf，但是对能力做了一些裁剪，而MaxCompute则借助安全容器来支持了完整的udf能力。
云主机限制：在云平台上来实现安全容器会有二次虚拟化的限制，所以我们需要裸金属或者物理机这样的资源形态。

强多租的优势与挑战

介绍了常见的多租模式之后，我们来总结一下多租的优势和挑战。

多租的优势在于：

可以开箱即用，无需创建独立的资源池。
可以实现秒级扩容，极致弹性，单租资源依赖云主机的话，从资源的购买到软件环境的准备，可能要到分钟级别，而在多租的平台上可能只是一个配置的参数变更。
计费上可以做到按照实际计算开销付费，而单独计算资源池的收费是按照资源池的规格来收费，无论到底有没有使用。
在成本方面，多租资源池通过不同租户作业之间的削峰填谷，可以带来更高的资源利用率，而云平台将这部分让利给用户，可以带来成本上的优势。

当然多租户也面临着一些挑战：

首先存储方面，云存储需要解决远程读写和中间文件存储的问题，内部存储可以实现定制优化，但是存储的开放性是一个问题。
在资源调度层面我们需要保证不同租户，不同类型的作业在平台上能够得到公平合理的调度，支持超大规模的计算节点。
运行时方面，需要支持UDF或者三方引擎的场景，需要实现运行时的隔离，保证租户之间不会出现数据的越权访问，或者单租户的恶意代码影响到平台和其他租户的安全性。
同时对于用户定制化的网络需求，也需要在租户层面实现打通，不能够做集群层面打通。

我们通过一张图来直观地看下多租在安全性方面的挑战。单租的资源池通过iaas层来做隔离，云上每个资源是在独立的安全组中；而多租的平台上，多租户之间的隔离则需要大数据平台自己来保证。在这些挑战中，关于资源调度层面主要关注的是大规模场景下的性能和可扩展性，而安全则是方案是否可行的关键。如果无法保障多租的安全，对云服务来说是不可接受的。

MaxCompute多租实现

接下来，我们看一下MaxCompute产品在强多租方面的实践。

首先简单介绍下 MaxCompute 产品。

MaxCompute是阿里云提供的适用于大数据分析场景的，企业级的云数仓，提供的是全托管serverless的服务，在多租的实现上是一个强多租的实现。我们支持了SQL, java 和python的UDF，支持计算平台内部pai机器学习，同时也支持开源spark的任务类型。这些都是在统一的计算和存储资源上提供的。

存储方面，我们依赖自研的飞天存储引擎pangu；使用了基于capability的权限模型，在不直接对外开放访问的情况下，权限模型是可以简化的；由于是内部存储，我们可以实现分布式访问，避免中心化节点带来的性能瓶颈。同时对于作业运行过程中的临时数据，我们可以利用内部存储实现更好的local化和管理。

一个多租的资源池离不开一个好的资源调度引擎。

在资源管控的调度层面，我们实现了一套高效可扩展的资源调度系统，可以支持大规模的计算节点，同时保证不同租户不同类型的任务在平台上能够得到相对公平的调度，做了完善的failover的处理。资源的形态上我们提供了预付费和后付费的资源形态，预付费资源能够得到更多的资源保障，后付费的用户则按照资源的需求规格和时间的先后顺序进行调度。

在资源管控的主机层面，我们通过cgroup的机制实现了作业级别的资源管控，来保证一个作业的异常不会影响到其他作业。支持作业的不同启动方式，支持以进程方式或者容器方式拉起，也可以同时管理cpu或者gpu的资源形态。

基于灵活性和扩展性的考虑，MaxCompute 在 sql 语言里面支持了用户自定义函数即UDF的能力，方便用户对计算行为进行扩展，同时也引入了对三方引擎，比如 spark 的支持。这些对平台来说是不可信代码，可能触发非预期的系统破坏，或者恶意用户进行攻击。

我们通过轻量级的安全容器，实现了进程级别的隔离，也就是将不可信代码运行在安全容器内部。

在安全性上对vm内核进行了裁剪，去掉了不必要的内核功能，减少攻击面，并提供必要的防护机制；对网络上禁止了默认的外部网络访问；在启动速度上做了优化，虽然我们是一个离线数据计算平台，用户对时延没有那么敏感，但是对整个链路上的优化也是我们一直努力的方向；同时降低vm的资源使用量，提高单机的计算密度，同时能够运行更多的任务。

计算数据的读写，需要在vm内外建立高效的数据通道。考虑到MaxCompute的集群规模和大数据计算任务时间短的特点，对安全容器的稳定性和性能都有着比较高的要求。

我们有了隔离的安全容器之后，针对类似spark的任务，节点之间需要互相通信，类似spark的driver和worker之间需要进行任务的分发和状态的监控，而这些需求无法构建在主机网络之上，所以我们基于安全容器构造了vxlan的虚拟网络，让同一个任务的所有节点运行在同一个虚拟网络中，虚拟网络中的节点通过私网IP进行通信，无法访问主机网络。对于用户定制化的外部网络访问需求，比如常见的用户访问公网上的一个接口或者vpc内部的其他数据服务，我们也做了任务级别的网络打通能力。用户在作业启动时声明需要访问的网络目标，在必要的权限检查后，在任务级别实现网络的打通。

同样我们还要关注性能和稳定性的问题。云上vpc的创建通常也是基于vxlan的技术，但是vpc的创建是相对固定的，一个用户通常只有一个vpc，购买主机则是往vpc中添加节点，操作相对低频。但当我们面对一个大数据平台时，任务启停是非常频繁的，并且在短时间内拉起任务内的成百上千个节点，对性能上会有比较大的挑战。

在单一的资源池上通过强多租的实现，让更多的业务形态成为可能。

基于以上安全容器和虚拟网络的隔离，我们在一个多租的集群上提供了强大的UDF的实现，相对于其他平台提供的UDF，我们在UDF的能力上限制更少，允许访问本地IO和网络，能够访问用户vpc内部的数据。

比如湖仓一体的场景中，我们可以通过创建networklink的方式打通对用户vpc的网络访问，在创建外部数据源的时候关联networklink后，就可以在MaxCompute内部通过sql访问外部数据，目前这些在MaxCompute的平台上都已经做了产品化的实现。

任务级别的隔离，使得我们可以在单个集群内提供混合的计算形态，除了sql和udf的实现外，我们还支持了内部的pai机器学习平台和开源的spark引擎。

Why & 后续演进

最后分享一下我们对于多租实现的一些思考，以及后续的演进方向。

回到设计的初衷，我们为什么要在统一的计算存储的资源上实现了强多租。MaxCompute是一个内部孵化的产品，目前集团内部90%以上的离线数据都运行在Maxcompute的平台上。在业务形态上，我们期望兼容hive的udf生态和对开源引擎的支持，而源于集团内部对于数据安全的要求，所以我们一开始就是多租安全的。在面向公有云服务时，我们又期望在资源粒度，弹性和成本上提供优势，促使我们最终坚持了强多租的形态。

未来的演进方向有三大方面：

开放存储：我们是基于内部存储，开放性上会有一些问题，因此我们会在存储层面面对计算的场景进一步提升我们的开放性。
单租计算：多租的场景下，某个大客户的临时突发的大规模资源消耗对平台来说相对是不友好的，可能会导致其他用户的作业产生排队，所以在面对这样的客户时提供单租的计算形态也是一个选择。
多云：开放存储和单租计算将来也会向多云方向发展，为多云形态提供支撑，方便用户有更多的选择，用不同的组合去实现用户个性化的需求。

今天的分享就到这里，谢谢大家。

分享嘉宾：董国平阿里云高级技术专家

编辑整理：Liyao DataFun

出品平台：DataFunTalk

01/分享嘉宾