Hadoop与大规模数据处理Hadoop与大规模数据处理

查礼（char@ict.ac.cn）presentation詹剑锋 讲解

中科院计算所2011.6.23

内容提要

大规模数据处理研究背景1

3

大规模数据处理开源软件Hadoop2

大规模数据计算相关研究@ICT

内容提要

1 大规模数据处理研究背景

3

大规模数据处理开源软件Hadoop2

大规模数据计算相关研究@ICT

研究背景 云计算的外延主要是大规模数据处理和基础设施弹性管理及租约式

供应

通信、网络、存储、传感器等电子信息技术飞速发展导致数据规模极大增加

传统的存储并处理这些数据的技术手段遇到瓶颈

Processing 100TB datasetsOne node Scanning@50MB/s = 35,000 min1000 node Scanning@50MB/s=35 min

Search Engine Data Warehousing Log Processing User Behavior Analyzing

MapReduce并行编程模型

Map并行处理大规模数据集

E.g., 1010 Internet web pages Reduce对处理结果进行聚集

系统负责资源分配和可靠性问题

M

x1

M

x2

M

x3

M

xn

k1

Map

Reducek1

kr

Key-ValuePairs

Dean & Ghemawat: “MapReduce: Simplified Data Processing on Large Clusters”, OSDI 2004

MapReduce示例

Map: 对所有单词产生 word, count对 Reduce: 累计单词数

Look Jane, look!

See Spot go.

Go Spot, go!

Look at

Spot!

See Spot run.

MapReduce示例

Map: 对所有单词产生 word, count对 Reduce: 累计单词数

Look Jane, look!

See Spot go.

Go Spot, go!

M M M M Extract

Word-CountPairs

M

look, 2 look, 1spot, 1

spot, 1

spot, 1spot, 1

go, 1go, 2

Look at

Spot!

See Spot run.

MapReduce示例

Map: 对所有单词产生 word, count对 Reduce: 累计单词数

Look Jane, look!

See Spot go.

Go Spot, go!

M M M M Extract

Word-CountPairs

M

look, 2 look, 1spot, 1

spot, 1

spot, 1spot, 1

go, 1go, 2

look

Sumspot

go

3 4 3

Look at

Spot!

See Spot run.

GFS - Google分布式文件系统

特点

GFS中所存储的文件通常较大（GB级），采用64MB数据块作为基本存储单元；

Google业务逻辑特点决定了GFS中的文件读多写少，写主要是追加操作，基本不存在随机写操作；

GFS的负载主要是对大文件的流式处理，客户端缓存无意义；

64MB数据块降低了元数据的数量，因此系统可使用单一元数据服务器结构。

Sanjay Ghemawat, et. al., The Google File System, SOSP’03

Why MapReduce + GFS？

简单 vs. 复杂 并行计算模式简单，编程容易。与MPI、OpenMP相比门槛低

为用户屏蔽数据通信、并发、同步、一致性等问题

专用 vs. 通用 只适用于大规模数据处理，如搜索引擎、用户日志分析，数据挖掘等

计算与存储方式紧密结合，计算向数据靠拢，专用存储模式

利于提高系统扩展性，因为任务间无依赖

内容提要

2

大规模数据处理研究背景

3

大规模数据处理开源软件Hadoop

1

大规模数据计算相关研究@ICT

Hadoop系统

Apache Nutch, 2002 NDFS + MapReduce, 2004 Hadoop, 2006Apache Hadoop, 2008 http://hadoop.apache.org/ Book:

http://oreilly.com/catalog/9780596521998/index.htmlWritten in Java

• Does work with other languages

Runs on• Linux, Windows and more• Commodity hardware with high failure

rate

Hadoop is the most successful open source software after Linux.

Hadoop 组成部分

HDFS

MapReduce

HBaseHiveHadoop 组成部分

HDFS

MapReduce

HBaseHiveHadoop 组成部分

HDFS体系结构

规模：10K nodes, 100 million files, 10 PB特性：适合数据批处理； 大化吞吐率；允许计算向数据迁移

优化：数据块副本、数据块放置策略、缓存策略等

Hadoop MapReduce处理流程

Facebook 业务系统组成

MySQL

www.facebook.comView/Click/Events Log Storage

Oracle RAC

Business intelligenceHive Web Interface / CLIData Analysis/Data Mining

Analytics for users 

ETL, Workflow Management

Hive on top of Hadoop

Zheng Shao @ Haddop in China 2009, Facebook inc.

内容提要

3

大规模数据处理研究背景1

大规模数据处理开源软件Hadoop2

大规模数据计算相关研究@ICT

数据计算相关研究@ICT

软件系统

大规模数据处理平台（Data Computing Platform）

关键技术

行列混合数据存储结构（RCFile）

DOT聚簇式互补索引（CCIndex）

ICT大规模数据处理平台构成

问题：半结构化数据的存储结构优化

将分布式数据处理系统中以记录为单位的存储结构变为以列为单位的存储结构，进而减少磁盘访问数量，提高查询处理性能。

由于相同属性值具有相同数据类型和相近的数据特性，以属性值为单位进行压缩存储的压缩比更高，能节省更多的存储空间。

支持列数据独立压缩/解压机制，在不影响列数据独立访问的前提下降低存储空间消耗，在用到某列时才解压之。 RLE：行程长度编码 BitMap：位图编码 Zlib, Gzip等：通用压缩方法

提供与Hadoop框架兼容的列存储文件访问接口，支持Hadoop程序对列存储文件中关系数据的透明访问。

行列混合数据存储结构-RCFile

RCFile与典型数据存储结构对比 Row-store：关系数据水平拆分为块，块内按行序存储

Conlum-group：关系数据垂直拆分为列组，列组间可存在重叠列，列组内按行序存储

RCFile：关系数据水平拆分，分片内按列序存储（已应用于Facebook Inc.）

行列混合数据存储结构-RCFile

RCFile与典型数据存储结构对比 Row-store：关系数据水平拆分为块，块内按行序存储

Conlum-group：关系数据垂直拆分为列组，列组间可存在重叠列，列组内按行序存储

RCFile：关系数据水平拆分，分片内按列序存储（已应用于Facebook Inc.）

Row-store

行列混合数据存储结构-RCFile

RCFile与典型数据存储结构对比 Row-store：关系数据水平拆分为块，块内按行序存储

Conlum-group：关系数据垂直拆分为列组，列组间可存在重叠列，列组内按行序存储

RCFile：关系数据水平拆分，分片内按列序存储（已应用于Facebook Inc.）

Column group

行列混合数据存储结构-RCFile

RCFile与典型数据存储结构对比 Row-store：关系数据水平拆分为块，块内按行序存储

Conlum-group：关系数据垂直拆分为列组，列组间可存在重叠列，列组内按行序存储

RCFile：关系数据水平拆分，分片内按列序存储（已应用于Facebook Inc.）

RCFile

RCFile存储空间对比

存储格式

数据表

原始文件大小 压缩行存储文件大小

RCFILE压缩文件大小

RCFILE文件长度同比减小

uri_infor 10.11MB 2.13MB 1.8MB 15.49%

user_login_data 68.71MB 21.03MB 20.28MB 3.57%

url_access_data 219.44MB 69.59MB 58.12MB 16.48%

lineitem(电商交易)

724.66 MB 227.07MB 157.29MB 30.7%

注： RCFile文件长度同比减小= 

(RCFILE压缩文件大小 - 压缩行存储文件大小) / 压缩行存储文件大小

数据表存储空间比较：

RCFile查询性能对比 测试环境

节点操作系统：Linux CentOS release 5.3 CPU：4核AuthenticAMD 1.8GHz 内存：5GB

测试查询 select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty,

sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge from lineitem where l_shipdate <= '1998-12-01' group byl_returnflag, l_linestatus;

测试结果 单位：秒

7节点与4节点加速效果：5GB 28% / 10GB 42% / 15GB 43% / 100GB 51%

在Hive中测试RCFile的性能

RCFile和Column-group、Column-store、row-store对比

测试环境 40节点，Intel 8 core CPU，32GB mem, 12*1TB Disk Hadoop 0.20.1, Linux kernel v2.6

存储空间对比/数据加载性能对比

USERVISIT表，9字段，原始数据120GB，采用Gzip压缩

查询性能对比

RANKING表，3字段

Q1：Select pagerank, pageurl From Ranking Where pagerank > 400 (~5%) Q2：Select pagerank, pageurl From Ranking Where pagerank < 400 (~95%)

存储空间对比

数据加载性能对比

RCFile和Column-group、Column-store、row-store对比

测试环境 40节点，Intel 8 core CPU，32GB mem, 12*1TB Disk Hadoop 0.20.1, Linux kernel v2.6

存储空间对比/数据加载性能对比

USERVISIT表，9字段，原始数据120GB，采用Gzip压缩

查询性能对比

RANKING表，3字段

Q1：Select pagerank, pageurl From Ranking Where pagerank > 400 (~5%) Q2：Select pagerank, pageurl From Ranking Where pagerank < 400 (~95%)

存储空间对比

数据加载性能对比

查询性能对比

RCFile在Hive 系统中的位置

HDFSMap ReduceWeb UI + Hive CLI + JDBC/ODBC

Browse, Query, DDL

MetaStore

Thrift API

Hive QL

Parser

Planner

Optimizer

Execution

SerDe

CSVThriftRegex

UDF/UDAFsubstrsum

average

FileFormats

TextFileSequenceFile

RCFile

User-definedMap-reduce Scripts

Reference: Zheng Shao @ Hadoop in China 2009

Application/End UserRCFile技术已集成至Hive、Pig、Howl等数据分析平台

Facebook的新数据已全部采用RCFile存储，之前的数据正在转换

问题：DOT上的多维区间在线查询

研究动机 网络应用中多维区间查询是普遍需求 不断增大的数据量提出了挑战：性能、存储开销、可靠性

应用需要什么样的数据模型？ 数据模型M介于Ordered Table模型和关系模型之间思路：增强高可扩

展性、高性能、高可靠性的分布式顺序表(Distribued Ordered Table, DOT)以支持多维区间查询CCIndex研究DOT

的索引

Complementary Clustering Index

HBase: 大规模分布式结构化数据存储系统• 结构：– 基于HDFS，Zookeeper构建– 数据按主键被分片为Hregion

，由HRegionServer管理– 一个HMaster进程管理多个

HRegionServer

• 特点：– 大规模非结构化或者半结构化

数据的结构化存储，随机在线读写场景

– HRegionServer不存在单点失效，扩展性好

– 数据规模上升时，通过添加对应数量的HRegionServer，性能基本不变

– HDFS保证数据可靠性

新版本：v0.90.3

HBase VS RDBMSHBase RDBMS

数据布局Data Layout

Column Oriented Row Oriented/Column Oriented

数据模型/模式Data Model/Schema

DOT/Schema free or de-normalization

Relational/XXX Paradigm

事务Transactions

No Yes

查询语言Query Language

Java API(RESTful) SQL

安全机制Security

In Development Yes

索引Index

Key lookup/Primary Key Only

B+ Tree/On Arbitrary Column

大数据容量Max Data Size

PB TB

I/O吞吐率I/O Throughput

Million TPS Thousands TPS

De-normalization Denormalization is the process of attempting to optimize the read 

performance of a database by adding redundant data or by grouping data. (From Wikipedia)

Person/Friend 朋友关系；查询某个人的所有朋友

PersonID（索引）

NAMEGENDERAGEetc.

row column familiesinfo: friend:

<id> info:nameinfo:genderinfo:age…

friend:<id>…

RDBMS HBase

FriendshipsPerson_ID（索引）

Friend_IDetc.

在HBase上实现多维区间在线查询

HBase高性能、高可靠性、高可扩展性

多属性区间查询、查询优化、记录级数据恢复

CCIndex

• 把用于备份数据的副本组织成为多份互为补充和校验的互补聚簇索引表，利用索引表上高效的连续扫描代替原表上的随机读取。

数据组织

• 基于分布式顺序表的分片信息对子查询结果集的大小进行估算， 后挑选 小子查询执行查询过程。

查询优化

• 通过互补聚簇索引表和互补校验表进行数据恢复，保证可恢复性同时仅少量增加存储开销。

数据恢复

实现 技术

CCIndex数据组织• 基于Apache HBase

– 禁用底层HDFS的副本机制

– 互补聚簇表和互补检查表用HBase存储

– 数据物理分布• 多张互补聚簇索引表

CCIT– 分别以某索引列全局

有序– 其主键为索引列的值

+原主键+索引列的值的长度

– 随机变连续• 互补校验表CCT

– 存储主键和索引列的对应关系

查询优化与数据恢复

通过分片信息预估扫描范围，优化查询执行速度。

通过CCT校验数据，并从其它表中获取数据，修补缺失。

CCIndex应用效果

• 环境：3节点– 双CPU共4核，2.0 

GHz AMD Opteron，6 GB内存，186GB RAID1 SCSI磁盘，千兆以太网

• 负载– 100万随机生成数据，

长度1K字节，– 主键+3个索引列

• 测试内容– 随机读写，连续读写，

扫描原表，扫描索引•CCIndex的索引扫描操作吞吐率是IndexedTable的11.4倍•CCIndex的随机写和顺序写吞吐率分别比IndexedTable快54.9% 和 121.4%

注：IndexedTable是HBase中的二级索引实现

CCIndex应用效果

• CCIndex 与IndexedTable 相比：– 索引列数N，取值从2到4– IndexTable的副本数，取值为N+1(估计值)–记录长度/索引列长，取值从10到30

• CCIndex存储开销相对于IndexTable增加5.3% 到29.3%。

• OriginalTable采用Primary Key上扫描代替索引扫描

• 取1KB大小1024连续行索引扫描的延迟为42ms

• 当查询结果集大于1024时，CCIndex的索引扫描延迟比IndexTable小9.2倍

CCIndex应用效果

CCIndex性能是MySQL Cluster 的1.9和2.1倍

• 环境：16节点– 双CPU共4核，

2.0 GHz AMD Opteron，6 GB内存，186GB RAID1 SCSI磁盘，千兆以太网

• 负载– 1.2亿条Nagios

监控记录，平均长度118字节，主键+2个索引列

– 与查询、或查询

注：图中30M、50M、70M和90M指query查询出的结果集大小。

查询举例：OR: CPU Utilization > 0.8 or CPU Utilization < 0.3 or ClusterID > 3。AND:CPU Utilization > 0.3 and CPU Utilization <0.9 and Cluster ID > 3。

HBase应用实例

StumbleUpon 实时数据服务，20000qps，20节点，i7，24GB，4X1TB

Yahoo! 网页内容优化，广告分析，150～800节点

Facebook Facebook Message，消息/对话/email/短信存储，每天增200

亿消息，每月1350亿邮件

Trend Micro 分布式系统事件追踪，日志，网页归档，商业智能，数据查询。

200节点，AMD 6core，32GB，10X500GB

Mozilla Foundation 崩溃报告系统，接收/存储/处理/展示崩溃信息，17节点，Quad 

core CPU，24GB，4X1TB

HBase应用实例

StumbleUpon 实时数据服务，20000qps，20节点，i7，24GB，4X1TB

Yahoo! 网页内容优化，广告分析，150～800节点

Facebook Facebook Message，消息/对话/email/短信存储，每天增200

亿消息，每月1350亿邮件

Trend Micro 分布式系统事件追踪，日志，网页归档，商业智能，数据查询。

200节点，AMD 6core，32GB，10X500GB

Mozilla Foundation 崩溃报告系统，接收/存储/处理/展示崩溃信息，17节点，Quad 

core CPU，24GB，4X1TB

淘宝数据魔方应用 - 多属性查询

淘宝数据魔方应用 - 分析结果

在大规模数据处理应用领域，专用化的数据处理技术如DFS存储，Map/Reduce计算模型，NoSQL DB成为必然的选择

互联网企业正在实践云计算技术，数据量过大导致无法采用常规架构，多采用Hadoop技术解决离线/在线数据计算问题。

数据中心和高性能计算中心在云计算技术驱动下将会出现角色交叉，体现了计算为中心向数据为中心计算模式的转变。大规模数据处理技术将起到重要作用。

以Hadoop为代表的开源软件折射出云计算的草根文化

总结

Hadoop in China历史

Founded by Hadoop engineers on 11/23/2008 1st Hadoop Salon (2008-11-23), 60 attendees 2nd Hadoop Salon (2009-05-09), 120 attendes Hadoop in China 2009 (2009-11-15), 300 attendes Hadoop in China 2010 (2010-9-4), 600 attendes

Covers Development, Application, Research and Tutorial around Hadoop technologies

Goals: Communicate, Understanding and Practice

HiC is NOT an pure academic conferenceHiC is a opportunity to exhibit your Great idea on HadoopHiC is a active stage for Hadoop grass-roots

www.hadooper.cn

Hadoop in China会场HiC 2009

HiC 2010

www.hadooper.cn

查礼（char@ict.ac.cn）weibo.com/solochar