2021SC@SDUSC
本篇我将对hadoop-tools中的最后一个内容Dynamometer进行分析
概观Dynamometer是测试Hadoop HDFS命名节点性能的工具。其目的是通过针对生产文件系统映像初始化名称节点并重放通过例如名称节点的审核日志收集的生产工作负载来提供真实环境。这允许重放一个工作负载，该工作负载不仅在特性上与生产中所经历的相似，而且实际上是相同的。
Dynamometer将启动一个Yarn应用程序，该应用程序启动单个名称节点和可配置数量的数据节点，将整个HDFS集群模拟为一个应用程序。另外还有一个工作量作业作为MapReduce作业运行，该作业接受审核日志作为输入，并使用其中包含的信息向NameNode提交匹配的请求，从而导致服务负载。
Dynamometer可以针对不同的Hadoop版本或不同的配置执行相同的工作负载，从而可以大规模测试配置调整和代码更改，而无需部署到真正的大规模集群。
在本文档中，我们将使用“Dyno-HDFS”、“Dyno-NN”和“Dyno-DN”分别指代已启动的HDFS集群、名称节点和数据节点少于Dynamometer应用。无条件使用的术语，如“HDFS”、“Yarn”和“名称节点”，是指Dynamometer运行的现有基础设施。
需求Dynamometer基于Yarn应用，因此需要现有的YARN cluster来执行。它还需要一个附带的HDFS实例来存储一些用于通信的临时文件。
构造Dynamometer由三个主要部件组成，每个部件都有自己的模块:
- 基础设施(dynamometer-infra):这是启动Dyno-HDFS集群的Yarn应用程序。
- 工作量(dynamometer-workload):这是重放审计日志的MapReduce作业。
- 块生成器(dynamometer-blockgen):这是一个MapReduce作业，用于为每个Dyno-DN生成输入文件；它的执行是运行基础设施应用程序的先决步骤。
在启动Dynamometer应用程序之前，必须完成许多设置步骤，指示Dynamometer使用什么配置、使用什么版本、加载时使用什么fsimage等。这些步骤可以执行一次，以将所有的东西都放在适当的位置，然后可以对它们执行许多Dynamometer执行，并进行微小的调整来测量变化。
Step1：准备必要的文件在启动第一个Dyno-HDFS集群之前，需要执行许多步骤
Step2：准备FsImage文件从名称节点收集fsimage和相关文件。这将包括fsimage_TXID名称节点作为检查点的一部分创建的文件fsimage_TXID.md5包含图像的md5哈希版本包含一些元数据的文件，并且fsimage_TXID.xml可以使用离线图像查看器从fsimage生成的文件:
hdfs oiv -i fsimage_TXID -o fsimage_TXID.xml -p XML
如果有辅助/备用名称节点，建议从辅助/备用名称节点收集这些文件，以避免给活动名称节点带来额外负载。
所有这些文件都必须放在HDFS的某个地方，在那里各种工作都可以访问它们。
它们应该都在同一个文件夹中hdfs:///dyno/fsimage。
所有这些步骤都可以通过上传-fsimage.sh脚本，例如:
./dynamometer-infra/bin/upload-fsimage.sh 0001 hdfs:///dyno/fsimage
其中0001是所需fsimage的事务标识。
Step3：准备一个hadoop二进制文件：收集Hadoop分发目标球，用于启动Dyno-NN和-DNs。此分布包含Dynamometer (e.g. YARN)不需要的几个组件，因此为了减小其尺寸，可以选择使用create-slim-hadoop-tar.sh脚本:
./dynamometer-infra/bin/create-slim-hadoop-tar.sh hadoop-VERSION.tar.gz
Hadoop tar可以位于HDFS，也可以位于运行客户端的本地。它的路径将通过-hadoop_binary_path争论。
Step4：准备配置文件准备一个配置目录。您需要使用标准的Hadoop配置布局指定一个配置目录，例如，它应该包含etc/hadoop/*-site.xml。这决定了Dyno-NN和-DNs将以何种配置推出。为使测功机正常工作而必须修改的配置(例如fs.defaultFS或者dfs.namenode.name.dir)将在执行时被覆盖。如果目录在本地可用，则可以是目录，或者是本地或远程(HDFS)存储上的归档文件。
Step5：执行块生成作业使用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。稀有减速器用于工作，并且D生成块列表-这将决定在Dyno-HDFS集群中启动多少Dyno-DNs。
Step6准备Audit Traces (Optional)只有当打算使用测力计的audit trace功能时，此步骤才是必要的；如果只是打算启动一个Dyno-HDFS集群，您可以跳到下一部分。
audit trace接受每个映射器一个输入文件，并且当前支持两种输入格式，可通过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，它应该是audit traces的开始时间(自Unix纪元以来的毫秒数)。这是所有地图绘制者就单一开始时间达成一致所必需的。例如，如果上面的行是第一个审计事件，您可以指定audit replay . log-开始时间. ms=42000。在一个文件中， audit logs必须按时间戳升序排列。
另一种支持的格式是org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogHiveTableParser.。它接受由带有输出字段的Hive查询生成的格式的文件，顺序如下:
- relativeTimestamp:从跟踪开始的事件时间偏移，以毫秒为单位
- ugi:提交用户的用户信息
- command:命令的名称，例如“打开”
- 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;
对Audit logs进行分区
需要注意到，在上面显示的Hive查询中，有一个由src分发子句，该子句指示输出文件应该由调用方的源IP进行分区。这样做是为了保持来自单个客户端的请求的更紧密排序。即使在分区内，测力计也不能保证严格的操作顺序，但是分区内的顺序通常比分区间的顺序保持得更紧密。
无论您使用Hive还是原始审核日志，都有必要根据执行工作负载重放所需的并发客户端数量对审核日志进行分区。使用源IP作为分区密钥是一种具有上述潜在优势的方法，但是任何分区方案都应该运行良好。
Running Dynamometer完成以上设置步骤后，就可以启动Dyno-HDFS集群并对其重放一些工作负载了！
一旦Dyno-HDFS集群完全启动，启动Dyno-HDFS YARN应用程序的客户端可以选择启动工作负载重放作业。这使得每次重放都变成客户端的单次执行，从而能够轻松测试各种配置。您也可以分别启动这两个，以获得更多控制。同样，可以为不受Dynamometer/YARN控制的外部名称节点启动动态域名系统。这对于测试尚不支持的命名节点配置(例如高可用性命名节点)非常有用。通过将-namenode_servicerpc_addr基础结构应用程序的参数，其值指向外部名称节点的服务RPC地址。
Manual Workload Launch首先启动基础架构应用程序，开始启动内部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-DNs处于活动状态。当Dyno-NN退出安全模式并准备使用时，它将通过日志记录进行通知。
此时，可以启动工作负载作业(仅限地图的地图缩减作业)，例如:
./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
工作负载生成的类型是可配置的；审计重放映射器重放审计日志跟踪，如前所述。审计重放映射器是通过配置配置的；auditreplay.input-path,auditreplay . output-路径和auditreplay.num-threads需要指定审核日志文件的输入路径、结果的输出路径以及每个映射任务的线程数。与中的文件数相等的地图任务数输入路径将会推出；每个任务将读入这些输入文件中的一个并使用线程数重放该文件中包含的事件的线程。尽最大努力以审计日志事件最初发生的速度忠实地重放审计日志事件(可选地，这可以通过指定audit replay . rate-因子这是重放速率的倍增因子，例如使用2.0以两倍于原始速度重放事件)。
审计重放映射器将基准结果输出到一个文件中零件r-00000在CSV格式的输出目录中。每行的格式都是用户、类型、操作、数量、累计量，例如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集群的拆除。若要查看支持的参数的完整列表，请使用-hekp旗帜。
体系结构Dynamometer是在YARN上的一种应用。Dynamometer应用中有三个主要因素:
- 基础设施是模拟的HDFS集群。
- 工作负载模拟HDFS客户端在模拟的名称节点上生成负载。
- 驱动程序协调另外两个组件。
封装在驱动程序中的逻辑使用户能够用一个命令执行测功机的完整测试执行，从而有可能完成诸如扫描不同参数以找到最佳配置之类的工作。
基础设施应用程序被编写为本地YARN应用程序，其中单个名称节点和多个数据节点被启动并连接在一起以创建完全模拟的HDFS集群。为了让测力计提供一个极其真实的场景，必须有一个集群，从名称节点的角度来看，该集群包含与生产集群相同的信息。这就是为什么上述设置步骤包括首先从生产名称节点收集FsImage文件，并将其放在主机HDFS群集上。为了避免复制整个集群的数据块，测力计利用了存储在数据块中的实际数据与NameNode无关的事实，NameNode只知道数据块元数据。测力计的区块生成作业首先使用离线图像查看器将FsImage转换为XML，然后对其进行解析以提取每个区块的元数据，然后在将这些信息放在HDFS上供模拟数据节点使用之前对其进行分区。模拟数据数据集用于绕过数据节点存储层，仅存储从上一步提取的信息中加载的块元数据。该方案允许测力计将许多模拟数据节点打包到每个物理节点上，因为元数据的大小比数据本身小许多数量级。
为了创建与生产环境相匹配的压力测试，测力计需要一种方法来收集有关生产工作量的信息。为此，使用了HDFS审核日志，其中包含针对名称节点的所有面向客户端操作的真实记录。通过重放此审核日志来重新创建客户端负载，并运行模拟数据节点来重新创建集群管理负载，测力计能够提供生产名称节点条件的真实模拟。
一个负载很重的名称节点每秒可以服务数万个操作；为了产生这样的负载，Dynamometer需要许多客户提交请求。为了确保每个请求与其原始提交具有相同的效果和性能影响，Dynamometer尝试以保留其原始顺序的方式提出相关请求(例如，创建目录，然后列出该目录)。正是出于这个原因，建议按照源IP地址对审计日志文件进行分区，假设来自同一主机的请求比来自不同主机的请求具有更紧密耦合的因果关系。为了简单起见，压力测试作业被编写为仅映射的MapReduce作业，其中每个映射器使用一个分区的审核日志文件，并针对模拟的NameNode重放其中包含的命令。在执行期间，会收集有关重播的统计信息，例如不同类型请求的延迟。
