大数据与机器学习融合
更多的线性代数和可扩展计算
我最近与柏林工业大学的学生进行了两次非常有趣的讨论，我了解了机器学习社区和大数据社区之间的鸿沟有多大。
线性代数和函数集合
一位学生正致力于使用几年前我使用Flink和Spark等下一代大数据框架作为他的硕士论文的一部分。他选择这种算法是因为它涉及的操作非常简单：计算标量乘积，矢量差和矢量范数。可能最复杂的是计算累计和。
这些都是归结为线性代数的运算，整个算法是以线性代数表示的伪符号中的几行代码。我想知道使用更多“函数集合”风格的API来制定这个过程有多困难。
例如，为了计算矢量的平方范数，必须对每个元素进行平方并对它们进行求和。在C语言中，你会这样做：
double squaredNorm （ int n ， double a [ ] ） {
double s = 0 ;
for （ i = 0 ; i < n ; i ++ ） {
s + = a [ i ] * a [ i ] ;
}
return s ;
}在Scala语言中，代码如下
def squaredNorm(a: Seq[Double]) =
a.map(x => x*x).sum在某种程度上，这里的主要挑战在于将这些for循环分解成由语言提供的这些序列基元。另一个例子：标量积（两个向量的相应元素的积的和）将变为
def scalarProduct(a: Seq[Double], b: Seq[Double]) =
a.zip(b).map(ab => ab._1 * ab._2).sum等等。
现在转向一个像Flink或Spark这样的系统，它提供了一组非常类似的操作并且能够分配它们，应该可以使用类似的方法。然而，第一个惊喜是在分布式系统中，没有顺序的概念。它其实更像是一个集合。
因此，如果您必须计算矢量之间的标量乘积，则需要扩展存储的数据以包含每个条目的索引，然后您首先需要连接索引上的两个序列以便能够执行映射。
这个学生还没有完成，但已经花费了大量的精神工作来重新思考新标准中的标准操作，最重要的是，他们对底层系统有信心，它可以执行一些操作，比如连接向量，使元素以巧妙的方式对齐。
我认为这里的主要信息是机器学习者真的喜欢用矩阵和向量来思考，而不是那么多的数据库和查询语言。这就是论文中描述算法的方式，人们思考的方式以及人们接受训练的方式，如果在Spark或Flink上面有一层图层，这将非常有帮助。在这方面已经有一些活动，如Spark中的分布式矢量或Mahout中的spark-shell，我很感兴趣它们是如何发展的。
大数据与大计算
另一个有趣的讨论是与博士进行的。他使用机器学习来预测固态物理的性质。他显然不太了解Hadoop，当我向他解释它时，他也发现它一点都不吸引人，尽管他在组集群上花了相当长的时间进行计算。
在TU Berlin有一个中等规模的机器学习小组。它由大约35个节点组成，承载了大约13TB的数据，用于过去10年左右的各种研究项目。但该集群并不在Hadoop上运行，它使用的是Sun的gridengine，目前由Univa维护。这是有历史原因的。实际上，目前的基础设施已经发展了很多年。这是实验室中分布式计算的简史：
早在二十一世纪初，人们仍然在办公桌下安装台式电脑。当时，尽管我认为磁盘空间已经通过NFS共享（可能主要是出于备份的原因），但人们在自己的计算机上完成了大部分工作。随着人们需要更多的计算能力，人们开始登录到其他计算机（当然，在询问是否确定之后），以及当时购买的几台较大型计算机。
这在很长一段时间内都不太顺利。首先，手动查找有空闲资源的计算机是非常麻烦的，通常，您的计算机会变得非常嘈杂，尽管您自己没有做任何工作。因此，下一步是购买一些机架服务器，并将它们放入服务器室，仍然使用NFS共享的相同的集中式文件系统。
下一步是阻止人们登录到单独的计算机。取而代之的是安装了gridengine，它允许您以shell脚本的形式提交作业，以便在集群中有空闲资源时执行。在某种程度上，gridengine就像YARN，但仅限于shell脚本和交互式shell。它有一些更高级的功能，但是人们通常提交它来在集群中的某个地方运行他们的程序。
目前情况已经有所发展，例如，NFS现在通过光纤通道连接到SAN，并且存在用于交互作业和批处理作业的不同插槽，但结构仍然相同，并且工作正常。人们将它用于matlab，本地代码，python和其他许多东西。
我认为这个系统仍然有效的主要原因是在这里运行的工作大多是计算密集型的，没有太多的数据密集型。大多数情况下，系统用于运行大批量的模型比较，在基本上相同的数据集上测试许多不同的变体。
大多数作业遵循相同的原则：他们最初将数据加载到内存中（通常不超过几百MB），然后计算几分钟到几小时。最终，生成的模型和一些性能数字被写入磁盘。通常，这些方法非常复杂（毕竟这是ML研究）。将其与典型的“大数据”设置进行对比，您可以在其中获得数TB的数据并运行相对简单的分析方法或在其上搜索。
这里的好消息是，今天最需要的可扩展计算并不复杂。因此，这不是关于MPI和计算工作人员，而是关于支持管理长时间运行的计算任务，处理工作依赖问题，故障快照等问题。
从大数据到复杂方法？
就我看到的方式而言，迄今为止，大数据主要是由于需要以可扩展的方式处理大量数据，而这些方法通常非常简单（至少在机器学习研究中是这么简单）。
但最终，更复杂的方法也将变得相关，因此可扩展的大规模计算将变得更加重要，并且甚至可能是两者的组合。目前已经有大量的工作用于大规模计算，例如来自运行物理学或电气学中的大规模数值模拟的人员，但数据库人员更少。
另一方面，机器学习者有很多潜力，可以开创新的可能性，以互动的方式处理大量数据，而像gridengine这样的系统根本不可能实现。
当这两个领域趋于一致时，必须做一些工作来提供正确的机制和抽象集。现在我仍然认为，在未来几年里，我们需要缩小一下这个相当大的差距。