报名 | 联邦学习进阶最后一课：联邦学习推荐算法及其应用

3 月 24 日，机器之心联合微众银行开设的公开课《联邦学习 FATE 入门与应用实战》 第五讲结课，微众银行人工智能部系统架构师曾纪策为大家介绍了 FATE 的整体架构、系统关键数据流以及如何实践。

3 月 26 日（周四），我们将迎来本系列公开课最后一讲，详情如下：

公开课第6讲

课程主题：联邦推荐算法及其应用

课程时间：3 月 26 日 20:00 主题讲解+在线答疑

课程讲师：谭奔 微众银行人工智能部高级研究员

讲师简介：博士毕业于香港科技大学，主要研究方向为迁移学习、推荐系统、机器学习等，目前在微众银行人工智能部门负责推荐算法研发工作，曾就职于腾讯，负责广告转化率预估、商品推荐等工作。在 KDD、AAAI、SDM、TIST 等国际学术期刊会议上发表论文 10 余篇，多次在国际数据挖掘大赛中名列前茅。

课程摘要：课程主要介绍联邦推荐系统背景、联邦推荐系统分类以及现有工作、联邦推荐算法实现和联邦推荐在新闻推荐的应用。

第4课精选问答

在每期课程的 QA 环节中，有一些问题被广泛提到并且很有价值，所以我们进行了精选与编辑，供大家参考。以下为第 4 课问答精选（第 4 课主题为使用 KubeFATE 部署生产环境的联邦学习 Kubernetes 集群）：

Q：生产环境是多个机构一起部署的，需要对方机构提供什么样的权限？

在正式的生产环境中，多个机构应该独立部署自己的 FATE 集群，然后通过 FATE-Cloud 连接起来一起进行联邦学习。FATE-Cloud 还在开发完善中。KubeFATE 在部署的时候尽量保证采用通用方案，所以只要保证网络通道，可以按照各组织的安全部门要求，加上安全保护。

Q：gRPC 访问失败的原因是？

gRPC 访问失败的可能原因很多，很难一概而论。按照我们的经验，可以观察下报错的时间点。如果是一开始执行就报错，很可能是 proxy 的 route_table 配置错误，可以检查下。如果是如本课那样，由 kubeFATE 部署的 Kubernetes 集群，就是你的 cluster.yaml 里有写错的地方；如果任务已经顺利跑起来，显示任务正在运行，突然跳出一堆 gRPC 错误，那很可能是 egg 的 processor 起的过多，资源不够。

可以参考：https://github.com/FederatedAI/KubeFATE/wiki/KubeFATE#1-running-toy-example-failed 里改小 eggroll.computing.processor.session.max.count 的配置；还有其他原因引起 gRPC 错误，譬如网络真的出现问题。所以 gRPC 错误需要具体问题具体分析。

Q：Native 部署与 k8s 部署优劣？

目前 FATE 的部署可以划分为四种方案，都各有优缺点和适应的场景。我主观的想法是：

如果想很快体验一下 FATE，或者跑的模型和数据在单台机器就够了，建议使用第二节课介绍的 KubeFATE -> Docker-Compose 的部署方案。这是门槛最低，最简单的部署方案，因为你不需要解决依赖环境带来的种种安装困难，唯一需要的只是装一个 Docker；

第二种是 standalone 的方案，如果只是想开发算法，需要如第三节课那样用 Python 去开发，而开发机器性能又不高，也想去测试底层的 egg 那些模块，那 standalone 是很方便的方案；

然后是今天介绍的 KubeFATE → Kubernetes 的部署方案。这是你对 FATE 的使用需求因数据集和模型变大，需要扩容，并且里面有数据需要维护一个 FATE 集群，所以考虑集群管理高级功能自然的需求；

最后是 Native 的集群部署方案。除非是因为特殊原因，譬如组织内部无法部署 Kubernetes，或者需要对 FATE 的部署进行自己的二次开发，否则我个人不是很推荐这个方案。即使使用这个方案，也推荐结合其他编排工具，譬如 Ansible，Puppet 类的来辅助，因为大规模部署我们需要讲究一致性。

Q：企业一般用的部署方式是什么？

这是个选型问题。我个人比较推荐企业使用 KubeFATE 的 Kubernetes 方案来部署。一来，这样可以对集群以一个整体去运维；二来 Kubernetes 也是主流跑分布式任务的事实标准，社区也有很多可以使用的工具辅助管理。

Q：k8s 部署不需要 java、python 吗？

这就是 container 部署的优势，这些依赖包都已经打包在了镜像里面。

Q：不太明白为什么会用 k8s 管理？由一个机构批量部署其他机构的环境？

一个机构不会部署别的机构环境。但是:

1、FATE 本身就是个复杂的分布式系统，有横向扩容等需求，所以 Kubernetes 可以很好解决这些问题；

2、一个机构内部可以有多个 FATE 的集群，譬如一个是开发用的，一个是生产用的；或者不同部门使用不同的 FATE 集群，也有可能有多个版本的 FATE 集群同时在跑。这些依托 Kubernetes 的 namespace 都可以很好的去解决。

Q：每个机构独立部署自己的 kubefate 吗？还是不同机构的 kubefate 协同完成联邦？

对，每个机构部署自己的 KubeFATE。不同机构可以用 FATE-Cloud 来协同，而 FATE-Cloud 会调用 KubeFATE。

Q：联邦需要做免密吗？

这其实是安全问题，是不能简单的做免密的。这个 FATE-Cloud 会解决，大家可以期待一下。