2021-07-21
SC'20: HPC I/O throughput bottleneck analysis with explainable local models
作者背景：Texas A&M University+ANL
简评：本文这类工作是典型的dirty work，而且很难得出什么结论，但是这类事情总是要有人做一做试一试，万一后人能从其中得到点什么呢。本文的结论也是看似有结果，但是实际上没什么用，真实环境也不会用的内容。
abs：
HPC中性能提升在I/O这里有瓶颈。本文分析了超算Theta多年的Darsh日志，试图找到poor I/O throughput的原因
1. intro 泛-精-专
泛：
因为HPC系统的复杂性，我们对HPC系统的运行时计算通讯存储的行为还存在很大的盲区。尤其是HPC的应用特征差异也非常大。
精：
理解IO的利用率很困难，现阶段，编程者和管理员只能靠着有限的观察，轶闻，零散的个人经验来设计应用模式或者从node级别或者系统级别来管理运行时系统。这种手工作坊式的工作存在很大的问题。需要automated data-driven的方法来解决。
直觉上的解决方案不但包括隔离情况下的单个应用特征，还要考虑减少数据的共性，简化建模的开销，探索跨应用的性能提升方案。
吞吐和数据大小以及处理器的个数存在一定相关性
所以打算用ML的方法，但是可解释性和效果之间存在权衡。本文建立一个可解释性的模型，解释如 如何对应用聚类，新来一个任务或应用应该如何归类，效果如何等问题？
贡献：
- 提出一个基于日志分析的特征提取pipeline，三年8w+数据
- 使用agglomerative clustering的模型
- 使用各种ML模型，预测误差在20%内，
- 建立了一个模型Gauge来进行特征的pipeline和聚类，可以根据不同的数据粒度和可解释性的IO吞吐量来分析IO
- 还搞了一个工具的网页版本介绍，https://ascslab.org/research/gauge/index.html
2. EXPLORATION OF THE APPLICATION SPACE
2.1 Darshan 工具
可以记录应用IO的数据，记录了3年，覆盖了系统28%的作业
本文主要关注：POSIX and MPI-IO，只选了POSIX ，因为POSIX 覆盖范围比MPI-IO广。
The POSIX module measures 86 features，we appended 10 Darshan metaparameters
一共96个特征？
2.2 数据消毒和规则化
删掉错误数据的任务和缺失值较多的feature，随时间变化引入的新特征也被忽视。
We remove common access size features and all time-sensitive features
加入时间信息的训练效果远好于完全没有时间效果的数据。
由于数据的量级差的特别大，所以我们对数据进行了规整，比如用百分比，或者取对数等
We are left with 45 percentage features and 12 logarithmic features
筛选罪业，从66万的数据里面选了9万出来，主要选取的是大作业，大作业传输的数据是小作业的60倍。未来的工作可以分析小作业的数据。
因为数据的局限性，本文的工作不是发掘既定时间内的io特征，而是朝着可解释性的方向发展，如如何判断好的IO特征
2.3 探索数据结构
数据整理好了，开始建模分析
9w个作业，每个作业57个特征（45个日志特征，12个算数特征），作业主要来自于占整体50%的6个大应用，
选了6种应用，每个应用选16个数据来进行io分析
rich structure
本文使用HDBSCAN对数据进行分成，然后更具分枝的情况，给所有数据划分了四个大类。
2.4 解释数据结构
为了解释数据聚类的原因，我们通过训练决策树来找原因，当决策树depth=1，depth=2的时候，我们观察决策树分类的依据。决策树的分类理由虽然造成很大的数据不平衡，但是决策树的准确度非常高98%，从侧面验证了分类决策的准确性。
凑字数内容：需要选择好数据分析的粒度，太细了会对单个作业进行分析，太粗了无法得到我们想要应用的特征。
3. 应用的IO特征
在我们可以解释IO运行的原因之前，我们试着先去预测IO的结果。
3.1 io的吞吐量度量衡
首先定义一个衡量准确度的指标，常用的L1，L2可能不太行，因为我们数据的量级差距太大，因此，本文选择了root mean squared logarithmic error (RMSLE) and mean absolute logarithmic error (MALE)
ML模型是规模无关的，应该同等惩罚相对的预测误差，无论是小和大吞吐量的工作
3.2 IO性能建模
传统的ML模型用了一个遍，最后选择了XGBOOST，
We have evaluated a number of different types of ML models, such as linear regression, decision trees, random forests, gradient boosting machines, and neural networks, and have chosen to use XGBoost
预测误差在1.2x左右，这在HPC领域算是蛮好的了，因为IO的吞吐量级变化特别大。再想降低误差比较难了，因为诸如系统竞争这类问题在实现系统中很难被囊括到模型中考虑
这里提到一个名词 I/O weather，这个对模型预测的准确度影响较大。
本文利用统计学的方法permutation feature importance (PFI)，来评估每个特征对训练模型输出的影响。这个方法保证输入数据的分布特征不变，但是不带特征信息。
实验证明时间信息对模型有很大的影响，为了学习io和吞吐量的关系，模型中去掉了时间信息
4. IO模型解释
我们用一个博弈论的理论来解释黑盒的ML模型，SHapley Additive exPlanations (SHAP)
建立了一个tool来动态分析不同的数据特征，不同的算法分析结果。
这套系统可以自动的分析数据，并用图形的方式展示出来
5. case study
现有分析io的工作，常常是聚焦于用户关注的特定应用，通过io分析可以得到非常好的性能提升。但是这些工作忽视更广泛的共性的特征。
本章节分析之前分类出的四个大类，以期指导生产系统Theta的优化工作。
5.1 集群A
5.2集群B
5.3 集群C
5.4 集群D
6. 相关工作
IHPC系统中IO瓶颈问题业已分出几类研究。一类是对实际运作下的文件系统IO的观测，另一类是软件层面的观察方法，包括 TAU [22], Paraver[23], SCALASCA [24], Paradyn [25], and Darshan，这些软件监控HPC运行时的IO数据，利用专家的insight来进行分析，可以更好的优化性能。
由于并行文件的复杂性和应用的复杂性，研究人员利用ML的方法来建模IO的特征。
监督的方法和无监督的方法都有很多相关工作。
本文的方法结合了无监督学习和有监督的方法。
7.未来工作
探索外部因素对IO的影响
提升模型的泛化性能和可解释性
研究本文模型中出错的原因。
8. 结论
编写和调试HPC的应用需要非常专业的领域知识，而且需要编程者对HPC即将运行的系统有非常深刻的认识。启发本文工作的原因是，HPC的编程人员和系统的管理者希望找出HPC应用无法充分利用IO的原因。虽然专家可以分析单个case并找到解决方案，但是我们希望要一个无监督的，自学习的系统来进行分析，于是本文推出了Gauge，对ALG的超算数据进行了分析和结果展示。
网友评论