PromiseOne commented on issue #7458: URL: https://github.com/apache/kyuubi/issues/7458#issuecomment-4807392487
感谢你的详细设计和充分的 benchmark 数据，对性能影响的量化分析非常有说服力。我完全赞同在 v1 阶段采用 fail-closed 策略，这确实是避免用户“静默性能劣化”最稳妥的做法。 不过，顺着你的思路，我想到一个后续可能遇到的现实场景：假如用户已经基于安全合规要求，全局开启了 Result Transform Hook（比如强制数据脱敏），但业务上又确实存在一个需要极致性能的 Arrow 格式查询场景。 在这种情况下，如果采用硬性的 fail-closed，用户就陷入了“二选一”的困境：要么为了 Hook 放弃 Arrow 的性能，要么为了 Arrow 冒着违规风险取消 Hook。 所以我在想，是否可以引入一个细粒度的控制参数，可以控制 arrow 格式的使用。但是这个参数仅管理员配置（如果是session级别的话，会有被用户绕过的可能，我记得没错的话，应该管理员也可以控制哪些参数能够在session中使用）。 我考虑的场景是这样的： 场景1：交互式查询，有使用后置hook的可能（因为在金融行业，有数据安全等合规性要求），这种场景必然是使用 Thrift。 场景2：以kyuubi服务，提供一些高性能接口，那么这种场景就有可能使用到 arrow ，但是使用这种场景通常不是人使用，而是接口调用，这种场景下，可能性能就会成为优先考虑的问题。 所以，我觉得应该有一个参数对这个进行控制，虽然一个参数不能控制两种场景，但是管理员可以搭建多个kyuubi来应对不同的场景。 我个人想法还是想着尽可能考虑多种场景，以应对不同人的需要。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
