3.4 大数据技术

对于普通人来说，大数据离我们的生活很远，但它的威力已无所不在：信用卡公司追踪客户信息，能迅速发现资金异动，并向持卡人发出警示；能源公司利用气象数据分析，可以轻松选定安装风轮机的理想地点；瑞典首都斯德哥尔摩使用运算程序管理交通，令市区拥堵时间缩短一半……这些都与大数据有着千丝万缕的关系。牛津大学教授维克托·迈尔-舍恩伯格在其新书《大数据时代》中说，这是一场“革命”，将对各行各业带来深刻影响，甚至改变我们的思维方式。如今，信息每天都在以爆炸式的速度增长，其复杂性也越来越高，当人类的认知能力受到传统可视化形式的限制时，隐藏在大数据背后的价值就难以发挥出来。理解大数据并借助其做出决策，才能发挥它的巨大价值和无限潜力。其中的一把金钥匙就是大数据技术。

在数据内容足够丰富、数据量足够大的前提下，隐含于大数据中的规律、特征就能被识别出来。通过创新性的大数据分析方法实现对大量数据快速、高效、及时地分析与计算，得出跨数据间的、隐含于数据中的规律、关系和内在逻辑，帮助用户理清事件背后的原因，预测发展趋势，获取新价值。

●　可视化分析

大数据分析的使用者有大数据分析专家，也有普通用户，但是二者对于大数据分析最基本的要求都是可视化分析，因为可视化分析能够直观地呈现大数据的特点，同时能够非常容易地被读者所接受，就如同看图说话一样简单明了。

●　数据挖掘算法

大数据分析的理论核心是数据挖掘算法。各种数据挖掘的算法基于不同的数据类型和格式才能更加科学地呈现出数据本身具备的特点，也正是因为这些被全世界统计学家所公认的各种统计方法（可以称为真理），才能深入数据内部，挖掘出公认的价值。另一方面，也是因为有这些数据挖掘的算法，才能更快速地处理大数据，如果一个算法得花费好几年才能得出结论，那么大数据的价值也就无从说起了。

●　预测性分析能力

大数据分析最重要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学地建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。

●　语义引擎

大数据分析广泛应用于网络数据挖掘，可以从用户的搜索关键词、标签关键词或其他输入语义分析和判断用户的需求，从而实现更好的用户体验和广告匹配。

●　数据质量和数据管理

大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。

大数据分析的基础就是以上几个方面，当然更加深入大数据分析的话，还有很多更加有特点的、更加深入的、更加专业的大数据分析方法。

3.4.1 数据技术的演进

大数据技术可以分成两个大的层面，即大数据平台技术与大数据应用技术。要使用大数据，必须先有计算能力，大数据平台技术包括数据的采集、存储、流转、加工所需要的底层技术，如Hadoop生态圈。大数据应用技术是指对数据进行加工，把数据转化成商业价值的技术，如算法，以及由算法衍生出来的模型、引擎、接口、产品等。这些数据加工的底层平台包括平台层的工具以及平台上运行的算法，也可以沉淀到一个大数据的生态市场中，避免重复的研发，大大地提高了大数据的处理效率。

大数据首先需要有数据，数据首先要解决采集与存储的问题。数据采集与存储技术随着数据量的爆发与大数据业务的飞速发展，也在不停地进化。在大数据的早期，或者很多企业的发展初期，只有关系型数据库用来存储核心业务数据，即使是数据仓库，也是集中型OLAP关系型数据库。比如很多企业，包括早期的淘宝，就建立了很大的Oracle RAC作为数据仓库，按当时的规模来说，可以处理10TB以下的数据规模。一旦出现独立的数据仓库，就会涉及ETL，如数据抽取、数据清洗、数据校验、数据导入，甚至是数据安全脱敏。如果数据来源仅仅是业务数据库，ETL还不会很复杂，如果数据的来源是多方的，比如日志数据、App数据、爬虫数据、购买的数据、整合的数据等，ETL就会变得很复杂，数据清洗与校验的任务就会变得很重要。这时的ETL必须配合数据标准来实施，如果没有数据标准的ETL，可能会导致数据仓库中的数据都是不准确的，错误的大数据会导致上层数据应用和数据产品的结果都是错误的。错误的大数据结论还不如没有大数据。由此可见，数据标准与ETL中的数据清洗、数据校验是非常重要的。

随着数据的来源变多，数据的使用者变多，整个大数据流转就变成了一个非常复杂的网状拓扑结构。在这个网络中，每个人都在导入数据、清洗数据，同时每个人也都在使用数据，但是谁都不相信对方导入和清洗的数据，就会导致重复数据越来越多，数据任务越来越多，任务的关系也越来越复杂。要解决这样的问题，必须引入数据管理，也就是针对大数据的管理，比如元数据标准、公共数据服务层（可信数据层）、数据使用信息披露等。

随着数据量的持续增长，集中式的关系型OLAP数据仓库已经不能解决企业的问题，这个时候就出现了基于MPP的专业级数据仓库处理软件，如Greenplum。Greenplum采用MPP方式处理数据，可以处理的数据更多更快，但是本质上还是数据库的技术。Greenplum支持100台机器左右的规模，可以处理拍字节（PB）级别的数据量。Greenplum的产品是基于流行的PostgreSQL开发的，几乎所有的PostgreSQL客户端工具及PostgreSQL应用都能运行在Greenplum平台上。

随着数据量的持续增加，比如每天需要处理100PB以上的数据，每天有100万以上的大数据任务，使用以上解决方案都没有办法解决了，这个时候就出现了一些更大的基于M/R分布式的解决方案，如大数据技术生态体系中的Hadoop、Spark和Storm。它们是目前最重要的三大分布式计算系统，Hadoop常用于离线的、复杂的大数据处理，Spark常用于离线的、快速的大数据处理，而Storm常用于在线的、实时的大数据处理。

3.4.2 分布式计算系统概述

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。Hadoop框架最核心的设计是：HDFS和MapReduce。HDFS为海量的数据提供了存储，而MapReduce为海量的数据提供了计算。Hadoop作为一个基础框架，上面也可以承载很多其他东西，比如Hive，不想用程序语言开发MapReduce的人、熟悉SQL的人可以使用Hive离线地进行数据处理与分析工作。比如HBase，作为面向列的数据库运行在HDFS之上，HDFS缺乏随机读写操作，HBase正是为此而出现的，HBase是一个分布式的、面向列的开源数据库。

Spark也是Apache基金会的开源项目，它由加州大学伯克利分校的实验室开发，是另一种重要的分布式计算系统。Spark与Hadoop最大的不同点在于，Hadoop使用硬盘来存储数据，而Spark使用内存来存储数据，因此Spark可以提供超过Hadoop 100倍的运算速度。Spark可以通过YARN（另一种资源协调者）在Hadoop集群中运行，但是现在的Spark也在往生态走，希望能够上下游通吃，一套技术栈解决大家多种需求。比如Spark SQL，对应着Hadoop Hive，Spark Streaming对应着Storm。

Storm是Twitter主推的分布式计算系统，是Apache基金会的孵化项目。它在Hadoop的基础上提供了实时运算的特性，可以实时地处理大数据流。不同于Hadoop和Spark，Storm不进行数据的收集和存储工作，它直接通过网络实时地接收数据并且实时地处理数据，然后直接通过网络实时地传回结果。Storm擅长处理实时流式数据。比如日志、网站购物的点击流是源源不断的、按顺序的、没有终结的，所有通过Kafka等消息队列传来数据后，Storm就开始工作。Storm自己不收集数据也不存储数据，一边传来数据，一边处理，一边输出结果。

上面的三个系统只是大规模分布式计算底层的通用框架，通常也用计算引擎来描述它们。除了计算引擎外，想要做数据的加工应用，我们还需要一些平台工具，如开发IDE、作业调度系统、数据同步工具、BI模块、数据管理平台、监控报警等，它们与计算引擎一起构成大数据的基础平台。在这个平台上，我们可以做大数据的加工应用，开发数据应用产品。比如一个餐厅，为了做中餐、西餐、日料、西班牙菜，必须有食材（数据），配合不同的厨具（大数据底层计算引擎），加上不同的佐料（加工工具），才能做出不同类型的菜系。但是为了接待大批量的客人，还必须配备更大的厨房空间、更强的厨具、更多的厨师（分布式）。做的菜到底好吃不好吃，这又得看厨师的水平（大数据加工应用能力）。

3.4.3 Hadoop

Hadoop由Apache基金会开发。它受到谷歌开发的Map/Reduce和Google File System（GFS）的启发。可以说Hadoop是谷歌的Map/Reduce和Google File System的开源简化版本。

Hadoop是一个分布式系统的基础架构。Hadoop提供一个分布式文件系统架构（Hadoop Distributed File System, HDFS）。HDFS有着高容错性的特点，并且设计用来部署在相对低成本的x86服务器上。而且它提供高传输率来访问应用程序的数据，适合有着超大数据集的应用程序。

Hadoop的MapReduce是一个能够对大量数据进行分布式处理的软件开发框架，是一个能够让用户轻松架构和使用的分布式计算平台。用户可以轻松地在Hadoop上开发和运行处理海量数据的应用程序。它主要有以下几个优点。

• 高可靠性。Hadoop的海量存储和处理数据的能力极强，同时具备高可靠性。

• 高扩展性。Hadoop采用分布式设计，可以方便地扩展到数以千计的节点中。

• 高效性。Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。

• 高容错性。Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。

• 高性价比。与常见的大数据处理一体机、商用数据仓库等数据集市相比，Hadoop是开源的，设备通常采用高性价比的x86服务器，项目的软硬件成本因此会大大降低。

1. 拓扑架构

如图3-9所示，Hadoop由许多元素构成。其最底层是HDFS，用于存储Hadoop集群中所有存储节点上的文件。HDFS的上一层是MapReduce分布式计算框架，该引擎由JobTrackers和TaskTrackers组成。HBase利用Hadoop HDFS作为其文件存储系统，利用Hadoop MapReduce来处理HBase中的海量数据，利用ZooKeeper作为协同服务。

（1）HDFS

在Hadoop中，所有数据都被存储在HDFS上，而HDFS由一个管理节点（NameNode）和N个数据节点（DataNode）组成，每个节点均为一台普通的x86服务器。HDFS在使用上与单机的文件系统很类似，一样可以建立目录，创建、复制和删除文件，查看文件内容等。但底层实现是把文件切割成Block（通常为64MB），这些Block分散存储在不同的DataNode上，每个Block还可以复制数份存储于不同的DataNode上，达到容错冗余的目的。NameNode是HDFS的核心，通过维护一些数据结构记录每个文件被切割成多少个Block，以及这些Block可以从哪些DataNode中获得、各个DataNode的状态等重要信息。

HDFS可以保存比一个机器的可用存储空间更大的文件，这是因为HDFS是一套具备可扩展能力的存储平台，能够将数据分发至成千上万个分布式节点及低成本服务器之上，并让这些硬件设备以并行方式共同处理同一任务。

（2）分布式计算框架（MapReduce）

MapReduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性。MapReduce实现了大规模的计算：应用程序被分割成许多小部分，而每个部分在集群中的节点上并行执行（每个节点处理自己的数据）。

总之，Hadoop是一种分布式系统的平台，通过它可以很轻松地搭建一个高效、高质量的分布式系统。Hadoop的分布式包括两部分：一个是分布式文件系统HDFS；另一个是分布式计算框架，一种编程模型，就是MapReduce，两者缺一不可。用户可以通过MapReduce在Hadoop平台上进行分布式的计算编程。

（3）基于Hadoop的应用生态系统

Hadoop框架包括Hadoop内核、MapReduce、HDFS和Hadoop YARN等。Hadoop也是一个生态系统，在这里面有很多组件。除了HDFS和MapReduce外，还有NoSQL数据库的HBase、数据仓库工具Hive、Pig工作流语言、机器学习算法库Mahout、在分布式系统中扮演重要角色的ZooKeeper、内存计算框架的Spark、数据采集的Flume和Kafka。总之，用户可以在Hadoop平台上开发和部署任何大数据应用程序。

HBase是Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在高性价比的x86服务器上搭建起大规模的结构化存储集群。HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；谷歌运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用ZooKeeper作为对应。

Hadoop应用生态系统的各层系统中，HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算框架，ZooKeeper为HBase提供了稳定服务和Failover机制。

此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变得非常简单。Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变得非常方便。

2. 行业应用

总之，数据处理模式会发生变化，不再是传统的针对每个事务从众多源系统中拉数据，而是由源系统将数据推至HDFS，ETL引擎处理数据，然后保存结果。结果可以将来用Hadoop分析，也可以提交到传统报表和分析工具中分析。经证实，使用Hadoop存储和处理结构化数据可以减少10倍的成本，并可以提升4倍处理速度。以金融行业为例，Hadoop有以下几个方面可以对用户的应用有帮助。

（1）涉及的应用领域：内容管理平台。海量低价值密度的数据存储，可以实现像结构化、半结构化、非结构化数据存储。

（2）涉及的应用领域：风险管理、反洗钱系统等。利用Hadoop做海量数据的查询系统或者离线的查询系统。比如用户交易记录的查询，甚至是一些离线分析都可以在Hadoop上完成。

（3）涉及的应用领域：用户行为分析及组合式推销。用户行为分析与复杂事务处理提供相应的支撑，比如基于用户位置的变化进行广告投送，进行精准广告的推送，都可以通过Hadoop数据库的海量数据分析功能来完成。

3. 软件厂商

Hadoop软件发布版的主要厂商有Cloudera和Hortonworks。Cloudera是被广泛采用的纯Hadoop软件发布厂商，其核心的开源产品Cloudera Distribution包括Apache Hadoop（CDH），被许多初期采用的公司广泛使用，也在基于Hadoop构建的云／SaaS厂商中非常流行。Cloudera和很多硬件大型IT公司结成了强大的合作伙伴关系。

Hortonworks为Hadoop生态系统提供专业服务，Yahoo和Benchmark Capital在2011年6月合资创建了Hortonworks。除了进一步开发Apache Hadoop的开源分发以外，Hortonworks也提供Hadoop专业服务，它在整个Hadoop产业中是技术领导者和生态环境的构建者。最近其发布的Hortonworks Data Platform集成了纯粹的开源Apache Hadoop软件。

4. 成功案例

Hadoop尤其适合大数据的分析与挖掘。因为从本质上讲，Hadoop提供了在大规模服务器集群中捕捉、组织、搜索、共享以及分析数据的模式，且可以支持多种数据源（结构化、半结构化和非结构化），规模则能够从几十台服务器扩展到上千台服务器。

基于Hadoop的应用目前已经开始遍地开花，尤其是在互联网领域。Yahoo!通过集群运行Hadoop，支持广告系统和Web搜索的研究；Facebook借助集群运行Hadoop，支持其数据分析和机器学习；搜索引擎公司百度则使用Hadoop进行搜索日志分析和网页的数据挖掘工作；淘宝的Hadoop系统用于存储并处理电子商务交易的相关数据。

随着越来越多的传统企业开始关注大数据的价值，Hadoop也开始在传统企业的商业智能或数据分析系统中扮演重要角色。相比传统的基于数据库的商业智能解决方案，Hadoop拥有无以比拟的灵活性优势和成本优势。

Hadoop的经典用户有百度、新浪、奇虎、世纪佳缘网、搜狐、优酷、赶集网、爱奇艺视频网站等。

3.4.4 Spark

随着大数据的发展，人们对大数据的处理要求也越来越高，原有的批处理框架MapReduce适合离线计算，却无法满足实时性要求较高的业务，如实时推荐、用户行为分析等。因此，Hadoop生态系统又发展出以Spark为代表的新计算框架。相比MapReduce，Spark速度快，开发简单，并且能够同时兼顾批处理和实时数据分析。

Apache Spark是加州大学伯克利分校的AMPLabs开发的开源分布式轻量级通用计算框架，于2014年2月成为Apache的顶级项目。由于Spark基于内存设计，使得它拥有比Hadoop更高的性能，并且对多语言（Scala、Java、Python）提供支持。Spark有点类似Hadoop MapReduce框架。Spark拥有Hadoop MapReduce所具有的优点，但不同于MapReduce的是，Job中间输出的结果可以保存在内存中，从而不再需要读写HDFS（MapReduce的中间结果要放在文件系统上），因此，在性能上，Spark比MapReduce框架快100倍左右，排序100TB的数据只需要20分钟左右。正是因为Spark主要在内存中执行，所以Spark对内存的要求非常高，一个节点通常需要配置24GB的内存。在业界，我们有时把MapReduce称为批处理计算框架，把Spark称为实时计算框架、内存计算框架或流式计算框架。

Hadoop使用数据复制来实现容错性（I/O高），而Spark使用RDD（Resilient Distributed Datasets，弹性分布式数据集）数据存储模型来实现数据的容错性。RDD是只读的、分区记录的集合。如果一个RDD的一个分区丢失，RDD含有如何重建这个分区的相关信息。这就避免了使用数据复制来保证容错性的要求，从而减少了对磁盘的访问。通过RDD，后续步骤如果需要相同数据集，就不必重新计算或从磁盘加载，这个特性使得Spark非常适合流水线式的数据处理。

虽然Spark可以独立于Hadoop运行，但是Spark还是需要一个集群管理器和一个分布式存储系统。对于集群管理，Spark支持Hadoop YARN、Apache Mesos和Spark原生集群。对于分布式存储，Spark可以使用HDFS、Cassandra、OpenStack Swift和Amazon S3。Spark支持Java、Python和Scala（Scala是Spark最推荐的编程语言，Spark和Scala能够紧密集成，Scala程序可以在Spark控制台上执行）。应该说，Spark紧密集成Hadoop生态系统中的上述工具。Spark可以与Hadoop上的常用数据格式（如Avro和Parquet）进行交互，能读写HBase等NoSQL数据库，它的流处理组件Spark Streaming能连续从Flume和Kafka之类的系统上读取数据，它的SQL库Spark SQL能和Hive Metastore交互。

Spark可用来构建大型的、低延迟的数据分析应用程序。如图3-10所示，Spark包含的库有：Spark SQL、Spark Streaming、MLlib（用于机器学习）和GraphX。其中，Spark SQL和Spark Streaming最受欢迎，大概60%的用户在使用这两个库中的一个。而且Spark还能替代MapReduce成为Hive的底层执行引擎。

Spark的内存缓存使它适合进行迭代计算。机器学习算法需要多次遍历训练集，可以将训练集缓存在内存里。在对数据集进行探索时，数据科学家可以在运行查询的时候将数据集放在内存中，这样就节省了访问磁盘的开销。

虽然Spark目前被广泛认为是下一代Hadoop，但是Spark本身的复杂性也困扰着开发人员。Spark的批处理能力仍然比不过MapReduce，与Spark SQL和Hive的SQL功能相比还有一定的差距，Spark的统计功能与R语言相比还没有可比性。

3.4.5 Storm系统

Storm是Twitter支持开发的一款分布式的、开源的、实时的、主从式的大数据流式计算系统，使用的协议为Eclipse Public License 1.0，其核心部分使用高效流式计算的函数式语言Clojure编写，极大地提高了系统性能。但为了方便用户使用，支持用户使用任意编程语言进行项目的开发。

1. 任务拓扑

任务拓扑（Task Topology）是Storm的逻辑单元，一个实时应用的计算任务将被打包为任务拓扑后发布，任务拓扑一旦提交将会一直运行，除非显式地去中止。一个任务拓扑是由一系列Spout和Bolt构成的有向无环图，通过数据流（stream）实现Spout和Bolt之间的关联，如图3-11左图所示。其中，Spout负责从外部数据源不间断地读取数据，并以元组（Tuple）的形式发送给相应的Bolt。Bolt负责对接收到的数据流进行计算，实现过滤、聚合、查询等具体功能，可以级联，也可以向外发送数据流。

数据流是Storm对数据的抽象，它是时间上无穷的元组序列。如图3-11右图所示，数据流通过流分组（stream grouping）所提供的不同策略实现在任务拓扑中的流动。此外，为了确保消息能且仅能被计算1次，Storm还提供了事务任务拓扑。

2. 总体架构

如图3-12所示，Storm采用主从系统架构，在一个Storm系统中有两类节点（一个主节点Nimbus、多个从节点Supervisor）及3种运行环境（Master、Cluster和Slaves）。

（1）主节点Nimbus运行在Master环境中，是无状态的，负责全局的资源分配、任务调度、状态监控和故障检测。一方面，主节点Nimbus接收客户端提交来的任务，验证后分配任务到从节点Supervisor上，同时把该任务的元信息写入ZooKeeper目录中；另一方面，主节点Nimbus需要通过ZooKeeper实时监控任务的执行情况。当出现故障时进行故障检测，并重启失败的从节点Supervisor和工作进程Worker。

（2）从节点Supervisor运行在Slaves环境中，也是无状态的，负责监听并接受来自主节点Nimbus所分配的任务，并启动或停止自己所管理的工作进程Worker。其中，工作进程Worker负责具体任务的执行。一个完整的任务拓扑往往由分布在多个从节点Supervisor上的Worker进程来协调执行，每个Worker都执行且仅执行任务拓扑中的一个子集。在每个Worker内部会有多个Executor，每个Executor对应一个线程。Task负责具体数据的计算，即用户所实现的Spout/Blot实例。每个Executor会对应一个或多个Task，因此系统中Executor的数量总是小于等于Task的数量。

ZooKeeper是一个针对大型分布式系统的可靠协调服务和元数据存储系统。通过配置ZooKeeper集群，可以使用ZooKeeper系统所提供的高可靠性服务。Storm系统引入ZooKeeper，极大地简化了Nimbus、Supervisor、Worker之间的设计，保障了系统的稳定性。ZooKeeper在Storm系统中具体实现了以下功能：

① 存储客户端提交任务拓扑信息、任务分配信息、任务的执行状态信息等，便于主节点Nimbus监控任务的执行情况。

② 存储从节点Supervisor、工作进程Worker的状态和心跳信息，便于主节点Nimbus监控系统各节点的运行状态。

③ 存储整个集群的所有状态信息和配置信息，便于主节点Nimbus监控ZooKeeper集群的状态。在主ZooKeeper节点挂掉后，可以重新选取一个节点作为主ZooKeeper节点，并进行恢复。

3. 系统特征

Storm系统的主要特征如下。

（1）简单编程模型。用户只需编写Spout和Bolt部分的实现，因此极大地降低了实时大数据流式计算的复杂性。

（2）支持多种编程语言。默认支持Clojure、Java、Ruby和Python，也可以通过添加相关协议实现对新增语言的支持。

（3）作业级容错性。可以保证每个数据流作业被完全执行。

（4）水平可扩展。计算可以在多个线程、进程和服务器之间并发执行。

（5）快速消息计算。通过ZeroMQ作为其底层消息队列，保证消息能够得到快速的计算。

Storm系统存在的不足主要包括：资源分配没有考虑任务拓扑的结构特征，无法适应数据负载的动态变化；采用集中式的作业级容错机制，在一定程度上限制了系统的可扩展性。

3.4.6 Kafka系统

Kafka是Linkedin所支持的一款开源的、分布式的、高吞吐量的发布订阅消息系统，可以有效地处理互联网中活跃的流式数据，如网站的页面浏览量、用户访问频率、访问统计、好友动态等，开发语言是Scala，可以使用Java进行编写。Kafka系统在设计过程中主要考虑了以下需求特征。

（1）消息持久化是一种常态需求。

（2）吞吐量是系统需要满足的首要目标。

（3）消息的状态作为订阅者（consumer）存储信息的一部分，在订阅者服务器中进行存储。

（4）将发布者（producer）、代理（broker）和订阅者（consumer）显式地分布在多台机器上，构成显式的分布式系统。

形成了以下关键特性。

（1）在磁盘中实现消息持久化的时间复杂度为O(1)，数据规模可以达到太字节（TB）级别。

（2）实现了数据的高吞吐量，可以满足每秒数十万条消息的处理需求。

（3）实现了在服务器集群中进行消息的分片和序列管理。

（4）实现了对Hadoop系统的兼容，可以将数据并行地加载到Hadoop集群中。

1. 系统架构

Kafka消息系统的架构是由发布者、代理和订阅者共同构成的显式分布式架构，它们分别位于不同的节点上，如图3-13所示。各部分构成一个完整的逻辑组，并对外界提供服务，各部分间通过消息（message）进行数据传输。其中，发布者可以向一个主题（topic）推送相关消息，订阅者以组为单位可以关注并拉取自己感兴趣的消息，通过ZooKeeper实现对订阅者和代理的全局状态信息的管理及其负载均衡的实现。

2. 数据存储

Kafka消息系统通过仅进行数据追加的方式实现对磁盘数据的持久化保存，实现了对大数据的稳定存储，并有效地提高了系统的计算能力。通过采用Sendfile系统调用方式优化了网络传输，提高了系统的吞吐量。即使对于普通的硬件，Kafka消息系统也可以支持每秒数十万的消息处理能力。此外，在Kafka消息系统中，通过仅保存订阅者已经计算数据的偏量信息，一方面可以有效地节省数据的存储空间，另一方面也简化了系统的计算方式，方便系统的故障恢复。

3. 消息传输

Kafka消息系统采用推送、拉取相结合的方式进行消息的传输。其中，当发布者需要传输消息时，会主动地推送该消息到相关的代理节点；当订阅者需要访问数据时，其会从代理节点进行拉取。通常情况下，订阅者可以从代理节点中拉取自己感兴趣的主题消息。

4. 负载均衡

在Kafka消息系统中，发布者和代理节点之间没有负载均衡机制，但可以通过专用的第4层负载均衡器在Kafka代理上实现基于TCP连接的负载均衡的调整。订阅者和代理节点之间通过Zookeeper实现负载均衡机制，在Zookeeper中管理全部活动的订阅者和代理节点信息。当有订阅者和代理节点的状态发生变化时，才实时地进行系统的负载均衡的调整，保障整个系统处于一个良好的均衡状态。

5. 存在不足

Kafka系统存在的不足之处主要包括：只支持部分容错，节点失效转移时会丢失原节点内存中的状态信息；代理节点没有副本机制保护，一旦代理节点出现故障，该代理节点中的数据将不再可用；代理节点不保存订阅者的状态，删除消息时无法判断该消息是否已被阅读。

3.4.7 各类技术平台比较

一般而言，批量计算相关的大数据系统，如批量处理系统（如MapReduce）、大规模并行数据库等，在数据吞吐量方面具有明显优势，但在系统响应时间方面往往在秒级以上。而当前的流式计算相关的大数据系统，如流式处理系统、内存数据库、CEP（复杂事件处理）等，在系统响应时间方面虽然维持在毫秒级的水平，但数据吞吐量往往在吉字节（GB）级别，远远满足不了大数据流式计算系统对数据吞吐量的要求。通常情况下，一个理想的大数据流式计算系统在响应时间方面应维持在毫秒级的水平，并且数据吞吐量应该提高到拍字节（PB）级别及以上水平。

流式大数据作为大数据的一种重要形态，在商业智能、市场营销和公共服务等诸多领域有着广泛的应用前景，并已在金融银行业、互联网、物联网等场景的应用中取得了显著的成效。但流式大数据以其实时性、无序性、无限性、易失性、突发性等显著特征，使得传统的先存储后计算的批量数据计算理念不适用于大数据流式计算的环境中，也使得当前诸多数据计算系统无法更好地适应流式大数据在系统可伸缩性、容错、状态一致性、负载均衡、数据吞吐量等方面所带来的诸多新的技术挑战。

1. 可伸缩性

在大数据流式计算环境中，系统的可伸缩性是制约大数据流式计算系统广泛应用的一个重要因素。Storm和Kafka等系统没有实现对系统可伸缩性的良好支持：一方面，流式数据的产生速率在高峰时期会不断增加且数据量巨大，持续时间往往很长，因此需要大数据流式系统具有很好的“可伸”的特征，可以实时适应数据增长的需求，实现对系统资源进行动态调整和快速部署，并保证整个系统的稳定性；另一方面，当流式数据的产生速率持续减小时，需要及时回收在高峰时期所分配的但目前已处于闲置或低效利用的资源，实现整个系统“可缩”的友好特征，并保障对用户是透明的。因此，系统中资源动态的配置、高效的组织、合理的布局、科学的架构和有效的分配是保障整个系统可伸缩性的基础，同时又尽可能地减少不必要的资源和能源的浪费。

大数据流式计算环境中的可伸缩性问题的解决需要实现对系统架构的合理布局，系统资源的有序组织、高效管理和灵活调度。在保证系统完成计算的前提下，尽量不要太久、太多地占用系统资源，通过虚拟化机制实现软、硬件之间的低耦合，实现资源的在线迁移，并最终解决大数据流式计算环境中的可伸缩性问题。

2. 系统容错

在大数据流式计算环境中，系统容错机制是进一步改善整个系统的性能、提高计算结果的满意度、保证系统可靠持续运行的一个重要措施，也是当前大多数大数据流式计算系统所缺失的。Kafka等系统实现了对部分容错的支持，Storm系统实现了对作业级容错的支持。大数据流式计算环境对容错机制提出了新的挑战，一方面，数据流是实时、持续地到来的，呈现出时间上不可逆的特征，一旦数据流流过，再次重放数据流的成本是很大的，甚至是不现实的，由于数据流所呈现出的持续性和无限性，也无法预测未来流量的变化趋势；另一方面，在流式大数据的计算过程中，大部分“无用”的数据将被直接丢弃，能被永久保存下来的数据量是极少的。当需要进行系统容错时，其中不可避免地会出现一个时间段内数据不完整的情况。再则，需要针对不同类型的应用，从系统层面上设计符合其应用特征的数据容错级别和容错策略，避免不必要的资源浪费及应用需求的不吻合。

大数据流式计算环境中的容错策略的确定，需要根据具体的应用场景进行系统的设计和权衡，并且需要充分考虑到流式大数据的持续性、无限性、不可恢复性等关键特征。但是，没有任何数据丢失的容错策略也未必是最佳的，需要综合统筹容错级别和资源利用、维护代价等要素间的关系。但在对系统资源占用合理、对系统性能影响可接受的情况下，容错的精度越高必将越好。

3. 状态一致性

在大数据流式计算环境中，维持系统中各节点间状态的一致性对于系统的稳定高效运行、故障恢复都至关重要。然而，当前多数系统不能有效地支持系统状态的一致性，如Storm和Kafka等系统尚不支持维护系统状态的一致性。大数据流式计算环境对状态一致性提出了新的挑战：一方面，在系统实时性要求极高、数据速率动态变化的环境中，维护哪些数据的状态一致性，如何从高速、海量的数据流中识别这些数据是一个巨大的挑战；另一方面，在大规模分布式环境中，如何组织和管理实现系统状态一致性的相关数据，满足系统对数据的高效组织和精准管理的要求，也是一个巨大的挑战。

大数据流式计算环境中的状态一致性问题的解决需要从系统架构的设计层面上着手。存在全局唯一的中心节点的主从式架构方案无疑是实现系统状态一致性的最佳解决方案，但需要有效避免单点故障问题。通常情况下，在大数据流式计算环境中，程序和数据一旦启动后，将会常驻内容，对系统的资源占用也往往相对稳定。因此，单点故障问题在大数据流式计算环境中并没有批量计算环境中那么复杂。批量计算环境中的很多策略将具有很好的参考和借鉴价值。

4. 负载均衡

在大数据流式计算环境中，系统的负载均衡机制是制约系统稳定运行、高吞吐量计算、快速响应的一个关键因素。然而，当前多数系统不能有效地支持系统的负载均衡，如Storm系统不支持负载均衡机制，Kafka系统实现了对负载均衡机制的部分支持。一方面，在大数据流式计算环境中，系统的数据速率具有明显的突变性，并且持续时间往往无法有效预测，这就导致在传统环境中具有很好的理论和实践效果的负载均衡策略在大数据流式计算环境中将不再适用；另一方面，当前大多数开源的大数据流式计算系统在架构的设计上尚未充分地、全面地考虑整个系统的负载均衡问题。在实践应用中，相关经验的积累又相对缺乏，因此，给大数据流式计算环境中负载均衡问题的研究带来了诸多实践中的困难和挑战。

大数据流式计算环境中的负载均衡问题的解决需要结合具体的应用场景，系统地分析和总结隐藏在大数据流式计算中的数据流变化的基本特征和内在规律，结合传统系统负载均衡的经验，根据实践检验情况，不断进行相关机制的持续优化和逐步完善。

5. 数据吞吐量

在大数据流式计算环境中，数据吞吐量呈现出了根本性的增加。在传统的流式数据环境中，所处理的数据吞吐量往往在吉字节（GB）级别，这满足不了大数据流式计算环境对数据吞吐量的要求。在大数据流式计算环境中，数据的吞吐量往往在太字节（TB）级别以上，且其增长的趋势是显著的。然而，当前流式数据处理系统（如Storm）均无法满足太字节（TB）级别的应用需求。

大数据流式计算环境中的数据吞吐量问题的解决，一方面需要从硬件的角度进行系统的优化，设计出更符合大数据流式计算环境的硬件产品，在数据的计算能力上实现大幅提升；另一方面，更为重要的是，从系统架构的设计中进行优化和提升，设计出更加符合大数据流式计算特征的数据计算逻辑。