简介：阿里巴巴生产集群追踪数据（clusterdata）是用于集群管理研究的公开数据集，主要面向数据中心调度、工作负载分析与资源管理方向的研究人员、学生及开发者。该数据集来自阿里巴巴集群追踪计划，包含 cluster-trace-v2017、v2018 与 GPU v2020 三个版本，分别覆盖 1300 台机器 12 小时、约 4000 台机器 8 天以及 GPU 集群信息，可用于理解现代 IDC 特征、在线服务与批处理作业混部、DAG 依赖关系等典型场景。资源包共 32 个文件，大小 16.22MB，内含 CSV/schema 数据表、Markdown 说明文档、Python 分析脚本与 Jupyter Notebook，方便读者直接加载数据进行初步探索与可视化复现。目前已有 1156 人学习下载。对从事云资源调度、集群追踪分析或科研复现的读者而言，这份压缩包提供了完整的原始字段定义、版本说明与图表示例，可帮助快速上手并理解阿里巴巴生产环境的真实负载特征。
1. 先说清楚：这套数据到底能干什么
做集群管理和资源调度的同学，大概率都碰到过一个尴尬：想验证调度算法、想研究资源利用率，却找不到一份真实的生产数据。模拟器生成的工作负载跟现实差太远，自己搭集群成本又高。阿里公开的 clusterdata 生产集群采集数据，就是为解决这个问题而来的——它是阿里内部生产环境集群运行记录的脱敏版本，覆盖物理机、容器、批处理任务、在线服务等多个维度，专门供集群管理方向的研究和工程实践使用。
这套数据给我的第一感受是“真”：里面的资源申请量、实际用量、任务生命周期、机器状态变化，都带着生产环境的嘈杂感，不像模拟数据那么干净规整。正因为这份“不干净”，用它做出来的结论才更有参考价值。不管你是做调度策略优化、容量规划、混部压力分析，还是研究数据中心的能耗和故障特征，这套数据都能垫底。
适合谁看？我说得直白一点：正在做集群调度相关毕设或论文的研究生，在企业里做资源管理系统、SRE 或云原生平台的工程师，以及想在简历上写下“基于生产级集群数据做过分析”的同学，都值得花一个下午把这份数据吃透。这篇文章就从数据全景、表结构、实操流程、踩坑经验到研究方向，完整过一遍。
2. 数据全景：阿里 clusterdata 不同版本之间差距很大
2.1 从 2017 到 2022，数据形态的演进
阿里公开的集群数据不是一套到底的，目前能拿到的至少有三个阶段，每个阶段的侧重点都不太一样。
最早公开的版本主要面向批处理负载，机器规模很大，数据里能看到 job、task、instance 三层任务模型，以及机器维度的资源使用记录。它的典型用途是做批处理集群调度算法的回放验证，比如传统 MapReduce 类负载的调度对比。
2018 年发布的版本是目前最常用的一套，也是我第一次接触的版本。它的最大变化是引入了在线服务负载，把微服务和批处理任务放在同一份数据里，正好对应阿里内部“离在线混部”的典型场景。机器数量大约几千台，采集周期覆盖数天到十几天，文件格式从原来的压缩文本变成了多个 CSV，字段做了大幅细化，容器维度的用量数据也补全了。
再往后公开的版本加入了 GPU 和异构资源。采集的对象从单一 CPU 集群变成了异构算力集群，监控粒度更细，适合研究 GPU 调度、异构资源分配这类新问题。各版本的具体字段和采样间隔，官方仓库里都有 README 说明，下载前建议先看一眼。
2.2 为什么这套数据比模拟数据值钱
很多人会问：我拿 Workload Generator 或者随机分布生成任务请求，不也能做调度仿真吗？为什么非要折腾一份几十 GB 的生产数据？
原因很简单：生产环境的负载特征是有“脾气的”。它的到达不是平稳泊松流，而是有明显的峰谷节奏，并且跟业务上线周期强相关；它的资源请求和真实使用量之间经常差几倍，很多任务申请了 4 核但实际上只用 0.2 核；它的失败模式也不是均匀的，会出现批处理任务海量重试、在线服务容器频繁迁移等情况。这些特征靠参数模型很难表达，但 clusterdata 里全都有。用真实负载做实验，审稿人和技术评审更容易信服，而且很多结论在模拟数据下根本观察不到。
3. 核心表结构与字段逻辑拆解
3.1 机器维度：machine_meta 与 machine_usage
机器维度是分析的地基。machine_meta 记录的是物理机的静态信息和生命周期状态，典型字段包括机器 ID、CPU 核数、内存大小、机器状态变化事件、事件对应的毫秒时间戳。这里的“状态变化”很关键，因为生产环境里机器会上下线、会故障隔离，不同时间段可用的资源总量是动态的。
machine_usage 则是机器维度的采样数据，每隔几十秒记录一次 CPU 利用率、内存利用率、磁盘读写、网络收发等指标。注意“利用率”在这里通常不是百分比，而是一个归一化值，CPU 用核数或百分比，内存用百分比，具体要看版本字段说明。做总量分析时，需要把它乘回机器总容量才能得到绝对使用量，这个换算细节非常容易踩坑。
用机器维度数据能干什么？比如画一张集群整体 CPU 利用率的时间序列图，能清楚看到负载的周期性；再比如把内存和 CPU 的利用率放在二维平面上，能看出机器资源的匹配程度，这是做资源超卖和容量评估的基础。
3.2 容器维度：container_meta 与 container_usage
容器维度主要描述在线微服务的运行状态。container_meta 里能拿到容器 ID、部署单元、部署组、所属机器、容器开始和结束时间这些信息。注意，在线服务的粒度不是任务，而是一个个常驻容器，同一个服务可能同时存在多个副本，分布在不同的机器上。
container_usage 是容器维度的采样数据，记录了每个容器在采样周期内的 CPU、内存、磁盘、网络用量。这块最值得挖的是“动态画像”：同一类服务的容器，CPU 用量在一天内波动可能非常大；不同副本之间的资源使用也未必均衡。做在线服务调度时，依赖的就是这类细粒度数据，例如做副本迁移、弹性伸缩策略，都需要先分析容器实际用量的分布特征。
3.3 任务维度：batch_task 与 batch_instance
批处理部分用的是两层模型：batch_task 描述任务元数据，比如任务 ID、所属 job ID、申请的资源量、任务类型、重试次数、状态；batch_instance 则描述每个任务实例的运行过程，包括实例 ID、所在机器、创建时间、开始时间和结束时间、实际资源使用量、实例状态。
做调度分析时，我一般先把 batch_task 里的申请量按时间展开，模拟一个“如果我来安排这些任务”的推演过程。然后拿 batch_instance 的实际运行时间和状态去对拍，看真实调度器的决策是什么样，自己的算法和它比好在哪、差在哪。这里有一个非常有价值的小技巧：很多实例是失败重试的，过滤掉状态异常的实例再统计，才能得到有效运行时长，否则平均执行时间会被明显拉偏。
4. 完整实操：从下载数据到产出第一张分析图
4.1 数据获取与存储选型
下载方面不用多说，官方仓库会给出下载地址。需要提醒的是数据压缩后依然有数 GB，解压后的原始 CSV 会膨胀很大，所以第一件事是规划磁盘。个人实践里，我建议直接落盘到本地 NVMe 硬盘，顺序读取速度很重要，因为 CSV 分析基本是纯扫描型负载。
存储格式上，除非你只在做一次性小样本，否则建议第一时间转成 Parquet 或 ORC 列式格式。我自己吃过亏：一开始图省事直接用 pandas read_csv 去读，内存直接被打满，进程被 OOM Kill。后来先把 CSV 用 Spark 转成 Parquet，再做任何统计分析都流畅得多。列式存储对这类“取少数列、扫描全表”的分析负载，收益是数量级的。
如果你的机器内存不大，还有一个折中方案：按天或按机器 ID 做分区抽样，先拿一部分数据验证分析逻辑，确认无误后再全量跑。做研究不是比谁跑的数据大，而是比结论是否可靠，采样分析完全够用。
4.2 时间戳的单位换算与数据清洗
这套数据里时间戳基本都是毫秒级 Unix 时间戳。拿到数据第一步，先把时间戳转成标准时间，并换算成相对时间（以数据集开始时刻为 0），这样画横轴才直观。下面的示例就是用 Spark 做最基础的读取和转换：
val usage = spark.read.option("header", "true") .option("delimiter", ",") .csv("path/to/machine_usage.csv") val df = usage .withColumn("ts_second", from_unixtime(col("timestamp") / 1000)) .withColumn("ts_date", to_date(col("ts_second"))) .na.drop(Seq("cpu_util", "mem_util")) df.groupBy("ts_date") .agg(avg("cpu_util").as("avg_cpu"), avg("mem_util").as("avg_mem")) .orderBy("ts_date") .show()这段逻辑不复杂，但有个细节要注意：原始数据里可能存在采样缺失或异常值，直接求平均会把结果带偏。我通常会先对用量字段做一次范围检查，比如 CPU 利用率落不到合理区间的记录直接过滤掉，再参与聚合。清洗策略要提前定好，不然后续改起来很痛苦。
4.3 复现一个经典指标：在线批处理混部的资源争抢
拿到干净数据后，第一个值得做的分析是“在线服务与批处理任务之间的资源争抢”。具体做法是，把同一台机器上的容器用量和批处理实例用量按时间对齐，叠加求和，再和机器的物理容量比对。
这个分析的结论很有意思：混部场景下，机器的峰值资源需求远大于平均值，说明在线服务的突发流量和批处理的波峰经常叠加。这也是为什么混部集群普遍要做资源隔离和压制，而不是简单地把两份负载加起来就行。数据会告诉你：问题确实存在，而且比预想严重得多。整个过程跑完后，我建议把结果导出成图表存下来，后面写论文或做方案汇报时直接能用。
5. 实际研究里最容易踩的坑
5.1 状态字段语义理解错位
任务和实例都有状态字段，但这套数据的取值含义和标准 YARN 或 Kubernetes 的状态名不完全一样。比如某个状态表示“实例被杀掉重跑”，如果不知道这层含义，统计任务成功率时就会把正常重试当成异常。我处理 batch_instance 时，会把状态维度先做一次 value_counts，把所有枚举值列出来，逐一对照官方说明，确认含义后再定义过滤规则。这个习惯所有用这份数据的人都该养成。
5.2 用量字段的归一化单位混淆
前面提到过，有的版本 CPU 利用率是百分比，有的是归一化小数，内存类似。如果不确认单位，分析出来的“集群利用率”可能整体放大 100 倍，结论完全离谱。建议在数据预处理阶段就把所有用量字段统一转换成“占机器总容量的百分比”，后续所有逻辑都在这个口径上运行。单位口径记录在数据字典里，但 README 写得比较简洁，下载完先花十分钟确认表格字段再动手，能省一晚上的排查时间。
5.3 全量数据跑太久、内存溢出
一个常见的翻车现场：用单机 pandas 读完整份 container_usage，然后 groupby 做聚合，跑了几分钟直接内存爆炸。解决办法分三层：最简单的是换用 Spark 或 DuckDB 这类能“吃”下大数据的引擎；进阶做法是只读取需要的列；再进阶是提前做时间窗口过滤。实际上，大部分研究结论在 10% 的采样数据上就能稳定呈现，不需要全量跑。
5.4 忽略机器上下线对容量计算的影响
集群里每台机器的生命周期不同，有的机器只运行了数据周期的一部分。计算集群总容量时如果直接按机器元数据里的配置求和，会高估实际可用的资源总量。正确做法是按时间片统计“存活机器集合”，再乘以单机容量得到有效总容量。这个问题在短时间尺度的利用率分析里尤其明显，跨天对比时必须处理。
6. 这套数据能支撑哪些方向的研究和落地
6.1 调度算法的离线仿真验证
最直接的方向是用真实负载做调度仿真。你可以把 batch_task 里的任务按提交时间排序，用自己实现的调度器模拟调度，然后对比真实集群的任务完成时间、资源利用率等指标。生产数据的价值在于任务的资源请求和真实运行时长都是有据可查的，仿真出来的结果更有说服力。我自己做调度算法对比时，会固定用同样的负载序列，只改调度策略，这样横向对比才公平。
6.2 集群资源画像与容量管理
通过机器和容器两层的用量数据，可以做非常细的画像分析：不同时间段集群的 CPU 与内存配比是否合理、哪些机器长期低利用率、哪些容器是资源大户、在线服务的峰值时段是什么时候。这些分析结果可以直接指导容量规划和采购决策。比如某段时间集群内存富余但 CPU 紧张，后续扩容就应该偏向 CPU 密集型机器，而不是盲目加同样的配置。
6.3 在线离线混部与资源隔离研究
这份数据里在线服务和批处理任务同时存在，是研究混部最好的素材。方向包括：混部场景下在线服务的 QoS 干扰模型、基于实际用量预测的压制定量策略、突发流量下批处理任务如何优雅退避等。结合容器维度的细粒度用量，还可以做副本级的性能隔离实验。这一块是目前集群管理领域比较热门的方向，数据现成、问题清晰、实验好设计。
再说一个扩展思路：官方数据是脱敏的，但如果你所在的团队也有生产集群，完全可以按照 clusterdata 的格式做一套内部数据采集管道，把这份开源数据的分析方法迁移到自己的集群上。很多企业在做容量治理和调度优化时，缺的不是算法，而是像这样一份“看得懂、能分析、可沉淀”的集群运行数据体系。
我个人实际用下来的最大体会是：这套数据最值钱的地方，不是它有多大规模，而是它把生产环境里那些“书上不会写”的细节都保留了下来。做研究的人面对的不再是理想化的负载模型，而是真实的资源碎片、任务重试、流量毛刺。这些东西，才是集群管理真正的难题所在。
最后分享一个实操层面的小建议：如果你准备拿这套数据做实验，先别急着写高大上的模型。第一步一定是自己动手画几张基础图表，把集群的 CPU 利用率、任务到达曲线、容器生命周期分布老老实实看一遍。等你对这些数据有了手感，再设计实验，效果会好得多。数据这个东西，看十篇文档不如亲手摸一遍。
本文还有配套的精品资源，点击获取
