多租户技术

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

相关文章

来自专栏腾讯云数据库(TencentDB)

腾讯自研新一代企业级云数据库CynosDB,打破安迪-比尔定律,释放硬件红利!

CynosDB是腾讯云自研的新一代高性能高可用的企业级分布式云数据库。融合了传统数据库、云计算与新硬件的优势,100%兼容开源数据库,百万级QPS的高吞吐,不限...

2.4K7
来自专栏云计算

使用容器进行应用程序路由

本文收录在DZone的容器编制与部署指南中。点击此处阅读更多富有洞察力的文章、行业统计数据等内容!

1885
来自专栏Rainbond开源「容器云平台」

当微服务遇上Docker系列之构建、实践与颠覆

1225
来自专栏SDNLAB

容器和云给网络带来巨大的压力

鉴于开发人员已经开始采用敏捷、方便的可编排技术,因此会越来越多地采用基于容器的应用程序。但是当这些应用程序进入生产阶段时,他们的编排解决方案对操作复杂性产生了相...

3239
来自专栏CSDN技术头条

如何创建一条可靠的实时数据流

数据的生命周期一般包含“生成、传输、消费”三个阶段。在有些场景下,我们需要将数据的变化快速地反馈到在线服务中,因此出现了实时数据流的概念。如何衡量数据流是否“可...

1818
来自专栏数据派THU

独家 | 一文读懂Apache Kudu

前言 Apache Kudu是由Cloudera开源的存储引擎,可以同时提供低延迟的随机读写和高效的数据分析能力。Kudu支持水平扩展,使用Raft协议进行一致...

3856
来自专栏JAVA烂猪皮

深入理解阿里分布式消息中间件

对于分布式消息中间件,首先要了解两个基础的概念,即什么是分布式系统,什么又是中间件。

922
来自专栏挖掘大数据

超详细的大数据学习资源推荐(上)

今天为大家推荐一些翻译整理的大数据相关的学习资源,希望能给大家带来价值。

3468
来自专栏Java呓语

架构·微服务架构(一)

微服务架构模式作为替代单体应用和面向服务架构的一个可行的选择,在业内迅速取得进展。由于这个架构模式仍然在不断的发展中,在业界存在很多困惑——这种模式关乎什么?它...

922
来自专栏携程技术中心

干货 | 携程机票实时数据处理实践及应用

995

扫描关注云+社区