随着机构和企业积累的数据越来越多，大数据价值逐步体现出来。2015年国务院向社会公布了《促进大数据发展行动纲要》（以下简称《纲要》），正式将大数据提升为国家级战略。《纲要》明确提出了大数据的基本概念： 大数据是以容量大、类型多、存取速度快、应用价值高为主要特征的数据集合，正快速发展为对数量巨大、来源分散、格式多样的数据进行采集、存储和关联分析，从中发现新知识、创造新价值、提升新能力的新一代信息技术和服务业态 。《纲要》提到大数据在推动经济转型发展，重塑国家竞争优势，以及提升政府治理能力等方面具有重要的意义，提出在信用、交通、医疗、卫生、金融、气象等众多领域发展大数据。

为了确保大数据思想顺利落地，在各个行业开花结果，需要掌握和利用大数据技术。本书正是从技术角度探讨了如何利用开源技术构建大数据解决方案，从而真正为政府和企业带来实用价值。

1.1　大数据系统产生背景及应用场景

1.1.1　产生背景

大数据技术直接源于互联网行业。随着互联网的蓬勃发展，用户量和数据量越来越多，逐步形成了大数据，这成为大数据技术的基础。根据有关技术报告知道，国内百度、腾讯和阿里巴巴等公司数据规模如下：

• 2013年百度相关技术报告称，百度数据总量接近1000PB，网页的数量大是几千亿个，每年更新几十亿个，每天查询次数几十亿次。
• 2013年腾讯相关技术报告称，腾讯约有8亿用户，4亿移动用户，总存储数据量经压缩处理以后在100PB左右，日新增200TB到300TB，月增加10%的数据量。
• 2013年阿里巴巴相关技术报告称，总体数据量为100PB，每天的活跃数据量已经超过50TB，共有4亿条产品信息和2亿多名注册用户，每天访问超过4000万人次。

为了采集、存储和分析大数据，互联网公司尝试研发大数据技术，在众多技术方案中，开源系统Hadoop与Spark成为应用最广泛的大数据技术，由于它们的用户量巨大，已经初步成为大数据技术规范。

1.1.2　常见大数据应用场景

目前大数据技术被广泛应用在各个领域，它产生于互联网领域，并逐步推广到电信、医疗、金融、交通等领域，大数据技术在众多行业中产生了实用价值。

1. 互联网领域

在互联网领域，大数据被广泛应用在三大场景中，分别是搜索引擎、推荐系统和广告系统。

• 搜索引擎： 搜索引擎能够帮助人们在大数据集上快速检索信息，已经成为一个跟人们生活息息相关的工具。本书中涉及的很多开源大数据技术正是源于谷歌，谷歌在自己的搜索引擎中广泛使用了大数据存储和分析系统，这些系统被谷歌以论文的形式发表出来，进而被互联网界模仿。
• 推荐系统： 推荐系统能够在用户没有明确目的的时候根据用户历史行为信息帮助他们发现感兴趣的新内容，已经被广泛应用于电子商务（比如亚马逊、京东等）、电影视频网站（比如爱奇艺、腾讯视频等）、新闻推荐（比如今日头条等）等系统中。亚马逊科学家Greg Linden称，亚马逊20%（之后一篇博文称35%）的销售来自于推荐算法。Netflix在宣传资料中称，有60%的用户是通过推荐系统找到自己感兴趣的电影和视频的。
• 广告系统： 广告是互联网领域常见的盈利模式，也是一个典型的大数据应用。广告系统能够根据用户的历史行为信息及个人基本信息，为用户推荐最精准的广告。广告系统通常涉及广告库、日志库等数据，需采用大数据技术解决。

2. 电信领域

电信领域是继互联网领域之后，大数据应用的又一次成功尝试。电信运营商拥有多年的数据积累，拥有诸如用户基本信息、业务发展量等结构化数据，也会涉及文本、图片、音频等非结构化数据。从数据来源看，电信运营商的数据涉及移动语音、固定电话、固网接入和无线上网等业务，积累了公众客户、政企客户和家庭客户等相关信息，也能收集到电子渠道、直销渠道等所有类型渠道的接触信息，这些逐步积累下来的数据，最终形成大数据。目前电信领域主要将大数据应用在以下几个方面 ：

• 网络管理和优化，包括基础设施建设优化、网络运营管理和优化。
• 市场与精准营销，包括客户画像、关系链研究、精准营销、实时营销和个性化推荐。
• 客户关系管理，包括客服中心优化和客户生命周期管理。
• 企业运营管理，包括业务运营监控和经营分析。
• 数据商业化：数据对外商业化，单独盈利。

3. 医疗领域

医疗领域的数据量巨大，数据类型复杂。到2020年，医疗数据将增至35ZB，相当于2009年数据量的44倍。医疗数据包括影像数据、病历数据、检验检查结果、诊疗费用等在内的各种数据，合理利用这些数据可产生巨大的商业价值。大数据技术在医疗行业的应用将包含以下方向：临床数据对比、药品研发、临床决策支持、实时统计分析、基本药物临床应用分析、远程病人数据分析、人口统计学分析、新农合基金数据分析、就诊行为分析、新的服务模式等 。

4. 金融领域

银行拥有多年的数据积累，已经开始尝试通过大数据来驱动业务运营。银行大数据应用可以分为四大方面 ：

• 客户画像应用： 客户画像应用主要分为个人客户画像和企业客户画像。个人客户画像包括人口统计学特征、消费能力、兴趣、风险偏好等；企业客户画像包括企业的生产、流通、运营、财务、销售、客户、相关产业链上下游等数据。
• 精准营销： 在客户画像的基础上银行可以有效地开展精准营销，银行可以根据客户的喜好进行服务或者银行产品的个性化推荐，如根据客户的年龄、资产规模、理财偏好等，对客户群进行精准定位，分析出其潜在的金融服务需求，进而有针对性地进行营销推广。
• 风险管控： 包括中小企业贷款风险评估和欺诈交易识别等手段，银行可以利用持卡人基本信息、卡基本信息、交易历史、客户历史行为模式、正在发生的行为模式（如转账）等，结合智能规则引擎（如从一个不经常出现的国家为一个特有用户转账或从一个不熟悉的位置进行在线交易）进行实时的交易反欺诈分析。
• 运营优化： 包括市场和渠道分析优化、产品和服务优化等，通过大数据，银行可以监控不同市场推广渠道尤其是网络渠道推广的质量，从而进行合作渠道的调整和优化；银行可以将客户行为转化为信息流，并从中分析客户的个性特征和风险偏好，更深层次地理解客户的习惯，智能化分析和预测客户需求，从而进行产品创新和服务优化。

1.2　企业级大数据技术框架

大数据尝试从海量数据中，通过一定的分布式技术手段，挖掘出有价值的信息，最终提供给用户，进而产生实用价值和商业价值。由于数据本身的多样性以及数据分析需求的多元化，大数据技术体系非常复杂，涉及的组件和模块众多，为了便于读者从顶层框架上对大数据有一个清楚的认识，本节尝试概括大数据技术框架。

在互联网领域，数据无处不在。以电子商务应用为例，如图1-1所示，当用户通过浏览器在淘宝上查看或购买商品时，会向淘宝后端HTTP服务器发送HTTP请求，这些HTTP服务器收到请求后，会将相应的内容返回给用户，同时以日志的形式将用户访问记录传大数据系统，以便能够通过大数据技术理解用户的行为意图，进而为广告投放、商品推荐等提供数据支持。本节将尝试剖析其间用到的基本的大数据技术。

从数据在信息系统中的生命周期看，大数据从数据源开始，经过分析、挖掘到最终获得价值一般需要经过6个主要环节 ，包括数据收集、数据存储、资源管理与服务协调、计算引擎、数据分析和数据可视化，技术体系如图1-2所示。每个环节都面临不同程度的技术挑战。

1.2.1　数据收集层

数据收集层由直接跟数据源对接的模块构成，负责将数据源中的数据近实时或实时收集到一起。数据源具有分布式、异构性、多样化及流式产生等特点：

• 分布式： 数据源通常分布在不同机器或设备上，并通过网络连接在一起。
• 异构性： 任何能够产生数据的系统均可以称为数据源，比如Web服务器、数据库、传感器、手环、视频摄像头等。
• 多样化： 数据的格式是多种多种多样的，既有像用户基本信息这样的关系型数据，也有如图片、音频和视频等非关系型数据。
• 流式产生： 数据源如同“水龙头”一样，会源源不断地产生“流水”（数据），而数据收集系统应实时或近实时地将数据发送到后端，以便及时对数据进行分析。

由于数据源具有以上特点，将分散的数据源中的数据收集到一起通常是一件十分困难的事情。一个适用于大数据领域的收集系统，一般具备以下几个特点：

• 扩展性： 能够灵活适配不同的数据源，并能接入大量数据源而不会产生系统瓶颈；
• 可靠性： 数据在传输过程中不能够丢失（有些应用可容忍少量数据丢失）。
• 安全性： 对于一些敏感数据，应有机制保证数据收集过程中不会产生安全隐患。
• 低延迟： 数据源产生的数据量往往非常庞大，收集系统应该能够在较低延迟的前提下将数据传输到后端存储系统中。

为了让后端获取全面的数据，以便进行关联分析和挖掘，通常我们建议将数据收集到一个中央化的存储系统中。

1.2.2　数据存储层

数据存储层主要负责海量结构化与非结构化数据的存储。传统的关系型数据库（比如MySQL）和文件系统（比如Linux文件系统）因在存储容量、扩展性及容错性等方面的限制，很难适应大数据应用场景。

在大数据时代，由于数据收集系统会将各类数据源源不断地发到中央化存储系统中，这对数据存储层的扩展性、容错性及存储模型等有较高要求，总结如下：

• 扩展性： 在实际应用中，数据量会不断增加，现有集群的存储能力很快将达到上限，此时需要增加新的机器扩充存储能力，这要求存储系统本身具备非常好的线性扩展能力。
• 容错性： 考虑到成本等因素，大数据系统从最初就假设构建在廉价机器上，这就要求系统本身就有良好的容错机制确保在机器出现故障时不会导致数据丢失。
• 存储模型： 由于数据具有多样性，数据存储层应支持多种数据模型，确保结构化和非结构化的数据能够很容易保存下来。

1.2.3　资源管理与服务协调层

随着互联网的高速发展，各类新型应用和服务不断出现。在一个公司内部，既存在运行时间较短的批处理作业，也存在运行时间很长的服务，为了防止不同应用之间相互干扰，传统做法是将每类应用单独部署到独立的服务器上。该方案简单易操作，但存在资源利用率低、运维成本高和数据共享困难等问题。为了解决这些问题，公司开始尝试将所有这些应用部署到一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用轻量级隔离方案对各个应用进行隔离，因此便诞生了轻量级弹性资源管理平台，相比于“一种应用一个集群”的模式，引入资源统一管理层可以带来众多好处：

• 资源利用率高 ： 如图1-3所示，如果每个应用一个集群，则往往由于应用程序数量和资源需求的不均衡，使得在某段时间内有些应用的集群资源紧张，而另外一些集群资源空闲。共享集群模式通过多种应用共享资源，使得集群中的资源得到充分利用。
• 运维成本低： 如果采用“一个应用一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本。而共享模式通常需要少数管理员即可完成多个框架的统一管理。
• 数据共享： 随着数据量的暴增，跨集群间的数据移动不仅需花费更长的时间，且硬件成本也会大大增加，而共享集群模式可让多种应用共享数据和硬件资源，这将大大减小数据移动带来的成本。

在构建分布式大数据系统时，会面临很多共同的问题，包括leader选举、服务命名、分布式队列、分布式锁、发布订阅功能等，为了避免重复开发这些功能，通常会构建一个统一的服务协调组件，包含了开发分布式系统过程中通用的功能。

1.2.4　计算引擎层

在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的，有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引；有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告系统及信用卡欺诈检测。为了解决不同场景下数据处理问题，起初有人尝试构建一个大统一的系统解决所有类型的数据计算问题，但最终以失败告终。究其原因，主要是因为不同类型的计算任务，其追求的目标是不同的，批处理计算追求的是高吞吐率，而实时计算追求的是低延迟。在现实系统中，系统吞吐率和处理延迟往往是矛盾的两个优化方向：系统吞吐率非常高时，数据处理延迟往往也非常高，基于此，用一个系统完美解决所有类型的计算任务是不现实的。

计算引擎发展到今天，已经朝着“小而美”的方向前进，即针对不同应用场景，单独构建一个计算引擎，每种计算引擎只专注于解决某一类问题，进而形成了多样化的计算引擎。计算引擎层是大数据技术中最活跃的一层，直到今天，仍不断有新的计算引擎被提出。如图1-4所示，总体上讲，可按照对时间性能的要求，将计算引擎分为三类：

• 批处理： 该类计算引擎对时间要求最低，一般处理时间为分钟到小时级别，甚至天级别，它追求的是高吞吐率，即单位时间内处理的数据量尽可能大，典型的应用有搜索引擎构建索引、批量数据分析等。
• 交互式处理： 该类计算引擎对时间要求比较高，一般要求处理时间为秒级别，这类系统需要跟人进行交互，因此会提供类SQL的语言便于用户使用，典型的应用有数据查询、参数化报表生成等。
• 实时处理： 该类计算引擎对时间要求最高，一般处理延迟在秒级以内，典型的应用有广告系统、舆情监测等。

1.2.5　数据分析层

数据分析层直接跟用户应用程序对接，为其提供易用的数据处理工具。为了让用户分析数据更加容易，计算引擎会提供多样化的工具，包括应用程序API、类SQL查询语言、数据挖掘SDK等。

在解决实际问题时，数据科学家往往需根据应用的特点，从数据分析层选择合适的工具，大部分情况下，可能会结合使用多种工具，典型的使用模式是：首先使用批处理框架对原始海量数据进行分析，产生较小规模的数据集，在此基础上，再使用交互式处理工具对该数据集进行快速查询，获取最终结果。

1.2.6　数据可视化层

数据可视化技术指的是运用计算机图形学和图像处理技术，将数据转换为图形或图像在屏幕上显示出来，并进行交互处理的理论、方法和技术。它涉及计算机图形学、图像处理、计算机辅助设计、计算机视觉及人机交互技术等多个领域。

数据可视化层是直接面向用户展示结果的一层，由于该层直接对接用户，是展示大数据价值的“门户”，因此数据可视化是极具意义的。考虑到大数据具有容量大、结构复杂和维度多等特点，对大数据进行可视化是极具挑战性的。下面我们举例说明发展可视技术的意义及挑战。

在医学领域，为了认识人体内部结构，美国国家医学图书馆于1989年开始实施可视化人体计划（VHP），并委托科罗拉多大学医学院建立了一男一女的全部解剖结构数据库。他们分别将男女不同性别的两具尸体从头到脚做CT扫描和核磁共振扫描（男的间距1毫米，共1878个断面；女的间距0.33毫米，共5189个断面），然后将尸体填充蓝色乳胶并裹以明胶后冰冻至零下80摄氏度，再以同样的间距对尸体作组织切片的数码相机摄影，分辨率为2048×1216，最终所得数据共56GB（男13GB，女43GB）。全球用户可以在美国国家医学图书馆允许的情况下获得该数据并用于教学和科学研究。VHP数据集的出现标志着计算机三维重构图像和虚拟现实技术进入了医学领域，从而大大促进了医学的发展和普及。

1.3　企业级大数据技术实现方案

真正意义上的大数据技术源于互联网行业，尤其是大数据技术引领者谷歌公司，由于其数据量大，解决的问题都是前沿的，对大数据技术的发展起到了重要的作用。本节将首先解析谷歌公司的大数据架构，之后介绍开源大数据实现方案。

1.3.1　Google大数据技术栈

Google在大数据方面的技术，均是以发表论文的形式对外公开的，尽管其没有对外开源系统实现代码，但这些论文直接带动了大数据技术的发展，尤其为大数据开源技术的发展指明了方向。Google公开发表的大数据系统方面的论文目前绝大部分都存在对应的开源系统实现。总结近10年Google发表的论文，涉及的大数据系统如图1-5所示，主要分布在数据存储层、资源管理与服务协调层、计算引擎层、数据分析层这四层中。

1. 数据存储层

• GFS[GGL03]： Google文件系统（Google File System）是一个分布式文件系统，具有良好的容错性、扩展性和可用性，尤其是容错性表现突出，这使得GFS可构建在大量普通廉价机器上，进而容易进行“Scale out”（横向扩展），相比于传统的“Scale up”（向上扩展）方案中采用的大型机或小型机等，大大降低了成本。
• BigTable[CDG+06]： 构建在GFS之上的分布式数据库本质上是一个稀疏的、分布式的、持久化存储的多维度排序映射表。BigTable支持插入和更新等操作，且行数和列数可以无限扩展，这在很大程度上弥补了传统关系型数据库在schema上的不灵活。
• MegaStore[BBC+11]： MegaStore是构建在BigTable之上，支持ACID特性的分布式数据库。它是一个具有高扩展性并可进行高密度交互的可用存储服务，其在Google的基础系统之中，起初主要解决App Engine的数据存储问题。MegaStore能够在广域网中同步复制文件写操作，在可接受的延时下，支持跨数据中心的故障迁移。
• Spanner[CDE+13]： Spanner是一个可扩展的、多版本、全球分布式、支持同步复制的数据库。它是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。Google官方认为，Spanner是下一代BigTable，也是MegaStore的继任者。

2. 资源管理与服务协调层

• Borg[VPK+15]： 一个集群资源管理和调度系统，它负责集群的资源管理和统一调度，并对应用程序进行接收、启动、停止、重启和监控。Borg的目的是让开发者能够不必操心资源管理的问题，让他们专注于应用程序开发相关的工作，并且做到跨多个数据中心的资源利用率最大化。
• Omega[SKA+13]： Google下一代集群资源管理和调度系统，采用了共享状态的架构，这使得应用程序调度器拥有整个集群的权限，可以自由获取资源，同时采用了基于多版本的并发访问控制方式（又称乐观锁，全称为MVCC，即Multi-Version Concurrency Control），解决潜在的资源冲突访问问题。
• Chubby[Bur06]： 该系统旨在为松散耦合的分布式系统提供粗粒度的锁以及可靠存储（低容量的），它提供了一个非常类似于分布式文件系统的接口，能够很容易的实现leader选举、分布式锁、服务命名等分布式问题，它设计的侧重点在可用性及可靠性而不是高性能。

3. 计算引擎层

• MapReduce[DG08]： MapReduce是一个批处理计算框架，它采用“分而治之”的思想，将对大规模数据集的操作，分解成Map和Reduce两个阶段，Map阶段并行处理输入数据集，产生中间结果，Reduce阶段则通过整合各个节点的中间结果，得到最终结果。简单地说，MapReduce就是“任务的分解与结果的汇总”。MapReduce具有高吞吐率、良好的容错性、扩展性以及易于编程等特点，被广泛应用于构建索引、数据挖掘、机器学习等应用中。
• Dremel[MGL+10]： Dremel是一个分布式OLAP（OnLine Analytical Processing）系统，通过引入列式存储、树状架构等技术，能够帮助数据分析师在秒级处理PB级数据。Dremel在一定程度上弥补了类MapReduce系统在交互式查询方面的不足。
• Pregel[MAB+10]： Pregel是一个分布式图计算框架，专门用来解决网页链接分析、社交数据挖掘等实际应用中涉及的大规模分布式图计算问题，Pregel采用了BSP（Bulk Synchronous Parallel Computing Model）模型 ，即“计算→通信→同步”模型，通过消息传递的方式，实现高效的迭代计算。
• Precolator[PD10]： Percolator是一个基于BigTable构建的大数据集增量更新系统。其目标是在海量的数据集上提供增量更新的能力，并通过支持分布式事务来确保增量处理过程的数据一致性和整体系统的可扩展性。Percolator最初是为了解决网页库增量更新而提出了的，用以弥补MapReduce无法逐个处理小规模更新的缺陷。
• MillWheel[ABB+13]： MillWheel是一个分布式流式实时处理框架，它允许用户自定义一些处理单元，并按照一定的拓扑结构连接在一起形成一个有向图，从而形成一个流式处理数据线。MillWheel具有低延迟、自动处理乱序、数据严格一次投递（exactly-once delivery）等优点，在Google被广泛应用于构建低延迟数据处理应用。

4. 数据分析层

• FlumeJava[CRP+10]： FlumeJava是一个建立在MapReduce之上的Java编程库，提供了一层高级原语以简化复杂的MapReduce应用程序开发，非常适合构建复杂的数据流水线。FlumeJava内置优化器，会自动优化应用程序的执行计划，并基于底层的原语来执行优化后的操作。
• Tenzing[CLL+11]： 建立在MapReduce之上的SQL查询执行引擎，它可以将用户编写的SQL语句转化为MapReduce程序，并提交到集群中分布式并行执行。

1.3.2　Hadoop与Spark开源大数据技术栈

随着大数据开源技术的快速发展，目前开源社区已经积累了比较完整的大数据技术栈，应用最广泛的是以Hadoop与Spark为核心的生态系统，具体如图1-6所示，整个大数据技术栈涉及数据收集、数据存储、资源管理与服务协调、计算引擎和数据分析这五个层级。

1. 数据收集层：

• 主要由关系型与非关系型数据收集组件，分布式消息队列构成。
• Sqoop /Canal ：关系型数据收集和导入工具，是连接关系型数据库（比如MySQL）和Hadoop（比如HDFS）的桥梁，Sqoop可将关系型数据库中的数据全量导入Hadoop，反之亦可，而Canal则可用于实现数据的增量导入。
• Flume ：非关系型数据收集工具，主要是流式日志数据，可近实时收集，经过滤，聚集后加载到HDFS等存储系统。
• Kafka ：分布式消息队列，一般作为数据总线使用，它允许多个数据消费者订阅并获取感兴趣的数据。相比于其他消息队列，它采用分布式高容错设计，更适合大数据应用场景。

2. 数据存储层

• 主要由分布式文件系统（面向文件的存储）和分布式数据库（面向行/列的存储）构成。
• HDFS ：Hadoop分布式文件系统，Google GFS的开源实现，具有良好的扩展性与容错性等优点，尤其是出色的容错机制设计，使得它非常适合构建在廉价机器上，这大大降低了大数据存储成本。目前开源社区已经开发了各种类型的数据存储格式，包括SSTable（Sorted String Table） ，文本文件、二进制key/value格式Sequence File、列式存储格式Parquet 、ORC 和Carbondata 等。
• HBase ：构建在HDFS之上的分布式数据库，Google BigTable的开源实现，允许用户存储结构化与半结构化的数据，支持行列无限扩展以及数据随机查找与删除。
• Kudu ：分布式列式存储数据库，允许用户存储结构化数据，支持行无限扩展以及数据随机查找与更新。

3. 资源管理与服务协调

• YARN ：统一资源管理与调度系统，它能够管理集群中的各种资源（比如CPU和内存等），并按照一定的策略分配给上层的各类应用。YARN内置了多种多租户资源调度器，允许用户按照队列的方式组织和管理资源，且每个队列的调度机制可独立定制。
• ZooKeeper ：基于简化的Paxos协议实现的服务协调系统，它提供了类似于文件系统的数据模型，允许用户通过简单的API实现leader选举、服务命名、分布式队列与分布式锁等复杂的分布式通用模块。

4. 计算引擎层

• 包含批处理，交互式处理和流式实时处理三种引擎。
• MapReduce/Tez ：MapReduce是一个经典的批处理计算引擎，它是Google MapReduce的开源实现，具有良好的扩展性与容错性，允许用户通过简单的API编写分布式程序；Tez是基于MapReduce开发的通用DAG（Directed Acyclic Graph的简称，有向无环图）计算引擎，能够更加高效地实现复杂的数据处理逻辑，目前被应用在Hive、Pig等数据分析系统中。
• Spark ：通用的DAG计算引擎，它提供了基于RDD（Resilient Distributed Dataset）的数据抽象表示，允许用户充分利用内存进行快速的数据挖掘和分析。
• Impala /Presto ：分别由Cloudera和Facebook开源的MPP（MassivelyParallel Processing）系统，允许用户使用标准SQL处理存储在Hadoop中的数据。它们采用了并行数据库架构，内置了查询优化器，查询下推，代码生成等优化机制，使得大数据处理效率大大提高。
• Storm /Spark Streaming：分布式流式实时计算引擎，具有良好的容错性与扩展性，能够高效地处理流式数据，它允许用户通过简单的API完成实时应用程序的开发工作。

5. 数据分析层

• 为方便用户解决大数据问题而提供的各种数据分析工具。
• Hive /Pig /SparkSQL：在计算引擎之上构建的支持SQL或脚本语言的分析系统，大大降低了用户进行大数据分析的门槛。其中，Hive是基于MapReduce/Tez实现的SQL引擎，Pig是基于MapReduce/Tez实现的工作流引擎，SparkSQL是基于Spark实现的SQL引擎。
• Mahout /MLlib：在计算引擎之上构建的机器学习库实现了常用的机器学习和数据挖掘算法。其中，Mahout最初是基于MapReduce实现的，目前正逐步迁移到Spark引擎上，MLlib是基于Spark实现的。
• Apache Beam /Cascading ：基于各类计算框架而封装的高级API，方便用户构建复杂的数据流水线。Apache Beam统一了批处理和流式处理两类计算框架，提供了更高级的API方便用户编写与具体计算引擎无关的逻辑代码；Cascading内置了查询计划优化器，能够自动优化用户实现的数据流。采用了面向tuple的数据模型，如果你的数据可表示成类似于数据库行的格式，则使用Cascading处理将变得很容易。

1.4　大数据架构：Lambda Architecture

Lambda Architecture（LA）最早是Twitter工程师Nathan Marz提出来的，它是一种大数据软件设计架构，其目的是指导用户充分利用批处理和流式计算技术各自的优点实现一个复杂的大数据处理系统。通过结合这两类计算技术，LA可以在延迟、吞吐量和容错之间找到平衡点。如图1-7所示，LA主要思想是将数据处理流程分解成三层：批处理层、流式处理层和服务层。

• 批处理层 。它的主要思想是利用分布式批处理计算，以批为单位处理数据，并产生一个经预计算产生的只读数据视图。该层将数据流看成只读的、仅支持追加操作的超大数据集。它可以一次性处理大量数据，引入复杂的计算逻辑（比如机器学习中的模型迭代计算，历史库的匹配等），其优点是吞吐率高，缺点是数据处理延迟高，即从数据产生到最终被处理完成，整个过程用时较长，通常是分钟或小时级别。
• 流式处理层 。为了降低批处理层带来的高延迟，LA又引入了流式处理层，该层采用流式计算技术，大大降低了数据处理延迟（通常是毫秒或秒级别），其优点是数据处理延迟低，缺点是无法进行复杂的逻辑计算，得到的结果往往是近似解。
• 服务层 。批处理层和流式处理层可以结合在一起，这样既保证数据延迟低，也能完成复杂的逻辑计算（只能保证最终一致性）。为了整合两层的计算结果，LA进一步引入服务层，它对外提供了统一的访问接口以方便用户使用。

一个经典的LA应用案例是推荐系统。在互联网行业，推荐系统被应用在各个领域，包括电子商务、视频、新闻等。推荐系统的设计目的是根据用户的兴趣特点和购买行为，向用户推荐感兴趣的信息和商品。推荐系统是建立在海量数据挖掘基础上的一种高级商务智能平台，以帮助商家为其顾客购物提供完全个性化的决策支持和信息服务。推荐系统最核心的模块是推荐算法，推荐算法通常会根据用户的兴趣特点和历史行为数据构建推荐模型，以预测用户可能感兴趣的信息和商品，进而推荐给用户。

图1-8所示为一个典型的推荐系统数据流水线架构。在该架构中，数据统一流入Kafka，之后按照不同时间粒度导入批处理和流式处理两个系统中。批处理层拥有所有历史数据（通常保存到HDFS/HBase中），通常用以实现推荐模型，它以当前数据（比如最近一小时数据）和历史数据为输入，通过特征工程、模型构建（通常是迭代算法，使用MapReduce/Spark实现）及模型评估等计算环节后，最终获得最优的模型并将产生的推荐结果存储（比如Redis）起来，整个过程延迟较大（分钟甚至小时级别）；为了解决推荐系统中的冷启动问题（新用户推荐问题），往往会引入流式处理层：它会实时收集用户的行为，并基于这些行为数据通过简单的推荐算法（通常使用Storm/Spark Streaming实现）快速产生推荐结果并存储起来。为了便于其他系统获取推荐结果，推荐系统往往通过服务层对外提供访问接口，比如网站后台在渲染某个访问页面时，可能从广告系统、推荐系统以及内容存储系统中获取对应的结果，并返回给客户端。

1.5　Hadoop与Spark版本选择及安装部署

1.5.1　Hadoop与Spark版本选择

随着社区迅猛发展以及各大互联网公司投入的增加，Hadoop与Spark已经成为大数据技术标准，这吸引了大量商业公司基于开源Hadoop与Spark版本实现自己的发行版，目前比较知名的Hadoop发行版有：

• Apache Hadoop：社区原始版本，由Apache基金会维护，是其他商业公司发行版的基础。
• CDH（Cloudera Distributed Hadoop）：Cloudera公司 发行版，其社区版所有源代码均开源，但企业版则闭源且收费，是使用最广泛的发行版之一，本书实验部分便是基于CDH版本的。
• HDP（Hortonworks Data Platform）：Hortonworks公司 发行版，其社区版所有源代码也开源，但企业版则闭源收费。
• 比较知名的Spark发行版有：
• Apache Spark：社区原生版本，由Apache基金会维护，是其他商业公司发行版的基础。
• Databricks Spark：Databricks公司 发行版，其社区版所有源代码均开源，内置企业版本，增加安全、审计、云等方面的支持。
• Hadoop企业发行版：各大Hadoop企业发行版，比如HDP和CDH，均内置了对Spark的支持。

各个发行版之间同一系统对外使用方式和接口是完全兼容的，不同之处在于它们引入了不同系统解决某个场景的问题，比如CDH选择Impala解决交互式分析问题，而HDP选择Hive On Tez；CDH引入了Cloudera Navigator和Sentry解决安全问题，而HDP则使用Ranger和Knox，另外，它们均提供了个性化的运维与管理工具等。在线上环境部署私有Hadoop与Spark集群时，为了避免各个系统之间兼容性（比如HBase不同版本与Hadoop版本之间的兼容性）带来的麻烦，建议大家直接选用商业公司发行版。

1.5.2　Hadoop与Spark安装部署

目前Hadoop与Spark存在两种安装部署方式：人工部署和自动化部署。其中人工部署用于个人学习、测试或者小规模生产集群，而自动化部署则适用于线上中大规模部署。为了让读者亲自动手学习Hadoop与Spark，本书主要介绍人工部署方式。读者可参考本书最后的附录，学习Hadoop生态系统中各个组件的安装部署方法。对于自动化部署方式，我们有两种选择：自己构建自动化部署系统及使用商业公司实现方案，比如Ambari 和Cloudera Manager 。

1.6　小结

本章首先以数据生命周期为线索，提出了六层大数据技术体系，包括数据收集、数据存储、资源管理与服务协调、计算引擎、数据分析和数据可视化，接着介绍了大数据技术体系的两个经典视线：Google大数据技术栈和Hadoop与Spark生态系统，以及大数据架构，最后介绍了Hodoop与Spark的版本选择及安装部署。

1.7　本章问题

问题1： 比较Google大数据技术栈和Hadoop/Spark开源大数据技术栈，并将它们所有对应的相似系统找出来。

问题2： 在Lambda Architecture中批处理数据线的意义何在，能否只保留实时数据线？ AS4vnewBtG0jMq7hNJjk6yqngjcYrF6rIHCzRnoc2Ky6quWmh+BGr30nMk6MvgLC