多租户技术

多租户技术(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 条评论
登录 后参与评论

相关文章

来自专栏数据科学与人工智能

数据质量监控的那些事

0x00 前言 往往那些不起眼的功能,最能毁掉你的工作成果。 本篇分享一些和数据质量监控相关的内容。数据质量监控是一个在快速发展的业务中最容易被牺牲和忽略的功能...

8055
来自专栏Web项目聚集地

为什么一定要前后端分离?

孤独烟,中国平安研发工程师,目前负责云平台架构设计以及需求研发工作。毕业后一直从事Java开发工作,在Web开发、架构设计上有多年的实战经验。在MySQL性能优...

1601
来自专栏云计算D1net

如何云化你的 Windows 应用?

AWS AppStream是一项新的亚马逊服务,它可实现Windows应用的云化,可将操作系统扩展至各种计算机和移动设备。今天,服务最实用的用例是将提供简单的游...

3507
来自专栏PPV课数据科学社区

【学习】Facebook的实时Hadoop系统

Facebook 在今年六月 SIGMOD 2011 上发表了一篇名为“Apache Hadoop Goes Realtime at Facebook”的会...

2944
来自专栏北京马哥教育

20款开发运维必备的顶级工具

开发运维工具与软件开发领域的最佳实践密切相关,也与必要的规范密切相关。在整个开发生命周期涉及到一大批新旧工具,从规划、编码、测试、发布到监控。本文介绍你应该考...

5146
来自专栏程序人生 阅读快乐

深度探索Linux操作系统:系统构建和原理解析 - 王柏生

《深度探索linux操作系统:系统构建和原理解析》是探索linux操作系统原理的里程碑之作,在众多的同类书中独树一帜。它颠覆和摒弃了传统的从阅读linux内核源...

1432
来自专栏架构师之路

互联网分层架构,为啥要前后端分离?

通用业务服务化之后,系统的典型后端结构如上: web-server通过RPC接口,从通用业务服务获取数据 biz-service通过RPC接口,从多个基础数据s...

4008
来自专栏Java架构

阿里java架构师:微服务写的最全的一篇文章

今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。

2K3
来自专栏BestSDK

好的产品诞生全过程:每个环节都细致入微

当我们提到一些常见的功能时,可以一笔带过,简单的描述一下就可以了,比如:对于微信登录,手机号注册。 那如果我们提到的是一些比较复杂的,具备一定创造性功能的时候,...

3005
来自专栏PHP在线

可以使用框架但千万不要依赖框架

我们是由于效率和易用性的考虑才产生框架。框架能节省开发时间。框架强制使用公共的约定,因此它能有效地解决一些共有的问题,比如页面渲染,assert判断,安全或者应...

3545

扫码关注云+社区

领取腾讯云代金券