hadoop的python库_python有大量机器学习库，但是不能结合hadoop，该如何实现大规模的机器学习？...

这个也是我们一直在思考的问题。

这里我们不考虑深度学习，因为深度学习和传统机器学习的 workload 是完全不同的，传统机器学习一般会在整个数据集上做训练等工作，而深度学习主要是以 batch 为单位，所以深度学习的 pattern 是数据小、模型大。

拿 Python 世界做机器学习最主流的库 scikit-learn(简称 sklearn) 来说，我们如果看它的代码，会发现绝大部分实现都是基于 numpy 的，主要是把算法用矩阵的操作来描述。当然有些操作不容易用矩阵描述，因此 sklearn 里也会有一些代码会用 Cython(把类 Python 代码编译到 C/C++)来实现。

Numpy API 简单，效率也不错。但有个问题，绝大部分操作不能用到多核。只有比如 dot(GEMM)和线性代数的一些操作能利用到多核。如果你用 sklearn 比较多，就知道有个无处不在的 n_jobs 参数，这个参数默认是 -1，也就是说，默认其实是 CPU 核的个数。这说明了，sklearn 其实会利用多核来加速计算。它内部用了一个叫 joblib 的库，来并行执行多个 embarrassingly parallel 的函数。

所以，我们总结下 sklearn：算法容易用矩阵操作来描述，因此，sklearn 内部绝大部分操作用 numpy 实现，不仅表达力很好，性能也不错。

sklearn 用 joblib 来在多核架构上加速。

那为什么还需要 mahout、Spark ML 呢？很简单，那是因为 sklearn 只能用单台机器来计算，因此必须受限于单机的内存，和计算能力。

然而，甭管是 mahout 还是 Spark ML，他们要描述算法只有这几条路：MapReduce，把算法拆成 map 和 reduce 两个操作实现，我们知道 map 和 reduce 之后都要落盘，机器学习算法又需要大量的迭代。所以，基于 MapReduce 虽然数据量上去了，计算时间也蹭蹭上去了。

RDD，RDD 扩展了 MapReduce 的表达能力，从函数式编程接口演化而来，它的好处是更容易描述出 pipeline 的操作，让更多窄依赖的代码得到优化。然而，RDD 只是一种编程模型，它并不描述数据长啥样，因此，如果你要实现各种机器学习算法，你的工作量是海量的，因为没有 矩阵操作 这种更适合用来描述机器学习算法的方式，所以，每个机器学习算法的实现都需要大量工作，需要非常多 tricky 的实现。

SQL，现在 Spark 大力推广的都是 Spark SQL，他不仅有编程模型，也有数据的定义(DataFrame 或者 Dataset)。然而，SQL 的表达里更多在 ETL 上，用来做机器学习有点勉为其难了。

还有一点，无论上 mahout 还是 spark，都和 GPU 没有太大关系。(Spark 3.0 的 project hydrogen 支持调度到 GPU 上，但没有根本解决表达力的问题)。

所以，分析到这里，其实我们需要的是一个矩阵的实现，它支持大规模的数据，此外有 numpy 的表达能力。这样，不光机器学习算法的实现，更优雅和自然(矩阵描述)，性能也不错，此外，矩阵也很容易 offload 到 GPU 上计算。

那为什么 Spark 不支持矩阵的操作呢？其实历史上有很多这样的尝试，都失败了。这个有空我们可以来探讨分析下，我的观点是，Spark 这种粗粒度的调度器实际上不适合用来描述矩阵的运算。

讨论了这么多，这也是我们 Mars 项目 从并行和分布式 numpy 开始的原因，我们需要处理大规模的矩阵和多维数组的能力，能用 GPU 计算。而在这基础上构建 Mars learn 模块来实现机器学习算法。实际上，我们从 sklearn 能相对轻松移植算法到 Mars learn，甚至都不需要搞明白算法是怎么实现的。

但这仍然需要大量的工作，而这么做就对我们的 Mars tensor(分布式 numpy)有了更多要求，numpy 的算子覆盖，并行和分布式的性能问题，等等等等。这并不容易。