2014到2015年蜕变：大象在跳舞，Hadoop从离线到在线

时代在变迁，市场在变化，周边的软硬件环境也突飞猛进般的发展，同时企业的业务需求也不断升级，从规模到成本都有较高的要求，这刺激Hadoop生态圈的变革。据AMR研究显示，到2020年Hadoop将拥有502亿美元市场。如此多金诱惑下，各大解决方案提供商对Hadoop生态圈的发力可谓是越来越快，顺应潮流，Hadoop生态圈也更为完善和成熟，更是划分出了子生态圈如Spark。正是在这样一个背景下，Hadoop的顺利度过了2014年。

2014业内哪些事情值得关注

1）大数据解决方案提供商hortonworks上市。

大数据软件提供商hortonworks于2014年11月11日向美国证监会提出IPO申请，这标志着Hadoop技术发展开始走入商业阶段，更标志着Hadoop技术从2014年开始真正的成熟了。

2）Hadoop2在开始大规模落地。

Hadoop2从提出到发展至今经历了数年时间，国内外有很多公司在尝试Hadoop2的架构，在这个阶段引领业内潮流并非主流大企业，率先尝试的反而是一些小公司。这些小公司数据量小，规模不大，迁移方便，但这些企业的尝试规模无法真正验证出问题，2013年国外如yahoo开始尝试Hadoop2的落地，并有了业内4500台左右的最大Yarn集群，国内如阿里、美团等企业都在尝试Yarn都取得了几百上千台的成绩，2014年国内腾讯Yarn集群规模接近万台。

3）国内Spark氛围渐浓，欲与Hadoop试比高。

2014年Spark是个爆发年，这一年里Spark社区快速发布了多个版本，最高版本已经到了1.2.0。Spark先是废弃了Shark然后大力发展Spark SQL，与此同时Spark Streaming也更为成熟；Spark社区内部优化无数，空前活跃，各种会议、研究、探讨，围绕Spark本身的周边配套系统也越来越多，形成了Hadoop生态圈内的不可忽视的小生态圈。国内外大小企业都在尝试Spark，如EBay，根据当前公开文献资料，EBay构建了一个大约2000台的Spark集群；如腾讯，构建了一个大约2000台左右的Spark集群，通过Spark挖掘运算之后的模型提供给广告推荐使用，给腾讯广告带来了100亿规模的收入；百度构建了大约1300台的Spark集群。。

盘点2014年展望2015的技术发展：

1 HDFS – 高度挖掘资源利用率的存储

2014年HDFS发布了主要以下特性。

1）更方便的在线升级：

HDFS支持在线升级，FSImage通ProtocolBuffer序列化与反序列化，元数据升级也更为方便。

2）异构存储：

在HDFS支持异构存储媒介的之前，HDFS假设底层存储媒介是同构的，性能完全一样，比如全是HDD（机械盘），但随着新型媒介的出现以及对应成本的下降，很多公司开始尝试使用新的存储媒介，比如SSD。基于此，HDFS也紧跟时代发展潮流，将支持异构存储媒介，即一个HDFS的各个存储节点上可以指定若干不同的存储媒介，比如HDD、SSD等，这样，用户可以根据应用特点将不同类型数据存储在不同媒介上，以满足性能需求。

3）集中管理的DataNode缓存：

即DataNode缓存，目前HDFS中个DataNode上缓存的数据并没有通过适当的途径暴露给外界应用程序，尤其是Spark、Hive、Pig、Impala等这样的计算框架无法充分利用DataNode的内存进行计算优化，比如本地内存、读优化等。该功能将集中管理DataNode缓存，并且统一控制哪些文件需要加载到缓存中来, 从而提高读取性能。

4）端到端的加密：

HDFS实现了一个透明的，端到端的加密方式。一旦配置了加密，从HDFS读出数据解密和写入数据加密的过程对用户应用程序来说都是透明的。加密过程是端到端的，这意味着数据只能在应用程序解密。

5）Archival Storage：

将计算能力与不断增长的存储能力分离。拥有高密度低成本的存储但是计算能力较低的节点将变得利用率更高，比如可以在集群中做冷存储。增加更多的此类节点作为冷存储可以提高集群的存储能力，跟集群的计算能力无关。

未来HDFS社区将发展跨数据中心的容灾：

目前的HDFS只支持机房内的容灾，而且目前的HDFS不支持跨机房部署，无法提供更大规模的全球可用的服务；在跨机房同步数据方面也只能依赖一些导入导出工具离线的操作。HDFS计划未来支持部署在多机房，实现跨机房容灾，零丢失率，低延时。

2 YARN – 面向通用化和服务化

社区对Yarn的定位开始更加通用化，也更面向服务，尤其可以面向7×24小时的服务，针对这些服务，系统需要更加健壮，可靠性更高，因此2014年Yarn发布了以下主要特性：

1）ResourceManager HA：

在hadoop 2.4.1版本中ResourceManager新增HA功能，这意味着集群中最大的单点解决了，系统可用性大大提升。

2）支持Docker：

Yarn的新版本中，支持了Docker，Yarn将使用Docker解决每个container执行环境的问题。使用Docker的Yarn集群将得到更好的资源隔离性，并可以更快速的部署 – Docker有强大的镜像存储和分发能力，开发者可以很方便的从镜像中心获取Hadoop YARN应用的镜像。

Yarn未来社区发展方向：

社区正在针对NodeManager HA特性研发，不久之后就会问世。从2014年的发展和社区最新的动向来看，社区对Yarn的规划是更通用化，更面向服务，尤其在7×24小时服务能力方面重点加强。

3 Spark – 高度活跃的小生态圈

Spark社区在2014年里共发布了四个版本，平均每个季度一个，这里每个版本都有一些新的功能和特性，使得Spark功能越来越丰富，更加可靠和高效。

2014年Spark发布了主要以下特性：

1）Standalone模式

增加Standalone模式下运行的HA功能，使得Spark Streaming的Driver在Standalone模式下当Driver丢失后可自动恢复。

2）GraphX

增加了多个算法，包括PageRank、SVD++、标签传播算法并进入稳定版本。

3）Mllib

新增SVN、PCA、L-BFGS、Word2Vec和TF-IDF、Navie Bayes、Random forests和Gradient-boosted算法，并支持learning pipelines机制这使得多个算法可以在一遍处理过程中执行完成。

4）Spark SQL

已经与Hive 0.13兼容，并可以支持动态分区插入，同时引入了动态字节码生成功能，同时支持多种语言编写的UDF函数。

5）Driver

实现了通过WAL机制来保证HA。

未来Spark社区:

Spark社区发展快速，已经形成了Hadoop生态圈下的小生态圈，并且以独立形式运作，支持高效的内存文件系统和更快速，更丰富的计算，成为Hadoop的一个强有力的补充计算引擎。

4 MR – 持续优化

2014年MapReduce发布了以下主要特性

1）Shuffle Handler提供了keep-alive机制，提高了Shuffle的效率。

2）提供了断点恢复的机制：

这使得已完成MapTask不需要因为NodeManger重启而重跑。

3）计算前数据切分这一步获取文件信息并行化。

4）提供了Rehash Partitioner机制，这个方案使Key的分布更均匀。

5）ApplicationManger由于ResourceManger HA的特性减少了失败重跑的代价。

6）支持任务内资源抢占机制。

未来社区发展方向：

1）由于抢占机制的引入提高了资源被抢占的概率，但为了减少Task被抢占的代价，Task断点恢复的机制加入到规划当中。

2）当前中间结果量的递增，引起磁盘随机读写次数增加导致性能非线性下降，未来将中间结果按Partition聚合和批处理等方案也在讨论当中。

5 HBase – 1.0时代

HBase开始进入1.0时代，系统在稳定性、可用性、易用性方面有质的提升，主要体现的特性如下：

1）HydraBase：

提供高可靠性：Region的副本只有一个是关键Region支持写入，其余的都是在线副本；设定一个延迟，这个延迟以内关键Region没有应答，就把请求发给其他在线副本，保证一致性和可靠性。

Replication Protocol：一组副本之间将只有一个leader，系统将使用RAFT协议来完成leader的选举，leader响应client所有读取和写入的请求，每个副本都会有自己的wal并存储在本地，写操作将由leader同步复制到其他副本。

RMAP：RMAP包含每个Region的quorum配置信息

基于到client的网络延迟，每个数据中心都将有一个Rank，RT最低的数据中心将具有最高等级的Rank，数据中心Rank排名较高、有quorum member资格的将能够接管领导权，较高等级（数据中心Rank加 机器Rank）的副本将最优可能成为leader。

具体架构见下图：

6 Hive – 性能优化

Hive社区在SQL性能优化方面做了大量工作，在2014年取得了许多的突破和进展：

1）ORCFile存储格式完善

丰富了ORCFile的统计信息（提供stripe level的列统计信息）以及外围的接口，让元数据库中存储的统计信息和ORCFile中的统计信息可以配合使用，进一步降低数据读取的代价

2）Hive on Tez

Tez是一个基于Yarn的DAG计算引擎，相比于MapReduce，Tez可以更加灵活的描述计算过程，减少中间结果落地的次数，大大提高了计算效率。Hive On Tez使得那些需要多步MapReduce计算的复杂SQL的执行效率明显提升

3）向量执行

向量查询执行是hive的一大特性，可以显著降低一些典型查询操作的cpu使用率，如扫描、过滤、聚合和连接。传统hive的查询执行是按行进行处理，这样效率很低，向量查询计划是批量处理数据，一次处理上千行数据，每列表示成一个向量，内部循环扫描这些列向量，没有方法调用、反序列化、条件语句等额外开销，提高cpu指令流水线的利用率，从而大大减少cpu的使用。使用此种方式，数据存储必须是ORC格式的。目前支持此种方式的数据类型有: tinyint, smallint, int, bigint, boolean, float, double, decimal, date, timestamp, string。支持此种方式的表达式有：算术表达式、逻辑表达式、比较表达式、数学函数、字符串函数、用户自定义函数、类型转换、日期函数和if表达式。

Hive从0.13版本加入此特性。

4）基于代价的优化器

Hive的基于代价的优化器使用了开源软件Optiq来获取更优的的执行计划。Optiq拥有超过50种优化手段，通过它以及数据统计信息，Hive可以方便的实现Join最优算法，Join最优顺序的选择等。同时它也提升了Hive的易用性，它的存在使得无需用户过多的参与就能得到比较优化的执行计划，从而提升SQL执行效率

5）SQL 完整性

除了性能的优化工作之外，Hive社区也在持续建设SQL的完整性：例如在where子句中使用子查询的功能（IN/NOT IN, EXIST/NOT EXIST）；引入了类似Oracle/PostgreSQL的CTES语法和功能，进一步加强SQL的表达能力；加入char数据类型，完善Decimal数据类型
未来社区发展:

社区计划以完善当前版本为主要目标，但更值得注意的是Hive On Spark工作，Spark目前发展迅速，大有与MapReduce分庭抗礼之势。目前Hive On Spark已经完成基本功能开发以及大部分的bugfix，估计在2015年会正式发布，值得期待。

7 Tez – 孵化成功

Tez是什么？Tez这样一个新兴的技术对大家来说比较陌生，但Tez确是Hadoop家族最有想象力的一个突破。Tez产生的主要原因是绕开MapReduce所施加的限制。除了必须要编写Mapper和Reducer的限制之外，强制让所有类型的计算都满足这一范例还有效率低下的问题——例如使用HDFS存储多个MR作业之间的临时数据，这是一个负载。Tez主要应用了DAG计算模型，它可以将多个有依赖的作业转换为一个作业从而大幅提升DAG作业的性能。2014年Tez成功从Apache项目孵化器中脱离出来成为Apache的顶级项目之一，这预示着Tez开始走向成熟化和产品化。

目前Tez拥有如下几点主要特性：

1）比原生Hadoop MapReduce更好的性能。使用Tez的调度框架可以减少其中不必要的处理阶段，如MRMR我们可以简化为MRR，参考架构示意图如下：

2）具有表现力的数据流API。

3）灵活：可以通过连接不同的输入、处理器和输出动态地构建运行时执行器。

4）数据类型无关性：仅关心数据的移动，不关心数据格式。

5）对MapReduce的无缝兼容，Tez能够运行任意MR任务，不需要做任何改动。

未来社区计划

2014中Tez主要发布了0.5.x系列版本，但大多以bugfix为主题，因此从这点来看2015未来社区也仍旧以稳定成熟为目标。

Hadoop社区虽然繁荣，但无法完全覆盖各种应用场景，即使可用也未必是最优方案，尤其在一些顶级企业中，面临的数据量都是海量的，社区的系统甚至无法考验的。不得不提，面对无法覆盖的需求，有实力的企业会自主研发各种差异化的系统。如百度自己研发了类似Yarn一样的调度系统，阿里自主研发了类似Hadoop的飞天系统，这段时期跟社区走的最近的腾讯自己维护的Hadoop版本跟社区对比也有很大差异，针对大数据的快速多维检索也有Hermes这类产品。

不得不说的持续的技术投入，重复成本较多，开源成为了社会进步的主要元素。BAT企业在开源这块最近几年贡献颇多，成为国内开源技术的引领者，这是一种进步是一种希望，也是在针尖对麦芒的商业背后的一种合作。由衷的希望社会能保持这种合作，让技术最大化的成长，让生态圈更完善。