分布式计算漫谈

        数据价值巨大已经成为当下互联网，乃至一些传统企业所公认的事实。处理数据的能力也随之成为技术开发人员所火热研究的领域。事实上，当下对于数据计算大抵分为两类，批处理和实时计算。

        自我理解，批处理和实时计算的差别在于，批处理需要数据有一个累积过程而真正的实时流计算则不需要。将一段时间累积的数据进行统一大规模计算继而生成结果是批处理的一般流程。而将累积时间缩短至最小，即当数据源产生数据时就进行处理，每时刻产出的结果既是中间态也是最终态，这样便成了实时计算。

       在早期大规模数据计算中，人们最先广泛使用的是批处理。从单机到分布式的发展，是现实数据量激增的迫使，同时也是技术人员思维方式的逐步转变。早年超级计算机的研发旨在不断加强单个计算机的处理能力以迎合不断膨胀的计算需求与处理规模。同时单机处理的简单方式也符合技术人员长期开发的习惯，然而利益最大化不断推动着人类社会的发展。当超级计算机的成本难以迎合企业、个人对于收支比的考量时，促使了分布式的产生。分布式简单可以理解成将较大作业进行拆分，由不同计算实体去完成分配给自己的小任务，然后汇聚中间计算结果生成最终表现。由此可见分布的具体表现在两个方面，数据的拆分和计算的拆分。拆分的原则则是保证被拆分对象的最小依赖，Google对于这种思维模式进行了总结与抽象提出了MapReduce模型，自此迎来了一波大数据处理热潮。MapReduce应该称之为一种编程范式，它将一个分布式作业纵向分为两个阶段Map和Reduce，真正并行化的操作在map时处理，map操作支持横向扩展以增加并行度，而最终结果的呈现则依赖reduce去做汇聚。MapReduce一度成为批处理的代名词，其实感觉并不是这样。MapReduce并不等于批处理，只是其最初的形态是与GFS紧耦合，而GFS是Google提出的基于磁盘的分布式文件系统，同时早期调度模式的简单粗暴，致使作业执行时间较长。只能适用于批处理作业的时间要求。事实证明，现在许多实时计算框架也是基于MapReduce模型而出的。

        实时计算，其实与批处理的差距并没有明显界线。一些实时处理平台的实现模型也是基于批处理来的。已有实时处理框架的实现思路大体分两种，一种是利用micro-batch的模式，另一种则是真正基于数据流的计算模式。Micro-batch模式的典型代表是Spark Streaming，它将一个持续型数据流作业进行分段，划分为小段的batch作业，最终利用调度批处理的方式去执行小型作业。而流式计算的典型代表则有老牌的Storm和后起之秀Flink，它们是基于数据流进行作业调度的，即数据产生则立即处理。这样看来，Spark Streaming其实并没有真正做到实时流处理而是采用讨巧的手段去迎合人们对于流处理的时间要求。这些讨巧的手段包括了内存计算，即中间结果缓存内存中，基于DAG图的作业调度模型以及lineage模型的容错机制。由此看来，自认为Spark整个框架的真正身份更倾向于内存计算平台而非流计算。然而Berkeley AMPLab给Spark的定义也称其是一个统一的大数据处理平台，即它能够用一个平台去处理几乎所有数据处理需要的作业模式，无论是批处理，流计算这种底层作业的支持，还是机器学习算法，SQL处理，甚至图计算等上层应用的辅助。Spark都做出了很好的解决方案，因此也得到了广泛的应用。而相对实时性更高的系统来说，无疑Storm或者Flink更能满足他们的需求。这种大而全还是小而精的选择相信只用处于特定场景的真正使用者才能分辨吧。