首页
学习
活动
专区
圈层
工具
发布
50 篇文章
1
客快物流大数据项目(一):物流项目介绍和内容大纲
2
客快物流大数据项目(二):物流项目详细介绍
3
客快物流大数据项目(三):项目解决方案
4
客快物流大数据项目(四):大数据项目为什么使用Docker
5
客快物流大数据项目(五):Docker介绍
6
客快物流大数据项目(六):Docker与虚拟机的形象比喻及组件介绍
7
客快物流大数据项目(七):Docker总结
8
客快物流大数据项目(八):Docker的安装和启动
9
客快物流大数据项目(九):Docker常用命令
10
客快物流大数据项目(十):Docker容器命令
11
客快物流大数据项目(十一):Docker应用部署
12
客快物流大数据项目(十二):Docker的迁移与备份
13
客快物流大数据项目(十三):Docker镜像
14
客快物流大数据项目(十四):DockerFile介绍与构建过程解析
15
客快物流大数据项目(十五):DockeFile常用命令
16
客快物流大数据项目(十六):使用脚本创建镜像
17
客快物流大数据项目(十七):自定义镜像mycentos
18
客快物流大数据项目(十九):项目环境准备
19
客快物流大数据项目(二十):物流管理系统服务器的数据路径配置和软件下载存放位置
20
客快物流大数据项目(二十一):Docker环境初始化
21
客快物流大数据项目(二十二):Docker环境中安装软件
22
客快物流大数据项目(二十三):OGG介绍
23
客快物流大数据项目(二十四):OGG安装部署
24
客快物流大数据项目(二十五):初始化业务数据
25
客快物流大数据项目(二十六):客户关系管理服务器
26
客快物流大数据项目(二十七):Cloudera Manager简单介绍
27
客快物流大数据项目(二十八):大数据服务器环境准备
28
客快物流大数据项目(二十九):下载CDH的安装包
29
客快物流大数据项目(三十):软件下载后存放位置
30
客快物流大数据项目(三十一):常用工具安装
31
客快物流大数据项目(三十二):安装CDH-6.2.1和初始化CDH服务所需的MySQL库
32
客快物流大数据项目(三十三):安装Server和Agent
33
客快物流大数据项目(三十四):CDH开始安装
34
客快物流大数据项目(三十五):CDH使用注意
35
客快物流大数据项目(三十六):安装ElasticSearch-7.6.1
36
客快物流大数据项目(三十七):安装Kinaba-7.6.1
37
客快物流大数据项目(三十八):安装Azkaban-3.71.0
38
客快物流大数据项目(三十九):Hue安装
39
客快物流大数据项目(四十):ETL实现方案
40
客快物流大数据项目(四十一):Kudu入门介绍
41
客快物流大数据项目(四十二):Java代码操作Kudu
42
客快物流大数据项目(四十三):kudu的分区方式
43
客快物流大数据项目(四十四):Spark操作Kudu创建表
44
客快物流大数据项目(四十五):Spark操作Kudu DML操作
45
客快物流大数据项目(四十六):Spark操作Kudu dataFrame操作kudu
46
客快物流大数据项目(四十七):Spark操作Kudu Native RDD
47
客快物流大数据项目(四十八):Spark操作Kudu 修改表
48
客快物流大数据项目(四十九):开发环境初始化
49
客快物流大数据项目(五十):项目框架初始化
50
客快物流大数据项目(五十一):数据库表分析

客快物流大数据项目(四):大数据项目为什么使用Docker

目录

大数据项目为什么使用Docker

一、场景一

二、场景二

三、场景三


大数据项目为什么使用Docker

随着大数据平台型产品方向的深入应用实践和Docker开源社区的逐渐成熟,业界有不少的大数据研发团队开始使用Docker。简单来说,Docker会让大数据平台部署更加简单快捷、让研发和测试团队集成交付更加敏捷高效、让产线环境的运维更加有质量保障

一、场景一

在大数据平台型产品的开发过程中,经常要跟许多模块打交道,包括Hadoop、HBase、Hive、Spark、Sqoop、Zookeeper……等多达几十个开源组件,为了不影响团队成员间的工作任务协同,开发人员其实非常需要自己有一套独立的集群环境,以便反复测试自己负责的模块,可真实的企业开发环境往往只有一两个大的虚拟集群,这可怎么办?

难道要给每个开发人员都配几台独立的物理机器?

二、场景二

针对每一次新版本的发布,产品测试组都需要反复的重装整个平台以便发现问题,而正如本文前面所阐述的那样,大数据平台所依赖的组件繁多,不同组件模块依赖的底层库也不尽相同,经常会出现各种依赖冲突问题,而一旦安装完成,就很难再让Linux系统恢复到一个非常干净的状态,通过Remove、UnInstall、rpm -e等手动方式卸载,往往需要花费很长的时间,那如何才能快速地恢复大数据平台集群的系统环境?

三、场景三

当测试人员在测试大数据平台过程中发现了一个BUG,需要保存现场,这里面包括相关的大数据组件配置、进程状态、运行日志、还有一些中间数据,可是,平台集群服务器节点数量很多,针对每个进程的配置目录和日志文件,都相对较独立,一般都需要专业的开发工程师或者运维工程师进入相关服务器节点,按照不同组件的个性化配置信息,手工方式收集所需的各个条目信息,然后打包汇集到日志中心服务器进行统一分析,而目前业界并没有一款能够自动分布式收集故障相关的日志系统,但测试工作还要继续,怎么办?

传统解决方案的缺陷

想要解决这些问题,第一个想到的方案当然是用虚拟机,但这种方式并不能完美的解决以上问题,比如:

  • 虽然虚拟机也可以完成系统环境的迁移,但这并不是它所擅长的,不够灵活,很笨重。
  • 虚拟机的快照可以保存当前的状态,但要恢复回去,就得把当前正在运行的虚拟机关闭,所以并不适合频繁保存当前状态的业务场景。
  • 虽然可以给每个人都分配几个虚拟机用,但它是一个完整的系统,本身需要较多的资源,底层物理机的资源很快就被用完了,所以我们需要寻找其它方式来弥补这些不足。
下一篇
举报
领券