nosql如何实现多租户,mysql多租户

网易Kyuubi

网易在Spark多租户方面的工作，这个项目叫做Kyuubi(该项目的开源地址： )，实际上是类似于HiveSever2的程序。

大家可能都知道，Hive一般有两种使用模式，一种是client模式，所有的SQL解析都客户端在这之中完成。一种是HiveSever2模式，整个SQL解析放到server端完成。

在集团内部实际使用过程中，更希望用户的使用行为通过Server端完成，否则会很难管理，因为客户端根本不在平台掌控范围之内，我们很难进行各种升级及配置变化。只有当MetaStore和HDFS 配置不暴露给用户，我们才能更好得管控。Hive的社区比较完善，在这方面没有问题，但是Spark还有些不足。

其实，所谓的Kyuubi只是在类似HiveSever2的基础上提供服务， 提供SparkSQL服务，而不是Hive SQL服务。

Kyuubi基于 Spark Thrift Sever 改造， Spark Thrift Sever 类似于 HiveSever2 ，但是它不够完善。由于我们在此基础上增加了多租户的功能，因此可以支持集团内部各业务线的使用。

要想实现多租户功能，首先要把SparkContext变成多实例，之后每次执行代理真正的用户身份执行;其次，我们提供了Spark SQL集群，用户请求负载均衡到每台Kyuubi服务器，并且这部分是高可用的，一台服务器挂了会立刻切换到另一台。

此外，我们对安全性也进行了改进，支持kerbros。其实，整个网易数据平台都是强安全认证系统，每个用户都有自己的kerberos key tabkerbros，所有系统拿kerberoskerbros做认证访问都是带认证的，Kyuubi要融入这个体系同样需要支持kerberoskerbros。

Kyuubi的主要特点如下：

一、具备统一接口，与HiveSever2相比，Kyuubi提供SwiftThrift的API，无论是Beeline客户端、JDBC客户端、ODBC客户端还是网易猛犸自助分析查询平台、有数可视化BI平台，Kyuubi都可以用标准的方式连接到Spark。

二、有弹性的资源控制能力，Kyuubi支持session级别的资源配置，每个session所需的队列、资源核数和内存都可以进行配置。

三、支持SparkContext的动态缓存。创建一个SparkContext耗时较长，所以我们要对SparkContext进行缓存设置，让用户不需要每次查询都动态创建SparkContext。

此外，也支持Spark动态资源分配特性，启用SparkContext需要启用一堆Spark执行器。如果业务需要较快的响应速度，那就直接发SQL，不需要等待进程启用。

四、Kyuubi安全特性，首先是支持Kerberos还有代理执行，最后支持集成我们的spark-authorizer权限验证插件，该插件对Spark没有侵入性，主要用于查询优化的最后阶段。实际上，具体权限对接的是rRangerr中的权限控制中心，通过集成Spark-authorizer，我们能够做到细粒度的权限控制。

此外，我们也支持服务的高可用和负载均衡，Kyuubi基于负载均衡的方式设计，通过将ZK作为Namespace来实现。具体过程为，Kyuubi将自己注册到ZK，ZK形成服务列表，注明各服务的存活状态，客户端会与ZK通讯拿到该服务器列表，从中挑选Kyuubi服务器执行。通过这种方式，我们将负载均衡到众多Spark查询设备上，从而避免了单点故障，保证了服务的可用性。

Kyuubi以 HiveServer2 Thrift API 为接口协议，提供Spark SQL服务。相比传统的Spark，Kyuubi主要增加了企业级特性，如果公司多租户场景较多且业务线复杂，多租户功能是比较要紧的事情比如多租户、权限、负载均衡等。

相关问答

Q1: Windows Server 2016第三版技术预览带来了哪些新特性

随着Windows Server 2016和System Center2016第 三版技术预览的发布，我们也迎来了全新的里程碑。借助这两个分别针对混合云和数据中心的解决方案的推出，微软希望能够帮助用户将云计算的灵活性引入企业。 对于微软来说，这些里程碑式的产品在公司发展历程中扮演了重要角色，它让我们有机会了解各个用户群体的看法。我们也希望用户能够从一开始就了解我们推出此 产品的初衷、熟悉新的功能，并了解这项新技术将如何改进你的业务。

对于用户来说，此次的亮点是首次发布的Windows Server容器。这是将容器技术带入WindowsServer生态系统的第一步，我们对随之而来的可能性感到非常兴奋。你可能已经看到容器技术的发展势头，这种新技术可以简化应用的开发与部署。我们致力于让容器技术成为现代应用平台的一部分，并将其整合在2016年推出的数据中心解决方案中，提供给我们的客户。您可以通过MikeNeil的博客了解有关于容器技术创新的更多信息。

容器仅仅是Windows Server和SystemCenter技术预览版众多新特性中的一个。除此之外，我们还增强了上一个预览版中的功能，并添加了一些新的特性，供你第一时间进行评估。

Nano Server

作为最小的内存部署选项，就像在技术预览版2阶段一样，Nano Server可以被安装在物理主机或虚拟机上。新的EmergencyManagement Console让用户可以在NanoServer控制台中直接查看和修复网络配置。此外，我们还提供PowerShell脚本用于创建一个运行NanoServer的Azure虚拟机。从应用的角度来说，你现在可以使用CoreCLR运行ASP.Netv5应用。总而言之，我们增加了重大功能以扩展Nano Server能力，而这一切的更新都建立在维持原有内存占用的基础之上。

软件定义网络

在第三版技术预览中，你会发现绝大多数网络功能是新增的。我们引入了用于编程政策的可扩展网络控制器、用于高可用性和高性能的L4负载均衡器、用于混合连接的增强网关，以及融合了RDMA流量和租户流量的底层网络结构。在此次发布的预览版中，你将首次体验到我们在Azure中使用的核心网络功能套件和SDN架构。

安全

此次发布的预览版增加了对于Hyper-V的投入：包括某些用于下一版本的安全创新。虚拟机隔离是我们承诺的核心，即帮助你保护共享环境中的资源。现在，你可以通过一个署名模板测试创建一个屏蔽虚拟机，以及该新屏蔽虚拟机的其他功能。你还可以发现WindowsServer扮演的全新角色——Host Guardian Service，管理员可以识别合法主机。

工作负载支持

● 用于增强关键工作复杂支持的附加特性和功能包括：

● 借助拥有OpenGL支持的Remote Desktop Services提高应用兼容性。

● 借助Storage Replica，对面向延展集群的站点感知而改进业务连续性场景。

● 通过为SQL Server集群删除特定域容器而增加灵活性。

管理

在System Center 2016第三版技术预览版中，增强的特性简化了WindowsServer中新功能的管理。包括对Virtual Machine Manager的改进，如支持集群节点的滚动升级，支持NanoServer作为主机和文件服务器。通过轻松管理隔离虚拟机和受保护主机，你还可以充分利用我们针对共享环境的安全增强功能。在存储方面，你会看到改进的功能，以保持满足预期的端对端服务质量（QoS）和更快速的数据（使用存储分层）检索。在OperationsManager中，我们则侧重于通过管理包的可发现性，和使用PowerShel自动化维护窗口的能力，来提升用户体验。

此外，我们还发布了面向Windows 10客户端的Remote Server AdministrationTools（RSAT），实现对Windows Server 2016技术预览版、Windows Server 2012R2和Windows Server 2012的远程管理。

更多的新特性待你评估，详情可查看Experience Guides；我们还欢迎各位参加我们的User Voice计划，参与整个开发过程。目前Windows Server 2016第三版技术预览及System Center 2016第三版技术预览都已经开放下载。期待来自你的建议。

注意：以上提到的软件、特性及功能均基于预览版，实际发布时可能会有所不同。

Q2: 多租户技术的实现方式

多租户技术的实现重点，在于不同租户间应用程序环境的隔离（application context isolation）以及数据的隔离（data isolation)，以维持不同租户间应用程序不会相互干扰，同时数据的保密性也够强。

应用程序部份：通过进程或是支持多应用程序同时运行的装载环境（例如Web Server，像是Apache或IIS等）来做进程间的隔离，或是在同一个伺服程序（server）进程内以运行绪的方式隔离。

数据部份：通过不同的机制将不同租户的数据隔离，Force是采用中介数据（metadata）的技术来切割，微软 MSDN 的技术文件则是展示了使用结构描述的方式隔离。

多租户就是说多个租户共用一个实例，租户的数据既有隔离又有共享,从而解决数据存储的问题。从架构层面来分析，SaaS区别

于传统技术的重要差别就是Multi-Tenant模式。

SaaS多租户在数据存储上存在三种主要的方案，分别是

1.独立数据库

这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。

优点：

为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；

如果出现故障，恢复数据比较简单。

缺点：

增大了数据库的安装数量，随之带来维护成本和购置成本的增加。

这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。

2.共享数据库，隔离数据架构

这是第二种方案，即多个或所有租户共享Database，但一个Tenant一个Schema。

优点：

为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。

缺点：如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；如果需要跨租户统计数据，存在一定困难。

3.共享数据库，共享数据架构

这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。

优点：

三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。

缺点：

隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；数据备份和恢复最困难，需要逐表逐条备份和还原。如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。