目录

• • 1. 设计一个规模合适的集群
  • • 1.1. 资源预估
    • 1.2. 选择服务器
    • 1.3. 分配集群角色
  • 2. 部署和管理集群的工具
  • • 2.1. Hadoop 的发展历程
    • 2.2. 部署和管理 Hadoop 的集群并不简单
    • 2.3. 三种工具的部署方式
  • 3. 自动创建虚拟机
  • • 3.1. 什么是 Vagrant
    • 3.2. 安装 Vagrant 和概念介绍
    • 3.3. 使用 Vagrant 构建一个虚拟机集群
  • 4. 自动化部署服务 (了解, 运维领域)
  • • 4.1. 痛点和 Ansible
    • 4.2. 使用 Vagrant 整合 Ansible
    • 4.3. 使用 Ansible 部署 CM
    • 4.4. 已知问题
    • • 可以解决的问题
      • 无法解决的问题

---

1. 设计一个规模合适的集群

• 目标
  • 给定需求和数据规模, 能够设计一个合适的集群
• 步骤
  1. 资源预估
  2. 选择服务器
  3. 为服务器选择服务(角色)

1.1. 资源预估

明确需求

需求点	量
标签数量	150个
标签计算任务数量	150个
数据抽取相关任务数量	10个
最少支持并发任务数量	5个
日数据增量	260G

如果一个Spark任务需要计算260G的数据, 需要260G的内存吗?

1. 给出一段 Spark 代码

rdd1 = sc.readTextFile(...)
rdd2 = rdd1.map(...)
rdd3 = rdd2.flatMap(...)

2. 分析执行策略, 简化的逻辑如下

rdd3 = rdd2.flatMap(...)
rdd3 = rdd1.map(...).flatMap(...)
rdd3 = sc.readTestFile(...).map(...).flatMap(...)

3. 按照这个逻辑, 没有必要把所有的数据都加载出来, 再逐个数据集去计算

得出结论, 如果计算 260G 的数据, 可能和计算 60G 的数据, 所需要的内存一样, Spark 会逐个取数据, 逐个计算, 计算完成后抛弃, 再取下一条

真的是这样吗? 再看一段代码

1. 给出一段Spark代码, 这段代码多了一个Shuffle算子

rdd1 = sc.readTextFile()
rdd2 = rdd1.map(...)
rdd3 = rdd2.flatMap(...)
rdd4 = rdd3.reduceByKey(...)

2. 分析执行过程

rdd4 = sc.readTestFile(...).map(...).flatMap(...).reduceByKey(...)

3. flatMap 出去的数据可能要汇总一下, 才能流入 reduceByKey

得出结论, 如果计算 260G 的数据, 和计算 60G 的数据, 所需要的内存确实不一样, 有 Shuffle 的情况下要稍微多一些才行

那么, 如何设计集群规模?

1. Spark 这样启动

spark-submit \
  --class org.apache.spark.examples.SparkPi \
  --master yarn \
  --deploy-mode cluster \
  --executor-memory 16G \
  --executor-cores 4 \
  --executor-num 10 \
  --total-executor-cores 100 \
  http://path/to/examples.jar \
  1000

2. executor-memory, executor-cores, executor-num 设置的原则
   1. executor-memory 是 executor-cores 的 2-4 倍, 取决于 Spark 任务是否有很多计算
   2. 通过 executor-num 来控制整个 Job 的内存占用

所以, 可以得到如下表格

点	量
Executor cores	4 cores
Executor num	10
Executor memory	16 G
Spark parallelism	128
Driver memory	6 G
Total cores	exenum * execores = 40
Total memory	exenum * exemem = 160
Pre job needs	40 core + 160 G
Cluster	(40, 160) * 5 * 1.2 = (240,1080) = 240 核心, 1080 G 内存

1.2. 选择服务器

假设公司很有钱, 选择在京东上买新的 Dell 服务器, 选择了一个比较好的机器如下

配置如下

类型	型号	容量	数量
CPU	Intel 至强 E5-2690V4	14 cores	2颗
内存	Dell ECC DDR4	32 G	4条(可扩展至24条)
硬盘	Dell SAS 3.5英寸	4 TB	3块(可扩展至8块)

所以, 单台服务器可以有 128G 内存, 28 cores, 那我们需要的集群数量如下

类型	数量
Master	3
Worker	10
Edge	2 (可 1U 低配)

这样的话, 我们集群的总资源量就如下, 可以看到, 已经非常够用了

类型	大小
CPU	280 cores
内存	1280 G
硬盘	120 T

1.3. 分配集群角色

按照如下方式分配是比较推荐的, 而且一般生产级别的大数据集群, 一定是要 HA 的

	Master 1-2	Master 3	Work 1-10	Gateway	Utility 1
NameNode	✔️
JournalNode	✔️	✔️
FailoverController	✔️
ResourceManager	✔️
HMaster	✔️	✔️
Zookeeper	✔️	✔️
JobHistory		✔️
SparkHistory		✔️
DataNode			✔️
NodeManager			✔️
HRegionsServer			✔️
Hue				✔️
Oozie				✔️
HiveServer2				✔️
Flume				✔️
用户画像系统				✔️
ClouderaManager					✔️
ManagementService					✔️
HiveMetastore					✔️

2. 部署和管理集群的工具

• 目标
  • 理解 Hadoop 发型版的历史和作用
• 步骤
  1. Hadoop 的发展历程
  2. 部署和管理 Hadoop 集群并不简单
  3. 三种工具的部署方式

2.1. Hadoop 的发展历程

1. 阶段一: 三篇论文
   1. GFS, 2003, 存储大量数据
   2. MapReduce, 2004, 使得大量数据可以被计算
   3. BigTable, 2006, 使得大量数据可以被及时访问
2. 阶段二: Hadoop
   1. DougCutting 在 2002 年创业做了 Lucene, 遇到了性能问题, 无法索引全网的数据
   2. Google 发布了 GFS 以后, DougCutting 把 Lucene 的底层实现改为类似 GFS 的形式
   3. 2006 年 DougCutting 投靠了 Yahoo!, 带去了 Lucene, 抽出底层的存储和计算, 变为子项目 Hadoop
   4. 从 2006 年开始, Yahoo! 把多个业务迁移到 Hadoop 中, 这个时代 Hadoop 才进入高速发展期

所以, Hadoop 是 Yahoo! 一个半内部的项目, 不是商业产品, 其部署和运维都需要专业的团队

2.2. 部署和管理 Hadoop 的集群并不简单

想要部署和运维 Hadoop 的集群有一些难点如下

1. Hadoop 是一个大规模的分布式工具, 想要在 4000 个节点上安装无疑非常困难
2. 而想要保证几千个节点上的 Hadoop 都正常运行, 无疑更加困难

所以, 第一个发现这个问题的人并不是我们, 而是 Cloudera 的老板

1. 2008 年的时候, 一个 Google 的工程师负责和另外一家公司一起合作搞项目, 在部署 Hadoop 的时候, 发现这玩意太难部署了, 于是出来创业, 创办了 Cloudera
2. 2011 年的时候, 原 Yahoo! 的 Hadoop 团队独立出来, 创办了一家公司, 叫做 Hortonworks

而 Hortonworks 和 Cloudera 所负责的事情大致如下

1. 帮助社区改进 Hadoop 和周边工具, 并提供发行版, 类似于 RedHat 和 Linux 的关系
2. 帮助客户部署 Hadoop 集群
3. 提供工具帮助客户管理 Hadoop 集群

但是他们的产品又是不同的, 如下

• Hortonworks
  • Ambari, 集群管理和监控
  • HDP, Hadoop 发行版
• Cloudera
  • Cloudera Manager, 简称 CM, 集群管理和监控
  • CDH, Hadoop 发行版

所以, 现在如果想要部署一个 Hadoop 的集群, 我们大致有三种选择

• 直接部署 Hadoop 开源版本, 简称 Apache 版本
• 部署 HDP 和 Ambari
• 部署 CDH 和 CM

2.3. 三种工具的部署方式

一 : 想要部署 Apache 版本的工具是最难的

• 要为所有节点配置环境, 例如关闭防火墙之类的

• 要在所有节点中安装 Hadoop, Hive, HBase, Spark 等

二 : 想要部署 CDH 集群, 其实也并不容易, 因为 CM 是主从结构的, 分为如下两个部分

• Cloudera Manager Server, 简称 SCM
• Cloudera Manager Agents, 简称 SCM Agents

所以, 我们需要做如下这件事

• 要为所有节点配置环境, 例如关闭防火墙之类的
• 要为所有节点安装 Agents
• 要在主节点安装 SCM
• 访问 SCM 部署 CDH 集群

三 : 想要部署 HDP 的集群, 理论上比 CM 更难一些

• 要为所有节点配置环境, 例如关闭防火墙之类的
• 要为所有节点安装 Ambari Agents
• 要在主节点安装 Ambari Server
• 访问 Ambari Server 建立集群

四 : 大家有没有发现, 这三种部署方式都有一个事情要做

• 在所有节点执行 xxx 命令

想象一下, 4000 个节点, 你准备怎么处理?

• 使用自动化运维工具, 自动的在所有节点执行相同的操作

例如, 在 4000 个节点中执行同样的 Shell 脚本, 无论怎么做, 其实都挺折腾的, 不是吗?

五 : 那为什么我们不能直接使用 Apache 版本的工具, 使用 Shell 脚本去安装呢?

• 集群部署出来以后, 可能会出错, 如何运维
• 集群部署出来以后, 可能配置文件要修改, 难道再在所有节点修改一遍吗?
• 集群部署出来以后, 我不知道它出错没, 需要监控

而上述这些功能, Ambari 和 SCM 都提供了, 所以我们当时的生产环境中, 运行的是 Cloudera Manager

3. 自动创建虚拟机

• 目标
  • 能够通过自动化的方式创建虚拟机
• 步骤
  1. 什么是 Vagrant
  2. 安装 Vagrant 和概念介绍
  3. 使用 Vagrant 构建一个虚拟机集群

3.1. 什么是 Vagrant

从现在就开始要搭建一个测试集群了, 回顾前面的课程, 先来说说虚拟机的痛点

• 安装麻烦
  • 建立虚拟机的时候, 我的网段好像写错了, 和别人的 IP 不一样, 总是操作失误
  • 虚拟机弄好以后, 还需要安装操作系统, 步骤那么多, 怎么可能不出错呢, 老师你肯定没讲清楚
  • WC, 虚拟机终于装好了!! 什么? 还需要安装 Hadoop, 几十个步骤!!!
• 工程和环境分离
  • 唉, 又要学习新项目了, 又要折腾环境, 算了, 请一天假放松放松
• 分发困难
  • 为啥老师发给我的虚拟机我运行不起来? 这是为什么!!!
  • 可能因为你和老师的环境不同. 什么!? 又是环境不同!!!

卒