原创 xgboost模型保存

6.1.1 默认保存为json文件，默认保存路径：'trained_xgb_models'文件夹下的xgb_model_{timestamp}.json。# 6.2 使用joblib保存模型，默认保存路径：'trained_xgb_models'文件夹下的xgb_model_{timestamp}.pkl。logger.info('模型保存成功，路径为: {}', model_save_path_json)# 6.1.2 保存为 bin 文件。# 6.1.2 保存为 txt 文件。

原创 Xgboost模型评估

logger.info('模型特征重要性: {}', xgboost_model.feature_importances_)# logger.error('请提供二维 np.ndarray 作为输出')# logger.info('预测测试集: {}', predict_result)logger.info('预测测试集: {}', predict_result)logger.info(' --- 检查 XGBoost 模型是否正确')logger.info(' --- 返回特征重要性')

原创 11111111

原创 一文了解Kafka的消息收集器RecordAccumulate

在上一篇文章《连Producer端的主线程模块运行原理都不清楚，就敢说自己精通Kafka》中，我们介绍了。在介绍原理之前，大家再重温一下Producer端的整体架构，图示如下所示：这个图看不懂没有关系，我们会在介绍Producer端原理时一一介绍每个部分的含义及其所复杂的功能。

原创 kafka生产者性能相关的参数理解

一个消息发送后在得到服务端响应之前，生产者还可以发送的消息条数，配合retries使用，可以保证消息的顺序性，假设有两条消息A、B，A先发送但失败了在执行重试时，B发送且成功了，之后A也重试成功了，此时A、B消息顺序就反了，如果将此参数设置为1，则可以保证A在重试时，B消息无法进行发送，必须等A收到broker响应后B才能发送，设置较高可以提升吞吐量，但会占用更多的内存，设置过高反而会降低吞吐量，因为批量消息的效率降低。发送到broker的请求将包含多个批处理，每个分区一个批处理，其中包含可发送的数据。

原创 【无标题】

acks=all ：只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应。# acks=1 ： 只要集群的首领节点收到消息，生产者就会收到一个来自服务器成功响应。# 值的序列化方式（建议使用Json，这种序列化方式可以无需额外配置传输实体类）# acks=0 ： 生产者在成功写入消息之前不会等待任何来自服务器的响应。# 发生错误后，消息重发的次数，开启事务必须设置大于0。# 开启事务，必须在开启了事务的方法中发送，否则报错。# 生产者内存缓冲区的大小。# Kafka服务器。

原创 【无标题】

【代码】【无标题】

原创 11111111111

1。