大数据的历史

2018年9月30日，中国互联网巨头腾讯公司的总裁刘炽平发出一封全员信，正式启动了公司历史上第三次重大组织架构调整，外界解读腾讯此举是为了把人工智能、大数据和云计算提升到更核心的战略位置，其实不止腾讯，谷歌、亚马逊、阿里巴巴、百度、小米等互联网巨头近年来都在调整组织架构，这些种种都是为了适应已经无法回避的ABC时代的到来。所谓ABC 是指以A（AI，人工智能）、B（Big Data，大数据）、C（Cloud，云计算）为代表的产业趋势和技术变革。业界普遍认为这将是继PC时代、移动互联网时代后的又一次产业变革，标志着一个全新的时代已经来临。这其中云计算（C）将会像我们日常生活中的水和电一样，作为整个互联网的底层基础设施提供服务，为企业的数据资产提供保管、访问的场所和渠道。有了基础设施但对企业来说只有数据才是真正有价值的资产，这里说的数据包括企业内部的经营信息、互联网中的商品信息、聊天软件中人与人的沟通信息、位置信息等等，这些数据的数量将远远超过企业现有的IT架构和基础设施的承载能力，随之而来的是企业应用的实时性要求也将大大超越现有的计算能力。如何盘活使用这些极具价值的数据资产，让它们能为国家治理、企业决策和个人生活服务，正是大数据处理的核心，也是云计算内在的灵魂和必然的升级方向。

随着这股趋势，最近几年大数据这个词也在诸多技术大会上越来越多地被提及。人们用它来描述和定义信息时代产生的海量数据，并命名与之相关的技术发展与创新。最早提出大数据时代到来的是全球知名咨询公司麦肯锡，其实大数据在物理学、生物学、环境生态学等领域以及军事、金融、通讯等行业存在已有时日，只是因近年来互联网和IT行业的发展而引起人们关注。根据中国信息通信研究院结合对大数据相关企业的调研测算，2017年我国大数据产业规模为4700亿元人民币，同比增长30%，预计到2020年产业规模将达到一万亿。（来源：中国信息通信研究院，《大数据白皮书(2018)》）

究竟何为大数据？根据研究机构Gartner给出的定义：大数据是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。（来源：搜狗百科）而麦肯锡全球研究所给出的定义是：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。诸多定义中搜狗百科的大数据词条更得我心：大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

被誉为“大数据商业应用第一人”的维克托·迈尔·舍恩伯格认为大数据是指不用随机分析法（比如抽样调查）这样的捷径，而是采用对所有数据进行分析处理的方式，大数据的核心就是预测，它将为人类的生活创造前所未有的可量化的维度。他认为大数据时代最大的转变就是，放弃对因果关系的渴求，而取而代之关注相关关系。也就是说只要知道“是什么”，而不需要知道“为什么”。这就颠覆了千百年来人类的思维惯例，对人类的认知和与世界交流的方式提出了全新的挑战（来源：《大数据时代》作者访华 与田溯宁对话大数据_网易科技）。这些用IBM的总结就是5V特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换而言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。

从技术发展历史看，可以把大数据处理划分为前身、产生、和应用三阶段。从上个世纪的90年代一直到本世纪初，可以说是大数据处理的前身，那时的数据存储和处理的主流还是在数据库上，随着数据库技术和数据挖掘理论的日渐成熟，数据仓库和数据挖掘技术开始逐步发展起来，各种商业智能工具开始被应用，比如数据仓库、专家系统、知识管理系统等等。

随着互联网各种新业务的出现，各类非结构化的数据大量涌现，使传统的数据库技术越来越难以应对。例如Facebook的流行使得社交类应用产生的大量非结构化数据，众所周知的 Google 公司其搜索引擎业务天然要面对日益膨胀的海量数据的存储和处理，这些都带动了大数据技术的发展进入了快车道。业界一般以 Google 公司在2003到2006年之间发布的三篇论文作为大数据处理技术产生的起点，分别是：GFS、MapReduce和Bigtable。GFS（2003）是一个可扩展的分布式文件系统，用于对分布式的大量的数据进行访问，它运行于廉价的普通硬件上，并提供了容错功能。MapReduce（2004）是处理海量数据的并行编程模式，用于大规模数据集的并行运算，它能够充分利用GFS集群中所有低价服务器提供的大量CPU，从架构上来说可以看做GFS的补充，它与GFS一道构成了海量数据处理的核心。GFS适合存储少量的非常大的文件，但不适合存储成千上万的小文件，为了处理大量的格式化以及半格式化数据，诞生了管理非关系型数据的分布式数据存储系统BigTable（2006），它的设计目标是快速可靠地处理PB级别的数据，并且能够部署到上千台机器上。以这三篇论文为标志可以看做大数据处理技术的起源。

在大数据处理技术的发展历程中不得不提的是Hadoop，2005年由Apache软件基金会主席Doug Cutting在雅虎时创建这个项目是一个针对大数据分析的开源分布式计算平台，它能够让应用安全扩展以处理数千个节点以及PB级数据。Hadoop通过构建一个关于MapReduce的开源平台，无意中创建了一个蓬勃发展的生态系统，其影响力所及的范围远远超出了其最初Hadoop的范围。在Hadoop社区，工程师可以从早期的GFS和MapReduce论文中改进和扩展这些想法，基于此之上产生了许多有用的工具，如Pig、Hive、HBase、Crunch等等。这种开放性是导致整个行业现有思想多样性的关键，同时Hadoop的开放性生态也直接促进了流计算系统发展。随着互联网行业的快速发展，生产、使用、处理和分析数据的速度也在以令人难以置信的步伐迅速增加，由社交媒体、物联网、广告和游戏等垂直领域都开始处理正在变得越来越大的数据集。从业务上来看这些行业需要一种接近实时的数据处理和分析，因此像Hadoop这种用于大数据的批处理的传统框架已不是很适合这些场合。2007年之后陆续启动了多个开源项目以新的思路来处理来自不止一个数据源的源源不断的数据记录，其中以Apache的众多项目最为著名，目前这些项目都处于不同的发展阶段。

现如今，随着智能移动设备、物联网等技术的广泛应用，数据的碎片化、分布式、流媒体特征更加明显，大数据技术开始与移动和云技术相结合，开始向复杂事件处理、图形数据库和内存计算等方向发展。大数据的概念越来越被垂直行业以及大众所接受，通过催化新的商业模式使得大数据同传统行业的边界变得越来越模糊，大家开始更加关注业务的创新而非技术本身，大数据产业的主题也转向应用对行业的变革性影响，来到了真正的应用阶段。

大数据的发展方向

大数据技术是一种新的技术和架构，致力于以较低的成本、更快速的采集、处理和分析各种超大规模的数据，从中提取对企业有价值的信息。随着该技术的蓬勃发展，让我们处理海量数据更加容易、更加便宜和迅速，成为利用数据的好助手，甚至可以改变许多行业的商业模式。在人工智能、云计算和物联网的帮助下，即使是复杂的大数据，也可以由普通的数据从业者利用相应的数据分析工具来进行处理。大数据分析已经脱离了热门IT趋势标签，现如今成为了公司业务必须的一部分，它将很快取代黄金成为人类最宝贵的资产之一，在《未来简史》中讲到：“谁拥有数据，谁拥有对数据的解释权，谁就有可能在未来的竞争中占得先机”。为了让读者快速了解有关大数据的最新信息，下面列出了一些最热门的大数据趋势，以推动行业未来发展。以下是摘自阿里云栖社区翻译整理的关于大数据值得了解的十大数据发展趋势

快速增长的物联网网络

由于物联网（IoT）技术，智能手机被用于控制家用电器变得越来越普遍。随着小米和阿里等智能设备在家庭中实现特定任务的自动化的普及，物联网热潮也正吸引着很多公司投资于该技术的研发。

更多组织将抓住机会以提供更好的物联网解决方案，这必然将带来更多收集大量数据的方法，以及管理和分析数据的方法。业界的研究趋势是推动更多能够收集、分析和处理数据的新设备，比如手环、智能音箱、眼镜等。

普及的人工智能技术

人工智能现在更常用于帮助大公司和小公司改善其业务流程。人工智能现在可以在执行任务时，能够比人类更快、更精确，以此减少人为引入的错误并改善整体流程，这使得人们能够更好地专注于更关键的任务，并进一步提高服务质量。

人工智能的快速发展以及较高的薪资吸引着很多开发人员进入该领域，幸运的是，市面上有成熟的人工智能开发工具箱可供使用，每个人都可以根据实际任务构建相应的算法，满足不断增长的需求。如果个人组织能够找到将其整合到业务流程中的最有效方式，那么可能会获得较大的优势。

预测分析的兴起

大数据分析一直是企业获得竞争优势并实现目标的关键战略之一，研究人员使用必要的分析工具来处理大数据并确定某些事件发生的原因。现在，通过大数据进行预测分析可以帮助更好地预测未来可能发生的情况。

毫无疑问，这种策略在帮助分析收集的信息以预测消费者行为方面非常有效，这允许公司在做相关开发之前了解客户的下一步行动，以确定他们必须采取的措施。数据分析还可以提供更多数据上下文，以帮助了解其背后真正的原因。

迁移到云端的暗数据

尚未转化为数字格式的信息称为暗数据，它是一个目前尚未开发的巨大数据库。预计这些模拟数据库将被数字化并迁移到云端，进而用于对企业有利的预测分析。

首席数据官将发挥更大的作用

现在，大数据越来越成为执行业务战略中的重要组成部分，首席数据官也在其组织中发挥着更重要的作用。首席数据管们被期待着引导公司走向正确的方向，并采取更积极的方法，这一趋势为寻求职业发展的数据营销人员打开了大门。

量子计算

目前，使用我们现有的的技术分析和解释大量数据可能需要花费大量时间，如果能在短短几分钟内同时处理数十亿的数据，我们就可以大大缩短处理时间，让公司有机会做出及时的决策，以达到更理想的效果。

这项艰巨的任务只能通过量子计算实现，尽管目前量子计算机的研究处于起步阶段，但已经有一些公司正在使用量子计算机进行相关实验，以帮助不同行业的实践和理论研究。之后不久，谷歌、IBM和微软等大型科技公司都将开始测试量子计算机，将它们集成到业务流程中。

开源解决方案

目前，有许多可用的公共数据解决方案，例如开源软件，它们已经在加速数据处理方面取得了相当大的进步，同时还具有实时访问和响应数据的功能。出于这个原因，预计它们将在今后快速发展且需求量会很大。虽然，开源软件很便宜，可以使用开源软件降低企业的运营成本，但是，使用开源软件也有一些弊端，这里是你需要知道的一些缺点。

边缘计算

由于物联网的发展趋势，许多公司正在转向研究连接设备以收集客户更多的数据或流程数据，这就创造了对技术创新的需求。新的技术旨在减少从数据收集到云端，其分析和需要采取行动的滞后时间。

针对这一问题，边缘计算可以提供更好的性能，因为其流入和流出网络的数据更少，云计算的成本更低。如果公司选择删除掉之前从物联网中收集到的不必要的数据，公司也可以从降低存储和基础设施这些成本中受益。此外，边缘计算可以加速数据分析，为公司做出正确的反应提供充足的时间。

更智能的聊天机器人

由于人工智能的快速发展，很多公司现在正部署聊天机器人来处理客户查询等应用场景，以提供更加个性化的交互模式，同时消除对人工的需求。

大数据与提供更愉快的客户体验之间有着很大的关系，因为机器人通过处理大量数据，进而根据客户在查询中输入的关键字来提供相关答案。在交互过程中，他们还能够从对话中收集和分析出有关客户的信息，这一流程进而帮助营销人员制定出更简化的策略，以实现更好的用户转化率。

总结

所有这些不同跨行业的技术飞跃，都是基于大数据的发展为其奠定的坚实基础。技术的进步将继续通过更智能的流程帮助我们创造出一个更美好的社会。我们必须充分了解这种技术的使用方式，以及腰实现具体的业务目标，二者结合才能最终从这些趋势中受益。这些都只是一个开始，大数据将继续作为我们在业务和技术方面所经历变革的催化剂。我们可以做的是思考如何有效地适应这些变化，并利用这项技术实现业务蓬勃发展。

其他还有人民网与去年发表的2018全球大数据产业将呈七大发展趋势

大数据处理框架简介

从技术角度看，一般认为真正开启大数据处理技术之门的是 Google 在2003到2006年间发表的三篇经典文章：GFS、BigTable、MapReduce，它们也被称为 Google 的分布式计算三驾马车，由此开始诞生了第一个在开源社区获得极大关注的大数据处理框架 Hadoop ，这个以 HDFS、HBase、MapReduce 为主的技术栈其影响一直延续到今天。

开始时大数据处理大都采用 离线处理 的方式，其核心处理逻辑是 MapReduce 。所谓 MapReduce 就是把所有的操作都分成两类：map 和 reduce。map 用来把数据分成多份，分开处理。reduce 则把处理后的结果进行归并，得到最终的结果。MapReduce 的理念虽好但在实际应用中的性能表现欠佳。其后出现了 Spark 框架通过其强大而高性能的批处理技术逐渐取代 MapReduce 成为大数据处理的主流。

随着时代的发展很多业务已经不再满足于离线的批处理方式，需要实时处理的场景变得越来越多。为了应付此类需求，Spark 推出了 Spark Streaming 以 微批处理 来模拟 准实时 的效果，但在处理实效上还是不尽如人意。以2011年 Twitter 推出的 Storm 流计算系统为标志，开启了面向更低延迟的流处理的方案。之后流处理的模式由 Flink 发扬光大，Flink 并不局限于单纯的流计算引擎，而是提供了一种更通用的可以处理批处理任务的流处理框架，从而开始正面挑战 Spark 的地位。

在大数据处理技术的讨论中经常会听到两个词：处理框架 和 处理引擎，按我个人的理解 引擎 和 框架 其实并没有什么区别，都是指对系统中的数据进行计算，但大部分时候把实际负责处理数据操作的组件称作引擎，而承担类似作用的 一系列组件 则叫做框架。比如 Hadoop 可以看作一种以 MapReduce 作为默认处理引擎的处理框架，而另一个处理框架 Spark 则可以纳入 Hadoop 中取代 MapReduce 的作用。这种组件和组件之间的互操作特性也是大数据系统之所以如此灵活的原因之一，因此在谈论大数据时一般情况下可以把 引擎 和 框架 相互替换或同时使用。

假如把大数据的处理框架按处理数据的状态进行分类，则某些系统是用批处理的方式处理数据，一些系统是以流的方式处理连续不断流入系统的数据，还有一些系统则同时支持这两种方式。因此我们可以把大数据处理框架分为三种类型：批处理、流处理 和 混合处理 。

批处理

所谓 批处理 是指把一项数据处理任务先分解成更小粒度的任务，把这些任务分布在集群中的各台实例上进行计算，之后把各实例上的计算结果重新计算和组合成最终结果。批处理系统通常会操作大量的静态的数据，并等到这些数据全部处理完成后才能得到返回的结果。这种模式适用于需要访问全量记录才能完成的工作，比如在计算总数和平均数时必须将数据集作为一个整体加以处理，而不能将其视作多条记录的集合。由于批处理在处理海量的持久数据方面表现出色，所以通常用于处理历史数据，很多在线分析处理系统的底层计算框架就是使用的批处理。批处理方式使用的数据集通常有以下特征：

• 有界：批处理数据集代表数据的有限集合
• 持久：数据通常始终存储在某种类型的持久存储位置中
• 大量：批处理操作通常是处理极为海量数据集的唯一方法

批处理框架的代表就是 Hadoop ，它是第一个在开源社区获得极大关注的大数据处理框架，很长时间内几乎是大数据技术的代名词。Hadoop 是一种分布式计算的基础架构，迄今为止 Hadoop 已经形成了一个广阔的生态圈，内部实现了大量的算法和组件，其核心有两个：HDFS 和 MapReduce 。HDFS （Hadoop 分布式文件系统）是一个分布式文件系统，这样的文件系统可以架构在价格低廉的集群上。MapReduce 是一种分布式任务处理的架构，正是这两部分构成了 Hadoop 的基石。Hadoop 的核心机制是通过 HDFS 和 MapReduce 进行数据存储、内存和程序的有效利用与管理。通过 Hadoop 把由多台普通的、廉价的服务器组合成分布式的计算-存储集群，从而提供大数据的存储和处理能力。

Hadoop 实际是一个大项目的总称，内部包含了很多子项目：

• HDFS：Hadoop分布式文件系统。它是 GFS 的开源实现，用于存储 Hadoop 集群中所有存储节点上的文件。可以在普通的 PC 集群上提供可靠的文件存储，通过数据块进行多个副本备份来解决服务器宕机或者硬盘损坏的问题。
• MapReduce：一个基于 Java 的并行分布式计算框架，它是 Hadoop 的原生批处理引擎，也是 Google 的 MapReduce 论文的开源实现。
• HBase：一个开源的分布式 NoSQL 数据库，它参考了 Google 的 BigTable建模。
• Hive：数据仓库工具。
• Pig：大数据分析平台。
• Mahout：一个机器学习 Java 类库的集合，用于完成各种各样的任务，如分类、评价性的聚类和模式挖掘等。其内部提供了一些经典的机器学习的算法。
• Zookeeper：一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。在 Hadoop 中它主要用来控制集群中的数据，比如管理 Hadoop 集群中的 NameNode，Hbase 中 Master Election、Server 之间状态同步等。
• Sqoop：用于在 Hadoop 与传统的数据库间进行数据的传递。
• Ambari：Hadoop 管理工具，可以快捷的监控、部署、管理集群。
  

  

Hadoop 及其 MapReduce 处理引擎提供了一套久经考验的批处理模型，以其可靠、高效、可伸缩的特点使人们能很方便地处理海量数据。允许用户通过很低成本的组件即可搭建完整功能的 Hadoop 集群，因此这种廉价而高效的处理技术可以灵活应用在很多案例中。与其他框架和引擎的兼容与集成能力使 Hadoop 可以成为使用不同技术的多种工作负载处理平台的底层基础。不过由于这种处理模式需要依赖持久存储，计算任务需要在集群的节点上执行多次读写，因此在速度上会稍显劣势，但是其吞吐量也同样是其他框架所不能匹敌的，这也是批处理模式的特点。

流处理

流处理 方式会随时对进入系统的数据进行实时的计算，这种模式不需要针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作。流处理中的数据集是 无边界 的，这就产生了几个重要的影响：

• 完整数据集只能代表截至目前已经进入到系统中的数据总量。
• 工作数据集也许更相关，在特定时间只能代表某个单一数据项。
• 处理工作是基于事件的，除非明确停止否则没有“尽头”。处理结果立刻可用，并会随着新数据的抵达继续更新。

小学时我们都会做过这样的数学题：一个水池有一个进水管和一个出水管，只打开进水管x个小时充满水，只打开出水管y个小时流光水，那么同时打开进水管和出水管，水池多长时间充满水？流处理系统就相当于这个水池，把流进来的水（数据）进行加工，然后再把加工过的水（数据）从出水管放出去。这样数据就像水流一样永不停止，而且在水池中就被处理过了。这种处理永不停止的接入数据的系统就叫做流处理系统。流处理系统并不对已经存在的数据集进行操作，而是对从外部系统接入的的数据进行处理。流处理系统可以分为两种：

• 逐项处理：每次处理一条数据，是真正意义上的流处理。
• 微批处理：这种处理方式把一小段时间内的数据当作一个微批次，对这个微批次内的数据进行处理。

由于海量数据的处理需要耗费大量的时间，所以批处理的方式不适合对处理结果时延要求较高的场景。而不管是逐项处理还是微批处理，其实时性都要远好于批处理模式，因此流处理适用于有接近实时处理需求的任务场景，比如日志分析，设备监控、网站实时流量变化等。因为这些领域对数据的变化做出及时反馈是很常见的需求，流处理适用于必须对变动或峰值做出响应，并且关注一段时间内变化趋势的数据。

流处理系统领域比较著名的框架有 Twitter 公司开源的 Storm ，LinkedIn 公司开源的 Samza，阿里巴巴的 JStrom，Spark 的 Spark Streaming 等等，它们都具有低延迟、可扩展和容错性等优点，允许你在运行数据流代码时，将任务分配到一系列具有容错能力的计算机上并行执行。也都提供了简单的 API 来简化底层实现，这些框架内部使用的术语可能并不相同，但包含的概念其实还是类似的，这里以 Storm 为例主要介绍一下。

在 Storm 中有一个用于实时计算的图状结构，称之为拓扑（topology）。这个拓扑将会被提交给集群，由集群中的主控节点（master node）分发代码，再将任务分配给工作节点（worker node）执行。一个拓扑中有 spout 和 bolt 两种角色，其中 spout 发送消息，负责将数据流以 tuple 元组形式发送出去。而 bolt 则负责转换这些数据流，在 bolt 中可以完成计算、过滤等操作，bolt 本身也可以随机将数据发送给其他 bolt。由 spout 发射出的 tuple 是不可变数组，对应着固定的键值对。

如果说 Hadoop 是水桶只能一桶一桶的去井里扛的话，那 Storm 就是水龙头，只要打开它就可以源源不断的出水。Storm 支持的语言比较多，比如 Java、Ruby、Python 等等。Storm 可以方便的在一个集群中编写和扩展复杂的实时计算，Storm 保证每个消息都会得到处理而且速度很快，在一个小集群中每秒可以处理数以百万计的消息。

Storm 是一个侧重于极低延迟的流处理框架，它可处理非常大量的数据，通过比其他解决方案更低的延迟提供结果。Storm 适合对于延迟要求比较高的单纯的流处理类型工作，它可以保证每条消息都被处理，还可以配合多种编程语言使用。

混合处理

在大数据处理技术中流派中，除了单纯的批处理和流处理模式之外，还有一些处理框架既可以进行批处理也可以进行流处理，我们称之为混合处理框架。虽然专注于一种处理方式可能非常适合特定场景，但是混合框架为数据处理提供了通用的解决方案。这些框架可以用相同或相关的组件和 API 处理两种类型的数据，借此让不同的处理需求得以简化。混合处理框架中目前比较著名的就是 Spark 和 Flink 。

Spark 是一种包含流处理能力的批处理框架，它既有自带的实时流处理工具，也可以和 Hadoop 集成，代替其中的 MapReduce。Spark 还可以拿出来单独部署集群，但是得借助 HDFS 等分布式存储系统。Spark 的强大之处在于其运算速度，与 Storm 类似 Spark 也是基于内存的，并且在内存满负载的时候，硬盘也能运算。Spark 最初的设计受 MapReduce 思想的启发，但不同于 MapReduce 的是 Spark 通过内存计算模型和执行优化大幅提高了对数据的处理能力。除了最初开发用于批处理的 Spark Core 和用于流处理的 Spark Streaming 之外，它还提供了其他编程模型用于支持图计算（GraphX）、交互式查询（Spark SQL）和机器学习（MLlib）。

Flink 则是一种可以处理批处理任务的流处理框架。在设计初始，Fink 的侧重点在于处理流式数据，这与 Spark 的设计初衷恰恰相反。Spark 把流拆分成若干个小批次来处理，而 Flink 把批处理任务当作有界的流来处理。Flink 中把批处理的数据看做是具备有限边界的数据流，借此将批处理任务作为流处理的子集加以处理。Flink 除了处理提供流处理（DataStream API）和批处理（DataSet API）能力之外，还提供了类SQL查询（Table API）、图计算（Gelly）和机器学习库（Flink ML）。Flink 还兼容原生 Storm 和 Hadoop 程序，可以在 YARN 管理的集群上运行。虽然 Spark 同样也提供了批处理和流处理的能力，但 Spark 流处理的微批次架构使其响应时间略长。Flink 流处理优先的方式实现了低延迟、高吞吐和真正逐条处理。虽然这两种框架经常被拿来做对比，但在市场需求的驱使下，其实两者都在朝着更多的兼容性发展。

离线与实时

假如把大数据技术按数据处理的时效性来划分则有离线计算和实时计算两类。

离线计算是在计算开始前已知所有输入数据，输入数据不会产生变化，且在解决一个问题后就要立即得出结果的前提下进行的计算。一般来说，离线计算具有数据量巨大且保存时间长；在大量数据上进行复杂的批量运算；数据在计算之前已经完全到位，不会发生变化；能够方便的查询批量计算的结果等特点。

实时计算是计算机科学中对受到 实时约束 的计算机硬件和计算机软件系统的研究，实时约束是从事件发生到系统回应之间的最长时间限制。实时程序必须保证在严格的时间限制内响应。通常要求实时计算的响应时间是以毫秒为单位，也有时是以微秒为单位。相比之下，非实时系统是一种无法保证在任何条件下，回应时间均匹配实时约束限制的系统。有可能大多数的情形下，非实时系统都可以匹配实时约束限制，甚至更快，只是无法保证在任何条件都可以匹配约束限制。与离线计算对应的则是实时计算，数据实时产生后就立刻处理，这种计算方式倾向于把数据看作是流。实时计算一般都是针对海量数据进行的，一般要求为秒级。实时计算主要分为两块:数据的实时入库、数据的实时计算。

以 Storm 为代表的实时计算和以 MapReduce 为代表的离线计算。实时计算对数据处理时间有着较高的要求，对于延迟阈值大数据界一直没有统一标准，默认是秒级（严格来说实时系统必须保证在某个时间边界内响应，通常是毫秒级或亚秒级，但无论是 Spark Streaming 还是 Storm 都只能保证计算时间较低，因此应该属于近实时系统）。离线计算对数据处理时间不太敏感，通常只要求在 N+1 的时间内看到结果。

由于应用场景不同，这两种计算引擎接受数据的方式也不太一样：实时计算的数据源通常是流式的，也就是来一条数据处理一条，所以也被称为流式计算。而离线计算的数据源通常是静态的、一个计算周期的完整数据，计算的时间也被设置在一个周期的数据全部收到后（通常是凌晨计算前一天的数据），所以也被称为批处理计算。有时这两种不同的数据接收方式以及它们所导致的不同的运行时间（实时计算任务需要一直运行，离线任务则是定时运行），会被一些工程师用于区分实时计算引擎和离线计算引擎。

总结

尽管流处理和批处理（特别是微批处理）之间的差异似乎只是时间差异很小的问题，但它们实际上对数据处理系统的体系结构和使用它们的应用程序都有着根本的影响。流处理系统的设计是为了在数据到达时对其进行响应。这就要求它们实现一个由事件驱动的体系结构, 即系统的内部工作流设计为在接收到数据后立即连续监视新数据和调度处理。另一方面, 批处理系统中的内部工作流只定期检查新数据, 并且只在下一个批处理窗口发生时处理该数据。

流处理和批处理之间的差异对于应用程序来说也是非常重要的。为批处理而构建的应用程序，通过定义处理数据，具有延迟性。在具有多个步骤的数据管道中，这些延迟会累积。此外，新数据的到达与该数据的处理之间的延迟将取决于直到下一批处理窗口的时间--从在某些情况下完全没有时间到批处理窗口之间的全部时间不等，这些数据是在批处理开始后到达的。因此，批处理应用程序(及其用户)不能依赖一致的响应时间，需要相应地调整以适应这种不一致性和更大的延迟。

批量处理通常适用于具有最新数据并不重要的用例，以及容忍较慢响应时间的情况。而流处理对于需要实时交互和实时响应的用例是必需的。

大数据系统可使用多种处理技术。对于仅需要批处理的工作负载，如果对时间不敏感，比其他解决方案实现成本更低的 Hadoop 将会是一个好选择。对于仅需要流处理的工作负载，Storm 可支持更广泛的语言并实现极低延迟的处理，但默认配置可能产生重复结果并且无法保证顺序。Samza 与 YARN 和 Kafka 紧密集成可提供更大灵活性，更易用的多团队使用，以及更简单的复制和状态管理。对于混合型工作负载，Spark 可提供高速批处理和微批处理模式的流处理。该技术的支持更完善，具备各种集成库和工具，可实现灵活的集成。Flink 提供了真正的流处理并具备批处理能力，通过深度优化可运行针对其他平台编写的任务，提供低延迟的处理，但实际应用方面还为时过早。

最适合的解决方案主要取决于待处理数据的状态，对处理所需时间的需求，以及希望得到的结果。具体是使用全功能解决方案或主要侧重于某种项目的解决方案，这个问题需要慎重权衡。随着逐渐成熟并被广泛接受，在评估任何新出现的创新型解决方案时都需要考虑类似的问题。