- 接口要做数据格式校验
- 考虑去重的问题
- Pod 在 IO 操作时没有做限流，同时 Pod 有大文件传输，导致 IO 过高
- Kafka、MySQL 等不要和不必要的 Pod 放在同一个 node 上。K8S master 节点也不要有不必要的 Pod 运行。否则稳定性不能保证。
- 增加监控
- ceph 的了解
- shutil.move(src, des)
src 不能是 des 的字文件夹，否则报错。比如，从’/tmp/test/hi’ 移动到 ‘/tmp’ 下面是不行的。 - 注意不同存储介质之间的文件传输，此时就需要网络参与进来。
node-selector、tolerance 应用：
- K8S 主节点配置 tolerance，保证测试 POD 不会影响到主节点上关键 POD 运行，避免出现整个集群崩溃的问题。
- K8S GPU 节点配置了断网，所以如果 POD 需要使用网络，那么就要使用 nogpu 的 node-selector，避免分配到 GPU 节点上。
- GPU 种类不同，A10、A100 也配置了对应的 node-selector。需要用 A10 或者 A100 的就配置对应的 node-selector。避免需要 A100，但是只写 nvidia-smi gpu num 被分配到 A10 机器上。当然后来，每个榜单限制了使用的机器资源。
- 后来 K8S 引入了不同类型的 CPU，原因在于 TCO 榜单，需要 CPU 密集运算 & 追求性能的榜单，CPU 种类不同性能是不一样的。为了保证结果的可比性，为每个 CPU 类型增加了对应的 node-selector。并选择更符合客户场景的 CPU 节点进行测试。
AutoML 二分类榜单建设时，光大大的建议：
在实际业务使用中，模型的训练数据并非一定是实时最新的，另外在预测的时候，特征也并非是实时最新的。用户特征属性会不断变化、物品特征会不断变化，在预测阶段实时的去获取全量数据的最新值是不现实的，一定会存在一定的延时性。所以在训练的时候也就需要按照实际业务中的特性，如果是每天更新一次数据特征，那么就需要允许一天的特征延迟。
所以二分类建榜单的时候，数据集方面是按照时间顺序进行的数据批次的划分。例如第一天的商品表、用户表、请求表、label 表，接下来是第二天的商品表、用户表、请求表、label 表。在训练的时候，使用前 n 天的数据进行训练；在预测的时候，用前 n 天的数据以及当天的请求信息进行预测。
除此之外，后来又增加了数据回流接口。在请求发送一段时间后，请求的结果会回传给被测服务，供被测服务进行滑窗操作。