Dynamometer是一种用于性能测试Hadoop HDFS NameNode的工具。其目的是通过针对生产文件系统镜像初始化NameNode，并重放通过NameNode审计日志等收集的生产工作负载，来提供一个真实环境。这使得可以重放不仅在生产环境中特征相似，而且实际上完全相同的工作负载。
Dynamometer将启动一个YARN应用程序，该程序会运行一个NameNode和可配置数量的DataNode，将整个HDFS集群模拟为单个应用程序。还有一个额外的workload作业作为MapReduce任务运行，它接收审计日志作为输入，并利用其中包含的信息向NameNode提交匹配请求，从而对服务产生负载。
Dynamometer可以在不同的Hadoop版本或不同配置下执行相同的工作负载，从而无需部署到真实的大规模集群，就能测试配置调整和代码更改在大规模环境下的效果。
在本文档中，我们将使用"Dyno-HDFS"、"Dyno-NN"和"Dyno-DN"来分别指代在Dynamometer应用程序内部启动的HDFS集群、NameNode和DataNodes。而像HDFS、YARN和NameNode这些未加限定的术语，则是指运行Dynamometer的现有基础设施。
有关Dynamometer工作原理的更多详细信息（而非使用方法），请参阅本页末尾的架构部分。
Dynamometer基于YARN应用程序运行，因此需要一个现有的YARN集群来执行。它还需要一个配套的HDFS实例来存储一些用于通信的临时文件。
Dynamometer由三个主要组件组成，每个组件位于各自的模块中：
dynamometer-infra): 这是启动Dyno-HDFS集群的YARN应用程序。dynamometer-workload): 这是用于重放审计日志的MapReduce作业。dynamometer-blockgen): 这是一个MapReduce作业，用于为每个Dyno-DN生成输入文件；运行基础设施应用前需要先执行此步骤。所有这些组件的编译版本都将包含在标准的Hadoop发行版中。您可以在打包发行版的share/hadoop/tools/dynamometer目录下找到它们。
在启动Dynamometer应用程序之前，需要完成一系列设置步骤，包括指示Dynamometer使用哪些配置、使用哪个版本、加载时使用哪个fsimage等。这些步骤只需执行一次即可将所有内容准备就绪，然后可以进行多次Dynamometer执行，只需进行微小调整即可测量变化。
下面讨论的脚本可以在发行版的share/hadoop/tools/dynamometer/dynamometer-{infra,workload,blockgen}/bin目录中找到。对应的Java JAR文件位于share/hadoop/tools/lib/目录。下文中对bin文件的引用均假设当前工作目录为share/hadoop/tools/dynamometer。
在启动您的第一个Dyno-HDFS集群之前，需要完成以下步骤：
从您的NameNode收集fsimage及相关文件。这将包括NameNode作为检查点过程一部分创建的fsimage_TXID文件、包含该镜像md5哈希值的fsimage_TXID.md5文件、包含一些元数据的VERSION文件，以及可以通过离线镜像查看器从fsimage生成的fsimage_TXID.xml文件：
hdfs oiv -i fsimage_TXID -o fsimage_TXID.xml -p XML
建议您从Secondary/Standby NameNode收集这些文件（如果有的话），以避免给Active NameNode增加额外负载。
所有这些文件必须放置在HDFS上某个位置，以便各个作业能够访问它们。它们都应位于同一文件夹中，例如hdfs:///dyno/fsimage。
所有这些步骤都可以通过upload-fsimage.sh脚本自动完成，例如：
./dynamometer-infra/bin/upload-fsimage.sh 0001 hdfs:///dyno/fsimage
其中0001是所需fsimage的事务ID。有关更多详细信息，请参阅脚本的使用信息。
收集用于启动Dyno-NN和-DNs的Hadoop发行版压缩包。例如，如果测试Hadoop 3.0.2版本，请使用hadoop-3.0.2.tar.gz。该发行版包含Dynamometer不需要的若干组件（如YARN），因此为减小体积，您可以选择使用create-slim-hadoop-tar.sh脚本：
./dynamometer-infra/bin/create-slim-hadoop-tar.sh hadoop-VERSION.tar.gz
Hadoop tar可以存放在HDFS上，也可以存放在运行客户端的本地机器上。其路径将通过-hadoop_binary_path参数提供给客户端。
另外，如果您使用-hadoop_version参数，只需指定要运行的版本（例如'3.0.2'），客户端将尝试自动从Apache镜像下载。更多详情请参阅客户端的使用说明。
准备一个配置目录。您需要指定一个符合标准Hadoop配置布局的配置目录，例如该目录应包含etc/hadoop/*-site.xml文件。这将决定Dyno-NN和-DNs启动时使用的配置。Dynamometer正常运行必须修改的配置（如fs.defaultFS或dfs.namenode.name.dir）会在执行时被覆盖。这可以是一个本地可用的目录，也可以是本地或远程（HDFS）存储中的归档文件。
这将使用fsimage_TXID.xml文件生成每个Dyno-DN应向Dyno-NN通告的块列表。它以MapReduce作业的形式运行。
./dynamometer-blockgen/bin/generate-block-lists.sh
-fsimage_input_path hdfs:///dyno/fsimage/fsimage_TXID.xml
-block_image_output_dir hdfs:///dyno/blocks
-num_reducers R
-num_datanodes D
在此示例中，使用之前上传的XML文件将区块列表生成到hdfs:///dyno/blocks目录。该作业使用了R个reducer，并生成了D个区块列表——这将决定在Dyno-HDFS集群中启动多少个Dyno-DN节点。
此步骤仅在您打算使用Dynamometer的审计追踪回放功能时才需要；如果您仅打算启动Dyno-HDFS集群，可以直接跳转到下一节。
审计追踪重放功能每个映射器接受一个输入文件，目前支持两种输入格式，可通过auditreplay.command-parser.class配置进行设置。系统会在启动时自动为审计日志目录中的每个审计日志文件创建一个映射器。
默认为直接格式，org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogDirectParser。该格式接受标准配置审计日志记录器生成的文件格式，例如类似以下内容的行：
1970-01-01 00:00:42,000 INFO FSNamesystem.audit: allowed=true ugi=hdfs ip=/127.0.0.1 cmd=open src=/tmp/foo dst=null perm=null proto=rpc
使用此格式时，您还必须指定auditreplay.log-start-time.ms，该参数应为审计跟踪的开始时间（以Unix纪元以来的毫秒数表示）。这是为了让所有映射器就统一的开始时间达成一致。例如，如果上述行是第一个审计事件，您将指定auditreplay.log-start-time.ms=42000。在文件中，审计日志必须按时间戳升序排列。
另一种支持的格式是org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogHiveTableParser。该格式接受由Hive查询生成的输出字段文件，字段顺序如下：
relativeTimestamp: 事件时间偏移量，以毫秒为单位，从跟踪开始计算ugi: 提交用户的用户信息command: 命令名称，例如'open'source: 源路径dest: 目标路径sourceIP: 事件的源IP假设您的审计日志存储在Hive中，可以通过类似以下的Hive查询生成：
INSERT OVERWRITE DIRECTORY '${outputPath}'
SELECT (timestamp - ${startTimestamp} AS relativeTimestamp, ugi, command, source, dest, sourceIP
FROM '${auditLogTableLocation}'
WHERE timestamp >= ${startTimestamp} AND timestamp < ${endTimestamp}
DISTRIBUTE BY src
SORT BY relativeTimestamp ASC;
您可能会注意到，在上面的Hive查询中有一个DISTRIBUTE BY src子句，这表示输出文件应按调用者的源IP进行分区。这样做的目的是尽量保持来自同一客户端的请求顺序更接近。Dynamometer不保证分区内操作的严格顺序，但通常分区内的顺序维护会比跨分区更紧密。
无论您使用Hive还是原始审计日志，都需要根据工作负载回放所需的并发客户端数量对审计日志进行分区。使用源IP作为分区键是上文讨论过具有潜在优势的一种方法，但任何分区方案都应该能取得不错的效果。
完成上述设置步骤后，您就可以启动Dyno-HDFS集群并对其重放一些工作负载了！
启动Dyno-HDFS YARN应用的客户端可以选择在Dyno-HDFS集群完全启动后立即启动工作负载回放作业。这使得每次回放都成为客户端的单次执行，便于轻松测试各种配置。您也可以分别启动这两部分以获得更多控制权。同样，可以为不由Dynamometer/YARN控制的外部NameNode启动Dyno-DNs。这对于测试尚未支持的NameNode配置（例如HA NameNodes）非常有用。您可以通过向基础设施应用传递-namenode_servicerpc_addr参数来实现这一点，该参数的值应指向外部NameNode的服务RPC地址。
首先启动基础设施应用程序以开始内部HDFS集群的启动，例如：
./dynamometer-infra/bin/start-dynamometer-cluster.sh
-hadoop_binary_path hadoop-3.0.2.tar.gz
-conf_path my-hadoop-conf
-fs_image_dir hdfs:///fsimage
-block_list_path hdfs:///dyno/blocks
这展示了所需的参数。您可以使用-help标志运行以查看进一步的用法信息。
客户端将跟踪Dyno-NN的启动进度以及它认为存活的Dyno-DN数量。当Dyno-NN退出安全模式并准备就绪时，客户端将通过日志记录进行通知。
此时可以启动一个工作负载作业（仅包含map的MapReduce作业），例如：
./dynamometer-workload/bin/start-workload.sh
-Dauditreplay.input-path=hdfs:///dyno/audit_logs/
-Dauditreplay.output-path=hdfs:///dyno/results/
-Dauditreplay.num-threads=50
-nn_uri hdfs://namenode_address:port/
-start_time_offset 5m
-mapper_class_name AuditReplayMapper
工作负载生成的类型是可配置的；AuditReplayMapper会按照之前讨论的方式重放审计日志跟踪。AuditReplayMapper通过配置进行设置；必须指定auditreplay.input-path、auditreplay.output-path和auditreplay.num-threads来分别配置审计日志文件的输入路径、结果输出路径以及每个map任务的线程数。系统将启动与input-path中文件数量相等的map任务；每个任务将读取其中一个输入文件，并使用num-threads个线程来重放该文件中包含的事件。系统会尽力按照事件最初发生的相同速度忠实重放审计日志事件（可选地，可以通过指定auditreplay.rate-factor来调整重放速度，该参数是重放速度的乘数因子，例如使用2.0表示以原始速度的两倍重放事件）。
AuditReplayMapper会将基准测试结果以CSV格式输出到输出目录中的part-r-00000文件。每行数据的格式为user,type,operation,numops,cumulativelatency，例如hdfs,WRITE,MKDIRS,2,150。
为了让基础设施应用客户端自动启动工作负载，工作负载作业的参数会被传递给基础设施脚本。目前仅支持以这种方式使用AuditReplayMapper。要使用与上述相同的参数启动集成应用程序，可以采用以下方式：
./dynamometer-infra/bin/start-dynamometer-cluster.sh
-hadoop_binary hadoop-3.0.2.tar.gz
-conf_path my-hadoop-conf
-fs_image_dir hdfs:///fsimage
-block_list_path hdfs:///dyno/blocks
-workload_replay_enable
-workload_input_path hdfs:///dyno/audit_logs/
-workload_output_path hdfs:///dyno/results/
-workload_threads_per_mapper 50
-workload_start_delay 5m
以这种方式运行时，客户端会在工作负载完成后自动销毁Dyno-HDFS集群。要查看支持的完整参数列表，请使用-help标志运行。
Dynamometer是构建在YARN之上的一个应用程序。Dynamometer应用中有三个主要角色：
驱动程序中封装的逻辑使用户能够通过单一命令对Dynamometer执行完整的测试运行，从而可以实现诸如扫描不同参数以找到最优配置等功能。
基础设施应用以原生YARN应用程序的形式编写，其中会启动一个NameNode和多个DataNode，并将它们连接起来以创建完全模拟的HDFS集群。为了使Dynamometer能够提供高度真实的场景，必须拥有一个从NameNode视角看包含与生产集群相同信息的集群。这就是为什么上述设置步骤首先需要从生产NameNode收集FsImage文件并将其放入宿主HDFS集群。为了避免复制整个集群的数据块，Dynamometer利用了以下事实：存储在数据块中的实际数据对NameNode无关紧要，NameNode只感知块元数据。Dynamometer的blockgen作业首先使用离线镜像查看器将FsImage转换为XML，然后解析该XML以提取每个块的元数据，接着对这些信息进行分区后放入HDFS供模拟DataNode使用。SimulatedFSDataset用于绕过DataNode存储层，仅存储从上一步提取的信息中加载的块元数据。这种方案使得Dynamometer可以在每个物理节点上部署多个模拟DataNode，因为元数据的大小比数据本身小多个数量级。
为了创建与生产环境匹配的压力测试，Dynamometer需要一种收集生产工作负载信息的方法。为此使用了HDFS审计日志，该日志完整记录了NameNode处理的所有客户端操作。通过重放这些审计日志来重现客户端负载，并运行模拟的DataNode来重现集群管理负载，Dynamometer能够真实模拟生产NameNode的运行状况。
一个负载沉重的NameNode每秒可以处理数万次操作；为了产生这样的负载，Dynamometer需要大量客户端提交请求。为了确保每个请求与其原始提交具有相同的效果和性能影响，Dynamometer尝试以保留其原始顺序的方式处理相关请求（例如，先创建目录再列出该目录）。正是出于这个原因，建议按源IP地址对审计日志文件进行分区，假设来自同一主机的请求比来自不同主机的请求具有更紧密的因果关系。为了简化操作，压力测试任务被编写为仅包含map的MapReduce作业，其中每个mapper消费一个分区的审计日志文件，并针对模拟的NameNode重放其中包含的命令。在执行过程中会收集有关重放的统计信息，例如不同类型请求的延迟。
要了解更多关于Dynamometer的信息，您可以查看宣布其初始发布的博客文章或此演示文稿。