分布式计算这一块，自己也是刚接触不久，故在此做一下简单的记录，以便后续的学习。首先总结一下市面上的主要大数据解决方案：
| 解决方案 | 开发商 | 类型 | 描述 |
|---|---|---|---|
| storm | 流式处理 | Twitter 的新流式大数据分析解决方案 | |
| S4 | Yahoo! | 流式处理 | 来自 Yahoo! 的分布式流计算平台 |
| Hadoop | Apache | 批处理 | MapReduce 范式的第一个开源实现 |
| Spark | UC Berkeley AMPLab | 批处理 | 支持内存中数据集和恢复能力的最新分析平台 |
| Disco | Nokia | 批处理 | Nokia 的分布式 MapReduce 框架 |
| HPCC | LexisNexis | 批处理 | HPC 大数据集群 |
结合自己所找的一些资料，本文主要介绍Hadoop和spark两种：
1.spark
（一）了解Hadoop
Hadoop是Apache开源组织的一个分布式计算开源框架(http://hadoop.apache.org/)，用java语言实现开源软件框架，实现在大量计算机组成的集群中对海量数据进行分布式计算。Hadoop框架中最核心设计就是：HDFS和MapReduce，HDFS实现存储，而MapReduce实现原理分析处理，这两部分是hadoop的核心。数据在Hadoop中处理的流程可以简单的按照下图来理解：数据通过Haddop的集群处理后得到结果，它是一个高性能处理海量数据集的工具 。核心设计有三块：
- HDFS:实现了一个分布式文件存储系统
- MapReduce:实现海量数据并行计算（分布式运算框架）
-
YARN: Yet Another Resource Negotiator 资源管理调度系统
（二）使用Hadoop
由于Hadoop采用分布式存储与计算，可以将较大的数据分布存储，然后运算可以很大的解决由于内存不足导致程序终止的问题，故在这里对常用的使用命令进行总结：
从开发机通过hadop进入自己的集群文件：
$ hdfs dfs -ls /user
新建文件tt
hdfs dfs -mkdir hdfs://xx/tt
删除文件
hdfs dfs –rm -r hdfs://xx/tt
复制文件
hdfs dfs –cp hdfs://xx/tt hdfs://yy/
从开发机上传文件xx到集群
hdfs dfs -put xx hdfs://xx/tt
从集群上下载文件到开发机
hdfs dfs -get hdfs://xx/tt2.spark
Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，最初在2009年由加州大学伯克利分校的AMPLab开发，并于2010年成为Apache的开源项目之一，与Hadoop和Storm等其他大数据和MapReduce技术相比，Spark有如下优势：
- Spark提供了一个全面、统一的框架用于管理各种有着不同性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求
- 官方资料介绍Spark可以将Hadoop集群中的应用在内存中的运行速度提升100倍，甚至能够将应用在磁盘上的运行速度提升10倍
目标：
- 架构及生态
- spark 与 hadoop
- 运行流程及特点
- 常用术语
- standalone模式
- yarn集群
- RDD运行流程
Spark与hadoop区别与联系:(https://www.cnblogs.com/cxxjohnson/p/8909578.html)
- Hadoop有两个核心模块，分布式存储模块HDFS和分布式计算模块Mapreduce
- spark本身并没有提供分布式文件系统，因此spark的分析大多依赖于Hadoop的分布式文件系统HDFS
- Hadoop的Mapreduce与spark都可以进行数据计算，而相比于Mapreduce，spark的速度更快并且提供的功能更加丰富
- 关系图如下：
引深点：分布式计算
分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总， 目的在于分析计算海量的数据。海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。 因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。下面以一个需求为例进行说明，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 如果没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
（1）分片算法
这是一种介于单机计算和成熟计算框架的过度解决方案，分布式计算通过对计算任务进行拆分，实现成本和需求双满足了。 如果数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。小明需要把这些数据按照一定维度进行划分。 按需求来看以用户ID划分最好，由于用户之间没有状态上的关联，所以也不需要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。
f(memberid) % 5 = ServerN这样程序可以分别部署到5台机器上，然后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不需要进行通信，可以避免很多问题。 机器上的程序本身也不具备分布式的特性，它和单机一样，只计算自身获取到的数据即可，所以如果某台机器上程序崩溃的话，处理方式和单机一样，比如记录下处理进度，下次从当前进度继续进行后续计算。
（2）消息队列
使用分片方式相对比较简单，但有如下不足之处。
- 它不具有负载均衡的能力，如果某台机器配置稍好点，它可能最先计算完，然后空闲等待着。也有可能是某些用户行为数据比较少，导致计算比较快完成。
- 还有一个弊端就是每台机器上需要手动更改对应的配置， 这样的话多台机器上的程序不是完全一样的，这样可以用远程配置动态修改的办法来解决。
小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，然后各台机器分别取消费这个队列。 于是就有了3个角色：
- 推送消息的，简称Master。
- 消息队列，这里以Rabbitmq为例。
- 各个处理程序，简称Worker或Slave都行。
虽然仅仅引入了个第三方，但它已经具备了分布式计算的很多特性。
- 计算任务分发。 Master把需要计算的用户数据，不断的推送消息队列。
- 程序一致性。 Worker订阅相同的消息队列即可，无需更改程序代码。
- 任意扩容。 由于程序完全一样，意味着如果想要加快速度，重复部署一份程序到新机器即可。 当然这是理论上的，实际当中会受限于消息队列、数据库存储等。
- 容灾性。 如果5台中某一台程序挂了也不影响，利用Rabbitmq的消息确认机制，机器崩溃时正在计算的那一条数据会在超时，在其他节点上进行消费处理。
（3）hadoop
如上面所描述的，Hadoop是一套海量数据计算存储的基础平台架构，数据越大越能提现其性能，小明对此进行了如下设计
- 目标任务是100G用户数据的计算任务。
- ”任务划分“ 对应Master和消息队列。
- “子任务” 对应Worker的业务逻辑。
- ”结果合并“ 对应把每个worker的计算结果入库。
- “计算结果” 对应入库的用户消费习惯数据。
参考链接：
https://blog.csdn.net/gwd1154978352/article/details/81095592
http://hadoop.apache.org/docs/r1.0.4/cn/quickstart.html（Hadoop快速入门）
https://blog.csdn.net/andrew_yuan/article/details/80306101（Hadoop入门篇）
https://www.cnblogs.com/mushroom/p/4959904.html（浅谈分布式计算的开发与实现）
2031
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
