TT Bigdata TT Bigdata
首页
GitHub (opens new window)
JaneTTR

JaneTTR

数据酿造智慧,每一滴都是沉淀!
  • Ambari 深度专题

  • Bigtop 方法论

  • 自定义集成

  • Ambari Server 与 Web

  • Ambari Metrics

  • Ambari Plus 思考

  • Redis集成实战

    • Bigtop通用部分

      • Step0-源码获取
      • Step1-构建规范的bom
        • 一、BOM 到底是什么?工程环境里的“包管家”
          • 1.1 BOM 的本质和作用
          • 为什么 BOM 很关键?
          • 1.2 BOM 在实际集成中的流程地位
        • 二、实际工作流与 dl 目录机制:包是如何被识别和缓存的?
          • 2.1 典型的自动化拉包流程
        • 三、bigtop.bom 配置字段全解读与最佳实践
          • 3.1 一个 Redis 组件的 BOM 配置实例
          • 3.2 字段说明表
          • 3.3 下载链接实际拼接逻辑
      • Step2-Redis源代码编译
      • Step3-源代码编译脚本构造
      • Step9-版本适配器
    • Bigtop打包部分

    • Ambari部分

  • 通用代码模板

  • 各组件代码

  • 技术专题
  • Redis集成实战
  • Bigtop通用部分
JaneTTR
2025-06-24
目录
一、BOM 到底是什么?工程环境里的“包管家”
1.1 BOM 的本质和作用
为什么 BOM 很关键?
1.2 BOM 在实际集成中的流程地位
二、实际工作流与 dl 目录机制:包是如何被识别和缓存的?
2.1 典型的自动化拉包流程
三、bigtop.bom 配置字段全解读与最佳实践
3.1 一个 Redis 组件的 BOM 配置实例
3.2 字段说明表
3.3 下载链接实际拼接逻辑

Step1-构建规范的bom

在上一节结尾,我们讲到了源码包下载的地址和流程。但在实际的 Bigtop 企业集成环境里,光有下载地址远远不够。你肯定会好奇:

“Bigtop 是怎么知道要下哪个包,放哪,怎么自动识别的?”

“为什么一条 gradle 命令就能完成源码自动识别和下载,甚至还能复用 dl 目录里的老包?”

其实,所有这些自动化“魔法”的背后,核心就是 bigtop.bom 文件。

# 一、BOM 到底是什么?工程环境里的“包管家”

# 1.1 BOM 的本质和作用

# 为什么 BOM 很关键?

  • 全局唯一管理: 一个大数据项目动辄几十上百个组件,只靠手工维护几乎不可能,必须集中在 BOM 配置里统一管理。
  • 自动适配各种下载/缓存场景: 支持本地提前下载、线上代理、源站自动归档等各种复杂场景。
  • 企业/团队协作: 多人同时维护,BOM 结构越规范越能避免“路径乱、包名错、自动化脚本跑崩”等工程惨剧。

# 1.2 BOM 在实际集成中的流程地位

  • 每个组件(比如 redis)都有一个单独的 BOM 配置段
  • gradle 构建时会优先从 BOM 里查找所有参数(版本、包名、路径、URL)
  • BOM 决定了源码包从哪里下载、解压后叫什么名字、dl 里如何缓存
  • 一旦 BOM 出错,后续自动化一律失败!这也是实际大数据编译环境中最常见、最头疼的踩坑点之一

# 二、实际工作流与 dl 目录机制:包是如何被识别和缓存的?

# 2.1 典型的自动化拉包流程

  1. 发起编译命令 比如你执行(以hudi为例):

    gradle hudi-rpm -PparentDir=/usr/bigtop -Dbuildwithdeps=true -PpkgSuffix -d
    
    1
  2. 系统自动检查 dl 目录 先在 $BIGTOP_HOME/dl/ 目录下寻找目标源码包。 下载动作 图:Bigtop会优先查找本地dl缓存,如果没有才去远程下载。

  3. 没有就触发远程下载 如果本地没有,就会用 BOM 里定义的下载链接,自动 wget/curl 下来。 Hudi源码包 图:下载成功后,包自动进入 dl 目录,下次可直接复用。

  4. 解压与命名归档 dl 目录的包名和 BOM 配置的 destination 必须严格一致,否则自动解压和后续编译全都会报错。

实践建议

提前把所有历史版本/大版本的源码包下好,放入 dl 目录,能极大减少构建等待时间,提高稳定性,适合企业内网和批量编译。

# 三、bigtop.bom 配置字段全解读与最佳实践

# 3.1 一个 Redis 组件的 BOM 配置实例

'redis' {
    name = 'redis'
    rpm_pkg_suffix = "_" + bigtop.base_version.replace(".", "_")
    relNotes = 'Redis v7.4.0 Release'
    version { base = '7.4.0'; pkg = base; release = 1 }
    tarball {
        destination = "${version.base}.tar.gz"
        source = destination
    }
    url {
        site = bigtop.gh_proxy + "https://github.com/redis/redis/archive/refs/tags/"
        archive = site
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 3.2 字段说明表

字段 解释及实际含义
name 组件名(比如 redis)
rpm_pkg_suffix 包名后缀,用于自动区分不同 bigtop 版本环境
relNotes 备注,通常写版本/发布说明
version.base 主版本号(比如 7.4.0)
version.pkg 包名简写
version.release 构建次数或小版本
tarball.destination dl 目录下保存包的文件名,和下载包保持一致
tarball.source 实际用于下载的包名,通常和 destination 一致
url.site 下载包的主站路径(可拼接代理加速前缀)
url.archive archive地址,一般和 site 保持一致

典型工程经验

  • tarball.destination 一定要和官方包名一致,否则自动解压识别不到
  • site 字段可以加 bigtop.gh_proxy 前缀,解决国内下载慢/限流等问题
  • 如果有 patch 或二次开发包,可以在 source/destination 自定义子路径,便于版本区分

# 3.3 下载链接实际拼接逻辑

以 Redis v7.4.4 为例:

  • site = bigtop.gh_proxy + "https://github.com/redis/redis/archive/refs/tags/"

  • tarball.source = 7.4.4.tar.gz

  • 最终下载链接:

    https://github.com/redis/redis/archive/refs/tags/7.4.4.tar.gz
    
    1
  • 下载包自动保存为:dl/7.4.4.tar.gz

#Redis#Stack集成#集成案例#Bigtop#源码编译
Step0-源码获取
Step2-Redis源代码编译

← Step0-源码获取 Step2-Redis源代码编译→

最近更新
01
当前版本 2026/08
08-29
02
把 Ambari Server HA 稳稳地跑起来
08-17
03
从一次启用操作追到主备就绪
08-17
更多文章>
Theme by Vdoing | Copyright © 2017-2026 JaneTTR | MIT License
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式