多租户技术

多租户技术(Multi-TenancyTechnology)又称多重租赁技术,用于实现如何在多用户的环境下共用相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。

具体的多租户隔离技术有多种,数据库通常有如下三种。

1. 独立数据库

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

优点:为不同的租户提供独立的数据库,有助于简化数据模型的扩展设计,满足不同租户的独特需求;如果出现故障,则恢复数据比较简单。

缺点:增大了数据库的安装数量,随之带来维护成本和购置成本的增加。这种方案与传统的一个客户、一套数据、一套部署类似,差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等要求数据隔离级别非常高的租户,可以选择这种模式,提高租用的定价。如果定价较低,产品走低价路线,那么这种方案一般对运营商来说是无法承受的。

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

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

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

缺点:如果出现故障,则数据恢复比较困难,因为恢复数据库将涉及其他租户的数据;如果需要跨租户统计数据,则存在一定困难。

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

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

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

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

9.5.2 多租户方案

在大数据技术里面,实现多租户会有多种部署模式。与传统数据库不同的是,大数据通常多租户通常希望能尽量共享数据,而其他资源隔离。如果数据不同享,那么和传统的数据库多租户基本没有什么区别。

例如,一家企业有两个租户,一个租户做ETL计算,另一个租户做一些基础的分析。为了实现多租户,会有多种不同的部署方式。

方案1:ETL和基础分析合并部署为一个Hadoop集群,并为数据处理和数据分析分别设置不同的租户,通过对两类租户设置不同的资源上限,实现资源隔离,做到互不影响,如图9.23所示。

图9.23

优点:

—这是较常规的部署方式,案例很多,比较稳定。

—部署简单,维护简单,通过YARN进行资源隔离简单方便。

—修改资源的配额简单。

—集群的扩容简单,并且不需要更改资源配额。

—资源利用率高,所有计算均可以利用所有节点的计算资源。

缺点:

—共用YARN,如果YARN崩溃,则ETL和Hadoop的计算都将崩溃。

—YARN的隔离是逻辑隔离,不如物理隔离更彻底。

方案2:ETL和基础分析共享一个HDFS,控制计算资源的YARN部署为两个,分别为数据处理和数据分析服务,做到计算存储资源的共享和计算资源的物理隔离。同时通过Hadoop的机架感知能力,保证三个副本的数据至少在ETL和基础分析计算集群所在的节点上各有一个副本,达到计算的本地化,如图9.24所示。

图9.24

优点:

计算资源物理隔离,两个YARN没有任何影响,一个崩溃不会影响另一个。

缺点:

—这种部署复杂、维护复杂,相当于维护两个集群。

—修改配额等于重新配置YARN集群。

—系统扩容后,两个计算集群均需要重新配置。

—计算资源利用率低,可能出现一个计算集群繁忙、另一个计算集群闲置的情况。

—让三个副本保证两个计算集群所在的节点各有一个,目前的社区版本无此方案。只能通过将两个集群设置为两个逻辑机架的方式实现。但是这样部署很可能会出现大量的三个副本分别部署在不同机架上的情况,影响整个HDFS集群的性能。

—如果HDFS集群崩溃,则仍然会导致整个系统崩溃。

方案3:ETL和基础分析合并部署为一个Hadoop集群,并为数据处理和数据分析分别设置不同的Hive、Spark等组件实例。实例可以指定具体部署的物理机或者容器,通过实例做到物理隔离;在YARN之上的计算资源完全隔离,做到互不影响,如图9.25所示。

图9.25

方案3是方案1的升级版本,相比方案1有更好的隔离性。

三种方案都有优缺点,第三种方案相对来说更折中一些。实际应用中需要根据不同的场景采用合适的方案。

本文选自我的新作《大数据架构详解:从数据获取到深度学习》9.5节。

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2017-02-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT笔记

SpringBoot开发案例从0到1构建分布式秒杀系统

最近,被推送了不少秒杀架构的文章,忙里偷闲自己也总结了一下互联网平台秒杀架构设计,当然也借鉴了不少同学的思路。俗话说,脱离案例讲架构都是耍流氓,最终使用Spri...

54012
来自专栏原创

高并发大容量NoSQL解决方案探索

1098
来自专栏51CTO技术栈的专栏

支撑百万用户同时在线的高并发直播弹幕系统是如何炼成的?

本文诠释了根据项目的发展阶段,直播弹幕系统进行平衡演进的过程。这三个阶段分别是快速上线,高可用保障体系建设,长连接演进。

9460
来自专栏京东技术

京东万台规模Hadoop集群 | 分布式资源管理与作业调度

吴怡燃, 京东大数据平台高级技术专家,擅长大数据平台的资源管理与调度系统的开发与建设。目前专注于以万台分布式调度系统及深度学习平台的开发与建设。

1453
来自专栏数据和云

技术前沿:Oracle 18c 最新特性概览

作者简介 ? Joel Perez Oracle ACE Director,云和恩墨高级云技术专家 自从今年OOW上Oracle宣布要推出18c,一直受到...

36911
来自专栏码洞

深入理解RPC——RPC在企业服务中的核心价值

随着企业 IT 服务的不断发展,单台服务器逐渐无法承受用户日益增长的请求压力时,就需要多台服务器联合起来构成「服务集群」共同对外提供服务。同时业务服务会随着产品...

561
来自专栏顶级程序员

谈谈互联网后端基础设施

作者:飒然Hang 原文:www.rowkey.me/blog/2016/08/27/server-basic-tech-stack/ (点击文末阅读原文即可...

2986
来自专栏微服务

全面解读NoSQL数据库Redis的核心技术与应用实践

互联网和Web的蓬勃发展正在改变着我们的世界,随着互联网的不断发展和壮大,企业数据规模越来越大,并发量越来越高,关系数据库无法应对新的负载压力,随着Hadoop...

2866
来自专栏纯洁的微笑

主流分布式架构的风流韵事...

862
来自专栏即时通讯技术

IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

在IM这种讲究高并发、高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色,当...

1173

扫码关注云+社区