XGBoost工程探索小记

由于工作需要，最近接触xgboost，尝试使用xgboost来提升推荐博文点击预测的准确度，因此对xgboost进行了一段时间的工程探索。由于有现成的spark集群，使用其提供的xgboost4j-spark方案来进行处理会方便很多，对集群的改动和要求很少，只要打好包进行上传即可运行。但是发现坑很多，并且这方面xgboost做法并不是很成熟。具体有以下几个坑：

1. xgboost与平台强相关，没有已经编译好的包，需要使用git下载项目后，进行本地编译。其中涉及到很多环境方面的问题，比如我使用的mac ox系统，就遇到了gcc、scala、maven等等方面的问题。
2. 解决了上面的问题，我们还要考虑分布式的问题(毕竟小数量自己算着玩儿没有什么太大意义)，xgboost工具本身想要直接利用spark等计算框架进行处理，但却缺乏一个系统的支持，没有清晰的文档来指导你进行maven编译打包，对spark2.X和spark1.X支持情况的描述也几乎为零，且其git上代码中的示例与官网的示例（明显是旧版）有很大出入，给使用者体验极差。在“spark版本”、“scala与maven编译”上有较多的坑。当然，如果你完全符合它的要求（spark2.0.1，scala2.11.8）可以顺利完成编译打包，但是目前业内基本以spark1.6.1为准，会出现很多“莫名其妙”的问题，因此这个方案最终没有成功。

不过根据对部门其他同事的咨询得知：效率最高、最常用运行方式有两种：

1. CLI方式，直接部署在hadoop集群上，使用yarn作为调度，修改配置文件即可运行。这种方式效率速度最快、分布式处理且能够处理的数据量极大，是最推荐的一种方式。缺点是需要建立在成熟的集群之上，并且需要有root权限进行本地编译。官方相关文档详见https://xgboost.readthedocs.io/en/latest/cli/index.html
2. 服务器单机多线程方式，为了方便易用，python当然是最好的选择，因此，xgboost也为我们提供了这种方式。与上述CLI方式一样，同样需要本地编译，且需要numpy, scipy等python第三方库的支持，属于单机运行，不能进行分布式处理。

XGBoost作为各种数据大赛中强力推荐的算法模型和工具，其准确率、效果是很好的，相信其开源项目会在将来更加完善、好用。