对于计算机来说，所谓的计算无非就是将存储在各个地方的数据通过数据总线进行传输，然后通过算术逻辑单元执行一系列预设的规则，最后再将输出写入一个位置。在计算能力有限、存储成本高的情况下，需要很好地利用计算机资源，使其计算能力最大化。因此，在编程初期，都是用指令直接操作硬件，如汇编语言中常见的。操作寄存器本质上是为了减少数据传输的时间，充分利用CPU的计算能力，避免CPU因为长时间传输数据而等待时间过长。分布式计算的到来随着科学技术的发展，“数据存储”领域在质和量上都得到了发展。除了稳定性和安全性的提升，容量也呈指数增长。因此整套服务可以直接在单机上搭建，类似LAMP的一键式搭建服务器的打包软件，应用场景更多。然而，随着业务的发展，另一个问题也逐渐浮出水面：虽然磁盘容量增加了，但机器的访问速度并没有变快。这是什么意思？例如：虽然磁盘驱动器的存储空间在20年前只有100MB，但读取整个磁盘只需要1分钟。虽然现在磁盘容量很容易达到1TB或1PB，但读取整个磁盘的数据需要几个小时。这背后的问题是技术发展的局限性：磁头在磁道上移动速度的增长远低于磁盘容量的增长。通俗地说，仓库面积从10平米扩大到100平米甚至1000平米，但是搬运工日常搬运货物的速度并没有明显提高，所以虽然仓库的容量是越来越大，但是整个仓库的货物搬动的时间也越来越长。幸运的是，我们还有另一个好消息：带宽越来越便宜。与20年前相比，千兆带宽的光纤非常普遍。网络可以实现一秒钟的传输，数据量已经远远超过了整个磁盘的容量。于是提出了一个大胆的想法：既然读取一个磁盘的数据需要好几个小时，那就把数据分成N份，放到不同的机器上并行读取。是否可以在一秒钟内读取数据？?采用网络并行方式读取，瓶颈从磁头移动转移到网络上，无需为增加高速带宽付出太多代价。或者仓库的例子。既然一个搬运工这么慢，搬1000平方米的仓库需要1000分钟，那1000个搬运工搬1000平方米需要1分钟吗？这个时候，唯一影响搬运工的就是大门了。大小只需要同时容纳1000名搬运工，不过开一道门的成本似乎并不高。大不了把四堵墙都拆掉做个门。MR世代一个绝妙的idea提出后，总会有很多follower去尝试去实现。Google率先抛出了三大论文：BigTable、GFS和MapReduce，从理论上描述了如何在分布式环境中实现数据。存储和计算，甚至提出分布式条件下的结构化检索。三大论文开创了分布式计算时代。然而，对于工程界来说，仅仅三篇论文是不足以解决生产问题的。Google并没有开源内部实现内容，于是另外一批团队：Yahoo，我自己根据论文实现，然后贡献给Apache，逐渐发展成今天还在热火朝天的：HDFS，Mapreduce，和HBase。其中，最主要的分布式计算模型：MapReuce，我们常称其为第一代MR，即：MRV1。上图是MRV1的主要架构图。我们可以看到，在MRV1中，主要分为两部分：运行环境和编程模型。所谓运行环境是指分布式任务调度、资源分配等任务运行过程中涉及的信息，而编程模型是指提供给开发者进行开发的接口。对于MRV1，它的运行结构图如下：可以看出，在MRV1中，当我们的一个任务被提交时，统一调度器对任务进行监控和分发，以及资源申请和回收控制等。MRV1有两个明显的阶段：映射和减少。Map阶段主要负责处理输入。每个Map任务对应一段数据，然后将数据发送到一个唯一的数据结构：ringbuffer。所谓环形缓冲区就是用来记录数据和索引的区域。当环形缓冲区即将溢出时，数据将被刷新到磁盘。数据输入完成后，会调用用户实现的map函数，然后和jobtracker保持联系，然后分别进入reduce阶段。缩减阶段将收集所有数据。此操作将被广泛定义。很多人称之为：洗牌。事实上，shuffle并不仅仅发生在reduce之后。对于MR，从数据从HDFS加载开始shuffle就已经开始，一直伴随到reduce结束。MRV1类似于工厂生产辣椒酱。许多工人负责切碎从流水线上送来的辣椒。这就是地图操作。工人们把切好的辣椒全部收集起来做成辣椒酱。这就是Reduce操作。可能某个工人不能以流水线送来的辣椒的速度把辣椒切成块，就需要把辣椒从流水线上拿下来，放在自己的地方慢切。这个动作相当于shuffle操作。因为***总结会等到所有人都把辣椒切好，所以如果一个人没有完成，就需要等待。这时候，我们常说的数据倾斜就出现了。第二代MR，MRV1，统一管理资源。这类似于一个公司的所有决策都需要由CEO来发布，或者有事联系不上，整个组织就成了无头鸡，完蛋了。因此，对于MRV1来说，虽然实现了并行计算模型，但其暴露的问题也很明显：固化的两阶段模型限制了迭代任务的执行。数据多次落地，整个运行时间大大延长。所有任务由统一的jobtracker调度，不存在单点故障。对资源的控制不足，没有明确的任务优先级。资源利用不合理。比如在V1中，资源分为mapsolt和reducesolt。结果，当map运行时，reducesolt全部空闲。安全控制。在这些问题逐渐暴露出来之后，也逐渐出现了很多补救措施。例如，Tez就是一个很好的例子。它接管了MRV1的输入输出，减少了它登陆磁盘的动作。目前Tez已经是Hive的内置计算。模型。但是这些补救框架并不能从根本上解决MRV1的问题，所以研究了第二代MR，也就是MRV2，那么MRV2是怎么做的呢？既然一个公司完全靠CEO来安排任务，而管理是有风险的，那么我们把公司所有的人分成N个小团队，每个团队都有自己的Lead负责工作安排。首席执行官做什么？CEO只负责把要做的事情交给小团队的Lead，小团队的Lead自己安排下属的工作。很多时候我们对MRV2这个名字并不熟悉，但是我们一定对一个名字很熟悉：Yarn。Yarn是MRV2下的核心功能。从上图中，我们发现对于MRV2，其资源的申请、控制、回收不再由统一的jobtracker（上例中的CEO）进行调度。在MRV2中，它产生了几个新的概念：ResourceManager：负责统一管理所有的资源。ApplicationMaster：负责任务监控、资源分配、回收等（上例中的小团队Lead）。节点管理器：每个节点的资源监控。这里不提Yarn，因为Yarn不是一种技术，而是一个概念，代表了V2中整个任务调度和资源管理系统。我们统称为：Yarn。我们可以对比一下MRV1和MRV2的组织图：在MRV2中，仍然分为运行环境和编程模型两部分。但是不同的是，每个应用都需要实现自己的ApplicationMaster，也就是资源管理系统。ResourceManager进行统一的资源分配，ApplicationMaster决定如何为每个Task分配资源。在实际开发中，我们发现我们好像没有写资源分配相关的代码，MR代码还是可以运行的。那是因为在MRV2中，默认提供了MR的ApplicationMaster。在MRV2中，API也发生了变化。为了兼容MRV1，有两套API。同时，由于MRV2的超高思想，整个资源调度是独立的，这带来了一个优势，即Yarn不仅可以调度MR计算引擎，还可以调度其他计算引擎，比如Spark。虽然目前可以使用Mesos，但大多数情况下我们还是会选择使用Yarn作为资源调度器。Spark分布式计算模型似乎让MRV2向前迈进了一大步，解决了很多问题。但是，对于MRV2来说，还有一些问题是它无法克服的。首先，为了兼容MR计算模型，它仍然保留了两阶段计算模型，因为它对于迭代计算来说基本上是弱的。MR模型就像一条工厂流水线。制作辣椒酱需要先将辣椒切碎，然后将它们聚集在一起制成辣椒酱。这是一个固定的两步操作。如果你想在剁之前做点什么，或者做辣椒酱之后，你放个标签什么的，MR模型就支持不了，所以“任意灵活迭代”的需求就出来了。这是Spark的特点。同时，MR的核心思想是：跑在便宜的服务器上，移动数据，所以对于实时计算，MVR2基本是盲目的。在这些问题之上，Spark诞生了。Spark的思想比较简单：移动计算但不移动数据。既然要搬动计算，那么我们如何描述这个计算呢？所以我们用RDD来封装一个记录来进行数据的对应，在这个封装之上记录计算。所以在Spark中，操作分为两类：Action和Transformation。为什么会有这两种操作呢？我们可以考虑一下。如果数据分散在100个节点，我们需要做的就是查询某个字段大于0的数据。那么这个计算就不需要把数据放在一起统一过滤了。只是在不同的节点过滤。而如果我们的操作是统计有多少条数据，就需要对数据进行汇总。因此，对于Spark来说，Action实际上会触发“移动数据”的动作，而Transformation只是进行一次标记转换。我们对Spark的各种调优大多是为了尽量减少Action操作。因为在Spark中，RDD是只读的，所以每一次操作都会产生一个新的RDD，这样就可以形成一系列的RDD依赖关系，也称为RDD链。模型训练模型训练更偏向于AI领域，AI领域有两个明显的分支：概率论和神经网络。在计算能力不足的时候，概率模型是最常见的做法，但是近几年发展起来的计算能力，让深度神经网络模型逐渐显出了风采，很多框架都展示了自己是深度学习框架的一面。模型训练本质上是数据特征的提取。训练本身与大数据没有必然联系，但两者相辅相成。数据量越大，提取的特征越多，模型训练的效果越好，但数据量越大，对计算的要求也越高，正因如此，模型的探索总是在实地尝试小数据和抽样。那么什么是特征呢？比如我们要预测一个人能活多久，最简单的方法就是返回已知已经死去的人的平均年龄，不管这个值是谁返回的，做这样的系统当然没问题.但是仔细观察就会发现，男性可以活到的年龄和女性是不一样的，所以我们可以简单修改一下，先判断性别再预测。如果是男性就返回男性的平均值，如果是女性就返回女性的平均值。平均的。这里我们无形中使用了性别这个特征，因为我们认为性别对结果有影响，训练需要找出无数这样的特征。不过目前对于大数据的处理能力似乎已经发展到一个非常好的阶段，至少在分布式计算方面，理论上是可以通过横向扩展来增加计算能力的**。然而，模型训练和工程应用的发展并不是那么顺利。归纳起来有以下几个原因：门槛比较高。将其应用于工程。对于模型训练，没有大量数据的支持，生产效果总是不尽如人意。然而，随着数据量的增加，如何处理这些数据就成了另一个领域的问题。它可以同时处理这两个问题。很少。在实际工程中，我们得到的数据集往往不能直接供训练模型使用。为了能够直接用于训练模型，需要进行大量的额外处理。这些成本甚至比模型训练本身还要高，所以让模型训练的成本变得更高。一些用户往往达不到模型训练的水平。比如连基础的数据平台都不存在，瞎用模型，导致效果不如预期，结果归咎于模型本身的质量。虽然模型训练的发展过程中存在诸多问题，但依然可以看出它在向前发展。目前，基于GPU的训练已经成为所有做模型训练的人的标配。谷歌甚至开发了自己的GPU：TPU。而很多芯片研发公司也在研发专用于模型训练的芯片。对于模型训练，目前一般有两种方式：单机模型训练分布式模型训练单机模型训练所谓单机训练，其实就是在单机上训练。对于单机模型训练，瓶颈主要在于提高单机性能配置，比如不断提升单机GPU的计算能力。至于数据，他们大多使用本地数据。虽然我们可以读取分布式文件系统的数据，但实际上我们还是要经过shuffle操作才能读取到本地的数据，而模型的训练就是整个过程。对于单机训练，我们可以使用奇异值分解等各种优化算法来降低计算成本。分布式模型训练对于单机训练，单GPU总会陷入瓶颈，那么对于模型训练，已经有人开始尝试了，分布式训练可以吗？分布式模型比其他分布式计算要困难得多。第一，模型依赖于数据，而模型本身的计算依赖于GPU，那么数据和算力如何结合呢？目前来看，模型的分布一般有以下几种方式：数据分布式训练模型分布式训练混合训练上图形象地描述了几种不同的训练方式。首先，对于数据分发，每个节点都有一个完整模型的副本。对于模型分发，模型的计算将分发到不同的节点。比如Tensorflow通过图形化的表达方式将计算描述为一个图，然后判断图中哪些计算可以并行运行，将它们拆分到不同的节点进行训练，从而实现分布式。训练的效果。在混合训练中，模型训练会分散，数据也会分散。不管是哪种分布式训练，最终都会涉及到一个操作：模型归一化。目前，有不同的方法来最终归一化模型。例如，集成算法在逻辑上实现了模型的归一化。最后，对于大数据和人工智能，现在只是处于起步阶段，未来还有很多工作要做，还有模型的训练，无论是单机还是分布式，尚未达到真正稳定的生产批次效应。这些挑战，不仅来自于技术的实现，也来自于业务的合作。如何利用已有的技术能力，并推动其解决业务中的问题，是需要关注的重点。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
