1.搭建测试环境

工欲善其事，必先利其器。为了顺利完成本次实验，请确保你的本地开发环境已安装Docker和Git。

由于是测试环境，我们选择All-in-One的部署模式，单个 Docker 容器，捆绑了所有 ClickStack 组件，用于演示和局部全栈测试。

这个综合的 Docker 镜像捆绑了所有 ClickStack 组件：

• ClickHouse
• HyperDX
• OpenTelemetry (OTel) 收集器（在端口 4317 和 4318 上暴露 OTLP）

此选项包含身份验证，允许在会话和用户之间持久保存仪表板、警报和保存的搜索。

1.1.使用Docker部署

以下命令将运行一个 OpenTelemetry 收集器（在端口 4317 和 4318 上）和 HyperDX 界面（在端口 8080 上）。

1

docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 docker.hyperdx.io/hyperdx/hyperdx-all-in-one

部署成功后会打印环境信息

1.2.访问HyperDX界面

访问 http://localhost:8080 以访问 HyperDX 界面。

创建一个用户，提供符合要求的用户名和密码。

点击 Create 后，将为集成的 ClickHouse 实例创建数据源。

随后会进入到HyperDX的主界面，此时并没有数据

2.导入示例日志、trace和指标

2.1.配置数据源

All-in-One部署模式中已经部署了Clickhouse，直接配置connection本地Clickhouse

2.2.复制摄取API KEY

导航到 团队设置 并从 API 密钥 部分复制 摄取 API 密钥。此 API 密钥确保通过 OpenTelemetry 收集器进行数据摄取的安全性。

2.3.准备并导入样例数据

1

# wget https://storage.googleapis.com/hyperdx/sample.tar.gz

此文件包含来自我们公共 OpenTelemetry 演示 的示例日志、指标和跟踪——一个简单的微服务电子商务商店。将此文件复制到您选择的目录中。

上面API 密钥导入环境变量，并将数据发送到 OTel 收集器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# export API key
export CLICKSTACK_API_KEY=<YOUR_INGESTION_API_KEY>

#
for filename in $(tar -tf sample.tar.gz); do
  endpoint="http://localhost:4318/v1/${filename%.json}"
  echo "loading ${filename%.json}"
  tar -xOf sample.tar.gz "$filename" | while read -r line; do
    echo "$line" | curl -s -o /dev/null -X POST "$endpoint" \
    -H "Content-Type: application/json" \
    -H "authorization: ${CLICKSTACK_API_KEY}" \
    --data-binary @-
  done
done

这模拟了 OLTP 日志、跟踪和指标源将数据发送到 OTel 收集器。在生产环境中，这些源可能是语言客户端，甚至是其他 OTel 收集器。

3.观测日志、trace及指标

3.1.观测日志

在Search视图，默认已经可以观测到日志记录

HyperDX允许您对事件（日志和跟踪）进行全文搜索。您可以通过输入与您的事件匹配的关键字来开始搜索。例如，如果您的日志包含“Error”，您只需在搜索框中输入“Error”即可找到它。

3.2.诊断trace

在trace界面，可以查看完整的分布式跟踪，并诊断问题错误来源

3.3.观测指标

有些时候，我们需要更直观的观测全局错误指标。可以选择相应的指标作为数据源，完成图表构建器以绘制 visa_validation_cache.size (Gauge) 的 最大值 并按播放按钮。缓存显然在达到最大大小之前不断增加，之后生成了错误。

1.我们的可观测性平台做对了吗

作为工程师，我们每天都在与系统的复杂性搏斗。而可观测性平台，本应是我们在黑暗中探索的明灯。但现实往往是，这盏“灯”本身就价格不菲，还时常忽明忽暗。

你是否也面临着这些似曾相识的场景？

• 高昂的账单： 每月审视商业 SaaS 服务的账单，感觉每一行日志、每一个指标都在燃烧经费。
• 运维的泥潭： 维护着一套由 ELK、Prometheus、Jaeger 等“攒”起来的系统，不同组件的升级、扩容和协调，消耗了大量精力。
• 低效的排障： 发现问题时，不得不在 Grafana、Kibana、Jaeger UI 之间来回跳转，复制粘贴 TraceID，宝贵的排障时间就在这无尽的“上下文切换”中流逝。

这些挑战背后，指向了行业的一个核心痛点：我们长期在“功能完备性”与“总拥有成本 (TCO)”之间做着艰难的权衡。

有没有一种架构，能够打破这种两难困境？ClickStack 尝试给出它的答案。

2.架构解析：ClickStack 为何选择 ClickHouse + OTel？

ClickStack 以 ClickHouse 为统一存储引擎，原生集成 OpenTelemetry 标准，旨在从根本上解决日志、追踪、指标三大数据的孤岛问题。

ClickStack 的架构设计非常清晰，它将宝押在了两项关键技术上：ClickHouse 作为统一存储，OpenTelemetry 作为标准入口。

这个选择并非偶然，而是深思熟虑的结果。

OpenTelemetry Collector：拥抱标准，面向未来

作为数据入口，OTel Collector 提供了无与伦比的开放性和兼容性。它意味着你的可观测性体系从第一天起就“不站队”，避免了被特定厂商锁定的风险。这是一个着眼于未来的战略选择。

ClickHouse：性能与成本的最佳平衡点

这才是 ClickStack 架构的真正王牌。为什么是 ClickHouse？因为它几乎是为可观测性这类海量数据分析场景量身定做的。

它采用列式存储 (Columnar Storage)。 简单来说，就是把同一列的数据（比如所有请求的 status_code）存在一起。这种存储方式带来了两大革命性优势：

• 极高的压缩比： 数据类型单一，压缩算法能发挥到极致。反映在成本上，就是你的存储开销可能会轻松降低 50%-80%。
• 闪电般的查询速度： 当你只关心某几列数据时（这在分析场景中非常常见），数据库无需读取整行，查询性能得到指数级提升。

HyperDX 前端：终结“多屏协同”的割裂感

统一的存储，自然需要统一的交互界面。为了提供现代化的用户体验，ClickStack 的前端 fork 并改进自优秀的开源项目 HyperDX。它将原本分散在不同工具中的查询和分析能力整合到了一处，让数据之间的关联变得自然而高效。

3.核心优势剖析：ClickStack 究竟能带来什么？

那么，这个架构到底能给我们的日常工作带来什么实际好处？

核心在于，它将可观测性的关注点，从“如何采集和存储”，拉回到了“如何高效地使用”上。

1. 显著的成本效益: 这是最直接的价值。更低的存储占用和简化的运维架构，意味着更低的总拥有成本 (TCO)。对于预算敏感的团队，这足以成为选择它的决定性理由。

2. 流畅的开发体验: 想象一下，在一个基于 HyperDX 的界面中，你看到某个服务 P99 延迟指标突然飙高，直接点击就能下钻到对应的分布式追踪列表；在最慢的一条 Trace 中，又能一键查看当时系统打印出的相关日志。这种无缝的分析体验，将极大缩短故障定位时间（MTTR）。

3. 架构的自由与主动权: 建立在开放标准之上，意味着你的技术栈拥有了更高的灵活性。你可以随时引入其他兼容 OTel 的工具，而不用担心被平台“绑架”。

4.横向评估：ClickStack 在生态中的坐标

当然，没有完美的技术方案，只有最合适的选择。我们将 ClickStack 放置于当前主流方案的坐标系中，可以更清晰地看到它的位置。

分析结论：
ClickStack 并非要取代谁，而是提供了一种全新的、极具吸引力的“第三条道路”。它精准地切入了商业 SaaS 的“价格敏感区”和传统开源组合的“运维复杂区”，为市场提供了宝贵的差异化选择。

五、结论：谁应该认真考虑 ClickStack？
经过全面的分析，我们可以得出结论：ClickStack 是一个定位清晰、架构先进且极具潜力的开源可观测性解决方案。

如果你和你的团队符合以下画像，那么强烈建议你将其纳入技术雷达：

• 务实的成本控制者： 你正在积极寻求降低可观测性平台的总体拥有成本，希望将每一分钱都花在刀刃上。

• 高效的系统建设者： 你希望构建一个技术栈统一、数据无缝关联的私有化平台，并愿意为此投入一定的运维精力。

• 开放的架构拥抱者： 你坚信开放标准的力量，希望构建一个不被任何厂商锁定、面向未来的技术基础设施。

诚然，作为一个发展中的项目，ClickStack 在某些高级功能（如 AIOps）和商业生态上尚需时日。但它已经用一种优雅而高效的方式，解决了可观测性领域最核心的成本与效率问题。

对于许多团队而言，这或许已经足够。

项目地址: https://github.com/clickvisual/clickstack

1.CPU sys 上涨背景

线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%，较为抢眼，系统相关服务却并无异常，令人有些困惑。

这个问题其实并不难解释，先说结论，因为kafka数据操作会优先在PageCache中进行，导致读写磁盘数据时是系统内核线程去操作而非用户应用层面，所以单机数据读写压力上涨后，系统内核线程的繁忙就表现为cpu sys上涨，甚至比cpu user使用还来的明显。

今天就借此和大家探讨下，kafka高吞吐性能的核心之一—PageCache。

2.kafka 消息存储

kafka的存储设计和一般的存储设计理念也差不多，都是分缓存，持久化层，缓存数据尽量放内存，持久化数据就会考虑多副本且落盘。一般的应用引擎设计都会考虑自己来实现缓存及写盘这一套逻辑，kafka的不同之处在于他并没有自己在内存中创建缓冲区，然后再实现向磁盘write的一系列方法，而是直接站在巨人们的肩膀上，使用了系统层面的PageCache。

基于Linux开源社区一众贡献者的多年打磨迭代，Linux的文件系统早已在PageCache做了大量的优化和填坑，且还会持续优化，这无异于为kafka的缓存模块提供的强大助力。

直接使用内核系统的PageCache:

• 减少内存开销： Java对象的内存开销（overhead）非常大，往往是对象中存储的数据所占内存的两倍以上
• 规避 GC 问题：JVM中的内存垃圾回收已经是多年诟病的问题了，随着堆内数据不断增长而变得越来越不明确，回收所花费的代价也会越来越大
• 简单可靠：内核系统会调用所有的空闲的内存作为PageCache，并在其上做了大量的优化：预读，后写，flush管理等，这些都不再需要应用层操心，全部有系统接管完成

3.kafka 数据读写

3.1.读写接力

Linux系统会把还没应用程序申请走的内存挪给PageCache使用，此时，当写入数据时，会先写入PageCache中，并标记为dirty。读取数据时，会先再PageCache中查询，如果有就快速返回，没有才会去磁盘读取回写到PageCache中。

因此，一般情况，只要生产和消费速率相差不是很远，数据读写都会发生在PageCache中，没有磁盘操作。这比起自己在内存中再维护一份消息数据提供读写，既不会浪费内存，又不用考虑GC，即便kafka应用重启了，数据也还在PageCache中，可以快速读取恢复。

3.2.异步 flush 数据落盘

由于kafka调用的是系统的PageCache，所以这里讲的kafka数据flush其实就是Linux内核的后台异步flush。

内核线程pdflush负责将有dirty标记的内存页，发送给 IO 调度层。内核会为每个磁盘起一条pdflush线程，每 5 秒（/proc/sys/vm/dirty_writeback_centisecs）唤醒一次，主要由以下面三个参数来调整：

• /proc/sys/vm/dirty_expire_centisecs：默认值 30s，page dirty的时间超过这个值，就会刷盘，所以即使意外OS crash，理论最多也就丢这 30s 的数据
• /proc/sys/vm/dirty_background_ratio：默认值 10%，如果dirty page的总大小超过了可用内存的 10%(即/proc/meminfo 里 MemFree + Cached - Mapped)，则会在后台启动pdflush线程刷盘，这个值是个比较重要的调优参数。
• /proc/sys/vm/dirty_ratio：默认值 30%，如果写入数据过快，超过了pdflush的速率，此时dirty page会迅速积压，当超过可用内存的 30%，则此时所有应用的写操作都会被block，各自去执行flush，因为操作系统认为现在已经来不及写盘了，如果crash会丢过多的数据，会阻塞住不再接纳更多的数据。我们要尽量避免这种情况的发生，长时间的写入阻塞，很容易带来一系列的雪崩问题。在 Redis2.8 以前，Rewrite AOF 就经常导致这个大面积阻塞问题。

3.3.Page Cache 清理策略

当写入的数据逐渐增多，直到内存满了，此时就需要考虑把应用占用的内存数据挪到swap区去，或者开始清理PageCache了。一般来说，我们会通过调整/proc/sys/vm/swappiness的值为 0，来尽量不使用swap。剩下的就来看看PageCache是如何清理的了。

Page Cache的清理策略是改良版的LRU。如果直接用LRU，一些新读取但只用一次的冷数据会占满了LRU的头部。因此将原来一条LRU的队列拆成了两条，一条放新数据，一条放已经访问过好几次的热数据。刚访问的数据放在新LRU队列里，多次访问命中后会升级到旧LRU队列的热数据队列。清理时会从新LRU队列的尾部开始清理，直到清理出足够的内存。

Linux通过配置/proc/sys/vm/min_free_kbytes的值，来优化系统开始回收内存的阈值。

3.4.预读策略

根据清理策略，当消费太慢，堆积的数据过多直到Page Cache被清理掉了，此时就需要读盘了。

系统内核针对这个问题，会有个预读策略，每次读取请求都会尝试预读更多的数据。

• 首次预读：readahead*size = read_size * 2 or _ 4，首次预读窗口会是读大小的 2~4 倍，可以提升 IO 效率
• 后续预读：readahead_size *= 2 ，后续预读会逐渐倍增，直到达到最大预读大小

这也是为什么有时候，我们会觉得应用有个”热身状态”，刚开始卡一下后，运行的越来越快，这其中预读策略就起到了一定的 IO 优化效果。

消费组应该算是kafka中一个比较有特色的设计模式了，而他的重平衡机制也是我们在实际生产使用中，无法避免的一个问题。

消费组

Consumer Group为kafka提供了可扩展、高容错特性的消费者机制。简单介绍下，大致有以下特点：

• 一个Consumer Group内可以有多个Consumer实例，该实例可以是一个进程，也可以是进程下的多线程
• 每个Consumer Group有一个唯一标识的Group ID
• 不同Consumer Group之间相互独立，互不影响
• Consumer Group内实例，与订阅的topic分区关系是一对一，或一对多的关系，Consumer Group会通过Coordinator尽量保持公平分配

理想情况下，我们应该设置Consumer实例的数量等于该Group订阅topic的分区总数，可以最大发挥消费性能。若设置的Consumer实例数少于订阅的分区数，则会为每个Consumer实例分配多个分区，消费性能会有所下降。若设置的Consumer实例数大于订阅的分区数，则会为每个Consumer实例分配 1 个分区进行消费，多余的Consumer实例则会闲置，只会浪费资源。

重平衡

重平衡（Rebalance）就是让一个Consumer Group下所有的Consumer实例,合理分配消费订阅topic的所有分区的过程。有 3 种情况会触发Consumer Group的Rebalance：

1. Group下实例数发生变化。有新的Consumer实例加入或者离开组。
2. 订阅的topic数发生变化。Consumer Group可以使用正则的方式订阅topic，比如 consumer.subscribe(Pattern.compile(“public.*log”))，该Group订阅所有以 public 开头，log 结尾的topic。这期间，新建了一个满足这样条件的topic，那么该Group也会发生Rebalance。
3. topic分区数发生变化。比如topic扩分区的时候，也会触发Rebalance。

单看上面任一触发条件，都没啥毛病。问题在于Rebalance过程中会出现以下问题：

• Rebalance过程的表现有些类似JVM FGC的情况，期间整个应用都会夯住，所有Consumer实例都会停止消费，等待Rebalance完成。
• Rebalance过程中，所有Consumer实例都会参与重新分配。即便Consumer Group中部分Consumer实例分配合理，也需要打散重新分配，会导致TCP重新建立连接，是一个比较重的操作，较为浪费资源。
• Rebalance的耗时取决于Consumer Group下的实例数量，一旦实例数过多，耗时极长，会造成大量消费延迟。

避免重平衡

对于上述Rebalance带来的一些弊端，从目前的社区版来看，暂时还没有很好的解决办法，我们只能尽量避免Rebalance的发生。
在生产业务场景中，很多Rebalance都是预期外或者不必要的。我们应用的TPS大多是被这类Rebalance拖慢的。

从上述的 3 个Rebalance触发条件抓手，后两条topic数量及分区数变化，一般都是主动运维的相关操作，这种操作带来的Rebalance一般是必然发生，难以避免的，我们组要来讨论下Consumer Group组成员变化引发的Rebalance。

Consumer Group实例增加的情况比较单一，当新启动一个Consumer的group.id已经存在，Coordinator会接管这个新实例，将其加入group.id相同的组，并重分配分区。这种操作场景，一般都还是预期内的，可能是通过扩容来提高TPS的操作。
Consumer Group实例数减少的情况就比较复杂了。除了正常停止下线某些Consumer实例，还会出现Coordinator误判实例为已停止状态，从而主动踢出Group。导致Rebalance发生。每个Consumer会定期向Coordinator发心跳包，保持keepalive。如果因为某些特殊原因，如网络抖动时，某个Consumer实例没有及时发送心跳请求，Coordinator会将其判定为离线，并从Group中移除，并开启新一轮Rebalance。针对这个问题，可以通过设置Consumer端一下几个参数来进行优化调整：

• session.timeout.ms
  即Consumer Group内实例的心跳超时时间，默认值是 10s
• heartbeat.interval.ms
  即心跳请求频率，频繁发送心跳请求会额外消耗带宽资源，但是能够更及时的触发Rebalance，默认值为 3s
• max.poll.interval.ms
  调用poll方法的时间间隔，默认值为 5min。期间没消费完poll回的消息，Coordinator会开启新一轮Rebalance

根据平时的实践经验，建议:
session.timeout.ms=6s
heartbeat.interval.ms=2s
原则上最好是满足session.timeout.ms >= 3 * heartbeat.interval.ms公式。

max.poll.interval.ms则需要根据下游实际消费能力进行调整，尽量设置的大一点，需要大于下游的最大消息处理时间。

如果进行完上述的各种调整后，还是频发触发Rebalance，最好再去排查下Consumer端的 GC 情况，实际生产环境中我经常碰到因为 GC 设置问题导致的Consumer程序频发 FGC 的问题，从而导致非预期内的Rebalance。

消息组件对消息的可靠性保障，常见的模式有3种：

• 最多一次(at most once)：消息可能会丢失，但不会重复
• 至少一次(at least once)：消息不会丢失，但有可能重复
• 精确一次(exactly once)：消息不会丢失，且不会重复，精准一次发送

kafka默认情况下，提供的是至少一次的可靠性保障。即broker保障已提交的消息的发送，但是遇上某些意外情况，如：网络抖动，超时等问题，导致Producer没有收到broker返回的数据ack，则Producer会继续重试发送消息，从而导致消息重复发送。
相应的，如果我们禁止Producer的失败重试发送功能，消息要么写入成功，要么写入失败，但绝不会重复发送。这样就是最多一次的消息保障模式。
但对于消息组件，排除特殊业务场景，我们追求的一定是精确一次的消息保障模式。kafka通过幂等性（Idempotence）和事务（Transaction）的机制，提供了这种精确的消息保障。

幂等

这里就不多说幂等的含义了，不清楚的自己查下资料。Producer默认不是幂等性的，向分区发送数据时，可能会出现同一条消息被发送多次导致消息重复的情况。但只需增加一些参数，即可开启幂等性。

1
2
3

props.put(“enable.idempotence”, ture)
或者
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG， true)

开启enable.idempotence后，kafka就会自动帮你做好消息去重的一系列工作。底层具体实现原理很简单，就是用空间换时间的优化思路，即在broker端多存一些字段来标识数据的唯一性。当Producer发送了具有相同字段值的消息后，broker会进行匹配去重，丢弃重复的数据。实际的代码没这么简单，但大致是这么个处理逻辑。
官方的这个幂等实现看似简单高效，但也存在他的局限性。他只能保证单分区上的幂等性，即一个幂等性Producer只能够保证某个topic的一个分区上不出现重复消息，无法实现多分区的幂等。此外，如果Producer重启，也会导致幂等重置。

事务

对于多分区保证幂等的场景，则需要事务特性来处理了。kafka的事务跟我们常见数据库事务概念差不多，也是提供经典的ACID，即原子性（Atomicity）、一致性 (Consistency)、隔离性 (Isolation) 和持久性 (Durability)。
事务Producer保证消息写入分区的原子性，即这批消息要么全部写入成功，要么全失败。此外，Producer重启回来后，kafka依然保证它们发送消息的精确一次处理。
事务特性的配置也很简单：

• 和幂等Producer一样，开启enable.idempotence = true
• 设置Producer端参数transctional.id

事务Producer的代码稍微也有点不一样，需要调一些事务处理的API。数据的发送需要放在beginTransaction和commitTransaction之间。Consumer端的代码也需要加上isolation.level参数，用以处理事务提交的数据。示例代码:

1
2
3
4
5
6
7
8
9

producer.initTransactions();
try {
            producer.beginTransaction();
            producer.send(record1);
            producer.send(record2);
            producer.commitTransaction();
} catch (KafkaException e) {
            producer.abortTransaction();
}

事务Producer虽然在多分区的数据处理上保证了幂等，但是处理性能上相应的是会有一些下降的。

依赖redis实现幂等

这里为什么还要额外讲通过依赖redis来实现幂等呢？因为笔者在早期维护kafka相关应用时，那会0.8系列版本的kafka还没有这些自带的幂等事务特性，只能依靠开发者自己来实现。
常见的方式就是通过数据的业务属性来生成个uniqueId来维护到redis中，利用redis的高并发，高吞吐，分布式锁特性，让写入kafka多分区的数据前，先去redis中校验一下uniqueId等方式，来实现幂等。得益于redis的高性能，在保证幂等同时，还能不让消息数据吞吐性能下降太多。当然，因为redis的依赖引入，也增加了架构的复杂度，从运维上来说也增加了整体的故障点，其中取舍需要自己来全局判断。

这次大概先介绍了下kafka的幂等各种实现方式，实际在事务，和依赖redis分布式锁来实现幂等的方式中，还要许多点值得我们深究来聊一下的，篇幅所限，后续再细讲

那么kafka是如何保证消息不丢失的呢？

前提条件

任何消息组件不丢数据都是在特定场景下一定条件的，kafka要保证消息不丢，有两个核心条件。

第一，必须是已提交的消息，即committed message。kafka对于committed message的定义是，生产者提交消息到broker，并等到多个broker确认并返回给生产者已提交的确认信息。而这多个broker是由我们自己来定义的，可以选择只要有一个broker成功保存该消息就算是已提交，也可以是令所有broker都成功保存该消息才算是已提交。不论哪种情况，kafka只对已提交的消息做持久化保证。

第二，也就是最基本的条件，虽然kafka集群是分布式的，但也必须保证有足够broker正常工作，才能对消息做持久化做保证。也就是说 kafka不丢消息是有前提条件的，假如你的消息保存在 N 个kafka broker上，那么这个前提条件就是这 N 个broker中至少有 1 个存活。只要这个条件成立，kafka就能保证你的这条消息永远不会丢失。

如何保证消息不丢

一条消息从产生，到发送到kafka保存，到被取出消费，会有多个场景和流程阶段，可能会出现丢失情况，我们聊一下kafka通过哪些手段来保障消息不丢。

生产端

Producer端可能会丢失消息。目前Kafka Producer是异步发送消息的，也就是说如果你调用的是producer.send(msg)这个API，那么它通常会立即返回，但此时你不保证消息发送已成功完成。可能会出现：网络抖动，导致消息压根就没有发送到Broker端；或者消息本身不合规导致Broker拒绝接收（比如消息太大了，超过了Broker的限制）。

实际上，使用producer.send(msg, callback)接口就能避免这个问题，根据回调，一旦出现消息提交失败的情况，就可以有针对性地进行处理。如果是因为那些瞬时错误，Producer重试就可以了；如果是消息不合规造成的，那么调整消息格式后再次发送。总之，处理发送失败的责任在Producer端而非Broker端。当然，如果此时broker宕机，那就另当别论，需要及时处理broker异常问题。

消费端

Consumer端丢数据的情况，稍微复杂点。Consumer有个”位移“(offset)的概念，表示Consumer当前消费到topic分区的哪个位置。如图：

kafka通过先消费消息，后更新offset，来保证消息不丢失。但是这样可能会出现消息重复的情况，具体如何保证only-once，后续再单独分享。

当我们consumer端开启多线程异步去消费时，情况又会变得复杂一些。此时consumer自动地向前更新offset，假如其中某个线程运行失败了，它负责的消息没有被成功处理，但位移已经被更新了，因此这条消息对于consumer而言实际上是丢失了。这里的关键就在自动提交offset，如何真正地确认消息是否真的被消费，再进行更新offset。

这个问题的解决起来也简单：如果是多线程异步处理消费消息，consumer不要开启自动提交offset，consumer端程序自己来处理offset的提交更新。提醒你一下，单个consumer程序使用多线程来消费消息说起来容易，写成代码还是有点麻烦的，因为你很难正确地处理offset的更新，也就是说避免无消费消息丢失很简单，但极易出现消息被消费了多次的情况。

实践配置

最后分享下kafka无消息丢失配置：

1. producer端使用producer.send(msg, callback)带有回调的send方法。
2. 设置acks = all。acks是Producer的一个参数，代表“已提交”消息的定义。如果设置成all，则表明所有Broker都要接收到消息，该消息才算是“已提交”。
3. 设置retries为一个较大的值。同样是Producer的参数。当出现网络抖动时，消息发送可能会失败，此时配置了retries的Producer能够自动重试发送消息，尽量避免消息丢失。
4. 设置unclean.leader.election.enable = false。这是Broker端的参数，在kafka版本迭代中社区也多次反复修改过他的默认值，之前比较具有争议。它控制哪些Broker有资格竞选分区的Leader。如果一个Broker落后原先的Leader太多，那么它一旦成为新的Leader，将会导致消息丢失。故一般都要将该参数设置成false。
5. 设置replication.factor >= 3。这也是Broker端的参数。保存多份消息冗余，不多解释了。
6. 设置min.insync.replicas > 1。Broker端参数，控制消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在生产环境中不要使用默认值 1。确保replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本离线，整个分区就无法正常工作了。推荐设置成replication.factor = min.insync.replicas + 1。
7. 确保消息消费完成再提交。Consumer端有个参数enable.auto.commit，最好设置成false，并自己来处理offset的提交更新。

春节将至，希望大家春节期间，线上服务稳定运行不宕机。提前祝大家新年快乐。

你了解几种kafka

kafka的确有好几种，这里我不是指他的版本，是指存在多个组织或公司发布不同特性的kafka。你应该听说过Linux发行版，比如我们熟知的CentOS、RedHat、Ubuntu等，它们都是Linux系统，其实就是因为它们是不同公司发布的Linux系统，即不同的发行版。kafka也同样有多个发行版。

Apache Kafka

Apache Kafka是最“正统”的kafka，也应该是你最熟悉的发行版了。自kafka开源之初，它便在Apache基金会孵化并最终毕业成为顶级项目，也被称为社区版kafka。重要的是，它是后面其他所有发行版的基础。也就是说，后面提到的其他发行版，要么是原封不动地继承了Apache Kafka，要么是在此之上扩展了新功能，总之Apache Kafka是我们学习和使用kafka的基础。

Cloudera/Hortonworks Kafka

Cloudera提供的CDH和Hortonworks提供的HDP是最常见的大数据平台，里面集成了目前主流的大数据框架，能够帮助用户实现从分布式存储、集群调度、流处理到机器学习、实时数据库等全方位的数据处理。我了解到很多创业公司在搭建数据平台时首选就是这两个产品。不管是CDH还是HDP里面都集成了Apache Kafka，因此我把这两款产品中的Kafka称为CDH Kafka和HDP Kafka。

当然在2018年10月两家公司宣布合并，共同打造世界领先的数据平台，合并成CDP一款产品，但能肯定的是Apache Kafka依然会包含其中，并作为新数据平台的一部分对外提供服务。

Confluent Kafka

Confluent公司，2014年，Kafka的3个创始人Jay Kreps、Naha Narkhede和饶军离开LinkedIn创办了Confluent公司，专注于提供基于Kafka的企业级流处理解决方案。2019年1月，Confluent公司成功融资D轮1.25亿美元，估值也到了25亿美元，足见资本市场的青睐。

这里说点题外话， 饶军是我们中国人，清华毕业的大神级人物。我们已经看到越来越多的Apache顶级项目创始人中出现了中国人的身影，另一个例子就是Apache Pulsar，它是一个以打败Kafka为目标的新一代消息引擎系统。至于在开源社区中活跃的国人更是数不胜数，这种现象实在令人振奋。

Confluent公司，主要从事商业化Kafka工具开发，并在此基础上发布了Confluent Kafka。Confluent Kafka提供了一些Apache Kafka没有的高级特性，比如跨数据中心备份、Schema注册中心以及集群监控工具等。

特性对比

说完世面上常见的kafka，我们来比较一下他们的特性

Apache Kafka

Apache Kafka，它现在依然是开发人数最多、版本迭代速度最快的kafka。如果你使用Apache Kafka碰到任何问题并提交问题到社区，社区都会比较及时地响应你。这对于我们kafka普通使用者来说还是比较友好的。

但是Apache Kafka的劣势在于它仅提供最最基础的组件，对于像Kafka Connect额外的数据工具，社区版kafka只提供了一种连接器，即读写磁盘文件的连接器，而没有与其他外部系统交互的连接器，在实际使用过程中需要自行编写代码实现。另外Apache Kafka没有提供任何监控框架或工具，你需要借助第三方的监控框架实现对kafka的监控。目前有一些开源的监控框架可以帮助我们用于监控Kafka（比如Kafka manager，Kafka Eagle等）

总而言之，如果仅仅是需要一个消息引擎系统或是简单的流处理应用场景，同时需要对系统有较大把控，那么推荐你使用Apache Kafka。

CDH/HDP Kafka

再说说大数据云平台公司发布的Kafka（CDH/HDP Kafka）。这些大数据平台已经集成了Apache Kafka，通过便捷化的界面操作将·Kafka·的安装、运维、管理、监控全部统一在控制台中。如果你是这些平台的用户一定觉得非常方便，因为所有的操作都可以在前端界面上完成，而不必去执行复杂的Kafka命令。另外这些平台提供的监控界面也非常友好，通常不需要进行任何配置就能有效地监控 Kafka。

这样做的结果是直接降低了你对Kafka集群的掌控程度。毕竟你对底层的Kafka集群一无所知，难以做到心中有数。这种Kafka 的另一个弊端在于它的滞后性。由于它有自己的发布周期，因此是否能及时地包含最新版本的Kafka就成为了一个问题。比如CDH 6.1.0版本发布时Apache Kafka已经演进到了 2.1.0 版本，但CDH中的Kafka依然是 2.0.0 版本，显然那些在Kafka 2.1.0 中修复的Bug只能等到CDH下次版本更新时才有可能被真正修复，而整个CDH升级还是略显繁重的。

简单来说，如果你需要快速地搭建消息引擎系统，或者你需要搭建的是多框架构成的数据平台且Kafka只是其中一个组件，那么我推荐你使用这些大数据云平台公司提供的Kafka。

Confluent Kafka

Confluent Kafka目前分为免费版和企业版两种。前者和Apache Kafka非常相像，除了常规的组件之外，免费版还包含 Schema注册中心和REST proxy两大功能。前者是帮助你集中管理Kafka消息格式以实现数据前后兼容；后者用开放HTTP接口的方式允许你通过网络访问Kafka的各种功能，这两个都是Apache Kafka所没有的。

除此之外，免费版包含了更多的连接器，都是Confluent公司开发并认证过的，可以免费使用。至于企业版，则提供更多功能。最有用的当属跨数据中心备份和集群监控两大功能了。多个数据中心之间数据的同步以及对集群的监控历来是Kafka的痛点，Confluent Kafka企业版提供了强大的解决方案。

不过Confluent公司暂时没有发展国内业务的计划，相关的资料以及技术支持都很欠缺，很多国内Confluent Kafka使用者甚至无法找到对应的中文文档，因此目前Confluent Kafka在国内的普及率比较低。

如果你需要用到Kafka的一些高级特性，且没有预算成本压力，那么推荐使用Confluent Kafka。

分区(partition)概念

要讲kafka分区数和吞吐量的关系，首先得理解什么是分区(partition)。

Partition是作用于具体的Topic而已的，而不是一个独立的概念。Partition能水平扩展客户端的读写性能，是高吞吐量的保障。通俗的讲，Partition就是一块保存具体数据的空间，本质就是磁盘上存放数据的文件夹，所以Partition是不能跨Broker存在的，也不能在同一个Broker上跨磁盘。对于一个Topic，可以根据需要设定Partition的个数。数据持久化时，每条消息都是根据一定的分区规则路由到对应的Partition中，并append在log文件的尾部(这一点类似于HDFS)，如上图；在同一个Partition中消息是顺序写入的且始终保持有序性；但是不同Partition之间不能保证消息的有序性(高吞吐量的保障)。kafka就是通过使用分区的设计将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。

吞吐量关系

在kafka中，Partition并不是最小的数据存储单元。Partition下还可以细分成Segment，每个Partition是由一个或多个Segment组成。但patition是kafka并行操作的最小单元。在producer和broker端，向每一个分区写入数据是可以完全并行化的，此时，可以通过加大硬件资源的利用率来提升系统的吞吐量，例如对数据进行压缩。在consumer端，kafka只允许单个partition的数据同时被一个consumer线程消费。因此，在consumer端，每一个Consumer Group内部的consumer并行度完全依赖于被消费的分区数量。因此，通常情况下，在一个Kafka集群中，partition的数量越多，意味着可以到达的吞吐量越大。

　　我们可以粗略地通过吞吐量来计算kafka集群的分区数量。假设对于单个partition，producer端的可达吞吐量为p，Consumer端的可达吞吐量为c，期望的目标吞吐量为t，那么集群所需要的partition数量至少为max(t/p,t/c)。在producer端，单个分区的吞吐量大小会受到批量大小、数据压缩方法、确认类型（同步/异步）、复制因子等配置参数的影响。经过测试，在producer端，单个partition的吞吐量通常是在10MB/s左右。在consumer端，单个partition的吞吐量依赖于consumer端每个消息的应用逻辑处理速度。因此，我们需要对consumer端的吞吐量进行测量。

分区扩展

　　虽然随着时间的推移，我们能够对分区的数量进行添加，但是对于基于Key来生成的这一类消息不太一样。当producer向kafka写入基于key的消息时，kafka通过key的hash值来确定消息需要写入哪个具体的分区。通过这样的方案，kafka能够确保相同key值的数据可以写入同一个partition。kafka的这一能力对于一部分顺序要求的业务应用是极为重要的，例如对于同一个key的所有消息，consumer需要按消息的顺序进行有序消费。如果partition的数量发生改变，那么上面的有序性保证将不复存在。为了避免上述情况发生，通常的解决办法是多分配一些分区，以满足未来的需求。

　　此外，我们还可以基于当前的业务吞吐量为kafka集群分配较小的broker数量，随着业务增长，再向集群中增加更多的broker，然后将适当比例的partition迁移到新增加的broker中去（迁移可以参考我之前的文章）。通过这样的方法，可以在满足各种应用场景（包括基于key消息的场景）的情况下，保持业务吞吐量的扩展性。

在规划分区数时，除了吞吐量，还有一些其他因素值得考虑，后续再聊。

内存开销

客户端producer有个参数batch.size默认为16KB。它会为每个分区缓存消息，一旦批次数满了后，将消息批量发出。一般来说，这个设计是用于提升吞吐性能的。但是由于这个参数是partition级别的，如果分区数越多，这部分缓存所需的内存占用也会越多。假如有10000个分区，按照默认配置，这部分缓存就要占用约157MB的内存。而consumer端呢？抛开拉取数据所需的内存不说，单说线程的开销。如果还是10000个分区，同时consumer线程数要匹配分区数的话(大部分情况下是最佳的消费吞吐量配置)，那么在consumer client就要创建10000个线程，也需要创建大约10000个Socket去获取分区数据，这里面的线程切换的开销本身就已经不容小觑了。
服务器端的开销也不小，如果阅读kafka源码的话就会发现，服务器端的很多组件在内存中维护了partition级别的缓存，比如controller，FetcherManager等，因此分区数越多，这种缓存的成本就越大。

文件句柄开销

每个分区在文件系统上会对应一个目录，用于存储维护kafka数据日志。该目录通常会有3个文件，.log，.index，.timeindex，对应kafka的日志数据文件和索引文件(老版本kafka没有timeindex文件)。broker会一直保持打开这3个文件句柄(file handler)。因此，如果分区数越多，所需要保持打开状态的文件句柄数也就越多，最终可能会突破单台broker的ulimit -n的上限。

链路延迟

kafka的链路延迟也就是producer端发布消息到consumer端接收消息所需要的时间。kafka只有在消息提交之后，才会将消息暴露给消费者，期间消息需要在in-sync副本列表中完成同步复制，这是耗时的主要部分。默认情况下，每个broker从其他broker节点进行数据副本同步时，该节点只会为此分配一个线程，该线程需要完成该broker上所有partition数据的复制。我查到数据显示，将1000个partition从一个broker到另一个broker所需时间延迟约为20ms，这意味着链路延迟至少是20ms。这样的延迟对于一些实时业务来说可能就有些长了。

SLA

kafka是通过副本机制(replica)提供高可用，来保障SLA的。每个partition都会有多个副本，每个副本分别存在于不同的broker。所有的数据副本中，有一个数据副本被选举为leader，负责处理producer和consumer请求。其他的数据副本为follower，由Kafka controller负责保证与leader的同步。当leader不可用时，会从follower中重新选出新的leader，这中间会有短暂的不可用时间，虽然大部分情况下可能只是几毫秒级别。但是假如，一个2节点的kafka集群中存在2000个partition，每个partition拥有2个副本。当其中一个broker意外宕机，所有1000个partition同时变得不可用。假设每一个partition恢复时间是5ms，那么1000个partition的恢复时间将会花费5秒钟，这可能对用户来说就会有一个明显的感知了。如果宕机的是controller节点，不可用时间将会更严重。

上述问题，通常情况下，都可以通过扩容集群来缓解，毕竟在不考虑成本的情况下，堆机器可以解决90%的问题。当然正常情况，还是得在合理的成本范围内，进行合理的规划和调优，上述弊端一般都是能在可控范围内的。

原因探究

这是因为kafka只保证分区数量在各个磁盘上均匀分布，但它无法统计每个分区实际占用磁盘空间。因此很有可能出现某些分区消息数量巨大导致占用大量磁盘空间的情况。在1.1版本之前，用户对此基本没有优雅的处理方法，即便手动迁移日志文件和offset信息，也需要重启生效，风险极高。因为1.1之前kafka只支持分区数据在不同broker间的重分配，而无法做到在同一个broker下的不同磁盘间做重分配。1.1版本正式支持副本在不同路径间的迁移，具体的实现细节详见kafka官方wikiKIP-113。

目录间迁移步骤

假设我在server.properties文件中配置了多个日志存储路径(代表多块磁盘)，如下所示：

1
2
3

# A comma seperated list of directories under which to store log files
log.dirs=/data1/kafka-logs,/data2/kafka-logs,/data3/kafka-logs

然后我创建了一个9分区的topic，并发送了900W条消息。查询这些目录发现Kafka均匀地将9个分区分布到这三个路径上，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

> ll /data1/kafka-logs/ |grep test-topic
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-3
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-4
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-5
> ll /data2/kafka-logs/ |grep test-topic
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-0
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-1
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-2
> ll /data3/kafka-logs/ |grep test-topic
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-6
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-7
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-8

假设由于还有其他topic数据分布等原因，导致磁盘存储不均衡。需要将test-topic的6，7，8分区全部迁移到/data2路径下，并且把test-topic的1分区迁移到/data1下。若要实现这个需求，我们首先需要写一个JSON文件,migrate-replica.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

{
    "partitions": [
        {
            "topic": "test-topic",
            "partition": 1,
            "replicas": [
                0
            ],
            "log_dirs": [
                "/data1/kafka-logs"
            ]
        },
        {
            "topic": "test-topic",
            "partition": 6,
            "replicas": [
                0
            ],
            "log_dirs": [
                "/data2/kafka-logs"
            ]
        },
        {
            "topic": "test-topic",
            "partition": 7,
            "replicas": [
                0
            ],
            "log_dirs": [
                "/data2/kafka-logs"
            ]
        },
        {
            "topic": "test-topic",
            "partition": 8,
            "replicas": [
                0
            ],
            "log_dirs": [
                "/data2/kafka-logs"
            ]
        }
    ],
    "version": 1
}

其中，replicas中的0表示broker ID，由于本文只启动了一个broker，且broker.id = 0，故这里只写0即可。实际上你可以指定多个broker实现为多个broker同时迁移副本的功能。另外当前的version固定是1。

保存好这个JSON后，我们执行以下命令执行副本迁移：

1
2
3
4
5
6
7
8

> bin/kafka-reassign-partitions.sh  --zookeeper localhost:2181 --bootstrap-server localhost:9092 --reassignment-json-file ../migrate-replica.json --execute
Current partition replica assignment
{"version":1,"partitions":[{"topic":"test-topic","partition":8,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":4,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":5,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":2,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":6,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":3,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":1,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":7,"replicas":[0],"log_dirs":["any"]},{"topic":"test-topic","partition":0,"replicas":[0],"log_dirs":["any"]}]}
Save this to use as the --reassignment-json-file option during rollback
Successfully started reassignment of partitions.

迁移结果

执行完成后，我们再次查看存储目录副本分布：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

> ll /data1/kafka-logs/ |grep test-topic
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-1
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-3
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-4
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-5
> ll /data2/kafka-logs/ |grep test-topic
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-0
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-1
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-2
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-6
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-7
drwxr-xr-x   6 kafka  staff  192 Dec 14 17:21 test-topic-8
> ll /data3/kafka-logs/ |grep test-topic

可以看到，6，7，8已经被成功地迁移到/data2下，而分区1也迁移到了/data1下。值得一提的是，不仅所有的日志段、索引文件被迁移，实际上分区外层的checkpoint文件也会被更新。比如我们检查/data2下的replication-offset-checkpoint文件可以发现，现在该文件已经包含了6，7，8分区的位移数据，如下所示：

1
2
3
4
5
6
7
8
9
10

> cat replication-offset-checkpoint 
0
7
test-topic 8 1000000
test-topic 2 1000000
test 0 1285714
test-topic 6 1000000
test-topic 7 1000000
test-topic 0 1000000
test 2 1285714

分区重分配方案

扩容后的数据均衡，其本质就是对topic进行分区重分配，数据迁移的过程。
在执行分区重分配的过程中，对集群的影响主要有两点：

1. 分区重分配主要是对topic数据进行Broker间的迁移，因此会占用集群的带宽资源；
2. 分区重分配会改变分区Leader所在的Broker，因此会影响客户端。

针对以上两点，第一点可以在晚间业务低峰时操作，必要时还可以和业务沟通，临时缩短数据保存时间，加快迁移，减少带宽影响时间。
针对第二点，有两个方案：

1. 整个分配方案分成两个步骤：
   1）手动生成分配方案，原有分区Leader位置不改变，只对副本进行分区重分配；
   2）等待数据迁移完成后，再手动更改分区分配方案，目的是均衡Leader。
2. 直接用Kafka官方提供的分区重新分配工具生成分区重分配方案，直接执行分区重分配。

重分配方案分析

方案一

方案一理论对客户端影响最小，把整个分配方案分成了两个步骤，也就是将对集群的带宽资源与客户端的影响分开了，对过程可控性很高。但问题是，如果集群中的某些topic，比如有64个分区，3副本，共192个副本，就需要在保持原有分区Leader位置不变的情况下，手动均衡其余副本，这个人工步骤过度繁杂，稍微有一点偏差，就会造成副本不均衡。

方案二

针对方案二我特意去看了分区重分配的源码，并对其过程进一步分析。发现分区重分配的步骤是，将分区原有的副本与新分配的副本合并成一个新的副本集合，新分配的副本努力追上Leader的offset，最终加入ISR。待全部副本都加入ISR之后，就会进行分区Leader选举，选举完后删除原有副本。这里注意，由于是最后选举完成才删除原副本，所以重分配的过程中，日志存储量是会大幅增加的。具体细节我后续单独写一篇文章叙述。

根据以上分析，意味着在数据进行重分配过程中，Leader并没有发生变动，所以客户端不会阻塞，数据迁移完成后进行Leader选举时发生变更，生产者会及时拉取最新的元数据，并重新进行消息发送，影响并不大。

重分配步骤

其实官方文档关于集群扩容讲解很详细：Expanding your cluster ,整个过程分为三个步骤：获取kafka给出的建议分配方案、按照给出的分配方案执行分配、查看分配的进度以及状态。这三个步骤对应了kafka脚本提供的三个partition reassigment工具。

1
2
3

--generate: 在此模式下，给定一个 topic 列表和一个 broker 列表，该工具会生成一个候选重新分配，以将指定的 topic 的所有分区移动到新的broker。此选项仅提供了一种便捷的方式，可以根据 tpoc 和目标 broker 列表生成分区重新分配计划。
--execute: 在此模式下，该工具基于用户提供的重新分配计划启动分区重新分配。（使用--reassignment-json-file选项）。这可以是由管理员制作的自定义重新分配计划，也可以是使用--generate选项提供的自定义重新分配计划。
--verify: 在此模式下，该工具将验证最近用 --execute 模式执行间的所有分区的重新分配状态。状态可以是成功完成，失败或正在进行。

1. 生成需要执行分区重分配的topic列表json文件：

   1 2 3 4 5

   > cat topics-to-move.json {"topics": [{"topic": "foo1"}, {"topic": "foo2"}], "version":1 }

2. 使用kafka-reassign-partitions.sh脚本获取分配方案：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   > bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate 当前分区副本分配 {"version":1, "partitions":[{"topic":"foo1","partition":2,"replicas":[1,2]}, {"topic":"foo1","partition":0,"replicas":[3,4]}, {"topic":"foo2","partition":2,"replicas":[1,2]}, {"topic":"foo2","partition":0,"replicas":[3,4]}, {"topic":"foo1","partition":1,"replicas":[2,3]}, {"topic":"foo2","partition":1,"replicas":[2,3]}] } 建议的分区重新分配配置 {"version":1, "partitions":[{"topic":"foo1","partition":2,"replicas":[5,6]}, {"topic":"foo1","partition":0,"replicas":[5,6]}, {"topic":"foo2","partition":2,"replicas":[5,6]}, {"topic":"foo2","partition":0,"replicas":[5,6]}, {"topic":"foo1","partition":1,"replicas":[5,6]}, {"topic":"foo2","partition":1,"replicas":[5,6]}] }

   保存当前分区副本分配情况，用作回滚操作用。保存建议的分区重新分配配置到expand-cluster-reassignment.json用于执行迁移。

3. 执行重分配，并验证。

   1 2 3 4 5 6 7 8 9 10

   > bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json --execute > bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json --verify Status of partition reassignment: Reassignment of partition [foo1,0] completed successfully Reassignment of partition [foo1,1] is in progress Reassignment of partition [foo1,2] is in progress Reassignment of partition [foo2,0] completed successfully Reassignment of partition [foo2,1] completed successfully Reassignment of partition [foo2,2] completed successfully

   is still in progress表示还在处理中，全部迁移成功后每个partition都会显示completed successfully。注意如果topic数据量大，这个过程可能会很长，在此期间不要进行敏感操作，可能会导致数据不一致。

自定义重分配

分区重新分配工具还可以将分区的副本移动到指定的一组broker。只需自定义修改分配配置文件，后续步骤同上。

例如，以下示例将topic foo1的分区0移到broker5,6中和将topic foo2的分区1移到broker2,3中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

> cat custom-reassignment.json
{
    "version": 1,
    "partitions": [
        {
            "topic": "foo1",
            "partition": 0,
            "replicas": [
                5,
                6
            ]
        },
        {
            "topic": "foo2",
            "partition": 1,
            "replicas": [
                2,
                3
            ]
        }
    ]
}

常规问题

由于在和读者交流的过程中，发现大家技术水平参差不齐，本着科普性文章的初衷，这里先讲一些比较基础的要点，大佬们可以忽略，直接跳过。

1. 在打包时，需要对照自己的Hadoop或者Spark版本，修改compile.conf文件中的版本号。否则有可能出现采集不到集群作业信息的情况。
2. 最好将自己Hadoop集群的相关配置文件都拷贝到dr.elephant的app-conf目录下。
3. 统一自己Hadoop集群的环境变量。

数据库问题

Database ‘default’ is in an inconsistent state!

启动失败并出现这个报错，一般是play框架的evolution问题，解决方法如下：

1. 停止dr.elephant并确保进程已kill
2. 删除原来的数据库并重新建库
3. 配置app-conf/elephant.conf中jvm_props="-Devolutionplugin=enabled -DapplyEvolutions.default=true"，开启evolution，使其能够自动初始化表结构。

Specified key was too long; max key length is 767 bytes [ERROR:1071, SQLSTATE:42000]

这是一个较为常见的错误了，官方的历史遗留问题导致，根据报错可以看出是由于索引长度超过mysql允许的最大长度导致。解决方法如下：

1. conf/evolutions/default目录下的1.sql和5.sql中，增加索引长度的截取为100。

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   evolutions/default/1.sql create index yarn_app_result_i4 on yarn_app_result (flow_exec_id(100)); create index yarn_app_result_i5 on yarn_app_result (job_def_id(100)); create index yarn_app_result_i6 on yarn_app_result (flow_def_id(100)); evolutions/default/5.sql -- flow_definition table change to UNIQUE KEY flow_def_id (flow_def_id(100)) -- job_definition table change to UNIQUE KEY job_def_id (job_def_id(100)) -- job_execution table change the index length like below: create index index_je_job_exec_id on job_execution (job_exec_id(100)); create index index_je_job_exec_url on job_execution (job_exec_url(100));

2. 或者修改mysql的my.cnf配置文件，添加innodb_large_prefix=1，然后重启MySQL，使其自身支持较大索引

3. 此外，建议mysql直接使用5.6及以上的版本，避免一些不必要的问题

作业信息采集问题

dr.elephant的核心原理就是通过采集作业信息日志，来进行一系列的分析，算法推荐等功能。
主要分为hadoop的MapReduce，和spark作业信息采集。

hadoop

采集原理

MapReduce作业信息有两种拉取方式可选，在app-conf/FetcherConf.xml进行配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<fetcher>
  <applicationtype>mapreduce</applicationtype>
  <classname>com.linkedin.drelephant.mapreduce.fetchers.MapReduceFetcherHadoop2</classname>
   <params>
    <sampling_enabled>false</sampling_enabled>
   </params>
</fetcher>
 
<fetcher>   
<applicationtype>mapreduce</applicationtype>
  <classname>com.linkedin.drelephant.mapreduce.fetchers.MapReduceFSFetcherHadoop2</classname>
    <params>
    <sampling_enabled>false</sampling_enabled>            
     <history_log_size_limit_in_mb>500</history_log_size_limit_in_mb>
     <history_server_time_zone>PST</history_server_time_zone>
    </params>
</fetcher>

通过源码分析，由于源码过长，这里就不贴出来了，直接讲源码逻辑，发现两个Fetcher类分别是：

• MapReduceFetcherHadoop2：通过API从yarn history server获取作业信息日志
• MapReduceFSFetcherHadoop2：通过读取HDFS和YARN的配置文件，读取mapreduce.jobhistory.done-dir等相关配置，直接读取HDFS上YARN的历史作业信息日志。每个作业对应.jhist和.xml两个文件

  1 2 3 4 5

  # *.xml文件里面记录的是相应作业运行时候的完整参数配置 hdfs dfs -cat /mr-history/done/2019/11/01/000000/job_1477464172237_0052_conf.xml # *.jhist文件里存放的是具体Hadoop作业运行的详细信息 hdfs dfs -cat /mr-history/done/2019/11/01/000000/job_1477464172237_0052-1477984365827-ocdp-QuasiMonteCarlo-1477984395977-4-1-SUCCEEDED-default-1477984370174.jhist

问题点

1. 为什么采集不到作业信息，界面上没有任何显示？

   • 注意dr.elephant打包前Hadoop version配置和被采集集群的版本信息是否对应上了，否则会出现采集不到的情况。
   • 查看history_log_size_limit_in_mb配置大小是否小于实际单个日志文件大小，导致无法拉取日志。
   • 检查drelephant.analysis.fetch.initial.windowMillis配置时间，这个配置为初始化时间拉取时间窗口，即拉取当前时间之前多久的历史作业。如果当前时间到时间窗口之前没有历史作业，则会出现无作业信息的情况。
   • drelephant.analysis.retry.interval配置为拉取间隔时间，这个配置过大，也会导致长时间不拉取作业，而无作业信息。

2. 运行一段时间后，为什么作业信息延迟严重？

   • drelephant.analysis.thread.count作业分析线程数影响着分析效率，设置的过小很容易延迟
   • 以上采集不到作业信息问题的几个排查点，也比较容易造成延迟情况，需要自己根据作业数量，进行一个评估设置

spark

采集原理

Spark作业信息同样有两种拉取方式可选，在app-conf/FetcherConf.xml进行配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<fetcher>
    <applicationtype>spark</applicationtype>
    <classname>com.linkedin.drelephant.spark.fetchers.FSFetcher</classname>
    <params>
      <event_log_size_limit_in_mb>500</event_log_size_limit_in_mb>
      <event_log_location_uri>webhdfs://localhost:50070/system/spark-history</event_log_location_uri>
    </params>
</fetcher>
<fetcher>
    <applicationtype>spark</applicationtype>
    <classname>com.linkedin.drelephant.spark.fetchers.SparkFetcher</classname>
    <params>
      <use_rest_for_eventlogs>true</use_rest_for_eventlogs>
      <should_process_logs_locally>true</should_process_logs_locally>
    </params>
</fetcher>

通过源码分析，由于源码过长，这里就不贴出来了，直接讲源码逻辑，发现两个Fetcher类分别是：

• FSFetcher：直接通过hdfs拉取spark的历史日志
• SparkFetcher：通过SHS REST API拉取spark的eventlogs，需要spark版本在1.5.0以上。此外还可以支持backfill功能，但仅适用于2.3.0以上版本。

问题点

1. MapReduce作业正常采集并分析，为什么spark作业没有分析数据？

   • 首先参照上面hadoop版本打包问题检查，打包前是否同样在配置文件中修改为正确的spark版本
   • 检查hdfs上spark eventlogs存放目录是否产生了日志文件，以及程序是否有相应的操作权限
   • 如果使用了老版本的dr.elephant，则还需要注意spark是否开启了spark.eventLog.compress，导致产生的spark日志为snappy格式，使得dr.elephant无法识别。老版本可以通过增加配置进行识别

     1 2	<event_log_dir>/spark- history</event_log_dir> <spark_log_ext>.snappy</spark_log_ext>

2. 为什么部分spark作业缺失，dr.elephant没有显示所有作业？

   • 同上Hadoop问题点，可能出现了延迟问题
   • SHS可能没有配好spark日志聚合，解决办法另行找SHS日志聚合资料，这里不再多说

以上是个人在实战中遇到的一些问题及解决方法，后续如果还有其他问题我也会及时更新，或者大家还遇上啥坑了也可以和我交流讨论。

加速你的作业流

一般对于特定的作业，最好有自己的配置。大多数情况下，作业的默认配置无法提供最佳性能。尽管作业调优比较费劲，但一些简单的调整往往也能带来不错的效果。

需要特别注意的是mapper和reducer的数量，io和内存使用的配置，以及生成的文件数量。对这几个参数进行调整，让参数更适合当前的任务，可以极大的提升任务的执行性能。

Apache的官网中Hadoop Map/Reduce Tutorial这篇文章提供很多详细且有用的调试建议，有兴趣的可以仔细看看。

常规建议

逐步调优很重要

对于Pig作业来说，如果使用默认参数来设置reducer的数量，这对作业的性能可能是致命的。一般来说，对每个Pig作业，都花一些时间来调优参数PARALLEL是非常值得做的。例如：

1

memberFeaturesGrouped = GROUP memberFeatures BY memberId PARALLEL 90;

文件数vs块数量

为了防止NameNode崩溃，存大文件比小文件更合理。NameNode每存储一个文件大概消耗70 bytes，每存储一个块大概消耗60 byte。一般情况下，对于任务来说，使用一个较大的文件要比使用十个小文件的效率高一些。在大规模集群下，这10 byte的差距会越来越大。此外在许多情况下，1个大文件比10个小文件操作起来更高效。

Java任务内存管理

默认情况下，每个map/reduce作业可以分配最大2G的内存。对于java任务，这2G的空间既包括1G的堆内存，又包括0.5-1G的非堆内存。对于有些任务来说，默认的空间分配可能是不够用的。下面列举了一些能够减少内存使用的技巧：

UseCompressedOops

32位JVM使用32bit无符号整型来定位内存区域，最大和定义的堆内存为(2^32 -1) = 4GB。64位的JVM虚拟机使用64bit的无符号Long整型来定位内存区域，最大可定义的堆内存大小为(2^64 - 1) = 16艾字节。虽然定义的堆内存增加了，但是用Long代替int型，所需内存空间也增加了。大约为原来的1.5倍。这使得你可以突破1G堆空间的限制，对此你可以做些什么呢？现在所有的JVM都支持UseCompressedOops选型，在某些情况下，他使用32bit的空间代替64bit空间来保存内存定位信息。这将可以减少内存的占用而不用回到32bit的情况。你可以在azkaban的作业文件中增加以下选项来实现：

1

hadoop-inject.mapreduce.(map|reduce).java.opts=-Xmx1G -XX:+UseCompressedOops

注意azkaban默认会使用自定义的属性覆盖掉默认配置属性，而不是将自定义的部分添加到mapred-site.xml默认文件中。你需要确认CompressedOops选项和其他默认的配置都是有效的。需要确认的是：”-Xmx1G”是配置文件mapred-site.xml中的，而其他的配置文件是我们自定义的。

UseCompressedStrings

这个选项会将String类型的变量转化为byte[]类型来保存。如果一个任务中使用了大量的String类型变量，那么这个选项将会极大的节约内存使用。在参数mapreduce.(map|reduce).java.opts配置中添加-XX:+UseCompressedString就会激活这个选项。每个作业分配的虚拟内存空间是需要的物理内存空间的2.1倍。如果我们程序抛出以下错误：

1
2
3
4

Container [pid=PID,containerID=container_ID]
 is running beyond virtual memory limits. Current usage: 365.1 MB of 1
GB physical memory used; 3.2 GB of 2.1 GB virtual memory used. Killing
container

你就可以尝试使用这个选项来对程序进行优化。

关键调优参数

Mappers

mapreduce.input.fileinputformat.split.minsize

这个参数表示输入到map中的每个文件块切分的大小的最小值。通过增加dfs.blocksize的块大小，可以增加每个map中输入文件块的大小，从而减少map的数量。这是因为如果说你设置mapreduce.input.fileinputformat.split.minsize的大小为HDFS块大小（dfs.blocksize）的4倍时，那么输入到每个map的数量就是4倍的dfs.blocksize，这样就减少了map的数量。如果把这个值设置为256MB，那么输入的文件大小就是268435456bit。

mapreduce.input.fileinputformat.split.maxsize

这个参数表示当使用CombineFileInputFormat和MultiFileInputFormat时，输入到map的每个文件的最大值。当这个值小于dfs.blocksize时，会增加作业的mapper的数量。这是因为如果说你设置mapreduce.input.fileinputformat.split.minsize的大小为HDFS块大小（dfs.blocksize）的1/4时，这样就将输入到每个map的文件大小限制为dfs.blocksize的1/4，就增加了map的数量。这个值是输入文件切分的值。因此要设置为256MB，你将指定值为268435456。需要注意的是，如果在使用CombineFileInputFormat时未设置最大分割大小，则作业将仅使用1个mapper来处理作业。（这可能是你不希望看到的）

Reducers

mapreduce.job.reduces

影响作业流性能的最大杀手之一是reducers的数量。reducers数量过少，可能会使任务时间超过15分钟，而数量过多也同样会有问题。针对每个特定的任务因地制宜的调整reducer数量是一项艺术。下面列了一些方法来帮助我们来设置合适的reducer数量：

• reducers越多意味着Namenode上文件越多，过多的小文件可能会导致Namenode宕机。因此如果reduce输出不大（小于512M），可以减少reducers的数量
• reducers越多意味着每个reducer处理数据的时间越短，如果reducers数量过少。那么每个reducer的消耗时间就会增加，reducer运行越快，就能处理更多的作业。

在大型任务中，清洗（Shuffling）操作的代价是比较高的。我们通过HDFS文件系统的各个计数器可以看到有大量的数据需要在不同的节点间进行交换。我们用20个reducers的作业来做个试验，文件系统的计数器如下：
FileSystemCounter：

• FILE_BYTES_READ | 2950482442768
• HDFS_BYTES_READ | 1223524334581
• FILE_BYTES_WRITTEN | 5967256875163

我们可以看到有超过1K个map产生了约5TB的中间数据。再看下清洗时间：
Shuffle Finished:
17-Aug-2010 | 13:32:05 | ( 1hrs, 29mins, 56 sec)

Sort Finished:
17-Aug-2010 | 14:18:35 | (46mins, 29sec)

可以看出，大约有5TB的数据花费了1个半小时来清洗，然后有花了46分钟来进行排序。这个时间成本是巨大的。我们希望任务可以在5-15分钟内完成。我们现在已经解决了这个问题。让我们来算一下：使用20个reducers需要消耗360分钟，200个reducers则需要36分钟，400个reducers则需要18分钟。因此围绕这个逻辑来进行改进，将reducers控制在500个以下则出现以下结果：
Shuffle Finished:
17-Aug-2010 | 16:32:32 | ( 12 mins, 46 sec)

Sort Finished:
17-Aug-2010 | 16:32:37 | (4sec)
效果看着还不错，通过一些调优，我们可以缩短一些任务时间。正如你猜的那样，反过来也一样。如果清洗时间很短，CPU使用也很少，那么说明reducer数量过少，合适的配置需要通过不断的试验来确定。

mapreduce.job.reduce.slowstart.completedmaps

这个参数决定了在reducer开始执行之前，至少有多少比例的mapper必须执行结束。默认值是80%。对于大多数任务，调整这个数字的大小可能会带来性能提升。决定这个数字的因素是：

• 每个reducer接收到多少数据
• 剩下的map每一个map作业需要花费的时间
  如果map的输出数据量比较大，一般会建议让reducer提前开始执行去处理这些数据。如果map任务产生的数量不是很大，一般建议让reducer的执行时间开始的晚一些。对于清洗过程的一个粗略的时间估计是：当所有的mapper结束后开始，到第一个reducer开始执行的时间为止。这是reducer获得所有的输入所需要的时间。一般认为，reducers开始执行时间是：最后一个map结束时间+清洗时间。

压缩

mapreduce.map.output.compress

将这个参数设置为True可以将map输出的数据进行压缩。这可以减少节点间的数据交互，但我们必须确保解压缩的时间要比传输时间短，否则会起反作用。对于大型或可以高度压缩的map输出数据，这个参数选型非常有必要，将大量减少清洗时间。对于小型map输出数据集，关闭这个参数，将降低解压缩带来的CPU消耗时间。注意与mapreduce.output.fileoutputformat.compress选项不同，那个参数决定了任务的输出回写到HDFS时是否需要压缩。

内存

mapreduce.(map|reduce).memory.mb

新版Hadoop中增加了堆内存的限制特性。这使得系统在繁忙情况下更好的管理资源分配。默认情况下，系统会分配给Java任务1GB的堆内存，以及0.5-1GB的非堆内存空间。因此，mapreduce.(map|reduce).memory.mb的默认值为2GB。在某些情况下，这个内存值是不够用的。如果只是设置Java的参数-Xmx，任务会被杀死，需要同时设置参数mapreduce.(map|reduce).momory.mb才能有效的提升或者限制内存使用。

进阶

控制io.sort.record.percent的值

参数io.sort.record.percent决定使用多少的间接缓存空间来保存每条和每条记录的元信息。一般来说，这个参数的设置是不合理的。

假设在map作业中使用日志的xml的配置文件：

使用上面的值：
| property | value |
| — | — |
| io.sort.spill.percent (length-kvstart+kvend) / length) | 0.8 |
| Size of meta data is (bufend-bufstat) | 22816958 (MB) |
| Records in memory (length-(kvstart+kvend)) | 671087 |
| Average record size (size/records) | 34 Bytes |
| Record+Metadata | 50 Bytes |
| Records per io.sort.mb (io.sort.mb/(record+metadata)) | 5.12 million |
| Metadata % in io.sort.mb ((records per io.sort.mb)*metadata/io.sort.mb) | 0.32 |

我们可以在256MB的缓存中保存很多数据。但是io.sort.record.percent应该设置为0.32，而不是0.5。当设置为0.5时，记录的元信息的缓存会比记录的缓存更大。

调整这个参数会使map运行的更快，磁盘溢出问题更少，因为io.sort.mb的效率更高了；不会再很快就使用完元数据缓冲区的80%空间。

调整io.sort.record.percent后会使得许多map数据不再溢出到磁盘，减少了55%的磁盘溢。最终，系统节省了30%的CPU资源消耗，和30分钟运行时间。

mapreduce.(map|reduce).speculative

这个参数决定了是否允许相同的map/reduce并行执行。你大概知道当发生数据倾斜时，有些mapper或reducer会运行很长时间。在这种情况下，你可能希望通过一些预判来防止数据倾斜。

Pig

在Pig中你可以通过增加以下命令来设置Hadoop和Pig

1

SET <property_name> <property_value>;

例如，如果你的map内存不足，可以通过以下命令增加内存

1

SET mapreduce.map.memory.mb 4096;

在Azkaban中，可以通过以下命令实现

1
2

jvm.args=-Dmapreduce.map.memory.mb=4096
to your job properties.

pig.maxCombinedSplitSize / 增加或减少mapper数量

默认情况下，Pig合并了小文件（pig.splitCombination默认为true），直到需要切分的HDFS块大小超过512MB。要进一步增加这个值，需要调高pig.maxCombinedSplitSize。相关详情可以看这里。你可以在你的Pig脚本中添加以下命令

1

set pig.maxCombinedSplitSize <size-in-bytes>;

在你的Pig脚本的开头。如果您通过Azkaban执行此Pig脚本，您也可以通过添加以下命令来设置他

1

jvm.args=-Dpig.maxCombinedSplitSize=<size-in-bytes>

在你的作业属性中。如果你的mapper耗时太长，想增加mapper数量，你必须同时设置

1
2

set pig.maxCombinedSplitSize <size-in-bytes>;
set mapreduce.input.fileinputformat.split.maxsize <size-in-bytes>;

如果值小于512MB。是因为Pig拆分块的值超过了pig.maxCombinedSplitSize，拆分大小由以下配置决定

1

max(mapreduce.input.fileinputformat.split.minsize, min(mapreduce.input.fileinputformat.split.maxsize, dfs.blocksize))

提供一些集群设置：

1
2
3
4

mapreduce.input.fileinputformat.split.minsize=0
mapreduce.input.fileinputformat.split.maxsize is unset
dfs.blocksize=536870912 // 512 MB
will evaluate to 512 MB.

Reducers数量

在Pig中，你可以基于每个作业控制Reducer的数量，还可以选择为整个脚本设置默认的reducers数量。浏览此处获取更多信息。

Hive

• mapreduce.input.fileinputformat.split.minsize
• mapreduce.input.fileinputformat.split.maxsize
• mapreduce.input.fileinputformat.split.minsize.per.node
• mapreduce.input.fileinputforomat.split.minsize.per.rack

对应Hive来说，你可能需要设置以上4个参数来调整切分大小。
例如：

1
2
3
4
5

-- The following are the default configurations on our Hadoop clusters.
set mapreduce.input.fileinputformat.split.maxsize                 = 2147483648;
set mapreduce.input.fileinputformat.split.minsize                 = 1073741824;
set mapreduce.input.fileinputformat.split.minsize.per.node        = 1073741824;
set mapreduce.input.fileinputformat.split.minsize.per.rack        = 1073741824;

如果你想增加mapper的数量，就减少这些配置的值；反之，则增加这些配置的值。

Dr.Elephant这个项目是希望构建一个可以自动优化hadoop mapreduce相关函数的调优框架。在这种情况下，是为了函数消耗最少的资源来完成作业。我们还希望在未来的版本将作业时间也作为函数资源消耗的参考指标。我们使用迭代算法和粒子群优化算法进行自动调优。这些迭代通过分析作业的多次运行结果来完成，我们已经在15-20次的作业中优化了20-30%的资源。

自动优化从作业的默认参数开始，并且在每次运行之后计算判断当前参数是否适合，并且根据算法建议新的参数。为了与Dr.Elephant交互，开发了getCurrentRunParameters新API，它返回给定作业当前运行的参数。

组件

守护进程

自动调优模块中有以下4个守护进程：

• 基线计算：该Daemon通过Dr.Elephant的历史数据平均值来计算新作业应当消耗的资源和时间
• 作业完成检查器：一旦修改了新的调优参数来执行作业，该Daemon将继续轮询作业直到完成。对于Azkaban调度器则使用Azkaban rest API
• 打分器（Fitness Computation Daemon）：一旦作业完成（成功/失败），该Daemon将根据作业消耗的资源和数据大小来评判参数集是否合适
• 参数生成器（Param Generator）：一旦设置好当前的参数集，该Daemon就会生成新的参数建议。目前我们使用PSO算法进行新的参数建议。

Rest API

有个getCurrentRunParameters的新API，它从数据库获取建议的参数并将其返回。目前，这是外部系统和Dr Elephant之间唯一的自动调优交互。

自动调优的测试版本将支持以下特性：

• 目前支持Pig Script优化
• 支持Azkaban调度器
• 支持全局开启或关闭自动调优
• 约束应用参数确保不会因为自动调优而导致作业失败
• 如果参数超出允许资源使用/执行时间的限制，则对其进行处罚

我们计划将在未来的版本支持以下特性：

• 支持Hive和Spark
• 执行时间优化
• 改进可视化报告

自动调优架构调整

Table 1: tuning_algorithm
这张表用于记录优化度量信息（资源，时间）和作业类型（Pig,Hive）的算法。通常情况下，一种作业类型应该有一种算法，但框架也支持一行有多种算法。

Table 2: tuning_parameter
此表记录tuning_algorithm中的每个算法优化的Hadoop参数。
例如mapreduce.map.memory.mb，mapreduce.task.io.sort.mb等。

Table 3: flow_definition
此表记录作业流，可以来自任何调度程序，如Azkaban，Oozie，Appworx等。

Table 4: job_definition
此表记录需要优化的作业。还包含除了自动优化信息之外的一般信息。作业信息放在2张表里，因为并不是所有作业都需要开启自动调优。

Table 5: tuning_job_definition
此表记录需要优化的作业和仅需要自动调整的信息。

Table 6: flow_execution
此表记录作业流的执行步骤。

Table 7: job_execution
此表记录作业流中的一次作业。包含自动优化之外的作业执行信息。作业信息放在2张表里，因为并不是所有作业都需要开启自动调优。

Table 8: tuning_job_execution
此表记录一次作业流的作业，并包含自动调优相关信息。这次执行对应一组参数。

Table 9: job_saved_state
由于优化算法的内部表。存储需要优化的作业的当前状态。

Table 10: job_suggested_param_value
记录一次作业的建议参数值。

资源用量

资源使用情况是你作业在GB小时内使用的资源量。

计量统计

我们将作业的资源使用量定义为任务容器大小和任务运行时间的乘积。因此，作业的资源使用量可以定义为mapper和reducer任务的资源使用量总和。

范例

1
2
3
4
5
6
7
8

Consider a job with: 
4 mappers with runtime {12, 15, 20, 30} mins. 
4 reducers with runtime {10 , 12, 15, 18} mins. 
Container size of 4 GB 
Then, 
Resource used by all mappers: 4 * (( 12 + 15 + 20 + 30 ) / 60 ) GB Hours = 5.133 GB Hours 
Resource used by all reducers: 4 * (( 10 + 12 + 15 + 18 ) / 60 ) GB Hours = 3.666 GB Hours 
Total resource used by the job = 5.133 + 3.6666 = 8.799 GB Hours

浪费的资源量

这显示了作业以GB小时浪费的资源量或以浪费的资源百分比。

计量统计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

To calculate the resources wasted, we calculate the following: 
The minimum memory wasted by the tasks (Map and Reduce)
The runtime of the tasks (Map and Reduce)
The minimum memory wasted by a task is equal to the difference between the container size and maximum task memory(peak memory) among all tasks. The resources wasted by the task is then the minimum memory wasted by the task multiplied by the duration of the task. The total resource wasted by the job then will be equal to the sum of wasted resources of all the tasks. 
 
Let us define the following for each task: 
peak_memory_used := The upper bound on the memory used by the task. 
runtime := The run time of the task. 
The peak_memory_used for any task is calculated by finding out the maximum of physical memory(max_physical_memory) used by all the tasks and the virtual memory(virtual_memory) used by the task. 
Since peak_memory_used for each task is upper bounded by max_physical_memory, we can say for each task: 
peak_memory_used = Max(max_physical_memory, virtual_memory/2.1)
Where 2.1 is the cluster memory factor. 
The minimum memory wasted by each task can then be calculated as: 
wasted_memory = Container_size - peak_memory_used 
The minimum resource wasted by each task can then be calculated as: 
wasted_resource = wasted_memory * runtime

运行时间

运行时间指标显示了作业运行的总时间。

计量统计

作业运行时间是作业提交到资源管理器和作业完成时的时间差。

范例

作业的提交时间为1461837302868 ms，结束时间为1461840952182 ms，作业的runtime时间是1461840952182 - 1461837302868 = 3649314 ms，即1.01小时。

等待时间

等待时间是作业处于等待状态消耗的时间

计量统计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

For each task, let us define the following: 
ideal_start_time := The ideal time when all the tasks should have started 
finish_time := The time when the task finished 
task_runtime := The runtime of the task 
- Map tasks
For map tasks, we have 
ideal_start_time := The job submission time 
We will find the mapper task with the longest runtime ( task_runtime_max) and the task which finished last ( finish_time_last ) 
The total wait time of the job due to mapper tasks would be: 
mapper_wait_time = finish_time_last - ( ideal_start_time + task_runtime_max) 
- Reduce tasks
For reducer tasks, we have 
ideal_start_time := This is computed by looking at the reducer slow start percentage (mapreduce.job.reduce.slowstart.completedmaps) and finding the finish time of the map task after which first reducer should have started
We will find the reducer task with the longest runtime ( task_runtime_max) and the task which finished last ( finish_time_last ) 
The total wait time of the job due to reducer tasks would be: 
reducer_wait_time = finish_time_last - ( ideal_start_time + task_runtime_max)

启发式算法

Map-Reduce

Mapper数据倾斜

Mapper数据倾斜启发式算法能够显示作业是否发生数据倾斜。启发式算法会将所有Mapper分成两组，第一组的平均值会小于第二组。
例如，第一组有900个Mapper作业，每个Mapper作业平均数据量为7MB，而另一份包含1200个Mapper作业，且每个Mapper作业的平均数据量是500MB。

计算

首先通过递归算法计算两组平均内存消耗，来评估作业的等级。其误差为两组平均内存消耗的差除以这俩组最小的平均内存消耗的差的值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

Let us define the following variables,
    deviation: the deviation in input bytes between two groups
    num_of_tasks: the number of map tasks
    file_size: the average input size of the larger group
    num_tasks_severity: List of severity thresholds for the number of tasks. e.g., num_tasks_severity = {10, 20, 50, 100}
    deviation_severity: List of severity threshold values for the deviation of input bytes between two groups. e.g., deviation_severity: {2, 4, 8, 16}
    files_severity: The severity threshold values for the fraction of HDFS block size. e.g. files_severity = { ⅛, ¼, ½, 1}
Let us define the following functions,
    func avg(x): returns the average of a list x
    func len(x): returns the length of a list x
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
We’ll compute two groups recursively based on average memory consumed by them. 
Let us call the two groups: group_1 and group_2
Without loss of generality, let us assume that,
    avg(group_1) > avg(group_2) and len(group_1)< len(group_2) then,
    deviation = avg(group_1) - avg(group_2) / min(avg(group_1)) - avg(group_2))
    file_size = avg(group_1)
    num_of_tasks = len(group_0)
The overall severity of the heuristic can be computed as,
    severity = min(
        getSeverity(deviation, deviation_severity)
        , getSeverity(file_size,files_severity)
        , getSeverity(num_of_tasks,num_tasks_severity)
    )
    
---
误差（deviation）：分成两部分后输入数据量的误差
作业数量（num_of_tasks）：map作业的数量
文件大小（file_size）：较大的那部分的平均输入数据量的大小
作业数量的严重度（num_tasks_severity）：一个List包含了作业数量的严重度阈值，例如num_tasks_severity = {10, 20, 50, 100}
误差严重度（deviation severity）：一个List包含了两部分Mapper作业输入数据差值的严重度阈值，例如deviation_severity: {2, 4, 8, 16}
文件严重度（files_severity）：一个List包含了文件大小占HDFS块大小比例的严重度阈值，例如files_severity = { ⅛, ¼, ½, 1}
然后定义如下的方法，
方法 avg(x)：返回List x的平均值
方法 len(x)：返回List x的长度大小
方法 min(x,y)：返回x和y中较小的一个
方法 getSeverity(x,y)：比较x和y中的严重度阈值，返回严重度的值
接下来，根据两个部分的平均内存消耗，进行递归计算。
假设分成的两部分分别为group_1和group_2
为了不失一般性，假设 
avg(group_1) > ave(group_2) and len(group_1) < len(group_2)
以及
deviation = avg(group_1) - avg(group_2) / min(avg(group_1) - avg(group_2))
file_size = avg(group_1)
num_of_tasks = len(group_0)
启发式算法的严重度可以通过下面的方法来计算：
severity = min(getSeverity(deviation, deviation_severity),getSeverity(file_size,files_severity),getSeverity(num_of_tasks,num_tasks_severity))

参数配置

阈值参数deviation_severity、num_tasks_severity和files_severity能够简单的进行配置。如果想进一步了解如何配置这些参数，可以点击这里进行查看。

Mapper GC

Mapper GC会分析任务的GC效率。它会计算出GC时间占所有CPU时间的百分比。

计算

启发式算法对Mapper GC严重度的计算按照如下过程进行。首先，计算出所有作业的平均的CPU使用时间、平均运行时间以及平均垃圾回收消耗的时间。我们要计算Mapper GC严重度的最小值，这个值可以通过平均运行时间和平均垃圾回收时间占平均CPU总消耗时间的比例来计算。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Let us define the following variables:
    avg_gc_time: average time spent garbage collecting
    avg_cpu_time: average cpu time of all the tasks
    avg_runtime: average runtime of all the tasks
    gc_cpu_ratio: avg_gc_time/ avg_cpu_time
    gc_ratio_severity: List of severity threshold values for the ratio of  avg_gc_time to avg_cpu_time.
    runtime_severity: List of severity threshold values for the avg_runtime.
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity of the heuristic can then be computed as,
    severity = min(getSeverity(avg_runtime, runtime_severity), getSeverity(gc_cpu_ratio, gc_ratio_severity)

参数配置

阈值参数gc_ratio_severity和runtime_severity也是可以简单配置的。如果想进一步了解如何配置这些参数，可以参考这里。

Mapper内存消耗

此部分指标用来检查mapper的内存消耗。他会检查任务的消耗内存与容器请求到的内存比例。消耗的内存指任务最大消耗物理内存快照的平均值。容器请求的内存是作业mapreduce.map/reduce.memory.mb的配置值，是作业能请求到的最大物理内存。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Let us define the following variables,
    avg_physical_memory: Average of the physical memories of all tasks.
    container_memory: Container memory
    container_memory_severity: List of threshold values for the average container memory of the tasks.
    memory_ratio_severity: List of threshold values for the ratio of avg_plysical_memory to container_memory
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity can then be computed as,
    severity = min(getSeverity(avg_physical_memory/container_memory, memory_ratio_severity)
               , getSeverity(container_memory,container_memory_severity)
              )

参数配置

阈值参数container_memory_severity和memory_ratio_severity也是可以简单配置的。如果想进一步了解如何配置这些参数，可以参考这里。

Mapper的运行速度

这部分分析Mapper代码的运行效率。通过这些分析可以知道mapper是否受限于CPU，或者处理的数据量过大。这个分析能够分析mapper运行速度快慢和处理的数据量大小之间的关系。

计算

这个启发式算法的严重度值，是mapper作业的运行速度的严重度和mapper作业的运行时间严重度中较小的一个。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Let us define the following variables,
    median_speed: median of speeds of all the mappers. The speeds of mappers are found by taking the ratio of input bytes to runtime.
    median_size: median of size of all the mappers
    median_runtime: median of runtime of all the mappers.
    disk_speed_severity: List of threshold values for the median_speed.
    runtime_severity: List of severity threshold values for median_runtime.
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity of the heuristic can then be computed as,
    severity = min(getSeverity(median_speed, disk_speed_severity), getSeverity(median_runtime, median_runtime_severity)

参数配置

阈值参数disk_speed_severity和runtime_severity可以很简单的配置。如果想进一步的了解这些参数配置，可以点击这里查看。

Mapper溢出

这个启发式算法通过分析磁盘I/O来评判mapper的性能。mapper溢出比例（溢出的记录数/总输出的记录数）是衡量mapper性能的一个重要指标：如果这个值接近2，表示几乎每个记录都溢出了，并临时写到磁盘两次（其中一次发生在内存排序缓存溢出时，另一次发生在合并所有溢出的块时）。当这些发生时表明mapper输入输出的数据量过大了。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Let us define the following parameters,
    total_spills: The sum of spills from all the map tasks.
    total_output_records: The sum of output records from all the map tasks.
    num_tasks: Total number of tasks.
    ratio_spills: total_spills/ total_output_records
    spill_severity: List of the threshold values for ratio_spills
    num_tasks_severity: List of threshold values for total number of tasks.
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity of the heuristic can then be computed as,
severity = min(getSeverity(ratio_spills, spill_severity), getSeverity(num_tasks, num_tasks_severity)

参数配置

阈值spill_severity和num_tasks_severity可以简单的进行配置。如果想进一步了解配置参数的详细信息，可以点击这里查看。 here.

Mapper运行时间

这部分分析mapper的数量是否合适。通过分析结果，我们可以更好的优化任务中mapper的数量这个参数设置。有以下两种情况发生时，这个参数就需要优化了：

• Mapper的运行时间很短。通常作业在以下情况下出现：
  • mapper数量过多
  • mapper的平均运行时间很短
  • 文件太小
• 大文件或不可分割文件块，通常作业在以下情况下出现：
  • mapper数量太少
  • mapper的平均运行时间太长
  • 文件过大 (个别达到 GB 级别)

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Let us define the following variables,
    avg_size: average size of input data for all the mappers
    avg_time: average of runtime of all the tasks.
    num_tasks: total number of tasks.
    short_runtime_severity: The list of threshold values for tasks with short runtime
    long_runtime_severity: The list of threshold values for tasks with long runtime.
    num_tasks_severity: The list of threshold values for number of tasks.
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity of the heuristic can then be computed as,
    short_task_severity = min(getSeverity(avg_time,short_runtime_severity), getSeverity(num_tasks, num_tasks_severity))
    severity = max(getSeverity(avg_size, long_runtime_severity), short_task_severity)

参数配置

阈值short_runtime_severity 、long_runtime_severity以及num_tasks_severity可以很简单的配置。如果想进一步了解参数配置的详细信息，可以点击这里查看。

Reducer数据倾斜

这部分分析每个Reduce中的数据是否存在倾斜情况。这部分分析能够发现Reducer中是否存在这种情况，将Reduce分为两部分，其中一部分的输入数据量是否明显大于另一部分的输入数据量。

计算

首先通过递归算法计算均值并基于每个组消耗的平均内存消耗将任务划分为两组来评估该算法的等级。误差表示为两个部分Reducer的平均内存消耗之差除以两个部分最小内存消耗之差得到的比例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Let us define the following variables:
  deviation: deviation in input bytes between two groups
  num_of_tasks: number of reduce tasks
  file_size: average of larger group
  num_tasks_severity: List of severity threshold values for the number of tasks.
  e.g. num_tasks_severity = {10,20,50,100}
  deviation_severity: List of severity threshold values for the deviation of input bytes between two groups.
  e.g. deviation_severity = {2,4,8,16}
  files_severity: The severity threshold values for the fraction of HDFS block size
  e.g. files_severity = { ⅛, ¼, ½, 1}
Let us define the following functions:
  func avg(x): returns the average of a list x
  func len(x): returns the length of a list x
  func min(x,y): returns minimum of x and y
  func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
We’ll compute two groups recursively based on average memory consumed by them. 
Let us call the two groups: group_1 and group_2
Without loss of generality, let us assume that:
  avg(group_1) > avg(group_2) and len(group_1)< len(group_2) then,
  deviation = avg(group_1) - avg(group_2) / min(avg(group_1)) - avg(group_2))
  file_size = avg(group_1)
  num_of_tasks = len(group_0)
The overall severity of the heuristic can be computed as, 
  severity = min(getSeverity(deviation,deviation_severity),getSeverity(file_size,files_severity),getSeverity(num_of_tasks,num_tasks_severity))

参数配置

阈值deviation_severity、num_tasks_severity和files_severity，可以很简单的进行配置。如果想进一步了解这些参数的配置，可以点击这里查看。

Reducer GC

这部分分析任务的GC效率，能够计算并告诉我们GC时间占所用CPU时间的比例。

计算

首先，会计算出所有任务的平均CPU消耗时间、平均运行时间以及平均垃圾回收所消耗的时间。然后，算法会根据平均运行时间以及垃圾回收时间占平均CPU时间的比值来计算出最低的严重等级。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Let us define the following variables:
    avg_gc_time: average time spent garbage collecting
    avg_cpu_time: average cpu time of all the tasks
    avg_runtime: average runtime of all the tasks
    gc_cpu_ratio: avg_gc_time/ avg_cpu_time
    gc_ratio_severity: List of severity threshold values for the ratio of  avg_gc_time to avg_cpu_time.
    runtime_severity: List of severity threshold values for the avg_runtime.
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity of the heuristic can then be computed as,
    severity = min(getSeverity(avg_runtime, runtime_severity), getSeverity(gc_cpu_ratio, gc_ratio_severity)

参数配置

阈值gc_ratio_severity、runtime_severity可以很简单的配置，如果想进一步了解参数配置的详细过程，可以点击这里查看。

Reducer内存消耗

这部分分析显示了任务的内存利用率。算法会比较作业消耗的内存以及容器要求的内存分配。消耗的内存是指每个作业消耗的最大内存的平均值。容器需求的内存是指任务配置的mapreduce.map/reduce.memory.mb，也就是任务能够使用最大物理内存。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Let us define the following variables,
    avg_physical_memory: Average of the physical memories of all tasks.
    container_memory: Container memory
    container_memory_severity: List of threshold values for the average container memory of the tasks.
    memory_ratio_severity: List of threshold values for the ratio of avg_physical_memory to container_memory
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity can then be computed as,
    severity = min(getSeverity(avg_physical_memory/container_memory, memory_ratio_severity)
               , getSeverity(container_memory,container_memory_severity)
              )

参数配置

阈值container_memory_severity和memory_ratio_severity可以简单的进行配置。如果想进一步了解配置参数的详细信息，可以点击这里查看。

Reducer运行时间

这部分分析Reducer的运行效率，可以帮助我们更好的配置任务中reducer的数量。当出现以下两种情况时，说明Reducer的数量需要进行调优：

• Reducer过多，hadoop任务可能的表现是：
  • Reducer数量过多
  • Reducer的运行时间很短
• Reducer过少，hadoop任务可能的表现是：
  • Reducer数量过少
  • Reducer运行时间很长

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Let us define the following variables,
    avg_size: average size of input data for all the mappers
    avg_time: average of runtime of all the tasks.
    num_tasks: total number of tasks.
    short_runtime_severity: The list of threshold values for tasks with short runtime
    long_runtime_severity: The list of threshold values for tasks with long runtime.
    num_tasks_severity: The number of tasks.
Let us define the following functions,
    func min(x,y): returns minimum of x and y
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity of the heuristic can then be computed as,
    short_task_severity = min(getSeverity(avg_time,short_runtime_severity), getSeverity(num_tasks, num_tasks_severity))
    severity = max(getSeverity(avg_size, long_runtime_severity), short_task_severity)

参数配置

阈值参数short_runtime_severity、long_runtime_severity以及num_tasks_severity可以很简单的配置，如果想进一步了解参数配置的详细过程，可以点击这里查看。

清洗&排序

这部分分析reducer消耗的总时间以及reducer在进行清洗和排序时消耗的时间，通过这些分析，可以评估reducer的执行效率。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Let’s define following variables,
    avg_exec_time: average time spent in execution by all the tasks.
    avg_shuffle_time: average time spent in shuffling.
    avg_sort_time: average time spent in sorting.
    runtime_ratio_severity: List of threshold values for the ratio of twice of average shuffle or sort time to average execution time.
    runtime_severity: List of threshold values for the runtime for shuffle or sort stages. 
The overall severity can then be found as,
severity = max(shuffle_severity, sort_severity)
where shuffle_severity and sort_severity can be found as: 
shuffle_severity = min(getSeverity(avg_shuffle_time, runtime_severity), getSeverity(avg_shuffle_time*2/avg_exec_time, runtime_ratio_severity))
sort_severity = min(getSeverity(avg_sort_time, runtime_severity), getSeverity(avg_sort_time*2/avg_exec_time, runtime_ratio_severity))

参数配置

阈值参数avg_exec_time、avg_shuffle_time和avg_sort_time可以很简单的进行配置。更多关于参数配置的相信信息可以点击这里查看。

Spark

Spark的事件日志限制

Spark事件日志处理器当前无法处理很大的日志文件。Dr-Elephant需要花很长的时间去处理一个很大的Spark时间日志文件，期间很可能会影响Dr-Elephant本身的稳定运行。因此，目前我们设置了一个日志大小限制（100MB），如果超过这个大小，会新起一个进程去处理这个日志。

计算

如果数据被限流了，那么启发式算法将评估为最严重等级CRITICAL，否则，就没有评估等级。

Spark负载均衡处理器

和Map/Reduce任务的执行机制不同，Spark应用在启动后会一次性分配它所需要的所有资源，直到整个任务结束才会释放这些资源。根据这个机制，对Spark的处理器的负载均衡就显得非常重要，可以避免集群中个别节点压力过大。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Let us define the following variables:
    
    peak_memory: List of peak memories for all executors
    durations: List of durations of all executors
    inputBytes: List of input bytes of all executors
    outputBytes: List of output bytes of all executors.
    looser_metric_deviation_severity: List of threshold values for deviation severity, loose bounds.
    metric_deviation_severity: List of threshold values for deviation severity, tight bounds. 
Let us define the following functions:
    func getDeviation(x): returns max(|maximum-avg|, |minimum-avg|)/avg, where
        x = list of values
        maximum = maximum of values in x
        minimum = minimum of values in x
        avg = average of values in x
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
    func max(x,y): returns the maximum value of x and y.
    func Min(l): returns the minimum of a list l.
The overall severity can be found as,
    severity = Min( getSeverity(getDeviation(peak_memory), looser_metric_deviation_severity), 
               getSeverity(getDeviation(durations),  metric_deviation_severity),
               getSeverity(getDeviation(inputBytes), metric_deviation_severity),
               getSeverity(getDeviation(outputBytes), looser_metric_deviation_severity). 
               )

参数配置

阈值参数looser_metric_deviation_severity和metric_deviation_severity可以简单的进行配置。如果想进一步了解参数配置的详细过程，可以点击这里查看。

Spark任务运行时间

这部分启发式算法对Spark任务的运行时间进行调优分析。每个Spark应用程序可以拆分成多个任务，每个任务又可以拆分成多个运行阶段。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Let us define the following variables,
    avg_job_failure_rate: Average job failure rate
    avg_job_failure_rate_severity: List of threshold values for average job failure rate
Let us define the following variables for each job,
    single_job_failure_rate: Failure rate of a single job
    single_job_failure_rate_severity: List of threshold values for single job failure rate.
The severity of the job can be found as maximum of single_job_failure_rate_severity for all jobs and avg_job_failure_rate_severity.
i.e. severity = max(getSeverity(single_job_failure_rate, single_job_failure_rate_severity),
                    getSeverity(avg_job_failure_rate, avg_job_failure_rate_severity)
                )
where single_job_failure_rate is computed for all the jobs.

参数配置

阈值参数single_job_failure_rate_severity和avg_job_failure_rate_severity可以很简单的进行配置。更多详细信息，可以点击这里查看。

Spark内存限制

目前，Spark应用程序缺少动态资源分配的功能。与Map/Reduce任务不同，能够为每个map/reduce进程分配所需要的资源，并且在执行过程中逐步释放占用的资源。而Spark在应用程序执行时，会一次性的申请所需要的所有资源，直到任务结束才释放这些资源。过多的内存使用会对集群节点的稳定性产生影响。所以，我们需要限制Spark应用程序能使用的最大内存比例。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Let us define the following variables,
    total_executor_memory: total memory of all the executors
    total_storage_memory: total memory allocated for storage by all the executors
    total_driver_memory: total driver memory allocated
    peak_memory: total memory used at peak
    mem_utilization_severity: The list of threshold values for the memory utilization.
    total_memory_severity_in_tb: The list of threshold values for total memory.
Let us define the following functions,
    func max(x,y): Returns maximum of x and y.
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity can then be computed as,
    severity = max(getSeverity(total_executor_memory,total_memory_severity_in_tb),
                   getSeverity(peak_memory/total_storage_memory, mem_utilization_severity)
               )

参数配置

阈值参数total_memory_severity_in_tb和mem_utilization_severity可以很简单的配置。进一步了解，可以点击这里查看。

Spark阶段运行时间

与Spark任务运行时间一样，Spark应用程序可以分为多个任务，每个任务又可以分为多个运行阶段。

计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Let us define the following variable for each spark job,
    stage_failure_rate: The stage failure rate of the job
    stagge_failure_rate_severity: The list of threshold values for stage failure rate.
Let us define the following variables for each stage of a spark job,
    task_failure_rate: The task failure rate of the stage
    runtime: The runtime of a single stage
    single_stage_tasks_failure_rate_severity: The list of threshold values for task failure of a stage
    stage_runtime_severity_in_min: The list of threshold values for stage runtime.
Let us define the following functions,
    func max(x,y): returns the maximum value of x and y.
    func getSeverity(x,y): Compares value x with severity threshold values in y and returns the severity.
The overall severity can be found as:
    severity_stage = max(getSeverity(task_failure_rate, single_stage_tasks_faioure_rate_severity),
                   getSeverity(runtime, stage_runtime_severity_in_min)
               )
    severity_job = getSeverity(stage_failure_rate,stage_failure_rate_severity)
    severity = max(severity_stage, severity_job)
where task_failure_rate is computed for all the tasks.

参数配置

阈值参数single_stage_tasks_failure_rate_severity、stage_runtime_severity_in_min和stage_failure_rate_severity可以很简单的配置。进一步了解，请点击这里。

本章篇幅较长，一些专有名词及参数功能，可以在Dr-Elephant的Dashboard中查。

仪表盘

Dr.Elephant的启动首页正如你所见

组件

集群统计信息

这个页面包含了集群最近的统计信息。列出了最近24小时分析过的作业数量，可进行优化的作业数量和待优化的作业数量。

最新分析

这一部分列出了最近一段时间分析的任务

搜索页

搜索页允许你通过一下选项过滤搜索作业和工作流：

• 作业ID：输入作业的ID，可以搜索一个特定的任务或者任务流。返回作业详情页面。
• 工作流执行ID/URL：使用作业流的执行ID或者URL（例如Azkaban的作业流），可以搜索到被这个作业流触发的所有任务。
• 用户名：提交任务的用户名
• 任务类型：搜索特定类型的所有任务
• 待优化等级：每个任务被Dr.Elephant诊断完以后，就会生成一份详细的诊断报告，其中就包括该任务的待优化等级。我们可以基于待优化等级搜索任务。例如，我们在待优化等级输入框中输入”severe（严重)”，搜索结果就会包含至少被一个启发式算法诊断为”severe”的所有任务。在该例子中，搜索时还可以同时指定启发式算法，那么搜索结果就只包含被该启发式算法诊断为”severe”的所有任务。
• 任务结束日期：我们也可以使用任务结束时间作为搜索条件。在”from”和”to”这两个输入框中，可以分别设定起始时间和结束时间。这个时间段是一个左闭右开的区间 （[from, to)），包含from这个时间点，但不包含to这个时间点。
  这些所有的搜索字段都可以组合使用。例如，我们可以指定”用户名”为”user1”，同时，指定”待优化等级”为”critical（危急）”，点击搜索，会返回所有的user1提交的任务中待优化等级为”critical”的任务。

作业详情

点击控制台或者搜索页中的任意一个作业，可以看到作业详情。

组件

1. 任务追踪链接（Jobtracker）：这个链接指向任务的追踪页面。在这个页面上，可以看到任务的详细信息、日志、map和reduce的task信息。
2. 任务执行链接（Job execution）：这个链接指向任务在调度器中的执行页面。例如，在Azkaban调度器上，指向这个任务的执行链接。
3. 任务定义（Job definition）：这个链接指向任务在调度器中的定义页面。例如，在Azkaban调度器上，指向这个任务的属性页面。
4. 任务流执行链接（Flow execution）：这个链接指向整个任务流的执行页面。例如，在Azkaban调度器上，指向这个任务流的执行页面。
5. 任务流定义（Flow definition）：同前面的任务定义（Job definition）。
6. 任务历史（Job history）：这个链接指向任务历史页面。
7. 任务流历史（Flow history）：这个链接指向任务流历史页。
8. 度量信息（Metrics）：这个链接显示Dr.Elephant每项作业的计算指标，目前显示使用的资源，浪费的资源，运行时间和等待时间信息。

启发式算法结果报告

当一个作业被Dr.Elephant分析时，Dr.Elephant会运行所有的启发式算法来分析这个任务。每个启发式算法都会对该任务计算出一个待优化等级，这个等级可能会是”无（none）”、”中等（moderate）”、”严重（severe）”或者”危急（critical）”。在每个任务的详细分析页面，都会展示它的待优化等级以及其他分析结果。如果任务的待优化等级不是”无（none）”时，表明某些启发式算法的诊断结果认为这个任务需要优化，同时也会提供相应的链接（帮助页面）来阐述该启发式算法提出的优化建议。开发者可以通过这个链接来帮助自己优化任务。

任务比较

通过这个比较页面，你可以比较两个不同的作业流执行情况。当我们比较两次作业流的执行时，相同的作业会做出比较并在顶部展示。其他的不同的作业，会按照作业流的顺序依次在下面展示。

历史作业页面

历史作业页面展示了每个特定任务近期所有执行情况的比较图

启发式视图

度量视图

组件

搜索框

我们可以在历史任务页面的搜索框中输入任务的ID或者Azkaban的URL来搜索特定的任务。点击搜索，就会得到该任务的历史执行情况的展示。在前面提到的任务详情页面中，也有链接可以跳转到该任务的历史执行情况页面。这个页面中展示的折线图代表了该任务在历史上每次执行性能的一个打分。

启发式图表（性能得分图）

执行性能打分图是一个折线图。X轴代表时间，Y轴代表分数。当我们将鼠标停留在折线图中的某个点上时，会看到有弹框弹出。弹框中列出了该任务在本次执行中造成性能问题的Top 3的阶段。执行性能的分数是通过一个简单的公式计算出来的，越低的分数表明该任务执行性能越好。

度量图（耗时和资源）

耗时和资源图表，X轴代表时间，Y轴代表资源。当鼠标悬停在其中一个数据点上时，该特定执行的指标会显示为弹出窗口。

表格展示-启发式算法

在性能打分折线图的下方，可以看到该任务流在近期每次执行的表格展示。第一列是每次执行的时间，点击每个时间，都能跳转到任务流在调度器中的执行详情页面。接下来的每一列都代表了任务流执行中的一个任务。在图表中的每个任务阶段，都包含了若干种颜色的圆点。当我们将鼠标停留在某个任意颜色的圆点上时，会弹出一个弹框展示所有的启发式算法，以及这些算法对该任务的待优化等级的分析结果。

表格展示-度量标准

在图表下方，您可以看到图表数据点数据的表格展示。每行代表作业的特定执行，列代表作业的mapreduce阶段。每个mapreduce列都分为更多列，每列代表一个度量。

历史任务流页面

在历史任务流页面，展示了每个特定任务流近期所有执行情况的比较。

启发式算法视图

度量视图

组件

搜索框

我们可以在历史任务页面的搜索框中输入任务的ID或者Azkaban的URL来搜索特定的任务。点击搜索，就会得到该任务的历史执行情况的展示。在前面提到的任务详情页面中，也有链接可以跳转到该任务的历史执行情况页面。这个页面中展示的折线图代表了该任务在历史上每次执行性能的一个打分。

启发式图表（性能得分图）

执行性能打分图是一个折线图。X轴代表时间，Y轴代表分数。当我们将鼠标停留在折线图中的某个点上时，会看到有弹框弹出。弹框中列出了该任务在本次执行中造成性能问题的Top 3的阶段。执行性能的分数是通过一个简单的公式计算出来的，越低的分数表明该任务执行性能越好。

度量图（耗时和资源）

耗时和资源图表，X轴代表时间，Y轴代表资源。当鼠标悬停在其中一个数据点上时，该特定执行的指标会显示为弹出窗口。

表格展示-启发式算法

在性能打分折线图的下方，可以看到该任务流在近期每次执行的表格展示。第一列是每次执行的时间，点击每个时间，都能跳转到任务流在调度器中的执行详情页面。接下来的每一列都代表了任务流执行中的一个任务。在图表中的每个任务阶段，都包含了若干种颜色的圆点。当我们将鼠标停留在某个任意颜色的圆点上时，会弹出一个弹框展示所有的启发式算法，以及这些算法对该任务的待优化等级的分析结果。

帮助

在Dr.Elephant UI首页点击Help可以跳转到帮助页面。还可以通过其他方式跳转到帮助页面，比如通过点击UI中任务详情页的explain链接（当启发式算法诊断结果为moderate、severe或者critical时出现这个链接）。在帮助页面，可以看到所有的启发式算法的介绍，以及这些启发式算法给出的优化建议。点击某个特定的启发式算法，可以看到该启发式算法得出的详细优化建议。上面图片中，展示了Mapper memory启发式算法给出的优化建议。

待优化等级

待优化等级代表了该任务的性能，表明了该任务在性能上需要优化的迫切程度。我们通过参数可以配置每个启发式算法的一些阈值，启发式算法给每个任务的诊断分析，都会得出一个待优化等级。待优化等级共有5个，下面按照待优化的迫切性降序排序给出：CRITICAL > SEVERE > MODERATE > LOW > NONE

请按照快速安装说明操作here.

先决条件

Play/Activator

Hadoop/Spark on Yarn

为了在本地部署Dr.Elephant测试，你需要安装Hadoop(version 2.x)或者Spark(Yarn mode, version > 1.4.0)，以及资源管理服务和历史作业服务（可以用伪分布式）。关于伪分布式模式在YARN上运行MapReduce作业相关说明可以在这里找到。

如果还没设置环境变量，可以导入HADOOP_HOME变量

1
2

$> export HADOOP_HOME=/path/to/hadoop/home
$> export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop

将hadoop的home目录添加到系统变量下，因为Dr.Elephant会调用到hadoop的某些类库

1

$> export PATH=$HADOOP_HOME/bin:$PATH

确保历史作业服务器正常运行，因为Dr.Elephant需要依赖他运行

1

$> $HADOOP_HOME/sbin/mr-jobhistory-daemon.sh start historyserver

数据库

Dr.Elephant需要一个数据库来存储相关祖业信息和分析结果数据

本地配置并启动一个mysql。可以从以下链接获取最新版的mysql：https://www.mysql.com/downloads/。`Dr.Elephant`支持`mysql 5.5+以上的版本，有啥问题可以去Alex (wget.null@gmail.com) 的Google小组讨论。创建一个名为drelephant`的库。

1
2

$> mysql -u root -p
mysql> create database drelephant

可以在Dr.Elephant的配置文件app-conf/elephant.conf中配置数据库的url、数据库名称、用户名和密码。

使用其他数据库
目前，Dr.Elephant默认是支持MySQL数据库。但我们可以在evolution files中看到DDL声明。如果想配置其他的数据库，可以参考这里进行配置。

测试Dr.Elephant

你可以通过调用编译脚本来测试，脚本会进行所有单元测试。

项目结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

app                             → Contains all the source files
 └ com.linkedin.drelepahnt      → Application Daemons
 └ org.apache.spark             → Spark Support
 └ controllers                  → Controller logic
 └ models                       → Includes models that Map to DB
 └ views                        → Page templates
app-conf                        → Application Configurations
 └ elephant.conf                → Port, DB, Keytab and other JVM Configurations (Overrides application.conf)
 └ FetcherConf.xml              → Fetcher Configurations
 └ HeuristicConf.xml            → Heuristic Configurations
 └ JobTypeConf.xml              → JobType Configurations
conf                            → Configurations files
 └ evolutions                   → DB Schema
 └ application.conf             → Main configuration file
 └ log4j.properties             → log configuration file
 └ routes                       → Routes definition
images
 └ wiki                         → Contains the images used in the wiki documentation
public                          → Public assets
 └ assets                       → Library files
 └ css                          → CSS files
 └ images                       → Image files
 └ js                           → Javascript files
scripts
 └ start.sh                     → Starts Dr. Elephant
 └ stop.sh                      → Stops Dr. Elephant
test                            → Source folder for unit tests
compile.sh                      → Compiles the application

启发式算法

Dr.Elephant已经为MapReduce和Spark集成了一系列的启发式算法。有关这些算法的详细信息，请参阅启发式算法指南。这些算法都是可插拔式的模块，可以很简单的配置好。

添加新的启发式算法

1. 你可以添加自定义的算法到Dr.Elephant中。
2. 创建新的启发式算法，并完成测试
3. 为自定义的启发式算法创建一个新的view页，例如helpMapperSpill.scala.html
4. 在HeuristicConf.xml文件中添加该启发式算法的详情
5. HeuristicConf.xml文件应该包含下列内容：
   • applicationtype：应用程序类型，是MapReduce还是spark
   • heuristicname：算法名称
   • classname：类名全称
   • viewname：view页全称
   • hadoopversions：该算法匹配的hadoop版本号
6. 运行Dr.Elephant，他应该包含你新添加的算法了

HeuristicConf.xml文件示例

1
2
3
4
5
6

<heuristic>
<applicationtype>mapreduce</applicationtype>
<heuristicname>Mapper GC</heuristicname>
<classname>com.linkedin.drelephant.mapreduce.heuristics.MapperGCHeuristic</classname>
<viewname>views.html.help.mapreduce.helpGC</viewname>
</heuristic>

配置启发式算法

如果你想要覆盖启发式算法中用到的关于严重性指标的的阈值，你可以在HeuristicConf.xml文件中指定其值，例子如下。
配置严重性阈值

1
2
3
4
5
6
7
8
9
10
11

<heuristic>
<applicationtype>mapreduce</applicationtype>
<heuristicname>Mapper Data Skew</heuristicname>
<classname>com.linkedin.drelephant.mapreduce.heuristics.MapperDataSkewHeuristic</classname>
<viewname>views.html.help.mapreduce.helpMapperDataSkew</viewname>
<params>
  <num_tasks_severity>10, 50, 100, 200</num_tasks_severity>
  <deviation_severity>2, 4, 8, 16</deviation_severity>
  <files_severity>1/8, 1/4, 1/2, 1</files_severity>
</params>
</heuristic>

调度器

如今，Dr.Elephant支持3种工作流调度器。他们是Azkaban，Airflow和Oozie。默认情况下，这些调度器都是可用的，除了Airflow和Oozie需要一些配置外，一般都是开箱即用。

调度器配置

调度器和他们所有的参数都在app-conf目录下的SchedulerConf.xml文件中配置。
通过下面的示例SchedulerConf.xml文件，了解调度器相应的配置和属性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<!-- Scheduler configurations -->
<schedulers>
    <scheduler>
        <name>azkaban</name>
        <classname>com.linkedin.drelephant.schedulers.AzkabanScheduler</classname>
    </scheduler>
    <scheduler>
        <name>airflow</name>
        <classname>com.linkedin.drelephant.schedulers.AirflowScheduler</classname>
        <params>
            <airflowbaseurl>http://localhost:8000</airflowbaseurl>
        </params>
    </scheduler>
    <scheduler>
        <name>oozie</name>
        <classname>com.linkedin.drelephant.schedulers.OozieScheduler</classname>
        <params>
            <!-- URL of oozie host -->
            <oozie_api_url>http://localhost:11000/oozie</oozie_api_url>
            <!-- ### Non mandatory properties ###
            ### choose authentication method
            <oozie_auth_option>KERBEROS/SIMPLE</oozie_auth_option>
            ### override oozie console url with a template (only parameter will be the id)
            <oozie_job_url_template></oozie_job_url_template>
            <oozie_job_exec_url_template></oozie_job_exec_url_template>
            ### (if scheduled jobs are expected make sure to add following templates since oozie doesn't provide their URLS on server v4.1.0)
            <oozie_workflow_url_template>http://localhost:11000/oozie/?job=%s</oozie_workflow_url_template>
            <oozie_workflow_exec_url_template>http://localhost:11000/oozie/?job=%s</oozie_workflow_exec_url_template>
            ### Use true if you can assure all app names are unique.
            ### When true dr-elephant will unit all coordinator runs (in case of coordinator killed and then run again)
            <oozie_app_name_uniqueness>false</oozie_app_name_uniqueness>
            -->
        </params>
    </scheduler>
</schedulers>

贡献新的调度器

为了充分利用Dr. Elephant的全部功能，需要提供以下4个ID

1. 作业定义ID：整个作业流程中定义的唯一ID。通过过滤这个ID可以查询所有历史作业
2. 作业执行ID：作业执行的唯一ID
3. 工作流定义ID：独立于任何执行的对整个流程的唯一ID
4. 工作流执行ID：特定流程执行的唯一ID

Dr. Elephant希望通过上述ID能与任何调度器对接。没有这些ID，Dr. Elephant无法为Azkaban提供集成。例如，如果没有提供作业定义Id，那么Dr. Elephant将无法捕获作业的历史数据。同样，如果没有提供Flow定义Id，则无法捕获工作流的历史记录。如果没有上述所有链接，Dr. Elephant只能在执行过程中（Mapreduce作业级别）显示作业的性能数据。

除了上述的4个ID之外，Dr. Elephant还需要一个可选的工作名称和4个可选链接，这些链接将帮助用户轻松的从Dr. Elephant跳转到相应的作业应用程序。
请注意，这不会影响Dr. Elephant的功能。

1. Flow Definition Url
2. Flow Execution Url
3. Job Definition Url
4. Job Execution Url

打分器

在Dr.Elephant中，通过启发式算法来分析运行完成的任务，会得到一个打分。这个分数的计算方法比较简单，可以通过将待优化等级的值乘以作业(task)数量。

1
2
3
4
5

int score = 0;
if (severity != Severity.NONE && severity != Severity.LOW) {
    score = severity.getValue() * tasks;
}
return score;

我们定义下列打分类型：

• 作业得分：所有作业的待优化等级数值之和
• 任务得分：该任务中所有的作业分数之和
• 任务流得分：该任务流中所有的任务分数之和

Step 1：在GitHub上注册一个账号，并fork一份Dr. Elephant项目代码。

Step 2：检出代码。

1
2

$> git clone https://github.com/<username>/dr-elephant
$> cd dr-elephant*

Step 3：先决条件：

• 你必须先安装play或者activator命令行。下载activatorzip包https://downloads.typesafe.com/typesafe-activator/1.3.12/typesafe-activator-1.3.12.zip ，解压并添加activator命令到你自己的环境变量$PATH。对于老版的play，你需要添加paly命令并替换activator。

1
2

export ACTIVATOR_HOME=/path/to/unzipped/activator
export PATH=$ACTIVATOR_HOME/bin:$PATH

• Dr.Elephant将分析数据结果存储在MySQL数据中。如果你还没装，请先安装好MySQL。（推荐5.5以上版本）

• 为了正常使用Dr. ElephantUI界面，需要安装npm及其依赖

  1 2 3

  sudo yum install npm sudo npm install -g bower cd web; bower install; cd ..

• 最后，你还需要安装好Hadoop或者Spark。

Step 4：（可选，Beta阶段）如果你想尝试自动优化的新功能，请按照以下步骤来操作。（更多详情：https://github.com/linkedin/dr-elephant/wiki/Auto-Tuning ）

• 修改app-conf/AutoTuningConf.xml中autotuning.enabled的选项为true来启用自动优化功能
• 安装python2.6以上的版本

• 如果你想使用自定义安装的python版本：

  • 将PYTHON_PATH设置为所需要的python版本的可执行文件路径即可：

    1	$> export PYTHON_PATH=/path/to/python/executable

  • 或者注释app-conf/AutoTuningConf.xml配置文件中的python.path选项。

• 安装inspyred包：

  1 2 3 4 5 6 7 8 9

  sudo pip install inspyred ``` * 如果pip安装失败，可以从https://pip.pypa.io/en/stable/installing/ 处安装。 **Step 5：**编译`Dr. Elephant`代码并打包生产`zip`包。`Compile.sh`脚本可以带一个配置文件路径参数，其中包含要编译的Hadoop和Spark的版本信息。具体信息请参阅开发者指南。 ``` bash $> ./compile.sh [./compile.conf]

编译完成后，打包文件在dist目录下。

1
2

$> ls dist
dr-elephant*.zip

Step 6：复制打包后的程序到你打算安装Dr. Elephant的服务器上。

Step 7：在你安装Dr. Elephant的服务器上，确认以下环境变量配置好了。

1
2
3
4

$> export HADOOP_HOME=/path/to/hadoop/home
$> export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
$> export SPARK_HOME=/path/to/spark/home
$> export SPARK_CONF_DIR=/path/to/conf

Step 8：你同样需要一个存储数据的后端数据库。在elephant.conf配置文件中配置MySQL数据库的相关连接信息。

1
2
3
4
5

# Database configuration
db_url=localhost
db_name=drelephant
db_user=root
db_password=""

Step 9：如果你的群集是kerberised，则更新keytab用户和elephant.conf文件中的keytab文件位置。

Step 10：如果你是第一次运行Dr. Elephant，你需要打开evolutions功能，为此，请在elephant.conf配置文件中添加（或取消注释），-Devolutionplugin=enabled 和 -DapplyEvolutions.default=true。这将会让Dr. Elephant自动创建相关的MySQL表，下次重启程序时记得关闭这个选项。

1
2

$> vim ./app-conf/elephant.conf
jvm_props=" -Devolutionplugin=enabled -DapplyEvolutions.default=true"

Step 11：要启动Dr. Elephant，需要在运行启动脚本时指定配置文件目录。

1

$> /bin/start.sh /path/to/app-conf/directory

要验证Dr. Elephant是否启动成功，请检查dr.log文件。

1
2
3
4
5
6

$> less $DR_RELEASE/dr.log
...
play - database [default] connected at jdbc:mysql://localhost/drelephant?characterEncoding=UTF-8
application - Starting Application...
play - Application started (Prod)
play - Listening for HTTP on /0:0:0:0:0:0:0:0:8080

要分析Dr. Elephant是否正确的分析作业，请检查dr.log文件。

1

$> less $DR_RELEASE/../logs/elephant/dr_elephant.log

Step 12：一旦应用启动，你可以打开ip:port (localhost:8080)，查看UI界面。

Step 13：要停止应用，只需执行

1

$> bin/stop.sh

Dr. Elephant依赖于YARN的资源管理服务器和历史作业记录服务器，来获取作业详细信息和记录。YARN作业及其分析的详细信息将存储在当前配置的后端mysql中。因此在运行Dr. Elephant前，必须安装好MySQL和hadoop 2。
从#162开始，将不再支持JAVA 6。

集群部署Dr. Elephant

部署配置

• 将配置文件的目录复制到集群的每台机器上

• 配置环境变量$ELEPHANT_CONF_DIR指向到你的配置文件目录

  1	$> export ELEPHANT_CONF_DIR=/path/to/conf/dir

Airflow和Oozie配置

如果你使用Airflow或Oozie调度系统，则需要编辑你$ELEPHANT_CONF_DIR目录下的SchedulerConf.xml的配置文件：

• Airflow，设置airflowbaseurl配置属性指向你的Airflow服务
• Oozie，设置oozie_api_url配置属性指向你的Oozie调度服务的API地址
  • 对于Oozie可以额外设置其他跟多可选属性，有关 更多信息，请参阅SchedulerConf.xml相关文档

二进制部署

• SSH连接到集群机器

• 切换到合适的部署用户

  1	sudo -iu <user>

• 解压dr-elephant二进制包

启动/停止dr-elephant

• 进入dr-elephant根目录

• 想启动dr-elephant，请允许启动脚本。启动脚本提供了一个配置文件目录位置的可选参数。如果你已经设置好了$ELEPHANT_CONF_DIR环境变量，只需要直接启动就要，不用带任何参数。否则，需要在运行时带上配置文件目录位置的参数。

  1	./bin/start.sh [/path/to/app-conf]

• 想停止运行，

  1	./bin/stop.sh

• 要部署新版本，请务必先停止正在运行的进程

Dr. Elephant是一个Hadoop和Spark的性能监控和调优工具。它能自动采集作业的度量指标并分析他，然后以简单明了的方式展现出来。Dr. Elephant的设计思想是通过作业分析结果来指导开发者进行作业调优，从而提升开发者效率和集群资源的利用率。Dr. Elephant使用了一组可配置的插件式启发算法来分析hadoop和spark作业并提供优化建议。然后针对结果数据来建议如何调整作业。这个算法还计算了作业的许多其他度量标准，用来为集群作业优化提供了有价值的参考信息。

为什么要使用Dr.Elephant?

大多数Hadoop优化工具，不管是开源还是商业的，都被设计用来采集系统资源指标和监控集群资源信息。他们大多数专注于简化Hadoop集群的部署和管理。很少有工具来帮助用户优化Hadoop作业流的。少数的几个可用工具要么扩展性差，要么不支持快速发展的Hadoop框架。Dr. Elephant能很好支持Hadoop生态框架以及后续的新框架，同时对Spark的支持也很友好。你同时也可以通过插件的方式配置各种你喜欢的启发式算法。旨在帮助Hadoop和Spark的用户了解他们的内部工作流，并帮助他们轻松优化他们的作业。

核心功能点

• 基于自定义规则的可配置启发式插件，用于诊断作业任务
• 和Azkaban集成，并支持任何Hadoop调度框架，比如：Oozie
• 统计历史作业和工作流的性能指标
• Job级别的工作流对比
• 针对MapReduce和Spark的性能诊断
• 具有良好的扩展性，能支持各种新的任务、应用和调度器
• 提供REST API，用户能够通过API获取所有信息

快速入门

用户指南
开发者指南
管理员指南
任务优化技巧

工作原理

Dr. Elephant会定期从YARN资源管理中心拉取近期成功和失败的作业列表。每个任务的元数据信息，计数器，配置及任务信息都可以从历史作业服务器获取到。一旦获取到所有的元数据信息，Dr. Elephant就基于这些元数据运行启发式算法，并生成一份该作业的性能诊断报告。该报告会多作业进行标记并评级，分为五个级别来评定改作业存在的性能问题严重程度。

用例

在LinkedIn，开发者们用Dr. Elephant来处理许多不同的用例，包括监控他们的工作流在集群上的运行情况，通过监控分析了解为什么作业运行较慢，比较作业每次运行的区别，Dr. Elephant的绿色性能指示灯已成为作业符合运行标准的先决条件。

作业性能分析案例

Dr. Elephant的主页或者仪表盘，包含了近期所有作业分析的数据。

一旦一个作业完成运行，我们将能在仪表盘中找到他，或者通过搜索页找到他。作业搜索，可以通过作业id，作业执行的url（如果是通过调度器调度的作业，是有url的），作业的执行者，结束时间，作业类型，甚至通过作业等级来过滤搜索。

搜索结果提供了一份高级的作业分析报告，通过不同的颜色来标识不同的严重性等级用以体现作业的综合性能情况。红色表示作业有严重问题需要调优，绿色表示作业能够高效运行。

通过过滤并找到一个人的作业后，可以获取每个作业的完整报告。该报告包含每个算法的详细信息和链接，并针对改作业提供了相应的优化建议。

由于python 2和3存在不小的区别，尤其个别第三方库并不是都兼容，所以有时候我们需要在同一台服务器上运行多个不同的python版本

1.安装pyenv

(1)安装到$HOME/.pyenv目录:

1

git clone https://github.com/yyuu/pyenv.git ~/.pyenv

(2)配置环境变量

1
2

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile

(3)添加pyenv初始化到你的shell并生效

1
2
3

echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bash_profile
source ~/.bash_profile

2.安装需要的python版本

查看可安装版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

[db_dlp@prd-bigdata20 ~]$ pyenv install --list
Available versions:
  2.1.3
  2.2.3
  2.3.7
  2.4
  2.4.1
  2.4.2
  2.4.3
  2.4.4
  2.4.5
  2.4.6
  2.5
  2.5.1
  2.5.2
  2.5.3
  2.5.4
  2.5.5
  2.5.6
  2.6.6
  2.6.7
  2.6.8
  2.6.9
  2.7-dev
  2.7
  2.7.1
  2.7.2
  2.7.3
  2.7.4
  2.7.5
  2.7.6
  ...

安装：

1

pyenv install 3.6.3

卸载：

1

pyenv uninstall 3.6.3

查看已安装版本：

1
2
3

[db_dlp@prd-bigdata20 ~]$ pyenv versions
* system (set by /home/db_dlp/.pyenv/version)
  3.6.3

3.切换python版本

局部切换
python版本仅作用于指定的目录环境，切换到指定的目录下执行：

1

pyenv local 3.6.3

全局切换

1

pyenv global 3.6.3

4.pyenv安装pyhton下载安装慢的问题

使用pyenv在安装python时，由于是去python官方下载，由于总所周知的原因，经常会遇到下载缓慢的问题。
对此，可以事先下载好python包，放到~/.pyenv/cache目录即可。修改~/.pyenv/plugins/python-build/share/python-build/3.6.3文件：

1
2
3
4
5
6
7
8
9

cat ~/.pyenv/plugins/python-build/share/python-build/3.6.2
#require_gcc
install_package "openssl-1.0.2g" "https://www.openssl.org/source/openssl-1.0.2g.tar.gz#b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33" mac_openssl --if has_broken_mac_openssl
install_package "readline-6.3" "http://ftpmirror.gnu.org/readline/readline-6.3.tar.gz#56ba6071b9462f980c5a72ab0023893b65ba6debb4eeb475d7a563dc65cafd43" standard --if has_broken_mac_readline
if has_tar_xz_support; then
  install_package "Python-3.6.3" "~/.pyenv/cache/Python-3.6.3.tar.gz" ldflags_dirs standard verify_py35 ensurepip
else
  install_package "Python-3.6.3" "~/.pyenv/cache/Python-3.6.3.tar.gz" ldflags_dirs standard verify_py35 ensurepip
fi

可以提前安装好一些依赖包：

1

yum install -y gcc make patch gdbm-devel openssl-devel sqlite-devel zlib-devel bzip2-devel readline-devel

这样再次执行pyenv install 3.6.3时，就不会出现安装慢的问题。

5.切换版本后python版本未变更

添加环境变量

1
2
3
4

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

如果变量生效报错，可能是需要安装pyenv-virtualenv插件：

1

git clone https://github.com/yyuu/pyenv-virtualenv.git ~/.pyenv/plugins/pyenv-virtualenv

上篇文章我讲了安装CDH的一些前置准备，可以参考《CDH安装前置基础准备条件》一文，这里就不再多说。

到此已完成：

1. 集群服务器配置，包括安装操作系统、关闭防火墙、同步服务器时钟等；
2. 外部数据库安装
3. CDH和CM版本均为5.14且已配置本地yum源

2.Cloudera Manager安装

2.1.安装Cloudera Manager Server

1.yum安装Cloudera Manager Server

1

yum -y install cloudera-manager-server

2.安装完成后，初始化数据库：

1
2
3
4

[root@bigdata02 yum.repos.d]# /usr/share/cmf/schema/scm_prepare_database.sh mysql cm cm passwordJAVA_HOME=/usr/java/jdk1.8.0_67-cloudera
Verifying that we can write to /etc/cloudera-scm-server
Creating SCM configuration file in /etc/cloudera-scm-server
Executing:  /usr/java/jdk1.8.0_67-cloudera/bin/java -cp /usr/share/java/mysql-connector-java.jar:/usr/share/java/oracle-connector-java.jar:/usr/share/java/postgresql-connector-java.jar:/usr/share/cmf/schema/../lib/* com.cloudera.enterprise.dbutil.DbCommandExecutor /etc/cloudera-scm-server/db.properties com.cloudera.cmf.db.[main] DbCommandExecutor              INFO  Successfully connected to database.All done, your SCM database is configured correctly!

2.2.启动Cloudera Manager Server

1

[root@bigdata02 ~]# systemctl start cloudera-scm-server

通过http://172.16.1.21:7180/cmf/login 访问CM

3.CDH安装

3.1.CDH集群安装向导

1.admin/admin登录到CM

2.一路下一步开始安装创建集群

3.输入ip段搜索主机

4.修改Parcels为之前创建的http本地源：

5.一路下一步安装完成即可。

4.集群设置安装

1.按需选择自己需要服务进行安装

2.进行角色分配，可参考下图：

3.分配完后，默认配置，进行安装完成后，启动即可。

本篇讲的较为简单，后续的配置，会针对常用的几个应用一个个来讲，所以这里不做过多叙述了。

1.基础环境

1.1.节点规模

测试环境，最小规模，最少4台服务器。一台做管理节点Cloudera Manager和NameNode等，另外三台用作worker，DATANODE节点，这种最小规模一般仅用于开发和测试。

如果是生产环境，最少6台，3台管理节点包括1个Cloudera Manager，2个NameNode做高可用，3个工作节点。

常见的较小规模的生产系统一般为10-20台。

###1.2.操作系统
CDH支持大部分主流的64位操作系统，我这里会以centos 6.9部署CDH 5.14版本为例子。其他CDH版本及其对应的操作系统版本可参考：CDH版本及其支持的操作系统版本

1.3.安装用户

可以用root，或具有免密sudo权限的用户

###1.4.硬件要求
要评估群集的硬件和资源分配，其实需要分析要在群集上运行业务的负载情况，以及将要部署的CDH组件。
还应该考虑存储和处理的数据大小，工作负载的频率，需要运行的作业并发数量以及应用程序所需的资源。
所以硬件配置需要视具体情况而定。

测试集群最低要求：

• CPU：最少4 cores
• 内存：最少16GB
• 网络：千兆及以上
• 磁盘：视情况而定

这里我使用的服务器配置是：

• CPU：56 cores
• 内存：14*16GB
• 网络：双万兆网卡绑定
• 磁盘：24*1.2T SAS(2.5 10K)

1.4.1.磁盘要求

所有节点服务器系统盘可以使用raid1或raid10，数据盘不要使用raid，应该用JBOD模式。hdfs存储系统本身就是分布式高可用的，使用raid就失去使用hdfs的初衷，且会有性能损失。

如果集群的规模不大，有多个应用服务复用的话，NN，ZK，JN等管理服务存放的数据目录也可以放在使用raid的磁盘上。

DataNode数据盘建议选择ext4或xfs，并配置noatime：

1
2
3
4
5
6
7

UUID=4df04bc1-c94b-45d6-a80c-4b2269211fa0 /data1 ext4 defaults,noatime  1 2
UUID=0ec154be-9923-4f05-ae0f-72fa98067d23 /data2 ext4 defaults,noatime  1 2
UUID=a87a9192-3e75-40c6-a58a-f851e5f888e3 /data3 ext4 defaults,noatime  1 2
UUID=283926d8-dc64-4a99-aa17-23e4f325897c /data4 ext4 defaults,noatime  1 2
UUID=b547c6d3-5898-4053-8a15-e38c7be3f9ba /data5 ext4 defaults,noatime  1 2
UUID=8a332303-6bcb-47cb-9def-546b70b75bcf /data6 ext4 defaults,noatime  1 2
UUID=2574f003-b84a-458b-8063-f503066b1101 /data7 ext4 defaults,noatime  1 2

目前常见的SATA读写速度大概在150MB/S-200MB/S，SAS或者SSD会更快，如果磁盘读写速度小于80MB/S，最好检查下磁盘，或者更换更好的磁盘，不然后期IO隐患很大。

1.4.2.网络要求

由于大数据应用，集群内部网络吞吐一般较大，稳健的高性能网络支撑十分重要。前期最好规划好，等到后期业务吞吐上去，网络撑不住再去升级底层网络设施是非常痛苦的。
最起码千兆网卡，根据实际情况，必要时需要考虑万兆网卡，以及配套的光纤交换机，并留有网卡绑定，交换机堆叠的扩展余地。

如果是使用云上的虚拟机，最好确认下网卡的多队列支持，笔者就被XX云网卡多队列支持数过少而坑过，导致集群性能利用率上不去，且CPU负载偏移，网络丢包等现象。

1
2
3
4
5
6
7
8
9
10
11
12

[root@prd-bigdata06 ~]# ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX:             0
TX:             0
Other:          0
Combined:       14
Current hardware settings:
RX:             0
TX:             0
Other:          0
Combined:       14

1
2
3
4
5
6
7
8
9
10
11
12

[root@bigdata17 ~]# ethtool -l p6p1
Channel parameters for p6p1:
Pre-set maximums:
RX:             0
TX:             0
Other:          1
Combined:       63
Current hardware settings:
RX:             0
TX:             0
Other:          1
Combined:       56

2.系统及应用环境

2.1.JDK

CDH发行版中自带JDK为1.7.0_67的版本，CDH5.3以后开始支持JDK1.8。可以实现自己安装好，或者后续安装CDH时，勾选CDH自带的JDK安装。

2.2.外部数据库

CM自动部署安装时会自带数据库进行系统配置、schema等并进行相应管理。
也可是自行部署，不用自带的，具体支持的数据库包括：

• MySQL：5.1、5.5、5.6、5.7

• PostgreSQL：8.1、8.3、8.4、9.1、9.2、9.3、9.4

• Oracle：11gR2、12c

这里我是自己部署的mysql，方便管理。 确保以下配置：

• 增加数据库的最大连接数
• 确保数据库支持UTF-8编码
• 配置为主备模式，参考如何实现CDH元数据库MySQL的主备

自己部署的话，就需要自己预先创建好CDH各项服务对应的元数据库。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

create database metastore default character set utf8;
CREATE USER 'hive'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON metastore.* TO 'hive'@'%';
FLUSH PRIVILEGES;
create database cm default character set utf8;
CREATE USER 'cm'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON cm. * TO 'cm'@'%';
FLUSH PRIVILEGES;
create database am default character set utf8;
CREATE USER 'am'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON am. * TO 'am'@'%';
FLUSH PRIVILEGES;
create database rm default character set utf8;  
CREATE USER 'rm'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON rm. * TO 'rm'@'%';
FLUSH PRIVILEGES;
create database hue default character set utf8;
CREATE USER 'hue'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON hue. * TO 'hue'@'%';
FLUSH PRIVILEGES;
create database oozie default character set utf8;
CREATE USER 'oozie'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON oozie. * TO 'oozie'@'%';
FLUSH PRIVILEGES;
create database sentry default character set utf8;
CREATE USER 'sentry'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON sentry.* TO 'sentry'@'%';
FLUSH PRIVILEGES;

2.3.开放端口

以下常用服务端口，根据实际情况，需要在防火墙上放行。

2.4.http服务

安装httpd服务主要是提供CDH和cm的本地源，进行离线安装。由于总所周知的原因，在线安装一般不会太顺利，最好是离线安装。

1
2
3
4
5
6

[root@bigdata02~]# yum -y install httpd
[root@bigdata02~]# chkconfig --add httpd 
[root@bigdata02~]# chkconfig httpd on
[root@bigdata02~]# service httpd start
Starting httpd:     [OK]
[root@bigdata02~]#

2.4.1.配置本地yum源

1. 在/var/www/html下新增cm5.14目录

1
[root@bigdata02~]# mkdir -p /var/www/html/cm5.14

1. 下载CM5.14版本的RPM安装包放在cm5.14目录下，并执行createrepo:

1
2
3
4
5
6
7
8
9
10

[root@bigdata02]# createrepo .
Spawning worker 0 with 7pkgs
Workers Finished
Gathering worker results
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete
[root@bigdata02]# ll

1. 在Cloudera Manager所在服务器的/etc/yum.repo.d目录下创建cm.repo文件，内容如下:

1
2
3
4
5
6
7

[root@bigdata04 yum.repos.d]# vim cm.repo
[cmrepo]
name=Cloudera Manager 5.14
baseurl=http://10.50.10.12/cm5.14
gpgcheck=false
enable=true

1. CDH Parcels部署同上。

2.5.hosts配置

将集群所有服务器的IP和HOSTNAME配置到hosts文件，并同步至集群的所有服务器。

2.6.系统相关设置

• 禁用selinux
• 关闭iptables防火墙

• swap相关设置

  swappiness表示如何使用swap分区。

  swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。linux的基本默认设置为60，这里我是设为1：

  1 2	/etc/sysctl.conf vm.swappiness=1

• 关闭透明大页面

  1 2	[root@bigdata02~]# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag [root@bigdata02~]# echo never >/sys/kernel/mm/redhat_transparent_hugepage/enabled

2.7.NTP时钟同步

如果公司有自己的NTP Server则可以集群中所有节点可配置企业NTP Server，如果没有则在集群中选用一台服务器作为NTP Server，其它服务器与其保持同步，配置如下：

1. 所有节点安装NTP

   1	[root@bigdata02~]# yum -y install ntp

2. 选一台做ntp server

   1 2 3 4 5 6 7

   [root@bigdata02~]# vim /etc/ntp.conf #server 0.centos.pool.ntp.org iburst #server 1.centos.pool.ntp.org iburst #server 2.centos.pool.ntp.org iburst #server 3.centos.pool.ntp.org iburst server 127.127.1.0 #local clock fudge 127.127.1.0 stratum 10

3. 集群其它节点与其同步，配置如下：

4. 1 2 3 4 5 6 7

   [root@bigdata04~]# vim /etc/ntp.conf # Use public servers from thepool.ntp.org project. #server 0.centos.pool.ntp.org iburst #server 1.centos.pool.ntp.org iburst #server 2.centos.pool.ntp.org iburst #server 3.centos.pool.ntp.org iburst server 172.16.1.22

5. 所有节点启动ntp:

   1 2 3 4 5 6

   [root@bigdata04~]# chkconfig --add ntpd [root@bigdata04~]# chkconfig ntpd on [root@bigdata04~]# service ntpd restart Shutting down ntpd: [ OK ] Starting ntpd: [ OK ] [root@bigdata04~]#

3.外部数据库

1. 集群中CM节点安装MySQL服务

   1 2 3 4 5

   [root@bigdata02~]# yum -y install mysql mysql-server [root@bigdata02~]# chkconfig --add mysqld [root@bigdata02~]# chkconfig mysqld on [root@bigdata02~]# service mysqld start Starting mysqld: [ OK ]

2. 初始化脚本

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

   [root@bigdata02~]# mysql_secure_installation NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FORALL MySQL SERVERS IN PRODUCTION USE! PLEASE READEACH STEP CAREFULLY! In order to log into MySQL to secure it, we'll needthe current password for the root user. If you'vejust installed MySQL, and you haven't set the root password yet, the passwordwill be blank, so you should just press enter here. Enter current password for root (enter for none): OK, successfully used password, moving on... Setting the root password ensures that nobody can log into the MySQL root user without the proper authorisation. Set root password? [Y/n] y New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! By default, a MySQL installation has an anonymous user, allowing anyone to log into MySQL without having to have a user account created for them. This is intended only for testing,and to make the installation go a bit smoother. You should removethem before moving into a production environment. Remove anonymous users? [Y/n] y ... Success! Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? [Y/n] n ... skipping. By default, MySQL comes with a database named 'test' that anyone can access. This is also intended only fortesting, and should be removed before moving into a production environment. Remove test database and access to it? [Y/n] y - Dropping test database... ... Success! - Removing privileges on testdatabase... ... Success! Reloading the privilege tables will ensure that all changes made so far will take effect immediately. Reload privilege tables now? [Y/n] y ... Success! Cleaning up... All done! If you've completed all of the above steps, your MySQL installationshould now be secure. Thanks for usingMySQL! [root@bigdata02~]#

3. 创建CDH所需要的库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

create database metastore default character set utf8;
CREATE USER 'hive'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON metastore.* TO 'hive'@'%';
FLUSH PRIVILEGES;
create database cm default character set utf8;
CREATE USER 'cm'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON cm. * TO 'cm'@'%';
FLUSH PRIVILEGES;
create database am default character set utf8;
CREATE USER 'am'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON am. * TO 'am'@'%';
FLUSH PRIVILEGES;
create database rm default character set utf8;  
CREATE USER 'rm'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON rm. * TO 'rm'@'%';
FLUSH PRIVILEGES;
create database hue default character set utf8;
CREATE USER 'hue'@'%'IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON hue. * TO 'hue'@'%';
FLUSH PRIVILEGES;
create database oozie default character set utf8;
CREATE USER 'oozie'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON oozie. * TO 'oozie'@'%';
FLUSH PRIVILEGES;
create database sentry default character set utf8;
CREATE USER 'sentry'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON sentry.* TO 'sentry'@'%';
FLUSH PRIVILEGES;

4.安装MySQL驱动，将mysql-connector-java-5.1.34.jar拷贝至/usr/share/java目录，并创建软链接。

CDH的安装前置要求大致就这些，后续会讲下CDH部署的具体步骤。以及由浅入深的讲下CDH的一些基本组件。

内容提要
在本节中，我们介绍一些在使用 scikit-learn 过程中用到的 机器学习 词汇，并且给出一些例子阐释它们。

机器学习：问题设置

一般来说，一个学习问题通常会考虑一系列 n 个 样本 数据，然后尝试预测未知数据的属性。 如果每个样本是 多个属性的数据 （比如说是一个多维记录），就说它有许多“属性”，或称 features(特征) 。
我们可以将学习问题分为几大类:

• 监督学习 , 其中数据带有一个附加属性，即我们想要预测的结果值（ 点击此处 转到 scikit-learn 监督学习页面）。这个问题可以是:
  • 分类 : 样本属于两个或更多个类，我们想从已经标记的数据中学习如何预测未标记数据的类别。 分类问题的一个例子是手写数字识别，其目的是将每个输入向量分配给有限数目的离散类别之一。 我们通常把分类视作监督学习的一个离散形式（区别于连续形式），从有限的类别中，给每个样本贴上正确的标签。
  • 回归: 如果期望的输出由一个或多个连续变量组成，则该任务称为 回归. 回归问题的一个例子是预测鲑鱼的长度是其年龄和体重的函数。
• 无监督学习, 其中训练数据由没有任何相应目标值的一组输入向量x组成。这种问题的目标可能是在数据中发现彼此类似的示例所聚成的组，这种问题称为 聚类 , 或者，确定输入空间内的数据分布，称为 密度估计 ，又或从高维数据投影数据空间缩小到二维或三维以进行 可视化 （点击此处 转到 scikit-learn 无监督学习页面）。

训练集和测试集
机器学习是从数据的属性中学习，并将它们应用到新数据的过程。 这就是为什么机器学习中评估算法的普遍实践是把数据分割成 训练集 （我们从中学习数据的属性）和 测试集 （我们测试这些性质）。

加载示例数据集

scikit-learn 提供了一些标准数据集，例如 用于分类的 iris 和 digits 数据集 和 波士顿房价回归数据集。
在下文中，我们从我们的 shell 启动一个 Python 解释器，然后加载 iris 和 digits 数据集。我们的符号约定是 $ 表示 shell 提示符，而 >>> 表示 Python 解释器提示符:

1
2
3
4

$ python
>>> from sklearn import datasets
>>> iris = datasets.load_iris()
>>> digits = datasets.load_digits()

数据集是一个类似字典的对象，它保存有关数据的所有数据和一些元数据。 该数据存储在.data 成员中，它是 n_samples, n_features 数组。 在监督问题的情况下，一个或多个响应变量存储在 .target 成员中。 有关不同数据集的更多详细信息，请参见 专用数据集部分 .
例如，在数字数据集的情况下，digits.data 使我们能够得到一些用于分类的样本特征:

1
2
3
4
5
6
7
8

>>> print(digits.data)  
[[  0.   0.   5. ...,   0.   0.   0.]
 [  0.   0.   0. ...,  10.   0.   0.]
 [  0.   0.   0. ...,  16.   9.   0.]
 ...,
 [  0.   0.   1. ...,   6.   0.   0.]
 [  0.   0.   2. ...,  12.   0.   0.]
 [  0.   0.  10. ...,  12.   1.   0.]]

并且 digits.target 表示了数据集内每个数字的真实类别，也就是我们期望从每个手写数字图像中学得的相应的数字标记:

1
2

>>> digits.target
array([0, 1, 2, ..., 8, 9, 8])

数据数组的形状
数据总是 2D 数组，形状 (n_samples, n_features) ，尽管原始数据可能具有不同的形状。 在数字的情况下，每个原始样本是形状 (8, 8) 的图像，可以使用以下方式访问:

1
2
3
4
5
6
7
8
9

>>> digits.images[0]
array([[  0.,   0.,   5.,  13.,   9.,   1.,   0.,   0.],
       [  0.,   0.,  13.,  15.,  10.,  15.,   5.,   0.],
       [  0.,   3.,  15.,   2.,   0.,  11.,   8.,   0.],
       [  0.,   4.,  12.,   0.,   0.,   8.,   8.,   0.],
       [  0.,   5.,   8.,   0.,   0.,   9.,   8.,   0.],
       [  0.,   4.,  11.,   0.,   1.,  12.,   7.,   0.],
       [  0.,   2.,  14.,   5.,  10.,  12.,   0.,   0.],
       [  0.,   0.,   6.,  13.,  10.,   0.,   0.,   0.]])

该 数据集上的简单示例 说明了如何从原始数据开始调整，形成可以在 scikit-learn 中使用的数据。

从外部数据集加载
要从外部数据集加载，请参阅 加载外部数据集.

学习和预测

在数字数据集的情况下，任务是给出图像来预测其表示的数字。 我们给出了 10 个可能类（数字 0 到 9）中的每一个的样本，我们在这些类上 拟合 一个 估计器 ，以便能够 预测 未知的样本所属的类。
在 scikit-learn 中，分类的估计器是一个 Python 对象，它实现了 fit(X, y) 和 predict(T)等方法。
估计器的一个例子类 sklearn.svm.SVC ，实现了 支持向量分类 。 估计器的构造函数以相应模型的参数为参数，但目前我们将把估计器视为即可:

1
2

>>> from sklearn import svm
>>> clf = svm.SVC(gamma=0.001, C=100.)

选择模型的参数
在这个例子中，我们手动设置 gamma 值。不过，通过使用 网格搜索 及 交叉验证 等工具，可以自动找到参数的良好值。

我们把我们的估计器实例命名为 clf ，因为它是一个分类器(classifier)。我们需要它适应模型，也就是说，要它从模型中学习。 这是通过将我们的训练集传递给 fit 方法来完成的。作为一个训练集，让我们使用数据集中除最后一张以外的所有图像。 我们用 [:-1] Python 语法选择这个训练集，它产生一个包含 digits.data 中除最后一个条目(entry)之外的所有条目的新数组

1
2
3
4
5

>>> clf.fit(digits.data[:-1], digits.target[:-1])  
SVC(C=100.0, cache_size=200, class_weight=None, coef0=0.0,
  decision_function_shape='ovr', degree=3, gamma=0.001, kernel='rbf',
  max_iter=-1, probability=False, random_state=None, shrinking=True,
  tol=0.001, verbose=False)

现在你可以预测新的值，特别是我们可以向分类器询问 digits 数据集中最后一个图像（没有用来训练的一条实例)的数字是什么:

1
2

>>> clf.predict(digits.data[-1:])
array([8])

相应的图像如下:

正如你所看到的，这是一项具有挑战性的任务：图像分辨率差。你是否认同这个分类？
这个分类问题的一个完整例子可以作为一个例子来运行和学习： 识别手写数字。 Recognizing hand-written digits.

模型持久化

可以通过使用 Python 的内置持久化模块（即 pickle ）将模型保存:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

>>> from sklearn import svm
>>> from sklearn import datasets
>>> clf = svm.SVC()
>>> iris = datasets.load_iris()
>>> X, y = iris.data, iris.target
>>> clf.fit(X, y)  
SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
  decision_function_shape='ovr', degree=3, gamma='auto', kernel='rbf',
  max_iter=-1, probability=False, random_state=None, shrinking=True,
  tol=0.001, verbose=False)
>>> import pickle
>>> s = pickle.dumps(clf)
>>> clf2 = pickle.loads(s)
>>> clf2.predict(X[0:1])
array([0])
>>> y[0]
0

在scikit的具体情况下，使用 joblib 替换 pickle（ joblib.dump & joblib.load）可能会更有趣，这对大数据更有效，但只能序列化 (pickle) 到磁盘而不是字符串:

1
2
3
4
5

>>> from sklearn.externals import joblib
>>> joblib.dump(clf, 'filename.pkl') 
之后，您可以加载已保存的模型（可能在另一个 Python 进程中）:
>>>
>>> clf = joblib.load('filename.pkl')

Warning joblib.dump 以及 joblib.load 函数也接受 file-like（类文件） 对象而不是文件名。有关 Joblib 的数据持久化的更多信息，请 点击此处 。
请注意，pickle 有一些安全性和维护性问题。有关使用 scikit-learn 的模型持久化的更多详细信息，请参阅 模型持久化 部分。

规定

scikit-learn 估计器遵循某些规则，使其行为更可预测。

类型转换

除非特别指定，输入将被转换为 float64

1
2
3
4
5
6
7
8
9
10
11
12
13

>>> import numpy as np
>>> from sklearn import random_projection
>>> rng = np.random.RandomState(0)
>>> X = rng.rand(10, 2000)
>>> X = np.array(X, dtype='float32')
>>> X.dtype
dtype('float32')
>>> transformer = random_projection.GaussianRandomProjection()
>>> X_new = transformer.fit_transform(X)
>>> X_new.dtype
dtype('float64')

在这个例子中，X 原本是 float32 ，被 fit_transform(X) 被转换成 float64 。
回归目标被转换为 float64 ，但分类目标维持不变:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

>>> from sklearn import datasets
>>> from sklearn.svm import SVC
>>> iris = datasets.load_iris()
>>> clf = SVC()
>>> clf.fit(iris.data, iris.target)  
SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
  decision_function_shape='ovr', degree=3, gamma='auto', kernel='rbf',
  max_iter=-1, probability=False, random_state=None, shrinking=True,
  tol=0.001, verbose=False)
>>> list(clf.predict(iris.data[:3]))
[0, 0, 0]
>>> clf.fit(iris.data, iris.target_names[iris.target])  
SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
  decision_function_shape='ovr', degree=3, gamma='auto', kernel='rbf',
  max_iter=-1, probability=False, random_state=None, shrinking=True,
  tol=0.001, verbose=False)
>>> list(clf.predict(iris.data[:3]))  
['setosa', 'setosa', 'setosa']

这里，第一个 predict() 返回一个整数数组，因为在 fit 中使用了 iris.target （一个整数数组）。 第二个 predict() 返回一个字符串数组，因为 iris.target_names 是一个字符串数组。

再次训练和更新参数

估计器的超参数可以通过 sklearn.pipeline.Pipeline.set_params 方法在实例化之后进行更新。 调用 fit() 多次将覆盖以前的 fit() 所学到的参数:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

>>> import numpy as np
>>> from sklearn.svm import SVC
>>> rng = np.random.RandomState(0)
>>> X = rng.rand(100, 10)
>>> y = rng.binomial(1, 0.5, 100)
>>> X_test = rng.rand(5, 10)
>>> clf = SVC()
>>> clf.set_params(kernel='linear').fit(X, y)  
SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
  decision_function_shape='ovr', degree=3, gamma='auto', kernel='linear',
  max_iter=-1, probability=False, random_state=None, shrinking=True,
  tol=0.001, verbose=False)
>>> clf.predict(X_test)
array([1, 0, 1, 1, 0])
>>> clf.set_params(kernel='rbf').fit(X, y)  
SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
  decision_function_shape='ovr', degree=3, gamma='auto', kernel='rbf',
  max_iter=-1, probability=False, random_state=None, shrinking=True,
  tol=0.001, verbose=False)
>>> clf.predict(X_test)
array([0, 0, 0, 1, 0])

在这里，估计器被 SVC() 构造之后，默认内核 rbf 首先被改变到 linear ，然后改回到 rbf 重新训练估计器并进行第二次预测。

多分类与多标签拟合

当使用 多类分类器 时，执行的学习和预测任务取决于参与训练的目标数据的格式:

1
2
3
4
5
6
7
8
9
10

>>> from sklearn.svm import SVC
>>> from sklearn.multiclass import OneVsRestClassifier
>>> from sklearn.preprocessing import LabelBinarizer
>>> X = [[1, 2], [2, 4], [4, 5], [3, 2], [3, 1]]
>>> y = [0, 0, 1, 1, 2]
>>> classif = OneVsRestClassifier(estimator=SVC(random_state=0))
>>> classif.fit(X, y).predict(X)
array([0, 0, 1, 1, 2])

在上述情况下，分类器被使用一个含有多个标签的一维数组训练，因此 predict() 方法提供相应的多类别预测。分类器也可以通过二进制表示的的标签的二维数组来训练:

1
2
3
4
5
6
7

>>> y = LabelBinarizer().fit_transform(y)
>>> classif.fit(X, y).predict(X)
array([[1, 0, 0],
       [1, 0, 0],
       [0, 1, 0],
       [0, 0, 0],
       [0, 0, 0]])

这里，使用 LabelBinarizer 使目标向量 y 被转化成二维数组的标签表示。在这种情况下， predict() 返回一个表示相应多重标签预测的 2d 矩阵。
请注意，第四个和第五个实例返回全零向量，表明它们不能匹配用来训练中的目标标签中的任意一个。使用多分类输出，类似地可以为一个实例分配多个标签:

1
2
3
4
5
6
7
8
9

>> from sklearn.preprocessing import MultiLabelBinarizer
>> y = [[0, 1], [0, 2], [1, 3], [0, 2, 3], [2, 4]]
>> y = MultiLabelBinarizer().fit_transform(y)
>> classif.fit(X, y).predict(X)
array([[1, 1, 0, 0, 0],
       [1, 0, 1, 0, 0],
       [0, 1, 0, 1, 0],
       [1, 0, 1, 1, 0],
       [0, 0, 1, 0, 1]])

在这种情况下，用来训练分类器的多个向量被赋予多个标记， MultiLabelBinarizer 被用来二进制化多个标签的二维数组，使之用来训练。 predict() 函数返回带有多个标记的二维数组作为每个实例的结果。

中文文档: http://sklearn.apachecn.org/cn/0.19.0/tutorial/basic/tutorial.html
英文文档: http://sklearn.apachecn.org/en/0.19.0/tutorial/basic/tutorial.html
GitHub: https://github.com/apachecn/scikit-learn-doc-zh（觉得不错麻烦给个 Star，我们一直在努力）
贡献者: https://github.com/apachecn/scikit-learn-doc-zh#贡献者
有兴趣的大佬们也可以和我们一起来维护，持续更新中 。。。
机器学习交流群: 629470233

安装 scikit-learn

Note: 如果你想为这个项目做出贡献，建议你安装最新的开发版本.

安装最新版本

Scikit-learn 要求:

• Python (>= 2.7 or >= 3.3)
• NumPy (>= 1.8.2)
• SciPy (>= 0.13.3)如果你已经有一个安全的 numpy 和 scipy，安装 scikit-learn 的最简单的方法是使用 pip

  1	pip install -U scikit-learn

或者 conda:

1

conda install scikit-learn

如果您还没有安装 NumPy 或 SciPy，还可以使用 conda 或 pip 安装这些。 当使用 pip 时，请确保使用 binary wheels，并且 NumPy 和 SciPy 不会从源重新编译，这可能在使用操作系统和硬件的特定配置（如 Raspberry Pi 上的 Linux）时发生。 从源代码构建 numpy 和 scipy 可能是复杂的（特别是在 Windows 上），并且需要仔细配置，以确保它们与线性代数程序的优化实现链接。而是使用如下所述的第三方分发。
如果您必须安装 scikit-learn 及其与 pip 的依赖关系，则可以将其安装为 scikit-learn[alldeps]。 最常见的用例是 requirements.txt 用作 PaaS 应用程序或 Docker 映像的自动构建过程的一部分的文件。此选项不适用于从命令行进行手动安装。

第三方发行版

如果您尚未安装具有 numpy 和 scipy 的 python 安装，建议您通过软件包管理器或通过 python 软件包进行安装。 这些与 numpy, scipy, scikit-learn, matplotlib 和许多其他有用的科学和数据处理库。
可用选项有:

Canopy 和 Anaconda 适用于所有支持的平台

Canopy 和 Anaconda 都运送了最新版本的 scikit-learn，另外还有一大批适用于 Windows，Mac OSX 和 Linux 的科学 python 库。
Anaconda 提供 scikit-learn 作为其免费分发的一部分.

Warning: 升级或卸载使用 Anaconda 安装的 scikit-learn，或者 conda 不应该使用 pip 命令。代替:
升级 scikit-learn:

1	conda update scikit-learn

卸载 scikit-learn:

1

conda remove scikit-learn

使用 pip install -U scikit-learn 升级 or pip uninstall scikit-learn 卸载 可能无法正确删除 conda 命令安装的文件.
pip 升级和卸载操作仅适用于通过 pip install 安装的软件包.

WinPython 适用于 Windows

该WinPython 项目分布 scikit-learn 作为额外的插件。
有关特定操作系统的安装说明或汇编出血边缘版本，请参阅 高级安装说明.

中文文档: http://sklearn.apachecn.org/cn/0.19.0/tutorial/basic/tutorial.html
英文文档: http://sklearn.apachecn.org/en/0.19.0/tutorial/basic/tutorial.html
GitHub: https://github.com/apachecn/scikit-learn-doc-zh（觉得不错麻烦给个 Star，我们一直在努力）
贡献者: https://github.com/apachecn/scikit-learn-doc-zh#贡献者
有兴趣的大佬们也可以和我们一起来维护，持续更新中 。。。
机器学习交流群: 629470233

分区格式

由于此块移动硬盘经常要在windows和mac平台来回切换使用，在不纠结单文件4GB的限制的情况下，当时使用的FAT32格式。还好此类格式和NTFS格式较为常见，恢复起来也较为容易。这里要说一下：

• FAT32格式磁盘可在windows和mac平台读写，但有单个文件4GB限制；
• NTFS完美兼容windows平台，但在mac平台下，默认为只读，但是通过魔改mac系统配置或者通过第三方插件可以取得写入权限；
• exfat格式同样兼容windows和mac平台读写，但是此类格式不太稳定，会有丢数据的现象，且一旦出问题，一般技术手段，基本难以恢复数据。

  恢复工具

  市面上硬盘数据恢复工具很多，大多是无法完全恢复丢失数据的。一般个人不是很重要的数据，且文件格式比较常规的，在数据丢失后立马停止文件写入，尝试修复还是有可能恢复90%+的数据的。这里说一下，我亲身试用过的一些工具，希望可以帮到有需要的朋友们，少走弯路。
• EasyRecovery (Kroll Ontrack)注意括号内软件厂商名字，由于市面上还有很多国产山寨数据恢复工具也叫EasyRecovery（大小写，空格啥的不同），名字上基本难以区分，所以要注意厂商名字。此款工具在10年前我就有使用过，即便是6.0的老版本，恢复能力也很强，就是扫描速度较慢。曾经恢复了300G的丢失数据，90%基本完美恢复。
• DiskGenius 老牌工具了，装过系统的应该都知道，在PE里基本都集成的磁盘分区工具，也有数据恢复功能。此次400+G的数据就是使用这个工具恢复的，常规文件格式恢复都OK，但是对PSD，拆分的压缩文件恢复成功率不高。总的来说还是可用的，注意某度下载的大部分最新破解版其实都是免费版，正常使用但是对单个大文件恢复有限制，以至于会误导以为数据无法恢复了。推荐使用4.7或者4.2的老版本有功能完整的破解版。
• finaldata 口碑在外的数据恢复工具，实际使用恢复情况并不理想，也可能是我找的版本不对。
• easyrecovery 国产山寨Kroll Ontrack厂商的工具名字，虽然抄袭大厂的工具名字，但是实际恢复能力也不差，基本能恢复。

数据量较大的推荐使用DiskGenius，扫描进度还能存档。数据量不大的可以选择easyrecovery，国外原版或者国产版均可。
具体的恢复过程这里就不细说了，都是windows工具，图形界面，看着就会，主要就是恢复时间较长。

Linux数据恢复

既然说到数据恢复了，我们工作中接触的服务器，还是Linux居多，这里也说说从rm -rf /* 到不跑路的常规救急方法。
在我初出茅庐，刚干运维的那段岁月，也曾年轻气盛，逮哪都是rm -rf *一把梭，终于有一次梭出问题了，把线上数据给梭没了，然后….此处省略中间办公室精彩剧情部分，直接上恢复过程。

exundelete恢复Linux文件系统数据

exundelete是用于针对Linux ext3,ex4的文件系统数据恢复的工具，大致原理就是扫出文件系统的inode的信息，然后根据iNode信息结合日志去查询对应的block位置，包括直接块和间接块，然后通过dd命令备份这些信息，恢复数据。

exundelete安装

官网下载最新版，extundelete-0.2.4
安装三连不再赘述

1
2
3
4

$tar jxvf  extundelete-0.2.4.tar.bz2
$./configure
$make
$make install

extundelete用法

首先及时卸载需要恢复数据的分区，然后查询分区可恢复的数据信息：

1

extundelete  /dev/sdc1  --inode 2

恢复单个文件

1

extundelete /dev/sdb1 --restore-file hosts

恢复一个目录

1

extundelete /dev/sdb1 --restore-files test/

恢复整个分区

1

extundelete /dev/sdb1 –-restore-all

经过实际测试，restore-all比较好用，在初次删除后可以很好的恢复文件及目录结构，但是如果我在相同位置新建了相同的文件名或者目录名，就会恢复失败。而恢复单独的文件或者目录则没有成功，也可能是我的姿势不对。

Consul是什么?

Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul是分布式的、高可用的、 可横向扩展的。它具备以下特性:

• 服务发现 Consul的客户端可提供一个服务，比如 api 或者mysql，另外一些客户端可使用Consul去发现一个指定服务的提供者。通过DNS或者HTTP接口可以很容易的找到他所依赖的服务。
• 健康检查 Consul客户端可提供任意数量的健康检查，指定一个服务(比如:webserver是否返回了200 OK 状态码)或者使用本地节点(比如:内存使用是否大于90%). 这个信息可由operator用来监视集群的健康。服务发现组件用来避免将流量发送到不健康的主机。
• Key/Value存储 应用程序可根据自己的需要使用Consul的Key/Value存储.比如动态配置,功能标记,协调,领袖选举等等,简单的HTTP API让他更易于使用。
• 多数据中心 Consul支持开箱即用的多数据中心.这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。Consul面向DevOps和应用开发者友好，使他适合现代弹性的基础设施。

Consul架构

Consul是一个分布式高可用的系统。
Agent与一个和多个Consul Server 进行交互.Consul Server 用于存放和复制数据.server自行选举一个leader。虽然Consul可以运行在一台server , 但是建议使用3到5台来避免失败情况下数据的丢失。每个数据中心建议配置一个server集群。

Consul部署

Consul用Golang实现，因此具有天然可移植性(支持 Linux、windows 和macOS)。安装包仅包含一个可执行文件（这是由golang语言特性决定的）。Consul安装非常简单，只需要下载对应系统的软件包并解压后就可使用。

常见以Linux平台为例：

1
2
3

$ wget https://releases.hashicorp.com/consul/0.8.5/consul_0.8.5_linux_amd64.zip
$ unzip consul_0.8.5_linux_amd64.zip
$ mv consul /usr/local/bin/

安装完即可执行命令验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ consul
usage: consul [--version] [--help] <command> [<args>]
Available commands are:
   agent          Runs a Consul agent
   event          Fire a new event
   exec           Executes a command on Consul nodes
   force-leave    Forces a member of the cluster to enter the "left" state
   info           Provides debugging information for operators.
   join           Tell Consul agent to join cluster
   keygen         Generates a new encryption key
   keyring        Manages gossip layer encryption keys
   kv             Interact with the key-value store
   leave          Gracefully leaves the Consul cluster and shuts down
   lock           Execute a command holding a lock
   maint          Controls node or service maintenance mode
   members        Lists the members of a Consul cluster
   monitor        Stream logs from a Consul agent
   operator       Provides cluster-level tools for Consul operators
   reload         Triggers the agent to reload configuration files
   rtt            Estimates network round trip time between nodes
   snapshot       Saves, restores and inspects snapshots of Consul server state
   validate       Validate config files/directories
   version        Prints the Consul version
   watch          Watch for changes in Consul