阿里巴巴集群跟踪数据 Cluster Data V2017翻译文档

原文链接：https://github.com/alibaba/clusterdata/blob/v2018/cluster-trace-v2017/trace_201708.md
以下阿里巴巴2017年公布的集群跟踪数据集（ Cluster Data V2017）,在公布该数据集以后，该公司又公布了 Cluster Data V2018，但由于2018数据集中有些数据情况说明并不详细，故翻译下2017的文档，以提供思考

概述：

---

阿里巴巴集群跟踪计划由阿里巴巴集团发布。通过提供来自实际生产的集群跟踪，该计划帮助研究人员、学生和对该领域感兴趣的人更好地了解现代互联网数据中心 （IDC） 的特征和工作负载。

到目前为止，已经发布了两个版本：

• 集群跟踪-v2017在12小时内包括约1300台机器。跟踪-v2017首先引入了在线服务（又名长运行应用程序）和批量工作负载的搭配。

• 集群跟踪-v2018包括约4000台机器，在8天的周边。除了比 Trace-v2017 具有更大的缩放器外，此件跟踪还包含我们生产批次工作负载的 DAG 信息。

  我们的动机

  ---

  正如最初所说，我们发布这些数据的动机是帮助相关领域的人们更好地了解现代数据中心，并为研究人员提供生产数据，以改变他们的想法。你可以随地使用跟踪，只要它是为重新seach或研究的目的。

  从我们的角度来看，这些数据是为了应对阿里巴巴在IDC在线服务和批量工作并存方面面临的挑战。我们将挑战作为以下主题来提炼：

  1. 工作负载特征。如何以具有代表性的方式模拟各种生产工作量，以对阿里巴巴的工作量进行定性，以便进行调度和资源管理战略研究。
  2. 将工作负载分配给机器的新算法。如何分配和重新安排工作负载到机器，以便更好地利用资源，并确保不同应用的性能 SLA（例如，通过减少资源争夺和确定适当的专业版）。
  3. 在线服务调度器和批次作业调度器之间的协作。如何调整在线服务与批量作业之间的资源配置，提高批次作业的吞吐量，同时保持可接受的QoS（服务的可口性）和在线服务快速故障恢复。随着配置规模（由不同调度员管理的工作量）不断增加，协作机制的设计也变得越来越重要。

  最后但并非最不重要的一点是，我们始终愿意与研究人员合作，提高我们集群的效率，并且有为研究实习生开放的职位。如果您有任何想法，请通过Aliababa 聚类数据或海阳鼎联系我们（海阳维护此集群跟踪，并为阿里巴巴的资源管理和调度组工作）。

  介绍

  随着数据中心规模的增长，大规模在线服务和批量作业共同分配用于提高数据中心效率。共同分配给现有的集群管理系统带来了巨大挑战，特别是对服务和工作调度员的挑战，它们必须共同努力，提高集群的利用率和效率。

  我们提炼出我们认为对学术界和工业界都感兴趣的以下研究主题的挑战：

  • 工作负载特征：我们如何以一种具有代表性的方式模拟各种生产工作量来描述阿里巴巴的工作量，以便进行调度员研究。
  • 将工作负载分配给机器和 cpu 内核的新算法。如何分配和重新调整工作负载到不同的机器和cpus，以更好地利用资源和可接受的资源争夺。
  • 在线服务与批量作业调度合作：如何调整在线服务与批量作业之间的资源配置，提高批次作业的吞吐量，同时保持可接受的服务质量和在线服务快速故障恢复。

  为了帮助研究人员解决上述问题，我们提供 24 小时内从生产集群中获取的微量数据。数据包括部分机器和整个集群的工作负载。所有机器包括可以同时运行在线服务和批量作业。

  通用技术和领域

  出于保密原因，我们混淆了跟踪中的某些信息

  时间和时间戳

  跟踪中的每个记录都包含一个时间戳，该时间戳在几秒钟内，相对于跟踪周期的开始。此外，0 的时间表示事件发生在跟踪期之前。在某些文件中，有一小部分条目（例如，少于 0.1%）带有负时间戳，它们还指示事件发生在跟踪开始时间之前。batch_instance.csv

  使用情况（包括实例和机器使用情况）的测量以 60 秒的时间间隔进行，平均超过 300 秒。出于保密原因，我们仅连续 12 小时披露使用数据。

  唯一标识符

  每台机器、在线和服务工作负载都给出一个数字 ID，这在跟踪期间是独一无二的。未提供服务和任务名称。

  资源单位

  大多数资源利用测量和请求已归一化，包括：

  • 内存大小
  • 磁盘空间

  Cpu核心计数未归一化

  数据表

  下面我们描绘对所提供的表。提醒：并非所有跟踪都将包括此处描述的所有类型的数据。列可能以不同的顺序出现，或者名称与此处报告的名称不同：此类详细信息的最终规范可以在schema.csv文件中找到。

  机器

  ---

  机器由两个表描述：机器事件表和机器资源利用表

  机器事件

  1. 时间戳
  2. 机器
  3. 事件类型
  4. 事件详细信息
  5. 容量：CPU
  6. 容量：内存
  7. 容量：磁盘

  此跟踪包括三种类型的机器事件：

  • add。集群中可用了一台机器。跟踪中的所有机器都有 ADD 事件，并且具有值为 0 的时间戳，因为所有机器都是在跟踪收集之前添加的。
  • softerror。由于软件故障（如低磁盘空间和代理故障），机器暂时不可用。
  • harderror。由于硬件故障（如磁盘故障），机器无法使用。

  在软件和硬件错误的情况下，不应将新的在线服务和批量作业放置在机器中，但现有服务和作业仍可能正常工作。错误原因可以从事件详细信息字段中推断。

  机器容量反映了每个维度的每台机器的规范化物理容量。每个维度（CPU 内核、RAM 大小）均独立正常化。

  机器利用率（server_usage.csv）

  1. 时间戳
  2. 机器
  3. 使用率：CPU
  4. 使用率：内存
  5. 使用率：磁盘
  6. load1：linux cpu负载平均为1分钟
  7. load5: linux cpu load average of 5 minute
  8. load15: linux cpu load average of 15 minute

  机器利用率是100的一小部分，反映了包括操作系统在内的所有工作量的总资源使用量。

  批量工作负载

  这些表描述了批次工作负载：

  • 实例表
  • 任务表

  用户以作业的形式提交批量工作负载（该工作量不包括在跟踪中）。工作包含多个任务，不同的任务执行不同的计算逻辑。根据数据依赖性，任务形成 DAG。实例是批次工作负载的最小调度单元。任务中的所有实例执行完全相同的二进制文件，具有相同的资源请求，但具有不同的输入数据。

  任务表（batch_task.csv）

  1. create_timestamp：任务的创建时间
  2. modify_timestamp：最新状态修改时间
  3. job_id
  4. task_id
  5. instance_num：任务实例数
  6. state：任务状态包括Ready|Waiting|Running|Failed||Cancelled（取消）
  7. plan_cpu：每个任务的cpu需求
  8. plan_mem：任务的每个实例都标准化内存需求

  实例表（batch_instance.csv）

  1. start_timestamp：实例启动时间（如果实例已启动）
  2. end_timestamp：实例结束时的实例结束时间
  3. job_id
  4. task_id
  5. machine_ID：运行实例的主机
  6. state：实例状态包括已Ready | Waiting | Running | Terminated | Failed | Cancelled (取消)| Interupted（互换）
  7. seq_no：运行试验编号，从1开始，每次重试增加1个
  8. total_seq_no：检索总数
  9. real_cpu_max：实际实例运行的最大cpu数
  10. real_cpu_avg：实际实例运行的平均cpu数
  11. real_mem_max：实际实例运行的最大规范化内存
  12. real_mem_avg：实际实例运行的平均规范化内存

  由于机器故障或网络问题，批次实例可能会失败。实例表中的每个记录记录一次尝试运行。在某些情况下，开始和结束时间戳可以是0。例如，在准备和等待状态下，所有时间戳为零：例如，在运行和失败状态中，开始时间为非零，但结束时间为零。

  在线服务

  这些表描述了在线服务：

  • 服务实例事件
  • 服务实例使用率

  服务实例事件（container_event.csv）

  1. ts：事件的时间戳
  2. event：事件类型包括：Create 和 Remove
  3. instance_id：在线实例ID
  4. machine_id
  5. plan_cpu： 请求的 cpu 号码
  6. plan_mem：要求规范化内存
  7. plan_disk：要求的规范化磁盘空间
  8. cpuset： 由在线调度器分配 cpuset， 由 “|” 划定 cpus

  此跟踪仅包括两种类型的实例事件。每个创建事件都会记录在线实例创建的完成，每个删除事件都会记录在线实例删除的完成。对于在跟踪期之前创建的容器，ts 字段的值为零。实例创建和移除的开始时间可以从完成时间推断，因为创建和删除通常在几分钟内完成。

  每个在线实例都根据 cpu 拓扑学和服务限制，由在线调度器提供独特的 cpuset 分配。对于数据集中的 64 cpus 计算机，0 到 31 的 cpus 位于相同的 cpu 包中，而 32-63 中的 cpus 位于另一个 cpu 包中。cpus 0 和 32 属于相同的 cpu 内核，cpu 1 和 33 属于另一个 cpu 内核，等等。cpuset 分配远非理想，例如，通过考虑共享相同 cpu 内核和包的实例之间的干扰水平差异，可以改进。

  服务实例使用情况（container_usage.csv）

  1. ts：测量间隔的开始时间
  2. instance_id：在线实例ID
  3. cpu_util：使用所请求的 cpus 百分比
  4. mem_util：已请求内存的使用百分比
  5. disk_util：已请求磁盘空间的使用百分比
  6. load1
  7. load5
  8. load15
  9. avg_cpi，每个说明的平均周期
  10. avg_mpki：每 1000 个指令的平均上一级缓存遗漏
  11. max_cpi：最高CPI
  12. max_mpki：最大MPKI

  服务实例的 cpu/mem/磁盘利用率相对于所要求的资源，最大利用率为 100（充分利用）。负载指标与分配的 cpus 相对。CPI 和 MPKI 指标在 1 秒内测量，并采集 5 个样本来计算平均值和最大值。

  批处理任务和实例的状态

  • 任务
    • Terminated：当所有实例完成时，任务将转到"终止"
    • Waiting：尚未初始化的任务
    • Failed：任务失败
    • Running：正在处理任务
  • 实例
    • Terminated：实例完成
    • Waiting：实例无法运行，因为它的某些依赖关系尚未完成
    • Running：实例正在对员工进行"运行"
    • Failed：实例失败
    • Interrupted：这是我们为备份实例引入的功能，实例因某些原因而停止

  文件格式

  每个数据表都以CSV格式给出，使用Unix样式的行尾（ASCII-LF）。CSV文件没有标题。所有表的模式也以CSV格式在名为schema.CSV的文件中给出

  已知问题

  以下是当前版本的数据集的已知问题，我们将尝试在下一个版本的数据集中修复它们。

  • 一些task_id和/或job_id在batch_instance.csv失踪。正如第#10期所述的参赛作品中失踪task_id和job_id，同时start_timestamp约在85%在60k到89K之间。
  • container_usage.csv有些instance_id没有出现在container_event.csv，例如，instance_id =9088 和其他一些。
  • batch_instance.csv的使用信息中有一些缺失的数据。