Hadoop自动化安装和配置的问题在于隐藏了许多Hadoop组件协同工作的重要细节,本书介绍如何手动安装和配置主要的Hadoop组件,以便**使用Hadoop平台。通过设置一个完全可运行的集群,可对Hadoop内部的运行机制产生更深入的了解,并且有助于你调试任何可能发生的问题。本书还介绍了保障基于Hadoop的大数据平台**的实现方案和*佳实践,覆盖Kerberos**协议和Hadoop**机制的设计,并包括在企业内部来确保Hadoop及其生态系统相关组件**的详细方案。

第1章
构建Hadoop集群
Hadoop是一款免费开源的分布式存储和计算平台。在构建该平台后,用户可以使用商用硬件中的集群来存储和处理大量数据。在过去的数年中,Hadoop已经成为大数据项目的事实标准。本章会讲述以下内容:
选择Hadoop集群硬件。
Hadoop发行版���
为Hadoop集群选择操作系统。
本章会讲解为Hadoop集群选择和配置硬件的概念,还会介绍不同的Hadoop发行版(其数量每年都在增加)以及它们之间的异同点。
无论读者是Hadoop管理员还是架构师,构建集群的**步是确定使用硬件的类型以及成本,但是在读者下单购买硬件准备大干一场之前还有一些必要的问题需要考虑。这些问题都与集群设计有关,比如集群需要存储的数据量、数据增长率的估计、主要的数据访问模式,集群是主要用于预定义的计划任务,还是用于探索性数据分析的多租户环境?Hadoop的架构和数据访问模型具有极大的灵活性,它能够承载不同类型的工作量,比如批处理海量数据或者配合诸如Impala这样的项目进行实时分析。
某些集群更适合于特定类型的任务,因此在选择硬件阶段就应考虑到集群的设计以及目的,这是非常重要的。在处理由成百上千个服务器所组成的集群时,*初有关硬件和总体布局的决定会对集群的性能、稳定性以及对应的成本起着至关重要的作用。
1.1 选择Hadoop集群硬件
Hadoop是可扩展的集群,它采用非共享系统处理大规模并行数据。Hadoop的总体概念是单个节点对于整个集群的稳定性和性能来说并不重要。根据这种设计理念,我们可以在单个节点上选择能够**处理少量(相对于整体的数据量大小)数据的硬件并且在硬件层面也无需过分追求稳定性和冗余性。读者可能已经知道,Hadoop集群由多种类型的服务器所组成。它们中有主节点,比如NameNode、备份NameNode以及JobTracker,还有称为DataNode的工作节点。除了核心的Hadoop成员外,我们通常还会采用多种辅助服务器,比如网关、Hue服务器以及Hive元存储服务器。典型的Hadoop集群结构如图1-1所示。
图1-1Hadoop集群的典型布局
这些类型的服务器在集群中各有分工,因此对于节点的硬件规格和可靠性要求也不尽相同。我们首先讨论针对DataNode的不同硬件配置,随后讲解有关NameNode和JobTracker的典型配置。
1.1.1 选择DataNode硬件
DataNode是Hadoop集群中的主要工作节点,它的作用主要有以下两种:存储分布式文件系统数据以及执行MapReduce任务。DataNode是Hadoop的主要存储和计算资源。有些读者可能认为既然DataNode在集群中扮演了如此重要的角色,我们就应该尽可能地使用*好的硬件。事实并非如此。在Hadoop的设计理念中将DataNode定义为“临时工”,也就是说,服务器作为集群的一部分需要足够**地完成任务,同时在出现故障时替换的成本不会太过昂贵。在大型集群中的硬件故障频率可能是核心Hadoop***所考虑的*为重要的因素之一。Hadoop通过将冗余实现从硬件迁移到了软件解决了这一问题。
Hadoop提供了多种级别的冗余。每个DataNode只存储了分布式文件系统文件的部分数据块,同时这些分块在不同节点中进行了多次复制,因此在单个服务器故障时,数据仍然能保证可访问性。根据读者选择的配置,集群甚至能够承受多个故障节点。除此之外,Hadoop还允许我们指定服务器位于机架上的位置并且在不同的机架上存储多份数据副本,这样即使在整个机架的服务器发生故障时也能极大地增加数据的可访问性(尽管这并不能严格地保证)。这种设计理念意味着我们无需为Hadoop DataNode采用独立磁盘冗余阵列(RAID)控制器。
我们可以为本地磁盘使用一种称为简单磁盘捆绑(JBOD)的配置来代替RAID。它为Hadoop的工作负载提供了更加出色的性能并且减少了硬件成本。由于冗余性是由分布式文件系统提供的,因此我们不必担心单个磁盘发生故障。
存储数据是DataNode的首要工作。它的第二个工作是作为数据处理节点运行自定义的MapReduce代码。MapReduce作业有多种不同的任务组成,它们在多个DataNode中并列执行并且在所有子任务都完成后作业才能生成逻辑上的统一结果。
因此Hadoop需要在存储和计算层面都提供冗余性。Hadoop通过在不同节点上重新执行失败的任务来实现这点,这样就不会扰乱整体作业。同样它会跟踪那些故障率较高、响应速度较慢的节点,*终这些节点会被列入到黑名单中并且从集群中剔除。
那么典型的DataNode需要配置何种硬件呢?在理想情况下,DataNode应该是一个平衡的系统,它应该拥有适量的磁盘存储容量以及运行功率。定义“平衡的系统”和“适量的存储容量”并不像听起来那么容易。在我们尝试构建具有可扩展性的*佳Hadoop集群时有需要考虑的因素。其中*重要的问题之一是集群的总存储量以及集群存储密度。这些参数关系密切。总存储量相对比较容易进行估算。基本上只需要了解集群中容纳的数据量就能够解决问题。根据下面的步骤读者可以估算集群中所需的存储量。
1. 确定数据源:列举所有已知的数据源并且确认是否需要引入所有或者部分数据。读者应该保留群集总存储量的15%~20%,甚至更多,这是为新数据源或者未知的数据增长预留的容量。
2. 估算数据增长率:每个确定的数据源都有对应的数据摄入率。举例来说,读者准备从OLTP数据库中进行导出,我们可以清楚地估算出该数据源在特定时间段内所生成的数据量。当然,读者也需要进行一些导出测试来获得准确的数字。
3. 将估算的存储量乘以副本因子(replication factor):到目前为止,我们所讨论的都是可用存储量。Hadoop通过将数据块进行多次复制并将它们放置在集群中的不同节点中来实现分布式文件系统层面的冗余性。默认情况下,每个分块都会进行3次复制。通过增加或者减少副本因子,读者可以对该参数进行调整。将副本因子设置为1并不可取,因为这样集群中就不存在任何的可靠性。我们首先应该获取集群存储量的估算值,然后将它乘以副本因子。如果读者估算今年需要300TB的可用容量并且所设置的副本因子为3,那么我们所需的存储量大约为900TB。
4. 考虑MapReduce临时文件以及系统数据:MapReduce任务在映射(map)执行和化简(Reduce)步骤之间会生成中间数据。这些临时数据并不位于分布式文件系统中,因此读者需要为临时文件预留服务器磁盘总量的25%~30%。此外,还应该为操作系统预留单独的磁盘分卷,但是操作系统的存储要求通常并不重要。
确定所有可用以及原始的集群存储量是选择DataNode硬件标准的**步。为了更进一步进行讨论,我们将集群所有可用的存储量称为原始容量,从硬件角度来说这点是非常重要的。另一个重要的标准是数据密度,它是集群总存储量与DataNode数量之间的商。通常我们有两种选择:采用大量配置低存储密度的服务器或者使用少量具有高存储密度的服务器。我们将对这两者进行介绍同时加以比较。

第1章 导言
1.1 研究日本大众传播学发展脉络的现实背景
1.2 本书的写作视角
1.3 学界对日本大众传播学研究的现状分析
1.4 日本大众传播学研究发展脉络的研究方法
第2章 社会因素对大众传播学研究体系的影响
2.1 思想层面的要因
2.2 日本民族特征对学术研究的影响
第3章 日本大众传播学研究的发展历程
3.1 前大众传播学研究时期的新闻学研究(1929~1948)
3.2 大众传播研究时期(1949~1990)
3.3 社会信息学研究时期(1991~2003)
3.4 信息研究的学科融合时期(2004至今)
第4章 日本大众传播学理论研究的特征
4.1 日本大众传播学研究的理论源流
4.2 社会心理学取向的研究
4.3 大众社会论取向的研究
4.4 马克思主义取向的研究
第5章 扎根于日本社会的大众传播学研究——以灾害信息学研究为例
5.1 灾害信息学研究的开端
5.2 日本灾害信息学研究的历史脉络
5.3 日本灾害信息学研究的主要课题
5.4 灾害信息学的研究现状
第6章 日本大众传播学研究的特征及其存在问题
6.1 日本大众传播学研究的特征
6.2 日本大众传播学研究的问题
第7章 日本大众传播学研究给中国的启示
7.1 中国传播学研究中的问题
7.2 日本对中国传播学研究的启迪
7.3 结语
参考文献
后记

1. 手把手教你配置**的Hadoop集群,充分利用Hadoop平台的优势。 2. 为Hadoop生态系统实现强健的端到端的**保障。