隐语分布式底座: 基于Ray的分布式联邦执行引擎

本文涉及的产品
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介: 隐语分布式底座: 基于Ray的分布式联邦执行引擎

隐语分布式底座: 基于Ray的分布式联邦执行引擎

原创王清、周爱辉隐语的小剧场 2023-01-16 10:08 发表于浙江

收录于合集#隐语解读20个

分布式联邦执行引擎升级是此次隐语V0.7.18版本核心迭代内容之一。隐语曾使用单一ray集群作为分布式底座,用户可以快速方便使用单机模拟分布式,并零成本迁移至多机集群。此次升级全新跨机构联邦分布式底座rayfed,是针对隐私计算领域需求,在保持隐语集中式编程易用性的基础上,提升整体系统的安全性。












隐语明密文混合编程思想















01隐语明密文混合编程思想

隐语旨在提供隐私保护下的机器学习和数据分析的统一框架,面临的场景天然是跨机构分布式。作为众多隐私保护技术的提供者,隐语希望提供明密文混合编程的统一视角。

为了这一目标,隐语提供两种抽象:一是设备抽象,将多方安全计算、同态加密、可信执行环境等隐私计算技术抽象为密文设备、将单方计算抽象为明文设备;二是计算抽象,将一个隐私计算任务分解为多个设备上的计算以及设备之间的数据传递。


基于上述抽象,数据分析和机器学习算法可以描述为一张「设备计算图」,其中节点表示某个设备上的计算,边表示设备之间的数据传递,从而由隐语分布式调度引擎进一步拆分并调度至物理节点,即需要将不同的计算任务调度到其正确的物理设备,也就是参与方的客户端。

02隐语业务场景下的调度任务执行挑战

结合隐私计算真实业务场景,隐语完成如上的任务还面临以下挑战:

  • 同构和异构逻辑交织
例如在水平联邦场景下,多个客户端往往是同构计算,而服务端与客户端则属于异构逻辑。又比如在垂直场景下,比如拆分学习,有label方和无label方的逻辑往往是异构的,无label的多个参与方则往往是同构的。另外,在多方安全计算模型下,参与方的逻辑主要是同构的,而同态加密模型下,密钥持有方和计算方逻辑则是异构的。以上场景不一而足,隐语需要有一种简洁高效的表达方式来支撑各种场景下的分布式逻辑表达。

  • 复杂的计算模型
既有有状态的计算,也有无状态的计算。比如在数据处理中,我们希望数据是无状态、不可更改的;在模型训练中,模型是有状态、可更改的,由迭代更新内部状态。为了支持大规模数据和模型,隐语还需要支持多种并行计算模型,包括数据并行、模型并行、混合并行等。

  • 同步和异步计算
例如机构内的并行计算比如Parameter Server模式可能是同步计算,而机构之间由于不同机构的计算资源、数据量、模型都可能存在差异,异步计算可以带来效率提升。为了最大化计算效率,隐语既需要支持同步计算,也需要支持灵活的异步计算。

  • 如何保护数据安全
除了算法本身的安全设计外,隐语本身也需要加强系统安全,包括但不限于机构间的身份认证、跨机构数据流动的安全性等。

03隐语调度引擎选型

在分布式机器学习领域,TensorFlow、PyTorch等框架已经取得了巨大的成功。面临这些挑战,隐语是否可以直接基于这些AI框架进行修改从而站在巨人的肩膀上?答案是不太可行,原因有多方面:

首先,这些框架本身是割裂的,这意味着比如选择了TensorFlow,则其他框架无法使用(除非每个框架都改一遍,但是代价很高);其次,这些AI框架在设计之初,面临的问题和隐私保护计算并不大相同,隐私保护计算场景的一个基本设定是原始数据是固定在机构内的不能任意流动,而TensorFlow、PyTorch等设计之初就不考虑数据流动受限的场景,而侵入式去修改这些框架,其工作量不亚于从头实现,而且也难以享受这些框架本身升级迭代的好处。最后,面临复杂的同构异构逻辑交织、复杂计算模型、同步异步计算等,这些AI框架本身也不是非常胜任。

而对照隐语的需求,ray提供了一套简洁但强有力的分布式原语(remote、get),能够同时支持无状态(function)和有状态(actor)计算模型,用户在ray提供的driver视角下可以方便且自然地进行分布式编程。













隐语分布式底座第一代:奠定易用性基础














隐语提供了多种明文密文设备,比如PYU(明文计算设备)、SPU(多方安全计算设备)、HEU(同态加密设备)等,这些设备通常由一个或者多个参与方的进程构成,用户在设备的基础上进行编程,而这些设备的底座是ray。

PYU本质上是ray的一个function或者actor,提供了python runtime,从而用户可以在PYU的基础上执行任意python代码。SPU/HEU则由多个ray的actor构成。设备之间的数据传递则是基于ray的remote object。

早期版本中,隐语使用单一ray集群作为分布式底座,奠定了隐语易用性的基础

每个机构都有若干个节点,所有机构的节点整体构成一个ray集群,我们称之为分布式底座第一代。因其既支持单进程模拟集群,也支持多机器集群,故而用户可以使用隐语在单机进行模拟分布式,快速评估引入隐私计算技术的效果与成本;也可以将代码从单机迁移至多机集群,低成本将隐私计算方案上线生产落地应用。













隐语跨机构联邦分布式底座:提升系统安全性














但旧版本也存在很多安全性的挑战。虽然我们通过限制代码分发、resource鉴权、白名单限制反序列化类型等等策略对ray的安全性做了增强,但是仍然存在不好解决的安全问题。想要系统性提升隐语跨机构安全性,RayFed作为ray的生态组件之一,能够提供跨机构的分布式联邦执行能力,提供了解决思路。

在V0.7.18版本中,隐语基于Ray分布式引擎和RayFed的跨机构执行能力,构建了全新的跨机构联邦分布式底座。在继承优秀的模拟体验,支持用户低成本进行单机模型,并且无缝从单机模拟切换至多机执行的同时,又支持多控制器执行,在保持集中式编程模式易用性的同时,提升了整体系统的安全性:

先从物理上隔离Ray集群,避免Ray复杂的分布式协议和通信引入的任何安全性漏洞问题。我们再提供非常有限的跨机构间通信的协议,以进行跨机构任务协调和数据传输。


能力继承,有增无减:
  • 提供一个统一的,上帝编程视角的,并且single-machine-like programming 的编程范式,以便于能够自然地编写跨机构的分布式程序。
  • 可以帮助更好地管理和使用联邦Ray集群。
  • 提供了高性能,安全的以太网通信能力;并且能在弱网络环境中稳定运行。
  • 面向可信设备友好的调度和使用能力。
  • 当然,它还具备:高性能的RPC,分布式故障处理和恢复,任务调度和异构资源管理,以及高性能的数据传输等。(powed by Ray)

    我们以一段代码为例来讲解RayFed的原理:
# Federated learning across 2 parties on Ray.
@fed.remote
class MyModel:
    pass
@fed.remote(party="ALICE")
class Aggregator:
    pass
model_1 = MyModel.party("ALICE").remote()
model_2 = MyModel.party("BOB").remote()
aggregator = Aggregator.remote()
model_1.load_data.remote()
model_2.load_data.remote()
for epoch in range(num_epochs):
    # 1. Train local model in the local parties.
    for step in range(num_steps):
        model1.train.remote()
        model2.train.remote()
    # 2. Aggregrate gradients and re-distribute it.
    acc1, w1 = model1.get_weights.remote()
    acc2, w2 = model2.get_weights.remote()
    new_w = aggregator.mean.remote(w1, w2)
    model1.update_weights.remote(new_w)
    model2.update_weights.remote(new_w)
    # step3: Aggregrate metrics and early stop.
    meant_acc = aggregator.mean.remote(acc1, acc2)
    if fed.get(meant_acc) > 0.98:
        break

上述代码将在2个机构内,以多控制器方式执行。每个机构将执行指定在其机构内的ray task。跨机构传递的ray objects将会被加密,通过动态构图时插入的send/recv barriers完成数据传输。所有`fed.get()`的语句将会触发一个boradcast barrier。由于是多控制器设计,不同机构看到的DAG全图应该是完全一致的。

隐语基于新版本底座,构建了一套核心的Device Flow Framework编程抽象,以供上层不同的AI和BI的框架使用。并且同时支持两种模式供用户使用

第一种是单ray集群的架构,该架构适合用户进行本地单机或者多机进行模拟仿真,用户可以快速验证算法正确性,易上手;

第二种是多控制器多ray集群架构,该架构适合生产环境使用,提供了跨机构下安全可靠的计算调度和执行能力。与此同时,隐语提供了非常便捷的操作,用户可以几乎无成本的从模拟模式切换至生产模式,仅需要在初始化的时候打开开关即可,底座架构的切换对用户是透明的。

明密文混合调度展望


隐语明密文混合调度层上承隐私计算算法开发者的使用需求,下启密码安全开发者的成果嵌入,是隐语框架中重要的隐私计算应用与隐私计算技术粘合部分。而Ray作为通用性分布式计算引擎,可基于Ray开发各种计算模式的其他引擎,并已经组成了丰富的生态组件:

  • 数据处理:RayData, Mars, Dask, Modin, etc.
  • 分布式训练:RayTrain, XGBoost, LightGBM, Horovod, PyTorch Lighting, etc.
  • 模型推理和服务: RayServe, Seldon.
  • 其他:如RayTune, RLlib等


目前隐语正在探索Ray生态中多个机器学习相关的库在隐私计算场景的应用,例如Mars、Ray Train、Ray Serve等,可以实现高性能、可扩展的分布式机器学习全链路pipeline。期待来自调度/编译器层面的开放合作,与隐语共建明密文混合编程能力。


 隐语官网

    https://www.secretflow.org.cn

 隐语社区:

https://github.com/secretflow

https://gitee.com/secretflow

 联系我们:

公众号:隐语的小剧场

B站:隐语secretflow

邮箱:secretflow-contact@service.alipay.com

收录于合集 #隐语解读

20

上一篇隐语v0.7.18版本更新,构建跨机构分布式底座RayFed下一篇隐语 Unbalanced PSI Benchmark 白皮书


相关文章
|
7月前
|
消息中间件 算法 Java
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的保障容量的三大关键方案实现
尽管经过了上一篇文章 《【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的低延迟可用性机制方案实现》有了低延迟的优化保障,消息引擎仍需精心规划其容量。为了提供无与伦比的流畅体验,消息引擎必须实施有效的容量管理策略。
97 2
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的保障容量的三大关键方案实现
|
7月前
|
存储 边缘计算 人工智能
云计算与分布式系统架构:驱动数字化时代的创新引擎
本文将探讨云计算与分布式系统架构在数字化时代中的重要性,介绍其基本概念和原理,并探讨其在推动技术创新、提升企业效率和满足用户需求方面的作用。同时,还将提出未来发展的趋势和挑战,为读者提供对云计算与分布式系统架构的深入理解。
|
SQL 分布式计算 数据库连接
大数据Spark分布式SQL引擎
大数据Spark分布式SQL引擎
274 0
|
7月前
|
消息中间件 存储 负载均衡
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的HA高可用解决方案
昔之善战者,先为不可胜,以待敌之可胜。不可胜在己,可胜在敌。故善战者,能为不可胜,不能使敌之必可胜。故曰:胜可知,而不可为。
265 2
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的HA高可用解决方案
|
Python
分布式框架ray的基本使用记录
分布式框架ray的基本使用记录
746 0
|
2月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
57 1
|
7月前
|
存储 分布式计算 分布式数据库
【专栏】云计算与分布式系统架构在数字化时代的关键作用。云计算,凭借弹性、可扩展性和高可用性,提供便捷的计算环境
【4月更文挑战第27天】本文探讨了云计算与分布式系统架构在数字化时代的关键作用。云计算,凭借弹性、可扩展性和高可用性,提供便捷的计算环境;分布式系统架构则通过多计算机协同工作,实现任务并行和容错。两者相互依存,共同推动企业数字化转型、科技创新、公共服务升级及数字经济发展。虚拟化、分布式存储和计算、网络技术是其核心技术。未来,深化研究与应用这些技术将促进数字化时代的持续进步。
221 4
|
2月前
|
存储 缓存 数据处理
深度解析:Hologres分布式存储引擎设计原理及其优化策略
【10月更文挑战第9天】在大数据时代,数据的规模和复杂性不断增加,这对数据库系统提出了更高的要求。传统的单机数据库难以应对海量数据处理的需求,而分布式数据库通过水平扩展提供了更好的解决方案。阿里云推出的Hologres是一个实时交互式分析服务,它结合了OLAP(在线分析处理)与OLTP(在线事务处理)的优势,能够在大规模数据集上提供低延迟的数据查询能力。本文将深入探讨Hologres分布式存储引擎的设计原理,并介绍一些关键的优化策略。
150 0
|
7月前
|
消息中间件 存储 Java
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的低延迟可用性机制方案实现
在充满挑战的2023年度,我们不可避免地面对了一系列棘手的问题,例如响应速度缓慢、系统陷入雪崩状态、用户遭受不佳的体验以及交易量的下滑。这些问题的出现,严重影响了我们的业务运行和用户满意度,为了应对这些问题,我们所在团队进行了大量的研究和实践,提出了低延迟高可用的解决方案,并在分布式存储领域广泛应用。
78 2
【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的低延迟可用性机制方案实现
|
7月前
|
存储 自然语言处理 搜索推荐
分布式搜索引擎ElasticSearch
Elasticsearch是一款强大的开源搜索引擎,用于快速搜索和数据分析。它在GitHub、电商搜索、百度搜索等场景中广泛应用。Elasticsearch是ELK(Elasticsearch、Logstash、Kibana)技术栈的核心,用于存储、搜索和分析数据。它基于Apache Lucene构建,提供分布式搜索能力。相比其他搜索引擎,如Solr,Elasticsearch更受欢迎。倒排索引是其高效搜索的关键,通过将词条与文档ID关联,实现快速模糊搜索,避免全表扫描。
289 13

热门文章

最新文章