1、时动态计算模式的内涵式转变。内涵式在这里 也比较容易理解，即结构优化、质量提高，是一种实现实质性的跨越式的进程。大数据平台允许用户将所有数据存储为其原生的业务对象格式，通过可用组件上的大规模并行计算实现价值，不仅仅是批量 处理和离线分析，同时支持实时查询和处理等特征，甚至要求响应时间在毫秒级别，并且可承受大规模的并发访问，这些都是“速度”特征的范畴。 1.1.2 为何大数据至关重要 这种非传统分析是否适合企业的业务需求？换句话说就是能否找到一个大数据平台可为当前的分析工具提供补充实现，并且兼容现有解决方案，以实现更好的业务成果。 通常情况下，数据必须经过清理才能规范地存放到数据仓库中。相反大数
2、据解决方案不仅会利用不适合传统仓库且数量庞大的数据，而且不需要改变原有数据格式，保留了数据的真实性，并能够快速 访问海量的信息。对于不能使用传统关系型数据库方法处理的信息所带来的挑战，大数据解决方案非常适合。大数据之所以重要，是因为其具备解决现实问题的三个关键方面。 分析各种不同来源的结构化、结构化和非结构化数据的理想选择。 当需要分析所有或大部分数据，或者对一个数据抽样分析效果不明显时，大数据解决方案是理想的选择。 未预先确定数据的业务度量指标时，是进行迭代式和探索式分析的理想选择。 1.1.3 NoSQL在大数据中扮演的角色 NoSQL，是Not only SQL的缩写，泛指非关系型的数据
3、库。与关系型数据库相比，NoSQL存在许多显著的不同点，其中最重要的是NoSQL不使用SQL作为查询语言。其数据存储可以不需要固定的表 模式，也通常会避免使用SQL的JOIN操作，一般又都具备水平可扩展的特性。NoSQL的实现具有两个特征：使用硬盘和把随机存储器作存储载体。 1.传统关系型数据库的缺陷 随着互联网Web 2.0的兴起，传统的关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型动态网站时已经力不从心，暴露了很多难以克服的问题。 （1）高并发读写的瓶颈 Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用静态化技术，因此数据库
4、并发负载非常高，可能峰值会达到每秒上万次读写请求。关系型数据库应付上 万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘I/O却无法承受。其实对于普通的BBS网站，往往也存在相对高并发写请求的需求，例如，人人网的实时统计在线用户状态，记录热门帖 子的点击次数，投票计数等，这是一个相当普遍的业务需求。 （2）可扩展性的限制 在基于Web的架构中，数据库是最难以进行横向扩展的，当应用系统的用户量和访问量与日俱增时，数据库系统却无法像Web Server和App Server那样简单地通过添加更多的硬件和服务节点来扩展 性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数
5、据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，而不能通过横向添加节点的方式实现无缝扩展。 （3）事务一致性的负面影响 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务 的修改上，以便维护所有数据的完整性，这随之而来的是性能的大幅度下降。很多Web系统并不需要严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成 了高负载下的一个沉重负担。 （4）复杂SQL查询的弱化 任何大数据量的Web系统都非常忌讳几个大表间的
6、关联查询，以及复杂的数据分析类型的SQL查询，特别是SNS类型的网站，从需求以及产品设计角度就避免了这种情况的产生。更多的情况往往只是 单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了，所以这部分功能不能得到充分发挥。 2.NoSQL数据库的优势 （1）扩展性强 NoSQL数据库种类繁多，但是一个共同的特点就是去掉关系型数据库的关系特性，若数据之间是弱关系，则非常容易扩展。例如，HBase、Cassandra等系统的水平扩展性能非常优越，非常容易实现 支撑数据从TB到PB级别的过渡。 （2）并发性能好 NoSQL数据库具有非常良好的读写性能，尤其在大数据量下，同样表现优秀
7、。这得益于它的弱关系性，数据库的结构简单。一般MySQL使用Query Cache，每当表发生更新操作时，Cache就会失 效，这是一种大粒度的Cache，在针对Web 2.0的交互中频繁应用，Cache性能并不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能要高很多。 （3）数据模型灵活 NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库中，增删字段是一件非常麻烦的事情。对于数据量非常大的表，增加字段简直就是一场噩梦。NoSQL允 许使用者随时随地添加字段，并且字段类型可以是任意格式。 HBase作为N
8、oSQL数据库的一种，当然也具备上面提到的种种优势。使用过Hadoop的读者知道，Hadoop最适合的应用场景是离线批量处理数据，其离线分析的效率非常高，能在分钟级别处理TB级 的数据，但是一般的应用系统并不适合批量模式访问，更多的还是用户的随机访问，就类似访问关系型数据库中的某条记录一样。HBase的列式存储的特性支撑它实时随机读取、基于KEY的特殊访问需 求。当然，HBase还有不少新特性，其中不乏有趣的特性，在接下来的内容中将会详细介绍。 1.2 HBase是什么 HBase（Hadoop Database）是一个高可靠、高性能、面向列、可伸缩的分布式数据库，利用HBase技术可在廉价P
9、C上搭建起大规模结构化存储集群。HBase参考Google的BigTable建模，使用类似 GFS的HDFS作为底层文件存储系统，在其上可以运行MapReduce批量处理数据，使用ZooKeeper作为协同服务组件。 HBase的整个项目使用Java语言实现，它是Apache基金会的Hadoop项目的一部分，既是模仿Google BigTable的开源产品，同时又是Hadoop的衍生产品。而Hadoop作为批量离线计算系统已经得 到了业界的普遍认可，并经过了工业上的验证，所以HBase具备“站在巨人肩膀之上”的优势，其发展势头非常迅猛。 HBase还是一种非关系型数据库，即NoSQL数据库。在
10、Eric Brewer的CAP理论中，HBase属于CP类型的系统，其NoSQL的特性非常明显，这些特性也决定了其独特的应用场景。接下来的内容将详细 讲解HBase的发展历史、发行版本和特性。 1.2.1 HBase的发展历史 Apache HBase最初是Powerset公司为了处理自然语言搜索产生的海量数据而开展的项目，由Chad Walters和Jim Kellerman两人发起，经过两年的发展之后被Apache基金会收录为顶级项目，同时 成为非常活跃、影响重大的项目。 2006年11月，Google开放了论文“Bigtable：A Distributed Storage System
11、for Structured Data”，该论文就是HBase的原型。2007年2月，倡导者提出作为Hadoop的模块的HBase原型，该原 型包含HBase的基本介绍、表设计、行键设计和底层数据存储结构设计等内容1。 经过一段时间的酝酿和开发工作，在2007年10月第一个可用的、简单的HBase版本发布，该版本只实现了最基本的模块和功能，因为只是初始开发阶段，此时的HBase版本发展很不完善。2008年1 月，Hadoop升级为顶级项目，HBase作为Hadoop的一个子项目存在，HBase的活跃度非常高，在短短不到2年的时间经历了N多个版本的发布，并且其中包含了版本号的大“跳跃”。下面是一
12、些版本发 布的信息： hbase-0.18.0于2008年9月21日发布 hbase-0.20.6于2010年7月10日发布 hbase-0.89.20100621于2010年6月25日发布 其中，从hbase-0.20.6到hbase-0.89.20100621版本，经历了版本的大“跳跃”。在2009年秋季发布0.20系列版本后，HBase经历了发展历史上的一次版本大变动，在此之前的版本都追随Hadoop的 主版本，例如，hbase 0.X.*版本都会伴随着Hadoop 0.X.*版本，之所以出现版本跳跃，官方给出的解释有两点。 Hadoop的版本更新已经放缓，而HBase相比Hadoop开
13、发来讲更加活跃，发布版本更加频繁，并且Hadoop已经有多个分支，HBase也需要兼容多个分支，所以不再需要与Hadoop的版本更新步伐保持一 致。 从HBase的功能实现上来讲，已经基本实现BigTable论文中实现的功能，也就是HBase的实现已经接近“1.0”，应该赋予一个更接近“1.0”的版本。 “跳跃”之后的版本发布比较规律，先后经历了0.90.*、0.92.*、0.94.*、0.96.*、0.98.*五个大的版本，现在稳定版本是0.94.*。 1.2.2 HBase的发行版本 本节主要介绍现有HBase的版本知识，从0.90.0之后，HBase的版本更新是非常有规律的，可以从0.9
14、0.0、0.91.0、0.92.0、0.93.0、0.94.0、0.95.0、0.96.0、0.97.0、0.98.0这样的版本变化中发现一些 规律。 这些版本都是大版本，其中偶数版本是稳定发布版，而奇数版本都是开发版，基本不对外发布，但是可以在官方JIRA的项目管理系统中找到这些奇数版本对应的开发信息，并且可以在SVN上找到相关 的最新开发代码。所以，偶数发布版本属于稳定版本，奇数开发版本属于不稳定版本，一般不建议用户在生产环境中使用开发版本，这些也是大版本的发布规律。 小版本一般基于当前大版本的问题进行修正，一般表示小版本的数字在1100之间，例如：0.94.1、0.94.2、0.94.3
15、、0.94.4。这些小版本都是基于0.94大版本的，截止到本书撰写时，最新版本是 0.94.18。小版本都是从小到大依次递增，不存在版本跳跃的情况。对于小版本而言，原则上数值越大越稳定，因为小版本都是基于某一个大版本的，在小版本中并不会增加新特征，而是修正一些代码的漏 洞和问题。 截止到本书完稿时，HBase官方给出的最新版本信息如下面的代码所示。从中可以看出，发布版本存在0.94、0.96、0.98三个大版本。其中stable文件夹包含了最新的稳定发布版本；to_remove表示已 经移除的版本；HEADER.html文件用于对代码发行版进行说明，即下面代码中的前半部分，从“HBase Re
16、leases path=/openresources/teach_ebook/uncompressed/14884/OEBPS/Text/.”开始，一直到“fresh.”结束的解释说明。每部分后面都有对应的发布时间，可以通过该时间判断版本发布的间隔和项目 的活跃程度。 HBase Releases Please make sure youre downloading from a nearby mirror site， not from www.apache.org. We suggest downloading the current stable release. The 0.96.x s
17、eries supercedes 0.94.x. We are leaving the stable pointer on the latest 0.94.x for now while 0.96 is still fresh. File Name File Size Date hbase-0.94.17/ - 26-Feb-2014 01：31 hbase-0.94.18/ - 24-Mar-2014 19：10 hbase-0.96.2/ - 03-Apr-2014 23：18 hbase-0.98.0/ - 07-Feb-2014 01：26 stable/ - 24-Mar-2014
18、19：10 to_remove/ - 07-Apr-2013 20：38 HEADER.html 429 19-Oct-2013 15：49 stable文件夹中存放的是最新的稳定发布版本，从下面的代码中可以看到最新的稳定版本信息，其中发布版本包含文件名字、文件大小和发布日期等参数。在下面两个版本中，带有security后缀的版本 可以使用安全认证和权限控制，基于Kerberos协议结构；另外一个版本是常规版本，一般搭建不需要用户权限控制的集群可以使用这个版本，权限控制部分可以交由中间业务逻辑层控制。 File Name File Size Date hbase-0.94.18-securit
19、y.tar.gz 59108691 24-Mar-2014 19：10 hbase-0.94.18.tar.gz 58691770 24-Mar-2014 19：10 HBase版本从0.94.0到0.96.0，变化比较大，由于Hadoop 2.0发布，HDFS已经发生变化，为了适应Hadoop 2.0的架构改变，HBase提供一个基于Hadoop 2.0的独立版本，该版本只支持Hadoop 2.0。同时，基于Hadoop 1.*版本的HBase继续存在，并且将长期存在，两个版本之间并不兼容，所以在发布、下载界面会看到两种版本的HBase同时存在，如下所示： Name Last modifie
20、d Size Description hbase-0.96.1.1-hadoop1-bin.tar.gz 20-Dec-2013 03：50 70M hbase-0.96.1.1-hadoop1-bin.tar.gz.mds 20-Dec-2013 03：50 1.3K hbase-0.96.1.1-hadoop2-bin.tar.gz 20-Dec-2013 03：50 86M hbase-0.96.1.1-hadoop2-bin.tar.gz.mds 20-Dec-2013 03：50 1.3K hbase-0.96.1.1-src.tar.gz 20-Dec-2013 03：50 4.9
21、M hbase-0.96.1.1-src.tar.gz.mds 20-Dec-2013 03：50 1.1K 由于在写作本书时，HBase的0.96版本分支上只有0.96.1.1版本，所以这里使用该版本作为示例，该示例中包含hadoop 1、hadoop 2和源码三个部分，也是从0.96版本开始，HBase将保持两个版本并 存的状态，这种状态将会在很长一段时间内持续存在。 这里不建议使用非稳定版本，即0.96及以上的版本，因为很多的新功能并没有经过工业界的验证。如果必须使用支持Hadoop 2.0的版本，建议使用0.96这个分支，因为这个分支已经迭代过不少小版 本，相对稳定。另外，一直致力于H
22、adoop技术研发和推广、HBase核心贡献者、Hortonworks高级技术成员Ted Yu对该版本的新功能、特性非常推崇，有些时候还是需要相信权威。 这里需要特别声明一下，本书的知识点讲解、安装部署、实战案例和性能调优等都是基于HBase 0.94版本的，该版本是写作本书时的最新稳定版。 1.2.3 HBase的特性 HBase作为一个典型的NoSQL数据库，可以通过行键（Rowkey）检索数据，仅支持单行事务，主要用于存储非结构化和半结构化的松散数据。与Hadoop相同，HBase设计目标主要依靠横向扩展， 通过不断增加廉价的商用服务器来增加计算和存储能力。 “典型”代表着HBase有不
23、少特性，这些特性都标志着HBase的特立独行、与众不同，同时其良好的出身和特性也奠定了其在大数据处理领域的地位。下面介绍HBase具备的一些非常显著的特点。 1.容量巨大 HBase的单表可以有百亿行、百万列，数据矩阵横向和纵向两个维度所支持的数据量级都非常具有弹性。传统的关系型数据库，如Oracle和MySQL等，如果数据记录在亿级别，查询和写入的性能都会 呈指数级下降，所以更大的数据量级对传统数据库来讲是一种灾难。而HBase对于存储百亿、千亿甚至更多的数据都不存在任何问题。对于高维数据，百万量级的列没有任何问题。有的读者可能关心更加 多的列：千万和亿级别，这种非常特殊的应用场景，并不是说
24、HBase不支持，而是这种情况下访问单个Rowkey可能造成访问超时，如果限定某个列则不会出现这种问题。 2.面向列 HBase是面向列的存储和权限控制，并支持列独立检索。有些读者可能不清楚什么是列式存储，下面进行简单介绍。列式存储不同于传统的关系型数据库，其数据在表中是按某列存储的，这样在查询 只需要少数几个字段的时候，能大大减少读取的数据量，比如一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩和解压算法。下面是传统行式数据库与列式数据库的不同特性。 传统行式数据库的特性如下： 数据是按行存储的。 没有索引的查询使用大量I/O。 建立索引和物化视图需要花费大量的时间和资源。 面
25、对查询需求，数据库必须被大量膨胀才能满足需求。 列式数据库的特性如下： 数据按列存储，即每一列单独存放。 数据即索引。 只访问查询涉及的列，可以大量降低系统I/O。 每一列由一个线索来处理，即查询的并发处理性能高。 数据类型一致，数据特征相似，可以高效压缩。 列式存储不但解决了数据稀疏性问题，最大程度上节省存储开销，而且在查询发生时，仅检索查询涉及的列，能够大量降低磁盘I/O。这些特性也支撑HBase能够保证一定的读写性能。 3.稀疏性 在大多数情况下，采用传统行式存储的数据往往是稀疏的，即存在大量为空（NULL）的列，而这些列都是占用存储空间的，这就造成存储空间的浪费。对于HBase来讲，为
26、空的列并不占用存储空间， 因此，表可以设计得非常稀疏。 4.扩展性 HBase底层文件存储依赖HDFS，从“基因”上决定了其具备可扩展性。这种遗传的可扩展性就如同OOP中的继承，“父类”HDFS的扩展性遗传到HBase框架中。这是最底层的关键点。同时，HBase 的Region和RegionServer的概念对应的数据可以分区，分区后数据可以位于不同的机器上，所以在HBase核心架构层面也具备可扩展性。HBase的扩展性是热扩展，在不停止现有服务的前提下，可以随时 添加或者减少节点。 5.高可靠性 HBase提供WAL和Replication机制。前者保证了数据写入时不会因集群异常而导致写入数
27、据的丢失；后者保证了在集群出现严重问题时，数据不会发生丢失或者损坏。而且HBase底层使用 HDFS，HDFS本身的副本机制很大程度上保证了HBase的高可靠性。同时，协调服务的ZooKeeper组件是经过工业验证的，具备高可用性和高可靠性。 6.高性能 底层的LSM数据结构和Rowkey有序排列等架构上的独特设计，使得HBase具备非常高的写入性能。Region切分、主键索引和缓存机制使得HBase在海量数据下具备一定的随机读取性能，该性能针对 Rowkey的查询能够达到毫秒级别。同时，HBase对于高并发的场景也具备很好的适应能力。该特性也是业界众多公司选取HBase作为存储数据库非常重要
28、的一点。 1 参见https:/cwiki.apache.org/confluence/display/DIRxSBOX/HBase+Prototype。 1.3 HBase与Hadoop的关系 HBase参考了Google的BigTable建模，且将下面三篇博文作为HBase实现的理论基础： BigTable by Google（2006） HBase and HDFS Locality by Lars George（2010） No Relation：The Mixed Blessings of Non-Relational Databases by Ian Varley（2009） 从上
29、面的博文列表中也可以看出，HBase和HDFS有着非常紧密的关系，更准确的说法是：HBase严重依赖Hadoop的HDFS组件，HBase使用HDFS作为底层存储系统。因此，如果要使用HBase，前提 是首先必须有Hadoop系统。从后面第2章的HBase安装过程的讲解中也可以总结出这点。Hadoop的组件之一MapReduce可以直接访问HBase，但是，这不是必需的，因为HBase中最重要的访问方式是 原生Java API，而不是MapReduce这样的批量操作方式。图1-2展示了HBase在Hadoop生态系统中的位置。 图1-2 Hadoop生态系统总图 因为HBase底层依赖Hado
30、op，所以选择Hadoop版本对HBase部署很关键。表1-1显示了不同HBase发行版本所支持的Hadoop版本信息。基于HBase版本，应该选择合适的Hadoop版本，表1-1中是 官方给出的HBase和Hadoop的版本支持矩阵。 表1-1 Hadoop版本支持矩阵 表1-1中字母的含义如下。 S：经过测试的、支持的。 X：不支持。 NT：可以运行但测试不充分。 当然，并不是说只要满足表1-1中的版本匹配就万事大吉了，在考虑版本匹配的同时，也需要考虑一些其他因素，例如： 如果使用0.94.x运行在Hadoop 2.2.0版本上，需要重新编译0.94.x。 对于ZooKeeper的版本只需
31、要跟HBase依赖库中的ZooKeeper保持一致即可。 1.4 HBase的核心功能模块 Hadoop框架包含两个核心组件：HDFS和MapReduce，其中HDFS是文件存储系统，负责数据存储；MapReduce是计算框架，负责数据计算。它们之间分工明确、低度耦合、相关关联。对于HBase 数据库的核心组件，即核心功能模块共有4个，它们分别是：客户端Client、协调服务模块ZooKeeper、主节点HMaster和Region节点RegionServer，这些组件的描述和相互之间的关联关系如图1-3所 示。 图1-3 HBase架构图 1.4.1 客户端Client 客户端Client是
32、整个HBase系统的入口。使用者直接通过客户端操作HBase。客户端使用HBase的RPC机制与HMaster和RegionServer进行通信。对于管理类操作，Client与HMaster进行RPC通信；对 于数据读写类操作，Client与RegionServer进行RPC交互。这里客户端可以是多个，并不限定是原生Java接口，还有Thrift、Avro、Rest等客户端模式，甚至MapReduce也可以算作一种客户端。 1.4.2 协调服务组件ZooKeeper ZooKeeper Quorum（队列）负责管理HBase中多HMaster的选举、服务器之间状态同步等。再具体一些就是，HBa
33、se中ZooKeeper实例负责的协调工作有：存储HBase元数据信息、实时监控 RegionServer、存储所有Region的寻址入口，当然还有最常见的功能就是保证HBase集群中只有一个HMaster节点。 1.4.3 主节点HMaster HMaster没有单点问题，在HBase中可以启动多个HMaster，通过ZooKeeper的Master选举机制保证总有一个Master正常运行并提供服务，其他HMaster作为备选时刻准备（当目前HMaster出现问 题时）提供服务。HMaster主要负责Table和Region的管理工作： 管理用户对Table的增、删、改、查操作。 管理Reg
34、ionServer的负载均衡，调整Region分布。 在Region分裂后，负责新Region的分配。 在RegionServer死机后，负责失效RegionServer上的Region迁移。 1.4.4 Region节点HRegionServer HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region。 HRegion由多个HStore组成，每个HStore对应了Table中的一个Column Family的存储。可以看
35、出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同I/O特性的列放在一个Column Family中，这样能保证读写的高效性。HRegionServer的组成结构如图1-4所示。 如图1-4所示，HStore存储是HBase存储的核心，由两部分组成：MemStore和StoreFile。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore中，当MemStore满了以后会 缓冲（flush）成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact操作，将多个Sto
36、reFiles合并成一个StoreFile，在合并过程中会进行版本合并和数据删除，因 此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。 图1-4 HRegionServer的组成结构 StoreFiles在触发Compact操作后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region分裂成2个Region，父Region会下线，新分裂的2个 子Region会被HMaster分配到相应的HR
37、egionServer上，使得原先1个Region的压力得以分流到2个Region上。 每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Lo推荐序一 2016年早些时候，我曾经写过一篇有关联通Hadoop的文章，在其中的“展望篇”里谈到过OLAP on Hadoop的新技术 Apache Kylin。今天Apache Kylin权威指南一书即将出版，我也有幸受本书作者之一韩卿（Luke）的邀请来写推荐序。 联通集团的BI是2010年建设的，由于全国有4亿用户的明细数据需要集中处理，再加上对移动互联网用户流量日志的采集， 使得数据量急增。截至201
38、3年已达PB级规模，并仍以指数级速度增长，传统数据仓库不堪重负，数据的存储和批量处理成了瓶 颈。另一方面BI上提供的面向用户的数据查询和多维分析服务，使得后台生产的Cube越来越多，几年下来已有七八千个。用户 需求对某一维度的改变往往会造成一个新Cube的产生，耗费资源不说，也为管理带来了极大的不便。2013年年底我们在传统数 据仓库之外搭建了第一个Hadoop平台，节点数也从最初的几十个发展到了今天的3500个，大大提高了系统的存储及计算能 力，为联通大数据对内对外的发展都起到了至关重要的作用。美中不足的是分布式存储和并行计算只解决了系统的性能问题，尽 管我们也部署了像Hive、Impala
39、这样的SQL on Hadoop技术，但在Hadoop体系上的多维联机分析（OLAP）却始终得不到满 意的结果。Oracle+Hadoop的混搭架构还因为有对OLAP的需求而继续维持着，零散的Cube数还在继续增长，架构师们还在继 续寻找奇迹方案的出现。 Apache Kylin就是在这种大背景下出现在我们的视野中的。一个好的产品首先要有一个清晰的定位，要有一套能够明确解 决行业痛点的方案。Kylin在这点上做得非常好，它把自己定义为Hadoop大数据平台上的一个开源OLAP引擎。三个关键词： Hadoop、开源、OLAP，使它的定位一目了然，不用过多地解释。同时，Kylin也是透明的，不像许
40、多产品把自己使用的技术搞 得很神秘，Kylin沿用了原来数据仓库技术中的Cube概念，把无限数据按有限的维度进行“预处理”，然后将结果（Cube）加 载到HBase里，供用户查询使用，使得现有的分析师和业务人员能够快速理解和掌握。相比于IOE时代的BI，它非常巧妙地使用 了Hadoop的分布式存储与并行计算能力，用横向可扩展的硬件资源来换取计算性能的极大提高。 为了能够将Kylin真正融入到联通的大数据架构中，我们正在紧锣密鼓地组织系统测试。比如对单用户级的数据查询、第三 方可视化工具的集成、多维Cube建立的维度数极限等的测试。我们还计划用Kafka来导入数据，用Spark来加工Cube，用
41、其他 产品来代替HBase进而提高数据读取性能，用Kylin的路由选择来桥接新老Cube，等等。这时出版的Apache Kylin权威指南 一书，对于我们来说无疑是雪中之炭，我们的许多疑惑都会在这本指南当中找到权威解答。 联通公司现在经历的这些过程很多企业都会遇到，“坑”我们愿意去填，路希望大家来走。在向读者推荐Apache Kylin 权威指南一书的同时，我们真诚期望Kylin（作为Apache开源社区第一个由中国人开发并主导的产品）能够成功，能够在不断 的实践中提高自己，能够充分利用中国这个占世界数据量20%的大市场，把自己打造成大数据领域的一只独角兽。 范济安 国家千人计划专家 中国联通
42、集团信息化部CTO 推荐序二 我是一个开源软件的爱好者，算是开源届的一名老兵。从1995年到美国留学起，就开始接触开源软件，当时的GNU、 Linux、FreeBSD和Emacs等自由软件让刚出国门的我感到惊艳万分。从那时开始，我就再没有和自由软件、开源软件分开过： 从读博士期间一直参与研发自由软件XSB、因个人爱好参与贡献GNU Emacs、在IBM工作期间基于一系列开源软件为团队开发 DocBook文档写作工具链，到后来在LinkedIn工作期间研究作为5个核心成员开源的分布式实时搜索系统SenseiDB，再到近几 年在小米大力推动开源战略，打造基于开源软件的小米云计算、大数据和机器学习技
43、术及团队。20多年来，对开源软件的热 爱，让我逐渐从一名早期的自由软件爱好者、信仰者、贡献者和管理者，变成了一名坚定的开源软件倡导者。在这期间，我见证 了开源技术的萌芽、兴起和今天的繁荣，也经历了国内外不同文化下的开源发展历程。 作为一名参与开源软件较早的中国人，我也深深地感受到了最初西方世界对中国人使用开源技术、参与开源软件开发的质疑 和冷落。因为互联网和自由软件进入我国较晚，也因为中国人在英语上的不足和东西方文化的差异，还因为早期国内的一些开源 爱好者对开源软件的理解不足，使得在开源方面较为领先的西方开源人士对国人在开源上的使用和贡献存在极大偏见。中国开源 力量融入国际开源社区的过程是缓慢
44、和艰苦的，幸运的是，近四五年来，随着GitHub的兴起和多个开源社区的迅猛发展，中国 每年产生的计算机人才也多了起来，中国越来越多的互联网公司开始正确地拥抱开源，中国工程师在国际开源社区的贡献和影响 力也越来越大（比如，作为一个很年轻的创业公司，小米就在不到一年半的时间里推出了3个HBase committer），这确实不是 一件容易的事。但是，今天不管是在云计算、大数据，还是容器等诸多开源技术领域，真正由中国人自己主导、从零开始、自主 研发、最后贡献到国际开源社区并成为顶级开源项目的，应该就只有Apache Kylin一个。Apache Kylin是2013年由eBay在上海 的一个中国工程
45、师团队发起的、基于Hadoop大数据平台的开源OLAP引擎，它利用空间换时间的方法，把很多分钟级别乃至小 时级别的大数据查询速度一下子提升到了亚秒级别，极大地提高了数据分析的效率，填补了业界在这方面的空白。 我非常高兴能够看到一个来自国内的团队开源一个项目，并在短短不到一年的时间里顺利使其毕业，也使其成为Apache软 件基金会的顶级项目，取得了可以和Hadoop、Spark等重大开源软件相提并论的成就。一支来自国内的工程师团队能够快速融 入国际开源社区，被全球最大的开源软件基金会接纳并成功占领一席之地，这是一件非常不容易的事情，足以让国人欣慰和骄 傲。这一切都和Apache Kylin项目背
46、后的负责人韩卿（Luke）密不可分。我是在QCon北京2014全球软件开发大会上认识韩卿 的，并由此第一次知道了Kylin这个项目，和韩卿开始交谈不久，我就觉得他是当时国内为数不多的、真正懂得开源软件打法的 一个人。那次的交谈非常愉快，从此我也开始关注这个项目并极度看好它。 开源项目，并不是将代码公开就完事了，团队需要做更多艰苦的工作来不断推广技术、经营社区和营销品牌，使得项目能够 被广泛接纳和使用。韩卿及Kylin团队在这方面做得非常出色，在各种国内外的技术大会上、很多开源社区里都可以看到他们忙 碌的身影。在短短的两年时间里，我就看到Kylin项目从Apache孵化器项目毕业成为顶级项目，也
47、看到这个团队离开eBay并创 立了Kyligence这家创业公司。今天，很多成功的重大开源项目背后都有一两个伟大的创业公司：Hadoop背后是Cloudera和 Hortonworks、Spark后面是Databricks，等等。我也看好Apache Kylin后面的Kyligence！ 小米不仅仅是一家手机公司，更是一个大数据公司，公司内部的很多产品和业务都深度依赖大数据分析，我们所面对的数据 量、挑战和困难都是空前的。Apache Kylin独特的数据查询性能优势在小米中有很多应用场景，我希望将来我们能够更多地用 到Apache Kylin技术，也希望和Kyligence能有深度的技术合作。 今年，深度学习和大数据引发了人工智能的热潮，人工智能的热潮反过来也会推动大数据领域相关技术的发展和演进，大数 据领域必将诞生更多的新技术和新产品。相信在不久的未来，会有更多的、类似于Apache Kylin的、由中国人主导的项目从实 际需求中产生、开源并被贡献到国际开源社区，向世界输出我们的技术实力。在将本书推荐给读者的同时，我也希望更多的读 者、团队和公司能一起参与、贡献和拥抱开源，努力提高我国技术人员在国际开源社区的影响力。Apache Kylin项目相关的经 验也非常值得其他技术人员学习和借鉴！ 崔宝秋 小米首席架
