第1章 为Hive打好基础:Hadoop 

到现在为止,任何有一丝好奇心的技术人员都听说过Hadoop,这是在办公室闲聊时被反复提及的一个词。对于Hadoop的看法不一,从“Hadoop就是浪费时间”到“它很了不起,将解决我们当前的所有问题”。你可能也听说过你们公司的董事、经理甚至首席信息官让团队开始实现这种新生的大数据事物,并且找到一个要用它来解决的问题。在谈到大数据时,非技术人士的第一反应通常是:“噢,你是说像NSA 那样吗?”毫无疑问,大数据带来了重大责任,但是显然,如果对大数据的使用及其好处缺乏认识,将会滋生不必要的恐惧、不确定和怀疑。

实际上,你在看这本书就说明你对Hadoop感兴趣。你可能已经知道Hadoop能让你存储和处理大量数据。我们猜测,你也认识到了Hive是一款强大的工具,允许你使用SQL来实现熟悉的数据访问操作。从书名可知,这本书是关于Hive的,它会告诉你Hive在访问大型数据存储时是多么重要。牢记这一点有助于理解我们为何撰写本书。我们已经有了像T-SQL和PL/SQL这样的工具,以及其他能够检索数据的分析工具,为什么还需要Hive呢?在现有环境中增加更多需要掌握新技能的工具,难道没有额外的资源成本吗?事实上,我们认为可用的数据是不断变化的,而且变化得很快。这种快速的变化迫使我们扩展自己的工具集,不能局限于过去30年所依赖的工具。我们将在后面的章节中看到,我们确实需要改变,但是也需要利用那些早已获得的成就和技能。

① 美国国家安全局。——译者注

Hadoop与“大数据”这个术语几乎同义。在我们看来,“大数据”正在慢慢地走向其他术语(例如决策支持系统和电子商务)的命运。当人们将“大数据”作为一种解决方案来谈论时,他们通常是从市场营销的视角来看问题的,而不是从一种工具或者能力的视角。我记得与一位高层管理人员会面时,他坚决要求我们不要在讨论中使用“大数据”这个术语。我同意了,因为我觉得这个术语会冲淡谈话的主题,使我们更关注于通用术语而没有触及技术的变革本质。但是话又说回来,数据确实在变大,而我们不得不从某个地方开始讨论这个话题。

我的观点是:Hadoop最初是一种用于解决特定问题的技术。它在不断演化,而且演化的速度比罐子里果蝇的繁殖速度还快。它已经演变成一种核心技术,正在改变企业看待其数据的方式——如何使用数据,如何深入理解所有数据——以解决特定业务需求并获得竞争优势。用于处理数据的现有模型和方法论正不断受到挑战。随着不断演进并且越来越被认可,Hadoop从一种小众的解决方案转变为每个企业都能从中获取价值的解决方案。再从另外的角度想想。现在的日常技术都是基于专门的需求创造出来的,例如军事需求。我们认为理所当然的东西,比如胶带和GPS,都是首先针对特定军事需求而开发的。为什么会这样?创新至少需要3个要素:一种迫在眉睫的需求,一个可以识别的问题,还有金钱。军队是庞大而复杂的组织,拥有人才、金钱、资源以及发明这些日常用品的需求。显然,军队为自己使用而发明的产品和零售商店里的产品往往不太一样。后者经过改良、推广和精心打磨,以供日常使用。随着我们深入了解Hadoop,要注意与此相同的过程:那些独特且紧紧聚焦于某一需求的发明将不断演进,以满足更广泛的企业需求。

如果要将Hadoop和大数据比作什么,可以将它们视为一段旅程。很少有公司在创立之初就需要含有1000个节点的集群,也不会轻易决定在这样的平台上运行关键业务。企业会经历一段可预测的旅程,时间从几个月到几年不等。希望本书能够帮助你开始自己的旅程,并且有助于阐明整个旅程的具体步骤。第1章介绍了Hadoop世界为什么与众不同,以及它的由来。本章为稍后的讨论奠定了基础。在学习具体的技术之前,你将了解Hadoop平台,也将明白开源模型为何如此不同且具有颠覆性。

1.1 一只小象出生了

2003年,Google公司发表了一篇并不引人注目的论文,题目为“The Google File System”。在硅谷之外并没有多少人关注这篇论文的发表和它试图传达的信息。这篇论文所包含的信息可直接用于像Google这样的公司,其主要业务聚焦于对互联网进行索引,而对于大多数公司来说,这并不是一个常见的用例。这篇论文描述了一种独特的存储框架,是为解决Google公司今后的技术需求而设计的。本着TL&DR的精神,这里给出其最突出的观点:

 故障是常态

 文件很大

 文件通过追加来更改,而不是通过更新来更改

 紧耦合的应用程序和文件系统API

如果你打算成就一家规模达数十亿美元的互联网搜索公司,上述假设大多都有意义。你将主要关心大文件的处理,以及以低延迟的代价连续进行长时间的读写操作。你也会想把自己的海量存储需求分散到(廉价的)商用硬件上,这样就不需要建立代价高昂的资源竖塔。数据摄入需要格外关注,在写入时对这些数据结构化(模式化)只会延迟处理过程。你还需要安排一个由世界顶级开发人员组成的团队,构建可伸缩、分布式且高可用的解决方案。

Yahoo注意到了这篇论文。他们在互联网搜索领域面临着类似的伸缩性问题,并且使用了由Doug Cutting和Mike Cafarella创建的一个名为Nutch的应用程序。Google的那篇论文为Doug和Mike提供了一个框架,可解决Nutch架构中很多固有的问题,其中最重要的是可伸缩性和可靠性。而接下来需要进行的就是对基于Google的论文设计的解决方案重新进行工程实现。

① 互联网用语,意思是“篇幅太长,不再阅读”。——译者注

注意 请记住,最初的GFS(Google文件系统)和发展成为Hadoop的这部分技术并不相同。GFS是一个框架,而Hadoop则是将该框架付诸实施。GFS仍然是Google专有的,也就是说,它并不是开源的。


当我们提起Hadoop时,经常会想到Google公司的那篇论文中有关存储器的那一部分概述。实际上,这个等式的另一半(更为重要)是Google公司在2004年发表的题为“MapReduce: Simplified Data Processing on Large Clusters”的论文。这篇论文采用一种被称作“易并行”(embarrassingly parallel)的方法,将大型分布式集群上的数据存储与该数据的处理相结合。


注意 对MapReduce的讨论将贯穿全书。MapReduce在交互式SQL查询处理中既是一个意义重大的角色,也是一个日益走向衰落的角色。


Doug Cutting和Yahoo的其他一些人看到了GFS和MapReduce对Yahoo自身用例的价值,因此从Nutch剥离出一个单独的项目。Doug用他儿子的玩具小象的名字Hadoop来命名这个项目。尽管这个名字很可爱,但是项目本身还是很严肃的,而且Yahoo打算推广它,用它来满足搜索引擎以及广告业务方面的需求。


注意 Hadoop社区流传着一个笑话:如果你将产品命名权交给工程部门而不是市场营销部门,那么就会得到类似于Hadoop、Pig、Hive、Storm、Zookeeper和Kafka这样的名字。我个人喜欢那些看起来愚蠢但是能够解决复杂实际问题的应用程序。至于那只Hadoop小象的命运嘛,Doug现在仍然随身带着它参加各种演讲活动。


Hadoop在Yahoo公司内部的规模增长并不典型,但是对于当前很多实现的模式来说,它是一个典范。在Yahoo的案例中,最初的开发只能扩展到少数几个节点,但是几年之后,就可以扩展到数百个节点了。随着集群的增长和扩展,系统摄入了越来越多的企业数据,组织内部的壁垒开始被打破,用户也开始从数据中发现更多的价值。随着所有职能领域的壁垒都被打破,更多的数据被迁移到集群中。一个有着美好目标的事物很快成了整个组织的核心和灵魂,更恰当地说,成了整个组织的存储和分析引擎。正如一位作者所述:

2011年,当Yahoo将Hortonworks分拆为一家独立的、专注于Hadoop的软件公司时,Yahoo的Hadoop基础设施已经拥有了42 000个节点和数百PB的存储空间。

1.2 Hadoop的结构

Hadoop通常包含两个部分:存储和处理。存储部分就是Hadoop分布式文件系统(HDFS),处理就是指MapReduce(MR)。


注意 在本书完成之际,这一环境正在改变。MapReduce现在只是在HDFS之上处理Hive的一种方式。MapReduce是一种传统的面向批量任务的处理框架。像Tez这样的新处理引擎越来越倾向于近实时的查询访问。随着YARN的出现,HDFS正日益成为一个多租户环境,允许很多数据访问模式,例如批量访问、实时访问和交互访问。


当我们考虑到常规文件系统的时候,会想到像Windows或Linux这样的操作系统。这些操作系统都安装在运行重要应用程序的单台计算机上。如果我们通过网络将50台计算机连接到一起,会发生什么呢?我们仍然有50个不同的操作系统,如果我们想要运行单个应用程序来使用它们所有的计算能力和资源,这种方式对我们没有多少帮助。

例如,我正在微软的Word软件中输入这些内容,该软件只能在单操作系统和单台计算机上安装和运行。如果想提高Word应用程序的运算性能,那么我别无选择,只能给我的计算机增加CPU和RAM。问题在于,我所能增加的CPU和RAM的数量是有限制的。我很快就会达到单台设备的物理极限。

HDFS则做了一些独特的事情。你可以选取50台计算机并且在每一台上都安装一个操作系统(如Linux)。在用网络将它们连接起来之后,你在所有计算机上都安装HDFS,并且将其中一台计算机声明为主节点,将其他所有计算机都声明为工作节点。这样你就构建了HDFS集群。现在,当你将文件复制到某个文件夹中时,HDFS会自动将文件的各个部分存放在集群的多个节点上。HDFS成为Linux文件系统之上的一个虚拟文件系统,它抽象了你在集群的多个节点上存储数据的事实。图1-1从整体上说明了HDFS如何从客户端抽象出多个系统。

图像说明文字

图1-1非常简单,展示了最基本的视图(将在1.3.2节详细说明)。最重要的一点是,现在的增长能力是水平的而不是垂直的。与为单台设备添加CPU或RAM不同,你只需要增加一台设备,也就是一个节点。线性可伸缩性允许你基于自己扩大的资源需求快速扩展自己的能力。敏锐的读者很快就会争辩说,通过虚拟化也可以获得类似的优势。那么让我们用虚拟化的视角来看待同一问题。图1-2展示了这样一个虚拟化架构。

图像说明文字

管理员在服务器(大多数情况下是一个服务器集群)上安装虚拟管理软件。该软件集中了CPU和内存这样的资源,这样看起来就像有一台有着大量资源的服务器。在虚拟操作系统层上有多个客户,可以将可用的资源池划分给每个客户使用。这样做的好处包括:IO资源的最大化、资源的动态供应,以及物理集群层的高可用性。存在的问题则包括:对SAN存储器的依赖、不能进行水平扩展、垂直扩展存在限制,以及对多操作系统安装存在依赖等。目前大多数数据中心都采用这种模式,而且在过去10多年里,虚拟化一直是IT界的主流趋势。


注意 图1-2中用到了术语ESX。我们当然并不特指VMWare。我们给出虚拟化的架构只是为了说明Hadoop如何从根本上改变了数据中心的模式,以满足独特的现代数据需求。对于很多用例来说,私有云虚拟化仍然是一种可行的技术,而且应该与其他架构(如设备或公有云)放在一起考虑。


Hadoop的其他优势还包括降低能源消耗以及减少物理服务器的占用和动态供应。Hadoop需要与保持了长达10多年的发展趋势的虚拟化架构相抗衡,这是一项艰难的任务。企业这些年来一直都在远离物理架构,在减少数据中心的物理服务器数量上取得了很大进展。如果在扩展文件系统之时,Hadoop所能提供的只是添加另一个物理节点,那么我们也就没有必要写这本书了,而Hadoop也将重蹈Pets.com的覆辙。Hadoop的架构还有更多特性,在商业上具有变革性意义,值得在物理架构上投入。

1.3 数据冗余

大规模的数据也必须是高可用的。Hadoop以高效且廉价的方式存储数据。Hadoop软件架构内置了一些机制,允许我们采用廉价的硬件。正如Google公司在其论文中所说的,最初的设计假定节点会发生故障。当集群水平扩展到数百、数千甚至数万个节点时,我们别无选择,只能假定在任意给定时间集群中都会有少量服务器出现故障。

如果有些服务器的故障会危害整个集群的安全和完整性,就会抵消HDFS所提供的任何其他好处,更不用说由于睡眠不足而导致的Hadoop管理员流失。Google和Yahoo的工程师面临着艰巨的任务,既要降低成本又要增加正常运行时间。目前已有的高可用性解决方案在满足他们的需求时,不可避免地会使公司陷入硬件成本、软件成本和维护成本的深渊中。为了满足他们的需求,有些事情必须改变。Hadoop成了解决这一问题的方案,但是首先我们需要了解为什么现有工具无法成为解决方案。

1.3.1 传统的高可用性

当我们想到冗余的时候,通常都会想到高可用性(HA)。高可用性是一种架构,它描述了你访问环境的频次。我们通常用“9”的形式来度量高可用性。我们可以说自己的运行时间是99.999,也就是五个九。表1-1显示了基于可用率的实际停机时间。

图像说明文字

① Pets.com是一家短命的互联网公司。——译者注

图像说明文字

成本通常与正常运行时间成比例。正常运行时间越多意味着成本越高。尽管有少量解决方案也依赖于软件,但是大多数高可用性解决方案都聚焦于硬件。大多数解决方案的理念都是采用一组被动系统,以备在主系统出现故障时使用。大多数集群基础设施都采用这种模式。你可能有一个主节点和任意数量的副节点,其中含有复制的应用程序二进制文件以及用于集群的特定软件。一旦主节点发生故障,副节点就会马上接管。


注意 你可以选择建立一个双活式集群,这其中的两个系统都在用。从资源的视角来看,你的成本仍然很高,因为当出现故障之后,你可能需要解决两个系统的应用程序在同一台服务器上运行的问题。


快速故障恢复可使停机时间最小化,而且如果正在运行的应用程序是集群感知型的,可以解决会话终止的情形,最终用户根本就不会意识到系统已经出现了故障。虚拟化就采用了这种模型。物理主机一般是由3个或者更多系统构成的集群,其中一个系统是被动式的,它在活动系统出现故障时负责接管控制。虚拟客户可以跨系统迁移,而且客户端甚至并未意识到操作系统已经迁移至其他服务器。该模型也有助于维护工作,例如应用更新、打补丁或者更换硬件。管理员在副系统上进行维护,然后将副系统切换成主系统,再对原系统进行维护。私有云采用了类似的框架,在大多数情况下,在集群中都有一个空闲服务器,主要用于替换出现故障的集群节点。图1-3展示了典型的集群配置。

图像说明文字

这种模式的成本会很高。集群需要共享存储架构,通常由一个SAN基础设施提供服务。SAN可以存储大规模数据,但是其建设和维护成本很高。SAN独立于服务器存在,因此数据需要通过网络接口进行传输。而且,SAN将随机IO和顺序IO混合在一起,这意味着所有的IO都是随机的。最后,管理员将大多数集群配置为活动/被动式。处于被动待命状态的服务器一直不被使用,直到出现故障为止。在这种情况下,硬件成本会加倍,但是可用资源却不会加倍。

存储器厂商采用了很多方法来保持存储器的高可用性,或者说存储冗余。最常见的方法就是使用RAID(独立磁盘冗余阵列)配置。表1-2给出了最常用的RAID等级。

图像说明文字

RAID之所以流行,是因为它提供了数据保护并且针对大多数工作负载提升了性能。例如,RAID 0并不提供数据保护,但是由于增加了磁盘驱动器的数量而加快了写入速度。与集群一样,RAID也需要付出代价。在镜像RAID配置的情况下,你要单独留下一块专用盘用于数据恢复。系统使用这块副盘只是为了复制写入的数据。这个过程会降低写入速度,而且在加倍成本的同时并没有使存储容量加倍。要实现一个5TB的镜像盘RAID,你需要购买10TB的存储器。大多数企业和硬件厂商都不会在服务器架构中实现RAID 0或RAID 1。

像EMC和NetApp这样的存储器厂商采用RAID 1+0(RAID 10)来配置其SAN环境。这满足了高可用性存储器需求,提升了性能。对于含有数十个阵列且阵列中含有6个或更多驱动器的大型SAN环境来说,这种方式运行良好。这些阵列被划分成若干个逻辑单元号,提供给服务器使用。然后,这些就变成了你的挂载点或者Windows的标准驱动器盘符。


注意 请耐心一点。围绕SAN和RAID存储器的讨论可能看起来平淡无奇,但是理解传统的存储器设计将会帮助你理解Hadoop的存储结构。在过去的20年中,SAN和RAID的使用已经形成事实上的标准,当在数据中心里使用Hadoop时,消除这种偏见是一个主要障碍。


因此,SAN本质上是拥有多个磁盘阵列并且由一个中央控制台管理的大型容器。公司购买了一台服务器,然后将它配备在数据中心里,为其提供最少的存储(通常是一个小型DAS盘)来安装操作系统,并且通过网络将其连接到SAN基础设施上。对于应用程序来说,不论是商用应用程序还是数据库,都要从SAN请求数据,然后通过网络传输数据并在服务器上进行处理。SAN变成了一种集成式存储基础设施,可以对数据进行分发而很少(甚至不需要)关注IO处理。在SAN之上附加的高可用性、许可证和管理组件都大大增加了每TB的成本。

SAN技术已有很多改进,例如更快的网络互连和内存缓存。但是尽管有这么多进步,SAN的主要目的从来都不是高性能。近15年以来,每TB的成本大大降低,而且仍然在继续下降,但是购买1TB的U盘和购买1TB的SAN存储器大不相同。同样,和虚拟化的例子一样,SAN有着实际应用,并且是大多数大型企业的基础设施。关键在于,企业需要一种更快、更便宜的方式来存储和处理大规模数据,同时也有着严格的高可用性要求。

1.3.2 Hadoop的高可用性

Hadoop为传统HA集群或基于SAN的架构提供了一种替代框架。它首先假设会出现故障,然后在源代码中构建解决故障的机制。Hadoop是具有高可用性的开盒即用产品。管理员不需要安装额外的软件或配置额外的硬件组件来使Hadoop具有高可用性。管理员可以将Hadoop的可用性配置得或高或低,但是高可用性为默认选项。更重要的是,Hadoop消除了高可用性带来的成本。Hadoop是开源的,高可用性也是其代码的一部分,因此通过传递性可知,将Hadoop作为HA解决方案并没有额外成本。

那么,Hadoop如何做到以低成本来提供高可用性呢?它主要利用了这样一个事实:在过去的30年里,每TB存储器的成本显著下降。与RAID配置类似,Hadoop需要复制数据以实现冗余,默认情况下所占空间是原始大小的3倍。这意味着10TB的数据在HDFS上存储就需要30TB。这也意味着当Hadoop存放一个文件时(假设是一个大小为1TB的Web日志文件),会将它分割成若干“块”,并在整个集群上分发。就1TB的日志文件来说,如果块的大小为128MB,那么Hadoop在分发文件时要用到24 576(8192×3)个块。图1-4展示了单个文件如何被分割存放在一个3节点的集群上。

图像说明文字

根据该配置的设定,这些块的大小介于128MB~256MB。


注意 对于一个文件系统来说,这些块的规模已经非常大了。作为参照点,Windows最大块的规模(也就是可从磁盘读入内存的最大规模)是4KB。这也是大多数基于Linux的操作系统所采用的标准。


大型块的规模在很大程度上影响了Hadoop的架构。它是部署、管理和提供Hadoop的核心所在。请考虑如下这些受大型块规模影响的因素:

 处理大型文件要比处理较小的文件效率更高

 主服务器上需要的内存更少(这一问题将在下一节探讨)

 使顺序读写更高效

 查找速率可缩减为传输时间的百分之几

对于大型文件处理,让我们回到刚才的1TB日志文件。由于块的规模设置为128MB,我们可以得到24 576个块,并且通过网络发送这些块,将它们写入各节点。如果块的规模是4KB,那么块的数量会急剧增加到805 306 368(268 435 456×3)个。稍后会讨论,这么大数量的块会对集群的特定部分造成过度的内存压力。较大的块规模还优化了系统的顺序读写,这在考虑对专用驱动器的访问时很有效。驱动器只是一个带有指针(孔径臂)的磁盘,它可以移动到数据在盘片上的位置。存储器并不能保证数据块会在磁盘上一个接一个地存放,因此,孔径臂绕着盘片随机移动以获取数据的过程需要时间。如果数据以较大的块存储或者按照顺序存放,就像大多数数据库事务处理日志文件那样,那么读写操作就会更加高效。孔径臂只需要从A点移动到B点,而不是在搜索数据时四处跳读。通过将数据存储为大型块,Hadoop就可以获得这种顺序访问的优势。孔径臂寻找数据需要花费时间,这被称作查找速率。查找速率和传输时间是磁盘的两个主要瓶颈,而标准磁盘又总是会成为系统的瓶颈。传输时间是将数据从磁盘移动到系统内存所需要的时间。与传输时间相比,查找速率要慢得多。Hadoop将查找速率降低为传输时间的百分之几。

在盘面上存储大型块可能看起来效率低下或存在限制,但是Hadoop也有“数据位置”的概念,这就使冗余更加有用。正如前面提到的,Hadoop由主节点和工作节点组成。我们将主节点称为NameNode(NN),将工作节点称为DataNode(DN)。NameNode执行以下功能:

 跟踪集群中的哪些块属于哪个文件

 维护集群中的每个块所在的位置

 根据节点位置来确定块的放置

 通过块报告跟踪集群的总体健康状况

NameNode不仅将文件分成块,还会跟踪这些块在集群中放置的位置。Hadoop知道所有可用的DataNode,清楚DataNode位于哪个机架上。可获知节点在哪个机架上的功能被称为“机架感知”。图1-5以图1-4为基础进行扩展,包括了机架感知功能。

图像说明文字

下面是Hadoop用来写入文件的步骤:

(1) 将一个块写入到机架1的节点1上;

(2) 该块的副本被写入到机架2的节点2上;

(3) 将一个副本写入到机架2的节点3上。

即使有两个以上的机架,第3个块仍然会被写入与第2个块相同的机架。块的写入顺序使可用性最大化,同时减少了网络流量。通过将第2个块写到机架2上,HDFS支持在整个机架出现故障时不影响文件恢复。最后一次写入是为了减少网络流量,因为在一个机架内的节点之间进行IO通信要比在不同机架的节点之间快得多。HDFS中的文件是很大的,因此Hadoop有许多不同的机制用于减少网络流量。在我们讨论处理过程之时,会详细介绍这个概念。

请记住,任何块或文件都不会存储在NameNode上。数据只存储在DataNode上。客户端与NameNode联系,确定在何处写入块或所需读取的块所在的位置,然后客户端直接与DataNode进行对话。NameNode将块的信息存储在内存中。这就是为什么采用规模大的块很重要。要跟踪的块越多,NameNode存储信息所需的内存就越多。

只有NameNode知道所有块位于何处,以及每个块属于哪个文件。如果丢失了NameNode,那么也就丢失了集群。这曾经是Hadoop的一个SPOF(单点故障)因素,但是现在,与其他重要系统一样,NameNode也可以高效融入集群以获得高可用性。在你扩建NameNode时,需要确保系统有足够的内存来处理预期数量的块,还有冗余硬件。另一方面,由于Hadoop的内置冗余,DataNode不需要额外的硬件冗余。你仍然希望自己的DataNode拥有足够的存储、内存和CPU来保存和处理数据。

1.4 MapReduce处理

存储只是这个“等式”的一部分。如果我们无法处理或分析数据,那么数据实际上是无用的。如果企业觉得自己无法从堆积如山的数据中洞察到什么信息,也不会那么轻易采用。我们也不希望节点故障对处理造成负面影响。同样,当我们在集群上启动一个作业流程时,如果仅仅因为单个节点不可用就必须花费5个小时重新启动整个作业,这是不可接受的。

在讨论Hadoop处理时,要理解的首个关键点就是Hadoop是一个Java环境。编写Hadoop的工程师使用了Java编程语言。Hadoop的MapReduce处理也是用Java编写的。在Hadoop的早期阶段,要做任何事情都必须具有很强的Java开发技能。幸运的是,对于大多数人来说,现在情况已经不是这样了。了解Java并且理解其工作机理,对于编写MapReduce代码和发现并修复Hadoop的故障很有帮助,不过作为业务分析人员或最终用户,你现在无须接触Java代码就可以执行复杂的处理和分析。正如下一章中将进一步讨论的,工程师专门创建了Hive,以将编写Java代码的必要性剥离出来。

既然市场已经剥离了Java与MapReduce的关联,那么为什么还要了解MapReduce处理是如何工作的呢?其要义在于,MapReduce要将大型作业划分成可并行执行的任务,对于Hadoop集群上的分布式处理来说,这仍然是最基本的方式。像Hive和Pig这样的应用程序,仍然可以在后台执行MapReduce(尽管并不推荐),而且理解MapReduce的工作模式是很有帮助的,这样就可以更好地优化我们的查询并理解它们的行为。随着YARN的出现,MapReduce只是在Hadoop上访问数据的另一种手段而已,不过MapReduce仍然很重要,值得加以讨论。


注意 YARN代表Yet Another Resource Negotiator(另一种资源协调器)。YARN是由Hortonworks公司的Arun Murthy开发的,被称为“面向Hadoop的操作系统”。它将资源管理从最初的MapReduce框架中分离出来,使MapReduce将重点放在分布式处理上,而不是资源和任务管理上。现在,YARN下的集群资源管理已经得到推广,它使得其他具有不同访问模式(交互、实时以及批处理)的应用程序能够同时在同一集群上运行。YARN在Hadoop 2.x中引入。Hadoop 2.x之前的版本被标记为传统Hadoop。YARN出现之前的MapReduce被称为MRv1,YARN出现之后的MapReduce则被称为MRv2。虽然本章将进一步探讨YARN,但是要更深入地了解YARN,建议阅读由Arun Murthy、Vinod Vavilapalli、Douglas Eadline、Joseph Niemiec和Jeff Markham合著的《Hadoop YARN权威指南》一书。


如前所述,Hadoop专门使用MapReduce来处理分布式计算机网络上的数据。它通过被称为“易并行”的方式来完成这一过程。这意味着数据的初始处理是在各独立节点上并行执行的。这与传统处理方式有所不同,传统处理方式在单台计算机上运行处理过程,或者在数据库处理的情况下,要从磁盘中提取数据并存储到内存再进行处理。

Map阶段是MapReduce并行处理的第一部分。回想一下Hadoop如何在磁盘上存储数据。它会将一个文件分成多个块,每个块都包含总数据的一部分。因此,如果你有个1TB的文件并且其中含有一份名单,那么该文件将被分割成大量的块,其中每个块都包含该名单的一个子集,这些子集存储在集群中的各个节点上。图1-6显示了如何在一个3节点的集群上分散存放一个含有名单的文件。

图像说明文字

MapReduce中的映射实际上是一个Java函数。它接收输入并生成一个新的输出。输出结果是一个键/值对。


注意 在你继续Hadoop生态系统的旅途时,将遇到许多有关“键/值对”概念的示例。NoSQL主要聚焦于键/值结构。这一点很重要,因为键/值模式对于分布式处理和处理半结构化数据来说非常有用,而半结构化数据并不容易被模式化为传统的RDBMS。


在我们的示例中,一个单独的Map()函数会在每个DataNode上运行,并处理DataNode上与文件相关联的所有块。该操作独立于其他DataNode上的所有其他块。对于第一个节点,它将把名字James作为输入并且输出(James, 1)。它将对每个节点上各块中的每个名字执行该操作,这样就可以得到如下输出:

(James,1), (Joan,1), (John,1), (Frank,1), (Peggy,1) 
(James,1), (Peter,1), (Peter,1),(Arthur,1),(Wendy,1),(Bob,1)
(Wendy,1),(Mordecai,1),(Frank,1),(Frank,1),(Susan,1),(Fredrick,1)

请记住,Hadoop将并行处理这些任务。在Map阶段,节点之间不需要通信。在处理大型数据集时这是非常重要的,因为你不希望出现系统内部通信或节点之间的数据传输。在处理中引入依赖项会导致诸如竞争条件和死锁等问题。通过并行处理,Hadoop在所谓的“无共享”架构中充分利用了专用IO资源。

另一个关键因素是将“处理”推送到“数据”的理念。在我们的场景中,Map任务在留存数据的节点上运行。Map阶段从不将数据提取到中心位置进行处理。同样,这也是处理大型数据集的关键,因为在网络上移动数TB甚至是数PB的数据是不可行的。我们希望在节点上就近处理数据,并且利用该节点可用的全部内存、磁盘和CPU资源。

在Map阶段完成之后,我们还有一个名为混洗和排序(shuffle and sort)的中间阶段。该阶段从Map阶段获取所有键/值对,并且将它们分配给一个约简器。每个约简器都接收与某个键相关联的所有数据。混洗和排序阶段是数据在集群中物理移动且进程之间进行通信的唯一时间段。


警告 当我们深入研究Hive的性能时,将会重点规避Reduce阶段。这一阶段可能成为瓶颈,因为它需要在网络上移动数据,节点间还需要通信。同样,在所有映射完成之前,不能开始Reduce阶段。


图1-7显示了Map阶段的数据如何通过混洗和排序过程实现跨节点移动。

图像说明文字

混洗和排序阶段负责按照键来对数据进行排序,并将数据发送给约简器任务。每个约简器将通过一个键接收所有数据。例如,这意味着一个约简器将通过名字James接收所有与之相关的数据。如果有2人或200人的名字为James,单个约简作业仍然会接收到与键James有关的所有数据。请注意名字Peter。该名字出现了两次,而且每次都出现在单独一个数据块上。在Peter的例子中,数据不必转移到另一个节点,而是可以在同一个节点上映射和约简。


警告 要了解你的数据!如果你有一个数据集,其中某个键的值数不匀称,例如文件中50% 的名字都是Bob,那么单个约简器可能不堪重负。


最后一个阶段是Reduce阶段。约简操作将每个键/值对作为输入,并根据键生成一个计数汇总。熟悉SQL的人可以将Reduce阶段与GROUP BY子句进行比较。约简器将获取到(Frank,1, Frank,1,Frank,1),然后将其转换为(Frank,3)。图1-8展示了最终结果。

图像说明文字

在所有处理结束之后,我们会得到一份名单以及文件中每个名字出现的总次数。这可能看起来微不足道,但是我们可以针对分布式存放在100个或更多节点上的一个10TB文件运行该MapReduce示例。随着我们向集群中添加更多的节点,其性能会提高。传统的RDBMS无法扩展到这样的级别。

1.4.1 超越MapReduce

贯穿本章,我们一直在提示MapReduce并不是Hadoop上处理数据的唯一方法。MapReduce是一种非常灵活的并行处理框架,具有可伸缩性和灵活性,同时也有许多缺陷。MapReduce可批量处理数据,它善于以并行方式处理大数据集,然后汇总结果。但是MapReduce不能很好地处理即席查询或实时查询模式。例如,你想获得某个产品过去10年在每家商店的销售信息,而且这个查询需要遍历10TB的数据,如果为了获得结果你愿意等待10个小时,那么MapReduce将是一个很好的选择。但是,如果你想获得密苏里州5家商店和密歇根州10家商店销量最高的两件商品,而且需要在10秒钟以内获得这些数据,那么MapReduce就不是一个好的解决方案了。在现实中,大多数组织都围绕着一个即席的或近实时的商业智能处理架构,其中并没有用到MapReduce。即使是采用少量连接或GROUP BY子句的简单SQL事务处理,也需要很长的计算时间,尤其是在处理大规模数据时。在看待RDBMS处理连接、GROUP BY、ORDER BY和其他计算的速度时,我们有点想当然,而且忽略了这样一个事实:处理速度应该归功于前期所花费的代价,即给数据添加约束形成特定模式结构并且符合特定规则。

Hadoop是一个schema-on-read框架,而不是一个schema-on-write框架。要将数据摄入到传统的RDBMS中,需要转换数据以适应包含表、行和列的关系结构。还有其他一些结构,比如数据类型int、varchar、date,以及表之间的关系约束。当源系统也是关系型时,尽管仍然困难重重,但是ETL(抽取、转换、装载)过程运转良好。但是,如果数据是非结构化的或半结构化的呢?日志文件数据通常不会按照表的结构存放,但是可以将这些数据转换为关系模型,而代价就是降低数据的摄入速度,以及在简单的域构造更改时(例如添加列或将整数值更改为字符串)破坏数据摄入过程。已经有大量文献阐述了现代数据的数量、速度和多样性,因此本书不再深入研究这些内容,但是请牢记,Hadoop为没有结构要求的系统自由摄入数据提供了折中方案。在失去结构的地方,我们获得了灵活性。这样Hadoop就从一个简单的存储环境转变成一个灵活的、可伸缩的计算环境,打破了开发人员和严格关系数据结构之间存在的限制。

程序员用Java编写MapReduce任务。MapReduce处理运行时的复杂事务以及集群上的作业管理和调度。MapReduce需要对Java和MapReduce API有很深入的了解。随着Hadoop成为主流,该产品必然要摆脱Java开发工具的定位,更加强有力地迎合商业领域,例如传统的ETL和过去30年里一直主导着数据分析的商业分析领域。接受度是Hadoop成功的关键,如果每个人都需要学习Java来分析存储在Hadoop中的数据,那么整体接受将是缓慢而困难的。

YARN拓展了Hadoop框架的范围和灵活性。YARN使MapReduce成为访问Hadoop存储系统中所存放数据的唯一方法。其他应用程序——例如采用Mahout和最近的Spark MLib进行机器学习,采用Hive和Tez进行即席查询,采用Pig进行数据流处理,等等——可以与MapReduce并肩执行,而且任何一个应用程序都不会消耗所有集群资源。YARN变成了将Hadoop作为企业数据存储的基础所在。

对本书感兴趣,表明你可能对SQL查询语言有基本的了解。SQL是传统RDBMS的语言,它影响着我们对数据访问的看法和认识。所有传统RDBMS都有一个查询引擎,其作用是优化对结构化数据的访问。Hadoop和MapReduce很少涉及有关索引、关系约束和统计信息这些基本RDBMS构造的知识。开发人员设计SQL查询引擎来利用这些假设,如果关系结构设计不当、不存在或者实现得很差,性能会显著降低。一个更大的问题是:“当Hadoop集群的架构并不像传统RDBMS那样时,该如何在Hadoop集群上匹配传统RDBMS的性能?”这正是主要的Hadoop发布者和开放社区正在解决的问题,这也是这个社区开始远离面向批处理的MapReduce的原因之一。除了批处理之外,他们更趋向于像YARN这样支持交互和近实时使用的可伸缩、可适应的框架。

1.4.2 YARN和现代数据架构

到目前为止,我们已经围绕虚拟化、SAN、传统HA配置以及磁盘配置讨论了架构。这些都是围绕数据中心设计和标准化的基本概念。Hadoop使虚拟服务器、SAN存储和RAID配置的概念变得混淆。在着手使用这种存储和处理数据的新方式时,连供应商、数据中心管理员以及安全管理员都会感到紧张。我们也不要忘记那些为了关键业务流程而可视化和访问数据的分析师。他们所做的工作推动了企业的发展,为业务带来了收益和重要见解,从而驱动新的收益渠道并提供竞争优势。干扰他们的工作就意味着损失生产力和收益。

像Hadoop这样的颠覆性技术不可避免地会激起许多阵营的强烈反对,引发恐惧、不确定和怀疑。供应商必然会为维持其数据中心的走势而抗争,为说明其技术的优势和其他技术的劣势而争论不休。当其他厂商想要占有一席之地时,就要接受这一不可避免的实现。不管有关特色/功能和风险/回报的“风暴”如何肆虐,CIO、CTO和业务分析师只是想要以高效、廉价的方式获取数据,并且尽可能少破坏数据。

Hadoop社区和这一领域的供应商(下一章会更详细地讨论供应商和配售)的主要工作就是实现破坏的最小化。供应商、销售人员和解决方案工程师很容易陷入对特性的争论中,而忽略了创建Hadoop的原因。Hadoop本质上是一种驱动现代分析的平台或架构。业界将其称为现代数据架构。

图1-9展现了现代数据架构的组件。

由于传统RDBMS的限制,该架构将一些额外的数据源整合到数据流程中。我们现在可以包含点击流、Web和社交、传感器和机器、日志和图像等来源。当以流输入或批处理将这些数据拉入Hadoop时,我们在HDFS中汇集数据以进行直接分析或将数据迁移到其他系统中。这种方法通过将资源密集且耗时的抽取、转换和装载操作转移到更为经济的Hadoop平台上,优化了RDBMS、企业数据仓库(EDW)和大规模并行处理(MPP)资源。从本质上看,你是从ETL模型转换到了ELT模型。你将所有东西都抽取并装载到Hadoop中,只需针对给定的平台或分析需求来转换数据。

YARN是这种架构背后的驱动力。如前所述,在引入YARN之前,MapReduce是Hadoop唯一的计算引擎。MapReduce有很多优点,也有很多缺陷。传统的Hadoop将MapReduce作业放入一个队列中,每个作业都必须在上一作业完成之后才能运行。这源于扩展槽的理念,以及有多少扩展槽可供MapReduce作业运行之用。MapReduce作业是批量操作,需要花费数小时或数天时间才能完成。如果你用集群来解决单纯的大数据问题,使用MapReduce非常棒,但如果你想分析每天的销售情况并且同时通过仪表盘进行钻取操作,就不会这么顺利了。

图像说明文字

YARN引入了容器的理念。容器是一个资源池,包含专用于特定应用程序进程的CPU、存储和内存等资源。ResourceManager根据指派的策略来调度作业并且对应用程序资源进行仲裁。这些策略可能(也可能不)包含诸如“市场营销部门最多获得50%的集群内存”或“将50%的集群内存分配给市场营销部门和人力资源部门,且人力资源部门获得其中30%的份额”这样的东西。这些关键约束允许基于用户或分组进行集群资源供应。


注意 文中给出的示例是一个计算能力调度器。该调度器允许按照粒度对每个分组或用户层级分配资源。另一个示例调度器是公平调度器,它的行为类似于FIFO(先入先出)调度器,或者更简单地说,是一个机会均等的调度器。YARN的默认调度器是计算能力调度器。


DataNode运行一个ApplicationMaster,其目的是基于每个应用程序控制每个容器。ApplicationMaster充当ResourceManager的信使(更具体地说,它是名为ApplicationManager的ResourceManager的一个组件),并在每个节点的本地控制资源分配。这使YARN框架可以更好地伸缩,比采用ResourceManager作为所有节点资源的中央管理器且没有本地资源协调器的架构更有优势。

ApplicationMaster增加了一项优秀的功能,即第三方产品可以编写利用AM设计的应用程序,而且它们的应用程序可以与其他AM应用程序一起运行。如图1-9所示,引入YARN框架和AM守护进程就可以进行多用途查询访问,例如批处理、交互和实时处理。我们把它称为多租户环境,它是现代数据架构的基础,使企业现在可以开始建立一个数据湖来汇集数据,他们选用的任何分析工具都可以在其中使用。集成对于采用Hadoop的公司和实现现代数据架构来说非常关键。Hadoop和YARN的原始精神推动了这种集成,它们的开发都是开放式的,而且兼顾所有人的利益。

1.4.3 Hadoop和开源社区

讨论Hadoop、YARN或Hive时,必然要提及开源软件开发以及开源软件如何适用于企业。开源一直是Hadoop及其生态系统的关键组成部分。当说到生态系统时,我们指的是所有与Hadoop直接集成并且是Apache软件基金会(ASF)一分子的应用程序。这其中包括Hive,也包括Sqoop、Pig、Oozie、Flume以及其他几十个特性,它们每一个都代表ASF中一个不同的软件开发项目。这种区分很重要,因为在确定兼容版本时可能会引起混淆,搞不清对于哪个产品版本来说哪些特性是可用的。我们很幸运,每个产品的项目开发都公开进行,我们可以自由关注有关功能增强和bug修复的交流。除了不需要软件授权许可之外,这也是开源软件真正“开放”的原因。开发过程并没有因为保密而被隐藏起来,事实上任何人都可以参与讨论,或者推荐在将来的产品发布中应该包含哪些特性。

许多像微软这样的大型软件公司都贡献了开源代码。大规模安装部署Hadoop的公司也为该产品贡献了代码。是什么激励他们公开代码呢?开源软件开发背后的驱动力是这样的想法:通过将代码贡献给项目,产品创新会更快,每个人都会从全社区的创新中受益。此外,在你的简历上有一个开源项目代码提交者的头衔并不是一件坏事。

当开始Hive之旅时,你会把大部分时间花在有关Hive的ASF主页上。这个页面可以通过网址http://hive.apache.org找到。图1-10展示了该主页。

其中,Documentation菜单下的Language Manual和Wiki以及Development菜单下的Hive JIRA都是非常重要的链接。JIRA是由Altassian开发的一款问题跟踪软件,被ASF社区用于跟踪与产品相关的bug、问题和常规项目管理用例。可以在ASF软件项目的帮助台查看JIRA。在后面的章节中,我们将讨论Hive ASF的详细信息,但是首先要深入了解开源的过程以及它对Hadoop这类项目的意义。

图像说明文字

下面引用的这段话突出了ASF的宗旨:

Apache软件基金会为Apache开源软件项目社区提供支持,它为了公众的利益提供软件产品……Apache项目具有以下特点:基于共识的协作开发过程,开放而讲求实效的软件许可,以及创建本领域领先的高质量软件的渴望。

ASF是一个支持多种软件开发项目的组织。它为社区提供了存储库和开发方法,为社区以开放方式创建应用程序提供了论坛和支持通道。它为程序员社区监视和规范软件开发提供了一个重要场所。它强调一种“协作共识”,即决策由个体投票做出,而个体则通过投票获得控制过程的能力。他们在一个项目中的地位和权力是其所做贡献和领导能力的直接结果。

每个Apache项目都是独立的,每个项目都拥有指派给它的顶级PMC(项目管理委员会),他们控制着整个项目的方向。一个人可以在多个项目的PMC中任职,不过这种情况很少见,也并不被鼓励。PMC之下是代码提交者,他们对项目有写访问权。代码提交者本质上也是项目开发人员,他们向项目提交代码。以下是Hive代码提交者的列表: http://people.apache.org/committers- by-project.html#hive。代码提交者也可以是发布经理,负责主要发布版本背后的保障工作。位于最底层的是贡献者。他可能会问一个相关的问题或者提出一个好的建议。贡献者无法决定项目的走向,而且不能添加或修改代码。

当然,并不是说贡献者不重要,这是一个以自愿加入为原则的组织。尽管代码提交者非常受欢迎,而且组织也愿意用高薪聘请他们,但是项目仍然需要那些愿意投入个人时间来做各种工作(从文档到bug报告,再到最基本的热情宣传)的贡献者。要成为一名贡献者,你并不需要是经验丰富的开发者,也不必住在硅谷。贡献者和代码提交者一样,来自世界各地的各行各业。请记住,开放源码开发是一个社区。它是一个由有奉献精神和驱动力的志愿者构成的社区,他们喜欢为了所有人的利益而创建世界级的软件。如果某个公司因为你的开发技能得到了开发者社区的证明和认可而决定付你高薪,那对于你来说就更好了。还要记住,如果你经常做贡献并且贡献了重要代码,就可以通过投票成为一名代码提交者。

项目的每个决定都是在邮件列表中做出的。没有什么是保密的,而且尽管理解这些对话很耗费时间,却也很有意思。可通过网址http://hive.apache.org/mailing_lists.html找到Hive的邮件列表。Hive有4个单独的列表:用户列表、开发人员列表、代码提交列表和安全列表。用户列表是针对问题和支持的一般列表,由开发人员监督,但主要是一个用户对用户的论坛。如果你打算使用Hive的话,强烈建议你订阅这个邮件列表(我认为你会用到)。只需向user-subscribe@hive.apache.org发送一封空电子邮件。之后,你会收到确认该订阅的电子邮件。


警告 订阅电子邮件列表很有帮助并且有利于增长见识,但是也会产生很多“噪声”。Hive社区充满活力并且很活跃,通过这些列表可以看到大量支持和用例活动,这些是你在互联网上任何其他地方都找不到的。如果你发现这些信息毫无用处或者妨碍了你,可以随时取消订阅。另一个获得帮助的选择是Hortonworks社区连接(即HCC)。你可以通过网址http://community.hortonworks.com找到它。


对于那些将Hive作为分析平台而非开发项目的人来说,开发人员列表、代码提交列表和安全列表可能很难理解。要理解本书中的概念和日常使用Hive,并不需要订阅这些列表,但如果你想了解内部工作情况,可以自由使用这些列表。你还可以访问电子邮件归档文件,无须订阅就可以查看。一直跟随项目就很容易深入其中,特别是当讨论转向错误修正或代码开发的时候。

Apache软件基金会提供有关代码开发的治理策略。这些策略本质上是比较民主的,尽管多数派获胜的民主有一点严格。代码提交者和社区要对提交的代码、包的发布版和过程策略进行投票。在许多情况下,只有PMC成员的投票具有约束力。投票和开发决策一样,是通过公共论坛在线进行的。如果你同意提交则输入+1,不同意则输入-1(本质上是否决)。除了标准的-1和+1投票,下面给出了投票的分数值和它们的含义。

 +0:我对它没有强烈的感觉,但是我可以接受。

 -0:我不会妨碍你的,但我宁愿我们不这样做。

 -0.5:我不喜欢这个主意,但是我找不到任何合理的理由来解释我的感受。

 ++1:哇!我喜欢这个!让我们干吧!

 -0.9:我真的不喜欢这个,但是如果其他人都想继续的话,我也不会阻止。

 +0.9:这是一个很酷的想法,我很喜欢,但是我没有时间或技能来帮助你。

投票为-1将终止该过程,直到这票否决以批准或撤回的形式重新提交。投反对票的人也必须提交一份技术设计文档来解释反对的理由。这有助于减少人们滥用否决权的机会。否决这一选择为该过程提供了一个强大的制衡体系,让个人能够在一个开放的论坛上充分解决分歧和争论。只有在各方达成共识之后,PMC才会更改或发布代码。

根据投票是否针对代码更改、程序策略或新版本发布,这些规则会有所不同。我们不再详细讨论这些差别,只需要知道这个过程是建立在民主的基础之上,这种设计是为了尽可能创造出最好的软件。这个过程让每个人都有机会为项目贡献意见和想法,同时对项目的方向和功能达成共识。个人在项目中的地位取决于个人能力。同伴们根据个体贡献及其就产品展现出来的知识,选举出一个代码提交者或PMC。开源社区是由最优秀、最聪明的人构成的社区,其主要目的是为每个人开发更好的软件。

1.4.4 我们身在何处

我不否认Hadoop领域变化得非常快,任何一本书都无法追上它的脚步。发布周期是用月而不是年来度量的,补丁和更新是用周而不是月来度量的。开源社区的创新速度是我们前所未见的。采用率推动着创新。大型公司(也许像你的公司一样)要接受Hadoop带来的挑战,抓住Hadoop带来的机会,利用它所提供的一切,从中发现缺陷或者必备项。这些公司(实际上是其中努力工作的开发人员和工程师,就像你一样)有机会通过提交代码和JIRA来驱动创新,也可以通过Hadoop供应商反馈建议来使之更加完美,进一步推动创新、提升采用率。开源社区充满活力、创新和驱动力,并致力于提供高质量且设计巧妙的软件解决方案来解决复杂的现代数据问题。

Hive是这个生态系统的一个很小却很重要的组成部分。Hive至关重要,因为它是进入极端复杂的数据存储环境的入口。Hive是传统模式与新模式之间的纽带。Hive得到Hadoop开发社区的认可,因为40多年来的RDBMS设计和访问经验非常宝贵和有用,值得在推广时借鉴。


注意 我突出“40多年”是因为E. F. Codd首次发表论文A Relational Model of Data for Large Shared Data Banks是在1970年6月。说来也怪,但也许并非巧合,该论文是在圣何塞发表的,也就是Google公司发表GFS论文(该论文影响了Yahoo公司Hadoop的开发)的地方,而Yahoo公司也恰好位于这一地区附近。


Hive是面向大众的Hadoop访问方法。面向大众的Hadoop,其实用性并不亚于福特的T型车或微波炉。我个人希望这种发展趋势能持续下去,而且相信一定会这样。如果Hadoop没有被组织中真正进行分析和洞察工作的用户所采用,那么它的可伸缩性和冗余性就没有意义。如果数据没有用、不易于访问或无法马上带来回报,那么它就没有任何意义。SQL是数据的自然语言,也是常规Hadoop分析的显而易见的选择。SQL提供了易用性、共识和灵活性。尽管Hive并没有100%映射到ANSI SQL,但它还是采用了传统SQL的核心部分,让业务分析人员能够快速适应和运行Hadoop环境。

还存在其他SQL-on-Hadoop引擎,例如Impala、HAWQ和Spark SQL。它们都有各自的优缺点以及强弱项。所有这些工具(包括Hive)都认同在Hadoop上提供交互式SQL功能的价值,了解我们期望从传统商业智能基础设施获得的性能。Hive因使用广泛及其多样化的开发社区(以世界上最大的一些IT组织为代表)脱颖而出。正如我们将在后面的章节详细了解到的,Hive不会消亡,它的功能和能力会继续增长,其唯一的目的就是让业务用户能够从Hadoop中有所收获。

目录

  • 前言
  • 致谢
  • 第1章 为Hive打好基础:Hadoop 
  • 第2章 Hive简介
  • 第3章 Hive架构
  • 第4章 Hive表DDL
  • 第5章 数据操作语言
  • 第6章 将数据装载到Hive
  • 第7章 查询半结构化数据
  • 第8章 Hive分析
  • 第9章 Hive性能调优
  • 第10章 Hive的安全性
  • 第11章 Hive的未来
  • 附录A 建立大数据团队
  • 附录B Hive函数