浅谈分布式计算的开发与实现(一)

阅读目录:

1. 介绍
2. 利用分片算法
3. 利用消息队列
4. Hadoop简介
5. MapReduce
6. 离线计算

介绍

分布式计算简单来讲，是把一个大计算任务拆分红多个小计算任务分布到若干台机器上去计算，而后再进行结果汇总。 目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号(外星文明)，淘宝双十一实时计算各地区的消费习惯等。

海量计算最开始的方案是提升单机计算性能，如大型机，后来因为数据的爆发式增加、单机性能却跟不上，才有分布式计算这种妥协方案。 由于计算一旦拆分，问题会变得很是复杂，像一致性、数据完整、通讯、容灾、任务调度等问题也都来了。

举个例子，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 若是没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
日常开发中相似的需求也不少，总结出来就是，数据量大、单机计算慢。 若是上Hadoop、storm之类成本较高、并且有点大才小用。 固然让老板买更好的服务器配置也是一种办法。

利用分片算法

小明做为一个有追求有理想的程序员，决定用介于单机计算和成熟计算框架的过分解决方案，这样成本和需求都能知足了。 分布式计算的核心在于计算任务拆分，若是数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。

如上所述，小明须要把这些数据按照必定维度进行划分。 按需求来看以用户ID划分最好，因为用户之间没有状态上的关联，因此也不须要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。

f(memberid) % 5 = ServerN

这样程序能够分别部署到5台机器上，而后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不须要进行通讯，能够避免不少问题。 机器上的程序自己也不具有分布式的特性，它和单机同样，只计算自身获取到的数据便可，因此若是某台机器上程序崩溃的话，处理方式和单机同样，好比记录下处理进度，下次从当前进度继续进行后续计算。

利用消息队列

使用分片方式相对比较简单，但有以下不足之处。

• 它不具备负载均衡的能力，若是某台机器配置稍好点，它可能最早计算完，而后空闲等待着。也有多是某些用户行为数据比较少，致使计算比较快完成。
• 还有一个弊端就是每台机器上须要手动更改对应的配置， 这样的话多台机器上的程序不是彻底同样的，这样能够用远程配置动态修改的办法来解决。

小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，而后各台机器分别取消费这个队列。 因而就有了3个角色：

• 推送消息的，简称Master。
• 消息队列，这里以Rabbitmq为例。
• 各个处理程序，简称Worker或Slave都行。

虽然仅仅引入了个第三方，但它已经具有了分布式计算的不少特性。

1. 计算任务分发。 Master把须要计算的用户数据，不断的推送消息队列。
2. 程序一致性。 Worker订阅相同的消息队列便可，无需更改程序代码。
3. 任意扩容。 因为程序彻底同样，意味着若是想要加快速度，重复部署一份程序到新机器便可。 固然这是理论上的，实际当中会受限于消息队列、数据库存储等。
4. 容灾性。 若是5台中某一台程序挂了也不影响，利用Rabbitmq的消息确认机制，机器崩溃时正在计算的那一条数据会在超时，在其余节点上进行消费处理。

Hadoop简介

Hadoop介绍已经至关多了，这里简述下好比:"Hadoop是一套海量数据计算存储的基础平台架构"，分析下这句话。

• 其中计算指的是MapReduce，这是作分布式计算用的。
• 存储指的是HDFS，基于此上层的有HBase、Hive，用来作数据存储用的。
• 平台，指能够给多个用户使用，好比小明有一计算需求，他只须要按照对应的接口编写业务逻辑便可，而后把程序以包的形式发布到平台上，平台进行分配调度计算等。 而上面小明的分布式计算设计只能给本身使用，若是另外有小华要使用就须要从新写一份，而后单独部署，申请机器等。Hadoop最大的优点之一就在于提供了一套这样的完整解决方案。

下面找了介绍Hadoop的概览图，跟小明的设计作对比下:

• 图中“大数据计算任务” 对应小明的100G用户数据的计算任务。
• ”任务划分“ 对应Master和消息队列。
• “子任务” 对应Worker的业务逻辑。
• ”结果合并“ 对应把每一个worker的计算结果入库。
• “计算结果” 对应入库的用户消费习惯数据。

PS：为了方便描述，把小明设计的分布式计算，叫作小和尚。

MapReduce

因为MapReduce计算输入和输出都是基于HDFS文件，因此大多数公司的作法是把mysql或sqlserver的数据导入到HDFS，计算完后再导出到常规的数据库中，这是MapReduce不够灵活的地方之一。 MapReduce优点在于提供了比较简单的分布式计算编程模型，使开发此类程序变得很是简单，像以前的MPI编程就至关复杂。

狭隘的来说，MapReduce是把计算任务给规范化了，它能够等同于小和尚中Worker的业务逻辑部分。 MapReduce把业务逻辑给拆分红2个大部分，Map和Reduce，能够先在Map部分把任务计算一半后，扔给Reduce部分继续后面的计算。 固然在Map部分把计算任务全作完也是能够的。 关于Mapreduce实现细节部分很少解释，有兴趣的同窗能够查相关资料或看下楼主以前的C#模拟实现的博客【探索C#之微型MapReduce】。

若是把小明产品经理的需求放到Hadoop来作，其处理流程大体以下：

1. 把100G数据导入到HDFS
2. 按照Mapreduce的接口编写处理逻辑，分Map、Reduce两部分。
3. 把程序包提交到Mapreduce平台上，存储在HDFS里。
4. 平台中有个叫Jobtracker进程的角色进行分发任务。 这个相似小和尚的Master负载调度管理。
5. 若是有5台机器进行计算的话，就会提早运行5个叫TaskTracker的slave进程。 这相似小和尚worker的分离版，平台把程序和业务逻辑进行分离了， 简单来讲就是在机器上运行个独立进程，它能动态加载、执行jar或dll的业务逻辑代码。
6. Jobtracker把任务分发到TaskTracker后，TaskTracker把开始动态加载jar包，建立个独立进程执行Map部分，而后把结果写入到HDFS上。
7. 若是有Reduce部分，TaskTracker会建立个独立进程把Map输出的HDFS文件，经过RPC方式远程拉取到本地，拉取成功后，Reduce开始计算后续任务。
8. Reduce再把结果写入到HDFS中
9. 从HDFS中把结果导出。

这样一看好像是把简单的计算任务给复杂化了，其实若是只有几台计算任务的话，使用Mapreduce确实是杀鸡用牛刀了。 若是有TB、PB级别的数据、跑在成百上千台计算节点上，Mapreduce的优点才会体现出来。 其计算框架图架构以下： 

离线计算

一般称Mapreduce及小和尚这种计算为离线计算，由于它对已经持久化的文件数据进行计算，不能实时响应。 还有个缘由就是它的处理速度比较慢，它的输入和输出源都是基于HDFS设计，若是数据不是一开始就写入到HDFS上，就会涉及到数据导入导出，这部分相对耗费时间。 并且它的数据流动是基于文件系统的，Map部分输出的数据不是直接传送到Reduce部分，而是先写入HDFS再进行传送。

处理速度慢也是Mapreduce的不足之处，促使了后面实时计算的诞生。
另外个缺点是Mapreduce的计算任务流比较单一，它只有Map、Reduce两部分。 简单的能够只写一部分逻辑来解决，若是想拆分红多个部分，如逻辑A、逻辑B、逻辑C等， 并且一部分计算逻辑依赖上一次计算结果的话，MapReduce处理起来就比较困难了。 像storm框架解决此类问题的方案，也称为流式计算，下一章继续补充。

 

PS：懒懒懒，一直拖到如今才写。