如何部署active-active的Hadoop集群

温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。

Fayson的github：https://github.com/fayson/cdhproject

提示：代码块部分可以左右滑动查看噢

1.文档编写目的

基于Hadoop部署企业数据中心(EDH)一个最主要的好处就是利用其横向扩展的能力。单个集群可以扩展到数千个节点。此外，根据一些生产系统的需要，此集群还包括数据的多级备份策略以及故障/错误保护，从而保证数据不丢以及系统的容错。然而，很多企业依旧需要多个集群来保证真正的容灾，为什么需要搭建多个集群，最主要的三个原因包括整个单一集群故障，地理位置，和基于不同的集群部署不同的应用。

1.1.集群故障

集群故障是指当数据和应用程序访问需要的正常运行时间，一个集群无法保障的情况，比如整个集群故障或停机。这适用于需要100%时间都正常运行的系统。集群可以按照计划或者因为计划外的原因停机，但为了超过99%的时间都正常运行应用作业，我们需要一个可以用作故障切换的另外一个集群。

1.2.地理位置

为了满足基于不同地理位置(如美国东部，美国西部，欧洲和亚洲)的实时需求，一般会设计部署多个集群在不同的地理位置，但这些不同的集群需要共享同样的数据，从而保证比如亚洲的请求回复跟美国东部的相同或者尽可能相同。常见例子包括支付监控系统，游戏平台和全球金融系统。

1.3.分离应用场景

什么时候需要通过集群来分离应用场景呢？通常我们可以通过SLA级别来划分，比如一些高SLA要求和一些低SLA要求的应用。我们可以使用一个集群是用作满足高SLA要求工作负载的，同时利用另一个集群主要运行一些低SLA要求的工作负载，两个集群基于同样的数据。比如在集群A上运行生产作业，研究开发或沙箱测试则基于集群B。这种集群分离，可以让一些Ad-hoc的作业更加灵活的运行在集群B而不会影响到生产系统。另外，如果集群A出故障了，生产作业可以迁移到集群B，同时阻止低SLA要求的作业运行。

2.什么是Active/Active

“Active/Active”是多集群部署的一种方式。但“Active/Active”对于不同的应用场景有不同部署和配置方式(本文后面会说明)，本文提到的“Active/Active”主要包括以下定义：

1.由多个集群组成

2.如果一个集群故障，通过迁移到另外的集群可以满足所有运营维护需求

3.万一单集群故障，可以避免数据丢失

4.支持Apache Hadoop生态系统的任何组件，不止HDFS

5.支持选择需要复制的数据

6.支持管理配置复制优先级和吞吐

Cloudera的EDH，CDH的企业版，可以让你简单的实现多个集群的“Active/Active”，通过使用Cloudera Manager集成的自动化备份和灾难恢复功能。(Backup and Disaster Recovery简称：BDR)

3.Active/Active的业务目标

主要是为了实现Hadoop和企业数据中心(EDH)的全部功能，同时不会受限于单集群的问题(如整个集群故障)，并可以完全分离工作负载。本节将列出为什么构建多集群是值得的。

3.1.集群级别丢失数据

虽然EDH中的文件默认都有三个副本，以防节点和磁盘发生故障导致的数据丢失，但是对于整个集群故障(比如自然灾害，人为操作错误，甚至被恶意攻击)的情况，许多行业或者企业依旧需要额外的防范。一个例子是按照萨班斯-奥克斯利法案(Sarbanes-Oxley)规定的大多数的金融公司为了保护他们的数据需要跨区域的部署数据中心。这个规定是为了将公司的数据以最小的距离分开保存在不同的地方从而保护数据，以确保各种灾难都不会造成丢失数据。

Cloudera企业版允许集群间的故障切换(本文后面会说明)，因此企业可以将他们的数据存储在多个物理位置达到保护数据的目的。

3.2.高SLA要求的工作负载快速故障切换

Hadoop可以让你将处理和分析任务转移到不同集群，并基于相同的数据重新运行起来。如果所需的数据在任何一个已连接的集群中可用，则你可以将作业(全文检索，SQL语句，jar包文件等)发送到任何一个保存了这些数据的集群来执行。这对于你有一些计划外的用户的作业需要临时运行是比较常见的，同时你也不能让一个集群的故障停机影响到已经在运行的一些作业。常见的场景比如运行近实时(NRT)的HBase作业，或者说基于Impala运行SQL数百名用户。

3.3.完整的工作负载隔离

Cloudera企业版具备许多内置的功能在单个集群中来保护各种工作负载不互相影响，包括CPU,内存和磁盘的使用控制。然而如果这些功能一旦没有配置好，仍然会出现资源的争用情况。通过集群隔离，不仅可以100%避免资源争用，而且可以完全利用第二个用于故障切换的集群资源来运行一些特定的工作负载比如研究或开发。通过配置不同的两个集群，你还可以对于不同的应用场景进行特定的优化。

有一个很好的例子参考用作部署两个集群，一个主集群用作高SLA要求的生产系统，另一个集群用作低SLA要求的ad-hoc的研究。如果主集群故障了，则可以将高SLA要求的作业切换到备份集群，同时暂停备份集群的ad-hoc作业，直到主备两个集群都同时正常工作。这种设计可以让你避免单集群故障或者集群上任何ad-hoc误操作带来的风险。

3.4.全球国家

一些企业经常用Cloudera企业版构建用户的360度画像视图。当这些用户在全球各地旅行时，无论他们在哪里，他们都期望能以较低的延时连接到最近的集群，并获得相同的个性化信息。Active/Active可以让企业在全球所有的集群之间同步数据 - 只会因为这些集群之间的网络速度有一些延迟。

这种业务场景的一个例子是比如我们需要监控全球任何地方的用户行为，但是我们希望他们能跟最近的集群进行直接的交互，从而避免不必要的延迟比如信用卡欺诈所需的。

4.多集群的Active/Active常见原型

在EDH中复制数据有很多种架构选择。这些架构都有不同的优点和缺点，但架构的选择一般取决于应用场景。选择哪个架构需要考虑多个因素，以下列出一些注意事项：

1.数据大小：一个一般的EDH集群如果用满10Gb的网络，通常五分钟就可以完成数据生成。

2.压缩率：使用压缩文件意味着集群之间复制数据时可以传输更多的数据，通常我们会在压缩率和解压处理速度之间取一个折中的压缩格式。

3.低延时的需求：给定数据集的SLA要求：秒级，分钟级还是小时级别。

4.底层的存储系统：存储不同需求也不同，比如HDFS通常是大批量的，Hive表需要考虑元数据，HBase一般是准实时或者是基于事件的。

下面讨论大部分EDH复制数据的原型设计，但对于一些特定的应用场景可能需要进行定制化的设计或开发。Cloudera企业版可以让企业扩展数据管理和处理的边界，并且当新的需求产生时，他的灵活性以及生产就绪的特性使其适应性更强。

4.1.批量的表/文件复制

批量复制HDFS文件或者Hive的表，是比较简单的。使用Cloudera企业版附带的备份和灾难恢复功能(BDR)，可以为数据集（文件夹），数据库或者表定义以下内容：

1.触发复制的条件：可以使用按照计划的时间间隔，或者使用Cloudera Navigator的策略来触发复制，或者其他按需复制。

2.复制的频率是多少：按照优先级和SLA要求排序。

3.允许多少带宽：按照数据集大小的优先级排序，并管理集群和集群之间的网络吞吐。

4.复制时是否允许删除：关闭复制时删除或者通过回收站机制可以防止人为的误操作。

5.选择源集群和目标集群：为了避免混淆，一般将复制定义为单向。

6.通知什么和如何被通知：BDR包含了很多通知选项。这样你可以跟踪数据的复制流程，一旦发生故障，马上就可以知道复制了哪些数据。

BDR是建立在Hadoop的命令Distcp之上的，因此，Cloudera企业版包含以下功能：

1.并行复制数据。

2.按字节复制数据，所以压缩数据在传输时不需要被解压。

3.复制的数据保留所有权限。

4.在复制数据的过程中，文件会被先放到目标集群的一个tmp目录，从而不会对目标集群基于同样目录正在运行的作业造成影响。

4.2.双写

根据一些企业的要求，通常是实时处理而不是批处理。对于这些应用场景，Kafka和Flume支持双写到两个集群。

在此设计中，Kafka被用作数据传输的通道或者管道，而Flume则可以将数据写入到HDFS，HBase或Solr并保存起来。

Kafka可以用作这个场景是因为：

1.水平可扩展。

2.Internalreplication to avoid data loss

3.保证跨集群的复制数据不丢(Kakfa MirrorMaker)

4.压缩可以减少占用带宽。

5.在处理错误，长时间中断或者任何其他的原因情况下，可以配置和存储几天的数据。

6.ConsumerGroups可以重新分配给剩余的其他消费者，以便万一单个消费者失败。

Kafka只是一个队列或者管道 - 它不会对数据进行改变或者持久化数据到目标存储。这时我们就需要Flume。它可以将数据写入到HDFS，HBase或者Solr，并且在业界已经稳定运行了多年。多个Flume节点可以一起工作作为Kafka的消费者。通过Kafka的Consumer Groups，如果一个Flume的节点出现故障，其他的Flume节点可以进行续传。你可以通过设置Flume的interceptor和serializer，从而对数据进行一些转化处理在写入最终目标存储前。

4.2.1双写与BDR的比较：

1.双写可以降低数据同时到达两个集群的延迟，BDR通常是数据单向先写入到主集群，然后通过主集群复制数据到备份集群。

2.双写比BDR的压缩率要低。根据所使用的压缩编码和文件格式，BDR通常具有更高的吞吐。例如，BDR通常都是基于Parquet和Gzip，而Kafka/Flume一般是基于文本的snappy，一般会有2-5倍的带宽差异。

3.BDR提供通知告诉你知道哪些文件从哪个集群到达了另一个集群。而如果是双写，要提供通知一般比较麻烦。一般你需要给每个事件添加一个时间戳，但这些都需要额外的开发和成本。

4.2.2.MirrorMakervs just Dual Consumer Paths

在决定如何选择Kafka复制数据时，你需要确认是否需要备份Kafka或只是双写。架构设计有一些区别，如果你要复制Kafka，你可能需要使用MirrorMaker，类似于下面的架构图：

这可以将事件都复制到第二个Kafka集群，以防万一第一个Kafka集群挂了，你有第二个Kafka集群作为故障切换。

如果你只是想进行数据双写，你就不需要使用MirrorMaker，那设计如下：

4.3.Apache HBase Replication

HBase是Hadoop中的NoSQL数据库，它有多种数据复制选择，包括主从，主主，或者跨多个集群进行数据复制。核心设计理念比较好理解，当数据写入HBase时，它会将Write Ahead Log (WAL)同时也写入到HDFS。通常，如果不做集群复制，有一个进程会读取这些WAL，把这些加入到Memstore进行分类和排序，然后再次将数据写入磁盘并且将这些数据进行分类和创建索引 - 这个进程叫“Store File Flushing”。

如果设置了HBase Replication, 只是增加一个Replication Queue到上面的设计就行了。它会读取第一个集群的WAL并将新增数据发送到第二个集群。如果第二个集群挂了，则第一个集群的HDFS会保留这些WAL，直到这第二个集群重新起来，然后数据会重新发送到这个集群。

这种设计非常适用于尽可能快的更新远程的HBase集群，但仍然有一些折中权衡考虑。比如所有的事件都写入到WAL，这些WAL都是通过网络来传输的。如果在主HBase集群每秒有非常多的操作超过了网络的极限(吞吐或延迟)，此时Replication Queue会延迟。它会为了追上主集群的每一秒的所有操作而导致延迟，如果追的上，则Replication Queue不会有什么问题。

当使用master-master模式时，数据会在两个集群之间进行复制，数据一致性问题会通过timestamp来解决，最后一次写入成功才算写入成功。还要考虑HBase中的数据一致有时候不仅仅是Rowkey的一致 - 还会有column/value不一致的情况。如果要求数据一致不通过timestamp来解决，可以通过schema的设计来解决，它允许集群特定的column的值的定义和分布范围。

4.4.高级设计

虽然上面的原型设计包含了最常见的应用场景，但仍然不适用于所有的应用场景。比如也许你需要比BDR延迟更低的时间，但仍然是以复制文件的形式。或者你可以通过增大文件压缩率的方式来更好的利用集群之间的网络。

Cloudera企业版的一个好处就是你可以利用它自适应的灵活性来满足复杂的场景和设计。通过各种生产就绪的执行引擎和框架，Cloudera企业版可以满足未来的数据复制应用场景。

对于低延时，高压缩率的例子，你可以使用一个长时间运行的Spark应用程序来解决这个问题，Spark的micro-batches会将这些在主集群需要删除的文件压缩在一起成Gzip+Parquet的格式，并传输到备份集群。这样可以减少BDR的启动和关闭时间，同时通过Gzip提高压缩率可以减少带宽使用。

但这只是某一个应用场景的某一个解决方案。Cloudera可以和合作伙伴一起为你设计最佳的解决方案基于你的应用场景和需求。

5.架构设计

5.1.Pipe Size

企业在实施多集群EDH时面临的问题之一最常见的就是集群之间的带宽太低。无论是10Gb/s, 40Gb/s, 80Gb/s还是更多，始终都可能被占满。比如一个100节点的集群可以让两个集群之间的10Gb/s带宽占满达24小时，如果它花10分钟来疯狂生成数据。

我们以下图作为例子来说明。如果你有2个100节点的集群，两个集群之间的带宽是20Gb/s，然后每个节点跟交换机之间是10Gb/s。在这种情况下，只需要两个节点就可以占满集群间的带宽。

这对企业意味着什么呢：

1.需要给数据优先级排序：下一节会详细说明这一点。简言之，只复制那些需要复制的数据。

2.管理员需要制定数据复制策略：由于网络带宽是共享资源，所以管理员需要监控和控制带宽使用。管理带宽使用最简单的方法是使用BDR和Cloudera Manager。

3.压缩：每一个原型设计需要使用不同的压缩率，从传输使用Snappy到Gzip+Parquet。根据选择不同的压缩方式，可以降低使用带宽2-30倍。

4.SLA&延迟：下一节会详细说明，由于受到带宽的限制，而且网线是有限的，因此在延迟和压缩率之间存在一些折衷选择。

5.2.数据分类

如上所述，EDH可以存储和生成大量的数据。这意味着我们需要选择哪些数据需要传输备份。

对于某些数据，可以比较简单的知道是否需要传输备份。在数据沙箱环境中使用和生成的数据，或者用来作为ad-hoc研究的数据通常不需要备份。重要的是EDH用户不用考虑集群间的带宽是否已经被占满了，我们也不希望管理员让用户停止实验或者研究。此外，刚装载到集群里的原始数据和多步ETL过程中的中间结果和临时文件不需要备份。等等这些都取决于你的应用场景，需求和不同数据集的SLA。

一旦你选择了需要备份的数据，确保压缩数据。有很多原因，包括：降低每TB的成本，减少数据源的读取资源，另外可以使用固定的集群间带宽传输更多的数据。

5.3.延迟和压缩的折衷考虑

压缩对于备份数据非常重要，但是根据上面的描述，但是每个事件的低延时和高压缩率通常是矛盾和冲突的。定义数据备份和复制策略时，必须仔细考虑和衡量这两个指标。

压缩率取决于你的压缩编码以及数据”量“(entropy)。当你在流式传输数据时，为了减少数据“量”的时间非常少（选择高压缩率压缩文件时一般耗时较久），但是在批处理的过程中，我们则可以实现更高的压缩率 - 这就是矛盾和冲突的，低压缩率+低SLA和高压缩率+高SLA。

一个例子是批处理就选择Parquet这种文件格式，这种列式文件格式可以降低整体数据“量”，并且压缩率很高。

流式计算场景，可以选择Snappy或LZO的压缩编码来提高速度，这种压缩率比Gzip要低，但是在写入数据时会消耗更少的CPU。

所以，流式计算场景一般的数据压缩范围为2x，而批量场景数据压缩可以到8-15x。

具体的压缩率取决于真实的数据以及其自然熵，但是比率基本在该文档描述的范围之内。

提示：代码块部分可以左右滑动查看噢

为天地立心，为生民立命，为往圣继绝学，为万世开太平。 温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。

推荐关注Hadoop实操，第一时间，分享更多Hadoop干货，欢迎转发和分享。

原创文章，欢迎转载，转载请注明：转载自微信公众号Hadoop实操