Hadoop大数据平台-测试报告及成功案例

Hadoop大数据平台测试报告及成功案例

目录

1技术规范书应答书 ................................. 错误！未定义书签。2技术方案建议 ......................................... 错误！未定义书签。3测试及验收 ............................................. 错误！未定义书签。4项目实施与管理 ..................................... 错误！未定义书签。5人员资质与管理 ..................................... 错误！未定义书签。6技术支持及保修 ..................................... 错误！未定义书签。7附录 ......................................................... 错误！未定义书签。

1.1 大数据平台测试报告

1.1.1某银行Cloudera CDH 性能测试测试

某银行现有HODS在支撑行内业务方面已经遇到瓶颈。希望通过搭建基于Hadoop 的历史数据平台(新HODS)，以提升平台运行效率及数据覆盖面，支撑未来大数据应用，满足未来业务发展需求。本次POC测试的主要目的是验证Hadoop商业发行版(EDH) 是否可以满足某银行HODS应用特点，主要考察点包括：

?验证产品本身的易用性、可扩展性，主要涉及集群的部署、运维、监控、升级等；

?验证产品对安全性的支持，包括认证、授权、审计三大方面；

?验证产品对资源分配的控制与调度；

?验证Hadoop基本功能，包括可靠性、稳定性、故障恢复等；

?验证Hadoop子系统(包括HDFS、HBase、Hive、Impala等) 的性能、使用模式、设计思想、迁移代价等。

1.1.1.1基础设施描述

1.1.1.1.1硬件配置

硬件配置分为两类：管理节点(master node) 与计算节点(worker node)。

管理节点配置(2)

CPU Intel? Xeon? E5-2650 v3 2.3GHz,25M Cache,9.60GT/s QPI,Turbo,HT,10C/20T (105W) Max Mem 2133MHz (40 vcore) 内存16GB RDIMM, 2133MT/s, Dual Rank, x4 Data Width (128GB)

网络Intel X520 DP 10Gb DA/SFP+ Server Adapter, with SR Optics

磁盘(操作系统) 600GB 10K RPM SAS 6Gbps 2.5in Hot-plug Hard Drive (1.2TB) 磁盘(存储) 1TB 7.2K RPM NLSAS 6Gbps 2.5in Hot-plug Hard Drive (6TB)

计算节点配置(4)

CPU Intel? Xeon? E5-2650 v3 2.3GHz,25M Cache,9.60GT/s QPI,Turbo,HT,10C/20T (105W) Max Mem 2133MHz (40 vcore)

内存16GB RDIMM, 2133MT/s, Dual Rank, x4 Data Width (256GB)

网络Intel X520 DP 10Gb DA/SFP+ Server Adapter, with SR Optics

磁盘(操作系统) 600GB 10K RPM SAS 6Gbps 2.5in Flex Bay Hard Drive (1.2TB)

磁盘(存储) 1TB 7.2K RPM NLSAS 6Gbps 2.5in Hot-plug Hard Drive (24TB) 1.1.1.1.2软件环境

操作系统Redhat, RHEL 6.6

JAVA SDK JDK 1.7

Hadoop商业发行

EDH 5.3.2, EDH 5.3.3, EDH 5.4.0

版

1.1.1.1.3系统架构建议

从规划的角度出发，Cloudera具有一套对Hadoop系统架构的推荐配置，包括节点(种类及数量)规划、数据存储规划、操作系统配置等等。

节点种类

Cloudera建议在生产系统中部署4种类型的节点：

管理节点(master node)：用于运行Hadoop管理类型的后台进程，包括NameNode,、Standby NameNode、Resource Manager等。同时管理节点也被用于运行Zookeeper、JornalNodes等辅助性(比如同步) 的后台进程。根据集群的规模，这

些后台进程可以运行在同一台服务器上，或者不同的服务器上。考虑到后续的扩展，一般建议使用至少3台服务器作为管理节点；

?计算节点(worker node)：用于运行计算类型后台进程，包括DataNode、NodeManager、RegionServer等。在集群规模较小时，也可以将Zookeeper部署到计算节点上(注意Zookeeper对机器性能比较敏感。若部署Zookeeper，机器上必须预留足够的资源)；

?公共设施节点(infrastructure node)：提供基础软件服务，比如DNS、NFS (如果需要的话)。该节点同时也被用于运行Cloudera Manager、Hue以及Cloudera Manager 与Hive需要使用的数据库实例(比如MySQL)；

?边缘节点(edge node)：具有外网IP以及Hadoop集群内网IP。该节点不部署任何Hadoop后台进程。但是具有访问Hadoop服务的所有配置文件。普通用户只被允许通过边缘节点使用Hadoop服务。

数据存储考虑

考虑到Hadoop通过数据块(Block) 的复制实现数据的高可用性。在规划数据存储空间时，需要特别注意。默认情况下，Hadoop分布式文件系统使用3备份进行数据存储。因此如果需要存储1TB的数据，集群至少需要3TB的存储空间。另外，MapReduce执行过程中需要临时文件目录保存中间计算结果，在一般情况下Cloudera建议分配10% ~ 25%的磁盘总空间用于临时文件的存储。

操作系统

Cloudera建议在生产系统中使用Cloudera Manager与CDH所支持(经过全面测试) 的操作系统。目前EDH 5.4前的版本官方支持RHEL 6.5，EDH 5.4+ 支持RHEL 6.6。目前某银行系统普遍采用RHEL 6.6。

域名正向/反向解析通过DNS执行。管理节点域名为hods-n01和hods-n02；计算节点域名为hods-d01、hods-d02、hods-d03和hods-d04。

Hadoop集群中的所有机器必须使用同样的时间(包括时区)。Cloudera建议使用网络时间协议(Network Time Protocol，简称NTP)作集群间节点的时间同步。

Cloudera一般建议用户关闭SELinux。某银行并不使用SELiunx。

Cloudera一般建议用户关闭IP tables (防火墙)。某银行要求使用IP tables。为了保证集群中服务的正常通信，需要在集群机器上打开相应端口保证集群服务可以绕过防火墙。具体端口号参见官方文档https://www.sodocs.net/doc/255698024.html,/content/cloudera/en/documentation/core/latest/topics/c m_ig_ports.html。

1.1.1.2集群部署

Cloudera Manager hods-n01

hods-n01

Alert Publisher

Event Server

Host Monitor

Service Monitor

Reports Manager

Navigator

Cloudera Embedded

hods-n01

Database

Zookeeper hods-n01, hods-n02, hods-d01

NameNode

HDFS Failover Controller

hods-n01, hods-n02

JournalNode

hods-n01, hods-n02, hods-d01

DataNode hods-d02, hods-d03, hods-d04

ResourceManager hods-n01, hods-n02

NodeManager hods-d02, hods-d03, hods-d04

HBase Master hods-n01, hods-n02

HBase RegionServer hods-d02, hods-d03, hods-d04

Sentry Server hods-n01

Oozie Server hods-n01

Hue Server hods-n01

Impala Catalog Server hods-n01

Impala StateStore hods-n01

Impala Daemon hods-d02, hods-d03, hods-d04

Hive Gateway hods-n01, hods-n02, hods-d01, hods-d02,

hods-d03, hods-d04

注：在POC测试环境中并没有设计边缘节点，因此Hadoop服务的客户端配置部署在集群的所有机器上。

1.1.1.3POC测试

1.1.1.3.1数据加载测试

HDFS数据加载

测试步骤：

1.对测试数据(57GB 2014年交易流水表) 通过命令md5sum计算校验码

2.将测试数据直接通过命令“hdfs dfs -put” 上传至HDFS

3.使用命令”hdfs dfs -get” 导出数据，并使用命令md5sum重新计算校验码

4.确认两次计算的校验码完全一致

上传时间：4.8m

执行过程中，无论磁盘、CPU、网络都没有出现瓶颈。

其他数据加载的方案讨论：

1.将不同数据文件放在不同磁盘上提高磁盘吞吐量

2.定制Java程序：在上传文件过程中，对数据分片(e.g. 10GB)，并使用Snappy压缩

HBase数据加载

测试步骤：

1.使用Impala(或者hive)对要导入的数据进行ETL

2.将生成的大表利用HBase bulkload导入HBase

Impala ETL时间(参考, 不作为测试依据)：4.2h，生成数据行数为1,986,709,856 (文件格式Parquet，文件大小171GB)

HBase bulkload时间：6.8h，生成HFile的大小为887.9GB

1.1.1.3.2数据导出测试

Hive表数据导出

测试步骤：

1.Hive创建一张与待导出表完全相同的数据表export，并设置对应的数据格式(例如使

用‘|’作为分隔符)

2.HiveETL 将数据导入到export表中

3.使用“hdfs dfs -get” 从HDFS中导出数据

Snappy+Parquet

=> txt

导出txt

到本地磁盘

导出数据

行数

导出数据

文件大小

“G roup by”

SQL

13.31s 11s 18336384 837MB “Join” SQL38.38s 25s 57152010 3.3GB HBase表数据导出

测试步骤：

1.Hive中创建一张数据表，映射到HBase

2.Hive中创建一张与HBase映射表完全一致的数据表export，并设置对应的数据格式

(例如使用‘|’作为分隔符)

3.Hive ETL将数据导入到export表中

4.使用“hdfs dfs -get” 从HDFS中导出数据

Hive ETL时间：11.4h，生成文件大小971.1GB

HDFS导出数据时间：59.8m

1.1.1.3.3统计分析性能

Hive/Impala的测试包括两类非常典型的SQL操作：使用group by的聚合操作以及使用join的关联操作：

select his.tran_date, his.branch, his.tran_type, sum(his.tran_amt), count(*), count(distinct his.base_acct_no), his.cr_dr_maint_ind, https://www.sodocs.net/doc/255698024.html,y

from

sym_rb_tran_hist his

group by his.tran_date, his.branch, his.tran_type, his.cr_dr_maint_ind, https://www.sodocs.net/doc/255698024.html,y; select fmc.client_no, acct.base_acct_no, trans.tran_amt, trans.tran_date, acct.internal_key

from sym_fm_client fmc

left join sym_rb_acct acct on fmc.client_no = acct.client_no

left join sym_rb_tran_hist trans on acct.internal_key = trans.internal_key

where fmc.acct_exec in ('0101', '0201', '2801') and fmc.client_type in ('100', '300') and acct.acct_desc like '%对私%';

测试HBase时，首先需要对3张表进行汇总，生成一张大表用于HBase的数据导入与查询：

drop table if exists tran_hist_hbase;

create table tran_hist_hbase

row format delimited

fields terminated by '|'

stored as textfile

as

select fmc.client_no, fmc.client_grp, fmc.client_name, fmc.client_type, fmc.rep_doc_id, trans.*

from sym_fm_client_snappy fmc

left join sym_rb_acct_snappy acct on fmc.client_no = acct.client_no

left join sym_rb_tran_hist_snappy trans on acct.internal_key = trans.internal_key;

HBase组件测试

单点查询的执行性能

选取3类不同数据规模的用户分别进行1年、2年、5年以及全量(12年)的查询测试：

用户编号用户类型1年查询数据规

模1000939928 100 (个人) 2,381

1001353940 200 (公司) 52,748

2193714 300 (金融机

构)

184,795

根据测试结果可以发现，返回2,000+条流水的时间在1秒左右；返回2,000,000+条流水的时间在75秒以内。考虑到某银行大部分普通用户的流水规模在每年几千条，用户基本在1 ~ 2秒左右可以获得请求响应，相比当前Oracle的性能有比较明显的提升。

另外，通过单个用户不同时间周期的流水表查询可以发现：返回的流水表记录的增长会增加查询的延迟，但是并没有呈现线性增长的趋势。例如用户1000939928查询12年的流水时间是2.635秒而不是1.108 * 12 = 13.296秒。

并发查询的执行性能(500)

通过Impala随机生成两个测试集，分别包含500个唯一的客户编号：

通过并发测试可以发现，HBase在高并发(500个请求并发) 的情况下仍然可以保持在秒级响应客户请求：对于测试集合1，平均时间少于1.5秒；对于测试集合2，平均时间不到1.3秒。对比是否共享HBase客户端连接可以发现，充分利用共享连接(比如预分配50 个客户端连接缓冲于连接池中) 可以大幅提升并发效率：对于测试集合1，平均时间从3.671秒下降到1.434秒，仅为原来响应时间的39.06%；对于测试集合2，平均时间从3.989秒下降到1.289秒，为原来响应时间的32.31%。

为了提高HBase的查询效率，还可以进一步在查询应用程序、HBase表设计等多方面进行优化。考虑到时间的约束以及这部分的优化更加侧重于具体的应用，故没有进行进一步深入研究。另外还需要注意的是，HBase的查询需要通过Zookeeper定位数据的索引信息，在高并发情况下需要调整Zookeeper默认的客户端最大连接数：

Hive组件测试

单条SQL的执行性能

从上述测试结果我们可以发现，不同种类的存储格式对Hive运行的效率有很大的影响。使用Parquet可以有效提升Hive的执行效率：group by的执行时间从14.4m下降到7.1m；join的执行时间从13.1m下降到6.8m。在Parquet的基础上是否使用压缩算法，从测试的结果没有发现太大的差异。从集群资源的使用上可以比较清晰地发现：使用Parquet 后，在CPU利用率没有明显变化的同时，大大降低了内存与磁盘的开销：对于group by SQL，内存峰值从243.5GB下降到121GB，读磁盘峰值从1.2GB下降到293.9MB；对于join SQL，内存峰值从210.9GB下降到85.3GB，读磁盘峰值从774.8MB下降到200.7MB。

在Hive任务执行过程中，会使用完YARN配置的所有资源，共114 (38 * 3)个vcore 以及228GB/456GB的内存(取决于运行Map还是Reduce)。集群的CPU利用率在55%左右。

并发SQL的执行性能(3+3)

并发测试采用3+3的模式，即同时运行3个group by和3个join SQL，总共6个SQL并发运行。运行过程中可以通过YARN内嵌的web页面对每个任务的执行状态进行观察，可以发现6个SQL任务之间产生了严重的资源竞争。因此并发后，SQL的执行性能出现了非常明显的下降：group by SQL从单独运行的7分钟下降为36分钟左右(执行时间为原来的5倍左右)；join SQL从单独运行的6.5分钟下降为34分钟左右。由于YARN采用公平调度策略，6个SQL享受到了基本相同的资源份额，因此每种SQL的执行时间非常相似。

Impala组件测试

单条SQL的执行性能

从Impala测试结果我们可以发现，不同种类的存储格式对Impala运行的效率有一定的影响，但是影响并不是太大。使用Parquet后两类SQL的运行效率都会带来一定程度的提升。而在Parquet的基础上是否使用Snappy压缩，对SQL的运行基本没有影响(与Hive 测试结果相同)。

就group by SQL而言，Impala的执行时间最快为21.9分钟慢于Hive的执行时间7分钟。这主要与Impala的实现机制有关，在Impala运行过程中，CPU的利用率普遍在5%以下。通过nmon的观察，在group by聚合计算时，每台计算节点上只会使用一个CPU vcore (Hive会使用机器上配置的最大vcore数，测试时为38)。在当前实现的版本中，Impala 在分布式执行group by或者join时，会限制每台机器上只使用单线程进行计算。

对于join SQL，出现明显性能差异的因素是“compute stats”。该命令为数据表计算统计信息，包括表中每一列有多少行、不重复的有多少行、最大值、平均值等。Impala 在执行SQL前，会根据这类统计信息优化SQL的执行计划(execution plan)。比对parquet+snappy+compute stats与parquet+snappy的执行计划可以发现，前者对交易流水表sym_rb_tran_hist进行表扫描(table scan)，对另外两张表sym_fm_client与sym_rb_acct采用BROADCAST的方式进行全表的网络传输；后者则会将sym_rb_tran_hist 进行网络传输。另外，我们还可以通过执行SQL过程中资源的使用情况来进一步验证执行计划优化的效果：使用compute stats后执行计划的网络传输峰值从255MB下降到165.5MB，而内存使用更是从原先的236.8GB下降到2.4GB (根据优化的执行计划, Impala对sym_rb_tran_hist只是进行表扫描操作，即本地磁盘的顺序读)。值得一提的是，Hive在执行该join SQL操作时，由于join的关键字段并不一致，从而会生成两个不同的MapReduce 任务进行执行，进一步降低执行的效率。因此即使Hive使用了整个集群的资源，由于SQL 执行计划的优化不足，Hive执行的时间也显著慢于Impala。

并发SQL的执行性能(3+3)

正如之前提到的，在当前实现的版本中，Impala在分布式执行group by或者join时，会限制每台机器上资源的使用。因此即使是在并发的情况下，Impala的执行效率也是非常

高效的。同样运行6个SQL，可以从测试结果中发现：虽然并发执行效率上不如单条SQL 的执行效率，但是性能下降并不明显(相比于Hive)：group by SQL从21.9分钟下降到26分钟左右；join SQL从4.1分钟下降到6分钟左右(甚至还比Hive单独运行join SQL快)。

1.1.2SAP HANA检测报告

根据研究机构IDC最新发布的调查报告，SAP的数据库业务在过去一年中保持了最快速的增长，收购Sybase两年之后，SAP凭借HANA的强势，已经坐稳数据库市场第四的位置。

IDC的数据显示，SAP数据库业务在2011年中增长了44%，同时数据库市场份额提高了3.9%，数据库收入也从2010年的6.97亿美元增长到了10亿美元。

在IDC最新出炉的RDBMS调查报告中，他们将SAP的增长归结为HANA内存数据库的表现良好，SAP在今年发布了明确的数据库发展路线，已经将Sybase ASE、Sybase IQ、SQL Anywhere和HANA等产品进行了充分的整合，目前SAP在数据库市场中的实力已不容小觑。

IDC预测5年之内，基于内存的技术将取代传统的磁盘。而像大数据这样概念的兴起，也为传统的数据库技术提出了更多的挑战。

1.1.

2.1测试简介

100 TB性能测试旨在证明SAP HANA的高效性和可扩展性；企业运用大型数据库中的数据进行运营分析时，SAP HANA能够帮助企业轻松提升实时商务智能的分析性能。以下将分别介绍测试环境，并提供和分析测试结果

测试环境

性能测试环境旨在搭建一个销售与分销（SD）智能商务查询环境，为大量的结构化查询语言（SQL）和业务用户提供支持。

数据库模式

下图1.18-1中的星形模式设计显示SD测试数据环境和每个表的基数。此设计中不使用手动调优结构；没有索引、物化视图、汇总表或其他为实现更快查询性能添加的冗余结构。

SD模式

测试数据

测试数据包括一个大的数据表和几个较小的维度表，如图1中所示。仅在数据表中就有1千亿条记录，代表5年的SD数据。数据使用“Customer_ID”在16个节点进行平均哈希分区，然后在每个节点，将数据按月份分区。这样，每个节点会有60个分区，每个分区约有1.04亿条记录。（另请参见图1.18-2和“加载”部分。）

系统配置

测试系统配置（图1.18-2）是一个配有8 TB RAM的IBM X5服务器的16节点群集。每台服务器有：

?4个CPU，每个CPU有10个内核，每个内核有2个超线程，合计：

?40个内核

?80个超线程

?512GB的RAM

?3.3TB的磁盘存储

测试配置

设置

这些性能测试没有使用结果的预缓存结构或任何手动调优结构，因此，这能够验证SAP HANA“加载即能查询”的能力。一种完全没有调优结构（内部或外部）的设计对建立可持续发展的实时商务智能环境非常重要；这种设计不仅能够加快实施过程，还为即席查询提供持续的灵活性，同时省去了调优结构的维护成本。

加载

使用SAP HANA中的“IMPORT”（“导入”）命令，可以并行完成加载，该命令是一个单独的SQL语句，用来指定要加载的文件。加载过程将自动在所有节点并行处理，并使用每个数据表定义的先分布后分区的模式3（在这种情况下，指哈希分布和按月分区）。测量的加载速度为每分钟1600万条记录，或每个节点每分钟100万条记录。这种加载性能足以在短短六分钟内加载1亿条记录（代表一个工作日的活动）。

压缩

数据压缩在数据加载过程中进行。SAP HANA的压缩率4比SD模式的压缩率高出20倍；将100 TB SD数据集压缩成一个3.78 TB的SAP HANA数据库，但是群集中的每个节点只被占用了236GB的RAM（见图1.18-2）。在100 TB的数据集中，大数据表占用了85TB，大数据表经压缩后所占用的空间不到每个节点可用RAM的一半。

查询

查询套件共有20个不同的SQL查询，包括11个基础查询外加一系列时间间隔（月、季度等）。所选查询代表在原始形式数据（即没有索引、调优或采用其他非规范化方法以避免连接，这些都是传统数据库中的惯例）上运行的混合工作负载环境。它们涵盖一系列商务智能活动，从部门到企业级别，包括：

?常规报告

?迭代查询（向下钻取）

?等级

?年同比分析

产生的查询范围从中度复杂到非常复杂，包括SQL构建，例如：

?多连接（Multiple Join）

?在列表中（in list）

?事实表对事实表连接（fact to fact joins）

?子查询

?相关子查询（CSQ）

?全部合并（Union all）

查询分组为商务智能用途的三个普通类别：

?报告——计算一段时间内各种材料或客户或两者的业务绩效衡量

?向下钻取——迭代用户启动的查询，用以收集给定的单个或一组材料或客户（或二者兼有）的详细信息

?分析——跨材料或客户（或二者兼有）进行定期深入历史分析

查询说明

下表“查询说明”记录每个查询的业务说明、SQL结构、范围和限定符以及时间周期变化。如果用多个时间期间介绍一个查询，每个时间期间都作为不同的查询运行；例如，查询R1作为四个不同的查询运行，涵盖了月度、季度、半年度和年度不同的时间周期，以反映其对应数据量发生变化后的性能表现（年度数据是月度数据量的12倍）。粗体项目表示查询复杂性要素。

1.1.

2.2测试结果

该测试测量了查询的响应时间和每小时的查询吞吐量。查询首先在单一流（single stream）中运行，以测量基准查询时间，然后在10、20和25个流中运行，以测量吞吐量

（按每小时查询数计算）和在不同工作负载环境中的查询响应时间。5 多个流（multiple streams）测试中各个流的查询提交顺序随机化6，并在每次查询之间插入10毫秒的“思考”时间，模拟多用户即席BI查询环境。“附录”中列出单独的运行时间。

基线测试

正如您在图1.18-3中的基准结果中看到的，大部分查询达到亚秒响应时间；即使最复杂的查询（涉及整整五年的数据）也可在不到四秒时间内完成。

报告和选项钻取查询（267毫秒到1.041秒）证明SAP HANA在汇总数据方面的卓越能力。例如，其中最长的运行R1-4仅仅用了一秒多(1.041)，相对于其月度运行R1-1，数据量增加了12倍，处理时间却只增加了2.8倍。

向下钻取查询（276到483毫秒）证明SAP HANA对即席连接的强大支持，因此为用户提供了“切片和切块”的无限能力，却无需让技术人员提供支持它的索引（传统数据库需要这样做）。

分析查询（677毫秒到3.8秒）跨越滑动时间窗口（年）高效执行了复杂连接（实际数据连接、子查询、CSQ、全部合并）和分析。一到六个月日期范围里（A1-1到A2-2）的查询能在两秒或更短时间内运行。查询A2-3分析全部五年的日期范围，运行时间不到四秒。全部分析查询时间完全在时间范围内，这样帮助实现迭代的思维性分析。

总之，基准测试表明SAP HANA针对给定的查询，随着数据量的增加实现了有效的扩展（超过线性）。

基准性能

吞吐量（并发测试）

吞吐量测试在下表“吞吐量测试”中汇总，并表明在面对不断增加的混合BI工作负载时，SAP HANA可有效扩展。

测试案例业务说明

1个流6282

10个流36600

20个流48770

25个流52212

对于25个流，平均查询响应时间不到三秒，仅高于基准2.9倍该基准是SAP HANA管理并发和混合工作量的卓越内部效率和能力的一个指标。

用估算的每位用户每小时查询数除以每小时总查询数，可以得出BI用户并发的粗略估计值。例如，每小时25个流的52,212次查询除以20（每三分钟一次查询的平均用户率），得出报告、向下钻取和分析查询类型混合的2,610个并发BI用户的合理估计值。

即席历史查询

Hadoop大数据平台架构与实践--基础篇

Hadoop大数据平台架构与实践--基础篇 大数据时代已经到来，越来越多的行业面临着大量数据需要存储以及分析的挑战。Hadoop，作为一个开源的分布式并行处理平台，以其高扩展、高效率、高可靠等优点，得到越来越广泛的应用。 本课旨在培养理解Hadoop的架构设计以及掌握Hadoop的运用能力。 导师简介 Kit_Ren，博士，某高校副教授，实战经验丰富，曾担任过大型互联网公司的技术顾问，目前与几位志同道合的好友共同创业，开发大数据平台。 课程须知 本课程需要童鞋们提前掌握Linux的操作以及Java开发的相关知识。对相关内容不熟悉的童鞋，可以先去《Linux达人养成计划Ⅰ》以及《Java入门第一季》进行修炼～～ 你能学到什么？ 1、Google的大数据技术 2、Hadoop的架构设计 3、Hadoop的使用 4、Hadoop的配置与管理 大纲一览 第1章初识Hadoop 本章讲述课程大纲，授课内容，授课目标、预备知识等等，介绍Hadoop的前世今生，功能与优势 第2章 Hadoop安装 本章通过案例的方式，介绍Hadoop的安装过程，以及如何管理和配置Hadoop 第3章 Hadoop的核心-HDFS简介 本章重点讲解Hadoop的组成部分HDFS的体系结构、读写流程，系统特点和HDFS

的使用。 第4章 Hadoop的核心-MapReduce原理与实现 本章介绍MapReduce的原理，MapReduce的运行流程，最后介绍一个经典的示例WordCount 第5章开发Hadoop应用程序 本章介绍在Hadoop下开发应用程序，涉及多个典型应用，包括数据去重，数据排序和字符串查找。 课程地址：https://www.sodocs.net/doc/255698024.html,/view/391

Hadoop大数据平台介绍

Hadoop是什么 Apache Hadoop is an open source software framework for storage and large scale processing of data-sets on clusters of commodity hardware

Hadoop名字的由来 Hadoop was created by Doug Cutting and Mike Cafarella in 2005 Named the project after son's toy elephant

从移动数据到移动算法

Hadoop的核心设计理念?可扩展性 ?可靠性

相对于传统的BI 架构转变 数据仓库电子表格 视觉化工 具 数据挖掘集成开发工具 数据集市 企业应用工具 传统文件日志社交& 网络遗留系 统结构化 非结构化 音视频数据应用非关系型数据库内存数据库NO SQL 应用 Nod e Nod e Nod e Hadoop * Web Apps MashUps 导出/导入INSIGHTS 消费Create Map 存储/计算实时数据处理通道（Spark,Storm)数据交换平台数据存储计算平台数据访问 层Kafka Flume Goldengat e Shareplex ..传感器传感器

hadoop 的适用场景 小数据+ 小计算量OLTP 业务系统：ERP/CRM/EDA 大数据+ 小计算量如全文检索，传统的ETL 小数据+大计算量D a t a Compute 数据 计算 实时性

Hadoop大数据平台-测试报告及成功案例

Hadoop大数据平台测试报告及成功案例

目录 1技术规范书应答书 ................................. 错误！未定义书签。2技术方案建议 ......................................... 错误！未定义书签。3测试及验收 ............................................. 错误！未定义书签。4项目实施与管理 ..................................... 错误！未定义书签。5人员资质与管理 ..................................... 错误！未定义书签。6技术支持及保修 ..................................... 错误！未定义书签。7附录 ......................................................... 错误！未定义书签。

1.1 大数据平台测试报告 1.1.1某银行Cloudera CDH 性能测试测试 某银行现有HODS在支撑行内业务方面已经遇到瓶颈。希望通过搭建基于Hadoop 的历史数据平台(新HODS)，以提升平台运行效率及数据覆盖面，支撑未来大数据应用，满足未来业务发展需求。本次POC测试的主要目的是验证Hadoop商业发行版(EDH) 是否可以满足某银行HODS应用特点，主要考察点包括： ?验证产品本身的易用性、可扩展性，主要涉及集群的部署、运维、监控、升级等； ?验证产品对安全性的支持，包括认证、授权、审计三大方面； ?验证产品对资源分配的控制与调度； ?验证Hadoop基本功能，包括可靠性、稳定性、故障恢复等； ?验证Hadoop子系统(包括HDFS、HBase、Hive、Impala等) 的性能、使用模式、设计思想、迁移代价等。 1.1.1.1基础设施描述 1.1.1.1.1硬件配置 硬件配置分为两类：管理节点(master node) 与计算节点(worker node)。 管理节点配置(2) CPU Intel? Xeon? E5-2650 v3 2.3GHz,25M Cache,9.60GT/s QPI,Turbo,HT,10C/20T (105W) Max Mem 2133MHz (40 vcore) 内存16GB RDIMM, 2133MT/s, Dual Rank, x4 Data Width (128GB) 网络Intel X520 DP 10Gb DA/SFP+ Server Adapter, with SR Optics

基于Hadoop的大数据平台实施——整体架构设计

基于Hadoop的大数据平台实施——整体架构设计大数据的热度在持续的升温，继云计算之后大数据成为又一大众所追捧的新星。我们暂不去讨论大数据到底是否适用于您的公司或组织，至少在互联网上已经被吹嘘成无所不能的超级战舰。好像一夜之间我们就从互联网时代跳跃进了大数据时代!关于到底什么是大数据，说真的，到目前为止就和云计算一样，让我总觉得像是在看电影《云图》——云里雾里的感觉。或许那些正在向你推销大数据产品的公司会对您描绘一幅乌托邦似的美丽画面，但是您至少要保持清醒的头脑，认真仔细的慎问一下自己，我们公司真的需要大数据吗? 做为一家第三方支付公司，数据的确是公司最最重要的核心资产。由于公司成立不久，随着业务的迅速发展，交易数据呈几何级增加，随之而来的是系统的不堪重负。业务部门、领导、甚至是集团老总整天嚷嚷的要报表、要分析、要提升竞争力。而研发部门能做的唯一事情就是执行一条一条复杂到自己都难以想象的SQL语句，紧接着系统开始罢工，内存溢出，宕机........简直就是噩梦。OMG!please release me!!! 其实数据部门的压力可以说是常人难以想象的，为了把所有离散的数据汇总成有价值的报告，可能会需要几个星期的时间或是更长。这显然和业务部门要求的快速响应理念是格格不入的。俗话说，工欲善其事，必先利其器。我们也该鸟枪换炮了......。 网上有一大堆文章描述着大数据的种种好处，也有一大群人不厌其烦的说着自己对大数据的种种体验，不过我想问一句，到底有多少人多少组织真的在做大数据?实际的效果又如何?真的给公司带来价值了?是否可以将价值量化?关于这些问题，好像没看到有多少评论会涉及，可能是大数据太新了(其实底层的概念并非新事物，老酒装新瓶罢了)，以至于人们还沉浸在各种美妙的YY中。 做为一名严谨的技术人员，在经过短暂盲目的崇拜之后，应该快速的进入落地应用的研究中，这也是踩着“云彩”的架构师和骑着自行车的架构师的本质区别。说了一些牢骚话，

Hadoop大数据平台-建设要求及应答方案

Hadoop大数据平台建设要求及应答方案

目录 2技术规范书应答书 (2) 2.1业务功能需求 (4) 2.1.1系统管理架构 (4) 2.1.2数据管理 (12) 2.1.3数据管控 (26) 2.1.4数据分析与挖掘 (27) 2.2技术要求 (30) 2.2.1总体要求 (30) 2.2.2总体架构 (31) 2.2.3运行环境要求 (32) 2.2.4客户端要求 (35) 2.2.5数据要求 (36) 2.2.6集成要求 (36) 2.2.7运维要求 (37) 2.2.8性能要求 (49) 2.2.9扩展性要求 (50) 2.2.10可靠性和可用性要求 (52) 2.2.11开放性和兼容性要求 (57) 2.2.12安全性要求 (59)

1大数据平台技术规范要求 高度集成的Hadoop平台：一个整体的数据存储和计算平台，无缝集成了基于Hadoop 的大量生态工具，不同业务可以集中在一个平台内完成，而不需要在处理系统间移动数据；用廉价的PC服务器架构统一的存储平台，能存储PB级海量数据。并且数据种类可以是结构化，半结构化及非结构化数据。存储的技术有SQL及NoSQL，并且NoSQL能提供企业级的安全方案。CDH提供统一的资源调度平台，能够利用最新的资源调度平台YARN分配集群中CPU,内存等资源的调度，充分利用集群资源； 多样的数据分析平台–能够针对不用的业务类型提供不同的计算框架，比如针对批处理的MapReduce计算框架；针对交互式查询的Impala MPP查询引擎；针对内存及流计算的Spark框架；针对机器学习，数据挖掘等业务的训练测试模型；针对全文检索的Solr搜索引擎 项目中所涉及的软件包括： ?Hadoop软件（包括而不限于Hadoop核心） ?数据采集层：Apache Flume, Apache Sqoop ?平台管理：Zookeeper, YARN ?安全管理：Apache Sentry ?数据存储：HDFS, HBase, Parquet ?数据处理：MapReduce, Impala, Spark ?开发套件：Apache Hue, Kite SDK ?关系型数据库系统：SAP HANA企业版 ?ETL工具：SAP Data Services 数据管控系统的二次开发量如下： ?主数据管理功能 通过二次开发的方式实现主数据管理功能，并集成甲方已有的主数据管理系统。

部署Hadoop大数据平台部署Hadoop平台

课题：项目3 部署Hadoop大数据平台第2部分部署Hadoop平台课次：第7次教学目标及要求： （1）任务1 JDK的安装配置（熟练掌握） （2）任务2部署Hadoop（熟练掌握） （3）任务3 理解启动Hadoop（熟练掌握） 教学重点： （1）任务1 JDK的安装配置 （2）任务2 部署Hadoop （3）任务3 启动Hadoop 教学难点： （1）任务2 部署Hadoop （2）任务3 启动Hadoop 思政主题： 旁批栏： 教学步骤及内容： 1.课程引入 2.本次课学习内容、重难点及学习要求介绍 （1）任务1 JDK的安装配置 （2）任务2 部署Hadoop （3）任务3 启动Hadoop 3.本次课的教学内容 （1）任务1 JDK的安装配置（熟练掌握） Hadoop的不同版本与JDK的版本存在兼容性问题，所有必须选择对应 版本的JDK进行安装，表中列出了Hadoop和JDK兼容表。我们通过测试 使用Hadoop3.0.0 和JDK1.8。 安装JDK我们使用JDK包安装的方式。首先我们新建JDK的安装目录 /opt/bigddata。操作步骤为：//定位opt目录【操作新建目录/opt/bigdata】

[root@master /]# cd /opt/ //在opt目录下新建bigdata文件夹 [root@master /]# mkdir bigdata //查看opt目录下文件夹是否存在 [root@master /]# ls bigdata [root@master /]# Jdk解压安装，步骤为：【操作解压步骤】 [root@master opt]# cd / [root@master /]# cd /opt/ [root@master opt]# ls bigdata jdk-8u161-linux-x64.tar.gz //解压jdk压缩包 [root@master opt]# tar -zxvf jdk-8u161-linux-x64.tar.gz [root@master opt]# ls bigdata jdk1.8.0_161 jdk-8u161-linux-x64.tar.gz //把Jdk目录移动至bigdata目录 [root@master opt]# mv jdk1.8.0_161/ bigdata [root@master opt]# cd bigdata/ //查看是否移动成功 [root@master bigdata]# ls jdk1.8.0_161 [root@master bigdata]# JDK配置环境变量，此步骤为添加JA V A_HOME变量，并配置JDK。具体步骤为：【操作JDK的配置】 //进入环境变量配置文件 [root@master /]# vi /etc/profile //添加如下信息 export JA V A_HOME="/opt/bigdata/jdk1.8.0_161" export PATH=$JA V A_HOME/bin:$PATH //激活环境变量配置文件 [root@master /]# source /etc/profile //验证JDK是否配置完成 [root@master /]# java -version java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

HADOOP大数据平台配置方法(懒人版)

HADOOP大数据平台配置方法（完全分布式，懒人版） 一、规划 1、本系统包括主节点1个，从节点3个，用Vmware虚拟机实现； 2、主节点hostname设为hadoop,IP地址设为192.168.137.100； 3、从节点hostname分别设为slave01、slave02，slave03，IP地址设为192.168.137.201、192.168.137.202、192.168137.203。今后如要扩充节点，依此类推； 基本原理：master及slave机器的配置基本上是一样的，所以我们的操作方式就是先配置好一台机器，然后克隆3台机器出来。这样可以节省大量的部署时间，降低出错的概率。安装配置第一台机器的时候，一定要仔细，否则一台机器错了所有的机器都错了。 二、前期准备 1、在Vmware中安装一台CentOS虚拟机； 2、设置主机名（假设叫hadoop）、IP地址，修改hosts文件； 3、关闭防火墙； 4、删除原有的JRE，安装JDK，设置环境变量； 5、设置主节点到从节点的免密码登录（此处先不做，放在第七步做）； 三、安装Hadoop 在hadoop机上以root身份登录系统，按以下步骤安装hadoop： 1、将hadoop-1.0.4.tar.gz复制到/usr 目录； 2、用cd /usr命令进入/usr目录，用tar –zxvf hadoop-1.0.4.tar.gz进行 解压，得到一个hadoop-1.0.4目录； 3、为简单起见，用mv hadoop-1.0.4 hadoop命令将hadoop-1.0.4文件夹 改名为hadoop； 4、用mkdir /usr/hadoop/tmp命令，在hadoop文件夹下面建立一个tmp 目录； 5、用vi /etc/profile 修改profile文件，在文件最后添加以下内容： export HADOOP_HOME=/usr/hadoop export PATH=$PATH:$HADOOP_HOME/bin 6、用source /usr/profile命令使profile 立即生效； 四、配置Hadoop Hadoop配置文件存放在/usr/hadoop/conf目录下，本次有4个文件需要修改。这4个文件分别是hadoop-env.sh、core-site.xml、hdfs-site.xml、mapred-site.xml。 1、修改hadoop-env.sh，在文件末添加如下内容： export JAVA_HOME=/usr/jdk (此处应与Java所在的目录一致) 2、修改core-site.xml文件，在文件中添加如下内容（教材109）： hadoop.tmp.dir

文秘知识-浅谈大数据Hadoop技术 精品

浅谈大数据Hadoop技术 摘要：随着移动互联网、物联网、共享经济的高速发展，互联网每天都会产生数以万亿 的数据，这些海量数据被称作为大数据。在这个大数据时代，数据资源对我们生活产 生了巨大影响，对企业经营决策也有着前瞻性指导意义。因此，大数据已经被视为一 种财富、一种被衡量和计算价值的不可或缺的战略资源。该文从大数据Hadoop技术谈起、分别从Hadoop的核心技术、生态系统和Hadoop技术在教学中的应用四个方面进 行了阐述。 关键词：大数据；Hadoop； HDFS； MapReduce 中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2019）32-0010-02 当前，我国以信息技术为主导的创新经济高速发展，特别是依托于移动互联网和物联 网技术的网络购物、移动支付、共享单车、微信通信交流等等，给人们生活方式带来 了深刻的变革。整个互联网正在从IT（Information Technology）时代向DT（Data Technology）时代D变，在这个DT时代，人们从被动的数据浏览者转变为主动的数据 生产者，人们每天的网络购物信息、各种电子支付信息、使用共享单车信息、微信中 浏览朋友圈的信息等等，都会产生数以万亿级的数据，这样庞大的数据如何存储、如 何传输、如何计算、如何分析、如何保证数据的完整性和安全性等等一系列新的技术 挑战应运而生。然而，Hadoop技术代表着最新的大数据处理所需的新的技术和方法， 也代表着大数据分析和应用所带来的新发明、新服务和新的发展机遇。 1 什么是Hadoop Hadoop是一个由Apache基金会所开发的，开源的分布式系统基础架构。简单地说就是一套免费的分布式操作系统。我们以前使用的计算机系统，都是安装在一台独立主机 上的单机版操作系统。例如我们熟知的微软公司的Windows操作系统和苹果公司的Mac OS。而分布式系统则是通过高速网络把大量分布在不同地理位置、不同型号、不同硬 件架构、不同容量的服务器主机连结在一起，形成一个服务器集群。分布式系统把集 群中所有硬件资源（CPU、硬盘、内存和网络带宽）进行整合统一管理，形成具有极高 运算能力，庞大存储能力和高速的传输能力的系统。 Hadoop就是以Linux系统为原型开发的大数据分布式系统。Hadoop具有很强的扩展性，只要是接通网络它就可以不断加入不同地域、不同型号、不同性能的服务器主机，以 提升集群的运算、存储和网络带宽，以满足大数据所需要的硬件要求。此外，Hadoop 还具有极强的安全性，由于分布式系统数据是存储在不同物理主机上的，而且Hadoop 数据一般每个数据存储三份，而且分布不同物理主机上，一旦其中一份数据损坏，其 余正常数据会很快替代它，这样很好地解决了数据完整性和安全性问题，为大数据提 供了安全高速稳定的系统平台。

hadoop是什么_华为大数据平台hadoop你了解多少

hadoop是什么_华为大数据平台hadoop你了解多少 Hadoop得以在大数据处理应用中广泛应用得益于其自身在数据提取、变形和加载（ETL）方面上的天然优势。Hadoop的分布式架构，将大数据处理引擎尽可能的靠近存储，对例如像ETL这样的批处理操作相对合适，因为类似这样操作的批处理结果可以直接走向存储。Hadoop的MapReduce功能实现了将单个任务打碎，并将碎片任务（Map）发送到多个节点上，之后再以单个数据集的形式加载（Reduce）到数据仓库里。Hadoop是一个能够对大量数据进行分布式处理的软件框架。Hadoop 以一种可靠、高效、可伸缩的方式进行数据处理。Hadoop 是可靠的，因为它假设计算元素和存储会失败，因此它维护多个工作数据副本，确保能够针对失败的节点重新分布处理。Hadoop 是高效的，因为它以并行的方式工作，通过并行处理加快处理速度。Hadoop 还是可伸缩的，能够处理PB 级数据。此外，Hadoop 依赖于社区服务，因此它的成本比较低，任何人都可以使用。 华为大数据平台hadoop你了解多少提到大数据平台，就不得不提Hadoop。Hadoop有三大基因：第一，Hadoop需要sharenothing的架构，所以它可以scale-out。第二，它是一个计算存储解耦的架构，好处是计算引擎可以多样化。举个例子，批处理有Hive，交互查询有Spark，机器学习还可以有后面的tensorflow这些深度学习的框架。第三，Hadoop是近数据计算的。因为大数据平台是一个数据密集的计算场景，在这种非场景下，IO会是个瓶颈，所以把计算移动到数据所在地会提升计算的性能。 网络技术的发展是推动大数据平台发展的一个关键因素。2012年以前是一个互联网的时代，这个时期互联网公司和电信运营商，掌握着海量的数据，所以他们开始利用Hadoop 平台来进行大数据的处理。那时候程序员自己写程序跑在Hadoop平台上来解决应用问题。2012年以后移动互联网的迅猛发展，这使得服务行业率先数字化。例如在金融行业，手机App让用户可以随时随地查询、转账，此时银行开始面临海量数据和高并发的冲击，就需要一个大数据平台来解决这个问题。这也就是为什么华为在2013年面向行业市场推出大