Flink History Server小文件优化

背景：

通过开启作业归档，JobManger会将结束运行态的Flink作业的统计信息（拓扑信息、运行状态、checkpoint、累加器、异常）归档到远端文件系统。History会从远端下载归档的作业信息并提供查询方式。
一个Flink作业代表平台任务（per-Job集群）的一次运行周期，一个平台任务对应这一个或多个Flink任务。

问题：

随着平台新增任务，以及用户对平台作业的更新迭代操作，归档的作业信息越来越多，很快本地磁盘inode资源就被打满。
通过研究发现主要系存在以下几点：
1、Historyserevr全量下载远端作业归档信息到本地；
2、作业归档信息下载到本地盘后立即解析；
3、单作业的归档信息在HistoryServer本地解析后以多个小文件存储，作业的拓扑结构越复杂、并行度越高，占用的inode资源越多

容器环境inode资源有限，很容易被打满：
几个月时间，已经产生大量历史作业信息：

本地存储格式：

归档文件解析后格式：
Flink ID: 98bb907e56ce49b66448f92ee371a794
Vertices ID： e3dfc0d7e9ecd8a43f85f0b68ebf3b80
示例作业只有一个Vertex，并行度为2，解析后依然存在大量小文件，且文件数量与作业拓扑的复杂度以及作业并发呈正比例关系。

├── accumulators.json
├── checkpoints
│   ├── config.json
│   └── details
│       ├── 175054
│       │   └── subtasks
│       │       └── e3dfc0d7e9ecd8a43f85f0b68ebf3b80.json
│       ├── 175054.json
        .......

│       ├── 175062
│       │   └── subtasks
│       │       └── e3dfc0d7e9ecd8a43f85f0b68ebf3b80.json
│       ├── 175062.json
│       ├── 175063
│       │   └── subtasks
│       │       └── e3dfc0d7e9ecd8a43f85f0b68ebf3b80.json
│       └── 175063.json
├── checkpoints.json
├── config.json
├── exceptions.json
├── plan.json
└── vertices
    ├── e3dfc0d7e9ecd8a43f85f0b68ebf3b80
    │   ├── subtasks
    │   │   ├── 0
    │   │   │   └── attempts
    │   │   │       ├── 0
    │   │   │       │   └── accumulators.json
    │   │   │       └── 0.json
    │   │   └── 1
    │   │       └── attempts
    │   │           ├── 0
    │   │           │   └── accumulators.json
    │   │           ├── 0.json
    │   │           ├── 1
    │   │           │   └── accumulators.json
    │   │           ├── 1.json
    │   │           ├── 2
    │   │           │   └── accumulators.json
    │   │           ├── 2.json
    │   │           ├── 3
    │   │           │   └── accumulators.json
    │   │           ├── 3.json
    │   │           ├── 4
    │   │           │   └── accumulators.json
    │   │           └── 4.json
    │   ├── subtasktimes.json
    │   └── taskmanagers.json
    └── e3dfc0d7e9ecd8a43f85f0b68ebf3b80.json

优化方案

1、引入平台任务维度信息，支持按作业维度下载最近N个作业归档文件
2、惰性解析，下载归档文件到本地，当有用户查询指定作业的信息再按需解析归档文件，避免小文件膨胀
3、定期清理归档文件与长时间未访问的解析文件

效果对比

inode使用从12699886下降到6311，减少2000倍。磁盘占用也显著下降
在这里插入图片描述

优化后HistoryServer本地文件存储结构：

/data/apps/historyserver# tree -L 3
.
├── archive // 下载到本地的归档文件
│   ├── 00476c2a91627914bbb0f76d41c1a261.archive
│   ├── 004900ceaa73d068ecc1607f58a7129b.archive
│   ├── 004be39ba36ae050b3b503ec55b12999.archive
│   ├── fa0954d99a5141194a95e0872743baa9.archive
│   ├── fa2170276f60e144e9c18f887cec5e61.archive
│   ├── fa57445a74a9f5cd29f7ac2d87455a19.archive
│   ├── faa1fecf21c6cdd7ae6fb486f27f3e04.archive
        ......
│   ├── 0398f323b79e07d8dfded4bb063605f2.archive
│   ├── 03e0857d5133f6644a6f025c868a3ee5.archive
│   ├── 03fc00fc976f68af029a0213ef5c1a70.archive
│   ├── 0415d22674e11bcd6e9424c4571d8b4b.archive
    // 最近存在访问查询的热点作业已解析成详情文件
├── jobs
│   ├── 53babd711d9b3d3669a30a61312ede34
│   ├── 53babd711d9b3d3669a30a61312ede34.json
│   ├── 5b14f9b76bec05a8eafb730a4cf3f7dc
│   ├── 5b14f9b76bec05a8eafb730a4cf3f7dc.json
│   ├── 60f72d31508396da33f53cab004d1420
│   ├── 60f72d31508396da33f53cab004d1420.json
│   ├── 94dfa54fe01cce85571d9bc74010a667
│   ├── 94dfa54fe01cce85571d9bc74010a667.json
│   ├── c837ffac45b6067ad68f09bcc53f7a85
│   ├── c837ffac45b6067ad68f09bcc53f7a85.json
│   └── overview.json
├── overviews
│   ├── 53babd711d9b3d3669a30a61312ede34.json
│   ├── 5b14f9b76bec05a8eafb730a4cf3f7dc.json
│   ├── 60f72d31508396da33f53cab004d1420.json
│   ├── 94dfa54fe01cce85571d9bc74010a667.json
│   ├── c837ffac45b6067ad68f09bcc53f7a85.json