HBase专题博客，持续更新中 https://bbs.huaweicloud.com/topic/detail?id=dd96da5006d045e6aabb8e1ab0156402

Apache Hive是一个构建在hadoop基础设施之上的数据仓库。通过Hive可以使用HQL语言查询存放在HDFS上的数据。HQL是一种类SQL语言，这种语言最终被转化为Map/Reduce. 虽然Hive提供了SQL查询功能，但是Hive不能够进行交互查询–因为它只能够在Haoop上批量的执行Hadoop。Apache HBase是一种Key/Value系统，它运行在HDFS之上。和Hive不一样，Hbase的能够在它的数据库上实时运行，而不是运行MapReduce任务。Hive被分区为表格，表格又被进一步分割为列簇。列簇必须使用schema定义，列簇将某一类型列集合起来(列不要求schema定义)。例如，“message”列簇可能包含：“to”, ”from” “date”, “subject”, 和”body”. 每一个 key/value对在Hbase中被定义为一个cell，每一个key由row-key，列簇、列和时间戳。在Hbase中，行是key/value映射的集合，这个映射通过row-key来唯一标识。Hbase利用Hadoop的基础设施，可以利用通用的设备进行水平的扩展。两者的特点Hive帮助熟悉SQL的人运行MapReduce任务。因为它是JDBC兼容的，同时，它也能够和现存的SQL工具整合在一起。运行Hive查询会花费很长时间，因为它会默认遍历表中所有的数据。虽然有这样的缺点，一次遍历的数据量可以通过Hive的分区机制来控制。分区允许在数据集上运行过滤查询，这些数据集存储在不同的文件夹内，查询的时候只遍历指定文件夹(分区)中的数据。这种机制可以用来，例如，只处理在某一个时间范围内的文件，只要这些文件名中包括了时间格式。HBase通过存储key/value来工作。它支持四种主要的操作：增加或者更新行，查看一个范围内的cell，获取指定的行，删除指定的行、列或者是列的版本。版本信息用来获取历史数据(每一行的历史数据可以被删除，然后通过Hbase compactions就可以释放出空间)。虽然HBase包括表格，但是schema仅仅被表格和列簇所要求，列不需要schema。Hbase的表格包括增加/计数功能。限制Hive目前不支持更新操作。另外，由于hive在hadoop上运行批量操作，它需要花费很长的时间，通常是几分钟到几个小时才可以获取到查询的结果。Hive必须提供预先定义好的schema将文件和目录映射到列，并且Hive与ACID不兼容。HBase查询是通过特定的语言来编写的，这种语言需要重新学习。类SQL的功能可以通过Apache Phonenix实现，但这是以必须提供schema为代价的。另外，Hbase也并不是兼容所有的ACID特性，虽然它支持某些特性。最后但不是最重要的–为了运行Hbase，Zookeeper是必须的，zookeeper是一个用来进行分布式协调的服务，这些服务包括配置服务，维护元信息和命名空间服务。应用场景Hive适合用来对一段时间内的数据进行分析查询，例如，用来计算趋势或者网站的日志。Hive不应该用来进行实时的查询。因为它需要很长时间才可以返回结果。Hbase非常适合用来进行大数据的实时查询。Facebook用Hbase进行消息和实时的分析。它也可以用来统计Facebook的连接数。总结Hive和Hbase是两种基于Hadoop的不同技术–Hive是一种类SQL的引擎，并且运行MapReduce任务，Hbase是一种在Hadoop之上的NoSQL 的Key/vale数据库。当然，这两种工具是可以同时使用的。就像用Google来搜索，用FaceBook进行社交一样，Hive可以用来进行统计查询，HBase可以用来进行实时查询，数据也可以从Hive写到Hbase，设置再从Hbase写回Hive。

论坛编辑有问题，见博客地址：https://bbs.huaweicloud.com/blogs/23a25012a06e11e89fc57ca23e93a89f

测试HBase性能的主流工具有2种，分别是YCSB和HBase自带的PerformanceEvaluation（简称PE），2种工具的对比分析如下： 1.YCSB：最大的优势在于其支持多平台测试，当需要测试不同类型数据库性能对比时，为了统一测试工具，通常会选用YCSB 2.PE：最大的优势为HBase的原生测试工具，当HBase对客户端连接有优化时，PE会最早获得优化效果。而YCSB当前最新版本的hbase client还是基于HBase1.0.2版本，如果在1.0.2版本到1.3.0版本之间，HBase对客户端连接有相关优化时，YCSB享受不到优化效果。 至于其他的一些说法，例如： PE测试case及提供给外界的接口比YCSB更丰富，提供了RandomWrite，SequenceWrite，scan，randomSeekScan，scanRange10 ，scanRange100等说法，个人觉得其实并不准确。YCSB和PE都提供了丰富的可选配置，来模拟指定的用户业务模型。YCSB的常用配置项说明请参考：https://github.com/brianfrankcooper/YCSB/wiki/Core-Properties 那为什么2款工具在默认配置下，测试性能结果会有很大的差异，PE会明显好于YCSB呢？主要原因有2个：1.写入流程不一样，PE使用了批量写HTable.put(List)，而YCSB是使用基本的put接口。批量写最大的好处是可以减少写入时建立网络连接的次数。默认情况下，一次Put操作即要与Region Server执行一次RPC操作，其执行过程可以被拆分为以下三个部分：T1：RTT(Round-Trip Time)，即网络往返时延，它指从客户端发送数据开始，到客户端收到来自服务端的确认，总共经历的时延，不包括数据传输的时间；T2：数据传输时间，即Put所操作的数据在客户端与服务端之间传输所消耗的时间开销，当数据量大的时候，T2的时间开销不容忽略； T3：服务端处理时间，对于Put操作，即写入WAL日志（如果设置了WAL标识为true）、更新MemStore等。其中，T2和T3都是不可避免的时间开销，那么能不能减少T1呢？List put将多次Put操作打包起来一次性提交到服务端，则可以将T1部分的总时间从T1 * N降低为T1，其中T1指的是单次RTT时间，N为Put的记录条数。假设都写入N条记录，PE的RTT为T1，YCSB的RTT为T1*N可见，PE通过引入批量写入，来提升写入性能。但带来的劣势就是可靠性有所降低。 2.两种工具的默认业务模型不一样我们以100%insert场景来说明该问题： 测试过程： 1.使用YCSB和PE分别**10000行数据，每行数据1000B 2.扫描**数据，结果如下： YCSB**数据的scan结果 PE**数据的scan结果： 可以看到，二者的默认数据模型有很大差异： YCSB：1行有1个ColumnFamily，包含了10个Column，每个Column长度为100B。 PE：1行有1个ColumnFamily，包含了1个Column，每个Column长度为1000B。 这种情况下，YCSB没**1行数据，需要调用10次put kv的操作，而PE只需要调用1次，这应该就是测试相同集群时，PE性能明显优于YCSB的原因。 那么，有没有办法让二者的数据模型保持一致呢？ 答案是肯定的，YCSB和PE都提供了灵活的接口来重新定义数据模型，例如： YCSB通过指定fieldlength和fieldcount分别指定column大小和column数量 PE也可以通过column参数指定column数量 总结： YCSB和PE都是优秀的性能测试工具，对于对比测试来说，只有统一测试工具和数据模型、业务模型才能测出有意义的对比数据。跨平台测试优先选择YCSB，只针对HBase进行测试，二者都可选，但PE相对简单，上手速度更快。

本帖最后由 JaisonSnow 于 2018-2-26 17:48 编辑本文首发于：NoSQL漫谈(nosqlnotes.com)：关于Bigtable在近些年做了哪些演进，只能从Cloud Bigtable的官方资料中一探究竟。在详细的分析了Cloud Bigtable的官方资料之后，遗憾的发现，除了云服务本身所需要的一些基础能力，以及为了吸引HBase存量用户而做的HBase接口兼容性工作以外，其它的Features可谓是“捉襟见肘”。曾经的规划在Bigtable论文中，曾提及当时团队成员正忙于二级索引以及跨集群容灾特性的开发：We are in the process of implementing several additional Bigtable features, such as support for secondary indices and infrastructure for building cross-data-center replicated Bigtables with multiple master replicas.直到今天我们所看到的Cloud Bigtable，也未见到这两个特性，猜测当时的部分团队成员已经转向Megastore的开发，或者后来发现这些能力放在一个上层系统中更加合适：[*]在Bigtable中实现二级索引，无非是在现有的Key-Value的接口基础上实现增量。[*]如要支持跨集群容灾能力，在当前架构下，可基于WAL日志的异步复制方案来实现。如构建同步容灾方案，对当前的架构提出了非常大的挑战。这些能力本身已涵盖在Megastore的设计中，所以干脆放弃在Bigtable中支持这些能力，这样还可以继续保持其系统的精简性。Cloud Bigtable与HBaseCloud Bigtable的官方资料中，HBase接口被暴露在最显眼的位置，纵观整个资料上下文，也可以发现HBase的身影“处处可见”。HBase的实现基本上参考了Bigtable论文中的设计，但Bigtable如果介绍一套崭新的接口所需要付出的代价可想而知，所以不得不依靠兼容HBase接口来吸纳更多的用户，可以理解这其中有多少不得已的“苦衷”。相信在很多年前，Google内部关于Bigtable是否开源就已经做过不少讨论，但这是一个“牵一发而动全身”的动作，因为Bigtable用到了很多Google内部的组件。从接口能力上，可以简单对比出来Bigtable与HBase的一些异同：[*]Column Family的可配置参数[*]ACL控制的粒度[*]Reverse Scan能力[*]支持的Filter种类[*]Coprocessor/Snapshot/Namespace/Procedure等高级特性[*]集群管理/表管理接口在后面的文章中将会再给出Bigtable与HBase的详细对比分析。Bigtable在请求时延上的优化从2015年Cloud Bigtable刚刚开放公测时，他们的工程师曾发表过一篇博客文章：Announcing Google Cloud Bigtable这篇文章重点在写吞吐以及P99读写时延方面与HBase/Cassandra做了对比：可以看出，无论是在吞吐量以及P99 Read/Write Latency方面，Bigtable都有显著的优势。虽然近几年HBase在性能上已经取得了不少改进，在P99读写时延方面的确比较诟病，主要受限于底层的HDFS能力。Jeff Dean在2014年的一个演讲(Achieving Rapid Response Times in Large Online Services)中，曾提到Bigtable在读写时延优化方面所做的一些工作，一些关键点包括：[*]Request Adaptation 基于最近的一些读取时延统计来做出一些预判来改善接下来的读取请求时延[*]Backup Request 原理很简单，当某个副本查询响应超出一定时间之后立马将请求发送至另外一个副本，这样可有效降低时延毛刺，类似技术如DistributedLog中的Speculative Read以及HDFS的Hedged Read特性。其它Cloud Bigtable支持多语言客户端，以及与Google Cloud服务的一些对接，都可归类于云服务基础能力，本文不作过多的展开。写在最后与HBase的活跃社区相对比，Bigtable在近些年的发展似乎非常缓慢。一个闭源技术，如不是战略级产品，公司就难有坚定的投入，最后的结局似乎都可预见…..Reference[*]https://cloud.google.com/bigtable/[*]https://conferences.oreilly.com/velocity/velocity2014/public/schedule/detail/34266[*]https://cloudplatform.googleblog.com/2015/05/introducing-Google-Cloud-Bigtable.html声明：本文仅代表个人观点本文首发于：NoSQL漫谈(nosqlnotes.com) 永久链接：Bigtable在近些年的演进