第13期圆桌会回顾 | FATE的在线组件FATE-Serving2.1.0版本介绍
作者：互联网
9月16日，FATE开源社区第13期圆桌会圆满落幕。本次圆桌会，由FATE团队的资深架构师邓凯老师，为大家介绍FATE的在线组件FATE-Serving2.1.0版本。
接下来带大家回顾经典问答环节，为各位朋友答疑解惑。
问答环节
● Q1：
serving-admin的service那个页面的weight是什么？
● A1：
weight就是权重，是我们在服务治理的时候需要关心的一些问题，比方说一个模型有可能分布在三台机器上，但是三机器的资源是不一样的，可能两台机器资源非常好，一台机器CPU非常弱，这时候需要对流量进行一些分配，可以把那两台的weight分成100，然后这边分成50，那么，比较弱的这台机器分的流量就是1/5。
● Q2：
不用deploy模型吗？
● A2：
deploy模型有。就是我刚才说的 FATE-Flow推模型的时候分成两个步骤，一个是load，一个是bind。
● Q3：
能否借助exchange?
● A3：
exchange是双方不同party之间的一个中间节点，实际上我们会有其他的比这个功能更完善的组件。
比方说，需要考虑到计费、流控、鉴权、路由相关的功能，比现在的exchange要更复杂，是因为本身在线业务就更复杂，它不像是离线传输的都是训练过程中产生的一些数据，而我们在线预测的时候传过去的请求可能每一笔都要计费的。
● Q4：
看代码，guest是会遍历host，把相关信息发给host，是修改了guest合并多个host结果那个阶段吗？
● A4：
实际上我们在做2.0.0的时候就已经为多host预测预留了，所以之前的代码会遍历host，但是模型离线推给在线的时候，模型数据是不支持多host预测的。
所以，这次我们是在模型的结构上进行了改动，在线和离线也都进行了一些相关的改动，使其能相互适配。由于我们之前在2.0.0的时候，在机制上设置上已经支持了多host的预测，所以你会在代码上看到会遍历host，把相关信息发给host，就是这个意思。
● Q5：
想问一下，比如有x1,x2,x3；guest发起在线推理时，有id，x1，x2；host那边是提前上传x3特征值么，如果host没做对应上传，预测时会有什么提示么？
● A5：
需要分成两种情况：1、在host方ID匹配不到；2、能够匹配到ID，但是特征不完整，无特征或者特征很少。
第一种情况建议由host方报错，判断逻辑可以在host的adaptor中去自定义开发，需要根据自己需求决定。
第二种情况一般不报错。也可以加入自定义逻辑，比如：拿不到特征或者特征命中率低于某个数值就认为这次预测请求失败。
● Q6：
鉴权这块是怎么设计呢？看默认是没有开启。
● A6：
我们之前的投产的业务鉴权是放在了中间节点这一块，在两端的鉴权是做的比较弱的一块。鉴权现在是支持了https，有颁发证书，双方安装各自相应的证书再进行一个鉴权。
鉴权的重点是我们放在了中间节点的设计，就是exchange那一块的设计。
● Q7：
只部署了2台服务器host、guest能否做联邦学习，还是只能做离线联邦？
● A7：
是可以的。因为在线比离线的需要的资源少多了，如果是离线都能训练的话，在线就一点问题都没有。
● Q8：
这个支持计费的加强exchange什么时候发布？
● A8：
我们现在做的一些FATE-Cloud的组件里面有，这些组件开源出去会有计费的一些功能，我们自己也有一些非开源的项目，计费相关的逻辑是比较完善的。
● Q9：
我理解host方的特征系统接入第三方的服务，在serving时就写好相关的接口。如果我想要更新这个第三方的特征服务，是可以不中断相关的服务么，也就是可以对第三方的特征系统热更新不？
● A9：
FATE-Serving不关心它的更新逻辑，只要保证你那边设计好接口，我通过这个接口能够访问能够正常就可以。比方说，更新特征的时候，你这个接口至少还是能够访问的，能不能支持热更新是在那个系统去决定，而不是Fate-serving决定，因为这个也没办法决定。
● Q10：
有没有单纯在在线预测节点做路由转发的exchange节点？
● A10：
你现在用离线的exchange也是可以进行转发的，只不过只是一个转发功能，没有其他功能。
● Q11：
我想问一下多host的话，是不是也是要打包多个host的extension的jar包去替换。
● A11：
如果你自己做实验，你是可以这么做的。正常情况下，如果投产的话，多host意味着是多个公司或者多个部门，获取特征的接口有可能是由不同的系统提供，然后这是需要各公司自行开发的。
● Q12：
纵向场景里面，进行在线的联邦推理两边数据不需要对齐吗。在实际的业务场景中，如果一方拿到了一条用户的实时数据，另一方并没有该用户的数据怎么办？
● A12：
一般逻辑是对方没有数据、拿不到特征，这时候是报错的。
（补充：报错逻辑可以在host的adaptor中去自定义开发 ，比如：拿不到特征或者特征命中率低于某个数值就认为这次预测请求失败，也可以做成ID匹配不到也不报错，需要根据自己需求决定。）
● Q13：
如何做多节点布署（至少3个节点）？
● A13：
只有在你自己去做实验的时候，你可能搞一个节点，实际上生产环境是至少三个节点，因为使用了zookeeper，zookeeper建议部署奇数个节点1个节点、3个节点、5个节点、7个节点这样子。
所以怎么部署多节点应该是比较简单一个问题，取决于你是怎么规划的。好比说，给你三台机器，你想怎么分配哪台机器部署什么组件，其实你怎么部署都可以，因为它通过了zookeeper寻址，所以只要端口不冲突部署在哪都无所谓。
● Q14：
麻烦问下exchange是什么角色，之前没有遇到过。
● A14：
我想应该在离线的时候已经用过rollsite了，对吧？之前我们经常使用rollsite来进行做进行一个转发的。在不同公司有可能它是不同的网络，如果两个公司并不知道对方的存在，它需要一个中间角色进行转发，如果是双方都知道的话，没有必要做这个事情的，就没有必要exchange这个角色，它就是一个路由转换。
（补充说明：在生产环境中，有可能不同的参与方属于不同的公司， 公司与公司之间的网络打通是一个比较繁重的事情，涉及到各个公司的网络策略、带宽分配、安全审计等等事物，exchange就是把整个网络变成一个星型网络，由负责exchange的公司负责对接各个合作方，完成上述工作，这样就减轻了各合作方自行互联的负担。）
● Q15：
多节点布署（至少3个节点）的相关资料望能提供一下！
● A15：
其实在文档上我们之前有一个类似的图，可以看一下，如果说觉得不够，可以在群里面给我们提一些建议，我们这边会安排同学去更新文档。
● Q16：
生产环境部署，更推荐exchange还是非exchange? 还没部署过exchange方式？
● A16：
需要知道生产环境是你们公司内部不同的部门之间进行一个交互，还是不同的公司之间进行一个交互。如果是不同公司，倾向于有exchange；如果是在内部的话是没必要的。如果在内部交互中使用，只是多一点交互，不能带来特别多的好处。
● Q17：
老师，请问进行一次在线预测的时间大约是多少？
● A17：
这个是不定的。可以回答一下我们目前线上的一些情况，大概是在100多毫秒，这是跨了两个公司的预测。因为跨了公网，有可能会耗时严重一点。如果是在公司内部不同部门之间进行内网的交互，应该会好很多。
在线预测的耗时很大部分是放在host那边获取特征那一步，获取特征时候，如果系统做的不够好的话，它的延迟高，整条链路的延迟就很高。
● Q18：
一套集群如何加载多个模型？起不同的服务ID可以吗？
● A18：
服务ID是跟模型是一一对应的，如果是多个模型肯定是不同的服务ID，如果是相同的服务ID就是直接覆盖了。不同的模型，相同的服务ID，就可能会导致不正确的选择模型，所以不同的模型一定是不同的服务ID。
● Q19：
最新版本FATE-Serving对FATE的版本有要求吗？最低版本是多少呢？还是不限版本？
● A19：
近一年发布的版本都是兼容的，最早以前的（如，两年前的）不一定，因为没有测过。
● Q20：
直观想，两个纵向联邦参与方能够同时拿到一个用户数据的可能性很小，如果一方拿到数据，另一方没有就报错的话，那在线推理的成功率会不会很低？
● A20：
这是在你选择合作方的时候是需要考虑的问题。
一般来说需要host那一方的数据比较全面，因为如果你拿不到特征，训练的模型只有一半起作用，这个效果也不会很好。如果说双方的数据非常少，传来传去都找不到自己的那些ID相关的特征，做联邦学习也没有什么太大的意义。一定是有一方的数据非常全，做这个才有意义。
● Q21：
FATE-Serving2.1.0更新到kubefate上了么？
● A21：
目前没有。
● Q22：
支持dsl v2训练出来的模型吗？
● A22：
FATE-Serving版本 >=2.0.4，FATE版本>=1.5.1的话，dsl v2训练是支持Serving调用的，但dsl v2推到Serving前，需要先deploy训练模型去指定生成的预测推理工作流。FATE dsl v1和dsl v2的一个比较大的区别是v1会帮你自动推导预测工作流，但导致的问题是当模型训练完之后，预测工作流就不可变了，所以dsl v2通过去掉自动推导、增加deploy操作由用户灵活去决定预测的工作流。
● Q23：
为什么不支持横向模型的预测？
● A23：
横向模型训练完成之后，每一方都会得到完成的模型，这个和纵向逻辑是不一样的。纵向联邦无论是离线训练还是在线推理阶段，都是需要双方协助的，而横向联邦则是离线训练完成后，在线阶段每一方拿到完整模型，可以单独用自己的数据来直接进行推理。而FATE里面横向联邦逻辑回归、GBDT或者NN，在推理阶段，可以使用第三方引擎来进行推理。基于这种考虑，FATE-v1.7会推出横向模型转成第三方可用的模型文件功能，届时用户可以使用该模型文件，再导入到第三方引擎去做推理即可。
标签：13,在线,FATE,exchange,模型,Serving2.1,host,节点 来源： https://blog.csdn.net/weixin_45439861/article/details/120430648