一、如何选择粗粒度和细粒度
从底层往上引申来理解粗粒度与细粒度。
一层：一个类，具有三个属性值。为了查询这个类的所有实例，细粒度查询的程度为属性值，即依次查询每个实例化对象的属性值，查询三次；粗粒度按对象查询，直接查询该类的所有实例化对象，查询一次。查询结果是相同的，但是查询的方式却不同。这一类的实例有Database中的查询操作，整表查询和逐步查询。
二层：一个数据集，包含有多个对象。当对数据集进行操作时，细粒度的处理方式会获取数据集中的每个对象，然后执行相应的操作，执行的次数为对象的个数；粗粒度直接对整个数据集进行操作，将数据集中的对象按序执行操作，并不在乎其中的对象的特点。数据集应用粗粒度的实例即Spark的RDDs。
三层：一个分布式应用，会让集群中的一些节点循环执行它所提供的计算。对节点分配资源时，细粒度的分配方式会检查应用执行所需要的每个节点，然后为这些节点分配资源；粗粒度的分配方式则以应用为单位，直接将应用所需的资源分配给应用，由应用来进行处理。分布式系统应用细粒度的实例即Mesos。
因此，粗粒度会忽略对象整体的内部细节，或者说是将内部细节在计算的过程中进行同化，达到以块为执行单位的效果；细粒度则注重对象的任何一个属性及执行步骤，或者说注意底层计算的重用部分，达到以点为执行单位的效果。
RDDs的操作中narrow dependencies是将一个RDD转换为新的RDD，操作的对象是RDD数据集，对RDD内部的<K，V>直接执行相应的map操作。因而，在进行写操作时一般是以整个RDD为单位进行写操作，采用粗粒度的方式更佳；而在进行读操作时，需要读取RDD时采用粗粒度寻址方式，而需要读取RDD中的内容进行action操作时，可以采用细粒度的寻址方式。
Mesos采用细粒度的共享方式，这样做的一个好处是，尽管有些任务并不是同时执行细粒度的task，但是长任务和短任务仍然能够共享空间。框架决定需要哪些资源时是根据任务的长短来决定的，长任务一般需要更多的资源。而后Mesos为框架分配资源（这个策略是可以由用户指定的），但是却由框架来决定接收哪些资源，接受的资源可以用来执行任务（长任务或者短任务），不接受的资源由Mesos回收分配给其他的框架，这样既避免了长任务得不到资源的尴尬，也避免了长任务占据太多资源而导致短任务得不到执行。这种方法对待长任务和短任务的方法是否可以推广到其他方面？当Spark中的进程被判断为straggler后，它和正常进程的关系类似于长任务和短任务，至少它们的资源需求应该类似，对straggler推测执行固然能够解决一些问题，但是如果在它们申请资源时进行两次资源的判定，保证starggler的执行过程不影响正常进程的执行，会不会提高系统的性能？
二、系统中功能的分配
Mesos的中心思想：定义一个能够保证资源共享利用率的尽可能小的接口，其他的工作都推给frameworks去做。
（未完，待续）