看完伯克利的Sky Computing论文后,整理一下部分论文中所描述的细节内容如下:
Sky Computing 只是由云间代理中介的云计算(见下图)。在 Sky Computing 中,⽤⼾不是直接与特定的云交互,⽽是将作业及其描述发送给跨云代理,然后由跨云代理选择运行作业各个部分的云,然后管理它们的执行。因此,云间代理在提供⼯作的⽤⼾和提供服务的云之间创建了⼀个双向市场。其中许多服务(例如,Kubernetes、Apache Spark、Apache Kafka)由多个云提供,⽽其他服务是特定于云的(例如,AWS Inferentia、BigQuery)。我们预计会有多个跨云代理,其中⼀些可能专⻔针对不同的⼯作负载。
Sky Computing由三层组成:
一层是用来掩盖低层次技术差异的兼容层。
一层是用来将作业路由到正确的云的云间层。
一层允许云彼此就如何交换服务达成协议(对等层)。这三层反映了互联网本身的设计—例如,互联网协议(IP)提供了网络间兼容性。
实现 Sky Computing 愿景的第一步是提供一个云兼容层,通过抽象出云计算服务,使在该层之上开发的应用程序无需更改即可在不同的云上运行。简而言之,兼容层是一组可以构建应用程序的接口或 API,然后可以通过云平台的一组接口将该兼容性层移植到每个云。
该层可以类比于互联网中的 IP 层,然而与 IP 层不同的是,云兼容层明显更广泛且定义不明确,因为云平台向应用程序提供了丰富的一组服务,包括计算、存储、数据传输等。 因此,云兼容层更像一个操作系统(例如 Linux),可以管理计算机资源并向应用程序提供 API。
如何构建这样一个云兼容层? 虽然每个云平台都提供一组专有的低级接口,但目前大多数用户主要与更高级别的管理和服务接口交互。其中一些是专有的,但已经有越来越多的接口受到开源软件(OSS)的支持。此外,涌现出大量由 OSS 创建者创立的公司,以在多个云上提供托管服务。如果企业的应用程序使用这些基于多云 OSS 的产品,从一种云切换到另一种云就能变得相对容易。
兼容层可以从这些 OSS 解决方案中构建出来。例如 Cloud Foundry,是一种开源多云应用平台,支持主要的云供应商以及内部部署集群。 以及 RedHat 的 OpenShift,是一个基于 Kubernetes 的多云和内部部署平台。因此,从纯粹的技术角度来看,实现一个能够广泛使用的兼容层是很容易的。问题是市场是否会支持这一发展。因为虽然兼容层对用户有明显的好处,但它自然会使云平台商品化,这可能不符合供应商的利益。
(i)降低云使⽤的障碍,从⽽扩⼤整个云市场;
(ii) 通过专⽤云进行快速技术创新(这将使⽤⼾能够获得最佳服务和硬件);
(iii) 更完整地集成各种计算选项(例如,边缘计算、本地计算和单个云中可⽤区域的选择);
(iv) 通过跨云部署增强合规性、安全性和弹性的机会(例如,在多个云中托管模型推理以提⾼可⽤性,或在需要时处理机密数据以满⾜新的监管约束,例如数据和运营主权)。
兼容层只是实现 Sky Computing 愿景的第一步。即使兼容层允许用户在不同的云上运行应用程序,用户仍然需要决定在哪个云上运行应用程序,需要在不同云之间进行性能/成本权衡。这类似于要求互联网用户为其域间流量明确选择 AS 路径,为了解决这个问题,Internet 使用 BGP 来做出 AS 级别的路由决策。同样,Sky Computing 应该实现一个云间层,从用户中抽象出云供应商;也就是说,用户不需要知道应用程序在哪个云上运行。 云间层是在兼容层之上实现的,如下图所示。
通过云间层,用户可以指定有关其作业应在何处运行的策略。这些策略允许用户表达他们对性能、可用性和成本之间权衡的偏好。此外,用户可能希望避免他们的应用程序在竞争对手运营的数据中心上运行,或者留在某些国家/地区以遵守相关的隐私法规。并且云间层也可以实现更安全的应用。
作者相信在兼容层之上实施云间层没有基本的技术限制。因为,从性能的角度来看,跨云移动作业与跨数据中心移动同一云平台中的作业非常相似。一旦应用程序被设计为跨多个数据中心运行,剩下的跨云问题可以通过以下三个功能来解决:
(1) OSS 服务的统一命名方案。
(2) 目录服务,允许云供应商注册他们的服务,并允许应用程序根据他们的喜好选择服务。
(3) 跨云计费机制。
服务命名方案:为了识别在特定云上运行的服务实例,需要一个命名方案来识别该实例。 一种方案是利用 DNS 来命名这些服务实例。 此外,需要将元数据与每个这样的服务实例相关联。此类元数据应包含应如何调用服务、云供应商的名称、位置、软件或 API 版本、硬件类型等。此外,可能还需要添加动态信息,如定价、负载和可用性。
目录服务:需要特定服务的应用程序必须找到满足其要求和偏好的服务实例,这需要目录服务。 每个云供应商可以通过提供名称和元数据信息将服务发布到该目录。此外,云供应商应定期更新其动态元数据,例如负载和定价。反过来,应用程序应该请求能够表达其偏好和要求的特定服务。收到此类请求后,目录服务将返回满足这些要求和偏好的实例。
计账和计费:通过 Sky Computing,用户的应用程序可以运行在多云中的一个云上,甚至同时运行在多个云上,每个云平台都必须对所使用的资源进行核算。 如果每个云平台都进行计费,那么用户需要在每个云上都有账户。有一种替代方案,让每个用户都与第三方签约,并累计费用,然后将每个用户的付款分配回各个云平台。
●服务目录:
该⽬录是云⽣态系统中服务接⼝的列表,以及⽀持每个服务的云集。每个(服务,云)条⽬都包含有关如何在该云上实例化和管理服务的说明以及⼀些价格和性能信息。代理控制服务⽬录中的信息,但它可以基于来⾃云和各种第三⽅的输⼊。
●Job API:
此 API 允许⽤⼾指定他们的作业(输⼊数据所在的位置、需要什么处理、数据如何流动等)以及他们
的优化指标(例如,成本或延迟)和约束(例如,流程数据)在特定国家的边界内,或在给定的响应时间内)。
●优化器:
给定⽤⼾的⼯作规范和要求,优化器⽣成最优的物理执行计划执行(例如,选择哪些云、实例类型和实例数量,计划还可能涉及或许还有这些云中的哪些位置)。
●数据编排:
处理存储在特定云区域中的数据有两种⽅法:在同⼀区域中运行计算阶段,或者在不同区域(可
能还有云)中运行阶段,但⾸先将数据移动到该区域。数据编排负责将数据移动或复制到优化器决定运行阶段的区域(请注意,优化器已将此类移动的成本和延迟考虑在内)。
●提供者:
负责跨云分配资源以执行物理计划。如果 Provisioner 未能在云上分配资源(或区域)由物理计划指定(例如,因为所需的资源不可⽤),它可能会要求优化器⽣成另⼀个物理计划。
●Executor:
Executor 编排资源上的物理计算计划由供应商分配,检测和重新启动故障并提供⼀定程度的故障排除。代理可能会使⽤⾃⼰的⾃定义执行器组件或商业上可⽤的编排和监控服务之⼀。
●计费服务(可选):
客⼾使⽤ Sky 的计费⽅式有多种可能性,我们预计⼏种不同的模式将共存。在某些情况下,每
个云都会直接向⽤⼾收取他们运行的部分⼯作费⽤。在其他情况下,云间代理可以提供⾃⼰的计费服务,在这种情
况下,它将与每个云提供商签订合同,代表⽤⼾⽀付作业执行费⽤,然后向⽤⼾收取总费⽤。
●身份和访问管理(IAM):
此组件将根据⼯作的性质⽽有很⼤差异,但⾄少⽤⼾必须向⼯作提供输⼊数据,这可能涉
及传递⼀些令牌或其他形式的凭据到云间代理。 Sky 还可以利⽤⼀些现有的多⽅⾝份协议和服务,包括Kerberos,全球认证,或商业产品,如Okta。
云间层旨在最能满足其需求的云(或多个云)上运行作业。如果作业涉及大型数据集,需要将数据移动到将发生计算的云中。目前大多数云平台都有定价政策,将数据传入云中比将数据移出要便宜得多。例如,将数据提取到 AWS 是免费的,而将数据从 AWS 传输出去可能需要 0.05-0.09 美元/GB。作者将这种定价形式称为“数据引力”定价,它驱动用户在当前所在的云平台中处理数据。 尽管如此,对于一些计算资源比数据传输成本高得多的工作,将数据从一个云移动到另一个云仍然是最划算的选择。
目前,导出数据的定价政策与数据可能要去的云无关。作者提出**“互惠数据对等”方案**,迄今为止还没有看到对此类方案的探索。在这种方案下,云间可以通过建立高速连接互相免费传递数据。使数据传输又快又便宜,降低两个同级云之间的数据重力,并实现更大的工作流动自由。
联邦机器学习(Federated machine learning/Federated Learning),又名联邦学习,联合学习,联盟学习。联邦机器学习是一个机器学习框架,能有效帮助多个机构在满足用户隐私保护、数据安全和政府法规的要求下,进行数据使用和机器学习建模。联邦学习作为分布式的机器学习范式,可以有效解决数据孤岛问题,让参与方在不共享数据的基础上联合建模,能从技术上打破数据孤岛,实现AI协作。谷歌在2016年提出了针对手机终端的联邦学习,微众银行AI团队则从金融行业实践出发,关注跨机构跨组织的大数据合作场景,首次提出“联邦迁移学习”的解决方案,将迁移学习和联邦学习结合起来。据杨强教授在“联邦学习研讨会”上介绍,联邦迁移学习让联邦学习更加通用化,可以在不同数据结构、不同机构间发挥作用,没有领域和算法限制,同时具有模型质量无损、保护隐私、确保数据安全的优势。
现有的联邦学习模型并行中,模型被均匀分配给各个训练设备。然而,由于联邦学习的训练设备往往是用户的智能终端,性能差异较大,使用均匀分配,往往会造成通信时间瓶颈。
正如我们都知道木桶效应:木桶的盛水量由最短的那块木板决定。而在传统的联邦学习中,存在类似现象:训练速度由最慢的那个设备决定。
Sky Computing 针对联邦学习的痛点,通过负载均衡,将不同规模和能力的云服务器智能互联,达到大规模计算的算力需求,同时通过联邦学习的方式,仅在云服务器内部访问用户数据,避免数据迁移和隐私泄露。
在计算机中,无论进行哪种操作,究其本质,负载都可以理解为「完成任务所需的时间」。由于在联邦学习中,训练模型的计算总量是固定的,因此如果我们能通过自适应的方式智能分配计算任务,便能够使得每个设备完成计算任务的耗时相同,确保整体训练的时间最优。而为了得到一个好的分配方式,我们需要首先得到模型和设备相关信息,然后再进行实际的适当分配操作。因此,对于训练模型,我们需要分为两个阶段:基准测试和分配。
在基准测试阶段,Sky Computing 需要收集来自两个维度的数据:**模型和设备。在模型维度,需要知道模型每一层所需的内存占用和计算量。**通过结合模型的预计内存占用和设备的可用内存,可避免内存溢出;而所需计算量越大,同一设备完成该任务的时间就越久。**在设备维度,需要知道设备的通讯延时、计算能力和可用内存等,受网络环境、当前运行负载等因素的影响。**对于算力强、通信好但可用内存少的设备,应在内存不溢出的前提下,尽量多分配模型层(计算任务)。由于 Sky Computing 是一个负载均衡的联邦学习系统,因此我们在基准测试阶段只关心设备的机器学习的能力。通过在每个设备运行小型的机器学习测试任务,测探设备的AI计算能力。
在决定任务分配方式时,经数学分析可知,分配方式本质上是一个NP-hard的混合整数线性规划问题。因此,在多项式时间内,我们无法得到一个最优解。而随着模型规模的不断增长,和设备数量的不断增多,计算最优解的成本显然是不可接受的。
因此,在实际情况中,我们不会直接计算求得最优解,而是尝试使用启发式算法得到近似解。在 Sky Computing 中,我们设计了一个两阶段的启发式算法:第一阶段为预分配,按照设备的实际可用内存大小进行模型的分配,并且计算每个设备实际的工作负载;第二阶段为分配调整,根据设备的负载量进行动态的调整,迭代降低整个系统的负载量。同时,为了验证 Sky Computing 的优越性,我们在实验中也设置了最优分配作为对比。
三种分配方式(even:均匀分配,heuristic:启发式算法,optimal:最优分配)。在不同的计算资源数量规模和不同的模型大小下的表现,并记录了每次完成迭代所花费的时间。可以看到,随着设备数量的增多和模型深度的增加,我们的启发式算法的效果十分显著。在64个节点160层隐藏层的实验环境下,Sky Computing 比当前的均匀分配模型并行可加速55%。
其中,由于最优分配计算成本极高,在64节点时已难以计算,不适用于实际应用,仅作为小规模时的参考值。
Sky Computing 是利用空间异构分布式计算特性加速联邦学习的一次成功尝试,获得了高达 55% 的性能提升。目前该项目仍处于开发阶段,未来我们将进行更加充分的实验,早日部署到实际应用中,并提供动态冗余等功能。
The Sky Above The Clouds 2205.07147.pdf
Spark 核心设计者解读 Sky Computing:关于云计算的未来构想
Sky Computing:利用空间异构分布式计算特性加速联邦学习
联邦学习_Google的FederatedAveraging算法