数据搜集与上传

[SAKURA-CAT]

我们即将在v0.3.0版本支持上传到公有云，用户将能够在公网查看其实验数据并在云端托管他们。

在技术层面，我们需要引入多线程以监控、上传实验数据，这将在这个issue中记录具体的技术细节。

[SAKURA-CAT]

为什么是多线程？

1. 多线程适合IO密集型任务，对于swanlab而言会有很多时间花费在数据上传上，所以多线程是个不错的选择
2. 多线程比较轻量级，我们现阶段不想添加过重的负担
3. 内存共享允许swanlab本体在一些数据通讯上更加方便
4. 多进程存在多个数据流问题（#304），目前还不太清楚怎么解决
5. 多进程开销过大，这与swanlab目前比较轻量的定位不太相符

上传时机？

由于我们的文件是分布式的，因此应该有一个上传总线（buffer）去汇集所有的日志数据，再设定时间间隔分片上传。幸运的是watchdog这个库本身多线程执行的，因此所想的方式是可以实现的。
考虑到以后会有系统信息收集等更多功能，所以最终应该有一个事件循环器去在一次循环中处理所有的待处理事项，比如数据上传、处理和信息收集等。

[SAKURA-CAT]

上传类型

对于上传的数据我们将其分为两大类：

1. 媒体类型，这种数据应该是“只要生成就上传”和“只要一改动就重新上传”
2. 日志类型，这种数据在修改时，在原本的文件后追加，在上传时只需上传新追加的数据

对于第一种，又分为两种情况：

• 实验配置信息，通过json、yaml、txt格式存储在files文件夹中——这类数据的特点是可能会出现改动
• 实验日志产物，通过log拿到的实验日志信息——这类信息的特点是一旦生成将不再改动

[SAKURA-CAT]

上传类型

对于上传的数据我们将其分为两大类：

1. 媒体类型，这种数据应该是“只要生成就上传”和“只要一改动就重新上传”
2. 日志类型，这种数据在修改时，在原本的文件后追加，在上传时只需上传新追加的数据

对于第一种，又分为两种情况：

• 实验配置信息，通过json、yaml、txt格式存储在files文件夹中——这类数据的特点是可能会出现改动
• 实验日志产物，通过log拿到的实验日志信息——这类信息的特点是一旦生成将不再改动

就目前而言，为了实现简单，我们不再区分改动还是不改动的问题，只区分上传方式的不同