分布式计算的核心思想在没有包裹业务之前并不复杂，简单而言，如果有一个任务（可以是查询，排序，搜索）可以被拆分为互不影响的若干个重复的小任务，那么我们就可以使用多台计算机并行的执行这些小任务。
任务执行必然需要对各种资源进行调用，例如硬件，数据，网络等，这些资源的调用会形成至少3个问题：
- 数据的一致性，如果某一个子任务对数据进行了修改，需要有策略保证其他子任务访问这块数据时得到及时更新。
- 任务执行的时序，如果先后执行的任务有依赖性，或者称之为stateful的执行，那么执行顺序需要进行一定的保证。
- 执行失败的处理，如果某一个计算节点挂掉了，那么如何保证整个计算框架可以继续执行，并且对失败的子任务进行重新分配。
接下来，在实现分布式计算的过程中，上层应用往往不希望对底层的任务调度，资源访问进行直接操作。我们还希望对节点的访问体验如同本地一般。这时，可以采用RPC框架进行接口的封装。
Hadoop，Spark，Storm，Flink在某种程度上都是提供了一个宽泛的分布式计算框架。它们并不针对于一个特定的计算问题，而是对任务的实现进行底层分布式实现并且提供面向上层的抽象接口。
Hadoop是最早的分布式框架，它的核心两个东西，MapReduce的任务拆分，和HBase。如果我们的任务只是纯粹计算和内存资源访问，Hadoop本身可能没什么优势。
Storm和Spark是针对实时处理的框架，例如它们具备的消息队列，流处理设计。在结构上，和Hadoop最大的区别可能是它们引入了内存访问，所以直观上感觉对数据的访问会比Hadoop要快一些。
Flink重点在于stateful的应用，即它对资源的访问不是单纯面向SQL，而是保留了内部的状态。相比前三者，Flink的优点在于能够对Stateful的应用降低延迟（latency）。如果我们的数据是消息队列，交易，那么考虑用flink。阿里在Flink之上开发了Blink，性能也非常好。
MeSoS是资源的分布式访问，即我们需要解决的第1个问题。
分布式计算框架选择，最根本的原则在于能否解决计算的瓶颈，包括磁盘读写，计算力，网络带宽，异构数据处理。这其中，计算力往往是最后才需要考虑的，其次是异构数据处理。一般而言，非涉及到复杂计算如神经网络训练，系统的瓶颈往往是数据量和传输带宽。如果是复杂计算，也没必要频繁调用分布式框架，以目前大部分公司常规业务而言，优先考虑单机。
如果我们的任务是纯粹的计算，并且强调实时性的时候，上面几个框架都显得过分冗余了，这时，利用rpc和多核进程反而能带来最优的性能。
网友评论