Multi Tenancy
多租户，从软件架构定义，即于多用户的环境共用相同的系统或程序组件，计算资源根据一定的策略进行隔离、竞争、共享，并且仍可确保各用户间数据的隔离性。
对于Spark On Yarn而言，我们已经拥有了Yarn这款优秀的的资源管理工具，怎样实现Multi Tenancy呢。
- 1、不同用户写不同的Application，通过指定
spark.yarn.queue提交到不同的队列; - 2、使用Apache Zeppelin/Apache Azkaban notebook或者工作流调度工具，挺好用的
- 3、对于SQL程序，能不用spark自带的继承自HiveServer2的Spark ThriftServer呢，答案是否定的，原因后面细数。
- 4、自己写个服务/App，实例化多个SparkContext 提交多个Yarn Applications到不同的队列，恩，这也是不行的。
- 5、 Some Unknown 奇技淫巧
相关JIRA/PR
| ISSUE | 超链接 | 状态 | 简介 |
|---|---|---|---|
| SPARK-2243 | Support multiple SparkContexts in the same JVM | Resolved/Won’t Fix | 如该JIRA的标题所讲，支持单JVM多sc的特性。对于Spark On Yarn,一个SparkContext实例对应于一个YarnSchedulerBackend，继而对应于一个Yarn的Application，在runtime的时候也只能提交到特定的某一个队列运行。用户无法在自己的一个程序中实例化多个SparkContext然后指定不同的queue来实现多租户的效果。详细讨论可通过连接前往。 |
| SPARK-5159 | Thrift server does not respect hive.server2.enable.doAs=true | Unresolved/reopened | 这是自然的。对于HiveServer2/Spark ThriftServer而言， 一个thrift的Req里面包含客户端的UserGroupInformation，无论走不走代理（proxying/Impersonation)，doAs情况下，都会依赖于这个ugi去执行。前者没啥问题，一系列的进程都是通过这个ugi去拉起的，不会有冲突；后者不然，执行环境在Server启动的时候就已经由SparkSQLEnv给你实例化好了SparkContext，每次你openSession不过是得到一个sqlContext级别的东西了，执行环境ugi都是由linux user或者spark.yarn.principal指定的，在两个ugi不一致的情况下，doAs自然会有权限的问题。 |
| SPARK-5159 | [SPARK-5159][SQL] Make DAGScheduler event loop forwarding UGI info to processing thread | closed/unmerged | 这个PR挺有意思，应该是在Task执行期间将UGI信息deliver到executor端，但是这样的话，所有客户端用户用的其实都是同一个yarn队列，资源上不存在隔离。 |
总结
- 1、SparkContext与Yarn的Application及队列一一对应，在一个服务里提供多租户，最先需要解决的问题就是SparkContext多实例的问题；
- 2、用户 -> SparkContext这个关系元组， 在这问题中其实就是一个天然可以隔离这一切的最直接手段。
- 3、医生写代码实在太丑，文章写得差不多了会开源，勿喷。
