一文解读大数据 (转)

1. 前言

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

假设我们必须从销售记录中统计各种商品的销售额，举个简单的例子。在单机环境中，我们只需要扫描销售记录，积累每种商品的销售额。如果将销售记录存储在关系数据库中，则更容易执行SQL语句。现在假设销售记录太多，需要设计多台计算机统计销售额的方案。本方案需要考虑以下问题，以确保正确、可靠、高效、方便的计算：

1. 如何为每台机器分配任务，是根据商品类型对销售记录进行分组，不同机器处理不同商品类型的销售记录，还是随机将部分销售记录分发给每台机器进行统计，最后根据商品类型合并每台机器的统计结果？
2. 这两种方法都涉及到数据的排序问题。应该选择哪种排序算法？应该在哪台机器上执行排序过程？
3. 如何定义每台机器处理的数据来自哪里，处理结果去哪里？数据是主动发送的，还是接收方在申请时发送的？如果是主动发送的，接收方不能处理怎么办？如果是在申请时发送的，发送方应该保存数据多久？
4. 任务分配是否不均匀，有些机器很快就完成了，有些机器一直很忙？即使是闲置的机器也需要等到忙碌的机器完成后才能开始执行？
5. 若增加一台机器，能否减轻其它机器的负荷，从而缩短任务执行时间？
6. 如果一台机器挂断了，它未完成的任务应该交给谁？会遗漏统计数据还是重复统计数据？
7. 在统计过程中，如何协调机器之间，是否需要一台专门的机器来指挥和调度其他机器？如果这台机器挂了怎么办？
8. （可选）如果销售记录不断增加，统计数据尚未完成，如何确保统计结果的准确性？结果是否可以实时更新？在再次统计时，是否可以避免大量的重复计算？
9. (可选)用户执行SQL能得到结果吗？

在上述问题中，除第一个问题外，其他问题与具体任务无关，在其他分布式计算场合也会遇到，而且很难解决。即使是第一个问题中的分组和统计数据也会涉及到许多数据处理场合，但具体方法是不同的。如果这些问题的解决方案可以包装在计算框架中，这些应用程序的开发可以大大简化。

2004年左右，Google发表了三篇关于GFS分布式文件系统的论文、并计算模型Mapreducee、BigTable是非关系数据存储系统，首次提出了大数据分布式处理的可重用方案。受Google论文的启发，Yahoo的工程师Doug Cutting和Mike 开发Hadoop的Cafarella。在借鉴和改进Hadop的基础上，在分布式环境中诞生了数十个大数据计算框架。本文在参考行业惯例的基础上，按以下标准对这些框架进行分类：

1. 如果不涉及上述提议的第8号、9两个问题属于批处理框架。批处理框架侧重于数据处理的吞吐量，可分为非迭代和迭代。迭代包括DAG(有向无环图)、图计算等模型。
2. 如果对第八个问题提出解决方案，则分为两种情况：如果关注处理的实时性，则属于流量计算框架；如果重点是避免重复计算，则属于增量计算框架。
3. 若重点关注第九个问题，则属于交互式分析框架。

本文分别讨论了批处理、流量计算和交互式分析三种框架，然后简要介绍了大数据计算框架的一些发展趋势。本文最后介绍了该领域的学习材料。

图1. 全景图大数据计算框架

2. 2.1批处理框架. Hadoop

Hadoop最初主要包括分布式文件系统HDFS和计算框架Mapreduce，这是一个独立于Nutch的项目。在2.0版本中，从Mapreduce中剥离资源管理和任务调度功能，形成YARN，使其他框架能够像Mapreduce一样在Hadoop上运行。与之前的分布式计算框架相比，Hadoop隐藏了许多繁琐的细节，如容错、负载平衡等，使用起来更方便。

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

图2. Hadoop生态系统(删减版)

Mapreduce可以理解为将一堆杂乱无章的数据按照一定的特点合并，然后处理并得到最终结果。基本处理步骤如下:

1. 输入文件按一定标准分割，每个分割对应一个map任务。一般来说，Mapreduce和HDFS在同一组计算机上运行，即每台计算机同时承担存储和计算任务，因此分割通常不涉及计算机之间的数据复制。
2. 按照一定的规则，将分片中的内容分析成键值对。通常可以选择预定义的规则。
3. 执行map任务，处理每个键值对，输出零或多个键值对。
4. Mapreduce获取应用程序定义的分组模式，并根据分组输出Map任务的键值进行排序。默认情况下，每个键名为一组。
5. Mapreduce在所有节点完成上述步骤后启动Reduce任务。每个组对应一个Reduce任务。
6. 通过网络获取指定组的所有键值对，执行reduce任务的过程。
7. 将键名相同的值合并为列表。
8. 执行reduce任务，处理每个键对应的列表，输出结果。

图3. Mapreduce处理过程

在上述步骤中，应用程序主要负责map和reduce的设计，其他工作由框架负责。在定义map任务输出数据的方式时，键的选择非常重要。除了影响结果的正确性外，它还决定了如何分组、排序和传输数据，以及如何分工执行reduce任务的计算机。上述商品销售统计的例子可以选择商品类型作为键。Mapreduce实施商品销售统计的过程大致如下：

1. 将销售记录分片分配给多台机器。
2. 每个销售记录分析为键值对，其中值为销售记录的内容，键可以忽略。
3. 执行map任务，将每个销售记录转换为新的键值对，其中键为商品类型，值为该记录中商品的销售额。
4. Mapreduce根据商品类型对Map任务生成的数据进行排序。
5. Mapreduce在所有节点完成排序后启动reduce任务。每种商品类型对应一个reduce任务。
6. 实施reduce任务的过程通过网络获取指定商品类型的各种销售额。
7. Mapreduce将同一商品下的销售额合并到列表中。
8. 执行reduce任务，累计各种销售额，获得该商品的总销售额。

上述过程也有优化的空间。在传输各种商品的每次销售数据之前，您可以在map端计算各种商品的销售额，这可以大大降低网络传输的负荷。mapreduce通过可选的combine任务支持该类型的优化。

2.2. DAG模型

现在假设我们的目标更进一步，我们希望知道前10种最畅销的商品。我们可以分为两个链接来计算：

1. 统计各种商品的销售额。Mapreduce已经实现，这在前面已经讨论过了。
2. 根据销售情况对商品类型进行排名。它可以通过一个排序过程来完成。假设商品种类繁多，需要通过多台计算机加快计算速度，我们可以使用另一个Mapreduce过程来实现。其基本思路是将map和reduce视为小组赛和决赛，首先计算每部分的前10名，然后总结后计算总排名的前10名。

从上面的例子可以看出，复杂的计算问题可以通过多个Mapreduce的组合来表达。然而，组合过程需要人工设计，这更麻烦。此外，所有的计算机都需要在每个阶段同步，这影响了执行效率。

为了克服上述问题，该行业提出了DAG（向无环图）计算模型，其核心思想是将任务分解为几个有序的子任务，以更灵活地表达各种复杂的依赖关系。Microsoft Dryad、Google FlumeJava、Apache Tez是最早出现的DAG模型。Dryad定义了几个简单的DAG模型，如串联、全连接和集成，通过组合这些简单的结构来描述复杂的任务，FlumeJava、Tez通过组合几个Mapreduce形成DAG任务。

图4. MapReduce(左)与Tez(右)

在执行复杂任务时进行比较

Mapreduce的另一个缺点是使用磁盘存储中间结果，严重影响系统的性能，这在机器学习等需要迭代计算的场合更为明显。由加州大学伯克利分校AMP实验室开发的Spark克服了上述问题。Spark改进了早期的DAG模型，并提出了基于内存的分布式存储抽象模型RDD（Resilient Distributed Datasets，可恢复分布式数据集)，有选择地将中间数据加载并留在内存中，以减少磁盘IO的成本。Spark基于内存的运算比Hadoop快100倍，基于磁盘的运算也快10倍。

图5. Mapreduce和Spark之间的结果

比较保存方法

Spark为RDD提供了丰富的操作方法，其中mapark、 filter、 flatMap、 sample、groupByKey、 reduceByKey、union、join、cogroup、mapValues、sort、PartionBy用于执行数据转换，生成新的RDD，而count、collect、 reduce、lookup、Save用于收集或输出计算结果。例如，在上述商品销售统计中，只需调用map和reducebykey进行Spark转换即可实现。整个程序只需要几行代码，包括加载销售记录和保存统计结果，并支持Java、Scala、Python、R等多种开发语言比Mapreduce编程方便得多。下图说明了reduceByKey的内部实现。

图6. RDD reduceByKey内部实现

RDD需要比Hadoop更多地考虑容错问题，因为它将数据存储在内存而不是磁盘上。有两种方法可以容错分布式数据集：数据检查点和记录数据更新。在处理大量数据时，数据检查点的运行成本非常高， 因此，Spark默认选择记录更新的方式。但是，如果更新粒度太细太多，记录更新的成本也不低。因此，RDD只支持粗粒度转换，即只记录单个块上执行的单个操作，然后记录创建RDD的一系列变换序列，类似于数据库中的日志。

当RDD部分分区数据丢失时，Spark根据之前记录的演变过程重新计算，恢复丢失的数据分区。Spark生态系统的另一个项目Allluxio(原名Tachyon)也采用了类似的想法，使数据写入速度比HDFS快。

以下总结了Spark对Mapreduce的改进:

• Mapreduce抽象水平低，需要手工编写代码；基于RDD抽象的Spark使数据处理逻辑的代码非常短。
• Mapreduce只提供map和reduce两种操作，缺乏表达；Spark提供了许多转换和动作，以及JOIN等关系数据库中的许多常见操作、GROUP 在RDD中实现了BY。
• 在Mapreduce中，只有两个阶段：map和reduce。复杂的计算需要大量的组合，开发人员自己定义组合模式；在Spark中，RDD可以连续执行多个转换操作。如果这些操作对应的RDD分区保持不变，也可以在同一任务中执行。
• Mapreduce处理逻辑隐藏在代码中，不直观；Spark代码不包含操作细节，逻辑更清晰。
• Mapreduce的中间结果放在HDFS中；Spark的中间结果放在内存中，当内存无法存储时，它被写入本地磁盘而不是HDFS，这显著提高了性能，特别是在迭代数据处理中。
• 在Mapreduce中，reduce任务需要等到所有map任务完成后才能开始；在Spark中，相同分区的转换构成流水线在同一任务中运行。

3. 3.1流量计算框架. 流计算概述

在大数据时代，数据通常是持续动态的。在许多情况下，数据需要在很短的时间内处理，并考虑容错、拥塞控制等问题，以避免数据遗漏或重复计算。流量计算框架是解决这类问题的方法。DAG(有向无环图)模型通常用于流量计算框架。图中的节点分为两类：一类是数据输入节点，负责与外部交互，并向系统提供数据；另一种是数据计算节点，负责过滤、累积、合并等处理功能。从外部系统传输的实时数据流经这些节点并串联起来。如果将数据流比作水，输入节点就像喷嘴，连续出水，计算节点相当于水管的转接口。如下图所示。

图7. DAG模型示意图流计算

为了提高并发性，每个计算节点对应的数据处理功能被分配到多个任务（相同或不同计算机上的线程）。在设计DAG时，需要考虑如何将待处理的数据分发给下游计算节点对应的任务，在实时计算中称为分组（Grouping）。最简单的方案是复制每个任务，但效率很低，更好的方法是处理每个任务数据的不同部分。应优先考虑随机分组能达到负载均衡的效果。但是，在执行累加、数据关联等操作时，需要确保同一属性的数据固定分发到相应的任务中，此时应采用定向分组。在某些情况下，还需要定制分组方案。

图8. 流计算分组

由于应用场合的广泛性，市场上有许多流量计算平台，包括谷歌 MillWheel、Twitter Stormheron和Apache项目、Samza、S4、Flink、Apex、Gearpump。

3.2. Storm及Trident

Storm是流量计算框架中最受欢迎和应用最广泛的。这是因为Storm有一个简单的编程模型，并支持Java、Ruby、Python和其他开发语言。Storm也具有良好的性能，每秒可以处理数百万条新闻。Storm在容错方面也非常优雅。以下是Storm确保新闻可靠性的想法。

在DAG模型中，确保信息可靠的困难在于，当前计算节点成功处理后，原始数据不能丢弃，因为其生成的数据仍然可能无法处理后续计算节点，需要重新生成。如果您想跟踪记录每个计算节点的信息处理，它将消耗大量的资源。

Storm的解决方案是将一个ID作为每个消息的唯一标志，并在消息中包含原始输入消息的ID。同时使用响应中心（Acker）保持每个原始输入信息的状态，状态的初始值是原始输入信息的ID。在每个计算节点成功执行后，输入和输出信息的ID是不同的或不同的或相应的原始输入信息状态。由于每个消息在生成和处理过程中分别不同或一次，所有消息在成功实施后都不同或两次，相应的原始输入状态为0。因此，当状态为0时，原始输入消息的内容可以安全删除，如果超过指定时间间隔后状态仍不为0，则认为处理消息的某个环节存在问题，需要重新执行。

图9. Storm确保信息可靠性过程示意图

Storm还实现了更高层次的抽象框架Trident。Trident通过微批处理处理数据流，如每次处理100条记录。Trident提供过滤、分组、连接、窗口操作、聚合、状态管理等操作，支持跨批聚合处理，优化执行过程，包括多个操作的合并、数据传输前的本地聚合等。微批处理数据流的框架和Spark Streaming。

(1) 实时流处理

(2) 微批处理

图10. 比较实时流处理和微批处理

以下是Storm、Trident与其他流量计算框架的比较：

4. 交互式分析框架4.1. 概述

在解决了大数据的可靠存储和高效计算后，如何为数据分析师提供便利越来越受到关注，最方便的分析方法是交互式查询。近年来，交互式分析技术发展迅速。目前，这一领域有十多个知名平台，包括谷歌开发的Dremel和Powerdrill，Facebook开发的Presto， Hadoop服务提供商Cloudera和HortonWorks分别开发Impala和Stinger，Apache项目Hive、Drill、Tajo、Kylin、MRQL等。

Spark、Flink等批处理和流量计算平台也内置了交互式分析框架。由于SQL已被业界广泛接受，目前的交互式分析框架支持使用类似SQL的语言进行查询。基于Hadoop的早期交互式分析平台，被称为SQL-on-Hadoop。后来的分析平台改为Spark、Storm等引擎，但是SQL-on-使用了Hadoop的称号。SQL-on-Hadoop还指为分布式数据存储提供SQL查询功能。

4.2. Hive

Apache Hive是由Facebook设计开源的基于Hadoop架构的最早大型数据仓库。Hive的基本思想是将HDFS中的文件组织成类似于传统数据库的存储系统，以定义模式信息。Hive 保持着 Hadoop 提供的可扩展性和灵活性。Hive支持熟悉的关系数据库概念，如表、列和分区，包括一定程度的非结构化数据 SQL 支持。它支持所有主要原语类型(如整数、浮点、字符串)和复杂类型(如字典、列表、结构)。它还支持类似的使用 SQL 声明语言 Hive Query Language (HiveQL) 表达式查询，任何熟悉的查询 SQL 人们很容易理解它。HiveQL被编译成Mapreduce流程执行。如何通过Mapreduce实现JOIN和GROUPP BY。

(1) 实现JOIN

(2) 实现GROUP BY

图11. 实现部分HiveQL操作的方法

与传统关系数据库相比，Hive如下：

Hive的主要弱点是基于Mapreduce，性能有限。基于Hive的改进和扩展，包括Stinger在内的许多交互式分析平台、Presto、Kylin等。Kylin是中国团队向Apache提交的项目，其独特之处在于提供多维分析（OLAP）能力。Kylin预计了多维分析中可能使用的测量，以便在查询时直接访问，从而提供快速查询和高并发性能力。Kylin在eBay、百度、京东、网易、美团都有应用。

4.3. CalciteSQL引擎

SQL查询引擎的优缺点对交互式分析的性能有重要影响。Spark开发了自己的查询引擎Catalyst，包括Hive、Drill、Kylin、许多交互式分析平台和数据仓库，包括Flink，都使用Calcite(原名optiq)作为SQL引擎。Calcite是Apache孵化项目，其创始人Juliann Hyde曾是Oracle数据库SQL引擎的主要开发者。Calcite具有以下技术特点：

• 支持标准SQL语言。
• 支持OLAP。
• 支持查询对流数据。
• 独立于编程语言和数据源，可以支持不同的前端和后端。
• 基于成本模型优化的支持关系代数、可定制的逻辑规划规则和查询引擎。
• 支持物化视图（materialized view）的管理。

由于分布式场景远比传统的数据存储环境复杂，calcite和catalyst仍在向oracle展开、在MySQL等经典关系数据库引擎学习阶段，性能优化还有很长的路要走。

5. 其它类型的框架

除了上面介绍的几种框架外，还有一些不太受欢迎但潜力重要的框架类型。图形计算是DAG以外的另一种迭代计算模型。它基于图论建模和计算现实世界，擅长表达数据之间的相关性，适用于Pagerank计算、社交网络分析、推荐系统和机器学习。这种框架包括谷ogle Pregel、Apache Giraph、Apache Hama、PowerGraph、，PowerGraph是目前该领域最杰出的代表。许多图形数据库也内置图形计算框架。

另一种是增量计算框架，讨论如何只计算一些新数据，以大大提高计算过程的效率，并可应用于数据增量或周期性更新。这种框架包括谷歌 Percolator、Microsoft Kineograph、阿里Galaxy等。

此外，还有Apache Ignite、Apache Geode(Gemfire的开源版)这样的高性能事务处理框架。

6. 总结与展望

自Hadoop诞生以来，大数据分布式计算技术发展迅速。然而，由于历史较短，这项技术还远未成熟。各种框架仍在不断改进，并相互竞争。

性能优化无疑是大数据计算框架改进的关键方向之一。性能的提高很大程度上取决于内存的有效利用。这包括上述内存计算，已广泛应用于各种框架中。内存资源的分配和管理对性能也有重要影响。JVM垃圾回收不仅给开发人员带来了便利，而且限制了内存的有效利用。此外，Java的对象创建和序列化也是浪费资源。Flink是内存优化的代表。考虑到性能，Flink的许多组件不需要依赖JVM垃圾回收机制来管理内存。Flink还使用开放内存池、用二进制数据代替对象、量身定制序列化、定制缓存友好算法等优化手段。Flink还优化了任务的执行，包括多阶段并行执行和增量迭代。

拥抱机器学习和人工智能也是大数据计算的趋势之一。Spark和Flink分别推出了机器学习库Spark ML和Flink ML。更多的平台在第三方大数据计算框架上提供机器学习，如Mahout、Systemlyx和apache孵化项目、HiveMall、PredictionIO、SAMOA、MADLib。这些机器学习平台通常同时支持多个计算框架，如Mahout和Spark、Flink、以H2O为引擎，SAMOA使用S4、Storm、Samza。在深度学习掀起热潮后，一些社区探索将深度学习框架与现有的分布式计算框架相结合。这样的项目包括Sparknet、Caffe on Spark、TensorFrames等。

支持同一平台上的各种框架也是发展趋势之一，特别是对于开发实力雄厚的社区。Spark以批处理模型为核心，实现了交互式分析框架架Spark SQL、Spark Streaming(以及正在实现的Structured Streaming）、GraphXX计算框架、Spark机器学习库 ML。在提供低延迟流量计算的同时，Flink没有落后于批处理、关系计算、图形计算和机器学习。其目标是直接进入大数据通用计算平台。GoogleBEAM(意思是Batch+strEAM）试着把Spark做好、Flink、Apex等计算框架纳入自己制定的标准，颇有号令江湖之意。

图12. 统一的BEAM模型

7. 学习资料

最后，介绍大数据计算的学习材料。入门前的理解、知识的扩展和知识的分散积累取决于相关网站、论坛和微信订阅号的长期访问，而问题的答案取决于搜索引擎的熟练控制。需要指出的是，互联网上的内容是不均衡的，许多信息已经过时，传播虚假信息也很常见，我们应该注意识别。

论坛首次推出知乎，Quora、Stack Overflow，幸运的话，开发者会亲自回答你。其他值得关注的网站或论坛包括炼数成金、全国人大经济论坛、CSDN、博客园、云栖社区、360大数据、推酷、伯乐在线、小象学院等。在微信订阅号中，InfoQ是最权威的，还有THU数据派、大数据杂谈、CSDN大数据、数据猿、Hadop技术博文等。

如果你想系统地学习，你应该首先参考官方网站文档。许多大数据平台的官方文档都比大多数教科书更详细。此外，官方文档和产品通常是同步更新的，这是其他数据无法实现的。然而，在可读性方面，书籍或视频教程要强得多。视频数据可以从上面提到的一些网站论坛下载。

在书籍方面，国外O'Reilly、Mannning两家出版社在大数据领域出版了许多优秀的书籍，尤其是Manning的In Action系列和O'ReilyDefinitive Guide系列。前者注重提高动手能力，后者知识全面。In Action和Definitive Guide系列的很多书都翻译成了中文，一般分别翻译成xx实战和xxx权威指南。另一家出版社Packt也值得关注。Packt的书比较薄，适合入门。至于中文原创书籍，推荐张俊林的《大数据日知录》，是对大数据存储和处理技术的综合梳理，系统性强。其他书不一一点评。如果你想买或读，可以参考豆瓣对这本书的评分。

图13. 一些推荐书籍

对于希望对大数据框架内部机制有深入了解的读者，建议先检索相关论文阅读。

这里就不一一列出谷歌的论文了，网上很容易找到。其他推荐论文如下: