背景

为了配合公司产品K8S化，方便产品快速扩展以及部署，需要对当前的大数据组件进行相关的多租户以及资源隔离的配置，组件暂时包含但限于HBase、ElasticSearch、Kafka和Redis。

下面将从不同角度对上面提到的四个组件进行多租户以及资源隔离方案的描述，并根据需求选取效果明显且性价比高的方案进行适配与实现。

正文

目标

• 实现单集群支持多租户，租户之间相互不影响

• 能够快速方便的管理单租户的数据

• 对当前已经存在的产品代码和架构的侵入在可控范围之内尽量的小

方案

HBase

多租户

HBase多租户方案可以使用HBase的namespace来实现,单套威胁感知测试程序使用单独的namespace，由于namespace中资源是可以单独管理的，所以将单套威胁感知数据放入特定的namespace中便于后续该套威胁感知测试环境HBase资源的管理和回收

资源隔离

HBase的资源隔离包含RSGroup、Quota管理以及读写分离的相关配置。

其中RsGroup应用的场景是针对服务器资源异构的HBase集群，根据服务的重要程度或者业务特点将Region分组用来满足不同的需求

而读写分离以及读写控制则是针对大数据高并发下针对读写的特点进行请求数量的比例控制，保证不同场景的协同工作

上面两种场景明显不符合公司当前的需求，所以暂时不考虑。

而Quota管理可以针对namespace的资源分配来满足不同的测试产品的配额来满足资源管控的需求。主要的控制方法和维度如下：

注：Space Quotas使用的是filesystem quotas，这个特性是随着HBASE-16961在HBase 2.0之后实现的，而当前产品HBase的版本是1.2，所以该功能暂时无法支持，后续升级HBase版本后可以考虑。

ElasticSearch

ElasticSearch没有主流的官方多租户的方案，现在比较流行的多租户方案包含两种：

• 基于索引的多租户方案，即每个用户使用不同前缀的一套表，最后基于该套表完成对不同租户的管理。这针对集群规模不算太大时候的场景比较友好，当集群和租户规模过大时，元数据膨胀率会比较高，集群的负载会比较高。

• 基于索引中的路由进行多租户管理的方案，即所有的用户使用一套表，通过routing来进行数据分发和隔离。这样做的好处是能保持很好的扩展性以及较好的性能，但是缺点是如果在原有代码的基础上改动较大，且按用户删除数据时并不是很方便。

根据上面两种方案的对比，结合当前产品K8S环境的需求以及特点，第一套方案比较合适，暂时采取第一套方案。

Kafka

多租户

kafka多租户可以使用两种方式实现：

• 基于不同的用户使用不同的topic组分开消费，优点是代码改动较小，只需要配置适配即可，方便资源管理。配合权限管理，可以做到资源隔离。但是缺点是针对部分公用数据的数据膨胀率过高，资源浪费，元数据膨胀率高，用户多的时候集群压力较大。

• 基于不同的用户使用相同的topic来存储数据，根据不用的key来进行区分和消费。优点是代码改动小，元数据膨胀率可以得到有效控制，适用于多用户的场景。但是缺点是无法做到资源隔离，且消费数据时需要根据key进行判断，影响数据处理效率，不适合大数据高并发处理场景，且没办法很容易地按照用户来单独管理数据。

根据上面两种方案的对比，结合当前产品的K8S环境的需求以及特点，第一套方案比较合适，暂时采取第一套方案。

资源隔离

kafka资源隔离包含两个层面，即Quota(配额)管理以及ACL权限管理。

Quota管理适用于对kafka的各种流量进行控制和限制，保证kafka的broker的资源不会被一个或者几个client耗尽，保证整个集群的稳定性和可用性。适用于高性能高并发场景下的集群稳定性的阿提升与保证。

权限ACL管理则是进行资源隔离的重要实现方式，在开启认证后，可以管理用户对于topic的访问权限，实现kafka的资源隔离。

Redis

redis通用的多租户的实现方式和kafka以及elasticsearch的方式类似，都是在key的前面加上租户的前缀来进行管理。

有种极端的情况可以投机取巧，那就是如果保证redis是单机版的前提下，可以使用redis自带的数据库进行多租户的管理，但是这个方案有有很大的制约：

• redis必须是单机版，集群模式的redis不支持分库即select操作;

• 该隔离只是逻辑层面上的隔离，底层并没有做隔离，FLUSHALL命令可以清空一个Redis实例中所有数据库中的数据;

• redis也不支持为每个数据库设置不同的访问密码，所以一个客户端要么可以访问全部数据库，要么一个数据库也没有权限访问;

从上面可以看出，其实redis的分库操作并没有想象中的那么美好。

最后考虑到公司产品对redis的占用比较少，所以更简单的方式就是使用docker快速部署多个redis实例来支撑多版本多租户，效果和单实例多套key效果差别不大。不仅不需要修改代码而且在实施上更容易把控。

总结

K8S的出现极大的提升了产品以及系统运维的效率以及效果，成为各个公司以及各个场景的宠儿也在意料之中。但是我们也没有必要过分神话K8S的作用，从而事事都K8S化，这样显然是矫枉过正的。

回到今天的需求，通过分析，对于公司产品来说，大数据组件由于其稳定性，对K8S的需求并不是很强烈，而且每个产品和系统都部署各自的存储集群的话，对整个K8S的资源也是一个浪费，更推高了K8S使用成本以及性能调优成本，得不偿失。

所以换个思路，将大数据组件以及存储单独部署在物理机上形成一个集群，而产品的应用利用K8S的特性进行管理，可以算是各取所需，扬长避短，也算是一个比较实际和高效的方案了。而实现这个目标的基础就是要实现大数据组件多租户以及资源隔离，也就是本文的需求来源了。

最后，如果想一起入门学习K8S的小伙伴，欢迎点赞转发加关注，下次学习不迷路，我们在K8S的路上共同前进！

最后挂个公众号二维码，公众号的文章是最新的，CSDN的会有些滞后，想追更的朋友欢迎大家关注公众号，谢谢大家支持。 

公众号地址：

了解更多Greenplum技术干货，欢迎访问Greenplum中文社区网站

​Greenplum 是最出色的开源MPP数据库，经过15年的发展，从数据仓库发展成了云时代的理想大数据平台。

1. 什么是多租户

多租户指一套系统能够支撑多个租户。一个租户通常是具有相似访问模式和权限的一组用户，典型的租户是同一个组织或者公司的若干用户。

要实现多租户，首先需要考虑的是数据层面的多租户。数据层的多租户模型对上层服务和应用的多租户实现有突出影响。本文重点介绍数据层多租户及Greenplum数据库对各种多租户模型的支持。

权衡不同的多租户实现方式时，需要考虑如下因素：

• 扩展性：租户数量级别，以及未来发展趋势

• 安全性：租户之间数据隔离级别要求

• 资源共享：多租户通常有某种形式的资源共享，需要避免某个租户的糟糕SQL吃掉系统资源，影响其他租户的响应时间

• 灵活性：不同租户可能有不同的需求，对特定租户需求的扩展能力

• 跨租户分析和优化：对全部租户或者多个租户的数据和行为进行分析的能力

• 运维和管理：运维管理的复杂度和便宜性，包括监控、修改数据库模式、创建索引、收集统计数据、数据加载等

• 成本：总体拥有成本，包括方案实现成本、运维成本等

2. 多租户模型

多租户模型描述了租户和该租户的数据之间的映射关系。不同的多租户模型会影响数据库和应用程序的设计、管理和维护。

使用较多的多租户模型有三种。 Greenplum 对这三种模型都有出色的支持。

2.1 一租户一数据库

最简单的多租户实现方式是为每一个租户创建一个Greenplum集群，如下图所示。应用程序为每个租户分配一个租户id，并为每个租户配置相应的数据库连接信息（包括数据库ip、端口等）。应用程序根据租户id连接到为其分配的数据库。

这种模型中不同租户的数据物理隔离，安全级别高。如果每个租户的Greenplum集群使用不同的硬件，则他们之间的资源使用也是物理隔离的；如果租户的Greenplum集群共用同一套硬件，则需要对资源进行合理分配和管理，避免相互影响。由于不同租户使用独立的数据库，灵活性好，容易满足不同租户的特定需求（譬如需要额外的字段）。出现故障时影响面小。缺点是数据库数量大，维护复杂，拥有成本高。适合租户数目比较少的场景。

2.2 一租户一名字空间

多个租户共享同一个数据库，每个租户拥有独立的名字空间（或模式）。应用程序为每个租户分配一个id，并把每个租户的所有操作限制在为其分配的名字空间/模式之中。如下图所示。

这种多租户模型下，不同租户的数据逻辑上相互隔离，安全控制相对简单。不同租户有不同的模式，可以简便的满足不同租户的特定需求，灵活性高。对资源管理能力要求高，以避免不同租户竞争资源。结合 Greenplum 的 filepace 和 tablespace 特性，可以把不同租户的数据存储在不同的磁盘上，降低了对磁盘IO的竞争。运维和管理较复杂，不易实现大量租户的跨租户分析。适合租户数目适中的场景。

2.3 全共享方式

不同租户共享同一个数据库、同一个名字空间。不同租户的数据在同一组表中共存，通过租户id标记和访问不同租户的数据（应用需要调整访问数据的SQL以包含租户id）。如下图所示。

这种多租户模型中，不同租户的数据物理存储在一起，对系统的资源隔离和安全隔离要求很高。运维相对简单。扩展能力好，可以支持较多数量租户。由于租户数据存储在一起，跨租户数据分析和优化非常简单。成本低，可以较低的代价支持更多的租户。

全共享模型中，很多数据库采用添加大量自定义字段的方式满足不同租户的特定需求，以提高灵活性。这种方式有诸多局限性，譬如字段数目不能太多、管理复杂等。Greenplum 自 5.0 开始支持更多半结构化数据，包括JSON、Hstore 等，通过这种半结构化数据，可以更灵活、高效、便捷的满足不同租户的特定需求。

2.4 混合模型

这种模型不是一个新的实现方式，而是混合前面介绍的三种模型以满足不同用户的服务级别需求。譬如对于最大的少数几个租户采用一租户一数据库的模型，其他租户采用全共享方式。或者对资源隔离级别要求高、服务响应时间要求高的客户采用一租户一数据库的模型，其他租户采用一租户一名字空间方式或者全共享方式。

2.5 对比

下表列出了不同模式的特点。混合模型兼具不同模型的优缺点，不再单独列出。根据不同需求可以采用不同的实现方式。

3. Greenplum 资源管理

上面提到，不管使用何种多租户模型（除非是不同的物理集群），否则都涉及到资源管理的问题，以满足不同租户的不同资源使用需求，避免某个租户过度使用资源，影响其他租户。

Greenplum 5 设计实现了一个全新的基于资源组的资源管理器，相比之前的资源队列，可以做到灵活高效的资源管理。

下表对资源组和资源队列进行了对比：

Greenplum 可以实现细粒度的资源管理，在云上多租户场景下，非常适合实现租户的资源隔离，避免某个租户过度占用资源，确保资源合理使用。

有关更多细节，请参考官方文档：

https://gpdb.docs.pivotal.io/580/admin_guide/workload_mgmt_resgroups.html

4. 总结

多租户是云数据库的基本要求，本文介绍了Greenplum的四种多租户实现方式，并对之进行了对比。还介绍了 Greenplum 新的基于资源组的资源管理器，以实现多租户的资源共享和隔离。