基于P2P 可伸缩架构的大数据分析平台研究与实现

基于 P2P 可伸缩架构的

大数据分析平台研究与实现 (申请清华大学工程硕士专业学位论文)

培养单位：软件学院

工程领域：软件工程

申请人：卓安

指导教师：王建民教授

联合指导教师：丁贵广副教授

二○一二年五月

Research and Implementation of Big Data Analysis Platform Based on P2P

Scalable Architecture

Thesis Submitted to

Tsinghua University

in partial fulfillment of the requirement

for the professional degree of

Master of Engineering

Zhuo An ( Software Engineering)

Thesis Supervisor : Professor Wang Jianmin

Associate Supervisor : Associate Professor Ding Guiguang

May, 2012

摘要

随着互联网应用的飞速发展和信息的社会化，数据呈爆发式的增长，传

统的关系数据库在处理分析如此海量的数据时出现性能和可扩展性的瓶颈，

所以必须研究新的有效的大数据分析平台。大数据技术目前还没成熟，也没

形成统一标准，但工业界已经广泛使用 Hadoop 作为其大数据处理平台，这

也带动了国内学术界对 Hadoop 相关技术研究。除了 Hadoop 外，NoSQL 相

关技术也得到较快发展，涌现了一批优秀的开源项目，如 HBase 和 Cassandra

等都被工业界广泛应用。

本文基于国家核高基科技重大专项——非结构化数据管理系统

LaUDMS 来研究和实现对大数据的处理分析相关技术。非结构化数据管理系

统 LaUDMS 重点就是深入研究大数据的存储和分析技术，并结合理论和实

践来解决对大规模非结构化数据的管理难题。

本文首先对大数据处理分析平台的研究现状进行了综述；其次在综合比

较分析现有平台优缺点的基础上介绍了非结构化数据管理系统 LaUDMS 的

内核清华知云 Kloud 的平台架构；再次是清华知云 Kloud 中的大数据分析平

台的技术研究和实现。技术研究包括深入分析了分布式数据仓库 Hive 的设

计和组件，并将其融合到基于 P2P 架构的 Cassandra 内部实现中；为实现 Hive

组件完全融合到 Cassandra 中，定义了基于 Cassandra 自由表的面向对象数

据模型来存取 Hive 的元数据信息；为提高自由表访问效率，描述了基于

Cassandra 自由表的辅助索引设计和实现，并且将其融合到 Hive 的分布式索

引插件框架中，实现 Hive 分析的性能优化。该大数据分析平台实现后对某

网站用户访问日志进行了实验分析，性能和可用性得到相应的提升，取得良

好效果。

关键词：大数据；MapReduce；自由表；辅助索引；数据模型

Abstract

With the rapid development of Internet applications and information

socialization, the data was at the explosive growth that the traditional relational

database meets performance and scalability bottlenecks to analyze such large

scale data, so it is necessary to study new and effective data analysis platform.

Big data technology is not mature and hasn’t formed a standard, but the industry

has widely used Hadoop as its big data processing platform, which also drives

academic to study Hadoop related technologies. Besides Hadoop , the NoSQL

related technologies also developed rapidly, and several famous open source

projects come out, such as HBase and Cassandra.

Firstly, the paper surveys on the big data processing and analysis platform.

Secondly, based on comprehensive comparative analysis of the existing big data

platform, introduces the architecture of Tsinghua Kloud that is the

LaUDMS(LaSQL Unstructured Data Management System)’s core platform.

Thirdly, introduces the research and implementation of Kloud’s big data

analysis platform followed by the main work of the paper. Research in-depth the

components of Hive and make Hive with Cassandra integrated. To make Hive

components fully integrated into the Cassandra, define the object-oriented data

model on the Cassandra schema-less table to store the Hive metadata. To make

condition query on Cassandra more effective, design and implement secondary

index on schema-less table and integrate into the distributed index plug-in

framework of Hive to optimize the performance of Hive analysis. The paper

analyzes user access log on the big data analysis platform described here and

achieves the good performance and availability.

Key words: big data; MapReduce; schema-less table; secondary index; data

第 1 章引言 ............................................................................................. 1

1.1 研究背景与意义 .............................................................................. 1

1.2 大数据平台架构分类 ...................................................................... 3

1.2.1 基于 Master-Slave 主从式架构的平台 ...................................... 3

1.2.2 基于 P2P 可伸缩架构的平台 .................................................... 5

1.3 主要工作及贡献 .............................................................................. 7

1.4 论文的结构安排 .............................................................................. 8

第 2 章相关工作 ...................................................................................... 9

2.1 大数据分析平台体系架构研究 ....................................................... 9

2.1.1 HadoopDB-并行数据库和 MapReduce 的融合 ........................ 10

2.1.2 epiC-同时支持 OLTP 和 OLAP 的弹性云计算平台 ................ 11

2.1.3 Brisk-Cassandra 与 Hadoop 的融合之作 .................................. 13

2.2 基于自由表的面向对象数据模型 .................................................. 14

2.2.1 自由表结构 ............................................................................. 15

2.2.2 JDO/JPA 的标准接口实现 ...................................................... 16

2.3 基于自由表的辅助索引 ................................................................ 16

2.3.1 辅助索引-行键存储 ................................................................ 17

2.3.2 辅助索引-数据存储 ................................................................ 18

2.4 本章小结 ....................................................................................... 20

第 3 章基于 Cassandra 的知云平台体系结构 ........................................ 21

3.1 知云平台体系架构 ........................................................................ 21

3.2 知云平台的分布式存储 ................................................................ 26

3.2.1 自由表存储 ............................................................................. 26

3.2.2 分布式文件系统 ..................................................................... 26

3.3 知云平台的分布式计算框架 ......................................................... 27

3.3.1 JobTrakcer 和 TaskTracker 运行在 Cassandra 上 ..................... 28

3.3.2 知云平台节点 OLAP 和 OLTP 服务的配置和切换 ................. 29

3.4 本章小结 ....................................................................................... 30

第 4 章知云中的大数据分析平台实现 .................................................. 31

4.1 Hive 与 Cassandra 融合组件分析 .................................................. 31

4.1.1 Cassandra CQL 引擎和 Hive Driver 引擎的融合 ..................... 34

4.1.2 Hive 元数据存储到 Cassandra 自由表中 ................................. 34

4.2 基于 Cassandra 自由表的面向对象数据模型 ................................ 37

4.2.1 对象-关系在自由表数据模型上的映射 .................................. 37

4.2.2 实现基于 Cassandra 自由表的面向对象数据模型 .................. 42

4.3 知云平台和 Hive 的结合 ............................................................... 43

4.3.1 易用的大数据分析平台 .......................................................... 43

4.3.2 可分析的大数据格式多样化 ................................................... 44

4.4 实验结果与分析 ............................................................................ 44

4.4.1 实验环境 ................................................................................. 45

4.4.2 实验结果 ................................................................................. 45

4.5 本章小结 ....................................................................................... 48

第 5 章基于 Cassandra 自由表的辅助索引设计和实现 ......................... 49

5.1 辅助索引设计 ............................................................................... 49

5.1.1 辅助索引格式 ......................................................................... 51

5.1.2 辅助索引并发更新机制 .......................................................... 51

5.2 辅助索引实现 ............................................................................... 53

5.2.1 辅助索引管理 ......................................................................... 53

5.2.2 辅助索引查询 ......................................................................... 55

5.3 辅助索引在知云大数据分析平台的应用 ...................................... 56

5.3.1 Hive 分布式索引框架解析 ...................................................... 56

5.3.2 实现 Hive 分布式索引框架下的辅助索引插件 ....................... 57

5.4 实验结果与分析 ............................................................................ 58

5.4.1 实验环境 ................................................................................. 58

5.4.2 实验结果 ................................................................................. 58

5.5 本章小结 ....................................................................................... 59

第 6 章总结与展望 ................................................................................ 61

6.1 论文工作总结 ............................................................................... 61

6.2 论文工作展望 ............................................................................... 62

参考文献 ................................................................................................... 63

致谢 ....................................................................................................... 67

声明 ....................................................................................................... 68

个人简历、在学期间发表的学术论文与研究成果 .................................... 69

主要符号对照表

TB 数据存储单位，万亿字节，Terabyte 的缩写

PC 个人计算机，Personal Computer 缩写

NoSQL 非关系型数据库，Not Only SQL 缩写

DAFS 一个文件系统，Distributed Avatar File System 缩写

DRBD Linux 系统块设备，Distributed Replicated Block Device 缩写

NFS 网络文件系统，Network File System 缩写

CAP 分布式领域有关 Consistency，Avaliability 和 Partition 关系的定理

DHT 分布式哈希环

ETL 数据采集和抽取操作

Kloud 清华知云平台

LaUDMS 国家核高基科技重大专项非结构化数据管理系统

OLTP 联机事务处理

OLAP 联机分析处理

JDO Java 对象持久化规范之一

JPA Java 对象持久化规范之一

LSM 数据的文件存储架构

HDFS Hadoop 的分布式文件系统

MPP 大规模并行处理

epiC 弹性云计算平台

RDBMS 关系数据库系统

SMS Hive 的查询计划生成器

ORM 对象关系映射规范

CCIT 自由表的辅助索引表，Complemental Clustering Index Table 缩写

DBA 数据库管理员

DAG 有向无环图

JDBC/ODBC 数据库连接驱动

UV 独立访客，Unique Visitor 缩写

Keyspace Cassandra 数据模型中表的概念，对应数据库中的 Database

第 1 章引言

1.1 研究背景与意义

随着互联网应用的飞速发展和信息的社会化，数据呈爆发式的增长，传统的

关系数据库在处理分析这样海量的数据时出现性能和可扩展性的瓶颈，所以必须

研究新的有效的大数据（Big Data）[1]平台。大数据的概念在业界没有明确统一定

义，IBM 将其特征概扩为大规模（Volume），多样性（Variety）和快速化（Velocity）

三方面，其中大规模表示数据量非常大，TB 级以上；多样性表示数据不像传统关

系数据库那样的结构化数据，而是有非常多的无法用二维表逻辑来表达的非结构

化数据；快速化表示数据产生速度和要求的分析速度都要快。另外对大数据分析

后的结果可用于用户的决策依据上，蕴含了大数据隐藏的价值（Value）。本文以后

提到的大数据的基本特征就体现在这四个 V 上。依据这个定义当前已进入大数据

时代，其中微博和社交网络的高速发展带来的信息社会化，这直接推动了大数据

的产生。此外还有物联网和移动互联网的大量实时的数据在产生，如何去管理和

分析这些数据已是当前业界面临的共同难题。

在大数据时代，传统关系数据库已无法处理 TB 级以上大数据，也不能很好支

持相应的分析。为高效处理和分析大数据，大数据技术领域也有相应的概念提出

——云计算[2]。云计算概念目前也是比较模糊，本文说到云计算是指将复杂的计算

处理程序自动分拆成无数个较小的子程序，再分发调度到多台服务器去并发执行，

然后合并各子程序的结果进行输出的一种计算模式。这种处理方式的优势就是使

得大数据的处理可通过廉价的 PC 电脑来完成，相较于大型服务器方便而成本也

低。随着企业规模的增长，大数据也随之出现，其价值的分析挖掘的在企业受到

重视，许多知名大型企业都构建了自己的大数据分析平台。

目前提供商用的大数据平台的公司主要有 Google，Amazon，Yahoo， IBM 和

Microsoft 等。Google 的大数据平台包括分布式文件系统 GFS[3]，分布式计算框架

MapReduce[4]，分布式数据库 BigTable[5]和分布式锁机制 Chubby[6]等。Google 这套

系统成功运行在百万台服务器上来为其庞大的搜索引擎服务，处理的数据量达到

PB 级。Amazon 则以云计算为基础提供了一套租赁存储和计算服务的平台，包括

弹性计算云 EC2[7]，基础存储架构 Dynamo[8]，简单存储服务 S3[9]，简单队列服务

SQS[10]和简单数据库服务 SimpleDB[11]等。Amazon 构建的大数据平台不仅服务自

己内部的互联网应用，也公开对外进行收费服务，已形成成熟的盈利模式。Yahoo

第 1 章引言

提供的大数据平台以分布式的数据存储平台 PNUTS[12]为代表，PNUTS 被设计成

可以对多个不同数据中心的分布式访问。PNUTS 包括存储单元 SU，Tablets 定位

Routers，Tablets 控制管理 Tablet Controller 和数据同步服务 Message Broker 等。IBM

推出的大数据平台类似 Amazon，提供即买即用的服务，这个平台被称为蓝云（Blue

Cloud）。蓝云包括 Xen[13]虚拟化，Linux 操作系统映像和 Hadoop[14]分布式文件系

统等。Microsoft 提供的大数据平台为 Azure[15]存储服务，包括大型二进制对象服

务，队列服务和数据表服务等，此外 Microsoft 也有对应于 Google 的 MapReduce

并行分布式计算框架 Dryad[16]。除了这些知名互联网企业，传统数据库和存储服务

商如 Oracle 何 EMC 等也都建设了自己的大数据平台，由此可见大数据的处理技术

已得到企业界的高度重视和应用。

企业界对大数据技术的需求和应用如此强烈也带动了开源界积极贡献开源的

大数据平台和学术界对大数据的理论研究。从 2003 年开始，Goolge 公开发表了一

系列核心技术的文章，包括 GFS，MapReduce 和 BigTable 等，这掀起了开源大数

据平台的开发热潮。其中典型的就是开源搜索引擎 Nutch 和全文索引 Lucene 之父

Doug Cutting依据GFS和MapReduce论文用 Java语言将之实现，2006年加入Yahoo

之后将其形成一个专门负责分布式存储和计算的项目，称之为 Hadoop。 Yahoo 将

Hadoop 贡献给 Apache 之后得到开源界大力支持，由此 Hadoop 得到快速的发展和

广泛的应用，目前 Hadoop 已经可以认为是大数据处理平台的一种标准。后来由

Cloudera 公司专门为 Hadoop 提供商业版的服务和开发支持。随后 Amazon 也发表

了其 Dynamo 的论文，Facebook 结合 Dynamo 的分布式哈希 DHT 架构和 BigTable

的数据模型开发了自己的高性能分布式数据库 Cassandra[17]，并发表了介绍

Cassandra 的论文。Facebook 将 Cassandra 也贡献给了 Apache，同样得到广泛的应

用，成为 NoSQL（Not only SQL）的代表之一，后来由 DataStax 公司专门为其提

供商业版服务和开发支持。此外还有很多 NoSQL 开源产品得到大量应用，如

MongoDB[18]和 Redis[19]等。

正因为 Hadoop 和 NoSQL 技术能对大数据提供高性能，强扩展性和高容错性

服务，Hadoop 和 NoSQL 技术得到快速发展，引起学术界对其一致性[20-22]，平台

架构，数据模型和辅助索引等方面的深入研究，本文关注和研究的是平台架构,数

据模型和辅助索引。其中平台架构本文将其分为两类，一类是以 Google 发表的 GFS

和 BigTable 为代表的 Master-Slave 主从式存储架构，另一类是以 Amazon 发表的

Dynamo 为代表的 P2P 存储架构。数据模型也分为两类，一类是关系数据库的行存

储模型，另一类是类似 BigTable 这样的列存储模型，本文称之为自由表模型，因

为这种数据模型的结构不固定，可以动态添加列。NoSQL 就是自由表存储模型的

第 1 章引言

典型代表，与传统关系数据相比具有模式灵活多变，高性能读写和高可扩展性等

优势。本文内容关注大数据的处理，所以不考虑传统数据库的使用，所提到的数

据模型就都指自由表模型，这里说的辅助索引也是基于自由表的。

1.2 大数据平台架构分类

前一节提到大数据平台架构可分为两大类：基于 Master-Slave 的主从式架构和

基于 P2P 的点对点架构。本节将通过举例的方式分析这两种架构的优缺点。

1.2.1 基于 Master-Slave 主从式架构的平台

图 1.1 基于 Master-Slave 主从式的 HDFS 架构

Master-Slave 主从式架构的典型用例就是 Hadoop 的体系架构。图 1.1 显示了

Hadoop 的主要模块之一 HDFS（Hadoop Distributed File System）[23]的架构，采用

的是 Master-Slave 模式，其中 Namenode 属于 Master，集群中只有一个；Datanodes

属于 Slave，集群中可以有多个。从用户的角度来看，它就像传统的文件系统一样，

可以通过文件路径对文件执行创建、读取、修改和删除操作等。Namenode 负责管

理文件系统的命名空间，记录文件数据块在每个 Datanode 上的位置和副本信息等

元数据以及客户端对文件的访问控制。集群中的 Datanode 一般是一个节点一个，

负责管理它所在节点上的数据存储，直接处理客户端的读写请求。这种架构

Datanodes 之间的数据块是互相备份的，某台 Datanode 因出现软硬件问题而宕机是

不会影响整个 Hadoop 集群的继续运转的。而如果是 Namenode 服务器宕机，整个

系统无法运行，因为 Namenode 是 Hadoop 集群中的一个单点。此外，Namenode

第 1 章引言

上存储的映像文件和事务日志是 HDFS 的核心数据结构，如果这些文件损坏，将

会导致 HDFS 不可用。

图 1.2 Hadoop Namenode 高可用性的改善方案 AvatarNode

一方面 Master-Slave 主从式的架构中读写控制在中心节点 Master 上，这个优

势就是有强的读写一致性，这在分布式领域是很关键的特性。根据 CAP[24]定理，

分布式系统具有一致性（Consistency）、可用性（Availability）以及分区容忍度

（Partition- tolerance）这三种属性，但是一个分布式系统只能同时满足其中的两个

属性。Hadoop 作为分布式文件系统就要有强的读写一致性，选择了 CP，保证文件

读写不冲突，所以选择 Master-Slave 模式也是简化了系统架构。

另一方面 Master-Slave 模式存在 Master 节点中心化这个问题一定程度上影响

了商用，因而业界对这个问题也进行了一定的改善，Facebook 提出了 Standy

AvatarNode 的解决方案[25]。如图 1.2 所示，备份 AvatarNode 通过 NFS 读取并执

行主 AvatarNode 的事务日志来保持数据的同步，并同时接收 Datanode 的数据块

信息报告，这保证了主备 AvatarNode 尽可能地减少数据不一致性，使得备份

AvatarNode 能够很快地切换为主节点的角色。主备 AvatarNode 的角色是注册到

ZooKeeper[26] 中的，DataNode 可以根据 ZooKeeper 中信息判断需要服从哪个

AvatarNode 节点的指令。为了实现热备 AvatarNode 的数据同步和易用性，

Facebook 还改进了 NameNode 事务日志，并部署了 DAFS（Distributed Avatar File

System）来屏蔽 AvatarNode 的故障切换，使得这些改变对客户端透明。Cloudera

针对这个单点问题也提出了一个冷备份方案，需借助第三方软件DRBD（Distributed

第 1 章引言

Replicated Block Device）和 Linux 上的 Heartbeat 组件，配置复杂。总的来说

Master-Slave 架构有如下缺点：

1. 中心化节点导致单节点问题，可用性低，虽然有一些方案来解决，但并不是很

完美。Facebook 提出的 AvatarNode 方案虽是热备份方案，也是目前较理想的

选择，但还需借用 NFS 来提供帮助，这一定程度影响元数据读写速度而且还是

无法保证主备切换间不出现操作失败错误。Cloudera 提供的冷备份方案缺陷更

多，除了不能进行热备份，还得依赖第三方组件以及带来的配置复杂。

2. 集群部署复杂。Master-Slave 模式带来的是集群角色较多，集群部署时需要根

据角色进行适当配置，带来一定的复杂性。

3. 集群性能受 Master 节点性能影响。由于 Master 保存了整个集群的元数据信息，

也就直接决定了整个集群的规模，该节点的内存和 CPU 等特性都是直接影响

因素。因此一般要选择一台高性能的服务器来做 Master 节点。

1.2.2 基于 P2P 可伸缩架构的平台

本文提到的 P2P 特指服务器端的分布式架构，并非提供 P2P 的网络服务，不

与 CS（Client/Server）服务模式相对应。基于 P2P 模式的典型分布式系统用例是

Cassandra 的体系架构，这个架构也是从 Dynamo 借鉴过来的。如图 1.3 所示，这

是 Cassandra 的节点之间的组织，每个节点角色都一样，形成一个 P2P 的环，节点

之间通过 Gossip 协议来进行通信。Cassandra 在 P2P 的环上依据一定的备份放置策

略存放多个备份可以做到高可用性，即环上的某节点宕机不影响整个集群使用。

此外 Cassandra 能识别多数据中心，这可以提供备份组的功能，通过调整节点的布

局来避免某个数据中心出现故障影响整个集群的可用性。Cassandra 为获得高可用

性牺牲了强一致性，即只能提供最终一致性。由此可见 Cassandra 的集群架构在

CAP 的折中问题上选择了 AP（即可用性和分区容忍度）。

这种 P2P 的模式的理论基础是分布式哈希 DHT，其理论要点就是每个节点

维护一部分路由和保存一部分数据，保证数据均衡的分布在集群中的各个节

点上，然后实现整个集群中的寻址和存储。一致性哈希（Consistent Hashing）[27]

是 DHT 的一种实现，其实现目标就是在节点加入和删除时不会导致映射关系发生

重大变化，Cassandra 采用的即为这种实现。如图 1.4 所示，该一致性哈希环上有

四个节点首尾相连形成一个环形哈希空间，在这个环形哈希空间中，如果沿着顺

时针方向从对象的哈希值出发，直到遇见一个存储节点，那么就将该对象存储在

这个存储节点上，因为对象和存储节点的哈希值是固定的，因此这个存储节点必

然是唯一和确定的。节点的加入和删除导致的映射关系变化只是环中的一部分：

第 1 章引言

图 1.3 基于 P2P 可伸缩架构的 Cassandra 集群示意

图 1.4 一致性哈希环

1. 节点加入。如图 1.4，如果在节点 2（node2）和节点 4（node4）之间加入一个

节点 5，则影响的映射关系只是节点 5 和节点 2 之间的对象，这些之前存储到

节点 4 的对象现在存储到节点 5 上了。

2. 节点删除。如图 1.4，如果删除节点 2，则影响映射关系的只是节点 2 和节点 1

之间的对象，这些之前存储在节点 2 的对象现在存储到节点 4 上了。

Gossip

Cassandra Node

Cassandra Node Cassandra Node

Cassandra Node

Cassandra Node Cassandra Node

第 1 章引言

3. 节点的加入和删除会导致负载均衡问题。Dynamo 使用了虚拟节点来解决这个

问题，每个节点管理环中的多个位置，达到一个动态的均衡。Cassandra 为简化

这种结构，给每个节点设定一个令牌 token，这个 token 就是哈希空间中的一个

值，通过修改负载轻节点的 token 值来使节点在环上移动实现负载均衡。

一方面 P2P 模式通过去中心化实现整个集群中无单点问题，可用性很高；并且

每个节点都一样且角色单一，部署也很简单。

另一方面 P2P 模式也有一些缺点，主要就是：

1. 不适合数据的一致性级别要求高的场景。这种模式设计的目标就是高可用性，

为获取高可用性舍弃了强一致性，而提供最终一致性，所以比较适合大数据的

分析场景。这种场景更新操作较少，对一致性级别要求不高。

2. 没有基于 P2P 的分布式计算框架来提供并行分析。目前 Cassandra 虽说可以利

用 Hadoop 来完成 MapReduce 分析，但是还得弄一套 Hadoop 集群并要进行相

应数据的 ETL 操作，这导致过多依赖 Hadoop 了。

1.3 主要工作及贡献

本文的工作主要是研究和实现基于 P2P 可伸缩架构的大数据分析平台，即重

点是对大数据提供分析的平台。前一节分析了目前大数据平台架构的两大类的优

缺点，且都有著名的开源代表，本文综合比较后选择基于 P2P 模式的 Cassandra 作

为存储平台，并融合 Hadoop 的分布式计算框架 MapReduce，这也是清华知云 Kloud

选择的基础平台。在这基础之上，为提供更方便的大数据分析的功能，还将基于

Hadoop 的数据仓库平台 Hive[28]和 Cassandra 进行融合以实现本文目标系统——基

于 P2P 可伸缩架构的大数据分析平台。为实现这个平台还在基于 Cassandra 自由表

的面向对象数据模型和基于Cassandra自由表的辅助索引等几个核心技术上进行了

改进和创新。

在融合 Hive 和 Cassandra 方面，本文首先详细介绍了基于 Cassandra 的清华知

云平台体系结构，然后具体介绍其中的大数据分析平台相关技术。深入研究了 Hive

的体系结构和相关组件，确定可融合到 Cassandra 的组件，以发挥两者优势。

Cassandra 本身具有高性能实时读写功能，即偏重联机事务处理 OLTP，Hive 则是

对大数据具有分布式并行处理的优势，偏重联机分析处理 OLAP。一般来说一个系

统 OLTP 和 OLAP 是不可能两者同时都满足的，但由于 Cassandra 支持多数据中心，

故可通过多数据中心配置来同时提供 OLAP 和 OLTP 功能，这也是本文所实现的

大数据分析平台的优势。

在基于自由表的面向对象数据模型方面，本文研究了 Java 对象持久化 JDO[29]

第 1 章引言

规范，并选取 JDO 实现框架 DataNucleus[30]作为实现基于 Cassandra 自由表的面向

对象数据模型的参考。为实现 Hive 完全与 Cassandra 进行融合，使得整个大数据

分析平台也是 P2P 模式的，需要使 Hive 成为 Cassandra 的一个组件。这就要求把

Hive 依赖的元数据库移植到 Cassandra 中的自由表中，因此本文研究和实现了把对

象-关系映射到 Cassandra 的自由表中并进行复杂的查询。

在基于自由表的辅助索引方面，本文综述了基于自由表的辅助索引研究现状，

然后针对目前Cassandra自带的辅助索引使用限制多和功能弱的缺点给出了另一种

辅助索引的设计和实现。自由表的辅助索引是对应关系数据库的 B-树索引的说法，

目的是避免全表的扫描，加快比较和排序等条件查询。自由表数据模型基于 LSM

（Log-Structured Merge）-Tree[31]的存储架构，采用的是列存储，能很好的水平扩

展，关系数据库的使用的索引技术在自由表中不能很好的扩展，所以针对自由表

需建立辅助索引（Secondary Index）来满足所需要的查询。本文提供的辅助索引方

案包括管理和查询两部分，利用基于 Cassandra 的自由表的列可动态添加且可自定

义列名排序的特性，构建复合列名来进行索引。这套辅助索引技术已应用到本文

所说的 Hive 元数据库的复杂查询中和 Hive 分布式索引插件的实现中以优化 Hive

分析性能。

1.4 论文的结构安排

本章后面的部分如下安排：第 2 章将介绍大数据分析平台研究现状和相关工

作，主要包括大数据分析平台的体系架构，基于自由表的面向对象数据模型和基

于自由表的辅助索引等三个研究内容。第 3 章介绍清华知云平台体系结构，讲解

各个模块的总体情况。第 4 章介绍清华知云平台上的大数据分析平台实现，即融

合 Hive 和 Cassandra 并进行实验。第 5 章介绍基于 Cassandra 自由表的辅助索引及

其应用。第 6 章是对本文研究和实现的大数据分析平台的工作进行总结和对未来

进一步工作的展望。

第 2 章相关工作

在大数据时代，商业界和开源界针对大数据的分析平台都有很多，商业界由

于代码封闭不能深入研究，所以本文研究基于开源界的相关技术。当前开源典型

代表就是 Hadoop，Hadoop 作为一个存储和处理大数据的分布式数据处理系统平

台，主要有两大模块组成，一个是支持海量数据存储的分布式文件系统 HDFS，另

一个是支持分布式调度的计算框架 MapReduce，优势是具有非常好的并行计算和

容错能力。Hadoop 的兴起除了开源者卓越的贡献，还得益于工业界和学术界很多

都是基于 Hadoop 来对大数据处理进行研究的。为了支持更好的数据分析，Facebook

贡献了基于 Hadoop 的 Hive 分析工具，通过类似 SQL 的语言来对大数据进行分析

操作，而不用去写 MapReduce 程序，大大方便了 Hadoop 的使用。但 Hadoop 存储

层具有单节点问题，其中 NameNode 节点性能也决定整个集群性能，不适合小文

件的存储。这也是本文所要做的改进和创新，即底层存储选择基于 P2P 可伸缩的

架构，如 Cassandra，然后融合 Hadoop 的 MapReduce 计算框架和 Hive 来构建大数

据的分析平台。

目前，国内外很多科研机构和公司已经在大数据分析技术方面进行了大量深

入的研究。本文主要研究领域集中在体系架构，数据模型和辅助索引三方面。

2.1 大数据分析平台体系架构研究

在传统数据库时代有并行数据库系统（Parallel Database）和数据仓库来进行

数据的分析，但这些都不能随着数据规模增大而进行任意扩展，伸缩性和容错性

都不好，这限制了其在大数据领域的使用[32]。Hadoop 目前被公认为大数据处理的

一个标准，其相对传统关系数据库来说的优势就是强大的并行性和容错性，这受

到业界的大量关注和研究。Hadoop 的设计目标是针对大数据处理，面向的应用也

比较广泛，可伸缩性强，通过 MapReduce 计算框架能很好的扩展到成千上万台机

器并行计算。但与并行数据库系统比在性能和效率上并不是非常好，所以有很多

其他大数据分析平台基于 Hadoop 来进行不同需求的改进[33-34]。大规模并行处理

（MPP，massively parallel processing）系统的 Aster[35]和 Greenplum[36]等就使用

MapReduce 来并行化他们的查询分析，不过他们都是商业界的使用。学术界提出

的 HadoopDB[37]也是将 Hadoop 的 MapReduce 框架应用到并行的关系数据库处理

中。学术界还针对 Hadoop 的缺点提出新的弹性云计算平台 epiC（elastic，

power-aware，data-intensive Cloud）[38]，该平台底层存储还是可用 HDFS 代替，但

并行计算框架则是基于 MapReduce 和 Dryad 的新一代分布式计算引擎。开源界则

尝试了将 Hadoop 和 NoSQL 的融合，除了 Hadoop 官方提供的类 BigTable 的自由

表 HBase[39]本身就是一种案例外，还有 DataStax 公司基于 Cassandra 和 Hadoop 构

建的开源项目 Brisk[40]也是很好的将 NoSQL 和 Hadoop 融合了。接下来将详细介绍

本文关注的这些大数据分析平台的架构，文献[41]对大规模数据分析平台进行了更

详细的比较。

2.1.1 HadoopDB-并行数据库和 MapReduce 的融合

图 2.1 HadoopDB 体系架构

HadoopDB 是将关系数据库 RDBMS 和 MapReduce 框架融合在一起来提供大

数据分析平台的架构，如图 2.1 所示，本质上是让 MapReduce 成为运行 RDBMS

的节点之间的通信层和任务调度器。关系数据库的优势是较好的性能和灵活方便

的查询接口，MapReduce 框架的优势则是可伸缩，容错好和能运行在异构的环境

里，HadoopDB 就是结合两者优势构建的混合系统。从总的架构来说就是 SQL 查

询语句经过 Hive 转换成 MapReduce 作业，然后会传递到 RDBMS 节点由数据库处

理，通过这种方式就使单节点的关系数据库变成了无共享（Shared-Nothing）架构

的并行数据库。

HadoopDB 具体实现的模块如图 2.1 所示，用椭圆标注的即是。其中 Database

Connector 扩展 Hadoop 的 InputFormat，负责将数据库中的数据转换成 key-value 对

传给 MapReduce 使用，所以对框架来说底层的数据库就类似 HDFS 上的数据块。

元数据管理 Catalog 维护了数据库的元数据信息，包括连接参数，如数据库地址，

驱动和验证信息等以及数据备份和数据分区等信息。数据导入模块 Data Loader 负

责将外部数据导入到 HadoopDB 中，包括两个哈希组件，一个是全局哈希，另一

个是局部哈希，前者目的是使数据能均衡的分布到各个节点上，后者为了保证各

个文件的大小不大于设置的最大的块的大小。查询计划生成器 SMS（SQL to

MapReduce to SQL Planner）负责将查询语言转换成 MapReduce 作业，并对其优化

保证大量的查询能在数据库中直接操作，实现上扩展了 Hive。

HadoopDB 本身还是依赖于 Hadoop，面向的是 OLAP 这类应用。另外底层存

储使用行存储的关系数据库，这相对列存储的自由表来说进行大规模数据分析性

能不能发挥更好。整个架构也是 Hadoop 的 Master-Slave 模式，所以单点问题也是

存在的。另一方面，HadoopDB 的其他理念和本文有一定相似之处，如利用

MapReduce 这个并行计算模块和底层存储独立，并将 Hive 的底层改用关系数据库

而不依赖于 HDFS 等，这也是本文学习参考的地方。

2.1.2 epiC-同时支持 OLTP 和 OLAP 的弹性云计算平台

epiC 系统的目标是构建同时支持 OLTP 和 OLAP 的系统[42]，如图 2.2 所示，

包括查询接口，弹性执行引擎 E3[43]（Elastic Execution Engine）和底层弹性数据存储

系统 ES2[44]（elastic storage system）。

查询接口就是将类 SQL 语言转化成 OLTP 和 OLAP 的具体查询，目的是方便

原来 RDBMS 的用户的使用。查询接口中的 OLTP Controller 和 OLAP Controller 分

别处理相应的查询。由于 OLTP 和 OLAP 的处理方式很不一样，epiC 的查询处理

引擎和底层存储系统是松耦合的，查询接口可根据查询类别使用不同的查询方式。

ES2 存有关于底层数据的元数据统计信息，这些信息被用于相应的查询控制器生成

最优的查询计划。OLAP 的处理是将查询被转换成一系列的作业（Job），通过弹性

执行引擎 E3 完成并行化的作业执行。OLTP 的处理是通过索引和查询优化来调用

ES2 的读写接口完成。两者都依赖 ES2 来提供事务支持，它们之间的访问竞争的

冲突是通过减弱 OLAP 的数据一致性，对 ES2 底层数据进行快照的方式来解决。

弹性执行引擎 E3 架构如图 2.3 所示，OLAP Controller 将多个作业提交到 E3

后，E3 的主节点 Master 会将作业分发到各个节点去并行的执行，和 MapReduce

框架一样只是完成执行的工作，需要底层数据切分和数据块定位的支持。E3 此外

还提供迭代计算的支持，因此很容易实现需要迭代计算的数据挖掘算法，比如

Kmeans。事实上该引擎结合了 MapReduce 和 Dryad 的优点，对复杂的数据处理流

程进行了优化，因此简化了相应的使用。

图 2.2 epiC 体系架构

图 2.3 epiC 分布式计算引擎 E3 架构

弹性数据存储系统 ES2 如图 2.4 所示，包含了三大模块，分别为数据导入控制

模块（Data Import Control），数据访问控制模块（Data Access Control）和物理存储

模块（Physical Storage）。数据导入控制模块负责将传统关系数据库中的数据和其

他第三方的数据批量导入到 ES2 系统中，其中导入管理器（Import Manager）负

责处理各种数据源的类型，写缓存（Write Cache）是为高效的批量写进行数据缓

存，缓存满后再灌入底层存储。物理存储模块包括分布式文件存储，分布式索引

和元数据的统计信息，为其他模块提供底层服务，其中分布式文件存储可以是任

意选择，epiC 选择了 HDFS。数据访问控制模块则是负责对来自 OLTP 和 OLAP

控制器和 E3 引擎的请求进行处理，将其转化为对底层近似最优的数据访问计划。

图 2.4 epiC 弹性存储引擎 ES2 架构

epiC为能够同时支持OLAP和OLTP在各模块上有很多优化，但其也做了牺牲，

比如 ES2 的底层数据模型采用的是关系型数据模型，前面提到这在大数据领域是

不适合的，因此本文选择自由表模型。ES2 还提供数据切分，自适应负载的备份策

略，事务管理等核心技术，但这都和关系数据模型或者主从架构相关，并没给出

基于自由表模型或者 P2P 可伸缩架构的方案。另外 ES2 也提供分布式辅助索引来

避免全表扫描，其实现并非基于自由表实现，而是基于 P2P 覆盖网络来实现范围

查询，通过其统一的索引框架来管理多种辅助索引[45-46]。目前 ES2 实现了基于 P2P

覆盖网络的分布式 B+-树索引[47]和分布式多维索引[48]。

2.1.3 Brisk-Cassandra 与 Hadoop 的融合之作

DataStax 是为 Cassandra 商业化提供支持和服务的公司，是目前 Cassandra 开

源的主要贡献者，类似 Cloudera 公司与 Hadoop 的关系。Brisk 则是 DataStax 公司

利用 Cassandra 作为底层存储，并融合 Hadoop 和 Hive 的开源项目。Brisk 内部基

于 Cassandra 的自由表实现了兼容 HDFS 的文件存储系统 CassandraFS，这样就能

在 Brisk 上直接跑 MapReduce 程序。由于底层存储实现完全是基于 Cassandra 的自

由表结构，所以 Brisk 没有 HDFS 的 Namenode 和 Datanode 节点，也就没有相应单

节点问题，如图 2.5 所示。虽然 MapReduce 框架中的 JobTracker 和 TaskTracker 之

间也是 Master-Slave 的关系，但是 JobTracker 故障后可以在集群任意的节点重启，

不足是没有保存相关状态，之前运行的作业可能无法继续完成。另外 Brisk 也能够

操作 Cassandra 自由表的数据，也就是说 Brisk 不仅可以被用来像 HDFS 一样存储

和分析任意文件，也能像 HBase 一样用 MapReduce 进行并发的分析表里的结构化

数据。此外 Brisk 利用 Cassandra 的多数据中心概念提供备份组实现，这样可以在

一个集群中同时实现实时数据读写和数据分析，不需要进行数据的迁移。其中左

半部分备份组 1 用于分析，右半部分备份组 2 则用于实时读写，两者之间的数据

同步由 Cassandra 在后台自动进行。

图 2.5 DataStax 开源 Brisk 架构

Brisk 的设计理念和知云平台很多相同地方，都是基于 P2P 可伸缩架构的大数

据平台，但是实现的方式不太一样，第 3 章会介绍知云平台的情况。Brisk 也集成

了 Hive 来进行大数据的分析，但是其实现很简单，原因是 Hive 的重要组件元数据

库 MetaStore 从关系数据库移植到 Cassandra 中时 Brisk 简化了相关的操作，这会导

致部分 HiveQL 无法支持。本文则针对这种情况深入研究 Hive 和 Cassandra 相关组

件，在基于自由表的面向对象数据模型和基于自由表的辅助索引两方面进行了改

进和创新，使得 Hive 和 Cassandra 能完全的融合在一起。

2.2 基于自由表的面向对象数据模型

自由表的数据模型是类似 BigTable 的松散的列存储数据模型，可以认为是稀

疏多维的 HashMap，与传统的关系型的数据模型有很大不同，即不能利用已有的

关系数据库的对象-关系映射方案将 Java 对象-关系直接映射到自由表上。关系数

据库上的对象-关系映射已经很成熟，比如 Hibernate[49]和 DataNucleus 等都有很好

的实现，用户可以用面向对象的思维方式去使用底层的 API 访问关系数据库。目

前对自由表的访问则需要直接使用与自由表模型相关的 API，用户需要理解自由表

模型才能知道如何去最优化访问底层。所以对习惯使用关系数据库的用户来说直

接用编程 API 操作自由表有一定的障碍。Brisk 之所以没有完全支持 HiveQL，也

是因为其没有基于自由表的面向对象数据模型实现，无法直接进行相关复杂的查

询。本文研究的这个基于自由表的面向对象数据模型能抽象底层数据模型，这样

让用户能像使用关系数据库一样只关注应用层，不需要理解底层的数据模型。

2.2.1 自由表结构

本文定义类似 BigTable 的列存储数据模型为自由表结构，列可以动态添加和

删除，不需要像关系数据库那样预定义。这里以 Cassandra 的自由表来描述自由表

的具体结构，如表 2.1 所示。

表 2.1 Cassandra 自由表结构

Timestamp Column Family 1 Column Family 2

URI Title Type

row1 t3 http://www.google.com

t2 http://www.apache.com

t1 Hadoop

row2 t5 text/html

t4 text/plain

自由表就是以表的形式存储数据，每个表由行和列组成，在 Casssandra 中称

为 Keyspace。每个列属于一个特定的列族（Column Family），列族对应关系数据

库中的表，但可以动态添加列。表中由行和列确定的存储单元称为一个元素（Cell），

每个元素保存了同一份数据的多个版本，由时间戳来标识。表 2.1 中有两行数据，

两个列族，其中第一个列族包含了两列，第二个列族包含了一列，另外元素的值

可有可无，有值的元素有 5 个，并且都有一个时间戳关联对应。行键是数据行在

表中的唯一标识，在底层按照字典序有序存储并作为检索记录的主键，这对应关

系数据库的主索引。底层存储时是按照列族进行存储，这也是为什么也叫列存储，

这对应关系数据的行存储。表 2.1 形象化的描述了自由表是按照列存储的稀疏行列

矩阵的概念模型，物理模型实际上就是把概念模型的一个行进行分割，并按照列

族存储，表中的空值是不被存储的，这样可以最优化存储空间。这种存储结构还

有的一个优势是任何一个列族都能随时向表中添加新列，支持灵活而复杂的数据

结构。此外，这种模型能水平分割，所以一个表可以无限大，系统会自动水平分

割到多个机器上并管理好，这也是自由表能支持海量数据的一个原因。

2.2.2 JDO/JPA 的标准接口实现

基于自由表结构的 Cassandra 提供的 API 和关系数据库的 API 相差很大，需要

熟悉关系数据库的用户去理解自由表模型才能有效的使用自由表。此外，一般应

用的设计是分层的，很多应用层代码都是使用对象-关系映射 ORM（Object/Relation

Mapping）框架来完成的，存储层对应用层是透明的。自由表本身作为持久化存储

层，也不需要暴露给用户过多细节，只需要提供面向对象的数据模型，让用户能

以面向对象编程的方式使用存储。因此如果有基于自由表的对象-关系映射实现后，

应用层代码就不用更改，则可以使用扩展性很好的自由表存储。

Java 对象持久化已经有一套接口标准，其主要有两个规范，分别是 JDO（Java

Data Objects）和 JPA（Java Persistence API）[50]，DataNucleus 平台能同时支持这两

个规范。DataNucleus 平台提供了一个可扩展的框架，具体的底层存储实现是以插

件的形式，所以提供的底层存储可以是关系数据库或者自由表等。根据插件定义，

底层存储需要实现持久化，查询和删除对象，并且还要映射对象之间的关系，包

括一对一，一对多和多对多等。此外，为支持复杂的表达式查询，还需要实现对

应的查询语言 JDOQL/JPQL，这就要求有辅助索引的帮助。DataNucleus 官方提供

了关系数据库的对象-关系映射实现，也提供了基于 HBase 自由表的对象-关系映射

简单实现，但没有使用辅助索引，而是直接进行扫描完成的。本文第 4 章将介绍

基于 Cassandra 自由表的面向对象数据模型 JDO 实现，该实现利用了基于自由表

的辅助索引来优化查询，并将其作为 DataNucleus 的底层插件，替换了 Hive 元数

据库 MetaStore 组件自带的基于关系数据库的存储。

2.3 基于自由表的辅助索引

自由表中的元素（Cell）由行键，列（列族：列名）和时间戳唯一确定，但很

多情况下用户想查询某列符合条件的所有记录，这时并不知道行键，所以要做全

表扫描，效率很低。这种查询在传统数据库中经常见到，一般是 where 子句里指

定相应条件，但可通过 B-树索引高效做到。B-树索引不能简单的应用到自由表中，

因为自由表需要高性能的实时读写，而且数据规模增大后能很好的水平扩展，而

B-树索引一是不能方便的扩展，二是数据规模大了之后读写性能急剧下降。因此

一般自由表只提供主键索引，即对行键索引，而需要用户去根据应用去构建自己

的基于列的辅助索引。

当前 NoSQL 运动的流行催生了自由表在业界的大量使用，对自由表上的列进

行范围查询也是需求很大。目前 HBase 和 Cassandra 等都是对行键才能直接做范围

查询，对于列进行范围查询则需要全表扫描，所以为避免全表扫描，需要进行构

建相应的辅助索引。本文研究的基于自由表的辅助索引就是用于加快自由表中表

数据的访问速度，有效避免全表扫描。根据当前业界对自由表的辅助索引研究现

状，本文将辅助索引实现分为两类，一类是索引里只存储行键，另一类是索引和

原表数据一起存储。前者查询索引时得到的只是行键，还需要利用这些行键进行

随机读取相关数据，后者则是查询索引的时候就可得到原有数据，无需再进行随

机读取，下面分别介绍相关实例。

2.3.1 辅助索引-行键存储

目前自由表的辅助索引很普遍的做法就是以列值作为行键，行键作为列重新

构造一个表，即可实现根据列值快速地定位相关数据所在的行，这种做法也叫反

向索引。这种索引方式简单，但有两大缺点，一是索引的数据可能不是本地的而

是其他机器上的，会导致数据的传输消耗，二是数据的更新和索引的更新不是原

子性会导致数据的不一致性。

ITHBase（Indexed Transactional HBase）针对 HBase 提出了事务级的索引，强

调了数据的一致性，其实现到 HBase RegionServer 的代码里了，有一定的性能问题。

IHBase（Indexed HBase）也是针对 HBase 的服务端的二级索引，和 ITHBase 不同

的是索引存放到内存里了，所以需要耗用很大内存，但对 HBase 本身性能影响不

大。ITHBase 和 IHBase 都是需要重写 HBase 原生的类，不能方便的与 HBase 主版

本同步升级。HBase 官方根据 BigTable Coprocessor 也实现了自己的 Coprocessor

来提供 Region 级别的辅助索引，这个方案有全局的排序和数据的一致性难题未解

决。Lily HBase Indexing[51]也是列值作为行键的反向索引，但在不同数据类型的列

值作为行键时排序上设计很完善，不需要用户去自己设计行键，此外还提供了一

个辅助索引的管理框架。Facebook 消息应用服务器的消息和元数据等存储在 HBase

中，为加快查询，其辅助索引构建则利用自由表中行键，列名和时间戳都是有序

的特性将索引是存储到列中。

作为自由表另一个代表 Cassandra，也是本文选用的自由表，其自带的辅助索

引是哈希索引，要做范围查询表达式中必须有一个等值表达式。每个 Cassandra 节

点索引的数据只是本地的，并不会去索引其他机器上的数据，查询的时候是将查

询请求并发发到各个节点进行并行查询。内部实现时将数据和索引写放到

Commit-Log 的一行里，做到数据和索引更新操作原子性。鉴于哈希索引限制很大

且功能弱，无法做灵活的范围查询，也不适合索引的列的值大多数不同的场景，

本文第 5 章基于 Cassandra 自由表提出新的辅助索引的构建与管理方法。

2.3.2 辅助索引-数据存储

图 2.6 CCIndex 索引-数据布局示意

与辅助索引-行键存储不同，CCIndex[52]（Complemental Clustering Index）提出

另一种方式，索引和数据一起存储，这样返回结果即是数据，不需要利用返回的

行键再去源表进行随机读取。其实现方式是设定源表的数据备份数为 1，其冗余通

过与相关索引存储来达到。CCIndex 是基于行键有序的自由表上的多列组合索引，

支持自由表上的多列的范围查询。多列的范围查询有 And 和 Or 的逻辑关系，为优

化查询性能，需要对每个列查询的结果集大小的预估，以使整个查询操作性能最

好。CCIndex 评估各列的查询的结果集大小后，先在一个结果集最小的 CCIT 进行

查询，然后依据其他列查询对结果集进行过滤。

如图 2.6 所示，CCIndex 给每个列索引的列分配一个 ComplementalTable，里

面存有除了源表的行键之外的所有列，这个表的行键为 {<colum-value>，

<row-key>，<length-of-colum-value>}。这个行键的设计优势是保证了表里的行是

按照索引列值和源表行键排序。源表和索引表都叫 CCIT(Complemental Clustering

Index Table),CCIT 的备份因子设为 1 减少占用空间。CCIndex 通过维护其他的 CCIT

来保证某个 CCIT 的可用性，并提供 CCT（Complemental Check Table）来帮助 CCIT

数据恢复。图 2.6 中源表 CCIT0 有行键 id，weight 和 height 两列。CCIT-W 和 CCIT-H

分别是索引 weight 和 height 的索引表，按照 weight 和 height 进行排序的。CCT 则

存储了行键和索引的列，CCT 是备份的，CCIT 则没有备份。当某个 CCIT 数据丢

失时，可通过其他的 CCIT 和相应 CCT 进行数据的修复。

CCIndex 在建立源表的同时建立索引相关的 ComplementalTable 和 CCT，通过

往这些表插入和删除相应数据来维护索引。CCIndex 通过索引和数据一同存储提供

高性能，高可用和占用存储空间的小三大特性，在 HBase 和 Cassandra 都有相关应

用，获得性能的提升。但 CCIndex 也有如下缺点：

1. CCIndex 要求自由表底层的行键是有序的，HBase 本身行键就是有序，但是

Casssandra 是基于 DHT 环，默认是行键被哈希到个节点，所以不能保证有序。

如果需要 Cassandra 中的行键保证有序，需要 Keyspace 配置数据在环上的分布

策略（Partitioner）时使用 OrderPreservingPartitioner 才能保证行键有序。

Cassandra 官方是不建议这么做，因为使用这个策略集群不能自动负载均衡，

导致某节点可能会负载过重；

2. 索引的列限制在 2-4 列之间，少于 2 列的话 CCIT 备份不足，可用性降低；

多余 4 列的话会导致数据备份过多，因为每列都需要建立一个 CCIT，包括了

所有的数据，占用存储空间比一般的备份策略（3 个备份）多；

3. CCIndex 不支持建好表后添加或删除索引，因为对包含大量数据的 CCIT 进

行删除的代价过高；另外 CCIndex 的写性能和数据修复速度都比反向索引构建

的方式慢；

4. CCIndex 的机制决定其适合随机读慢，顺序读快的场景，比如 HBase，而

Cassandra 是为随机读优化的，顺序读不快。

基于以上这些问题 CCIndex 并不适合作为基于 Cassandra 的自由表辅助索引，

受到的限制过多。自由表上建立辅助索引因其分布式的场景带来很多的复杂性和

困难，所以自由表内部实现不像传统关系数据库带有功能很完善的索引机制。本

文则针对这些问题和大数据分析的应用场景，在第 5 章会研究和讨论另外一种基

于 Cassandra 的自由表辅助索引，突破了已有索引工作的众多限制。

2.4 本章小结

本章主要介绍了大数据分析平台研究现状和相关工作，主要包括大数据分析

平台的体系架构研究现状，基于自由表的面向对象数据模型和基于自由表的辅助

索引的研究现状。

本章第一部分介绍了和本文研究相关的大数据分析平台的架构，并且分析了

他们的不足之处。HadoopDB 和 epiC 都基于 Master-Slave 架构，虽与本文选择的

P2P 架构不同，但其中设计有可借鉴的地方。HadoopDB 利用 Hadoop 的 MapReduce

框架，将底层存储改用关系数据库来提升性能，本文则选用自由表作为底层存储。

HadoopDB 还将 Hive 的一些查询尽可能的向下推至底层，利用底层关系数据库进

行高性能的查询。epiC 在同时支持 OLTP 和 OLAP 上设计很精湛，利用基于负载

自适应的备份策略和主从备份机制很好的将 OLTP 和 OLAP 请求分开。本文则利

用了 Cassandra 的多数据中心提供的备份组来区分 OLTP 和 OLAP，没有使用主从

备份机制，相对来说要灵活。

本章第二部分介绍基于自由表的面向对象数据模型，为本文融合 Hive 和

Cassandra 做基础。为了能向上层应用提供 JDO 支持，需要在底层的自由表上去实

现相应的对象-关系映射和查询语言 JDOQL。

本章第三部分介绍基于自由表的辅助索引研究现状，目前包括两类索引构建

方式，一是索引和行键存储，二是索引和数据存储，相比较而言，前者比后者更

范式化（normalized）。本文第 5 章将在 Cassandra 的自由表上进行构建辅助索引，

根据分析对比，选择前者构建方式，即索引和行键存储。

第 3 章基于 Cassandra 的知云平台体系结构

第 3 章基于 Cassandra 的清华知云平台体系结构

本文研究是基于国家核高基科技重大专项——非结构化数据管理系统

LaUDMS（LaSQL Unstructured Data Management System），LaUDMS 是一个基于云

计算技术对海量非结构化数据进行统一管理的云数据管理平台，该平台基于无共

享架构、大规模和低成本的商用计算机集群，通过自主定义的 LaSQL 语言来统一

支持文本、图像、音频和视频等非结构化数据存取，并提供基于逻辑表达式、关

键词和样例的精确查询、模糊查询和相似查询等服务。总的来说，LaUDMS 提供

了一种统一管理大数据的解决方案。LaUDMS 的内核为清华知云 Kloud 平台，同

时支持海量数据的联机事务处理(OLTP)和联机分析处理(OLAP)，具有良好的伸

缩性、可靠性和可用性，后文简称为知云平台。本文实现的大数据分析平台则是

其中的 OLAP 部分。

3.1 知云平台体系架构

本文研究和实现的是 LaUDMS 的内核知云平台的 OLAP 部分，为明确本文的

工作在知云平台中的定位和实现的基础，首先介绍知云平台整体的层次架构和包

含的组件情况。如图 3.1 所示，知云平台的层次架构主要分为四层，从下往上依次

是：

特征数据收集、抽取和集成层。这层主要负责非结构化数据向底层的 ETL

（Extraction-Transformation-Loading）过程，对要存储到底层的非结构化数据

抽取相应的特征（结构化数据），并存到自由表中以便做扩展的检索和查询服

务。

数据存储和计算层。这层主要负责大数据的存储和计算服务，需要提供可扩

展性好，高可用的分布式存储系统。因为数据规模很大，对数据的处理也是需

要尽可能在多台机器上并行，所以要有一个分布式计算的框架。另外这层除了

直接存取文件，还需要有自由表来存取结构化数据。

数据查询处理层。这层则是针对用户传递过来的查询请求进行解析和优化，

提供类似 SQL 引擎的功能，然后调用底层适当的 API 完成相应的操作并返回

结果。

数据服务层。这层提供对外服务接口，对非结构化数据管理提供统一查询接

口。为此需要提供类 SQL 语言，Web 服务等多种方式让用户选择，除了 Java

外还需要考虑服务多语言的客户端，比如 C/C++, Python 等。这层具体提供跨

媒体查询，数据迁移，数据挖掘和分析等服务。

图 3.1 清华知云平台层次架构

除了这四层基础平台，还有跨越这四层基础平台的安全控制，系统管理工具和

大数据管理标准体系作为知云平台的支撑。知云平台的层次架构从应用需求的角

度介绍了知云平台具体需要做什么，通过分层设计将复杂的大数据统一管理方案

进行了以繁化简。下面从技术的角度介绍相关组件是如何完成这些应用需求的。

如图 3.2 所示，知云平台 Kloud 以分布式存储和计算服务为核心，周围环绕四大组

件，包括查询检索、分析挖掘、管理工具和安全控制。知云平台整个系统很庞大，

以组件组装的方式能有效的对功能模块进行解耦，上层应用可以根据需要选用相

关组件，以提供更灵活的定制功能。

知云平台的基础组件是底层存储和计算服务，其包含了基于 Cassandra 的分布

式文件系统，自由表存储和分布式计算系统，这个组件给知云平台带来的优势是

提供了完整的基于 P2P 去中心化可伸缩架构的基础平台。底层存储同时支持类似

Hadoop 的 HDFS 的文件系统访问和 NoSQL 的自由表（Key Value）读写访问，并

在其上构建了 MapReduce 框架运行环境。该组件对应知云平台层次架构的数据存

储和计算层，是知云平台的基础和核心组件，是系统必选的，为其他组件提供基

础服务。

图 3.2 清华知云平台组件示意图

安全控制组件则是对存储在知云平台的数据进行访问控制管理和版权管理，

这在多用户场景中保护用户隐私数据是有必要的。安全控制组件是可选的，对于

数据隐私安全不是很重要的情况可以不选用该组件。

管理工具组件包括监控工具，ETL 工具，调优工具和 DBA 管理工具，这些主

要面向知云平台的用户。知云平台是一个分布式集群，相对传统的关系数据库的

单节点来说更难管理。现在关系数据库一般都有可视化的管理工具，所以 LaUDMS

作为一个分布式的大数据管理方案，更需要用户友好的界面工具来简化相关操作，

方便用户的使用。管理工具组件对应知云平台层次架构的特征数据收集、抽取和

集成层和系统管理工具。

查询检索组件是对非结构化数据进行管理的核心功能组件，对应关系数据库

的查询功能，主要提供 OLTP 服务。该组件包括了高维索引，文本索引和柔性事务，

这些对查询检索操作的性能优化非常重要。分析挖掘是非结构化数据管理的另一

个核心功能组件，对应数据仓库的分析挖掘功能，主要提供 OLAP 服务。该组件

包括了数据挖掘，语义抽取和统计分析，这些对分析挖掘应用提供良好的支撑。

在传统数据库领域一般 OLAP 和 OLTP 是分开处理的，分别是关系数据库 RDBMS

处理 OLTP 和数据仓库处理 OLAP。为保证两个系统的数据一致，需要定期从关系

数据库 RDBMS 中导入数据到数据仓库中，导致维护成本较高。这在大数据领域

是不现实的，因为大数据的数据量级都是 TB 级以上，仅数据导入这个阶段就会耗

用很长时间，效率很低。知云平台利用基于 Cassandra 的多数据中心的备份组功能

同时支持 OLTP 的实时访问和 OLAP 的数据分析访问，所以这个问题在知云平台

上得以很好的解决。查询检索和分析挖掘两个组件对应知云平台层次架构的数据

查询处理层。

查询检索组件和分析挖掘组件的对外服务都可以通过类SQL的LaSQL引擎组

件提供，这个组件对应知云平台层次架构的数据服务层。LaUDMS 作为一个代替

关系数据库的大数据管理方案，有必要为熟悉关系数据库的 SQL 语言的用户提供

一个学习成本低的使用方式，LaSQL 引擎就是给用户提供这样一个类似使用 SQL

来访问 LaUDMS 的方式。用户书写类 SQL 语句然后传给 LaSQL 引擎，LaSQL 引

擎负责解析和优化，生成查询计划调用底层 API 进行处理。

通过对知云平台整个系统的层次架构和包含组件情况的介绍，现在可以明确

本文工作的定位。知云平台是 LaUDMS 的核心和基础，能同时支持 OLTP 和 OLAP

服务，本文所做的工作则是知云平台的 OLAP 部分，即支撑大数据的分析。第 2

章介绍的很多系统都有不足并且可以互补，知云平台正是结合这些系统的优点提

供的一种大数据处理基础平台。

知云平台的 P2P 体系架构如图 3.3 所示，整个架构是基于 Cassandra 的 P2P 去

中心化架构，利用 Cassandra 的多数据中心支持将系统分为两个备份组，一个是负

责 OLAP 的 MapReduce 作业分析（黄色标注节点），另一个是负责 OLTP 的实时

Key/Value 读写应用（灰色标注节点）。从图中可以看到，这两个备份组都是在一

个分布式哈希 DHT 环中，只是逻辑上分为两个组了。这样的好处是在一个集群中

作业分析和实时应用可以分布在不同的硬件资源上，避免了因为资源竞争而影响

性能，同时又能通过一定的备份策略将数据自动存储到相应的备份组中。

知云平台基于 Cassandra 的分布式哈希 DHT 环只是负责了数据在集群中的分

区（Partitioner），没有考虑备份的放置，在分布式系统中，为提供高可用性和负载

均衡，备份放置策略也是很关键的。Cassandra 有很多内置备份放置策略，知云平

台为同时支持 OLAP 和 OLTP 选用了 NetworkTopologyStrategy，该策略和多数据中

心配合后备份的放置非常灵活。备份在每个备份组的存放是独立的，即一个备份

存放在某个备份组的哪个节点的计算还是依赖分布式哈希技术，然后同一个备份

组其余的备份则存放到沿着 DHT 环顺时针的接下来的机器中，这个过程会优先存

放到不同的机架（Rack）中，此外可以设置每个备份组的存有备份的个数。具体

某个节点属于哪个备份组是可配置的，Cassandra 也提供了相关接口（Snitch）来控

制节点所在的备份组。知云平台为保证某个节点能灵活切换所在的备份组实现了

Snitch 接口，即能控制某个节点是属于 OLTP 服务备份组还是 OLAP 服务备份组。

图 3.3 知云平台的 P2P 体系架构图

图 3.3 中两个备份组的节点交替出现在 DHT 环中，这是为了通过设定相应节

点的 token 值来保证数据在每个备份组都能平均分布。知云平台的节点的 token 值

设定和单数据中心类似，考虑到每个备份组的节点数目不一定相同，需要分情况

讨论。如果两个备份组的节点个数相同可以先对一个备份组的节点生成相应的

token 值，然后另一个备份组的对应节点的 token 值则设置为当前备份组的节点的

token 值加 1。如果两个备份组的节点个数不相同则需要每个备份组分别计算节点

token 值后，调整相应 token 值使得在整个 DHT 环不相同且尽可能分布平均即可。

由此可见，知云平台利用 Cassandra 的备份组来很灵活的同时支持了 OLTP 服

务和OLAP服务。Cassandra的备份数目相关设置是在创建Keyspace的时候指定的，

可以根据应用需求设定每个备份组的备份数目。Cassandra 通过这些设置能将客户

端的请求路由的正确到节点，让用户的数据流向相应的备份组。知云平台正是在

这些技术基础上实现了融合文件和自由表的分布式存储以及在此之上的分布式计

算框架来支撑 OLAP 服务。

3.2 知云平台的分布式存储

大数据时代，数据的规模决定了需要一套分布式集群存储系统来存储大数据，

其中结构化的数据需要自由表来存储，非结构化的数据作为文件需要分布式文件

系统来存储。知云平台即是根据这样的需求在底层实现既支持自由表存储，又支

持类似 HDFS 大文件存储的分布式文件系统。

3.2.1 自由表存储

结构化的数据存储到自由表中，是因为自由表能对结构化数据能提供低延迟

随机访问。自由表的存储也可以说是 Key/Value 存储，是可扩展的和分布式的，能

支撑 TB 级规模以上的数据量。知云平台本身是基于 Cassandra 的，所以采用的就

直接是 Cassandra 的自由表存储。Cassandra 和其他自由表如 HBase 等相比，具有

高性能实时读写能力[53]，能直接对外提供 OLTP 服务。知云平台基于访问对延迟

的需求，在 Cassandra 上还实现了与 MegaStore[54]的事务类似的分布式柔性事务，

区别在于柔性事务能提供基于延迟的最优访问策略。图 3.3 所示的知云节点都可提

供自由表存储服务。

3.2.2 分布式文件系统

自由表存储除了直接提供低延迟的 Key/Value 读写访问外，由于灵活的格式，

经过一定的数据模型设计，也能支持复杂的数据格式。知云平台实现的文件系统

的存储就是基于自由表存储，只是在自由表上面设计一套数据模型来管理文件目

录的元数据信息。

目前对 Cassandra 的访问都是走 Thrift 接口，遗憾的是 Thrift 不支持流的访问，

所以知云文件系统把大文件存到 Cassandra 中时，需要进行切块传输，然后存储到

自由表中的多个列中。为和其他自由表区分，知云平台创建了一个专门的 Keyspace

来存储文件，包括了两个列族，其中一个是记录文件块的元数据信息，如名字，

大小，块信息和目录结构信息等，另一个则专门存储文件块的数据。如图 3.4 所示，

对文件的元数据信息访问时访问列族 file_metadata 即可，每个文件或目录作为一

行，其中文件的列包括文件名，大小和文件块的 ID 等，这些 ID 对应另一个列族

file_data 的行键；目录的列包括目录名，文件数和文件 ID 等，这些 ID 对应本列族

的行键。如果要对文件数据访问，则先去列族 file_metadata 获取文件块 ID，然后

从列族 file_data 获取真正的数据。这种数据模型一个优势是一个文件的块可以分

布在集群不同的机器上，能有效保证负载均衡。

图 3.4 知云文件系统数据模型

Hadoop 底层的文件系统可以是第三方实现，只要该文件系统实现 Hadoop 定

义的 FileSystem 接口，知云平台为支持 MapReduce 计算，故选择实现这个接口作

为底层的分布式文件系统。知云平台基于图 3.4 的数据模型实现了 Hadoop 的

FileSystem 类接口，这样底层能完全兼容类似 HDFS 的访问。知云平台实现的这个

文件系统还遵守 HDFS 设计的原则，即适合一次写多次读的场景。另外由于移动

数据成本比移动计算大，所以在计算时知云文件系统也能提供数据位置感知等保

证计算能在本地完成，为 MapReduce 的高效执行提供了基础。

知云分布式文件系统实现基于 Cassandra，所以也是 P2P 去中心化的，没有单

点问题，更重要的是没有 Namenode 和 Datanode 这些复杂的角色，不需要额外的

部署工作。如果集群需要同时提供 OLAP 和 OLTP 服务，则专门为知云文件系统

创建的Keyspace只在用于MapReduce作业分析的备份组上设定备份数目为大于或

等于 1，其他备份组都为 0，如图 3.3 所示分布式文件系统（以文件块代表）部署

在 MapReduce 作业分析的备份组的上。

3.3 知云平台的分布式计算框架

知云平台目前的分布式计算框架是 Hadoop 实现的 MapReduce，本文以后提到

的 MapReduce 如无特别说明都是指 Hadoop 的实现版本。实际上 Cassandra 本身也

是能直接用 Hadoop 的 MapReduce 进行分析的，因为它内部实现了 Hadoop 的

InputFormat 和 OutputFormat 接口，这样 MapReduce 可以直接读写 Cassandra 中表

的数据，但是这么做还需要部署一套 Hadoop 集群，部署和管理都很复杂。另外知

云平台提供了完全兼容 HDFS 的底层文件系统，所以 Hadoop 的 MapReduce 也能

直接在知云平台上跑，但是需要额外去启动 JobTracker 和 TaskTacker 进程。

为了能减少对 Hadoop 的部署依赖，知云平台把 MapReduce 的 JobTracker 和

TaskTracker 也移植到知云节点中。这样做只需要部署一套集群即可，而且

JobTracker 和 TaskTracker 的启动也内置到知云节点中，使用非常方便。除了部署

简单外，这样设计还能利用 Cassandra 的 P2P 架构使得 JobTracker 可以随意切换，

这样 JobTracker 的故障影响减少到最小。由此可看出，知云平台的分布式计算框

架的特性就是让 MapReduce 能非常容易的运行在 P2P 的底层架构上。

3.3.1 JobTrakcer 和 TaskTracker 运行在 Cassandra 上

Hadoop 的 MapReduce 框架和 HDFS 类似也是 Master-Slave 模式，其中

JobTracker 为 Master，可以有多个 TaskTracker 作为 Slave。图 2.1 显示的 HadoopDB

架构中描述了 JobTracker 和多个 TaskTracker 之间的主从关系，图 3.5 则描述了

MapReduce 作业在 JobTracker 和 TaskTracker 之间的运行流程。用户只需要按照

MapReduce 框架规范实现好自定义的 Map 函数和 Reduce 函数，然后向集群提交该

作业，集群会自动将其调度到多台机器上去并行的计算完成并返回结果。这大大

降低了用户使用分布式计算的难度。

图 3.5 MapReduce 作业运行流程

分布式计算与存储不一样，负责作业调度的 JobTracker 在知云系统中同一时

刻只能有一个，不能像存储那样做到完全 P2P，但还是能受益于知云的 P2P 架构。

Hadoop 的 MapReduce 框架的 JobTracker 地址是由配置文件 mapred-site.xml 中

mapred.job.tracker 属性值决定，MapReduce 启动之后不能更改，JobTracker 和

TaskTracker 的角色也固定了。如果要切换 JobTracker 节点，需要修改

mapred-site.xml 中的 mapred.job.tracker 属性值，并同步到所有节点，然后重启所有

的 JobTracker 和 TaskTracker，这在大的集群里代价还是很大的。

知云则将 JobTracker 和 TaskTracker 视为线程，可以跑在任意的知云节点上。

图 3.3 显示了知云节点运行的服务线程，负责实时访问应用的节点只运行了

Cassandra 线程；负责 MapReduce 作业分析的节点则还额外运行了 JobTracker 线程

或者 TaskTracker 线程，其中 TaskTracker 线程运行在每个分析的节点上，JobTracker

线程则只运行在一个节点上。运行 JobTracker 的节点和运行 TaskTracker 的节点之

间只是组成临时的作业调度主从关系，因为 JobTracker 可以移到任意其他节点上。

为了做到 JobTracker 地址的动态性，知云将 JobTracker 节点的地址和端口存入

Cassandra 的自由表中，而不是在 MapReduce 配置文件 mapred-site.xml 中设定静态

的地址和端口。JobTracker 的节点切换只需要修改 Cassandra 自由表中 JobTracker

地址的值，知云的后台会定期检测该值，一旦发现改变负责作业分析的知云节点

时会将自由表中新的 JobTracker 的地址和端口设为 mapred-site.xml 中的

mapred.job.tracker 属性值然后启动新的 JobTracker 和 TaskTracker 线程。

知云平台通过基于 P2P 架构的底层存储，使得 MapReduce 的运行因为

JobTracker 可以在知云节点之间随意动态切换而更健壮。MapReduce 框架中

TaskTracker 节点是多个的，它们之间可以互相备份，只有 JobTracker 节点是一个，

其发生故障会影响 MapReduce 的运行，所以 JobTracker 能动态切换大大减少了其

故障对作业运行的影响。

另一方面，由于知云平台所有节点都一样，数据分布在所有节点上，所以所

有节点都能参与作业的执行和分析，并不需要设定特定的 Master 节点（如

Namenode 或 JobTracker 等，在 Hadoop 中这些节点一般不存数据），这样对于相同

规模集群，和 Hadoop 相比多了一个计算节点。

以上表明与 Hadoop 上的 MapReduce 框架相比，知云平台进一步降低了框架

的维护和使用难度，相同规模集群提供更多的计算节点并提高了可靠性。

3.3.2 知云平台节点 OLAP 和 OLTP 服务的配置和切换

知云平台节点属于作业分析节点还是实时服务节点是可配置的，在节点启动

的时候设定相关参数即可。如果指定的参数是作业分析，则相应的节点启动

Cassandra 进程时同时启动相应的 JobTracker 和 TaskTracker 线程，否则只启动

Cassanra 进程。

要切换一个节点的角色只需要重启的时候设定相应参数即可，另外得益于底

层 P2P 架构，如图 3.3 中 6 个节点的工作角色都是可以互相切换的。这种节点角色

的切换对于集群中的工作负载调度和资源分配非常有用，比如可以在集群对外服

务忙到时候让更多节点作为 OLTP 服务节点提供在线实时服务，而在集群空闲的时

候则可以让更多节点作为 OLAP 服务节点提供离线分析服务。这种灵活性是知云

平台一个重要的优势。

3.4 本章小结

本章介绍了基于 Cassandra 的知云平台体系架构，明确本文工作在国家核高基

科技重大专项——非结构化数据管理系统中的定位。本章首先描述了 LaUDMS 是

一种统一管理大数据的完整的解决方案，并确定其内核是知云平台。通过解读知

云平台的层次架构和包含的组件情况，具体介绍了知云平台的 P2P 体系架构和底

层构件。知云平台基于 Cassandra 的 P2P 去中心化可伸缩架构，底层构件包括同时

支持分布式文件系统和自由表的分布式存储以及分布式计算框架 MapReduce。知

云平台基于这些底层构件向上层提供 OLTP 和 OLAP 基础服务，本文工作即是其

中 OLAP 部分。

第 4 章知云中的大数据分析平台研究和实现

第 4 章知云中的大数据分析平台实现

前一章介绍了知云平台的体系架构，知云向上层提供基于 P2P 可伸缩架构的分

布式存储和分布式计算框架，能同时支持 OLTP 和 OLAP 服务。其中 OLTP 的服务

已经由 Cassandra 本身的实时性，灵活的一致性级别和针对访问延迟的柔性事务体

现，OLAP 服务则还没有较好的体现。虽然知云已有 MapReduce 运行框架支撑作

业分析，但是对上层来说还是过于复杂，尤其对复杂作业分析使用不方便。本章

在知云现有基础上进一步针对大数据的分析进行扩展，构建基于 P2P 可伸缩架构

的大数据分析平台，以体现知云的 OLAP 服务。

为简化对大数据分析的工作，商业界和开源界都在分布式存储和计算框架上提

供更抽象简单的类似 SQL 语言的访问，如 Google 的 Sawzall[55]，Yahoo 的 Pig[56]，

Microsoft 的 SCOPE[57]/DryadLINQ[58]和 Facebook 的 Hive 等，其中 Pig 和 Hive 现在

都是 Hadoop 生态系统的一部分。知云底层接口完全能够兼容 Hadoop，所以 Pig

和 Hive 可以直接在知云平台上运行。Pig 提供的是语言是 Pig Latin，和 SQL 语言

较大不同，更像是脚本语言，而 Hive 提供的语言 HiveQL 则和 SQL 非常类似，其

余两者作用差不多，基于这点本文选择 Hive 作为知云上的大数据分析工具。本章

结合知云平台底层的支持，将 Hive 融合到 Cassandra 中，实现基于 P2P 可伸缩架

构的大数据分析平台。

4.1 Hive 与 Cassandra 融合组件分析

Hive 是 Facebook 贡献的一个基于 Hadoop 的数据仓库分析平台，主要负责将

用户输入的 HiveQL 语句翻译成 MapReduce 作业进行相关的分析，这样原来使用

传统关系数据库的用户现在也很容易在 Hadoop 上处理大数据的分析。如图 4.1 所

示， Hive 是构建在 Hadoop 之上的，本质上可以看成是 Hadoop 的一个客户端，

包含如下三个组件：

用户接口。Hive 用户接口包括 CLI（Command Line Interface 命令行），Web

界面和 JDBC/ODBC。其中 CLI 和 Web 界面是交互操作接口，面向的是最终用

户，而且每次使用 CLI 都会启动一个 Hive 副本，Web 界面则需要某节点启动

Hive Web 服务器才可通过浏览器访问，这都不适合上层应用。JDBC/ODBC 可

以面向上层应用，但是需要在某节点启动 Hive Thrift Server，然后客户端连接

至该节点。

图 4.1 Hive 体系架构

元数据库 Metastore。Hive 为支持类似 SQL 的查询，对存储在底层的数据

组织方式进行建模，并将模型的元数据信息存储在关系数据库中，如 Mysql

和 Derby 等。这些元数据包括表的名字，列信息，分区（Partition）及其属性，

桶（Bucket）和表的数据所在目录等。Hive 为描述元数据的表的关系，设计了

共有 20 多张表格，这些表及其之间的关系存放到关系数据库中以便查询。

查询计划生成器 Driver。这个组件是 Hive 的核心，包括对 HiveQL 的编译、

优化和执行，其中生成的查询计划（任务的有向无环图 DAG）会序列化成

plan.xml 存储在 HDFS 中，然后运行 MapReduce 作业时相关任务会读取

plan.xml 按照依赖顺序执行。

图 4.2 显示了 Hive 组件与 Hadoop 的交互示意，可以看到 Hive 先将 HiveQL 语

句翻译成查询计划，然后提交到 Hadoop 中执行该计划。执行过程主要是启动相关

MapReduce 作业，然后并行的对存储在布式文件系统 HDFS 上的数据反序列化并

进行查询处理，最后返回相应的结果。

通过上面对 Hive 的组件分析得知，Hive 只是建立在 Hadoop 之上的一个客户

端，并没有和 Hadoop 集群一起绑定，导致使用 Hive 还需要进行额外的配置，对

上层应用支持也不方便。另外 Hive 能支持上层应用的用户接口的 JDBC/ODBC 使

用还需要启动一个节点来提供服务，而这给系统引入了单点问题。本文则基于 Hive

的这些缺点将 Hive 与 Cassandra 融合，成为知云平台服务大数据分析的工具，以

构造基于 P2P 可伸缩架构的大数据分析平台。如图 4.3 所示，本文在知云平台基础

上将 Hive 服务嵌入到每个知云的节点上，整个系统还是 P2P 的架构，没有引入新

的单点故障。

图 4.2 Hive 组件与 Hadoop 交互示意

图 4.3 知云大数据分析平台 P2P 体系架构

Hive 的三个组件中除了用户接口外都是可移植到底层的，和底层其他服务一

起统一对外提供服务，大大方便用户的使用。本文将 Hive 与 Cassandra 融合的基

本思想有两个，一是 Cassandra 内部已经有一个类 SQL 的查询引擎 CQL（Cassandra

Query Language），其主要提供 OLTP 服务，所以 Hive 的查询计划生成器 Driver 很

容易融合进来对外提供 OLAP 服务；二是 Cassandra 的自由表提供低延迟访问，能

很好的存储 Hive 的元数据，并且带来了自动备份的功能。

4.1.1 Cassandra CQL 引擎和 Hive Driver 引擎的融合

图 4.4 Cassandra 内部组件层次架构

如图 4.4 所示，Cassandra 内部组件层次架构很清晰，主要分两大功能组件，一

是负责集群分布式的协调管理，如数据分区，备份和容错等；二是单节点的管理，

如服务客户端的读写请求，数据的可靠存储等，CQL 引擎则在这个组件上。由于

整个 Cassandra 集群都是 P2P 架构的，每个节点都一样，所以只要针对单节点修改

即可。另一方面，知云本身是基于 Cassandra 实现的分布式存储和分布式计算框架，

可以支持 Hive 的执行，所以 Hive Driver 引擎实现到 Cassandra 节点上作为知云的

一部分也是合理的。

通过对 CQL 引擎和 Hive Driver 引擎各自的实现分析，在 Cassandra 节点内部

融合这两个引擎，需要统一管理这两个引擎的调度。知云上面的 LaSQL 引擎则是

完成这样的工作，在 Cassandra 节点上实现了同时支持 CQL 和 HiveQL 的查询，并

扩展了其他查询操作。知云通过 LaSQL引擎的统一接口对外提供了 OLTP 和 OLAP

服务，对用户来说通过一个客户端就既然完成实时应用访问，又能对大数据进行

分析，这带来很大的方便。

4.1.2 Hive 元数据存储到 Cassandra 自由表中

Hive 默认是将元数据存储在关系数据库而不是 HDFS 中，是因为 Hive 需要低

延迟访问元数据信息，并且可进行复杂的查询，而这些在 HDFS 中是做不到的。

另外这些元数据很关键，为保证高可用性，需要多个备份，这个在关系数据库不

太方便做到。知云平台基于的 Cassandra 自由表则能同时满足低延迟访问和自动备

份，所以 Hive 的元数据存入 Cassandra 自由表中很合理，只不过需要本文做一定

的工作。

Hive 元数据的表及其之间的关系多而复杂，由于自由表的数据模型和关系数

据库的数据模型不一样，为了能将这些存储到自由表中以便方便的查询，有必要

理解其中的语义信息。如图 4.5 描述了 Hive 的数据存储模型。

图 4.5 Hive 数据存储模型

Hive 的数据存储模型的粒度从大到小包括：Database，Table，Partition 和

Bucket， HDFS 上与这些模型对应的数据都存储在配置文件 hive-site.xml 中

hive.metastore.warehouse.dir 属性指定的数据仓库的目录下面，默认为

/user/hive/warehouse 为方便后面表示简记为 WHDIR。下面具体介绍各模型在 Hive

中的相关语义：

Database 提供一个名字空间，和关系数据库的数据库概念类似，下面包含若

干表格，这可防止表名之间的冲突。Database 在 Hive 中对应 WHDIR 下的一

个目录，Hive 默认的 Database 为 default，所以不指定数据库的话，创建的表

的数据都会放到这个目录下。

Table 概念上也是和数据库中的 Table 类似，在 Hive 中对应 WHDIR/DB 下

的一个目录，其中 DB 目录代表这个表所属的数据库，所有的 Table 数据都保

存在这个目录中。另外 Hive 存在特殊的表 External Table，该表指向在 HDFS

或其他存储系统中已经存在的数据，和 Table 在元数据的组织上是相同的，

而只是实际数据的存储不同。删除 Table 时，Table 中的数据和元数据将会被同

时删除，而删除一个 External Table 时，仅删除元数据。

Partition 是 Hive 组织一个表的数据的方式，对应 Table 下的一个目录。通过

对 Table 粒度的细分能对大表的分析更有效，因为很多场景可能只需要分析大

表的一部分。Partition 的划分是递归的，即 Partition 下面还可以包含子 Partition，

这个跟应用需求有关，用户设计的时候可参考分析的需求确定分析的粒度。另

外 Partition 的命名方式是“part_col_name=part_val”，可用于条件查询过滤。

Bucket 对 Table 某列进行哈希，然后根据哈希值切分数据，目的是为了将一个

大文件切分成小文件，然后并行去分析。Bucket 在 Hive 中对应 Table 或 Partition

下的一个文件。Bucket 本质上和 Partition 一样将大表数据细分，以更有效的对

大数据进行分析，但是 Bucket 另一个作用对数据进行抽样。

表 4.1 Hive 0.8.1 数据模型对应的 Java 类

类名依赖关系映射

MDatabase 无依赖，无需映射关系

MTable 依赖 MDatabase 等，需映射关系

MPartition 依赖 MTable 等，需映射关系

MStorageDescriptor 依赖 MColumnDescriptor 等，需映射关系

MSerDeInfo 无依赖，无需映射关系

MType 依赖 MFieldSchema 等，需映射关系

MOrder 无依赖，无需映射关系

MFieldSchema 无依赖，无需映射关系

MPartitionEvent 无依赖，无需映射关系

MColumnDescriptor 依赖 MFieldSchema，需映射关系

MIndex 依赖 MTable 等，需映射关系

MRole 无依赖，无需映射关系

MRoleMap 依赖 MRole，需映射关系

MGlobalPrivilege 无依赖，无需映射关系

MDBPrivilege 依赖 MDatabase，需映射关系

MTablePrivilege 依赖 MTable，需映射关系

MTableColumnPrivilege 依赖 MTable，需映射关系

MPartitionPrivilege 依赖 MPartition，需映射关系

MPartitionColumnPrivilege 依赖 MPartition，需映射关系

Hive基于这些存储模型对存储在HDFS上的结构化数据进行了关系模型建模，

然后利用类似 SQL 的语言 HiveQL 来进行复杂的查询。为支持表中的列的多种数

据类型和对数据序列化反序列化操作，Hive 还提供了丰富的数据类型支持和数据

序列化反序列化的类库。这些都作为被 Hive 作为元数据存储在关系数据库中，Hive

持久化时采用 JDO 的规范，并设计了相关的 Java 类。在 Hive 0.8.1（本文实现时

采用的版本）的实现中，元数据模型包括的类如表 4.1 所示。

表 4.1 还显示了持久化 Hive 的元数据时是否需要映射依赖关系，从中可以看

到，大部分对象持久化时都需要将依赖关系存储，这些对象-关系映射在关系数据

库都已有成熟的框架来完成，Hive 使用的便是 DataNucleus 实现的类库来将这些

Java 对象持久化到关系数据库。本文则要将这些对象-关系映射到 Cassandra 的自

由表中，并能被基于条件进行灵活的查询，然后替代 Hive 自带的基于关系数据库

的实现。要实现这个目标需要做两个工作，一是设计基于自由表的面向对象数据

模型，即将对象-关系映射到自由表中；二是基于这个模型实现相关的查询以替代

Hive 自带的元数据库的实现。Hive 是支持第三方的元数据库的实现的，只需要在

配置文件hive-site.xml中的属性hive.metastore.rawstore.impl设为第三方实现的类即

可。

4.2 基于 Cassandra 自由表的面向对象数据模型

本文在 2.2 节中介绍了基于自由表的面向对象数据模型的研究现状，其中提到

如果可以在自由表上实现对象-关系的映射，用户就不需要去理解底层的自由表数

据模型，能像使用关系数据库一样使用扩展性好的自由表存储。本节则详细描述

对象-关系在 Cassandra 自由表上的映射以及相关的查询 JDOQL 实现。

4.2.1 对象-关系在自由表数据模型上的映射

对象-关系映射 ORM 是面向对象的类和关系数据库的表之间映射的机制，本文

则将面向对象的类映射到自由表上，从概念上来说类到关系数据库以及自由表的

映射关系如表 4.2 所示。其中面向对象的类映射为自由表的列族，类的实体对象映

射为自由表的一行，对象标识符映射为自由表的行键，对象的属性则映射为自由

表的列。

表 4.2 这种映射是基础的映射，也很直观，但由于对象的属性可能是其他对象

的引用，即有依赖关系，现在的问题是如何把对象之间的引用关系能通过这种映

射体现。文献[59]介绍了要将 Java 对象及其之间关系映射到关系数据库中需要解决

继承映射和关系映射两个问题，另外由于自由表没有像关系数据库一样自动产生

主键，所以本文还需解决主键映射问题。

表 4.2 对象-关系到自由表的概念映射

面向对象概念关系数据库概念自由表概念

类表列族（Column Family）

对象记录行

对象标识符主键行键

属性字段列

为能够清楚描述对象-关系到自由表的映射，下面描述的时候会列举典型的实

例，实例中带有的图左边是 UML 类图关系，右边是自由表中的列族里的数据示例。

4.2.1.1 主键映射

很多情况下 Java 对象会依赖数据库自动产生主键，所以类属性里不会有主键，

但是自由表由于其分布式特性，没有提供自动产生全局唯一的主键的功能，所以

需要客户端产生主键。因此，本文要求持久化的类里需要一个 ID 属性来标识该对

象全局唯一，并将其映射为自由表的行键。

4.2.1.2 继承映射

继承是面向对象的一种重要特征，子类会自动继承父类的属性，所以持久化对

象时需要考虑这种关系以防信息丢失。根据面向对象的继承体系，可能会有接口，

抽象类和实体类三种类型，但是前两者无法实例化，也即不需持久化，所以继承

映射只考虑实体类。对于实体类，本文依据目前关系数据库常用继承映射方案，

将其应用在自由表上有以下三种方式：

1. 每个实体类映射到自由表的一个列族，并且每个子类对应的列族重复包含其所

有层级的父类的属性，如图 4.6 所示，类 Manager 继承 Worker，分别映射到自

由表上的两个列族，并且子类将从父类继承的属性也映射到自己的列族里。这

种方式的优点是父子类分开存储，访问单个对象的性能高，缺点是父类修改后，

不仅需要修改该类对应的列族，也要修改每个子类对应的列族，所以适合类型

之间属性重叠少并且很少修改的情形。

2. 每个实体类映射到自由表的一个列族，但是子类从父类继承的属性不重复映射

到自己的列族里，而是保证属于一个继承体系中的每个列族对于同一对象包含

相同的行键。这样当需要取得子类对象数据时，需要访问其所有层级的父类对

应的列族。如图 4.7 所示，Manager 类映射到自由表的列族时保证了行键和父

类映射的一致，而没有将 Worker 类的属性重复映射。这种方式的优点是可以

减少第一种方式中的数据的冗余，且父类修改不影响其子类，缺点是读取一次

数据需要访问多个列族，所以适合类型之间属性重叠多且修改频繁的情形，和

方式一互补。

图 4.6 每个实体类完整映射到自由表的一个列族

图 4.7 每个实体类部分映射到自由表的一个列族

图 4.8 一个继承体系映射到自由表的一个列族

3. 每个继承体系映射到自由表的一个列族，列族的每行包含的属性完整，并且还

添加一个额外的用以标识该行代表的被持久化的实体类类型的列。如图 4.8 所

示，Worker 类和 Manager 类都映射到 Worker 列族，每行对应的数据完整，且

加了 discriminator 列来代表其持久化的类型。这种方式的优点是映射简单，新

加一个类只需添加相应的行并要修改 discriminator 属性即可，无需添加新的列

族，此外只有一个列族所以数据访问速度也快，缺点是数据冗余。这种方式在

关系数据库里可能会导致表过大，但是这在自由表里不是问题，所以本文综合

比较三种方式也是优先选择这种方式。

从以上分析可以知道，三种继承映射的实现方式各有优缺点，需要根据具体应

用确定使用哪种方式最好。实际上以上三种方式都不是完美的，也不是互相排斥，

有时可以根据应用需求混合使用这三种继承映射方式。

4.2.1.3 关系映射

封装是面向对象的是另一大特征，即将数据和方法封装到类里，只暴露访问

接口，然后被作为其他类的属性引用。这种情况就会产生类之间的依赖关系，所

以持久化对象时需保证其包含的被引用对象也能正确的持久化以避免信息丢失。

表 4.3 容器类数据到自由表的映射

容器类型映射方式映射格式

Collection（List，Set 等）容器里每个对象映射为对应列

族的一列，列名为容器名字和

容器里每个对象的 ID 值的组

合，列值为空

{<collection-name>，<object-ID>} : <null>

Map（HashMap 等）容器里每个对象映射为对应列

容器里的 Key 对应的 ID 值的

组合，列值为 Value 对应的 ID值

{<map-name>，<map-key-ID>} : <map-value-ID>

Array（Object[]等）容器里每个对象映射为对应列

容器里对象的索引位置的组

合，列值为该对象的 ID 值

{<array-name>，<index of object>} : <object-ID>

对象之间的引用关系是有数量约束和方向性的，其中数量约束有一对一关系，

一对多（多对一）关系和多对多关系；方向性包括单向关系和双向关系。这些关

系在关系数据库中是由外键来维护的。由于自由表中没有外键这一机制，本文在

自由表持久化这些关系时采用在自由表的列中保存这些引用对应的对象 ID 的方

式，所以只需关注被引用的对象在引用对象中的数量关系，而引用关系的方向性

在这种持久化方式下无需考虑。依据这种方式，关系映射在自由表中具体只包括

如下两种情形：

1. 一对一关系或多对一关系。这种情形是被引用对象数量都为 1，本文映射时将

该引用对应的属性名字做为列名，引用对象的 ID 作为列的值，该值根据主键

映射就是相应的行键。如图 4.9 所示，Student 类含有对 Teacher 类的一个引用，

则在其列族加了相应的列 teacher，值为 Teacher 列族对应的行键。

图 4.9 多对一关系在自由表上映射示意

图 4.10 一对多关系在自由表上映射示意

2. 一对多关系或多对多关系。这种情形是被引用对象数量大于 1，面向对象领域

里一般会用容器类来实现，共有三类容器，分别是 Collection，Map 和 Array。本

文针对这三类容器的数据在自由表上进行如表 4.3 所示的方式映射，装有被引用对

象的容器本身是对象的一个属性，所以里面的每个对象都映射到相应的列里，另

外和多对一关系类似，映射相关对象时都是使用对象 ID 的值。如图 4.10 所示，

Teacher 类有一个 Collection 类型的属性 students，里面装有多个 Student 类的对象，

是典型的一对多关系，Teacher 列族有 Collection 属性的映射，每列名字都是

students-<student-id>，列值为空。

4.2.2 实现基于 Cassandra 自由表的面向对象数据模型

前一小节主要关注对象-关系在自由表上的映射，没有说明如何在已有的映射

模型下进行查询。本节则基于 Cassandra 自由表对前一小节介绍的对象-关系映射

进行实现，并实现相应的查询，以能完全将 Hive 的元数据库从关系数据库移植到

Cassandra 自由表中。Hive 的元数据库持久化实现是基于 DataNuclueus 的框架，为

保持一致，本文也是基于 DataNuclueus 的框架实现。

DataNuclueus 是一个支持 JDO/JPA 规范的通用的框架，采用插件式的架构，

其底层存储可以是 XML 文件、关系数据库或者自由表等，其主要作用就是提供通

用的数据访问层，让底层对上层应用是透明的，即上层应用代码不用修改即可使

用不同的底层存储。如图 4.11 所示，DataNucleus 已有很多底层存储的实现，包括

RDBMS，MongoDB，HBase 和 BigTable 等，这些实现对于本文实现基于 Cassandra

自由表的底层存储都有参考价值。

DataNucleus 为了能做到底层存储以插件式提供，内部定义了一套自定义实现

底层存储插件的接口，能同时支持 JDO/JPA 规范。由于 Hive 的元数据库使用的就

是 DataNucleus 自带实现的关系数据库存储插件，并且使用的是 JDO 规范，所以

本文如果按照 DataNucleus 的底层存储插件提供的 JDO 规范去实现基于 Cassandra

自由表的底层存储，理论上就可以直接替换 Hive 的元数据库依赖的关系数据库存

储。

图 4.11 Datanucleus 平台架构

根据 DataNucleus 底层存储插件的接口，需要实现存储管理，连接管理和

JDOQL 语言查询等功能，下面介绍各功能的实现要点：

存储管理。主要包括持久化，读取和删除对象及其之间的关系，即实现 4.2.1

节描述的对象关系-映射及相应的读写操作，这些都是使用 Cassandra API 即可

实现。由于自由表存储 Key/Value 时数据类型默认都是 Byte 数组，所以本文还

实现了各种数据类型到 Byte 数组的序列化和反序列化操作。另外这里和关系

数据库不一样的地方是访问数据的一致性的控制，Cassandra 提供多种级别的

一致性，为了保证数据能有强一致性，目前默认实现时采用了

ConsistencyLevel.QUORUM。

连接管理。负责应用到底层存储的连接，由于底层是 Cassandra 集群，为高

效连接集群，本文实现了连接 Cassandra 集群的连接池。另外从连接池获取连

接时考虑了集群某节点宕机的情况，遇到这种情况系统会自动找下一个可用的

连接，这保证系统的健壮性。

JDOQL 语言查询。底层存储为支持上层应用的复杂的表达式查询请求，还

需要实现 JDOQL 语言。JDOQL 是面向 JDO 规范的查询语言，和 SQL 对比使

用很类似，但是和对象特性结合更紧密，比如查询时能直接用对象属性或者方

法等。Hive 实现元数据库的查询时就使用了 JDOQL 语言，带来的好处是底层

对 Hive 来说是透明的，换用其他支持 JDOQL 查询的底层存储 Hive 代码可以

不用修改。根据 DataNucleus 提供的接口，实现 JDOQL 查询实现时需要底层

存储提供基于某列条件的查询。通过 2.3 节的介绍可知，为高效查询必须底层

有辅助索引的帮助。本文第 5 章实现的基于 Cassandra 辅助索引则被用于

JDOQL 语言查询实现。

本文按照 DataNucleus 规范实现了基于 Cassandra 自由表的面向对象数据模型

存储后，将其替换为 Hive 的元数据库存储，即完成 Cassandra 和 Hive 的融合。

4.3 知云平台和 Hive 的结合

知云平台是基于 Cassandra 构建的，提供了基于 P2P 可伸缩架构的分布式文件

系统和自由表存储，并在上面提供 MapReduce 分布式计算框架。现在 Hive 和

Cassandra 也进行融合后，知云平台和 Hive 也就自然结合在一起，这个结合能带来

两大优势，一是提供了易用的大数据分析平台，二是可直接用于分析的大数据格

式更多样化了。

4.3.1 易用的大数据分析平台

Hive 对大数据分析的强大功能现在就直接作为知云平台的一部分了，实现了

本文提出的基于 P2P 可伸缩架构的大数据分析平台。

从服务端来说，现在部署大数据分析平台不需要先去了解 Hadoop 系统的众多

模块角色，然后进行一系列繁杂的部署步骤，只需要像部署 Cassandra 集群一样简

单的在每个节点上启动 Cassandra 即可。整个平台都是 P2P 架构，也不用担心有单

点问题。知云平台同时支持 OLTP 和 OLAP 服务，数据都存储在 Cassandra 上集群

上，数据无需经过导入导出过程即可分析。

从客户端来说，现在不需要去依赖 Hive 运行环境了，使用轻量级 LaSQL 客户

端即可完成原先 Hive 能做的任何事情。

4.3.2 可分析的大数据格式多样化

最初 Hive 只能分析 Hadoop 上的结构化文件，后来提供扩展可分析其他存储

系统上的数据，但这些都需要不同的集群部署，且无法使用计算的本地性优势。

知云平台提供的底层存储包括分布式文件系统和自由表存储，能存储任意的大数

据格式，这对于具有复杂的格式的非结构化数据存储来说非常适合。另外这数据

存储都基于 Cassandra 存储集群，计算本地性优势突出。现在不仅可以分析基于文件的数据，也能直接分析自由表的结构化数据，针

对数据格式多样化选择不同存储带来的可优化空间也多了。由于大数据分析很多

都基于 MapReduce 分布式计算框架，所以对大数据分析优化一般都集中到

MapReduce 流程的优化[60-64]。本文构建的大数据分析平台基于自由表的底层存储，

所以对底层存储访问优化也是对大数据分析优化的另一种方式[65-67]。HadoopDB 就

是尽量的把查询放到关系数据库去做以提高分析性能，但是这些查询语句有限，

而且关系数据库的行存储模式相对自由的列存储模式更不适合进行数据分析。本

文第 5 章介绍的基于自由表的辅助索引就是对自由表存储的结构化数据的分析的

优化方式之一。

4.4 实验结果与分析

本章实验目的为验证本章介绍的基于 P2P 可伸缩架构的大数据分析平台的可

行性及带来的性能影响。当前知云中的大数据分析平台实现基于 Cassandra 1.0.7，

Hadoop-0.20.2-cdh3u3，和 Hive 0.8.1，运行数据分析时知云节点都配置为 OLAP 服

务节点。本章实验测试内容主要是对用户访问日志数据的 uv 区间统计，这里的 uv

即 Unique Visitor（独立访客），指一个客户端对应一个访客，uv 区间统计则是指在

相同的客户端只被计算一次的情况下对指定的某时间区间内的访客数统计。这种

查询在用户日志分析中经常使用，如果能通过简单输入类似 SQL 语言的语句就可

完成，那用户就不需要去了解 MapReduce 如何编程，大大方便了普通用户的使用。

4.4.1 实验环境

硬件

表 4.4 实验的硬件环境

硬件参数参数值

节点个数 5

CPU Intel E5620 (2.40GHz/4 核/12MB/80W)，2颗 CPU

内存 4*8G=32G

硬盘 12*1TB 3Gbps SATA 7.2K 第一块盘作为操

作系统，其它盘作为数据盘网络双网卡绑定方式，千兆网口，在一个接入

交换机下

软件

操作系统为 CentOS 6.2，Java 环境使用 Oracle JDK 1.6.0_29。本章实验的数据

为某网站的一天的用户访问日志，格式固定，每行数据包括日志 ID，用户访问时

间，用户 ID，用户 IP 等。另外数据在测试系统中设置的备份数为 2。

4.4.2 实验结果

本次实验则针对所有的用户日志数据统计每天的 uv 数据，不同的客户端由用

户日志数据里的用户 ID 标识。这个统计操作相对来说有点复杂，因为有 distinct

操作和 Group by 操作，涉及到排序。这在关系数据库中的单机场景下，很容易做

到，但是在知云中是分布式的场景，没有 Hive 的话需要自己去写复杂的 MapReduce

程序。本文完成的知云中的大数据分析平台，则可直接输入 HiveQL 语句完成统计，

充分体现了本文实现的大数据分析平台的易用性。

为验证知云中的大数据分析平台的正确性和性能影响，本文将 Hadoop 作为测

试基准。图 4.12 为知云和 Hadoop 分别使用 HiveQL 的 Load 语句的执行时间对比，

从图中看到 Hadoop 的数据导入表现较好，这是由于知云的数据导入是基于 Thrift

服务，不能很好的支持流的读写，而 Hadoop 则是直接使用 Socket 流的方式。这只

能说明 Hadoop 在大的文件读写较有优势，但并不能说明其在小数据有同样优势。

事实上知云由于还有自由表存储，所以存取结构化的小数据要比Hadoop快。图 4.13

则为知云和 Hadoop 的日志分析的性能对比，从图中可以看到知云分析性能要好很

多，并且随着数据规模的增加，消耗时间增长也更缓慢。这其中主要的原因是知

云是完全 P2P 架构，所以没有 Hadoop 的 Namenode 节点，所有的节点都可以作为

存储和并行计算的节点。而 Hadoop 的 Namenode 一般是需要独立一个节点，不存

储具体数据，集群其他节点作为存储和计算节点。通过这两个实验可以说明本文

实现的大数据分析平台的正确性和较好的分析性能。

图 4.12 知云大数据分析平台和 Hadoop 日志数据导入性能对比

图 4.13 知云大数据分析平台和 Hadoop 日志分析性能对比

另外本文实现的大数据分析平台底层存储包括分布式文件和自由表存储的两

种方式，分析的数据可来自分布式文件存储，也可来自自由表存储，为验证其对

多样式的数据的分析支持，这里导入数据采用两种方式，一种是作为文件直接导

入知云的分布式文件系统中，然后用 Hive 去分析；另一种是逐行读取以 Key/Value

的方式写入知云的自由表存储中，然后也用 Hive 去分析。

图 4.14 知云大数据分析平台使用不同存储方式日志分析性能对比

图 4.14 显示了本文大数据分析平台使用不同底层存储对应的分析性能情况，

从中可以看到，使用知云文件系统进行存储时比使用自由表存储的分析性能要差

一点。这主要是因为 Hive 从文件系统读取数据分析时需要利用元数据信息对相应

的数据进行反序列化，而直接使用自由表存储的数据则不用，并且还受益于自由

表存储的低延迟访问优势。另一方面，由于数据导入到文件系统时不需要进行数

据抽取工作，以块的方式直接存入文件系统即可，而导入到自由表中时需要进行

相应的抽取工作并写入表的列中，所以导入数据时使用文件存储方式速度要快。

这个实验重在说明知云大数据分析平台对多存储方式的数据的分析能力。

通过本实验的分析，实验结果验证了知云的大数据分析平台的易用性和数据

存储方式的灵活性。一方面通过该大数据分析平台，用户很容易去完成日常进行

的数据统计分析，不需要去边写复杂的 MapReduce 程序。另一方面并且借助底层

存储的可扩展性，也能支撑大规模的数据分析，并且底层存储能对数据格式的多

样化提供支持。对于非结构化数据可以存入文件系统进行分析，而结构化数据可

以优先存入自由表中以获取分析时更好的性能。

4.5 本章小结

本章详细介绍了知云中大数据分析平台的实现，该平台完全基于 P2P 可伸缩架

构，没有单点问题，并提供易于使用的类 SQL 方式来执行分析作业，这是知云的

OLAP 服务的重要体现。

本章第一部分深入研究分析了 Hive 和 Cassandra 可融合的组件，融合的原则还

是基于 Cassandra 的 P2P 架构，不引入新的单点。所以确定将 Hive 的元数据库存

储和 Driver 引擎融合到 Cassandra 中，使 Hive 成为知云平台的一部分。

本章第二部分则针对将 Hive 元数据库移植到 Cassandra 中的目标研究了对象-

关系在自由表上的映射，并在 Cassandra 的自由表中实现。该实现依据 DataNuclues

的底层存储插件规范，所以能很容易替换 Hive 自带的基于 DataNucleus 关系数据

库存储的元数据库实现。

本章第三部分则讲述知云平台和 Hive 结合的优势，即提供了易用的大数据分

析平台和可分析的大数据格式更多样化，也就是本文实现的大数据分析平台的特

性，大数据的四个 V 基本特征在本平台上有均有体现。大数据的大规模（Volume），

多样性（Variety）和快速化（Velocity）特征在知云存储上体现，其价值（Value）

则由对其分析的结果体现。

本章第四部分则通过实验验证了本平台的易用性和数据存储方式的灵活性，用

户可以很容易去做日常使用的统计分析，并且分析的数据存储格式可以多样化。

最后，本文实现的大数据分析平台作为知云的 OLAP 服务体现，对上可以支撑

数据挖掘模块的应用，是国家核高基科技重大专项——非结构化数据管理系统

LaUDMS 的重要组成部分之一。

第 5 章基于 Cassandra 自由表的辅助索引设计和实现

本文 2.3 节介绍了基于自由表的辅助索引研究现状，从中可以看到辅助索引在

自由表中对提高数据访问性能很重要。4.2 节中介绍的在自由表上实现面向对象数

据模型即需要借助本章介绍的辅助索引来实现复杂的查询。另外本文实现的大数

据分析平台也是包括对自由表存储的数据分析的，通过辅助索引能很大提升自由

表存储分析性能。自由表没有像关系数据库一样自带对列的索引机制主要原因是

自由表上实现辅助索引有如下 4 个难题：

1. 支持亿级数据量的索引。自由表存储是面向海量数据分布式存储的场景，所以

数据量会很大，亿级以上，索引数据可能会跨多个机器。

2. 提供高性能的范围查询。这也是构建辅助索引的目的，如果不考虑性能，最简

单可以用 MapReduce 去分布式全表扫描查询，但是只能适合离线分析的场景，

不适合在线使用的场景。

3. 数据的低冗余。即索引本身带来额外的数据存储空间要小，不能超过被索引的

数据。

4. 数据的一致性能有效保证。因为索引和数据都是分布式存储，根据 CAP 理论，

这种场景下数据的一致性保证是个与可用性权衡的问题。

在这几个难题中，高性能与数据低冗余，强一致性是相互制约的关系。如果选

择高性能地范围检索，必然需要靠冗余索引数据来提升性能，而数据冗余会导致

更新数据时难以实现一致性，特别是分布式场景下。如果不要求高效地范围检索，

那么可以不考虑产生冗余数据，一致性问题也可以间接避免。这些都是根据具体

应用去选择的，所以一般在由应用根据需求去实现辅助索引。本章就将详细介绍

在 Cassandra 自由表上的辅助索引设计和实现，以解决自由表中如何高效和快速查

询某个列值符合条件的行的难题，其中数据一致性通过额外附加的一张自由表间

接达到。

5.1 辅助索引设计

为了能更好理解本文描述的辅助索引设计，有必要先了解 Cassandra 内部存储

结构。Cassandra 的设计融合了 Dynamo 的 P2P 架构和 BigTable 的数据模型，并且

存储机制也是和 BigTable 一样采用 LSM-Tree 存储架构，通过增量写来保证对磁盘

的操作是顺序的，所以 Cassandra 表现出来的写性能非常好。如图 5.1 所示描述了

Cassandra 单节点内部写数据的流程，从中可以看到 Cassandra 存储结构主要有

Commit-Log，MemTable 和 SSTable 三个。

图 5.1 Cassandra 内部写数据流程

新来的数据最先写入 Commit-Log，Commit-Log 作用和关系数据库日志类似，

负责写数据前纪录日志，以免数据丢失，然后数据会写入对应的 MemTable。

MemTable 则为数据在内存的存储结构，每个 MemTable 对应一个列族（Column

Family），满足一定条件后会批量写入硬盘，存储为 SSTable 结构。SSTable 是数据

在硬盘上的存储结构，并且一旦写入就不可修改，只能读取，下一个 MemTable

会写入一个新的 SSTable 文件，这就可能导致一个列族的数据存在多个 SSTable 里。

读取数据的数据时需要读取该列族对应的所有 MemTable 和 SSTable，这在列

族很大时候效率会很低，所以 Cassandra 采用 Bloom Filter 算法来快速定位读取的

行键在哪个 SSTable 上。定位到一个 SSTable 的数据文件后，还需要继续定位行键

所在的行以读取数据，行键在 SSTable 上都是保证有序的，所以 Cassandra 还对行

健在数据文件的位置偏移进行索引以便哈希查找定位。此外，Cassandra 还对一行

的列按照列名进行排序，并对列名索引，这样根据列名能快速定位到该列数据。

由此可见，Cassandra 内部提供了两级索引来提高随机读取效率，一是针对行键的

索引，可快速定位行键所在的数据文件，二是针对列名的索引，可快速定位一行

的某列在文件中的位置。

通过对 Cassandra 内部存储结构的读写机制的介绍可以知道，既然 Cassandra

内部支持列名一级的索引，则理论上可以利用单独的一个列族来存放索引数据，

并且就存放到列名上。这个想法受到Cassandra内部实现的两个不是很严格的限制，

一是一行的列数最大为 20 亿，二是列名的大小不超过 64KB，大多数情况下是可

行的。本文设计的辅助索引正是基于这个想法，并且能尽量规避 Cassandra 的两个

限制。辅助索引的设计包括两部分，一是索引格式，二是索引并发更新机制。

5.1.1 辅助索引格式

自由表辅助索引信息一般包括索引的数据和行键，根据本文辅助索引设计的

基本思想，索引数据存储到列名上，所以需要将它们组合在一起成为复合列名，

这带来的问题是复合列名如何排序。根据 Cassandra 内部实现，列名可以是任意的

Byte 数组，并按照字节排序，所以这里可以对复合列名按字节进行编码以能按照

字节排序。为能正确按字节排序，索引信息的内容尽量结构化，复合列名的各个

部分能相对独立排序，这里独立排序的意思是各个部分按各自相应数据类型进行

序列化反序列化，并按照正确的数据类型进行比较。因此，需要一个字节来标记

相应部分的数据类型，现在可以确定的是复合列名各部分格式如图 5.2 所示，其中

equality-tag 用表示该部分比较类型是<，>或者=中的哪种。因为复合列名具体包括

哪些部分与辅助索引的并发更新机制有关，所以具体格式由下面介绍的辅助索引

并发更新机制来决定。

图 5.2 复合列名的各部分格式

5.1.2 辅助索引并发更新机制

当辅助索引构建好后，如果要对自由表里的数据进行添加，更新或者删除等，

也应该同时能对建好的辅助索引进行更新，并能保证数据的一致性，这在分布式

领域要做到是比较困难的。根据本文辅助索引设计，当要更新索引时，需要从同

一个列族先读入索引的旧值（相应的复合列名）然后再写入新值，这个步骤因为

没有锁机制很容易引起并发冲突。为解决这个问题，一方面本文基于 Cassandra 的

写机制使用每个写操作附带的时间戳 timestamp 来控制数据总是最新的，因为时间

戳可以代表数据值的新旧；另一方面需要添加一个新的列族负责存储旧索引的一

些信息，这些信息会被更新数据的程序用来读取旧索引值并用于更新索引列族中

的数据，这样索引列族中只有写入数据，不用被读取了，而这个新的列族存放的

信息也会同时被更新，以保证保存的旧数据不会很多。

上述索引并发更新机制能解决并发冲突问题，数据一致性也能得到解决，现

在的问题是新添加的列族如何保存旧的索引信息。这个列族保存的信息和原数据

所在的列族信息应该一致，即包括行键，列名和列值都一致，但对这个列族操作

也存在并发读写情况，所以列名也应采取复合列名，在原有列名后面添加一个全

局唯一的 ID，本文采用的是 TimeUUID 类型，这样保证所有数据更新都有相应记

录。

图 5.3 Index 列族索引格式

图 5.4 IndexEntry 列族索引格式

综合辅助索引格式设计和并发更新机制，现在可以确定本文辅助索引的设计

了，即新添加两个列族，一个是 Index，负责索引信息存储；另一个是 IndexEntry，

辅助内部索引更新维护。Index 列族的一行对应一个列的索引，行键为索引名，列

名为索引信息的复合列名，具体包括索引数据类型，索引数据的值，索引数据在

原列族的行键和与 IndexEntry 列族对应的 TimeUUID，列值为空，如图 5.3 所示。

这里需要说明的是在复合列名开头添加索引数据类型部分主要是保证排序时两者

的数据类型相同才进行比较。IndexEntry 列族一行对应一个列的具体数据，行键为

索引数据对应的行键，列名为索引列名加上一个 TimeUUID 组成的复合列名，列

值为索引数据的值，如图 5.4 所示。

通过上面对辅助索引的设计描述可以知道，设计的索引类型辅助索引-行键存

储，相对范式化，比较适合索引的数据规模很大的场景，所以可应用于本文实现

的大数据分析平台的性能优化中。目前设计唯一的限制是一列的索引信息都保存

在一行里，所以受 Cassandra 一行能支持的列个数和大小的限制。本文为突破这个

限制保证一行的列的数目不超过限制，当索引行的大小到一定阈值后将行进行分

片（Shard），以使索引信息能存储到多行，并在索引名后加上分片号。因为索引信

息可能存放到多行，所以在索引查询时需要根据情况进行结果的合并。

为保存索引行的分片元数据信息，在 Index 列族加一行来记录这些元数据信息，

列名为索引名，值为分片的个数。为确保一个索引的信息能平均分布到多行，在

写入索引信息是采用 ROUND ROBIN 算法平均写入各个行。

5.2 辅助索引实现

本节针对 5.1 节介绍的辅助索引设计进行实现，主要包括两个部分，一是辅助

索引的管理，二是辅助索引的查询。目前的实现不考虑索引信息超过一行的列数

的限制，所以将一列的索引信息都存放在一行，不进行分片。

5.2.1 辅助索引管理

这里说的辅助索引管理主要是指辅助索引的维护，包括辅助索引的创建和更

新，具体需完成三个任务。

首先需要实现本文辅助索引格式基于复合列名构造的列名自定义排序，排序

算法设计的思想就是把复合列名的每个部分看出是独立的，两个复合列名比较时

分别比较相应部分即可，比较时从左向右，一旦能确定顺序即结束比较。该排序

算法是辅助索引实现的基础，通过对 Cassandra 内部对列名排序的实现研究，本文

只需要实现 Cassandra 定义好的接口，即两个列名的比较函数。这个函数的实现就

是把复合列名的各个部分相互比较即可。

然后是创建存储索引信息的 Keyspace 和 Index，IndexEntry 两个列族，并设定

列族的对应列名比较类型为复合列名的比较类。

这些基础工作完成后，即可更新辅助索引数据了，既能批量构建，也能基于

自由表里已有的数据顺序构建，前者构建效率较高，特别是大批量导入数据时更

有效。索引创建和更新具体的算法如下：

Algorithm 5-1 辅助索引创建和更新

public void updateSecondaryIndex(String rowkey, IndexMeta idxMeta, String colName, Object colValue) { 1. long timestamp = createLock(); //初始化时间戳

UUID new_uuid = newTimeUUID(); String idxName = idxMeta.get(colName);

2. BatchOp batch = new BatchOp(timestamp);//初始化批量操作 batch.begin();

3. IndexInfo oldIndex = getOldIndexInfo(IndexEntry, rowkey, colName); //删除旧索引 Op idxUpdateOp = updateIndex(oldIndex, rowkey, colName, colValue); batch.add(idxUpdateOp); Op idxEntryUpdateOp = deleteIndexEntry(oldIndex); batch.add(idxEntryUpdateOp);

4. if(colValue != null) {//有新值则添加索引信息 Op idxAddOp = addIndex(idxName, rowkey, colName, colValue); Op idxEntryAdOp = addIndexEntry(rowkey, colName, colValue); batch.add(idxAddOp); batch.add(idxEntryAddOp); }

5. batch.commit(); //提交索引更新操作 }

下面是对算法 5-1 关键步骤的详解：

1. 首先获取全局的时间戳，TimeUUID 和索引名。时间戳是标识本次更新数据版

本，Cassandra 以时间戳来表示数据的新旧程度并总用新的数据覆盖就的数据。

TimeUUID 则是控制并发冲突的一个标识，并应用到 IndexEntry 列族和 Index

列族的复合列名里，这样并发的时候不用锁来同步，因为每个并发操作都会有

不同的 TimeUUID。

2. 然后初始化 Batch 操作，因为索引的更新涉及到很多键值的更新，所以把它们

都封装到一个 Batch 操作方便控制，也可以保证所有更新操作使用相同的时间

戳。另外 Cassandra 支持 Batch 操作多次提交，因为是幂等操作。

3. 接着要去 IndexEntry 列族获取相应旧索引的信息，这里的信息包含了行键，索

引列的值和对应的 TimeUUID，可用于更新 Index 列族中旧的数据，并将相关

操作添加到 Batch 操作里。另外 IndexEntry 列族中这些旧的数据也是需要删除

的，所以相关操作也加入到 Batch 操作里。

4. 如果索引新值不为空，说明要在 IndexEntry 列族和 Index 列族都添加新值，并

将相关操作添加到 Batch 操作里，如此就达到更新索引的目的。

5. 提交 Batch 操作，完成辅助索引的更新操作。

5.2.2 辅助索引查询

由于本文辅助索引的设计是基于 Cassandra 的列族对列名进行范围查询支持，

所以辅助索引的查询主要就是列读取操作，速度很快，具体算法如下：

Algorithm 5-2 辅助索引查询

public Set<String> searchSecondaryIndex(String colName, Object colValue, CompareOp compare, IndexMeta idxMeta, int page, boolean all) { 1. String idxName = idxMeta.get(colName); //获取索引名

Set<String> result = new Set<String>(); //初始化索引查询的初始和结束复合列名

2. CompositeColumnName start = createCompositeColumnName(colName, compare); CompoisteColumnName end = createCompositeColumnName(colName, compare);

3. List<CompositeColumnName> ccNames = getColumnNames(idxName, start, end, page); //批量获取符合条件列名

4. for (CompositeColumnName cc : ccNames) { //拆解得到 rowkey String key = decompositeKey(cc); result.add(key); }

5. if(ccNames.size() < page ) //没有更多结果 goto 7;

6. if(all == true) { //获取更多结果 start = end; goto 3; }

7. return result; //返回结果集 }

下面是对算法 5-2 关键步骤的详解：

1. 获取索引名，并初始化结果集 Result。索引名是 Index 列族中的一个行键，结

果集里存放的则是符合查询条件的行键。

2. 根据查询条件构造复合列名的最小和最大组合。因为查询条件有可能是<，>

或=等，所以需要设置查询时列名的范围，这个通过正确设置索引格式

equlity-tag 字段来做到。

3. 对 Index 列族进行列名的批量范围查询。Cassandra 直接支持这种查询，所以速

度很快。

4. 对返回的复合列名列表进行拆解得到行键，添加到结果集 Result 里。返回的复

合列名列表并不是想要的结果，所以还需进行拆解得到对应的行键才能添加到

结果集。

5. 判断是否还有更多结果集，如果没有则返回结果集并结束，否则进入下一步。

判断是否有还有更多结果集很简单，只需比较返回结果集大小和批量查询设置

的大小，如果前者小于后者，则表示没有更多结果集，否则还有更多结果集。

6. 判读是否翻页，如果是则设置新的查询条件，如设置开始的复合列名，并转到

步骤 3，否则返回结果集并结束。

7. 返回结果集并结束。

5.3 辅助索引在知云大数据分析平台的应用

本文设计的辅助索引基于 Cassandra 内部列名索引机制，和 Cassandra 天然结

合在一起，也没有引入单点问题。辅助索引的主要作用是支持范围查询和对自由

表访问性能的提升，所以在知云的大数据分析平台实现中已被用来完成基于

Cassandra 自由表面向对象模型的复杂查询和对自由表存储的访问性能优化。本章

则主要介绍如何将辅助索引融合到 Hive 0.8.1 提供的分布式索引插件框架中，这样

做的好处是用户可以通过 HiveQL 来控制辅助索引的创建和删除，并能对分析性能

进行优化。辅助索引是基于自由表存储的，而知云与 Hive 的结合使得 Hive 也能很

好的分析自由表存储的数据，所以辅助索引的加入能从底层存储的角度来优化

Hive 分析性能。

5.3.1 Hive 分布式索引框架解析

Hive 现在对底层存储不再要求必须是 HDFS，允许其他底层存储，如关系数据

库和自由表存储等，只要底层存储实现了 HiveStorageHandler 接口即可。正因为底

层存储多样化，相应索引建立的方式也不一样，所以 Hive 提供索引建立和查询时

也不是建立一种通用的索引，而是建立索引框架以支持第三方索引插件。Hive 提

供的索引插件接口是 HiveIndexHandler，第三方索引只要实现了该接口即能被

HiveQL 调用，即在 CREATE INDEX 的时候指定索引实现的类即可。Hive 0.8.1 在

该索引框架下自带实现了 CompactIndex 和 BitmapIndex 两个索引，都是针对文件

存储的方式，而本文辅助索引则在自由表存储上实现，与它们是互补的情况。知

云平台底层既有分布式文件存储，又有自由表存储，所以这些索引都可以为知云

大数据分析平台服务。

Hive 对实现 HiveIndexHandler 接口的索引会自动生成一个 MapReduce 作业，

然后提交执行，所以辅助索引实现该接口后就可以自动通过 MapReduce 来进行分

布式创建和查询。这个接口的方法有如下 5 个：

1. boolean usesIndexTable();//决定是否以 Hive 的 Table 来存储索引数据

2. void analyzeIndexDefinition(

org.apache.hadoop.hive.metastore.api.Table baseTable,

org.apache.hadoop.hive.metastore.api.Index index,

org.apache.hadoop.hive.metastore.api.Table indexTable)

throws HiveException;//对于使用 Hive 的 Table 存储索引数据的情形需根据

//用户提供的 Index属性需设定 IndexTable的一些附加属性

3. List<Task<?>> generateIndexBuildTaskList(

org.apache.hadoop.hive.ql.metadata.Table baseTbl,

org.apache.hadoop.hive.metastore.api.Index index,

List<Partition> indexTblPartitions, List<Partition> baseTblPartitions,

org.apache.hadoop.hive.ql.metadata.Table indexTbl,

Set<ReadEntity> inputs, Set<WriteEntity> outputs)

throws HiveException;//生成建立索引计划

4. void generateIndexQuery(List<Index> indexes, ExprNodeDesc predicate,

ParseContext pctx, HiveIndexQueryContext queryContext);//生成对索引的查询

//计划，包括多个索引结果集的合并

5. boolean checkQuerySize(long inputSize, HiveConf conf);//检查查询的大小是否超

//出限制

5.3.2 实现 Hive 分布式索引框架下的辅助索引插件

由前一节的分析可知，Hive 的索引框架接口设计的很简单，第三方实现后，

能利用 Hive 的分布式功能去创建索引和查询索引，因为 Hive 会把其转换成

MapReduce 作业去完成。

针对本文设计的辅助索引情况，实现 Hive 分布式索引框架下的辅助索引插件

主要实现两个接口，一个是生成建立索引计划 generateIndexBuildTaskList，另一个

是生成索引查询计划 generateIndexQuery，索引的数据还是存在自由表上。所以从

实现来看建立索引和 5.2 节描述的类似，只不过需要封装实现 Hive 索引框架的接

口，而索引查询则除了利用 5.2 节描述的索引查询算法封装实现 Hive 索引框架的

接口外，还需要 Hive 的优化器来支持。Hive 有很多可配置的优化选项，其中

Predicate Pushdown 优化用来将条件查询下推到底层，这样就能利用底层存储的索

引技术去高效完成，这个特性由配置文件中的 hive.optimize.ppd 属性控制，默认是

true。Hive 还有 hive.optimize.index.filter 和 hive.optimize.index.groupby 两个属性来

控制自动访问相关索引进行优化，本文实现将其都设置为 true 以能使用辅助索引

加速分析。

5.4 实验结果与分析

本实验主要测试 5.3.2 节描述的辅助索引实现到 Hive 分布式索引框架后的性

能与之前没有使用辅助索引的性能对比。由于辅助索引只是基于自由表存储，所

以这次实验数据都导入到自由表上存储，并用 HiveQL 建立好辅助索引。

5.4.1 实验环境

硬件

表 5.1 实验的硬件环境

硬件参数参数值

节点个数 5

CPU Intel E5620 (2.40GHz/4 核/12MB/80W)，2颗 CPU

内存 4*8G=32G

硬盘 12*1TB 3Gbps SATA 7.2K 第一块盘作为操

作系统，其它盘作为数据盘网络双网卡绑定方式，千兆网口，在一个接入

交换机下

软件

操作系统为 CentOS 6.2，Java 环境使用 Oracle JDK 1.6.0_29。本章实验的数据

为某网站的一天的用户访问日志，格式固定，每行数据包括日志 ID，用户访问时

间，用户 ID，用户 IP 等。另外数据在测试系统中设置的备份数为 2。

5.4.2 实验结果

本次实验仍针对所有的用户日志数据统计每天的 uv 数据，但同时要求日志 ID

大于 1000000，这里对日志 ID 这列建立辅助索引。

实验对比的是 Hive 执行分析时是否使用辅助索引之间的性能，结果如图 5.5

所示。从图中可以看到，辅助索引确实对性能提升作用明显，尤其是数据量大了

之后优势更明显。这主要得益于 Hive 提供的 Predicate Pushdown 优化来将条件查

询下推到底层，所以对存储在自由表中的数据进行分析时使用辅助索引能优化

Hive 的分析性能。该实验结果也说明本文实现的大数据分析平台的可优化空间很

多，可以是查询计划，也可以是查询执行的分布式计算框架，还可以是底层存储

等。其中每个方面都可以是个研究方向，本文则从底层存储的索引着手进行了深

入的研究。

另一方面辅助索引也带来建立和维护的代价，频繁更新因为涉及到两个列族

会导致写速度受影响，还有存储空间的消耗，这也是一般自由表不带辅助索引，

或者自带的索引功能较弱的原因。所以需要根据应用需求去选择是否使用辅助索

引或者使用哪种辅助索引的设计。

图 5.5 知云大数据分析平台使用辅助索引日志分析性能对比

需要说明的是本文辅助索引用于优化 Hive 的分析性能是其应用之一，上述实

验也已经验证，另外一个应用是在 Hive 的元数据库信息查询中。知云平台中 Hive

的元数据信息是存储在 Cassandra 自由表中，涉及到很多复杂的查询，所以需要借

助辅助索引来完成。4.4 节和 5.4 节的实验都间接验证了辅助索引在元数据库的查

询中应用的正确性。

5.5 本章小结

本章介绍了基于 Cassandra 自由表的辅助索引设计和实现，并介绍了其在大数

据分析平台中的应用。根据 2.3 节介绍的辅助索引分类，本文实现的辅助索引属于

辅助索引-行键存储类，索引的设计突破很多已有索引机制的限制。

本章第一部分介绍了辅助索引的设计，包括辅助索引的格式和辅助索引并发

更新机制。简单的说就是利用基于 Cassandra 自由表的列可动态添加且可自定义列

名排序的特性，构建复合列名来进行索引，所以索引的大部分操作都是列操作，

速度很快。

本章第二部分介绍了辅助索引的实现，构建了两个列族，分布负责索引信息

存储和内部索引更新维护。具体实现包括辅助索引管理和辅助索引的查询两部分，

都是直接在 Cassandra 上的实现，对于知云来说没有引入新单点，索引的管理和查

询也是分布式的。

本章第三部分介绍了辅助索引在知云大数据分析平台的应用，主要是根据

Hive 的分布式索引框架，实现 Hive 定义的索引接口，然后应用于 Hive 的分析性

能优化。这个应用很好的完成了知云平台通过索引对自由表存储上的数据进行分

析的性能优化。另外辅助索引还应用于 Hive 元数据信息的查询实现中。

本章第四部分则进行实验的对比，结果表明辅助索引确实能带来性能提升，

但是也有使用代价，应根据应用需求选择是否使用辅助索引。

第 6 章总结与展望

6.1 论文工作总结

随着互联网应用的飞速发展和信息的社会化，数据呈爆发式的增长，现在已

进入大数据时代，越来越多的企业都在大数据中分析挖掘以获取有利决策的价值。

工业界和开源界为应对大数据的处理，都推出了相应的大数据处理平台，这也带

动了学术界对大数据平台的研究，包括体系架构，一致性，数据模型和辅助索引

等领域。本文则在这个大背景下对基于 P2P 可伸缩架构的大数据分析平台进行了

深入的研究，并将之实现。

本文将大数据平台的架构分为两类，一类是 Master/Slave 主从式架构，典型代

表是 Hadoop 的 HDFS 分布式文件系统；另一类是 P2P 可伸缩架构，典型代表是

Cassandra 自由表存储。Master/Slave 模式有单点问题，部署也较复杂，而 P2P 架

构则相反，所以本文选择 P2P 架构的大数据平台，但是基于 P2P 架构目前没有相

应的分布式计算框架，无法有效做大数据分析。为了能实现基于 P2P 可伸缩架构

大数据分析平台，本文在以下三方面进行了改进和创新：

1. 大数据分析平台架构方面，研究了分布式数据仓库 Hive 的设计和组件，并将

其融合到基于 P2P 架构的 Cassandra 内部实现中。这带来的好处是提供了易用

的大数据分析平台和可分析的大数据格式更多样化，这也是本文实现的大数据

分析平台的特性，完整体现了大数据的四个 V 基本特征。其中大数据的大规

模（Volume），多样性（Variety）和快速化（Velocity）特征在知云存储上体现，

其价值（Value）则由对大数据进行分析的结果体现。

2. 基于 Cassandra 自由表的面向对象数据模型方面，为实现 Hive 组件完全融合到

Cassandra 中，定义了基于 Cassandra 自由表的面向对象数据模型来存储 Hive

的元数据信息。该实现依据 DataNuclues 的底层存储插件规范，所以能很容易

替换 Hive 自带的基于 DataNucleus 关系数据库存储的元数据库实现。这个数据

模型的实现屏蔽了底层的使用细节，使熟悉传统关系数据库的 ORM 技术的应

用开发人员很容易直接使用可扩展的自由表存储。

3. 基于 Cassandra 自由表的辅助索引方面，描述了基于 Cassandra 的自由表辅助

索引设计和实现，并将其应用到基于 Cassandra 自由表的面向对象数据模型的

复杂查询的实现上。此外还将其融合到 Hive 的 MapReduce 分布式索引插件框

架中，实现 Hive 分析的性能优化。

第 6 章总结与展望

6.2 论文工作展望

本文虽然研究和实现了基于 P2P 可伸缩架构的大数据分析平台，也带来了一

种容易使用的大数据分析的方式和可分析的大数据格式多样化等特性，但是大数

据处理的技术还不成熟，没有一定的标准，所以还是有很多工作去做。根据本文

现有工作的情况和研究的积累，本文的后续工作可以在以下方面展开：

1. 大数据分析平台架构方面。本文目前使用的分布式计算框架是 MapReduce，这

个框架最大的问题是性能不是很好，所以可以考虑像 E3 引擎一样结合 Dryad

研究一套性能好的分布式计算框架。根据 Hadoop 的官方网站，现在已经出了

下一代 MapReduce[68]，这个也是值得去研究的。之所以对 MapReduce 要求较

高是因为现在大数据分析平台发展很重要的一个趋势是由离线分析渐渐转向

实时分析，或者准实时分析。这里就可能会涉及到很多其他的技术，比如分布

式缓存 Memcached[69]，分布式内存数据库等。以后将这些工作能放进来的话，

本文的大数据分析平台性能就会得到显著提升。

2. 在基于自由表的面向对象数据模型方面，现在的实现不是很完美，瓶颈在自由

表的辅助索引有一定限制。现在辅助索引支持多列索引的 OR 逻辑查询时很难

做到分页，因为每个索引查询的结果都是无序的，并且遇到结果集很大超过内

存时就无法处理了。这种情况就只能离线查询，利用 Hive 的分析查询去完成，

所以还是要去研究能和自由表结合更紧密的 Hive 查询引擎，以优化 Hive 的分

析查询。

3. 在基于自由表的辅助索引方面，主要就是多列索引优化。可以采用类似

CCIndex 的方法根据索引大小进行结果集评估，先对结果集最小的索引查询然

后再用其他条件进行过滤。问题的难点是如何进行结果集大小评估，所以需要

对自由表本身进行研究，找到可以优化的方法。

4. 整个大数据分析平台性能优化方面。本文实现的大数据分析平台将存储，计算

和分析结合紧密，可优化空间很多，包括查询计划，查询执行的分布式计算框

架和底层存储等。其中每个方面都可以是个研究方向，本文只在底层存储的索

引着手进行了深入的研究。

参考文献

[1] Radar. http://radar.oreilly.com/2012/01/what-is-big-data.html.

[2] Chen K, Zheng WM. Cloud computing: System instances and current research. Journal of Software, 2009.

[3] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google file system. SOSP, 2003:29-43.

[4] Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters. OSDI, 2004.

[5] F. Chang, Dean J, Ghemawat S, et al. Bigtable: a distributed storage system for structured data. OSDI, 2006.

[6] Burrows M. The Chubby lock service for loosely coupled distributed systems. OSDI, 2006.

[7] Amazon. http://aws.amazon.com/ec2/.

[8] G. DeCandia, D. Hastorun, M. Jampani, et al. Dynamo: amazon’s highly available key-value store. SOSP, 2007.

[9] Amazon. http://aws.amazon.com/s3/.

[10] Amazon. http://aws.amazon.com/sqs/.

[11] Amazon. http://aws.amazon.com/simpledb/.

[12] B. F. Cooper, R. Ramakrishnan, U. Srivastava, et al. Pnuts: Yahoo!’s hosted data serving platform. PVLDB, 2008.

[13] Barham P, Dragovic B, Fraser K, et al. Warfield A. Xen and the art of virtualization. In: Proc. of the 9th ACM Symp. on Operating Systems Principles, 2003.

[14] Apache Hadoop. http://hadoop.apache.org/.

[15] Brad Calder. Windows Azure Storage - Essential Cloud Storage Services. In Microsoft Professional Developers Conference (PDC), 2008.

[16] M. Isard, M. Budiu, Y. Yu, et al. Dryad: distributed data-parallel programs from sequential building blocks, SIGOPS, 2007.

[17] A. Lakshman and P. Malik. Cassandra: a decentralized structured storage system, SIGOPS Oper. Syst. Rev, 2010.

[18] MongoDB. http://www.mongodb.org/.

[19] Redis. http://redis.io/.

[20] T. Kraska, M. Hentschel, G. Alonso, et al. Consistency rationing in the cloud: Pay only when it matters. PVLDB, 2009.

[21] ZHANG, C., ZHANG, Z. Trading replication consistency for performance and availability: an adaptive approach. In IEEE ICDCS,2003.

参考文献

[22] H. T. Vo, C. Chen, B. C. Ooi. Towards elastic transactional cloud storage with range query suuport, PVLDB, 2010.

[23] K. Shvachko, H. Huang, S. Radia, et al. The hadoop distributed file system, in 26th IEEE (MSST2010) Symposium on Massive Storage Systems and Technologies, 2010.

[24] Browne J. Brewer’s CAP theorem. http://www.julianbrowne.com/article/viewer/ brewers-cap- theorem. 2009.

[25] D. Borthakur. Apache Hadoop goes realtime at Facebook. In SIGMOD 2011.

[26] Apache ZooKeeper. http://hadoop.apache.org/zookeeper/.

[27] KARGER, D., LEHMAN, et al. Consistent hashing and random trees:Distributed caching protocols for relieving hot spots on the World Wide Web. In Proceedings of the 29th Annual ACM Symposium on Theory of Computing, 1997.

[28] A. Thusoo, J. S. Sarma, N. Jain, et al. Hive - a petabyte scale data warehouse using hadoop, in ICDE, 2010.

[29] JDO. http://db.apache.org/jdo/.

[30] DataNucleus. http://www.datanucleus.org/.

[31] O'NEIL, P., CHENG, et al. The log-structured merge-tree (LSM-tree). Acta Inf, 1996.

[32] S. Wu, F. Li, S. Mehrotra, et al. Query Optimization for Massively Parallel Data Processing. ACM Symposium on Cloud Computing (SOCC). 2011.

[33] Qin XP, Wang HJ, Du XY, et al. Big data analysis—Competition and symbiosis of RDBMS and MapReduce. Journal of Software, 2012.

[34] WANG Shan, WANG Hui-Ju, QIN Xiong-Pai, et al. Architecting Big Data: Challenges, Studies and Forecasts. Chinese Journal of Computers, 2011.

[35] Aster. http://www.asterdata.com/.

[36] Greenplum. http://www.greenplum.com/.

[37] A. Abouzeid, K. Bajda-Pawlikowski, D. J. Abadi, et al. Hadoopdb: An architectural hybrid of mapreduce and dbms technologies for analytical workloads. In PVLDB, 2009.

[38] epiC project. http://www.comp.nus.edu.sg/~epic/.

[39] Apache HBase. http://hbase.apache.org/.

[40] DataStax. http://www.datastax.com/docs/0.8/brisk/about_brisk.

[41] A. Pavlo, A. Rasin, S. Madden, et al. A Comparison of Approaches to Large Scale Data Analysis. SIGMOD, 2009.

[42] C. Chen, G. Chen, D. Jiang, et al. Providing Scalable Database Services on the Cloud, WISE, 2010.

[43] G. Chen, K. Chen, D. Jiang, et al. an Elastic Execution Engine for Scalable Data Processing Journal of Information Processing, 2012, 20(1).

[44] Y. Cao, C. Chen, F. Guo, et al. ES2:A Cloud Data Storage System for Supporting Both OLTP and OLAP. IEEE International Conference on Data Engineering (ICDE), 2011.

参考文献

[45] S. Wu, K. L. Wu. An Indexing Framework for Efficient Retrieval on the Cloud IEEE Data Eng. Bull, 2009.

[46] G. Chen, H. T. Vo, S. Wu, et al. A Framework for Supporting DBMS-like Indexes in the Cloud Int'l Conference on Very Large Data Bases (VLDB), 2011.

[47] S. Wu, D. Jiang, B. C. Ooi, et al. Efficient B+-tree Based Indexing for Cloud Data Processing. Int'l Conference on Very Large Data Bases (VLDB), 2010.

[48] J. Wang, S. Wu, H. Gao, et al. Indexing Multi-dimensional Data in a Cloud System. ACM Int'l. Conference on Management of Data (SIGMOD), 2010.

[49] Hibernate. http://www.hibernate.org/.

[50] JPA. http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html.

[51] Lily. http://www.ngdata.com/site/products-services/lily.html.

[52] Yongqiang Zou, Jia Liu, Shicai Wang, et al. CCIndex: a Complemental Clustering Index on Distributed Ordered Tables for Multi-dimensional Range Queries, in 7th IFIP International Conference on Network and Parallel Computing, 2010.

[53] B. F. Cooper, A. Silberstein, E. Tam, et al. Benchmarking cloud serving systems with ycsb. In SoCC '10: Proceedings of the 1st ACM symposium on Cloud computing, 2010.

[54] Baker, J., Bond, et al. Megastore: providing scalable, highly available storage for interactive services. Conference on Innovative Data Systems Research (CIDR), 2011.

[55] PIKE, R., DORWARD, et al. Interpreting the data: Parallel analysis with Sawzall. Scientic Programming Journal, 2005.

[56] Apache Pig. http://pig.apache.org/.

[57] C.Ronnie. SCOPE: Easy and Efficient Parallel Processing of Massive Data Sets. Proc. VLDB Endow., 2008.

[58] M. Isard, M. Budiu, Y. Yu, et al. DryadLINQ: A System for General-Purpose Distributed Data-parallel Computing Using a High-Level Language, ACM SIGOPS Operating Systems Review, 2009.

[59] ORM to Relational Database. http://www.agiledata.org/essays/mappingObjects.html

[60] D. Jiang, B. C. Ooi, L. Shi, et al. The Performance of MapReduce: An In-depth Study. PVLDB, 2010.

[61] J. Dittrich, J.-A. Quiane-Ruiz, A. Jindal, et al. Hadoop++: Making a Yellow Elephant Run Like a Cheetah. PVLDB, 2010.

[62] T. Condie, N. Conway, P. Alvaro, et al. MapReduce Online. In NSDI, 2010.

[63] BU, Y., HOWE, et al. HaLoop: Efficient iterative data processing on large clusters. In Proceedings of VLDB, 2010.

[64] D. Jiang, A. K. H. TUNG, G. Chen. MAP-JOIN-REDUCE:Towards Scalable and Efficient Data Analysis on Large Clusters, IEEE Transactions on Knowledge and Data Engineering (TKDE), 2010.

参考文献

[65] Y. He, R. Lee, Y. Huai, et al. RCFile: A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse Systems. In ICDE, 2011.

[66] Y. Lin, D. Agrawal, C. Chen, et al. Llama: Leveraging Columnar Storage for Scalable Join Processing in the MapReduce Framework. In SIGMOD Conference, 2011.

[67] A. Floratou, J. M. Patel, E. J. Shekita, et al. Column-Oriented Storage Techniques for MapReduce. PVLDB, 2011.

[68] Yahoo. http://developer.yahoo.com/blogs/hadoop/posts/2011/03/mapreduce-nextgen-schedule r.

[69] Memcached: a distributed memory object caching system. http://www.danga.com/memcache d.

致谢

衷心感谢导师王建民教授在整个研究生阶段对我的辛苦栽培，给予我发挥才

能的平台。衷心感谢丁贵广副教授，在课题研究，项目开发与论文撰写过程中给

予的耐心细致的指导。他们的言传身教让我终身受益。

感谢朱妤晴博士对我平时实验的指导和帮助，让我能快速学习并成长，不胜

感激。

感谢信息系统与工程研究所全体老师和同学们给实验室营造了良好的学习氛

围，也感谢清华大学提供的平台，给予我良好的学习资源。

本文研究内容承蒙国家核高基科技重大专项支持，特此致谢。

最后，深深感谢父母对我学业与生活一如既往的关心鼓励与大力支持。

声明

本人郑重声明：所呈交的学位论文，是本人在导师指导下，独立进行研究工

作所取得的成果。尽我所知，除文中已经注明引用的内容外，本学位论文的研究

成果不包含任何他人享有著作权的内容。对本论文所涉及的研究工作做出贡献的

其他个人和集体，均已在文中以明确方式标明。

签名：日期：

个人简历、在学期间发表的学术论文与研究成果

个人简历

1987 年 05 月 23 日出生于江西省万安县。

2005 年 9 月考入南京大学软件学院软件工程专业，2009 年 7 月本科毕业并获

得工学学士学位。

2009 年 9 月进入清华大学软件学院攻读软件工程硕士学位至今。

研究成果

[1] 王建民，丁贵广，卓安等. 一种键值库辅助索引的构建与管理方法: 中

国(已提交申请)

[2] 王建民，丁贵广，卓安等. 一种非结构化数据查询语言的解析和处理方

法: 中国(已提交申请)

[3] 王建民，丁贵广，卓安等. 一种非结构化数据管理系统的可视化管理方

法: 中国(已提交申请)

基于P2P 可伸缩架构的大数据分析平台研究与实现

Documents

架站神器Weebly 教學

Google Play上架全攻略

The Meaning of New Confucianism 现代新儒家的概念

现 #8722;抵嵨 † Ÿ株‰ −帚弥指 •株 #353; #376;种

资料9. 现有器材清单

精通QTP 与自动化测试框架设计实战

第9章图象的压缩编码

赫斯特指数（Hurst）指数及在Excel 中的实现

17320002-RefComp-SRC-S ZHZL系列紧凑型螺杆压缩机

视频原始图像中存在着大量的信息冗余，如时间冗余、空间冗余、信息熵冗余、谱间冗余、几何结构冗余、视觉冗余和知识冗余等等。运动估计是视频压缩

精密测量的目的: - 减少废品、缩短机床停机时间,提高效率!

揭秘历史隐得来希发轫现代大学省略育思想的演进历史观和大学观述评展立新

WinCC V7.5 典型架构和选型

现代电子系统设计 - 文曲经典数字图书馆

陕西坚瑞消防股份有限公司发行股份及支付现金购买 ... - 企查查

在场与缺席：一个正义分析框架(Presence and Absence: A Framework for Justice)

2019 特殊用途压缩机- 产品手册PRODUCT MANUAL - 格力

Detrimental Citizenship Behaviour: A Multilevel Framework of Antecedents and Consequences. 有害的公民行为：一个前因与后果的多层次框架

App Inventor 2單機版與伺服器架設

3D打印从想象到现实精校文字版