大数据的学习需要预先了解哪些基础知识？

计算机的基本工作就是处理数据，包括磁盘文件中的数据，通过网络传输的数据流或数据包，数据库中的结构化数据等。随着互联网、物联网等技术得到越来越广泛的应用，数据规模不断增加，TB、PB量级成为常态，对数据的处理已无法由单台计算机完成，而只能由多台机器共同承担计算任务。而在分布式环境中进行大数据处理，除了与存储系统打交道外，还涉及计算任务的分工，计算负荷的分配，计算机之间的数据迁移等工作，并且要考虑计算机或网络发生故障时的数据安全，情况要复杂得多。

举一个简单的例子，假设我们要从销售记录中统计各种商品销售额。在单机环境中，我们只需把销售记录扫描一遍，对各商品的销售额进行累加即可。如果销售记录存放在关系数据库中，则更省事，执行一个SQL语句就可以了。现在假定销售记录实在太多，需要设计出由多台计算机来统计销售额的方案。为保证计算的正确、可靠、高效及方便，这个方案需要考虑下列问题：

1. 如何为每台机器分配任务，是先按商品种类对销售记录分组，不同机器处理不同商品种类的销售记录，还是随机向各台机器分发一部分销售记录进行统计，最后把各台机器的统计结果按商品种类合并？

2. 上述两种方式都涉及数据的排序问题，应选择哪种排序算法？应该在哪台机器上执行排序过程？

3. 如何定义每台机器处理的数据从哪里来，处理结果到哪里去？数据是主动发送，还是接收方申请时才发送？如果是主动发送，接收方处理不过来怎么办？如果是申请时才发送，那发送方应该保存数据多久？

4. 会不会任务分配不均，有的机器很快就处理完了，有的机器一直忙着？甚至，闲着的机器需要等忙着的机器处理完后才能开始执行？

5. 如果增加一台机器，它能不能减轻其他机器的负荷，从而缩短任务执行时间？

6. 如果一台机器挂了，它没有完成的任务该交给谁？会不会遗漏统计或重复统计？

7. 统计过程中，机器之间如何协调，是否需要专门的一台机器指挥调度其他机器？如果这台机器挂了呢？

8. （可选）如果销售记录在源源不断地增加，统计还没执行完新记录又来了，如何保证统计结果的准确性？能不能保证结果是实时更新的？再次统计时能不能避免大量重复计算？

9. （可选）能不能让用户执行一句SQL就可以得到结果？

上述问题中，除了第1个外，其余的都与具体任务无关，在其他分布式计算的场合也会遇到，而且解决起来都相当棘手。即使第1个问题中的分组、统计，在很多数据处理场合也会涉及，只是具体方式不同。如果能把这些问题的解决方案封装到一个计算框架中，则可大大简化这类应用程序的开发。

2004年前后，Google先后发表三篇论文分别介绍分布式文件系统GFS、并行计算模型MapReduce、非关系数据存储系统BigTable，第一次提出了针对大数据分布式处理的可重用方案。在Google论文的启发下，Yahoo的工程师Doug Cutting和Mike Cafarella开发了Hadoop。在借鉴和改进Hadoop的基础上，又先后诞生了数十种应用于分布式环境的大数据计算框架。本文在参考业界惯例的基础上，对这些框架按下列标准分类：

1. 如果不涉及上面提出的第8、9两个问题，则属于批处理框架。批处理框架重点关心数据处理的吞吐量，又可分为非迭代式和迭代式两类，迭代式包括DAG（有向无环图）、图计算等模型。

2. 若针对第8个问题提出来应对方案，则分两种情况：如果重点关心处理的实时性，则属于流计算框架；如果侧重于避免重复计算，则属于增量计算框架。

3. 如果重点关注的是第9个问题，则属于交互式分析框架。

本文下面分别讨论批处理、流计算、交互式分析三种类别的框架，然后简要介绍大数据计算框架的一些发展趋势。

 

批处理框架

Hadoop

Hadoop最初主要包含分布式文件系统HDFS和计算框架MapReduce两部分，是从Nutch中独立出来的项目。在2.0版本中，又把资源管理和任务调度功能从MapReduce中剥离形成YARN，使其他框架也可以像MapReduce那样运行在Hadoop之上。与之前的分布式计算框架相比，Hadoop隐藏了很多繁琐的细节，如容错、负载均衡等，更便于使用。

Hadoop也具有很强的横向扩展能力，可以很容易地把新计算机接入到集群中参与计算。在开源社区的支持下，Hadoop不断发展完善，并集成了众多优秀的产品如非关系数据库HBase、数据仓库Hive、数据处理工具Sqoop、机器学习算法库Mahout、一致性服务软件ZooKeeper、管理工具Ambari等，形成了相对完整的生态圈和分布式计算事实上的标准。