17、基于 Apache Bigtop 的 Hadoop 数据处理栈开发与部署

基于 Apache Bigtop 的 Hadoop 数据处理栈开发与部署

1. 基础概念

在大数据领域，有许多基于 Apache Hadoop™ 的数据处理栈，例如 Amazon EMR 和 Hortonworks Data Platform。其中，Apache Hadoop™ 可能是最为人熟知的数据处理栈，它由 HDFS（存储层）和 MR（分布式存储之上的计算框架）组成。不过，这种简单的组合已无法满足现代需求，但 Hadoop 常被用作高级计算系统的基础。一个完整的 Hadoop 栈通常会扩展其他组件，如 Apache Hbase™、Apache Hive™、Apache Ambari™（安装和管理应用程序）等，具体扩展组件及版本如下表所示：

组件	版本
hadoop	2.7.1
hbase	0.98.12
hive	1.2.1
ignite-hadoop	1.5.0
giraph	1.1.0
kafka	0.8.1.1
zeppelin	0.5.5

那么，如何构建、验证、部署和管理这样一个“简单”的软件栈呢？我们先从验证说起。

2. 测试栈

测试栈的目的是确保软件在交付时能够正常运行，并实现预期功能。它包含多个应用程序，通过运行特定工作负载、暴露组件集成点以及验证组件之间的兼容性，来验证软件栈的可行性。

例如，在上述示例中，测试栈将包括集成测试应用程序，确保 Hbase v 0.98.16 能在 Hadoop 2.7.1 上正常工作，能与 Hive 1.2.1 协同工作，能使用底层的 Hadoop Mapreduce，能与 YARN（Hadoop 资源导航器）配合，并能将 Hbase 0.98.16 用作外部表的存储。同时，Zeppelin 验证应用程序可确保数据科学家的笔记本能正确构建并配置，以与 Hbase、Hive 和 Ignite 协同工作。

3. “在我笔记本上能运行”的局限性

一个典型的现代数据处理栈包含 10 到 30 多个不同的软件组件，且大多数组件作为独立的开源项目，有自己的发布计划、时间表和路线图。此外，还需要在 CentOS7 和 Ubuntu 14.04 集群上使用 OpenJDK8 运行该栈，同时还要考虑旧版本栈的升级需求。因此，“在我笔记本上能运行”的方法已不再可行。

4. 开发定制化栈

软件开发者、数据科学家或商业供应商如何开发、验证和管理一个可能包含市场上尚未提供的组件版本的复杂系统呢？接下来我们将探讨如何开发一个满足软件和运营需求的软件栈。

4.1 Apache Bigtop 的历史

Apache Bigtop（http://bigtop.apache.org）经历了多次演变和修订：
- 2004 - 2005 年，Sun Microsystems Java Enterprise Stack（JES）的创建和交付结合了 Tinderbox CI 和描述栈组成的构建清单。
- Sun Microsystems 进一步尝试开发栈框架概念，旨在管理企业存储服务器的软件栈。该框架跟踪更多信息，但具有特定领域性、严格的数据库模式和依赖实现的构建系统。
- Yahoo! Hadoop 团队开发了用于管理和支持 Hadoop 0.20.2xx 软件栈生产的框架，这是 Apache Bigtop 的前身。随着安全性的引入，组合复杂性急剧增加，在现有时间和资源限制下难以管理。
- 现代 Apache Bigtop 的第一个版本由实现 Yahoo! 框架的工程师开发，引入了软件和测试栈的正确概念化，提供了能在分布式环境中工作的集成测试框架等诸多改进。早期的部署配方和打包由 Cloudera 的开发者贡献，2011 年春季提交给 Apache 软件基金会进行孵化，后来成为顶级项目。

如今，Apache Bigtop 被所有 Apache Hadoop 商业供应商用作其发行版的基础框架，这为最终用户带来了许多好处，因为不同发行版的包布局、配置位置和生命周期管理路由方式相同。不过，Apache Ambari 和一些闭源集群管理器除外，它们使用自己的生命周期控制电路，绕过了标准的 Linux init.d 协议。

4.2 Apache Bigtop 的概念和哲学

从概念上讲，Bigtop 由四个子系统组成，各有不同用途：
1. 栈组成清单或物料清单（BOM） ：定义了栈中包含的组件、版本、源代码位置等信息。
2. Gradle 构建系统 ：管理工件创建（包）、开发环境配置、集成测试执行等功能。
3. 集成和冒烟测试及 iTest 测试框架 ：用于验证软件栈的集成性和正确性。
4. 部署层 ：通过 Puppet 配方实现无缝集群部署和配置管理，可快速部署功能齐全的分布式集群。

Apache Bigtop 为栈应用开发者、数据科学家和商业供应商提供了可预测和完全可控的流程，用于迭代设计、实现和交付数据处理栈。其哲学理念是经验验证，而非软件开发中的理性方法。这是因为栈运行的环境复杂多变，许多因素会影响分布式系统的性能和稳定性，如内核补丁级别、运行时环境版本、网络策略等。通过 Apache Bigtop 进行全栈集成验证，可以发现已发布项目中可能存在的向后不兼容更改，从而及时修复问题。

同时，结合 Jenkins 和 TeamCity 等持续集成工具，使用 Apache Bigtop 可以缩短开发周期，提高软件质量，快速发现 bug。你可以通过信息散热器（https://cwiki.apache.org/confluence/display/BIGTOP/Index）快速了解当前问题。

5. 项目结构

Bigtop 项目的顶级结构包含以下重要部分：
- build.gradle ：构建系统的核心。
- packages.gradle ：构建系统的核心。
- bigtop.bom ：默认的栈组成清单。
- bigtop_toolchain/ ：设置开发环境。
- bigtop-test-framework/ ：iTest 集成测试框架的所在目录。
- bigtop-tests/ ：包含集成和系统测试的所有代码以及 Maven 构建，用于配置环境并针对集群运行测试。
- bigtop-deploy/ ：包含分布式集群、虚拟和容器环境的所有部署代码。
- bigtop-packages/ ：提供创建可安装二进制工件所需的所有内容。

6. 构建系统

Apache Bigtop 构建系统使用 Gradle（http://gradle.org/），Bigtop 源代码树包含一个 gradlew 包装脚本。要开始使用 Bigtop，你需要 JDK7 或更高版本，并克隆 Bigtop 仓库：

git clone https://git-wip-us.apache.org/repos/asf/bigtop.git

你也可以从 github.com 镜像（http://github.com/apache/bigtop.git）进行分叉。要查看可用任务列表，可运行：

cd bigtop
./gradlew tasks

可以一次性构建栈组件：

./gradlew deb 或 ./gradlew rpm

也可以进行显式选择：

./gradlew allclean hive-rpm

Bigtop 构建系统可用于创建开发环境和构建二进制文件、编译和运行测试、将项目工件部署到中央仓库、构建项目网站等。它还可以指定栈中组件之间的依赖关系，确保上游依赖项在需要时自动先构建。例如，在构建时传递 -Dbuildwithdeps=true 参数，Bigtop 会先下载并构建 Hadoop，然后再构建 Hive。默认情况下，Bigtop 仅构建显式指定的组件。

此外，Bigtop 提供了从现有包生成本地 apt 和 yum 仓库的功能，允许栈开发者通过指向本地文件系统中的仓库位置来快速测试新构建的包：

./gradlew apt|yum

这将使用顶级 output/ 目录下找到的所有 DEB 或 RPM 包创建相应的仓库。在任何时候，要探索最终用户可用的所有标准任务，可执行：

./gradlew tasks

7. 工具链和开发环境

为了创建包含数十个组件的栈，系统需要配备大量开发工具。Bigtop 工具链（位于 bigtop_toolchain/ 顶级目录下）提供了所有受支持平台的开发需求。Bigtop 使用 Puppet 不仅用于部署，还用于设置开发环境。你无需成为 Puppet 专家，只需确保具有 sudo 权限并运行以下命令：

./gradlew toolchain

这将自动为你的系统安装所有包，包括栈组件所需的正确版本的 JDK。

8. BOM 定义

Bigtop 提供了物料清单（BOM）文件，用于表达包含的组件、版本、源代码位置等属性。默认的 BOM 文件名为 bigtop.bom ，使用简单的自文档化 DSL。以下是一个典型的组件描述示例：

'hbase' {
  name    = 'hbase'
  relNotes = 'Apache Hbase'
  version { base = '0.98.12'; pkg = base; release = 1 }
  tarball { destination = "${name}-${version.base}.tar.gz"
            source      = "${name}-${version.base}-src.tar.gz"}
  url  { download_path = "/$name/$name-${version.base}/"
         site =    "${apache.APACHE_MIRROR}/${download_path}"
         archive = "${apache.APACHE_ARCHIVE}/${download_path}"}
}

可以使用同一作用域或 BOM 其他部分中已定义的变量，如 pkg = base 。DSL 处理器在检测到任何错误时将停止构建。

组件的标准源是官方 Apache 项目发布，但你也可以通过指向不同的源存档位置来从其他地方构建组件。可下载的 URL 会自动构造为 url.site/url.download_path/tarball.source 。例如，如果你想从 GitHub 仓库的 branch - 1.2 分支构建 Hbase，可将定义修改为：

tarball { destination = "${name}-${version.base}.tar.gz"
          source      = "hbase-1.2.zip" }
url     { download_path = "apache/hbase/archive"
         site = "https://github.com/${download_path}"
         archive = site }

然后运行 ./gradlew hbase-clean hbase-deb 为 Debian 生成一组新的二进制文件。此外，还可以直接从 Git 版本控制系统创建组件包，更多信息请参考 Bigtop 源代码树顶级文件夹中的 README.md 文件。

9. 部署

拥有开发和验证栈的工具只能构建包，如果无法部署和运行工作负载，这些包的价值就有限。软件栈通常提供安装（在分布式环境中为部署）、管理和控制其组件及状态的方法，Bigtop 也提供了几种配置环境的方式。

9.1 Bigtop 预配置器

Bigtop 预配置器是框架的一个子系统，提供了使用虚拟机或 Docker 容器快速启动完全分布式 Hadoop 集群的便捷方式，位于项目源代码树的 bigtop-deploy/vm 目录下。详细信息可参考：https://cwiki.apache.org/confluence/display/BIGTOP/Bigtop+Provisioner+User+Guide。以下是使用步骤：
1. 打开 <BIGTOP_ROOT>/bigtop-deploy/vm/vagrant-puppet-docker vi vagrantconfig.yaml 文件。
2. 更新 Docker 镜像名称，从 bigtop/deploy:centos-6 或 bigtop/deploy:debian-8 更改，并将仓库指向 https://cwiki.apache.org/confluence/display/BIGTOP/Index。选择要部署的组件，如 [hadoop, yarn, hbase] 。
3. 运行命令： ./docker-hadoop.sh --create 3

标准预配置器带有预定义的配置，如果你不需要特殊配置，可直接使用。预配置器集成到了构建系统中：

./gradlew -Pnum_instances=3 docker-provisioner

假设你的计算机已安装 Vagrant 和 Docker，执行上述命令后将启动一个完全分布式的集群。你可以通过 SSH 进入集群节点并执行常规操作。预配置器脚本支持更多命令，详细信息请参考顶级 README.md 文件。要了解更多关于使用 Docker 进行 Hadoop 预配置的信息，可参考 Evans Ye 的相关演示（http://is.gd/FRP1MG）。

9.2 无主 Puppet 集群部署

对于更复杂的集群配置情况，可使用 Bigtop Puppet 配方（位于项目源代码树的 bigtop-deploy/puppet 目录下）。这是一种高级的集群设置方式，除非你需要自行管理集群，否则可以跳过此部分。完全分布式部署与预配置器示例相比需要更多步骤，但通过几个额外的命令，你可以根据需要启动任意规模的集群，可选择为 HDFS 和/或 YARN 提供高可用性，以及设置或不设置安全性。

部署系统的实现是一个无主动态系统，所有节点具有相同的配方，但不同节点接收自己的配置文件。部署系统使用 Puppet Hiera 查找和收集模块收集节点信息，并将其与 Bigtop 配方中的角色定义进行对比。以下是一个高级示例：
- Bigtop 提供默认拓扑模板文件 bigtop-deploy/puppet/hieradata/site.yaml ，定义了集群的一些关键参数，如 bigtop::hadoop_head_node 、 hadoop::hadoop_storage_dirs 、 hadoop_cluster_node::cluster_components 以及可选的 bigtop::roles 列表。重要的是，头节点必须设置为完全限定域名（FQDN），否则节点识别将无法工作。
- 默认情况下，角色机制关闭，集群中的所有节点被分配为工作节点，头节点承担主节点角色。如果部署 HDFS 和 YARN，头节点将运行 NameNode 进程和 Resource Manager 进程。组件集由 hadoop_cluster_node::cluster_components 定义，如果未显式设置该列表，将安装和配置所有可用包。
- 要使用角色机制，在 site.yaml 中设置 bigtop::roles_enabled: true 并为每个节点指定角色。但这可能需要为不同节点管理单独的配置，尤其是在集群拓扑简单的情况下。每个守护进程的完整角色列表可在 bigtop-deploy/puppet/manifests/cluster.pp 清单中找到。
- 完整的配置参数列表及其默认值可在 bigtop-deploy/puppet/hieradata/bigtop/cluster.yaml 文件中找到。

假设存在五个运行 Ubuntu 14.04 的节点，主机名分别为 node[1 - 5].my.domain ，节点功能如下：
- node1 到 node5 为工作节点。
- node1 作为头节点。
- node5 处理网关功能。

要部署的栈包括 HDFS、mapred - app、ignite - hadoop 和 Hive 组件。以下是部署步骤：
1. 在 node1.my.domain 节点上，在 /work 目录下克隆项目 Git 仓库。
2. 根据上述布局， site.yaml 文件内容如下：

bigtop::hadoop_head_node: "node1.my.domain"
bigtop::hadoop_gateway_node: "node5.my.domain"
hadoop::hadoop_storage_dirs:
  - /data/1
  - /data/2
hadoop_cluster_node::cluster_components:
  - ignite_hadoop
  - hive
bigtop::jdk_package_name: "openjdk-7-jre-headless"
bigtop::bigtop_repo_uri: \
"http://bigtop-repos.s3.amazonaws.com/releases/1.1.0/
ubuntu/14.04/x86_64"

3. 确保所有节点具有相同的配方和配置。由于 Puppet 会修改系统状态，必须以特权账户（如 root）执行。如果节点之间具有无密码 SSH 登录，操作会更方便，否则可在提示时手动输入密码。使用 rsync 或其他方式将 /work 文件夹的内容同步到集群中的所有节点，推荐使用 pdsh 和 rsync 命令，但需指定 SSH 用户名和 SSH 密钥路径，详细信息可查看 rsync 手册页。

通过以上步骤，你可以使用 Apache Bigtop 开发、验证、部署和管理复杂的数据处理栈，满足不同的软件和运营需求。

基于 Apache Bigtop 的 Hadoop 数据处理栈开发与部署

10. 集成验证

在完成了数据处理栈的开发与部署后，集成验证是确保整个系统能够正常工作的关键步骤。通过集成验证，可以发现各个组件之间的兼容性问题、数据传输问题以及系统整体的稳定性问题。

10.1 集成测试框架 iTest

Bigtop 提供了集成测试框架 iTest，它位于 bigtop-test-framework/ 目录下。iTest 能够在分布式环境中工作，对软件栈进行全面的集成测试。测试代码位于 bigtop-tests/ 目录中，使用 Maven 进行构建和配置环境，然后针对集群运行测试。

以下是使用 iTest 进行集成测试的一般步骤：
1. 确保开发环境已经正确配置，并且集群已经部署完成。
2. 进入 bigtop-tests/ 目录。
3. 使用 Maven 命令进行测试：

mvn clean test

这个命令会执行所有的集成测试用例，并输出测试结果。

10.2 具体测试场景

以 Hbase、Hive 和 Ignite 为例，测试它们之间的集成情况。
1. Hbase 与 Hadoop 的集成测试 ：确保 Hbase v 0.98.16 能够在 Hadoop 2.7.1 上正常工作，使用 Hadoop 的存储和计算资源。
2. Hbase 与 Hive 的集成测试 ：验证 Hbase 能够作为 Hive 的外部表存储，实现数据的交互和查询。
3. Zeppelin 与 Hbase、Hive、Ignite 的集成测试 ：保证数据科学家的笔记本能够正确构建并配置，与这些组件协同工作。

11. 持续集成与质量保障

持续集成工具如 Jenkins 和 TeamCity 已经成为日常软件工程过程的一部分。结合 Apache Bigtop 使用持续集成工具，可以带来诸多好处。

11.1 缩短开发周期

通过持续集成，每次代码提交后都会自动触发构建和测试流程。如果发现问题，能够及时反馈给开发者，避免问题积累到后期才被发现，从而大大缩短了开发周期。

11.2 提高软件质量

持续集成过程中，会对软件栈进行全面的集成测试和验证。这有助于发现软件中的 bug 和兼容性问题，及时进行修复，提高软件的整体质量。

以下是使用 Jenkins 与 Apache Bigtop 进行持续集成的基本流程：
1. 安装 Jenkins ：在服务器上安装 Jenkins，并进行基本配置。
2. 配置 Jenkins 项目 ：创建一个新的 Jenkins 项目，配置项目的源代码仓库（如 Bigtop 的 Git 仓库）。
3. 设置构建步骤 ：在 Jenkins 项目中设置构建步骤，包括克隆代码、运行 ./gradlew 命令进行构建和测试等。
4. 设置定时任务 ：可以设置定时任务，定期触发构建和测试流程，确保软件栈的稳定性。

12. 总结与展望

通过本文的介绍，我们了解了基于 Apache Bigtop 的 Hadoop 数据处理栈的开发、部署和管理过程。Apache Bigtop 提供了一套完整的解决方案，从栈的组成定义、构建系统、测试框架到部署机制，都为开发者和数据科学家提供了便利。

在未来，随着大数据技术的不断发展，数据处理栈的规模和复杂度可能会进一步增加。Apache Bigtop 也需要不断地进行改进和优化，以适应新的需求。例如，支持更多的组件和版本，提高部署的灵活性和效率，加强安全性能等。

同时，持续集成和质量保障将变得更加重要。通过引入更多的自动化测试和监控工具，可以进一步提高软件的质量和稳定性，减少人为错误和故障的发生。

13. 关键知识点总结

为了方便大家回顾和掌握本文的关键知识点，下面以表格的形式进行总结：

知识点	描述
Apache Bigtop 概念	由栈组成清单（BOM）、Gradle 构建系统、集成测试框架和部署层组成，提供可预测和可控的流程
构建系统	使用 Gradle，可一次性或显式选择构建组件，能处理组件依赖关系，还能生成本地仓库
开发环境	通过 bigtop_toolchain/ 工具链和 Puppet 自动安装所需包和 JDK
BOM 定义	使用简单 DSL 定义组件信息，可修改源位置构建组件
部署方式	包括 Bigtop 预配置器和无主 Puppet 部署，可根据需求选择
集成验证	使用 iTest 框架进行集成测试，确保组件间的兼容性和系统稳定性
持续集成	结合 Jenkins 等工具，缩短开发周期，提高软件质量

14. 流程图：基于 Apache Bigtop 的数据处理栈开发部署流程

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(开始):::process --> B(开发环境配置):::process
    B --> C(构建系统设置):::process
    C --> D(定义 BOM):::process
    D --> E(组件构建):::process
    E --> F(部署):::process
    F --> G{部署方式}:::process
    G -->|Bigtop 预配置器| H(使用预配置器部署):::process
    G -->|无主 Puppet 部署| I(使用 Puppet 部署):::process
    H --> J(集成验证):::process
    I --> J
    J --> K(持续集成):::process
    K --> L(结束):::process

这个流程图展示了基于 Apache Bigtop 进行数据处理栈开发和部署的主要步骤，从开发环境配置开始，经过构建、部署、验证，最后进入持续集成阶段，形成一个完整的开发流程。

通过以上内容，我们全面了解了基于 Apache Bigtop 的 Hadoop 数据处理栈的开发、部署、验证和持续集成过程，掌握了相关的技术和操作方法，能够更好地应对大数据领域的挑战。